测试架构师修炼之道--读书笔记

第一部分 瓶颈：软件测试工程师该如何进行职业规划

第1章 软件测试工程师的“三年之痒”

1.1 软件测试发展简史：调试--证实--证伪--预防--模型--全周期；

1.2 中国的软件测试行业：起点高；困境和迷局（不了解、不理解、外包）；迷茫（门槛低、深入难）

1.3 认识软件测试的优势和劣势：优势是入门容易、理解产品、理解用户、多面手；劣势是认可度低、发展受限；

第2章 软件测试工程师的职业规划

2.1 软件测试的职业发展方向：管理（初级管理者、中级管理者、高级管理者）；技术（产品测试专家、专项测试工程师）；角色和段位；质量领域发展（产品流程设计、企业质量管理者、客户满意度管理专家）；

2.2 软件测试工程师的职业规划建议：技术或管理；跳槽的建议；软件测试创业；

第二部分 突破：向 软件测试架构师的目标迈进

软件测试是一门结合产品领域、管理、心理学和经济学等综合性的技艺。软件架构师的精髓在于找到最适合的软件测试技术，且不断的持续改进。

第3章 软件测试架构师应该和不应该做的事情

3.1 软件测试架构师需要关注和不关注的事情

需求分析：理解商业目标；梳理用户场景；输出总体策略（详见7.1-7.3）；

测试分析和设计：制定阶段策略（详见7.4）；落实策略，保证质量；

测试执行：执行版本策略（详见8.1-8.2，8.4）；跟踪执行（详见8.3）；质量评估（详见6.3，8.4）；

质量评估：阶段/发布质量评估（详见8.6）；

3.2 像软件测试架构师一样的思考：目标、范围、深度广度、重点难点、如何测试、如何评估；

3.3 软件测试经理可以替代软件测试架构师吗：合作互补；

3.4 系统架构师可以替代软件测试架构师吗：协作配合；

第4章 软件测试架构师的知识能力模型

测试技术（软件产品质量模型、测试类型、测试方法、测试设计、探索式测试、自动化测试）+产品知识、沟通协调、书面表达

4.1 软件产品质量模型：六类属性（功能性、可靠性、易用性、效率、可维护性和可移植性）；

功能性：软件产品在指定条件下使用时，提供满足 明确和 隐含要求的功能的能力；5个子属性（适合性、准确性、互操作性、安全性、功能顺从性）；

可靠性：特定条件下使用时，软件产品维持规定的性能级别的能力；4个子属性（成熟性、容错性、可恢复性、可靠性顺从性）；

易用性：产品被用户理解、学习、使用和吸引用户的能力；5个子属性（易理解性、易学性、易操作性、吸引性、依从性）

效率：相对于所用的资源数量，软件产品可提供适当的性能的能力，也就是我们常说的产品性能；3个子属性（时间特性、资源利用率、效率依从性）；

可维护性：软件产品可被修改的能力；5个子属性（可分析性、可修改性、稳定性、可测试性、依从性）；

可移植性：软件产品从一种环境迁移到另外一种环境的能力，环境可以指硬件、软件或组织等；5个子属性（适应性、可安装性、共存性、易替换性、依从性）；

4.2 测试类型：测试需要考虑的不同角度（功能测试、安全性测试、兼容性测试、配置测试、可靠性测试、易用性测试、性能测试、安装测试等）；

4.3 测试方法

1、产品测试 车轮图：一个软件测试者要从哪些方面（测试类型）用哪些方法（测试方法）去测试产品（质量属性）的关系图；产品测试两个关键问题，分别是全面性和深度；

2、 功能测试方法：运行是指软件测试中，测试人员模拟用户的“操作”或“行为”；

单运行正常值输入法：系统允许的“正常值”的测试方法；

单运行边界值输入法：测试系统的“边界值”的测试方法；

多运行顺序执行法：按照一定顺序来进行多个运行操作的测试方法；

多运行相互作用法：多个存在相互关系的运行组合在一起进行测试；

3、 可靠性测试方法

