冒烟测试

17 Mar 2025 | 6 分钟阅读

当开发团队提交构建软件时,冒烟测试就派上用场了。冒烟测试的目的是确定软件构建是否可测试。它在“构建软件”时进行。此过程也称为“第 0 天”。

这是一个节省时间的过程。它减少了测试时间,因为测试只在应用程序的关键功能不起作用或关键错误未修复时进行。冒烟测试的重点是应用程序核心和主要功能的工作流程。

在进行深入、严格的测试(在检查所有可能的正负值之前)之前,测试应用程序的基本和关键功能,就称为冒烟测试。

在冒烟测试中,我们只关注应用程序的正向流程,只输入有效数据,不输入无效数据。在冒烟测试中,我们验证每个构建是否可测试;因此,它也称为**构建验证测试**。

当我们执行冒烟测试时,我们可以及早发现阻塞性错误,这样测试工程师就不会无所事事,或者他们可以继续进行并测试**独立的、可测试的模块**。

注意

  • 测试工程师知道该模块是独立可测试的,因为我们已经对它们进行了一轮冒烟测试。
  • 开发团队可以花时间修复错误,而且他们不会感到压力,因为测试团队不会无所事事,而且发布不会被推迟,因此这是一个节省时间的过程。

执行冒烟测试的流程

冒烟测试不需要设计测试用例。只需要从已设计的测试用例中挑选所需的测试用例。

如上所述,冒烟测试侧重于核心应用程序的工作流程;因此,我们选择能够覆盖应用程序主要功能的测试用例集。测试用例的数量应尽可能少,并且执行时间不得超过半小时。

何时执行冒烟测试

通常,每当安装新构建时,我们都会执行一轮冒烟测试,因为在最新的构建中,我们可能会遇到阻塞性错误。因为可能会有一些更改破坏了主要功能(修复错误或添加新功能可能会影响原始软件的很大一部分),或者我们在安装时进行冒烟测试。

当稳定的构建安装在任何地方(测试服务器、生产服务器和用户验收测试)时,我们都会进行冒烟测试以查找阻塞性错误。

Smoke Testing

让我们使用一些不同的场景,这有助于我们更好地理解何时进行冒烟测试

场景 1

开发人员开发应用程序并将其交给测试团队,然后测试团队将开始进行功能测试

假设我们有四天的时间进行**功能测试**。第一天,我们检查一个模块,第二天,我们检查另一个模块。第四天,我们发现了一个**关键错误**。当将其交给开发人员时,他/她会说这需要再花两天时间来修复。然后我们不得不将发布日期推迟这两天。

Smoke Testing

为了克服这个问题,我们执行**冒烟测试**,让我们看看它是如何工作的。在上述情况下,与其逐个模块进行彻底测试并在最后得出关键错误,不如在进行功能、集成和系统测试之前进行**冒烟测试**,也就是说,在每个模块中,我们都必须测试基本或关键功能,然后再进行进一步测试,正如我们在下面的图片中看到的那样。

Smoke Testing
Smoke Testing

场景 2

在执行功能测试时,如果测试工程师在早期阶段识别出主要错误,有时开发人员在早期阶段发现主要错误并不合适。因此,测试工程师会在进行功能、集成、系统和其他类型的测试之前执行冒烟测试。

在进行冒烟测试时,测试工程师发现主要错误,他/她会交给开发团队进行修复。错误修复后,测试工程师将继续进行进一步的测试,正如我们在下面的图片中看到的那样。

Smoke Testing

情况 3

在这种情况下,如果我们已经执行了冒烟测试并发现了阻塞性错误,并且也解决了该错误。在执行系统测试后,我们将应用程序从测试服务器发送到最终用户服务器进行一轮用户验收测试。当客户执行验收测试并且没有发现任何问题并且对应用程序感到满意时,因为我们已经执行了冒烟测试。

Smoke Testing

场景 4

验收测试完成后,应用程序将被部署到生产服务器。我们在生产服务器上执行了一轮冒烟测试,以检查应用程序是否安装正确。如果任何真实用户发现任何阻塞性错误,他们会感到恼火,并且不会再次使用该应用程序,这可能会导致客户业务损失,正如我们在下面的图片中看到的那样。

Smoke Testing

为了将来避免这个问题,开发团队经理、测试团队经理将获取客户登录信息并进行一轮冒烟测试。

**例如**,真实用户正在使用 Facebook 应用程序,并且每次我们都会在内部更新新功能,而实际用户不会受到影响,因为他们不知道内部的变化,并且可以正常使用该应用程序。

在生产服务器上,**业务分析师 (BA)、开发团队经理、测试团队经理、构建团队和客户**都可以进行冒烟测试。

为什么我们要做冒烟测试?

  • 我们将进行冒烟测试以确保产品是可测试的。
  • 我们将在开始时执行冒烟测试,检测基本功能中的错误,然后将其发送给开发团队,以便开发团队有足够的时间来修复错误。
  • 我们进行冒烟测试以确保应用程序已正确安装。

注意

  • 在应用程序开发的早期阶段,如果我们进行冒烟测试,它会发现更多的错误。但在应用程序开发的后期阶段,如果我们进行冒烟测试,我们在冒烟测试中捕获的错误数量将非常少。因此,冒烟测试的投入精力相对较少。
  • 我们何时对每个构建进行冒烟测试?

每当安装新构建时,我们都会确保该构建是否可测试,如果可测试,则执行冒烟测试,正如我们在下面的图片中看到的那样。

Smoke Testing

冒烟测试的类型

冒烟测试分为两种类型

正式冒烟测试

在此过程中,开发团队将应用程序发送给测试负责人。然后,测试负责人将指示测试团队进行冒烟测试,并在执行冒烟测试后发送报告。测试团队完成冒烟测试后,会将冒烟测试报告发送给测试负责人。

非正式冒烟测试

在此,测试负责人表示应用程序已准备好进行进一步测试。测试负责人不要求进行冒烟测试,但测试团队仍通过进行冒烟测试来开始测试应用程序。

实时示例

假设我们正在使用一个电子商务网站,该网站的核心功能应该是登录、特定搜索、将商品添加到购物车、将商品添加到收藏夹、支付选项等。在这里,我们正在测试下订单的功能。测试后,测试人员必须对应用程序功能的正常运行有信心。

工作流程的步骤如下

  • 点击商品
  • 应打开描述页面。
  • 点击添加到购物车
  • 应打开购物车
  • 点击立即购买
  • 应显示付款选项。选择其中一种。
  • 订单已下
Smoke Testing

如果此功能正常工作,那么测试人员将在测试中通过它,然后测试同一个应用程序的下一个功能。

冒烟测试的优点

  • 这是一个节省时间的过程。
  • 在早期阶段,我们可以发现错误。
  • 它有助于恢复系统质量,从而降低风险。
  • 它易于执行,因为它节省了我们的测试工作和时间。

下一主题健全性测试