冒烟、回归、系统

先熟悉下整个项目的流程，把大致的框架过一遍，不懂的地方记录下来，再问开发，把流程都掌握了，再对照已有的文档给予项目立项（测试计划、测试方案）

用例不必写的太过于详细（app模块变动较大，过于详细维护成本太高，而且项目经理给你的时间短，会浪费项目执行时间）

把每个功能模块罗列出来，大致的功能点，用什么方法去测试，都给标注，然后再根据测试需求执行测试

按功能模块测试（根据设计好的各个大类功能模块划分，然后再逐一细化，覆盖到每个功能）

按业务流程测试（把各模块串联起来形成完整的业务流程、同一业务使用每个路径检查）

数据流向、同一功能不同入口有效性检查测试、交互性检查

它的测试目标是：

1）确认系统测试的过程是按需求说明书进行的

2）确认新系统是否与需求说明书有不同之处或者存在缺陷。

3）对新系统在进行测试的过程中出现的不足或不符合要求的地方进行记录。

4）建立完善的系统测试缺陷记录跟踪库。

5）对测试过程中出现的问题进行修改，使之能达到令用户满足的程

系统测试包括：功能性测试、性能测试、负载测试、强度测试、容量测试、安全性测试、配置测试、故障恢复测试、安装测试、文档测试、用户界面测试等，其中，功能测试、性能测试、配置测试、安装测试在一般情况下是必需的

3）功能方面包括：·

业务功能的覆盖，关注需求规格定义的功能系统是否都已实现。

业务功能的分解，通过对系统进行黑盒分析，分解测试项及每个测试项的测试类型。·业务功能的组合，主要关注相关联的功能项的组合功能的实现情况。

业务功能的冲突，业务功能间存在的功能冲突情况，如共享资源访问等。

4）子系统方面包括：

·单个子系统的性能。

子系统间的相互影响，子系统的工作状态变化对其他子系统的影响。

所有的检测工作都要验证系统中的每个部分是否均已得到正确的集成，并能完成指定的功能。

用户方面包括：

·用户手册、使用帮助、支持客户的其他产品技术手册是否正确、是否易于理解。

·用户界面测试，在确保用户界面能够通过测试对象控件或入口得到相应访问的情况下，测试用户界面的风格是否满足用户要求，如界面是否美观、界面是否直观、操作是否友好、易操作性是否够好。

·可维护性测试，可维护性是指系统软、硬件实施和维护功能的方便性，目的是降低维护功能对系统正常运行带来的影响。

·安全性测试，安全性测试主要包括两个部分：测试数据的安全性和操作的安全性。也就是说，只有规定的数据才可以访问系统，其他不符合规定的数据不能访问系统；只有规定的操作权限才可以访问系统，其他不符合要求的操作权限不能访问系统。

2）系统应用的角度模拟实际应用环境，对系统的兼容性、可靠性、性能等进行的测试

系统测试的测试类型

1.功能测试功能测试只考虑各个功能，不需要考虑整个软件的内部结构及代码。一般从软件产品的界面、架构出发，按照需求编写出测试用例，从而测试一种产品的特性和可操作行为，以确定它是否满足要求。

2.性能测试性能测试（Performance Testing）是评价一个产品或组件与性能需求是否符合的测试

通过性能测试，可以确定在各种工作负载下系统的性能。

性能测试可分为三个方面：应用在客户端、网络上和服务器端的性能测试。其目的是测试当负载逐渐增加时，系统各项性能指标是否会变化

3.负载测试负载测试（Load Testing）通过测试系统在资源超负荷情况下的表现，发现设计上的错误或验证系统的负载能力

4.容量测试通过性能测试，如果找到了系统的极限或苛刻的环境中系统的性能表现，在一定程度上，就完成了负载测试和容量测

5.安全性测试安全性测试是在测试过程中检查系统对非法入侵的防范能力。6.用户界面测试用户界面测试是测试界面是否按界面是否简洁、美观。

7.配置测试配置事实上指的是软件生产过程中所需要的硬件、软件，以及开发过程中产生的各种各样的文档资料。配置测试就是从用户使用的角度出发，对它们进行全方位的测试，保证软件在网络操作系统下能够正常运行。