异常值输入法：测试系统容错性，基本可靠性测试方法（系统正常，输入异常）；

故障植入法：把系统放在有问题环境中进行测试的一种可靠性测试方法（系统异常-故障模拟，正常输入）；

稳定性测试法：长时间、大容量运行某种业务，测试系统的成熟性；性能测试是测试真实规格是否与承诺规格一致，稳定性测试是低于性能值前提下测试，压力测试是在高于性能值的前提下测试；四字要诀，多（数量）、并（并发）、复（反复）、异（异常）；

压力测试法：超过系统规格的负载进行测试的一种可靠性测试方法；突发负载模型（希望系统正常）、持续负载模型（系统可能打死）；

恢复测试法：使用超过规格的负载测试、再将负载降到规格以内的测试方法；普通版（高-低）、加强版（高-低-高-低...）；测试系统的可恢复性；

4、 性能测试方法：真实规格与承诺规格是否一致；除确认规格之外，还希望发现系统的瓶颈；

测试出系统最好的性能值：正确处理新业务的最大能力；同时正确处理的最大业务能力；

分析会影响性能值的各种因素，测试他们对性能的影响：影响因素、影响趋势、最坏值；

以场景为单位来测试性能：评估产品在用户使用环境中的性能表现，更有实际意义；

5、 易用性测试法：用户理解、使用产品时对产品的能力；

一致性测试法：测试对象是用户界面，测试风格、布局、元素、提示等；目的是证实；

可用性测试法：测试对象是用户界面，是否易于理解、使用，需要与功能测试结合，以场景作为测试粒度，以用户视角进行测试；推荐交叉测试法；

4.4 测试设计技术

1、测试点 不等于测试用例

测试用例是一份真正能够指导测试的测试说明书；

2、 四步测试设计法

测试分析是发现性过程，测试设计是创造性过程；

第一步： 建模；

类型1：流程类，绘制“流程图”来建立测试模型；

类型2：参数类，绘制“输入输出表”来建立测试模型；

类型3：数据类，绘制“等价类分析表”来建立测试模型；

类型4：组合类，绘制“因子表”来建立测试模型；

第二步： 设计基础测试用例；

基础测试用例只确定了测试条件；

第三步： 补充测试数据；

为基础测试用例确定测试输入，补充测试数据；

第四步： 扩展；

根据经验，补充用例，增加有效性；

3、对测试点进行 分类

流程类特征：输入的不同进行不同的处理；

参数类特征：参数值是有限的，系统会对不同的参数值作出不同的处理或响应；

数据类特征：数据取值是一个范围，系统对允许输入数据作出的处理或响应往往是一样的；

组合类特征：流程、参数、数据的组合；

4、 流程类测试设计：路径分析法；

绘制流程图-使用路径分析法（语句覆盖、分支覆盖、全覆盖、最小线性无关覆盖（有两条出边是必要条件，为判定数+1））得到测试条件-使用等价类或边界值等技术确定测试条件-其它需要考虑的；

5、 参数类测试设计：输入输出分析法

使用“输入-输出表”-100%覆盖“输入输出表”-其它需要考虑的；

6、 数据类测试设计：等价类和边界值分析法

使用“等价类分析表”-使用“边界值”来为“等价类分析表”确定测试数据-其它需要考虑的；

7、 组合类测试设计：正交分析法

使用“因子表”-使用“正交分析法”来生成测试用例-其它需要考虑的

8、 控制用例粒度：测试点的 组合和拆分

控制用例粒度，是测试设计中非常重要的一项工作。

第一：我们希望整个团队测试用例的总数维持在一个比较合理的范围内，同时达到测试验证产品的效果，需要我们控制测试用例的 源头（测试点），不要过粗或者过细。

第二：不同的用例粒度，可能会发现产品 不同层次的问题（细粒度用例可能更容易发现功能设计和实现方面问题，粗粒度用例可能更容易从系统角度去发现问题），所以我们不同的测试阶段，对测试点进行拆分和组合，不同层次去测试产品，发现问题。

还有一种控制测试用例粒度的方法，就是 策略覆盖，执行的过程中需要考虑内容的重要性和测试执行的便利性。

