关于Smoke Test

Smoke Test (冒烟测试）在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。

在很多情况下，做Smoke Test是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率比较低。

“冒烟测试”（Smoke Test）这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给冒烟测试设备加电。如果没有冒烟，则该组件就通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。

介绍
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。冒烟测试一般用于每日构建(Nightly build)，构建服务器首先从CVS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执 行最基本的功能，则认为通过了冒烟测试，这时，构建服务器会把程序打包成安装文件，然后上传到内部网站，第二天一早，测试人员来了以后，会收到构建服务器发来的邮件提示昨晚是否构建成功。若构建成功，则测试人员进行相关的功能测试。

准则   
与开发人员协同工作由于冒烟测试特别关注更改过的代码，因此必须与编写代码的开发人员协同工作。必须了解以下内容：
1、代码中进行了什么更改。若要理解该更改，必须理解使用的技术；开发人员可以提供相关说明。
2、更改对功能有何影响。
3、更改对各组件的依存关系有何影响。
在进行冒烟测试前检查代码在运行冒烟测试前，进行侧重于代码中的所有更改的代码检查。代码检查是验证代码质量并确保代码无缺陷和错误的最有效、最经济的方法。冒烟测试确保通过代码检查或风险评估标识的主要的关键区域或薄弱区域已通过验证，因为如果失败，测试就无法继续。

在干净的调试版本中安装私有二进制文件
由于冒烟测试必须侧重于仅对更新后的二进制文件中的功能更改进行验证，所以必须通过使用被测试文件的调试二进制文件来使测试在干净的测试环境中运行。注意：在冒烟测试中，使用不匹配的二进制文件进行测试是一个常见错误。为了避免此错误，当两个或多个更新后的二进制文件之间存在依赖项时，请在测试版本中包括所有更新后的二进制文件。否则，测试的结果可能无效。

创建每日构建 (Daily Build)
每日构建要求团队成员协同工作，并鼓励开发人员彼此保持同步。如果新版本的迭代被延迟，则该延迟很容易导致具有多个依赖项的产品不同步。遵循每日构建和冒烟测试的过程，任何更改过的或新的二进制文件都可确保实现高质量。注意：将高质量的每日构建作为团队最重要的任务。如果由于签入代码未进行冒烟测试而导致版本中断，则需要开发人员和测试人员停止所有其他工作，直到问题被解决为止。对导致中断版本的人员的处罚不应该很重，但这个处罚一定要能强调这样一个道理：正确日构建是团队最重要的任务。不需要执行穷举测试。冒烟测试的目的不是确保二进制文件100%没有错误。这样需要花费太多的时间。执行冒烟测试是为了在高级别验证版本。要确保二进制文件中的更改不会破坏常规版本的稳定性，也不会导致功能中出现严重错误。

Web测试和负载测试
生成Web测试和负载测试时，在运行任何时间长、工作量大的测试之前运行冒烟测试是一种很好的做法。在Web测试和负载测试中，冒烟测试时间短，工作量也小。使用冒烟测试是为了在运行性能测试或压力测试之前，确保一切都已正确配置并可按预期运行。