8.安装测试安装测试（Installing Testing）是为了测试应用软件安装在特定的操作系统下能否正常运行。安装测试考虑的内容主要有：磁盘空间、目录、权限等。测试的一般要求是：磁盘空间要求留有30%～35%的空间；目录要求建立完整、醒目、方便操作；权限要求分为系统管理员级、特殊用户级和一般用户级。同时还应考虑到系统发生故障死机后重新启动和安装的问题，需要对安装的代码以及安装的用户手册进行核

《系统测试方案》

系统设计的产品，指导执行的，是技术角度写的；

计划提示做什么，方案明确怎么做

核心：

测试策略选取、系统子项的细分

测试策略选取

策略：

单元测试策略、集成、系统策略

如何搭建测试环境：环境选取（部分、辅测环境、真实、仿真环境）、数据准备（谁、如何准备、存放哪）脚本开发（说明脚本语言、说明技术、开发注意什么、测试注意什么）、维护；
如何执行测试用例

（顺序、BUG处理流程、测试日报、报告编写）

顺序类型：

先执行功能用例-性能用例同时执行剩余用例；
用例优先级执行；

BUG处理流程：

直接提交还是先沟通
提交跟踪流程是怎么样的
缺陷报告包含内容

系统子项的细分

计划确认范围，大的测试点、需要细化测试点，测试需求和子项没有什么区别；查看3.2.1节

原则：

技术角度指导工作；方案可以很粗、或者细，关键看测试活动能力；不同项目不太测试方案，针对特定的项目进行分析，找匹配的方案；计划变化，方案也需要变化；

回归测试实训

《软件测试实用技术和常用模板》

无论是修改错误还是增加新的功能或是提高性能，原则上都要进行回归测试，以保证代码修改正确，且不会对其余部分造成负面影

测试用例：·能够测试软件的所有功能的代表性测试用例。·专门针对可能会被修改影响的软件功能的附加测试用例。·针对修改过的软件成分的测试用例。

它包括两个部分，一个是已经存在的测试用例，另一个是发现Bug后我们要针对这些Bug可能影响的地方进行编写的测试用例，这两个部分的测试预期结果也是已知的。

工作量很大，所以，回归测试尽量采用自动化测试。自动测试化以非常高效的方式进行，

回归测试的目的是：·确认软件经过变更或修改后是否仍满足所有的需求。·确认变更后会对软件的功能或性能产生怎样的影响。

回归测试的范围，具体表现为：1）测试所有修改或修正过的功能模块。2）测试与被修改的模块相关的模块。3）测试所有新增加的功能模块。4）测试整个系统。

人员

流程：

1）识别出软件中被修改的部分。

2）从测试用例库中排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库。

3）依据一定的策略从新的基线测

用例库中选择测试用例测试被修改的软件。

4）如有必要，生成新的测试用例集，用于测试新的基线测试用例库无法充分测试的软件部分。

5）用测试用例集执行修改后的软件。步骤2和步骤3验证修改是否破坏了现有功能，步骤4和步骤5验证修改工作本身；

执行用例：

1、注意以下两点：

1）各测试阶段发生的修改一定要在本测试阶段内完成回归测试，以免将错误遗留到下一回归测试阶段。

2）回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改、集回归。

2、重新进行回归测试时需要注意的问题有以下四点：

1）安排新的测试者完成回归测试。

2）分配更有经验的测试者开发新的回归测试用例。

3）在不影响测试目标的前提下，鼓励测试者创造性地执行回归测试用例（变化的输入、按键和配置有助于激励测试者揭示新的错误）。

4）在回归测试中，可以将回归测试与兼容性测试结合起来进行。

3、掌握回归测试的手段：

1）要熟悉系统的业务流程，对业务需求以及相关模块要非常清楚，保证回归测试的质量和效率。

2）及时更新和维护回归测试用例库当中的测试用例，确保执行的回归测试用例是最新的。

3）要掌握回归测试的测试用例优先级别，对优先级高的功能模块优先进行回归测试。

