冒烟测试

冒烟测试 (smoke testing)，据说是微软起的名字。在《微软项目求生法则》一书第 14 章“构建过程”关于冒烟测试，就是开发人员在个人版本的软件上执行目前的冒烟测试项目，确定新的程序代码不出故障。

冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。

冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

在一般软件公司的软件编写过程中，内部需要编译多个版本 (Build)，但是只有有限的几个版本需要执行正式测试（根据项目开发计划），这些需要执行的中间测试版本，在刚刚编译出来后，软件编译人员需要进行基本性能确认测试，例如是否可以正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等 Bug。如果通过了该测试，则可以根据正式测试文档进行正式测试。否则，就需要重新编译版本，再次执行版本可接收确认测试，直到成功。

新版本的基本功能确认检查的测试，有的公司称为版本健康检查 (Build Sanity Check)。对于编译的本地化软件新版本，除了进行上面提到的各种测试检查，还要检查是否在新的本地化版本中正确包含了全部应该本地化的文件。可以通过采用文件和目录结构比较工具，首先比较源语言版本和本地化版本的文件和目录中的文件数目、文件名称和文件日期等，这个过程称为版本镜像检查 (Build Image Check)。其次，分别安装源语言版本和本地化版本，比较安装后的文件和目录结构中的文件数目、文件名称和文件日期等，这个过程称为版本安装检查 (Build Installing Check)。

在进行冒烟测试前检查代码

在运行 冒烟测试前，进行侧重于代码中的所有更改的代码检查。代码检查是验证代码质量并确保代码无缺陷和错误的最有效、最经济的方法。 冒烟测试确保通过代码检查或风险评估标识的主要的关键区域或薄弱区域已通过验证，因为如果失败，测试就无法继续。

在干净的调试版本中安装私有二进制文件

由于 冒烟测试必须侧重于仅对更新后的 二进制文件中的功能更改进行验证，所以必须通过使用被测试文件的调试二进制文件来使测试在干净的 测试环境中运行。

注意：在 冒烟测试中，使用不匹配的二进制 文件进行测试是一个常见错误。为了避免此错误，当两个或多个更新后的 二进制文件之间存在依赖项时，请在测试版本中包括所有更新后的二进制文件。否则，测试的结果可能无效。

创建每日构建(Daily Build)

每日构建要求 团队成员 协同工作，并鼓励开发人员彼此保持同步。如果新版本的迭代被延迟，则该延迟很容易导致具有多个依赖项的产品不同步。遵循 每日构建和 冒烟测试的过程，任何更改过的或新的 二进制文件都可确保实现高质量。

注意：将高质量的 每日构建作为 团队最重要的任务。如果由于嵌入代码未进行 冒烟测试而导致版本中断，则需要开发人员和测试人员停止所有其他工作，直到问题被解决为止。对导致中断版本的人员的处罚不应该很重，但这个处罚一定要能强调这样一个道理：正确构建是 团队最重要的任务。

不需要执行 穷举测试。 冒烟测试的目的不是确保 二进制文件100%没有错误。这样需要花费太多的时间。执行 冒烟测试是为了在高级别验证版本。要确保 二进制文件中的更改不会破坏常规版本的稳定性，也不会导致功能中出现严重错误。

Web测试和负载测试

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