冒烟测试(smoketesting)每日构建(DailyBuild).docVIP

冒烟测试(smoke testing)每日构建 (Daily Build)关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日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.对开发进度计划的要求，需要细化