4）使用回归测试自动化工具进行测试。

5）回归测试人员应及时与开发人员进行有效的沟通，及时地反馈回归测试的情况。

6）回归测试人员应该熟悉并掌握系统开发使用的各种计算机语言。

用例库：

1、回归测试用例库的维护方法：

9.3.1 删除过时的测试用例实用的测试用例是经过长期的工作积累而成的，删除不是一味清除原有测试用例，而是对原有的测试用例进行加工改造，使之适应新的应用项目。

9.3.2 改进不受控的测试用例在测试用例库中，有的测试用例是可重复并且是可控制的，但是有的测试用例是不可控制的（有些对输入或运行状态十分敏感的测试用例是不容易重复而且是难以控制的，会影响回归测试的效率），进行改进，使其达到可重复和可控制的要求。

9.3.3 删除冗余的测试用例在回归测试中，所以需要定期地整理、维护测试用例库，将冗余的用例删除，并保存到回归测试用例库中，从而提高测试用例库的高效性和可用性。

9.3.4 增添新的测试用例随着应用的环境、功能、性能的不同。如果某个程序段、构件或关键的接口发生了变化，那么应该开发新测试用例重新对其进行测试；

2、介绍常用的回归测试方法

9.4.1 再测试全部用例将测试用例库的全部测试用例组成回归测试包进行测试，这是一种比较安全的方法。再测试全部用例具有最低的遗漏回归错误风险，但测试时间、人员、设备和经费成本最高。全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是随着开发工作的推进，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往会超过预算并影响进度。

9.4.2 基于风险进行测试从测试用例库中选择测试用例进行回归测试，这种方法有一定的风险。选择测试用例时，首先要选择运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例。

9.4.3 基于操作进行测试如果测试用例库的测试用例是基于软件操作开发的，回归测试时可以优先选择基于操作的测试用例，针对最重要或最频繁使用的功能进行测试，这种方法可以在给定预算的情况下有效地提高系统的可靠性，但实施起来有一定的难度。

9.4.4 仅测试修改部分当测试者对修改的局部化有足够的信心时，可以仅测试修改部分，但要分析修改情况和修改的影响，使回归测试尽可能覆盖受到影响的部分，但这种方法实施起来有一定的风险。在回归测试时采用多种测试技术是常见的，

表现在以下两个方面：

1）测试者对一个修改的软件进行回归测试时，回归测试者可以采用多种回归测试方法，如采用回归测试工具，进而增加对修改软件的信心。

2）不同的回归测试者可能会根据自己的经验和判断选择不同的回归测试技术和方法。

回归测试的参考依据：

1）如果特定测试用例的执行结果对于以前的版本通过，而对于当前版本未通过，则回归未通过。需要提交新版本，并对测试用例重新设置后重新测试。

2）如果特定测试用例的执行结果对于以前的版本未通过，而对于当前的版本通过，则可以确定缺陷修改有效。

3）如果特定测试用例的执行结果对于以前的版本未通过，而对于当前版本也未通过，且对于这个特定的测试用例没有针对缺陷修改，则可能意味着这个测试用例的执行结果未通过，而且在回归测试中不应该选择这类测试用例。

4）如果特定测试用例的执行结果对于以前的版本未通过，但是通过某种写入文档的迂回方法可以通过，而且测试人员也对这种迂回方法感到满意，则可以

对于系统测试周期和回归测试周期都通过。如果测试人员对迂回方法不满意，则可以认为系统测试周期未通过，但是回归测试周期是通过的。

《冒烟测试规范》

腾讯移动品质中心

目标：版本的快速发布和多版本并行的测试。

如何利用它减少测试的压力还可以提高测试质量。

破解法1：每个版本指定一名开发打包，在冒烟开始半小时前就开始进入打包流程

破解法2：每个版本轮流换人组织冒烟，打包的人也是轮流的，大家就会互相体谅不同角色的难处

破解法3：使用模板在电脑上录bug，一键导入tapd, 并且谁提的bug谁负责回归

然后测试同学就爽歪歪了！

