《测试架构师的修炼之道》六—如何才能制定好测试策略--转载

制定测试策略是软件测试架构师最核心的技能，但是要想做好这项工作并不是容易的事情。

一、理解测试策略

1.1 什么是测试策略

通俗来讲就是六个字'测什么'和'怎么测'。

·测试的对象和范围是什么？

·测试的目标是什么？

·测试的重点和难点是什么？

·测试的深度和广度？

·如何安排各种测试活动（先测试什么，再测试什么）？

·如何评价测试的效果？

1.2 测试策略与测试方针

测试策略并不等同于测试方针，这是很容易被混淆的一对概念。

什么是测试方针？

测试方针是产品测试中的通用要求、原则或底线。

通用是测试方针的显著特点：它不针对某个特定产品，而是一个产品族，或是一个产品系列，并且在较长的一段时间内都是适用的。

测试方针举例：

·产品的缺陷修复率达到75%以上，才能发布。

·开发转给测试的版本，需要进行自测，并出具测试报告。

·对发布版本，无论代码修改了多少，都要对基本功能进行回归测试。

·产品升级后发现有功能丢失了，这类缺陷的等级为严重。

测试策略仅针对当前特定产品版本而言，并不像测试方针那样具备通用性。可以这样理解测试策略：

遵循测试方针+项目实际情况=测试策略

测试策略需要遵循测试方针，并不意味这我们不能根据项目的实际情况来对测试方针进行调整。

以产品的缺陷修复率要达到75%以上，才能发布这条测试方针为例，如果当前某个特定产品版本对产品质量要求特别高，在制定测试策略时，我们可以考虑将这条方针调整为’产品的缺陷修复率达到90%以上，严重以上的缺陷修复率为100%‘

1.3 测试策略与测试计划

通过测试策略确定的测试活动，在测试计划中被拆解为一个个任务，并为每个任务确定工期，执行的先后次序和责任人。

测试计划的制定者是测试经理，属于测试管理的范畴。

测试策略的制定者是测试架构师，属于测试技术的范畴。

1.4 测试策略与测试方案

测试方案主要解决的是特性在测试设计和测试执行方面的问题。

测试方案需要遵循测试策略

从责任人角度来说，测试策略的责任人是软件测试架构师，而测试方案的责任人是各个特性测试责任人。

 

附：测试车轮图

二、四步测试策略制定法

一套指导我们制定测试策略的整个过程的方法：四步测试策略制定法。

 

2.1 明确产品质量目标

1）我们的测试目标就是让产品在发布的时候能够满足事先约定的质量目标

对测试来说，我们的测试目标就是让产品在发布的时候，能够满足事先约定的质量目标。我们制定测试策略，也是为了让产品经过各种测试后，最后达到质量目标。

2）围绕产品质量目标进行刚刚好的测试

过多地被好奇心左右，测试很可能会偏离本来的测试目标，变成了凭感觉测试。

不凭感觉，理性的测试应该是这样的：

产品质量要求高的是测试重点，反之为非重点。

产品质量要求高的投入大，反之小。

产品质量要求高的要测的深，反之浅。

总而言之，要围绕产品质量进行，并不需要试图将每个地方都测试得全面深入，刚刚好才是我们真正需要追求得测试状态。

3）将目标—行为—评估形成闭环

一旦发现没有达到产品质量目标，就调整测试策略，让整个测试始终保持在达到产品质量目标的航线上。

2.2 进行风险分析

1）提前识别项目中可能存在哪些会阻塞测试的风险，然后基于风险来调整测试策略

举例：实际项目中测试活动无法顺利开展的一些例子

例1：在需求阶段，需求工程师未能提供全面的产品需求文档，导致测试设计时场景缺失，无法达到测试设计的预期效果

例2：在测试设计时，开发未能提供相关设计文档，或是文档未能及时更新，导致测试设计遗漏或者不准确，无法达到测试设计的预期效果

例3：在测试执行时，发现一些测试用例因为缺陷或者代码提交的原因阻塞了，不能按照原计划进行测试执行

例4：在测试执行时，发现缺陷迟迟不能修改，缺陷分析结果不能达到预期

等等。。

2）基于风险来加强和降低测试投入

老功能在老版本中已经被测试过，质量的起点相比全新开发的功能要高，失效的风险更低。即使全新开发的功能和老功能的质量目标是一样的，我们也没必要等同投入资源——理想状态是测试能够基于风险来进行测试：

