今天，我们将讨论一个完美的软件交付工作流中必不可少的两个环节，烟雾测试，及与之紧密相关的健康测试。这两个测试负责检测产品中大大小小的更改，保证程序能够按照原计划顺利运行。这些更改可能是对整个产品没有什么影响的简单用户界面修改，也可能是会影响整个程序的大规模后端更改。
有一些人可能以为烟雾测试和健康测试是一样的，但你仔细对比每种测试的用例，就能意识到这两者的区别。烟雾测试用于检查整个应用程序。在许多情况下，烟雾测试覆盖应用程序的所有主要功能。健康测试则更具针对性，用于测试应用程序的特定功能。
了解所有关于烟雾和健康测试的知识，能让你和团队在正确的时间采用正确的测试方法。尽管两种测试多少有些类似，但在特定时候，它们还是无法互相替代的。另外，我们也将进一步学习，在应用程序完整的端到端测试中，这两者将如何相互补充。
烟雾测试，从头到尾保障程序安全运行
健康测试与烟雾测试的主要区别，在于发布功能所需的测试级别和类型。通常，烟雾测试是这样进行的，软件产品的所有关键功能都需要一一进行测试，直到显示 “通过”。这个过程可以通过手动或自动测试技术实现。在烟雾测试期间，任何一个测试失败，意味着代码的更改可能引入了一些缺陷。
烟雾测试通常由质检人员完成。在某些情况下，开发人员可能会在本地进行某种形式的烟雾测试。不过无论如何，烟雾测试的主要任务都是：
- 用于从头到尾检测应用程序主要功能的关键路径。通常包括后端 API 测试，使用 Postman 或 CI/CD 管道等自动测试方法。
- 为门控签入等方法提供检查点。这类构建测试是保护代码库，不受引入错误的影响。
- 作为第一道防线，在进入质量检测环节之前，识别明显错误。
烟雾测试帮助检查应用程序的方方面面，使开发始终能聚焦在功能请求、重构或新错误上。这个简单的测试步骤，补充了团队的开发工作流程，帮助提高开发速度，同时创建更稳定的产品。
另外，在健康测试的基础上实行烟雾测试，是提高程序代码质量的好办法。在这类测试中，可以在开发人员的工作站上使用可编写脚本的测试产品，进行自动化测试。这种方法可以阻止一些简单问题渗入其他环境，进而帮助其他团队节省再次测试或验证的时间。
自动烟雾测试，何时应该集成至 CI/CD 管道？
烟雾测试用于验证产品的各个部分。因此，经常需要使用自动化来减少质检人员手动检查所需的时间。像前面提到的脚本解决方案，可以为代码质量检查提供更多机会。
另外，烟雾测试主要用在 CI/CD 进程的部署阶段。无论是开发环境还是已知的质检环境。使用测试矩阵，可以调用程序的各个关键部分，通过前端或后端方法进行测试。因此，全面了解产品，才能保证测试滴水不漏，精准覆盖程序的各个功能。
团队在 CI/CD 进程中实施此类自动烟雾测试的方法有很多。对于 Azure 用户来说，可以运行 Visual Studio 测试任务。那些使用 Jenkins、TravisCI 等工具的团队，可添加“run”步骤，帮助快速完成测试。不论哪种情况，将烟雾测试添加到 CI/CD 管道，都可以帮助团队大幅提升代码质量。
简化的健康测试
与烟雾测试一样，健康测试也是然用于验证构建。但在结构上，健康测试更为随意。其功能主要集中在范围更窄的测试矩阵中，这类测试通常可以替换部分烟雾测试。但是，健康测试是一个更加直接的方法，检测具体的更改。
使用健康测试时，工程师应该先准确定位与更改区域相关的程序缺失或损坏。此外，任何与代码更改有关系的项目都应该进行更彻底地测试，以确保它们仍然可以正常工作，包括各种大大小小的更改。
健康测试的主要功能包括：
- 高度集中的测试矩阵，用于在代码更改后验证应用程序特定区域的前端和后端功能。
- 与全套的脚本或构建测试相比，健康测试更为简单。
- 可在进行完整的程序回归测试之前，识别错误。
说健康测试简单，但测试范围却更加集中，可能有点矛盾。说其简单，主要是因为这种验证可以通过“点菜方式”按需进行测试。在烟雾测试大范围地验证之后，测试人员可以将重点放在产品的特定部分，而不用等待回归测试完成。
另一方面，一些健康测试的方法也可以扩展成为烟雾测试。准确、重复地使用这些测试方法，可以建立一个完整的检测周期，验证程序是否能顺利运行。
烟雾测试和健康测试的用例
博客读到这，想必大家都应该清楚烟雾和健康测试的不同之处。接下来，我们将使用两个例子来说明两种测试的使用场景。在这些场景中，我们也将对比烟雾测试和健康测试的使用时间。
在两种使用场景中，我们都是开发一个虚拟的 web 应用程序，用于显示网络运营中心（N.O.C.）的各种警报仪表盘。这是一个标准动态 web 应用程序，具有典型的数据库连接要求。
场景 1
在这个场景中，我们对产品的企业标志进行了更改。代码修改完成并提交到源代码，CI/CD 进行构建并打包代码。这些更改包括样式更改，以及其他一些预计不会影响产品整体功能的修改。
最佳的操作是需要完成烟雾测试，查找任何明显问题。这些问题的出现可能与进行的更改相关，也可能没有直接关系。因为简单的错误或复杂的代码合并都可能引发代码问题。在这一点上，CI/CD 管道内的自动健康测试可以验证环境有没有被破坏，但手动烟雾测试可以保证在视觉上，所有更改都是正常状态。记录这些烟雾测试结果，接下来，我们可以进一步进行回归测试，保证将来的版本中不会出现任何错误。因为在将来的产品版本中不会涉及用户界面更改。
场景 2
要升级虚拟程序后端使用的数据库，需要更改与数据连接相关的代码。与第一个场景一样，此更改将提交到源代码，并进行构建、部署和测试。与其他变更流程一样，第一道防线可能包括烟雾测试。但鉴于我们只是修改产品中特定的数据输入和输出部分，因此我们需要采取针对性的测试方法，为后续的烟雾测试指明方向。这可能包括手动测试，确保数据库连接存在、稳定，并且不会对现有数据造成无法修复的损坏。
所以，我们应该使用健康测试来确保程序的基本层面完好无损。大部分情况下，应该先运行健康测试，然后进行烟雾测试，在版本发回开发团队之前将基本问题拦截。
或者，在健康测试之前运行烟雾测试，开发团队可在一个安全版本的基础上进一步往前推进。这个安全版本通过烟雾测试的保障，符合开发级别的需求。随后，健康测试可以在测试阶段进行。这种方法的理念是“先排除大问题，再用健康测试解决小问题”。
结合烟雾测试和健康测试，保障程序的现在和将来版本
显然，默认情况下，烟雾测试的应用范围更广，特别是在自动化软件交付管道中，不过一些手动健康测试也是不可或缺的。两者有效结合才能保证整个应用程序没有新的错误。
了解什么时候需要增加健康测试，常常是软件开发人员和测试人员考虑的主要问题。如前所述，某些健康测试部分可能是未来烟雾和回归测试的基础。这两种方法的结合提升整个测试的性能，也可以更有效地测试未来的代码变更。
