冒烟测试

敏捷项目测试策略文档模板 　　在一个敏捷工作环境种，我们的研发工作以冲刺期和高度迭代的形式展开。每一个迭代周期都关注少数的需求或者用户故事，所以在文档在敏捷项目种的数量和内容方面都倾向于轻量化。 　　对于测试计划这样的文档也是如此，不过我们也确实需要为敏捷团队去提供一个概要的敏捷测试策略，以供指导。 　　敏捷测试策略文档是为了给团队提供一个最佳的测试实践和一些形式的测试体系。记住，敏捷并不意味着没有体系。 　　下面我们来看一个敏捷测试策略文档，看看我们都应该包含些什么内容。 1.　　 一份测试策略中通常都会对于更宽泛的商业目的和目标做出任务说明。 　　 一个典型的任务说明可以是： 　　“通过快速反馈和缺陷预防，持续的交付可工作的，满足用户需求的软件，而不仅仅是缺陷发现” 　　细化以后： 　　“● 在定义完需求的接收条件/测试之后，代码才能进行编写。 　　 ● 接收测试不通过，一个需求就不能被判断为完成。” 　　在敏捷项目中，通常还会包含关于质量保证的提示： 　　● 质量保证是系统和可靠的保证产品满足用户需求的一系列活动。 　　● 在SCRUM（敏捷）中，质量保证是所有人的责任，而不单单是测试人员。在我们开发新产品的过程中，我们通过质量保证活动来确保正确的质量。　 　 2.　　 测试级别 　　 2.1　　单元测试 　　WHY : 确保代码被正确开发 　　WHO : 开发工程师

　　在一个敏捷工作环境种，我们的研发工作以冲刺期和高度迭代的形式展开。每一个迭代周期都关注少数的需求或者用户故事，所以在文档在敏捷项目种的数量和内容方面都倾向于轻量化。 　　对于测试计划这样的文档也是如此，不过我们也确实需要为敏捷团队去提供一个概要的敏捷测试策略，以供指导。 　　敏捷测试策略文档是为了给团队提供一个最佳的测试实践和一些形式的测试体系。记住，敏捷并不意味着没有体系。 　　下面我们来看一个敏捷测试策略文档，看看我们都应该包含些什么内容。 1.　　 一份测试策略中通常都会对于更宽泛的商业目的和目标做出任务说明。 　　 一个典型的任务说明可以是： 　　“通过快速反馈和缺陷预防，持续的交付可工作的，满足用户需求的软件，而不仅仅是缺陷发现” 　　细化以后： 　　“● 在定义完需求的接收条件/测试之后，代码才能进行编写。 　　 ● 接收测试不通过，一个需求就不能被判断为完成。” 　　在敏捷项目中，通常还会包含关于质量保证的提示： 　　● 质量保证是系统和可靠的保证产品满足用户需求的一系列活动。 　　● 在SCRUM（敏捷）中，质量保证是所有人的责任，而不单单是测试人员。在我们开发新产品的过程中，我们通过质量保证活动来确保正确的质量。　 　 2.　　 测试级别 　　 2.1　　 单元测试 　　WHY : 确保代码被正确开发 　　WHO : 开发工程师/技术架构师 　　WHAT :

做好冒烟测试 在很多公司很多项目，都没有做冒烟测试，研发完成就直接转给测试。之前我经过一部分项目，都没有冒烟测试流程，结果在测试环节时常出现一些主流程阻塞等严重紧急问题，测试人员无法继续进行后续测试，项目整体处于阻塞状态。如果开发人员能在短时间内快速解决那还是好的，可是并不会这么如人意，甚至有些流程环节多次阻塞。 在后来一些项目中，我们开始尝试在项目流程中加入冒烟测试。一个普通的迭代冒烟测试不会太长，我没目前最长也就是半天，研发自我冒烟测试检测出问题，快速修改，当所有冒烟测试用例全部通过，就可以提交测试。 项目实践得出，一个良好的冒烟测试，会让提测功能质量更好，测试无阻塞更加高效，项目推进更顺畅。 冒烟测试的作用意义 帮助开发老师形成自测习惯，增加提测时的功能质量（有些项目是测试人员进行冒烟或者CI自动化进行） 减少流程阻塞，提测前解决部分明显的问题，保证主体流畅通畅不阻塞 整体流畅通畅，项目迭代推进更快速 冒烟测试作为衡量开发人员开发质量指标之一 冒烟测试用例如何写 冒烟测试用例其实就是测试人员编写的测试用例中level为0的用例，这些用例就是项目迭代的主流程。 千万不可将所有用例做为冒烟用例，这样做只会让开发认为开发人员把测试人员的工作做了，那还要测试人员干什么的错觉。 如何做 迭代初期制定好冒烟测试计划 测试老师编写好测试用例 从测试用例中选出冒烟用例