冒烟的好处

a) 体验问题：版本dogfood和showcase时间太晚，冒烟可以早期暴露大量体验类问题
b) 机型问题 : 冒烟参与的人多，可以快速覆盖更多的机型和android版本
c) 问题暴露：在还未正式提测前就开始冒烟，可以快速暴露问题和解决
d) 人多力量大：各个角色一同参与冒烟，可以从不同的维度发现问题，经常都能给出一些很有效的优化建议

无法解决所有问题，也存在一些不可避免的缺点，例如：提bug的有效性，重复bug录入，开发解决大量bug带来的耗时等。

一些冒烟数据和改进过程，大家可以参考下：

1、BUG有效性：

有效性： 64% 命中率
建议：宁可错过，不可放过

2、重复BUG：

说明：下图是被拒绝的冒烟bug的分布，重复的bug占比比较高
参考：越多人提的bug，越重要？在思考bug有效性的时候，重复bug可以作为一个参考，越多人提的bug是否需要更加关注。

3、冒烟BUG分布

影响因素：

1. 功能改动
2. 冒烟指导力度（大家可以依据自己的重点功能加强对应的冒烟路径指导力度）

4、我们的优化之路

在FT的实践过程中，各个角色提出自己的意见，对冒烟测试的组织优化起到了关键性的作用。

冒烟基础实践篇

测试准备：

设备：一台录入bug的笔记本（附件有bug录入模板）

冒烟时间：每天下午5:30 到 6:00，规定半小时以内

开发童鞋：

1. 轮流：每个版本指定一名开发童鞋
2. 打包： 5:30之前打好冒烟的包，发到冒烟的RTX群让大家安装
3.收集：收集当天的冒烟路径（由各个功能的开发和测试提供）
4. 拉人： 5:30准时拉人去冒烟
5. 推荐：跟大家推荐今天重点体验的功能和路径（一般对应的开发会主动引导）

测试童鞋：

1. 问题收集 : 负责收集各个同学提供的bug，并使用模板批量导入到tapd（必须当天导入）
2. 问题回归：每天会打印需要回归的bug，在冒烟的时候让对应的同学回归
3. bug优先级控制：根据提的冒烟bug，可以协助开发标明优先级或者类型
4. Bug回归推动：需要关注bug的解决情况，在需要的时候推动bug的解决和回归
5. 推荐：测试也需要引导测试的路径，可以从测试的一些角度提出

产品童鞋：

1. 每天的showcase：在冒烟过程中，大家会有很多体验或者需求的问题，产品会在场帮忙大家解答或者收集大家的反馈，有效的反馈都会录入到tapd

如何录入问题

1、标题格式说明：【版本+模块名+冒烟测试】【BUG/体验】xxxx--提bug人
2、录入TAPD:(录入模板参考附件，录入方式见下

实践小技巧：

今天我当家：开发轮流负责, 提高主动性和加强对测试的理解
今日事，今日毕：当天录入bug, 快速录入让开发快速解决
一秒转产品：体验类的问题快速转产品处理，产品再消化为产品问题，确定是否进行需求变更

- 宁可错过，不可放过：无论问题大小，是体验类还是bug类，都让大家进行录入

快速回归bug：快速回归不遗留，遗留打屁股
追求大而全：收集下大家的机型和android版本，可以适当的补充遗漏的机型和android版本手机
吃货诱惑：FT内可以偶尔准备一些小零食，在冒烟的时候提供，让日复一日的冒烟有一些小惊喜

没有达到敏捷的条件，确实可能需要整体交付一个版本后统一测试、再修复、在测试

提前介入测试流程

开发做完一个需求，需求的状态改为：编码结束，已送内评
测试组对编码结束，已送内评的需求提前介入测试，每天花少量时间（暂定 1 小时）进行验收冒烟测试，提交发现的阻塞性、未实现的 bug。并提醒开发修复。其他严重的、普通的缺陷只记录 Redmine，正式提测后开发再修复
冒烟测试通过后，需求状态改为：内评通过，已送测试

目标

正式提测前，阻塞性、未实现的 bug，全部修复