9、 错误推断法

错误推断法是一种基于 经验的测试设计方法。用到四步测试设计中第四步，作为经验 补充的测试用例，是一个比较推荐的方法。错误推断法中的经验，主要源于对产品缺陷的 分析。定期组织分析活动，分享经验，拓展思路。

4.5 探索式测试

探索式测试非常注重测试思维。

1、探索式测试的 基本思想：CPIE模型；收集C-划分优先级P-分析调研I-实验E；与传统测试相比，探索式测试弱化了流程，强调实践，边学边测，持续改进；优势是快速测试，高效发现产品缺陷，缺点是容易将焦点集中在缺陷发现而偏离对需求的验证，对基本测试覆盖不足，测试点不易复用，不易积累；

2、 选择合适的探索式测试方法：第一步，对产品的特性进行 分区；第二步，根据不同分区选择适合的探索式测试方法；

历史区测试法：老代码，包含修复已知缺陷的代码，多一些时间测试曾经有很多缺陷的代码是特别重要的；包含恶邻测试法（缺陷横行的代码段）、博物馆测试法（老的可执行文件和遗留代码）、上一版本测试法（运行先前版本支持的所有场景和测试用例）；

商业区测试法：销售特性，产品的重要功能和特性，测试的重点测试对象；包含指南针测试法（手册、场景及产品需求）、卖点测试法（吸引用户的特征）、地标测试法（寻找测试点，明确测试项）、极限测试法（向软件提出很多难以回答的问题）、快递测试法（专注于数据）、深夜测试法（不操作时，查看自处理情况）、遍历测试法（最短路径访问对象）；

娱乐区测试法：针对辅助特性，不那么重要的特性；

配角测试法（特定特征，紧邻主要功能）、深巷测试法（最不吸引人的特性，或最流行、最不流行混着测）、通宵测试法（长时间运行）

破旧区测试法：问题高发特性，测试思想就是继续“落井下石”；

破坏测试法（缺陷横行的代码段）、反叛测试法（输入最不可能的数据）、强迫症测试法（强迫一遍又一遍接受同样的数据）；

旅馆区测试法：平台或维护特性，被忽视或者少描述的次要及辅助功能；

取消测试法（启动相关操作，然后停止，查看处理反应）、懒汉测试法（自行处理空字段及默认值）；

旅游区测试法：针对的是噱头特性，关注如何快速访问文件的各个功能，目的是到此一游；

收藏家测试法（通过测试收集软件的输出，将那些可以到达的地方都到达一遍）、长路径测试法（访问离应用程序某个开始点尽可能远的特性）、超模测试法（关心表面的东西，只测试界面）、测一送一测试法（同时处理多个功能时，能否正常）

其他区测试法：无法归类的区域，如产品的可测试性、可维护性等；

内部测试法（需要进行某项功能测试之前完成，收集那些部分对确认测试结果、定位问题有用的内部输出）、变动区测试法（分析当前版本与之前版本内容的变化，针对变化内容进行测试）

3、 开展探索式测试：

3.1、确定探索式测试任务：确认任务范围，三种思路（全局场景探索、特性漫游探索、局部功能点探索）；确定范围后，确定测试方法；

3.2、设计探索地图并执行探索式测试：根据被测对象特点，使用测试方法分析得到测试点，然后执行测试，并记录结果；使用探索式测试是能够直接用测试点来进行产品测试的，也是其速度快、效果高的优势所在；测试过程中可以灵活实时调整测试策略；

3.3、探索式测试总结：哪些方法可以更有效发现产品问题；本次探索测试中的教训；

4.6 自动化测试

用好已有的自动化、根据产品测试需求向自动化团队提出合适的自动化需求；

1、需要知道的一些自动化测试真相

自动化并不廉价，相反，自动化很贵（时间人力技术成本）；自动化脚本往往没有想象中那么可靠（意外发现的缺陷，自动化可能都不会发现；自动化本身可能不可靠）；自动化测试不是单靠自测就能搞定的事情（需求要确定清楚，UI或命令行也需要尽早确定，测试用例也要尽快写出来）；

