编辑本段简介
冒烟测试(smoke test)在测试中发现问题,找到了一个Bug,然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug,或者是否会对其它模块造成影响,就需要针对此问题进行专门测试,这个过程就被称为Smoke Test。在很多情况下,做Smoke Test是开发人员在试图解决一个问题的时候,造成了其它功能
模块一系列的连锁反应,原因可能是只集中考虑了一开始的那个问题,而忽略其它的问题,这就可能引起了新的Bug。Smoke Test优点是节省测试时间,防止build失败。缺点是覆盖率比较低。
冒烟测试是自由测试中的一种。
编辑本段来源
冒烟测试(smoke testing),据说是
微软起的名字。在《
微软项目求生法则》一书第14章“构建过程”关于
冒烟测试,就是开发人员在个人版本的
软件上执行目前的冒烟测试项目,确定新的程序代码不出故障。
编辑本段应用
在一般
软件公司,软件在编写过程中,内部需要编译多个版本(Builds),但是只有有限的几个版本需要执行正式测试(根据项目开发计划),这些需要执行的中间测试版本,在刚刚编译出来后,软件编译人员需要进行基本性能
确认测试,例如是否可以正确安装/
卸载,主要功能是否实现,是否存在严重死机或数据严重丢失等Bug。如果通过了该测试,则可以根据正式测试文档进行正式测试。否则,就需要重新编译版本,再次执行版本可接收
确认测试,直到成功。
编辑本段现状
新版本的基本功能确认的测试,有的公司称为版本健康检查(Build Sanity Check)。
对于编译的本地化
软件新版本,除了进行上面提到的各种检查,还要检查是否在新的本地化版本中正确包含了全部应该本地化的
文件。可以采用
文件和
目录结构比较工具,首先比较源语言版本和本地化版本的文件和目录中的文件数目、文件名称和文件日期等,这个过程称为版本
镜像检查(Build Image Check);其次,分别安装源语言版本和本地化版本,比较安装后的
文件和目录结构中的文件数目、文件名称和文件日期等,这个过程称为版本安装检查(Build Installing Check)。
编辑本段准则
与开发人员
协同工作
1、代码中进行了什么更改。若要理解该更改,必须理解使用的技术;开发人员可以提供相关说明。
2、更改对功能有何影响。
3、更改对各组件的依存关系有何影响。
在进行冒烟测试前检查代码
在运行
冒烟测试前,进行侧重于代码中的所有更改的代码检查。代码检查是验证代码质量并确保代码无缺陷和错误的最有效、最经济的方法。
冒烟测试确保通过代码检查或风险评估标识的主要的关键区域或薄弱区域已通过验证,因为如果失败,测试就无法继续。
在干净的调试版本中安装私有二进制文件
注意:在
冒烟测试中,使用不匹配的二进制
文件进行测试是一个常见错误。为了避免此错误,当两个或多个更新后的
二进制文件之间存在依赖项时,请在测试版本中包括所有更新后的二进制文件。否则,测试的结果可能无效。
创建每日构建(Daily Build)
每日构建要求
团队成员
协同工作,并鼓励开发人员彼此保持同步。如果新版本的迭代被延迟,则该延迟很容易导致具有多个依赖项的产品不同步。遵循
每日构建和
冒烟测试的过程,任何更改过的或新的
二进制文件都可确保实现高质量。
注意:将高质量的
每日构建作为
团队最重要的任务。如果由于嵌入代码未进行
冒烟测试而导致版本中断,则需要开发人员和测试人员停止所有其他工作,直到问题被解决为止。对导致中断版本的人员的处罚不应该很重,但这个处罚一定要能强调这样一个道理:正确日构建是
团队最重要的任务。