冒烟测试.doc

冒烟测试.doc

《冒烟测试.doc》由会员分享，可在线阅读，更多相关《冒烟测试.doc（3页珍藏版）》请在冰豆网上搜索。

冒烟测试

1.什么是冒烟测试

冒烟测试，是对软件基本的功能进行测试，测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本的功能正常，保证软件系统能跑的起来,可以进行后续的正式测试工作，如果最基本的测试都有问题，就直接打回开发部了，所以正式交付测试的版本必须首先通过冒烟测试的考验。

不做冒烟测试的问题：

测试人员直接测的话,测试执行一半或者刚开头，就出现基本功能有问题，无法继续测试下去的情况，这时只能中断测试，返回给开发部进行修改,这样会浪费测试部门的时间和资源。

冒烟测试，只是一个测试活动，并不是一个测试阶段。

也就是说，冒烟测试贯穿于测试的任何一个阶段，单元测试里会有冒烟测试、集成测试里会有冒烟测试、系统测试里也会有冒烟测试。

2.基于每日构建的冒烟测试

在微软，冒烟测试就是在每日build建立后，对系统的基本功能进行简单的测试。

这种测试强调功能的覆盖率，而不对功能的正确性进行验证。

冒烟测试一般用于每日构建（Nightlybuild），构建服务器首先从VSS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试，这时，构建服务器会把程序打包成安装文件，然后上传到内部网站，第二天一早，测试人员来了以后，会收到构建服务器发来的邮件提示昨晚是否构建成功。

若构建成功，则测试人员进行相关的功能测试。

l基于每日构建的冒烟测试的优点主要有:

1.进度可见并可以控制到1-2天的细粒度，很容易看到进度的偏差；

2.及早的发现开发BUG和缺陷并分析解决，对开发人员的一种监督和促进，提高软件质量

3.由于将大集成分解到每日构建中的小集成，避免了传统产品集成或集成测试时候出现的严重问题的可能。

4.在项目中宣灌质量意识，强调第一次就把事情做好，而不是等测试来帮你发现问题。

l基于每日构建的冒烟测试也存在一些风险和缺陷，具体主要有：

1.给开发人员太大压力，开发每天都在较紧张环境中工作

2.需要额外的测试人力资源和每日构建硬件环境的投入

3.开发人员不能专注，既要分心去修改BUG，又要开发新的功能点

4.对开发负责人要求更好，需要将功能细化到1-2天的有明确输出的功能点

5.开发需要投入额外的精力来保证每日构建顺畅

l基于每日构建的冒烟测试适用场景

1.对进度偏差控制和要求很高的项目

2.开发检查点和里程碑制定的很细致的项目

3.采用增量和迭代开发的项目,快速和敏捷开发的项目

3.基于送测版本的冒烟测试

这个做法来源于微软的每日build和冒烟测试，只是把粒度放大了。

不是做每日build，而是根据版本计划，开发组定期发布送测版本，测试组拿到新的版本先做冒烟测试，测试通过则开始正式测试，不通过就返给开发组。

这种做法的优点可以避免微软的每日build和冒烟测试做法的一些缺陷，同时也会因粒度粗而有自身的缺点。

n冒烟测试的实现过程

a）测试规划阶段：

冒烟测试用例的编写，以及测试执行，都是需要时间成本的，故在最初制作项目计划时，就应该识别该任务，并充分考虑其工作量。

根据项目实际，确定在单元测试，集成测试，系统测试的哪个或哪几个阶段开展冒烟测试。

b）冒烟测试用例设计：

分析系统主要功能和业务流程，编写覆盖这些功能的正向测试用例。

如果没有用例就无法跟踪和掌握整个冒烟测试的重点，以及各个版本之间的冒烟对比。

冒烟测试用例应该随着系统的不断扩展而不断扩展，它不应该是一成不变的。

c）冒烟测试执行：

每个版本发布时，根据版本包含的功能特性，评估需要执行的冒烟测试用例。

d）冒烟测试结果输出：

冒烟测试执行情况，通过的测试用例数，不通过的测试用例数，据此判断是否开始正式的测试。

n冒烟测试用例应该包含的内容

a）业务流的测试，保证正常业务链路的通畅。

b）工作流的测试，主要是测试流程流转是否正常，至于流程步骤的表单内容是否正确则不关注。

c）关键功能的测试，至少要保证系统运转所需的启动数据，以及一些开关控制正常。

d）重要基本功能的测试，比如对核心业务有影响的一些增删改等。

n冒烟测试的入口准则：

a）软件版本已经发布；

b）冒烟测试计划和测试用例通过评审；

c）测试环境准备完毕；

n冒烟测试的出口准则：

a）发现的致命和严重类缺陷为0；

b）一般和建议类缺陷总数/冒烟场景总数<=2；

c）所有必选测试场景的通过率=100%；

d）随即抽取的可选测试场景通过率>80%；

4.冒烟测试自动化

冒烟测试可以手动执行，可以考虑自动化执行。

稳定的系统适合自动化冒烟测试，集成过程中的系统适合手工冒烟测试，因为冒烟测试内容在动态变化，变化中的自动化脚本维护工作量比较大。

自动化冒烟测试脚本应当遵循的原则

1、覆盖主要功能；

2、测试脚本要简单、易用；

3、测试脚本要独立；每个测试脚本要尽可能的独立，每个测试脚本覆盖的测试点要尽可能的单一。

5、要有对测试脚本的设计和说明文档，以便于维护。

6、测试结果收集：

留存每一次的测试结果，对比一段时间内的测试结果，可以知道产品那些功能点质量不稳定，如果同一个测试点在一段时间内经常不能够测试通过，那么这一部分的代码十分有必要进行review，有可能存在更大的隐患。

5.XX产品的冒烟测试举例

XX是一个简单、易用、高效、开放和面向服务的应用集成平台，它对外提供的功能主要体现在可以提供不同的接入和接出协议方式的服务调用。

所以，XX的冒烟测试主要是验证XX能够正确提供上述功能。

XX的冒烟测试用于验证XX多种接入接出协议下的服务调用功能是否正确。

每次拿到测试版本，先确定要执行的冒烟测试用例，然后执行冒烟测试，记录并分析测试结果：

如果冒烟测试通过，则开始后续正式的测试工作。

如果测试不通过，则提交对应的bug，同时该版本返给开发组；等到再有新版本或补丁的时候，再次开始冒烟测试。