2、如何评估自动化的收益

自动化测试的实施成本（前期开发成本+后期维护成本）；自动化测试的运行次数（优先选择真正需要多次执行的测试用例）；自动化测试实施成本比；

3、自动化测试工具介绍

单元测试工具、UI测试工具、性能测试工具；

第5章 软件测试架构师的软能力修炼

除了硬能力之外，也需要一些软能力。

5.1 沟通和协商

产品测试中的沟通原则：1、尽早沟通（帮助我们预防分歧）；2、既要对事，也要对人（对人强调的是理解沟通对象，换位思考）；

通过沟通来获得对产品测试有用的信息：1、以测试的视角来读需求、设计文档，来准备沟通的问题（测试的视角，是否可测？怎么测试？怎样才算验证通过？）；2、以需求工程师或开发的视角来问问题（沟通是相互启发的过程）；3、总结、跟踪和确认；

和测试团队成员沟通：主动进行反复的沟通（简介-讲解-举例-总结）；和领导或投资决策者沟通（更关心：产品测试结果和产品的质量评估结论；重要BUG；重要风险；进度）；

5.2 写出漂亮的测试用例

测试用例 模板：测试用例编号、用例标题、预置条件、测试数据、测试步骤、预期结果；合理控制用例的粒度；

测试用例标题要是一个 完整的句子：状语，主语，谓语，宾语，补语（可选）；

用 条件而不是参数来描述测试用例标题：参数更适合在测试用例模板中的测试数据部分体现；

如果一个用例中包含 多个参数，用例中应该是每个参数的取值；

不要在测试用例中 引用别的测试 用例；

避免测试用例中 包含过多的 用户接口细节：用例执行者是专业人士，用例不必写的面面俱到；

明确测试步骤和预期结果的 对应关系：增加简单的标记（如check[]）来明确对应关系；

避免在测试步骤中使用 笼统的词：避免反复、长时间、大量等描述，应该明确；

第三部分 修炼：软件测试架构师的核心技能

第6章 如何才能制定好测试策略

制定测试策略是软件测试架构师最核心的技能。

6.1 理解测试策略

1、什么是测试策略？通俗说，就是测啥咋测；具体说，有测试对象范围、测试目标、测试重点难点、测试深度广度、如何安排测试、如何评价测试；

2、测试策略等于测试方针？测试方针是产品测试中的通用要求、原则或底线；遵循的测试方针+项目实际情况=测试策略；

3、测试策略等于测试计划？测试计划属于测试管理的范畴，测试策略属于测试技术的范畴；

4、测试策略等于测试方案？测试方案主要解决的是特性在测试设计和测试执行方面的问题；测试方案需要遵循测试策略；

6.2 四步测试策略制定法

1、明确产品 质量目标：我们的测试目标就是让产品在发布的时候能够满足事先约定的质量目标（详见6.3节）；围绕产品质量目标进行刚刚好的测试；将目标-行为-评估形成闭环（详见第8章）；

2、进行 风险分析：提前识别项目中可能存在阻塞测试的风险，然后基于风险调整测试策略；基于风险来加强和降低测试投入；

3、 适配产品 开发流程：测试策略的结构；根据研发流程来安排测试活动；

4、进行 测试分层：通过测试分层，能够将大的目标分到不同层次中阶段完成，合理的测试分层，能够让测试目标SMART化；

5、 四步测试策略制定法中的测试技术；

6.3 产品质量评估模型

产品质量评估模型将用在测试目标的确定和评估上，它是整个测试策略的基础。

优秀的产品质量过程评估模型的特征：多维度（覆盖各个维度，全面分析和考虑）；定量和定性（指标和分析结合）；过程+结果（还需分析评估）；

软件产品质量评估模型：测试覆盖度分析（需求覆盖度评估、路径覆盖度分析）；测试过程分析（测试用例分析、测试方法分析、测试投入分析）；缺陷分析（缺陷密度分析、缺陷修复情况分析、缺陷趋势分析、缺陷年龄分析、缺陷触发因素分析）；

