第六章：如何制定测试策略
6.1 理解测试策略
1、什么是测试策略？
测什么？怎么测？
- 测试的对象和范围是什么？
- 测试的目标是什么？
- 测试的重点和难点是什么？
- 测试的深度和广度是什么？
- 如何安排测试活动（先测什么，再测什么？）
- 如何评价测试的效果？
2、测试策略和测试方针？
测试方针是产品测试的通用要求、原则或底线。
遵循测试方针 + 项目实际情况 = 测试策略
3、测试策略和测试计划？
它们之间的关系是：通过测试策略确定的测试活动被分解为一个个测试任务，这些任务有确定工期，执行的先后次序和责任人。
测试计划属于测试经理的范畴。
4、测试策略和测试方案？
测试方案解决的是特性在测试设计和测试执行方面的问题。 而测试策略解决的是产品测试的六大问题。
6.2 测试策略制定法（4步）
- 明确“产品质量目标”
- 进行“风险分析”
- 适配“产品开发流程”
- 进行“测试分层”
一、明确产品质量目标
1、通过“产品质量评估模型”来得到产品的质量目标。
2、围绕产品的质量目标来进行刚刚好的测试，即质量要求高的重点测，质量高的测试投入大，质量要求高的测得深。
3、围绕着产品质量评估模型将目标——行为——评估形成闭环。
我们通过“产品质量模型”得到具体的产品质量目标，根据质量目标来制定测试策略，确定测试活动，接着执行测试活动，最后对测试效果进行评估。
二、进行风险分析
如果漏掉了风险风险，那么在测试执行过程中会出现很多阻碍而且会感觉测试策略很笨重。
1、提前识别项目中的阻碍测试的风险，基于风险调整测试策略。
2、基于风险来加强和降低测试的投入。
三、适配“产品开发流程”
四、进行测试分层
测试分层是将有公共测试目的的测试活动放在一起形成一个组，然后一组一组地逐一进行测试。
通过测试分层，可以将大的测试目标分解到不同层中去执行。
五、四步制定法中的测试技术
明确产品质量目标：产品质量评估模型、缺陷分析技术
风险分析： 风险分析技术、老功能分析技术
测试分层： 分层测试技术
6.3 产品质量评估模型
很多时候，即使使用了多个质量指标去评估质量，但是心里还是没底— —这是因为这些指标往往覆盖不全，导致心里没底。
产品质量评估模型的优秀特质：
- 多维度：能够覆盖质量评估的各个维度，能够帮助评估者全面分析和考虑。
- 定量 + 定性：指标和分析相结合，能够有效避免在只有指标的情况下，被绕过去，变得形同虚设。
- 过程 + 结果：不近评估测试的结果，还对过程进行分析和评估。
从3个方面建立质量评估模型：
- 测试覆盖度评估
- 测试过程评估
- 缺陷分析
6.4 测试覆盖度评估
需求覆盖度：已经测试验证的产品需求和产品需求规格总数的比值。（定量指标）
路径覆盖度：已经测试到的语句的数量和程序中可执行语句的总数量的比值（定性指标）
一、需求覆盖度评估
需求覆盖度的目标必须是100%。
需求覆盖度评估有一下两个方法：
方法1：直接在需求表中确认测试情况。
方法2：建立测试用例和需求的对应关系。
注：方法1最好不要在测试结束后再进行确认，这样往往时间不够。而应该边测试边确认。方法2注意的是需求变化的那部分，特别是项目后期的增加、修改、删除的需求。方法2中可能会出现一对多或者多对多的情况，所以最好有工具来维护。
二、路径覆盖度评估
语句覆盖：覆盖系统中所有判定和过程的最小路径集合
分支覆盖：覆盖系统中每个判定的所有分支所需的最小路径数
全覆盖：100%地覆盖系统所有可能的路径的集合
最小线性无关覆盖：保证流程图中每个路径片段能够至少执行一次的最少的路径组合
1、确定路径覆盖策略
可以将最小线性无关覆盖作为一个基本的路径覆盖方式
对优先级高的功能特性，可以在最小线性的基础上增加一些路径
对优先级低的功能特性，可以在最小线性无关覆盖的基础上减少一些路径
2、使用路径分析法设计测试用例
3、跟踪测试用例的执行情况
6.5 测试过程评估
一、测试用例评估
- 测试用例执行率
- 测试用例执行通过率
- 测试用例和非测试用例发现缺陷比
用例执行率 = （执行用例的失败数+成功数）/ 总用例数 【注：同一条用例重复执行，只算一次】
影响执行率的因素可能有测试阻塞和未执行。
测试用例执行通过率可以分为：首次执行通过率和累积执行通过率。
首次执行通过率 = 第一次执行该测试用例的结果为“通过”的测试用例数 / 已经执行的测试用例数
累积执行通过率 = 测试用例结果为“通过”的测试用例数 / 已经执行的测试用例数
首次执行通过率可以评估开发版本的质量
乐基执行通过率可以评估产品发布是的质量
测试用例和非测试用例发现缺陷比。
二、测试投入分析
6.6 缺陷分析
1、缺陷密度
即每千行代码发现的缺陷数。
确定和分析缺陷密度的重要意义在于：
1、通过缺陷密度，我们可以预测产品中可能会有多少缺陷
2、通过缺陷密度，可以帮助我们评估当前已经发现的缺陷总数是否足够多。如果缺陷密度和预期偏差较大，原则上不应该退出测试，发布产品。
由于实际的缺陷密度和预期的缺陷密度不会恰好相等，所以应该有一个偏差范围：比如偏差范围3%、5%等。
2、缺陷修复率
即：已经修复解决的缺陷总数和已经发现缺陷总数的比值。
1.缺陷的严重程度
3、缺陷趋势分析
即：随着测试时间的进行，测试发现的缺陷趋势和开发解决缺陷的趋势。
1、绘制缺陷分析图
主要的指标有：累积发现的缺陷数，当天发现的缺陷数，累积解决的缺陷数，当天解决的缺陷数
2、缺陷趋势曲线的“凹凸点”和“拐点”
理想情况下，应该是随着时间的增加，先出现凹曲线，一段时间后出现凸曲线。注意拐点的位置不能过快或者没有拐点
3、缺陷是否收敛
累积发现的缺陷最后为凸函数，最后与累积解决的缺陷越来越靠近，最终趋于一点。
PS：如果累积解决的缺陷趋势没有趋向一点，说明开发还有很多缺陷没有修复，应该继续测试
如果累积发现的缺陷趋势还是为凹函数，那么说明还有可能有很多的缺陷被发现，也应该继续测试。
4、缺陷年龄分析
是指软件产生或引入缺陷的时间。
| 缺陷年龄 | 描述 |
| 继承或历史遗留 | 属于历史版本。继承版本或是移植代码中的问题，非新开发的问题 |
| 需求阶段引入 |
缺陷是在产品需求设计阶段引入的，主要包括如下情况： 1、需求不清的问题 2、需求错误的问题 3、系统整体设计的问题 |
| 设计阶段引入 |
缺陷是在产品设计阶段引入的问题，主要包括如下情况： 1、功能和功能之间的接口的问题 2、功能交互的问题 3、边界值设计方面的问题 4、流程、逻辑设计相关的问题 5、算法设计方面的问题 |
| 编码阶段引入 |
缺陷是在产品编码阶段引入的问题，主要包括如下情况： 1、流程、逻辑实现相关的问题 2、算法实现相关的问题 3、编程规范相关的问题 4、模块和模块之间接口的问题 |
| 新需求或变更引入 | 缺陷是因为新需求、需求变更或设计变更引入的问题 |
| 缺陷修改引入 | 缺陷是因为修改缺陷时引入的问题。如开发虽然成功修复了一个缺陷，但修改又引入了新的缺陷 |