冒烟测试方案V1.0（完整版）

1、 冒烟测试方案 V1.0 目录1.引言 . 31.1测试目的 . 32.测试范围 . 3测试内容 . 33.测试策略 . 3测试方法 . 34.测试实施 . 42.13.14.14.24.34.4测试实现过程 . 4测试要点 . 5测试准入准出 . 5冒烟测试自动化 . 5 1.引言1.1 测试目的冒烟测试（ Smoke Testing）可以说是一种预测试，软件代码正式编译并交付测试之前，先尽量消除其“表面的”错误，确保软件基本功能符合需求规格说明书要求，发的负担。减少后期测试开2.测试范围2.1 测试内容在实际的软件测试工作中，分为三类：SmokeTesting在软件研发的不同阶段有所不同。

2、大体可以1.形成集成测试版本以前 Smoke Testing是随着代码的不断开发必做的一项工作，目的是验证各个单元能够成功执行，并保证测试版本能够顺利集成。2.形成集成测试版本以后在代码 check in到 daily build之前执行 Smoke Testing，以保证新的或者更改过的代码不破坏集成版本的完成性和稳定性。3.后期预测试 Bug的修正后期 daily build相对稳定时，针对每个Bug所做的 Bug Fix都要先在“干净的 build中进行 Smoke Testing，测试通过的 Bug Fix才能check in到新的 daily build中。3.测试策略3.1 测试方

3、法1.基于每日构建的冒烟测试冒烟测试就是在每日build建立后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。冒烟测试一般用于每日构建(Nightly build)，构建服务器首先从VSS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试。 基于每日构建的冒烟测试的优点主要有：a)进度可见并可以控制到1-2天的细粒度，很容易看到进度的偏差；b)及早的发现开发 BUG和缺陷并分析解决，对开发人员的一种监督和促进，提高软件质量c)由于将大集成分解到每日构建中的小集成

4、，现的严重问题的可能。避免了传统产品集成或集成测试时候出d)在项目中宣灌质量意识，强调第一次就把事情做好，而不是等测试来帮你发现问题基于每日构建的冒烟测试也存在一些风险和缺陷，具体主要有：a)给开发人员太大压力，开发每天都在较紧张环境中工作b)需要额外的测试人力资源和每日构建硬件环境的投入c)开发人员不能专注，既要分心去修改BUG，又要开发新的功能点1-2天的有明确输出的功能点d)对开发负责人要求更好，需要将功能细化到e)发需要投入额外的精力来保证每日构建顺畅基于每日构建的冒烟测试适用场景a)对进度偏差控制和要求很高的项目b)开发检查点和里程碑制定的很细致的项目c)采用增量和迭代开发的项目,快

5、速和敏捷开发的项目2.基于送测版本的冒烟测试此种方法来源于每日构建和冒烟测试，只是把粒度放大了。不是做每日本计划，开发组定期发布送测版本，测试组拿到新的版本先做冒烟测试，式测试，不通过就返给开发组。build，而是根据版测试通过则开始正这种做法的优点可以避免微软的每日而有自身的缺点，在此就不做详述。build和冒烟测试做法的一些缺陷，同时也会因粒度粗4.测试实施4.1 测试实现过程1.测试规划阶段：冒烟测试用例的编写，以及测试执行，都是需要时间成本的，故在最初制作项目计划时，就应该识别该任务，并充分考虑其工作量。根据项目实际，确定在单元测试，集成测试，系统测试的哪个或哪几个阶段开展冒烟测试，明

6、确准入准出标准。2.冒烟测试用例设计：分析系统主要功能和业务流程，编写覆盖这些功能的正向测试用例，推荐使用正交表，运用正交法制定一套测试用例。冒烟测试的重点，以及各个版本之间的冒烟对比。展而不断扩展，它不应该是一成不变的。如果没有用例就无法跟踪和掌握整个冒烟测试用例应该随着系统的不断扩3.4.冒烟测试执行：每个版本发布时，根据版本包含的功能特性，用例评估需要执行的冒烟测试冒烟测试结果输出：冒烟测试执行情况，通过的测试用例数，不通过的测试用例数，据此判断是否开始正式的测试。 4.2 测试要点1.2.3.4.业务流的测试，保证正常业务链路的通畅工作流的测试，主要是测试流程流转是否正常，至于流程步骤

7、的内容是否正确则不关注。关键功能的测试，至少要保证系统运转，以及一些正常功能实现。重要基本功能的测试，比如对核心业务有影响的一些增删改等4.3 测试准入准出冒烟测试的入口准则a)软件版本已经发布b)冒烟测试计划和测试变更需求和用例通过评审c)测试环境准备完毕冒烟测试的出口准则a)发现的致命和严重类缺陷为b)所有必选测试场景的通过率0=100%c)随即抽取的可选测试场景通过率80%4.4 冒烟测试自动化冒烟测试可以手动执行，可以考虑自动化执行。稳定的系统适合自动化冒烟测试，集成过程中的系统适合手工冒烟测试，因为冒烟测试内容在动态变化，变化中的自动化脚本维护工作量比较大。自动化冒烟测试脚本应当遵循的原则1.2.3.4.5.6.覆盖主要功能；测试脚本要简单、易用和详细说明测试脚本要独立每个测试脚本要尽可能的独立每个测试脚本覆盖的测试