6.4 测试覆盖度评估

需求覆盖度评估：“已经测试验证的产品需求数”与“产品需求规格总数”的比值；两种方法：1、直接在需求表中确认测试情况；2、建立测试用例和需求的对应关系（注意需求变化的部分，设计遗漏可能会影响需求覆盖评估；本方法最好有工具支持）；

路径覆盖度分析：“已经测试到的语句的数量”与“程序中可执行语句的数量”的比值；三步分析法，1、确定路径覆盖策略；2、使用路径分析法设计测试用例；3、跟踪测试用例执行情况；

6.5 测试过程评估

分析的对象是测试用例、测试方法和测试投入；

测试 用例评估：测试用例执行率；测试用例执行通过率（首次执行通过率、累积执行通过率）；测试用例和非测试用例发现缺陷比；

测试 方法分析：只按照测试策略来确定要使用的测试方法--分析测试设计是否和测试策略中的测试方法符合--分析测试执行时的测试方法是否符合测试策略--通过缺陷分析来确定测试策略是否需要调整；

测试 投入分析；

6.6 缺陷分析

缺陷 密度：每千行代码发现的缺陷数；缺陷密度可以预测产品中有多少缺陷，帮助我们评估当前以及发现的缺陷总数是否足够多；

缺陷 修复率：指产品“已经修复的缺陷总数”与“已经发现的缺陷总数”的比值；缺陷修复率能够帮助我们确定当前产品发现的缺陷是否被有效修复，为当前的产品质量是否达到测试质量目标提供最直接的判断依据；为保证重要缺陷优先修复，我们按照不同的缺陷严重程度确定缺陷修复；

缺陷 趋势分析：指随着时间的进行，测试发现的缺陷趋势和开发解决缺陷的趋势；能够帮助我们判断当前系统是否还能容易地发现缺陷，进而帮我们确定是否可以退出测试；1、绘制缺陷趋势图（累积发现的缺陷数、新发现的缺陷数、累积解决的缺陷数、当前解决的缺陷数）；2、缺陷趋势曲线的“凹凸性”和“拐点”（理想的趋势曲线；趋势曲线拐点出现的过早；趋势曲线拐点未出现）；3、缺陷是否收敛（两个条件：趋势曲线变为凸函数；累积发现和累积解决两曲线越来越靠近）；缺陷年龄分析：软件产生或引入缺陷的时间(继承或遗留、需求阶段、设计阶段、编码引入、新需求或变更引入、缺陷修复引入)；三步走展开年龄分析活动；第一步：确定缺陷的缺陷年龄；第二步：统计各类缺陷年龄的数量，绘制分体图；第三步：进行缺陷年龄分析（理想的年龄分析图；没有在特定的测试层次发现该层的缺陷；继承或历史遗留引入缺陷过多；新需求或变更引入的缺陷过多；缺陷修改引入缺陷过多）；

缺陷触发因素分析：对测试中使用的测试方法进行分析；三步走：确定缺陷的测试方法和测试类型；统计出各种测试方法发现的缺陷数目，绘制缺陷触发因素分析图（有些方法没有发现缺陷或者发现的少；有些方法发现的特别多；）；

组合使用各种缺陷分析技术：进行缺陷分析，并不满足只对产品质量的某一个方面进行评估，需要我们组合使用这些缺陷分析技术；

6.7 风险分析技术

涉及的技术主要有风险识别，风险评估，风险应对和老功能分析；

1、风险 分析：风险分析的对象是测试策略；
风险识别：三步走；第一步，分析该项测试活动需要关注哪些内容；第二步，分析上述内容都能够进行保质保量顺利进行的条件；第三步，逐一分析这些条件是否能够满足；

风险评估：确定风险的优先级；风险优先级正交表、需求类风险、设计类风险、流程类风险、历史类风险；

2、风险 应对：回避风险、转移风险、减轻风险、接受风险；