·对高风险的部分加强测试投入

·对低风险的部分降低测试投入

2.3 适配产品研发流程

·何时开展测试策略的制定

·制定测试策略是一次到位，还是分几次完成

1）测试策略的结构

很难在项目的需求分析阶段就制定出一份非常详尽的测试策略。如果测试策略的内容只是一些大方向，大原则，到执行层面就很容易变形，违背了测试策略制定的初衷。

根据在哪个阶段项目能够确定到哪种程度的实际情况，来为测试策略设计一个符合这种进程的结构。

 

传统研发流程示意图

针对这个研发流程，设计了总体测试策略—阶段测试策略—测试执行策略的测试策略结构。

2）根据研发流程来安排测试活动

 

测试人员职责

需要软件测试架构师能够做好版本测试策略，能够和开发人员进行有效沟通，使得双方能够理解彼此的节奏，达到更好的配合。

2.4 进行测试分层

测试分层指将有共同测试目的的测试活动放在一起形成一个组，然后一组一组地逐一进行测试。

2.5 四步测试策略制定法中地测试技术

 

三、产品质量评估模型

3.1 优秀的产品质量评估模型特征

·多维度：能够覆盖质量评估的各个维度，能够帮助评估者全面分析和考虑

·定量+定性：指标和分析相结合，能够有效避免在只有指标的情况下，被’绕’过去，变得形同虚设

·过程+结果：不仅评估测试的结果，还对过程进行分析和评估

3.2 软件产品质量评估模型

 

测试覆盖度评估：对测试范围及测试的深度与广度进行分析和评估

测试过程评估：对测试过程和测试的投入情况来进行分析与评估

缺陷分析：对测试结果进行分析和评估

四、测试覆盖度评估

测试覆盖度评估是对产品测试的全面性的分析和评估，是产品测试能够对产品质量进行评估的基础。

 

4.1 需求覆盖度评估

需求覆盖度的目标必须为100%，即测试保证对产品承诺要实现的需求都进行了验证。

需求覆盖度评估的两种方法：

方法1：直接在需求表中确认测试情况，尽量不要再项目测试快结束的时候才进行，很可能会打乱整个测试节奏，可以根据开发的合入计划，边测试边确认。

方法2：建立测试用例和需求的对应关系，通过编号来建立需求和测试用例的对应关系，从一开始就保证需求的覆盖，从源头上避免了需求遗漏的风险。需要注意需求变化，避免遗漏。

4.2 路径覆盖度评估

路径覆盖是‘已经测试到的语句的数量’和‘程序中可执行语句的总数量’的比值

需要用到路径分析法

 

1）确定路径覆盖策略

·将最小线性无关覆盖作为一个基本的路径覆盖方式

·对优先级高的功能特性，可以在最小线性无关覆盖的基础上增加一些路径

·对优先级低的功能特性，可以在最小线性无关覆盖的基础上减少一些路径

·不建议全面进行全覆盖，页不建议使用语句覆盖

2）使用路径分析法设计测试用例

3）跟踪测试用例的执行情况

五、测试过程评估

 测试过程评估分析的对象是测试用例，测试方法和测试投入。

5.1 测试用例的评估

通过3个指标来对测试用例进行评估

·测试用例执行率

·测试用例执行通过率

·测试用例和非测试用例发现缺陷比

此外还需要对测试用例划分优先级，在项目进行或者人力紧张的情况下，就可以优先保证高优先级的测试用例执行率，步执行某些低优先级的测试用例。

5.2 测试方法分析

确定测试方法后，在测试设计和测试执行中跟进，保证各个特性使用的测试方法和测试策略相符，并通过缺陷来确认测试策略是否合适，是否需要调整测试策略

5.3 测试投入分析

 

测试投入分析主要从测试人员安排和测试投入工作量来进行分析，确认重要的、高风险的特性能够保证测试投入

如果发现测试投入和测试策略不符，则需要考虑调整测试投入，或者调整测试策略。进行风险识别和风险控制，及时调整测试策略。

六、缺陷分析

缺陷指在产品测试中发现产品不符合需求和设计的地方。如果仅仅把缺陷当成产品问题记录，而不去挖掘缺陷数据背后隐含的和产品质量有关的信息，就显得太可惜了。

6.1 缺陷密度

缺陷密度指每千行代码发现的缺陷数。

对于一个产品研发项目而言，确定、分析缺陷密度的重要意义在于：