项目流程 这是一个大概的项目流程，可以适用于大部分项目，而每个项目都会有属于自己的一套流程标准，这里只是提供参考。 无论是项目成员，还是项目经理，我们都需要了解整个项目流程并知道每个流程应该做什么，以及这样做的目的和意义，这样才能在项目中的每个关键点和时间点都能保证项目进度和质量。 而在有些开发模式或者有些项目中，项目经理往往都会参与到所有的项目流程中。 一、需求 需求阶段往往都是由产品经理和需求方进行沟通对接，也有一些项目是项目经理在需求阶段就一起参与。无论什么样的协作方式，需求一定要梳理清楚。如果不梳理需求那么开放模式就可能需要考虑换一种了。 工作 需求收集与分析整理 需要输出 需求框架及部分需求文档 二、原型 原型基本由产品经理进行设计，这个阶段产品经理输出原型及PRD，这些都需要进行评审，这样能 工作 原型设计 原型评审 PRD PRD评审 需要输出 原型设计 原型PRD 各种必要文档补充 三、UI设计 当原型设计与PRD都评审通过，基本这个项目可以进入半开发状态，这个时候UI同学需要针对原型进行UI设计，UI设计完成也需要做UI评审。 工作 UI设计 UI设计评审 输出 UI设计 四、研发 大多数时候我们是在研发和UI设计同时进行，如果是瀑布式开发的就需要先完成UI设计，再进行研发。比较好的流程是对数据库设计进行评审，研发完进行冒烟测试等等

BVT测试介绍： BVT测试也称为"冒烟测试".版本验证测试 (BVT) 通常由一组广泛的测试组成，这些测试用于验证特定版本的总体质量。BVT 通常根据设定的计划自动运行，经常在夜间进行。也可以手动运行，例如自动运行失败后。如果 BVT 中的所有测试均已通过，则认为该版本成功。就是拿到一个软件，首先不急于完全测试，而是在很短的时候内把软件的基本功能走一遍，看有没有什么大的问题，如果存在大的问题，就没有必要再进一步测试了。可以节约时间，提高测试效率。冒烟测试，也有称作烟雾测试（smoke Test):一种用于验证系统基本功能的实现并达到一定程度的稳定性的测试。这种测试经常用作进入下一个等级的测试的入口准则的一部分。关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说冒烟测试就是在每日build建立后对系统的基本功能进行简单的测试， 这种测试强调功能的覆盖率，而不对功能的正确性进行验证 。从这一点看和所谓的“接受性（验收）测试（Acceptance Test）”非常相似。不同之处就在于他们执行的频率和被测的版本不同。 至于冒烟测试这个名称的来历，大概是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟在进行其它测试，否则就必须重新来过。类似的如果冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正

什么是软件？ 软件是计算机系统中与硬件相互依存的另一部分， 软件包括程序+文档 什么是软件测试？ （1）软件测试是在现有软件（程序+文档）中寻找缺陷的过程； （2）软件测试是指使用人工或者自动化手段来运行或测试某个系统的过程，目的是检验系统是否满足需求规格说明书中的要求 软件测试的目的？ 测试的目的是找出软件产品中的错误，使软件尽可能的符合用户的要求。 黑盒测试： 又叫功能测试，把程序看成一个黑盒子，完全不考虑程序的内部结构和处理过程，根据规格说明书，通过操作软件验证程序的功能是否与规格说明书规定的一致。 白盒测试： 也称结构性测试，是基于代码的测试，按照程序内部的逻辑结构，检测程序是否能按预定要求进行正确的工作。 回归测试： 回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 冒烟测试： 是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性，冒烟测试又称版本验证测试。冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件的基本功能正常，可以进行后续的正式测试工作。 简单地说，冒烟测试就是用较少的人，在较短的时间内测试程序的主要功能，如果通过再进行正式的测试。 aplha测试和bate测试的区别？ Alpha测试(α测试)： 通常也叫“验证测试”，主要是指在软件开发完成以后

BVT测试介绍： 　　BVT测试也称为"冒烟 测试 ".版本验证测试 （BVT） 通常由一组广泛的测试组成，这些测试用于验证特定版本的总体质量。BVT 通常根据设定的计划自动运行，经常在夜间进行。也可以手动运行，例如自动运行失败后。如果 BVT 中的所有测试均已通过，则认为该版本成功。就是拿到一个软件，首先不急于完全测试，而是在很短的时候内把软件的基本功能走一遍，看有没有什么大的问题，如果存在大的问题，就没有必要再进一步测试了。可以节约时间，提高测试效率。 冒烟测试 ，也有称作烟雾测试（smoke Test）：一种用于验证系统基本功能的实现并达到一定程度的稳定性的测试。这种测试经常用作进入下一个等级的测试的入口准则的一部分。关于冒烟测试，应该是 微软 首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说冒烟测试就是在每日build建立后对系统的基本功能进行简单的测试，这种测试强调功能的覆盖率，而不对功能的正确性进行验证。从这一点看和所谓的“接受性（验收）测试（Acceptance Test）”非常相似。不同之处就在于他们执行的频率和被测的版本不同。至于冒烟测试这个名称的来历，大概是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟在进行 其它 测试，否则就必须重新来过。类似的如果冒烟测试没有通过