3、 老功能分析：差异性分析（老功能在新版本和老版本上的差异，找差异是新版本中做好老功能测试的金钥匙）；历史测试情况分析（确认老功能在新版本和老版本中的质量要求是否一致；进行测试方法分析；进行缺陷分析；对组织和人进行分析）；

6.8 分层测试技术

V模型：单元测试、集成测试、系统测试、验收测试；

设计测试分层：1、某通信公司测试分层；单元测试、MST（模块级）-BBIT（单元/模块接口）测试、SDV（系统设计）-SIT（系统集成）-SVT（吸引验证）测试、验收测试；2、某公司敏捷测试分层；单元测试、功能测试、非功能测试、探索测试；

第7章 测试策略实战攻略

测试策略实战，运用第6章思路和方法；

7.1 开始

收集了解项目信息：项目范围、人力投入、历史情况、产品背景、用户市场等；

7.2 初次使用“四步测试策略制定法”

1、产品质量等级（第1级完全商用；第2级受限商用；第3级测试；第4级不能使用）；

2、确定项目中各个特性的质量等级（逐一确定项目包含特性的产品质量等级）；

3、对项目整体进行风险分析（项目整体角度进行分析）；

4、确定测试策略的结构（总体策略、阶段策略、执行策略）；

5、初步确定测试分层；

6、回顾（四步走；质量分析；风险分析；总体、阶段、执行策略；单元、集成、系统、验收）；

7.3 制定总体测试策略

1、分解产品 质量目标：根据质量等级来分解产品的质量目标；为每个测试分层确定测试目标；

2、使用 老功能分析法来对特性进行分类：全新特性；老特性变化；老特性加强；老特性无变化；

3、基于 质量和风险来确定测试深度和测试广度（深度指使用的测试方法，广度指测试的范围）：使用产品质量评估模型初步确认测试深度；考虑用老功能分析更新测试深度；基于老功能分析来初步确定测试广度；

4、确定测试 优先级：质量等级越高，优先级越高；相同质量等级下，全新特性比老特性优先级高；改动越多的老特性，优先级越高；根据优先级等级，制定测试投入策略；

5、确定测试 总体框架：三个层次，分别是策略层（类似大脑，负责指挥）、活动层（类似身体，负责执行）、保证层（类似五官，负责保证）；

6、回顾：总体测试策略输出的就是 两张表（总体测试策略分析表，测试投入策略表）和 一幅图（测试总体框架）；

7.4 制定阶段测试策略

阶段测试策略向上能够承接总体测试策略，向下能够指导后面的测试执行；

1、测试 设计策略：按照测试深度来进行测试设计，然后执行测试用例，达到执行的目的；

1.1、使用“测试分析设计表”来保证测试设计符合测试策略（包含3个表，分别是测试分析准备表、测试类型分析表（列为需求，行为测试类型）、功能交互分析表）；

1.2、四步测试设计法和测试广度：参见4.4，输出测试用例；

1.3、测试用例等级：测试用例分级会为后面进行的分层测试、回归测试、验收测试和自动化测试在如何选择用例方面提供方便；

2、 集成测试策略：俄罗斯方块心项目的集成开发；集成测试的对象和测试目标（新合入功能是否正确；功能集成后系统功能正确性；原来的系统功能没有被合入的功能破坏）；入口准则--何时开始（用例输出且评审完毕；测试资源到位；测试环境就位）；测试用例选择（功能：级别1；新功能集成：级别2和部分级别3；确认原系统：级别1）；出口准则（集成功能开放、集成完成；测试用例执行完成；缺陷分析符合预期；达到集成测试质量目标）；

3、 系统测试策略：系统测试的对象和测试目标（系统角度验证测试功能的正确性；系统角度验证各种非功能质量的正确性）；入口准则--何时开展（集成测试出口、测试准备到位）；测试用例选择（功能测试：级别1和部分级别2；非功能：级别3和级别4）；测试执行顺序（考虑以下：有些测试方法本来就需要满足一定条件；先进行复杂的，再进行简单的；组合多种测试方法）；出口准则（达到目标）；