·通过缺陷密度，我们可以预测产品中可能会有多少缺陷

·通过缺陷密度，我们可以评估我们当前已发现的缺陷总数是否足够多

如果我们发现实际的缺陷密度值偏低，通常可能是：

·产品质量较好

·测试能力不足，未能充分暴露缺陷

·测试投入不足，未能充分暴露缺陷

6.2 缺陷修复率

·在每个测试分层（如集成测试、系统测试）开始的时候确定缺陷修复率目标

·在每个测试分层结束时判断是否达到目标，是否可以进入下一阶段的测试

·如果最终的缺陷修复率不能达到预期，原则上不应该退出测试，发布产品

1）缺陷的严重程度

 

 

2)考虑了缺陷的严重程度的缺陷修复率

6.3 缺陷趋势分析

缺陷趋势是指‘随着测试时间的进行，测试发现的缺陷趋势和开发解决缺陷的趋势’

缺陷趋势分析可以帮助我们判断当前系统是否还能很容易地发现缺陷，进而帮助我们确定是否可以推出测试，发布产品。

1）绘制缺陷趋势图

 

 

2）缺陷趋势曲线地凹凸性和拐点

 

在测试策略不变的情况下，出现“拐点”，说明当前的测试方法已经不能有效去除系统的缺陷，当前的测试可以按照计划结束，进入下一阶段的测试。
这里强调测试策略不变非常重要。例如，测试团队的投入减少了，也可能会导致“拐点”的出现。这时就需要我们调整测试策略来达到测试目标，而不是准备结束测试了。

3）缺陷是否收敛

当我们发现缺陷不收敛时，做好代码改动方面的控制，是一个很好的思路：
·严格控制代码改动，非必要不改动。
·做好代码的静态检查。
·做好和修改相关的功能自测，避免因为缺陷修改而引入新的问题

6.4 缺陷年龄分析

缺陷年龄定义：

 

缺陷年龄分析图：

 

如果真能达到这样的水平，测试也就可以“光荣”失业了。但实际情况是，每个阶段都会有一些缺陷“逃逸”到下一阶段，需要“测试”来发现这些逃掉的缺陷。
 

6.5 缺陷触发因素分析

缺陷出发因素分析，就是对测试中使用地测试方法进行分析。

1）确定缺陷的测试方法和测试类型

2）统计出各种测试方法发现的缺陷数目，绘制缺陷触发因素分析图

3）进行缺陷触发因素分析

6.6 组合使用各种缺陷分析技术

 

七、风险技术分析

7.1 风险分析

1）风险识别

风险识别方法：

 

2）风险评估

机会成本告诉我们，要想用有限的资源获得最大的收益，就需要我们优先处理最可能会发生、影响（如损失）最大的事件。这就需要我们对识别出来的风险点进行评估，确定风险优先级，然后优先处理高风险的问题。简言之，风险评估的目标就是确定风险优先级。

·风险优先级正交表

·需求类风险

·设计类风险

·流程类风险

·历史类风险

7.2 风险应对

在风险管理中，风险应对主要分为如下4种：
·回避风险：指主动避开损失发生的可能性。
·转移风险：指通过某种安排，将自己面临的风险全部或部分转移给其他一方。
·减轻风险：指采取预防措施，以降低损失发生的可能性和影响程度。
·接受风险：指自己理性或非理性地主动承担风险。

“风险应对”举例：新需求在开发过程中不断被增加
·“回避风险”的做法：置之不理。
·“转移风险”的做法：将新需求外包。
·“减轻风险”的做法：寻求额外资源或裁剪其他优先级低的需求。

·“接受风险”的做法：将新需求加入项目范围，通过加班来完成新需求。

7.3 老功能分析

对老功能进行风险分析，以此来确定老功能在新版本中的测试深度和测试广度，制定“刚刚好”的测试策略。

 

1）差异性分析

2）历史测试情况分析

八、分层测试技术

8.1 V模型

最经典的测试分层——V模型

 

·单元测试：从产品实现的函数单元的角度，验证函数单元是否正确。
·集成测试：从产品模块和功能的角度，验证功能模块和模块之间的接口是否正确。
·系统测试：从系统的角度，验证功能是否正确，验证系统的非功能属性是否能够满足用户的需求。
·验收测试：从用户的角度，确认产品是否能够满足用户的业务需求。

8.2 设计测试层次

1）某通信公司的测试分层

 

2）某公司在敏捷环境下的测试分层