简介 1.1 编写目的 本文档用于记录测试过程，总结各轮次的测试情况，分析测试数据，归纳测试工作进行过程中暴露的问题与遗留的风险，给出相应的测试建议以供后续项目参考。 1.2 项目背景 xx需要一个拥有真实用户的社区化产品，通过真实高信任度用户关系的建立，提高用户粘性，提升活跃会员数，带来长效的增长。在此背景下，以真实用户为基础的社区应运而生。主要具有以下5点意义： 提高社区活跃会员数 提高用户粘度 建立真实（和用户的社区身份相一致）的多维用户信息 建立高信任度的用户关系 达到真实可信用户关系中的用户之间的传播效应 1.3 定义、首字母缩写词和缩略语 无 1.4 参考资料 各轮系统测试阶段总结 测试概要 整个xx项目的测试经历了xx-1.0与xx-1.1两个阶段，共经历了1轮集成测试、6轮冒烟测试和7轮系统测试和1轮上线跟踪测试。整个测试过程中累计执行用例8100条，发现缺陷1026个。截至xx-1.1第四系统测试结束，所发现的高权重问题已得到修复和验证。 2.1 测试时间 整个xx项目的测试时间从xx年2月18日开始，到xx年3月27日上线止，期间各阶段工作情况如下： 2.2 测试范围 本次测试覆盖的范围包括：功能测试、兼容性测试、接口测试、数据迁移测试、性能测试、安全性测试和品质监控。以下分别对功能测试、兼容性测试、接口测试、数据迁移测试、性能测试和安全性测试进行说明。

（一）什么时候进行冒烟测试 测试是测试人员确认软件存在bug的过程，此过程中不可避免是需要开发人员要 不停的修改bug，那么常常会发现 一个功能的改动，导致下一轮系统测试出现问题 。 即发现也许以前修改的bug的确是解决了，可是 由于修改一个或多个bug导致其他 功能模块出现新的问题 ，测试跑不通了，只能测试终止。 那么我们如何确保开发人员修复了bug后，这个bug的修复没有影响到其他 功能模块呢？这时就需要进行冒烟测试啦。 （二）什么是冒烟测试 冒烟测试是自由测试的一种，由开发人员与测试人员共同进行。 在测试过程中发现问题，测试人员找到了一个Bug，然后开发人员会来 修复这个Bug，冒烟测试是否通过决定了下一轮系统测试是否可以执行。 使用一袋烟的功夫 快速对软件的主要功能进行测试 冒烟测试的重要性 不作用于本身而是 决定了下一轮测试是否能达到理想的效果 与 系统测试 不同之处在于冒烟测试是一种不 要求覆盖面有多广测试 ，但是要 保证 被测对象的主要部分功能要得到测试，不要求每一个功能都面面俱到 ， 但是要保证所有 被修改过以及与修改相关的功能、主要的功能都是可用的 ， 即证明这个版本可进行系统测试 (三)执行冒烟测试的前提 前面提到冒烟测试是与开发的合同协作，因此有几个合作前提： a) 初步了解代码中进行了什么更改。若要理解该更改，必须理解使用的技术 b)

1. 核心 冒烟测试就是完成一个新版本的开发后，对该版本最基本的功能进行测试，保证基本的功能和流程能走通。 　　如果不通过，则打回开发那边重新开发； 　　如果通过测试，才会进行下一步的测试(功能测试，集成测试，系统测试等等)。 简化：门槛测试，一个开关而不是一个阶段。 目的：版本验证测试BVT（Build Verification Testing）。 时间：开发转测试，历时半至一个小时，很短。 对象：需求覆盖，主功能路径。 优点：节省测试时间，防止build失败。 缺点：覆盖率还是比较低。 操作：对着需求文档把新功能过一遍；把所有流程功能走一遍；用monkey跑个一两个小时；如果有历史用例的话，可以把用例分级，冒烟级、详细级、回归级等等 用例：冒烟测试基本上不需要什么用例，如果有的话，就用详细用例里，覆盖需求文档级别的用例就可以了 冒烟测试 ，是 版本验证测试 ，主要 确认新的版本是否存在致命性bug ，冒烟测试最大的优点在于节约测试的时间成本，减少测试轮数。 回归测试 ，是软件 维护阶段 对软件修改后进行的测试，指修改了旧代码后，重新进行测试以确认修改没有引入 新的错误 或 导致其他代码产生错误 。 2. 定义 　　维基百科上对冒烟测试的解释: 　　 smoke testing is preliminary testing to reveal simple failures