4、 验收测试策略：Alpha测试（谁来执行（测试人员模拟用户进行测试，了解用户的人及测试组员交叉测试是不错选择）、测试策略（用户学习产品、产品资料、安装部署、升级、移除、上下游设备、业务、故障、管理配置、日志报表等运维功能））；Beat测试，用户参加的测试；入口准则--何时开始（系统测试出口，Alpha测试人员及方案已经确认，Beat测试用户已经确定）；出口准则--何时推出，发布产品（达到总体策略中产品质量目标）；

5、回顾：确定了测试设计策略；确定了各个测试阶段的测试策略；

第8章 版本测试策略和产品质量评估

项目开始进入测试执行阶段，测试架构师也要进入执行测试策略的工作中了；

8.1 开始

测试阶段的工作，主要是围绕：制定版本测试策略，跟踪测试执行，质量评估；

8.2 第一个版本测试策略

1、测试范围以及和计划相比的偏差：实际提交的功能和设计不符时，如果相关功能对测试人员而言不可测，则不接收测试；反之，接收测试；

2、本版本的测试目标：以测试对象--测试方法--测试结果这样的方式来描述测试目标，好处是强调了基本测试要求，比数字指标容易理解和执行；

3、需要重点关注的内容：首先，对提交的功能，提出团队重点关注内容；其次，确定测试的优先级表；

4、测试用例的选择：根据测试用例等级，选择测试用例就简单多了；

5、测试执行顺序：质量情况好，可以考虑更多的测试方法组合起来执行；刚提交的功能，质量不好或不明时，不建议组合测试；

6、试探性的测试策略--需要大家分工合作的地方：全局因素工作量大，可以进行试探测试；一些全局性配置，也可以使用这样的策略；

7、接收测试策略：开发将版本交由测试人员时，测试人员先进行一次测试，确认版本没有阻塞性问题；如果阻塞可以规避，建议继续测试；

8、回顾：测试范围及计划偏差、测试目标、重点内容、用例选择、执行顺序、试探性测试、接收测试；

8.3 跟踪测试执行

跟踪的目的有三个：确保测试团队按照测试策略来执行；实时关注缺陷，通过缺陷分析评估策略是否适合，是否需要调整；关注项目风险，基于风险调整策略；

1、跟踪测试 用例执行情况：

1.1、测试团队的测试执行顺序是否和测试策略相符（测试团队是否按照特性优先级顺序来执行测试用例；测试团队是否按照测试策略中的测试方法、测试顺序来进行测试；）；

1.2、被阻塞的测试用例（测试人力不足、测试时间不够、测试环境不具备、其他缺陷导致）；

2、 每日跟踪缺陷：缺陷的趋势是否正常、是否存在引入缺陷修改引入的缺陷、本版本必须解决的缺陷、本版本需要解决的缺陷；

2.1、哪些缺陷必须在本版本中解决：标准只有一个，就是会不会对后续的测试造成阻塞；

2.2、哪些缺陷需要在本版本中解决：我们希望在本版本中修复的缺陷；优先解决的缺陷类型：

缺陷的改动越大，越需要尽早解决；缺陷涉及需求、方案、涉及，需尽早解决；优先解决严重程度为致命和严重的缺陷；

2.3、缺陷趋势是否正常：预估拐点会在哪个版本出现；判断当前版本的缺陷趋势是否正常；

2.4、是否存在缺陷修改引入缺陷的问题；

3、 调整测试策略：

发现测试情况与测试策略不符时，需要调整测试策略；如下调整思路：

被阻塞的测试用例是属于几个功能，还是很多功能；存在阻塞的功能，原计划不在本版本中执行的用例，是否可以调整到本版本；没有阻塞的功能，原计划不在本版本执行的用例，是否可以调整到本版本中测试；

在缺陷跟踪的时候，发现趋势不符合预期；如果拐点出现的太早，当前测试方法已经不能有效发现缺陷，需要分析原因，调整策略；如果一直未出现拐点，当前测试还能有效发现缺陷，根据项目情况进行调整；

8.4 版本质量评估

1、使用软件产品质量评估模型来进行质量评估：

