关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说，冒烟测试就是在每日build建立后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。从这一点看和所谓的“接受性（验收）测试（Acceptance Test）”非常相似。不同之处就在于他们执行的频率和被测的版本不同。
至于冒烟测试这个名称的来历，大概是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟在进行其它测试，否则就必须重新来过。类似的如果冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正，测试人员测试的版本必须首先通过冒烟测试的考验。
冒烟测试的说法据说是：
就象生产汽车一样，汽车生产出来以后，首先发动汽车，看汽车能否冒烟，如果能，证明汽车最起码可以开动了。说明完成了最基本的功能。
冒烟测试准则
在软件中，“冒烟测试”这一术语描述的是在将代码更改签入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。
注意
“冒烟测试”这一术语源自硬件行业。该术语源于此做法：对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。
下面的准则描述了冒烟测试的最佳做法。遵循准则的效果会有很大的不同，从增强团队成员之间的交流，到形成特定的使用测试和调试工具的方式等。
与开发人员协同工作
由于冒烟测试特别关注更改过的代码，因此必须与编写代码的开发人员协同工作。必须了解以下内容：
- 代码中进行了什么更改。若要理解该更改，必须理解使用的技术；开发人员可以提供相关说明。
- 更改对功能有何影响。
- 更改对各组件的依存关系有何影响。
在进行冒烟测试前检查代码
在运行冒烟测试前，进行侧重于代码中的所有更改的代码检查。代码检查是验证代码质量并确保代码无缺陷和错误的最有效、最经济的方法。冒烟测试确保通过代码检查或风险评估标识的主要的关键区域或薄弱区域已通过验证，因为如果失败，测试就无法继续。
在干净的调试版本中安装私有二进制文件
由于冒烟测试必须侧重于仅对更新后的二进制文件中的功能更改进行验证，所以必须通过使用被测试文件的调试二进制文件来使测试在干净的测试环境中运行。
创建每日构建 (Daily Build)
每日构建要求团队成员协同工作，并鼓励开发人员彼此保持同步。如果新版本的迭代被延迟，则该延迟很容易导致具有多个依赖项的产品不同步。遵循每日构建和冒烟测试的过程，任何更改过的或新的二进制文件都可确保实现高质量。
将高质量的每日构建作为团队最重要的任务。如果由于签入代码未进行冒烟测试而导致版本中断，则需要开发人员和测试人员停止所有其他工作，直到问题被解决为止。对导致中断版本的人员的处罚不应该很重，但这个处罚一定要能强调这样一个道理：正确的每日构建是团队最重要的任务。
不需要执行穷举测试。冒烟测试的目的不是确保二进制文件 100% 没有错误。这样需要花费太多的时间。执行冒烟测试是为了在高级别验证版本。要确保二进制文件中的更改不会破坏常规版本的稳定性，也不会导致功能中出现严重错误。
Web 测试和负载测试
生成 Web 测试和负载测试时，在运行任何时间长、工作量大的测试之前运行冒烟测试是一种很好的做法。在 Web 测试和负载测试中，冒烟测试时间短，工作量也小。使用冒烟测试是为了在运行性能测试或压力测试之前，确保一切都已正确配置并可按预期运行。
每日构建和冒烟测试的优点主要有:
1.进度可见并可以控制到1-2天的细粒度，很容易看到进度的偏差
2.及早的发现开发BUG和缺陷并分析解决，对开发人员的一种监督和促进，提高软件质量
3.由于将大集成分解到每日构建中的小集成，避免了传统产品集成或集成测试时候出现的严重问题的可能。
4.在项目中宣灌质量意识，强调第一次就把事情做好，而不是等测试来帮你发现问题
每日构建和冒烟测试也存在一些风险和缺陷，具体主要有
1.给开发人员太大压力，开发每天都在较紧张环境中工作
2.需要额外的测试人力资源和每日构建硬件环境的投入
3.开发人员不能专注，既要分心去修改BUG，又要开发新的功能点
4.对开发负责人要求更好，需要将功能细化到1-2天的有明确输出的功能点
5.开发需要投入额外的精力来保证每日构建顺畅
适用场景
1.对进度偏差控制和要求很高的项目
2.开发检查点和里程碑制定的很细致的项目
3.采用增量和迭代开发的项目,快速和敏捷开发的项目
每日构建提前需要进行的准备工作
1.对开发进度计划的要求，需要细化出每1-2天的开发进度计划，可以到一个很小的功能点。
2.对每日构建测试计划的要求，需要根据开发进度计划来安排冒烟测试和系统测试进度计划。
3.需要提前准备好每日构建的环境(每日构建必须是独立的环境)
每日构建和冒烟测试工作的实现可以人工来实现，但更多的需要借助些自动化的工具来完成。对于每日构建一般要提前编写好每日够建的脚本，可以借助Ant或NAnt构建工具来完成。每日构建脚本的复杂性跟项目或系统本身复杂性相关，对于简单的只有一个项目的解决方案，可能构建脚本会很简单，而对于较复杂的系统或项目构建脚本将会教复杂。NAnt是一个强大的通过构建脚本自动编译的工具，在NAnt里面会做如下事情，而这个即使打开解决方案来编译也无法做到。
1.调用批文件重新自动生成数据访问层组件
2.创建相关的部署需要的cs_client,bs_client,server,service相关目录并拷贝公用文件
3.按照公用项目->逻辑层->界面层顺序和项目间依赖关系对各个项目逐一编译
4.调用外部工具soapsuds生成数据访问dll的代理类文件,逻辑层重新引用代理类进行编译(分布式部署需要)
5.引用3,4步需要的dll对Web项目进行编译
6.拷贝编译结果到相关的输出目录
每日构建和每日编译的最大区别就在于是否进行了冒烟测试，系统必须通过了冒烟测试才能够算每日构建成功。而测试人员人工介入的测试是基于冒烟测试通过的基础上面的。这里很简单一个例子，如我们NAnt配置文件忘记拷贝一个公共文件到server目录了，这个时候每日编译可能是通过的，但如果把这个版本部署出去测试无法进行测试的。或者说冒烟测试的一个重要作用就是要彻底解决由于构建自身原因引起的各种缺陷或Bug。
冒烟测试由于要验证整个编译的正确性，因此冒烟测试必须是针对整个系统进行冒烟测试。但冒烟测试只需要关注系统的主体功能即可，通过冒烟测试并不是说系统没有BUG，只是说通过了冒烟测试后可以说系统是一个稳定的版本，说系统的每日构建是成功了，代表系统可以转交专门的测试人员进行测试了。冒烟测试工作一般要采用自动化来进行，可以借助如LoadRunner等工具来录制自动化测试脚本，冒烟测试的脚本应该由专门的测试人员来维护，而且随着测试的进展冒烟测试脚本也应该是不断增加和补充的。
对于每日构建失败，直接责任的开发人员需要程度责任并付出代价。微软顾问经常爱举的一个例子就是凌晨2,3点开发人员被叫到公司解决每日构建失败的问题的案例。实际操作可能很难，但对构建造成影响的必须要承担应有的责任。
每日构建一般要配合使用源代码管理工具，而构建时间一般安排在每天下班后或晚上进行。开发人员需要保证每天检入的代码是能够顺利编译通过的，并保证在本机已经做了相关测试。每日构建并不是一定要要求每天都有新的功能点完成，如果今天开发完成的东西不是一个独立的可以提交测试的功能点，这个时候当天的源代码最好不要检入。代码的检入周期一般要在2-3天内，如果周期再长基本上就达不到每日构建的作用了。
每日构建必须有独立和专门的构建服务器和构建环境。构建服务器和构建环境与测试环境的最大区别在于构建环境是完全Copy开发环境，单独出构建环境目的是保证构建过程不和开发环境和过程冲突。如果条件不允许的话可以将构建环境和测试环境合并，但构建环境必须和开发环境分离。
每日构建的成功要素
1.每天都进行编译和冒烟测试
2.冒烟测试脚本随着测试的进度不断完善和补充
3.构建成功在项目中拥有较高的优先级
4.通过过程的制定保证构建失败更多的是因为异常因素而非规则不清
5.在压力下不要抛弃过程
404
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