1.1、在版本质量评估中记录需求和实现的偏差：由开发人员提供的实际提交的功能和需求的偏差；在测试过程发现的实际功能和需求的偏差（与此有关的BUG列表；开发人员、测试人员和SE需求澄清进展、结论及后续进展）；

1.2、在版本质量评估中进行测试过程评估：测试用例通过率（首次执行通过率、累积执行通过率）；测试用例在多个版本中的测试结果（出现反复，可能存在隐患，需要根因分析）；

1.3、在版本质量评估中进行缺陷分析；

2、版本质量评估中的缺陷分析；

2.1、版本缺陷密度评估；

2.2、版本缺陷年龄分析；

2.3、版本缺陷触发因素分析；

3、调整测试策略：评估发现可能会影响最终发布的质量问题，需要采取相应的措施；

4、建立特性版本质量档案：至少包括当前测试覆盖度方面的记录、测试过程的分析和记录、缺陷分析；

8.5 后面的版本测试策略

进入下一个循环；

1、 回归测试策略：是一种确认性质的测试；测试目标有缺陷回归、功能回归、阶段回归；

1.1、缺陷验证策略：确认缺陷被开发人员正确修复了；

1.2、功能回归策略：确认老功能不会因为新合入的功能而失效；新功能回归测试、老功能回归测试；

1.3、阶段回归策略：确认产品当前的质量达到该阶段的质量目标；集成测试阶段回归测试、系统测试阶段回归测试、验收测试阶段回归测试；

2、 探索式测试策略：将它与传统测试结合起来；

2.1、将探索式测试和传统测试结合起来：先进行传统测试，再进行探索测试；

2.2、探索式测试方法的选择策略：集成测试时，先使用商业区测试法和娱乐区测试法，再使用历史区测试法和破旧区测试法；系统测试时，先使用历史区测试法和破旧区测试法，再使用商业区测试法和娱乐区测试法，最后使用旅馆区测试法和旅游区测试法；

2.3、探索式测试策略在版本策略中：确认范围；根据当前阶段确认主要的探索式测试方法；输出探索式测试任务；

3、 自动化测试策略：主要的还是放在回归测试，如功能回归和BUG回归；需要我们先对需要多次执行的测试用例进行自动化、优先自动化简单的可靠的功能；

3.1、确定自动化脚本编写的优先级：优先级高的优先实现；优先级一样的，优先实现简单的可靠性高的；

3.2、自动化开发和测试如何与测试项目配合；

3.3、关于自动化率；

3.4、鼓励通过脚本来解决测试中的实际问题；

4、回顾：形成了版本测试策略关注的所有内容；

8.6 阶段质量评估（包括发布质量评估）

每个阶段即将完成时，进行一轮整体性评估，判断是否满足出口标准；

1、阶段质量评估项目：

1.1、确认总体测试策略中的质量目标是否完成：发现质量红线未达到；一般质量目标未达到；

1.2、质量的重要目标（质量红线）；

1.3、对未达到的一般性质量目标制定应对措施：非测试用例发现缺陷的原因分析；组合缺陷分析；

1.4、遗留缺陷分析；

2、非测试用例发现缺陷的原因分析：原因分析可以在整个测试团队进行；

3、组合缺陷分析：一般性的质量目标问题，需要组合分析，系统角度整体评估问题影响；

4、遗留缺陷分析：版本发布时不准备修复的缺陷；

4.1、缺陷对用户的影响程度；

4.2、缺陷发生的概率：用户环境中发生的概率；

4.3、缺陷风险评估和规避措施；

4.4、不能遗留的缺陷：致命缺陷、没有规避措施的严重缺陷不应该遗留；

4.5、缺陷遗留列表：作为讨论和发布的材料；

5、临近发布时的缺陷修复策略：缺陷遗留标准可能有差异；发布临近，严控缺陷修复的数量；

6、非必然重现BUG的处理：需要跟踪和处理；

7、总结：发布阶段，质量评估并给出评估结论是一项重要的工作；保证产品能够按时按质按量发布；贯穿测试项目始终的活动；