测试架构师：4 如何才能制定好测试策略

测试架构师：4 如何才能制定好测试策略

 

2016-08-18

目录

1　理解测试策略
  1.1 什么是测试策略？
  1.2 测试策略等于测试方针？
  1.3 测试策略等于测试计划？
  1.4 测试策略等于测试方案？
2　四步测试策略制定法
  2.1 明确“产品质量目标”
  2.2 进行“风险分析”
  2.3 适配“产品研发流程”
  2.4 进行“测试分层”
  2.5 “四步测试策略制定法”中的测试技术
3　产品质量评估模型
  3.1　优秀的产品质量评估模型的特征
  3.2　软件产品质量评估模型
4　测试覆盖度评估
  4.1　需求覆盖度评估
  4.2　路径覆盖度评估
5　测试过程评估
  5.1　测试用例评估
  5.2　测试方法分析
  5.3　测试投入分析
6　缺陷分析
  6.1　缺陷密度
  6.2　缺陷修复率
  6.3　缺陷趋势分析
    6.3.1 绘制缺陷趋势图
    6.3.2 缺陷趋势曲线的“凹凸性”和“拐点”
    6.3.3 缺陷是否收敛
  6.4　缺陷年龄分析
    6.4.1 肯定缺陷的缺陷年龄
    6.4.2 统计出各种缺陷年龄的数量，绘制缺陷年龄分析图
    6.4.3 进行缺陷年龄分析
  6.5　缺陷触发因素分析
    6.5.1 肯定缺陷的测试方法和测试类型
    6.5.2 统计出各类测试方法发现的缺陷数目，绘制缺陷触发因素分析图
    6.5.3 进行缺陷触发因素分析
  6.6　组合使用各类缺陷分析技术
7　风险分析技术
  7.1　风险分析
    7.1.1 风险识别
    7.1.2 风险评估
  7.2　风险应对
  7.3　老功能分析
    7.3.1 差别性分析
    7.3.2 历史测试状况分析
8　分层测试技术
  8.1　V模型
  8.2　设计测试层次

 

四步测试策略制定发思惟导图

1 理解测试策略

---

 返回

1.1 什么是测试策略？

“测试策略”通俗来说就是6个字：“测什么”和“怎么测”。

具体来说，就是答好和产品测试相关的六大问题：

• 测试的对象和范围是什么？
• 测试的目标是什么？
• 测试的重点和难点是什么？
• 测试的深度和广度？
• 如何安排各类测试活动（先测试什么，再测试什么）？
• 如何评价测试的效果？

1.2 测试策略等于测试方针？

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

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

测试方针举例：

• 产品的缺陷修复率要达到75%以上，才能发布。
• 开发转给测试的版本，须要进行自测，并出具测试报告。
• 对发布版本，不管代码修改了多少，都要对基本功能进行回归测试。
• 产品升级后发现有功能丢失了，这类缺陷的等级为严重。

试策略仅针对当前特定的产品版本而言，并不像测试方针那样具有通用性。反过来，咱们却是能够这样理解测试策略：循测试方针+项目实际状况=测试策略

试策略须要遵循测试方针，并不意味着咱们不能根据项目的实际状况来对测试方针进行调整。

• 产品的缺陷修复率要达到75%以上，才能发布这条测试方针为例。若是当前某个特定产品版本，对产品质量的要求特别高，在制定测试策略的时候，咱们能够考虑将这条测试方针调整为“产品的缺陷修复率要达到90%，严重以上的缺陷修复率为100%”。

1.3 测试策略等于测试计划？

测试策略也不是测试计划，它们之间的关系是：经过测试策略肯定的测试活动，在测试计划中被拆解为一个个任务，并为每一个任务肯定工期、执行的前后次序和责任人，如图1所示。

图1　测试策略与测试计划的关系

表1 “测试计划”示例

此外，测试计划的制订者是测试经理，属于测试管理的范畴。而测试策略的制定者是软件测试架构师，属于测试技术的范畴。

1.4 测试策略等于测试方案？

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

测试策略要解决的是产品测试的六大问题。显然，测试方案要解决的问题没有那么“高大上”，就是如何对特性进行测试设计和如何安排这个特性的测试执行，具体包括：

• 对特性的需求、场景、设计进行分析，提取测试点。
• 对测试点选择合适的测试设计方法（如使用怎样的测试设计模型、测试数据的选择），生成测试用例。
• 自动化测试设计。
• 测试执行时须要按照怎样的顺序来执行这些测试用例。

举例以下：

测试方案模板（以一个“特性”为单位）：

• 1.××特性的场景
  • a）用户场景描述。描述用户会如何使用这个特性。
  • b）测试场景描述。描述测试时会怎样模拟用户的使用，模拟和实际的差异在哪里，是否会有风险，等等。
• 2.××特性设计分析
  • a）产品实现中的关键业务流程。
  • b）重要的算法（或实现技术）的分析。
  • c）其余须要注意的内容分析。
• 3.××特性测试分析
  • a）测试类型分析。
  • b）功能交互分析。
• 4.××特性测试设计
  • 对测试点使用四步测试设计法，逐一获得测试用例。
  • 以“树”形结构来组织这些测试用例。
  • 为测试用例划分优先级。
• 5.××特性测试执行
  • 哪些测试用例准备进行手工测试。
  • 哪些用例计划进行自动化测试。
  • 哪些地方可能还须要进行探索测试。
  • 测试用例是否须要考虑测试执行顺序。

2）测试方案须要遵循测试策略

测试方案须要遵循测试策略对具体某个特性的测试深度和广度的要求。

例如，某测试策略对特性A和特性B的测试说明，见表2。

表2 测试说明

2　四步测试策略制定法

---

 返回

该在何时开始制定测试策略？若是在项目开头进行，你会发现不少和测试策略相关的内容根本就还不明了，无从下手；若是在项目后期进行，内容是明了，可是作测试策略的意义又在哪里呢？

可见，咱们仍是须要一套方法来指导咱们制定测试策略的整个过程，“四步测试策略制定法”应运而生，如图2所示。

图2　四步测试策略制定法

2.1 明确“产品质量目标”

明确“产品质量目标”是咱们在制定测试策略过程当中十分关键的一个步骤。对咱们而言，不只须要关注操做层面的具体方法，更要理解其中蕴含的测试策略思想。

1）咱们的测试目标就是让产品在发布的时候可以知足事先约定的质量目标

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

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

图3　产品质量评估

如图3：

• 首先，咱们将产品质量评估模型做用于具体的产品，获得产品质量目标。
• 其次，咱们根据产品质量目标来制定测试策略，肯定接下来的测试活动。
• 再次，执行各类测试活动。
• 最后，对测试效果进行评估，评估产品的质量目标是否达到。

2.2 进行“风险分析”

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

实际项目中真的有不少问题，都会让咱们的测试变得举步维艰。

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

• 例1：在需求阶段，需求工程师未能提供全面的产品需求文档，致使测试设计时场景缺失，没法达到测试设计的预期效果。
• 例2：在测试设计时，开发未能提供相关的设计文档，或是文档未能及时更新，致使测试设计遗漏或不许确，没法达到测试设计的预期效果。
• 例3：在测试执行时，发现一些测试用例由于缺陷或者代码提交的缘由阻塞了，不能按照计划进行测试执行。
• 例4：在测试执行时，发现缺陷迟迟不能修改，缺陷分析的结果不能达到预期。

“骨感”的现实告诉咱们，须要提早识别项目中可能存在哪些会阻塞测试的风险，而后基于风险来调整咱们的测试策略，增长一些测试活动或者质量保证活动。

2）基于风险来增强和下降测试投入

2.3 适配“产品研发流程”

什么时候开展测试策略的制定活动？制定测试策略是一次到位，仍是要分几回完成？

这就须要咱们将测试策略的制定和研发流程结合起来。

1）测试策略的结构

图4是一个传统研发流程示意图。针对这个研发流程，咱们设计了整体测试策略—阶段测试策略—测试执行策略这样的测试策略结构。

图6-4　传统研发流程示意图

有了这样的结构，咱们可以将当前的测试策略老是控制在“当下”，即项目的状况老是在比较肯定的范围内，避免咱们过于纠结“将来”。

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

测试策略中具体的内容，也须要和研发流程保持一致，确保测试和开发的节奏可以彼此吻合。

从大层面来讲，测试在各个阶段的活动和开发的活动是可以配合起来的，如图6-5所示：

图6-5　测试人员职责

要达到这个大层面的吻合，是比较容易的。相对比较困难的是，是在版本测试阶段，开发活动和测试活动彼此配合的问题。简单地说，就是开发人员在作计划的时候是否考虑了测试活动：

• 是否只是提交了一个“中间层”而非最后用户可见的功能？提交的功能是否可测？
• 测试可否有足够的时间进行测试准备？
• 测试可否在下个版本提交以前完成测试？

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

除此以外，咱们即将要介绍的测试分层，也能帮助咱们更好地制定版本测试策略。

2.4 进行“测试分层”

到目前为止，咱们已经可以综合考虑研发流程、风险，并基于产品质量目标来制定测试策略。经过上面的分析，咱们能够获得不少测试活动，会发现有那么多要作的事情，如今的问题是咱们该以什么策略去安排这些测试活动？

这个问题的最佳答案就是进行“测试分层”。

测试分层最大的价值在于：

• 经过测试分层，咱们可以将一个大的测试目标，分到不一样层次中分阶段去完成；
• 合理的测试分层，可以让测试目标SMART化。可以让咱们将目标（产品质量目标）—行为（测试活动）—评估（质量评估）的闭环，真正在产品测试中落地。

2.5 “四步测试策略制定法”中的测试技术

经过前面的介绍，咱们了解到在使用四步测试策略制定法来制定测试策略时，会使用到一些方式或者模型。总的来讲，如图6-6所示。

图6　四步测试策略制定法中用到的方式或模型

3　产品质量评估模型

---

 返回

产品质量评估模型将用在测试目标的肯定和评估上，它是整个测试策略的基础。在介绍这个重要模型以前，咱们想先花一点笔墨来讨论一下一个优秀的产品质量评估模型应该具有哪些特征。

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

产品质量评估中的几个场景：

• 场景1：项目计划的时间到了，就发布产品。
• 场景2：将缺陷修复率做为产品的质量目标。产品必须达到必定的缺陷修复率，才能发布。
• 场景3：咱们为产品创建了不少指标来做为质量目标，如缺陷修复率、测试代码覆盖率等。产品必须达到制订的质量目标，才能发布。

结果：

• 场景1说明测试团队当前尚未产品质量评估的具体办法
• 场景2和场景1相比，已经有了判断标准，能够说是有质的改变，但场景2也有“软肋”，就是评价的标准太过于单一
• 场景3看起来很好，可是在实际操做的时候，咱们每每会发现，咱们费时费力地对这些指标进行了统计、分析和跟踪，最后也都达到了，可是咱们对产品质量的好坏依然感到内心没底

我分析出现场景3中的问题，主要缘由有3点：

• 第一，这些指标覆盖的维度可能不全，咱们可能遗漏掉了一些重要的考察项。
• 第二，“指标”自己比较容易被“聪明人”绕过去，变得形同虚设。
• 第三，整个质量评价体系中全是指标，缺乏定性的分析

例如，咱们以测试的代码覆盖度要达到90%做为一项质量目标。为了达到这个目标，咱们可能会选择一些容易进行测试“覆盖”，但实际上风险并不大的地方进行测试。虽然最终能达到90%的测试覆盖目标，可是没有被测试到的10%那部分状况如何，是否真的不须要测试，可能会有哪些风险，对咱们来讲都是“未知”的。未知正是内心没底的源头。

若是咱们将这个问题从评估引伸到目标的层面，若是咱们在制订目标的时候，考虑的不只仅是指标，而能包含一些如“对重要特性，要达到100%的测试覆盖”“测试方法要包含语句覆盖、判断覆盖、路径覆盖”等的描述，以此做为要达到的质量目标，不只能解决上述的问题，还能更好地帮助咱们肯定要进行的测试活动。

综上，一个优秀的产品质量评估模型，应该具有以下特质：

• 多维度：可以覆盖质量评估的各个纬度，可以帮助评估者全面分析和考虑。
• 定量+定性：指标和分析相结合，可以有效避免在只有指标的状况下，被“绕”过去，变得形同虚设。
• 过程+结果：不只评估测试的结果，还对过程进行分析和评估。

3.2　软件产品质量评估模型

咱们将从3个方面来创建软件产品质量评估模型，对产品质量进行分析、肯定和评估（图7）：

图7　产品质量评估模型

• 测试覆盖度评估：对测试范围及测试的深度与广度进行分析和评估。（定量指标）
• 测试过程评估：对测试过程和测试的投入状况来进行分析与评估。（定量指标+定性分析）
• 缺陷分析：对测试结果进行分析和评估。（定量指标+定性分析）

4　测试覆盖度评估

---

 返回

表3　测试覆盖度评估的定义与属性

4.1　需求覆盖度评估

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

“需求覆盖度”中的“需求”，能够是“包需求”，也能够是“需求规格”“story”“user case”等能够表明项目中产品需求的内容，你们能够根据项目的实际状况来选择。

需求覆盖度评估有如下两种方法：

方法1：直接在需求表中确认测试状况

方法2：创建测试用例和需求的对应关系

方法2是在测试设计的时候，经过编号来创建需求和测试用例的对应关系。这样咱们只要保证这些测试用例都被执行了，需求也就都被测试验证了，见表6-5。

方法2的优点是，测试可以从一开始就保证需求的覆盖，从源头上避免了需求遗漏的风险；还很容易经过不一样的测试设计方法，让不一样优先级的需求可以有不一样的测试深度，更利于软件测试架构师对整个项目进行把控。

可是方法2也有一些须要注意的地方：

• 须要注意需求变化的部分：特别是在项目后期“增长”“修改”和“删除”的需求，避免遗漏。
• 方法2和测试设计的关系变得比较紧密，测试设计遗漏可能会影响对需求覆盖度的评估。
• 另外在实际项目中，需求和测试用例的对应关系，可能也并不像前面表格的例子中那样标准的一对一的关系，而是一对多、多对一或多对多这种比较混乱的状况，要想手工维护好这些关系并非一件容易的事情，特别是当遇到需求发生变化了，或是经过缺陷来增长测试用例等状况的时候，要修改的地方就更多了。因此，方法2最好可以有工具支持，可以经过工具来维护这些对应关系。

4.2　路径覆盖度评估

表6-6　路径分析法总结

第一步：肯定路径覆盖策略。
软件测试架构师能够以特性或者功能为粒度，根据该功能的质量目标来肯定路径覆盖策略。在如何选择肯定路径覆盖策略上，建议以下：

• 能够将最小线性无关覆盖做为一个基本的路径覆盖方式。
• 对优先级高的功能特性，能够在最小线性无关覆盖的基础上增长一些路径。
• 对优先级低的功能特性，能够在最小线性无关覆盖的基础上减小一些路径。

表7　路径覆盖策略的记录

第二步：使用路径分析法设计测试用例。

第三步：跟踪测试用例的执行状况。

当测试团队按照路径覆盖策略完成了用例设计后，对路径覆盖度的评估，就转换为了测试用例执行状况的评估。咱们的目标是这些设计的用例可以至少被执行一遍，而且测试结果为“经过”。若是存在测试用例在产品发布的时候都被“阻塞”，没法执行的状况，咱们就须要对阻塞的状况进行分析，评估当前的覆盖度是否可以知足测试的基本要求。

5　测试过程评估

---

 返回

5.1　测试用例评估

1.测试用例执行率

2.测试用例执行经过率

3.测试用例和非测试用例发现缺陷比

们但愿“经过测试用例发现的缺陷”和“发散测试”，也就是非测试用例发现的缺陷”的比值可以在一个合理的范围内。

若是比值太低，即大部分缺陷都是经过发散测试发现的，可能的问题是：

• 随机测试投入过多。
• 测试设计水平不高，存在测试设计遗漏。
• 对产品的需求或者设计的理解不正确、不许确或者不深刻，存在测试设计错误。

若是果比值太高，大多数缺陷都是经过测试用例发现的，可能的问题是：

• 测试人员不肯意进行发散测试（这样的测试团队可能也是一个比较沉闷、缺少激情、只是完成任务的测试团队）。
• 测试投入不足，没有时间进行发散测试。
• 测试思路尚未打开。若是存在这种状况，说明测试设计可能也不够全面。

5.2　测试方法分析

图8　详细总结图

其中：

• “分析测试设计是否和测试策略中的测试方法符合”，能够经过测试设计的过程跟踪、测试评审等方式去跟踪和分析。
• “分析测试执行时的测试方法是否符合测试策略”，能够经过测试执行时的日报、周报，测试用例执行状况等方式去跟踪和分析。
• “经过缺陷分析来肯定测试策略是否须要调整”，主要是对缺陷进行缺陷触发因素分析，相关的内容将在6.6节中为你们详细描述。

5.3　测试投入分析

测试投入分析也是很重要的一项测试过程评估项目，在这里咱们主要从测试人员安排和测试投入工做量来进行分析，确认重要的、高风险的特性可以保证测试投入，符合测试策略。

表8　测试投入分析

6　缺陷分析

---

 返回

可是若是咱们仅仅把缺陷当成产品问题的记录，而不去挖掘缺陷数据背后隐含的和产品质量有关的信息，就显得太惋惜了。

6.1　缺陷密度

缺陷密度是指每千行代码发现的缺陷数。咱们在肯定了缺陷密度后，还能够顺带获得缺陷总数。

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

• 经过缺陷密度，咱们能够预测产品中可能会有多少缺陷。
• 经过缺陷密度，能够帮助咱们评估当前已经发现的缺陷总数是否足够多。若是“缺陷密度”和预期误差较大，原则上不该该退出测试，发布产品。

咱们可以在产品测试以前，较为准确地预测产品的缺陷密度并将此做为一个测试目标，主要基于以下假设：

• 在系统复杂度、研发能力必定的状况下，由各个环节引入系统中的缺陷总数也会是基本一致的。

若是咱们发现实际的缺陷密度值偏高，一般最可能的缘由为：产品总体质量不高。此时，软件测试架构师能够：

提升缺陷密度的预估值。

对缺陷较多的地方增长测试投入，如增长测试人力、增长测试时间、使用更多的测试方法等。

考虑和研发经理、开发人员、系统工程师等一块儿进行一些质量改进和质量保证工做，如增强评审等。

若是咱们发现实际的缺陷密度值偏低，一般最可能的缘由为：

• 产品总体质量较好。
• 测试能力不足，未能充分暴露缺陷。
• 测试投入不足，未能充分暴露缺陷。

6.2　缺陷修复率

在每一个测试分层（如集成测试、系统测试）开始的时候肯定缺陷修复率目标。有时候产品的缺陷实在太多，为了保证重要缺陷可以被优先修复，咱们能够对缺陷按照严重程度进行划分，而后按照不一样的严重程度来肯定缺陷修复率。

1.缺陷的严重程度

表9　缺陷的严重程度的定义与示例

6.3　缺陷趋势分析

缺陷趋势是指“随着测试时间的进行，测试发现的缺陷趋势和开发解决缺陷的趋势”。咱们进行此项分析的重要缘由在于：缺陷趋势分析可以帮助咱们判断当前系统是否还能很容易地发现缺陷，进而帮咱们肯定是否能够退出测试，发布产品。

6.3.1 绘制缺陷趋势图

表10　缺陷趋势分析表

咱们将表10绘成图，就获得了如图9所示的缺陷趋势分析图。

图9　缺陷趋势分析图

在绘制缺陷趋势分析图时，不要忘记去掉节假日、周末公休日等“没有工做的日子”。

6.3.2 缺陷趋势曲线的“凹凸性”和“拐点”

1）理想的“累积发现的缺陷趋势”曲线

图10　理想的变化趋势

2）“累积发现的缺陷趋势”的“拐点”出现得过早

“拐点”的出现，意味着测试团队在这个测试阶段里已经没法有效发现产品的缺陷了。出现这种状况，可能的缘由有：

• 测试团队的投入发生了变化（如人员调动或者减小），而且已经影响了测试。
• 测试发生了阻塞（如产品质量差，存在会阻塞测试执行的缺陷），没法有效开展测试活动。
• 测试策略不当，当前的测试方法确实已经发现不了产品的缺陷了。

3）“累积发现的缺陷趋势”的拐点未出现

这说明在这个测试阶段里，测试团队依然能够发现产品大量的问题。出现这种状况，可能的缘由是：

• 测试团队未按照测试策略进行测试，可能使用了更多、更复杂的方法来发现产品缺陷。
• 版本质量太差，缺陷密度高于预期。

出现第一种状况，这个团队的测试者水平应该比较不错（至少掌握的测试方法比较多）；也应该比较有测试激情（不是按照软件测试架构师要求的任务测完就结束了，而是本身主动去发现系统更多的问题）；另外版本的质量可能也不错（至少还可以使用各类测试方法来“折腾”系统），没有严重的测试阻塞。但这依然须要软件测试架构师和测试者仔细核对测试计划，确认测试者是在保证了测试计划的前提下才进行发挥的——核对的过程可能会让人感到有些尴尬，但咱们的核心理念是：经过测试策略来进行“刚恰好”（咱们必须保证对重点测试部分的确认）的测试，而不只是为了发现产品的缺陷。

若是确认发现测试计划存在误差，须要在下个版本中进行补充测试，并和测试者作好沟通。

出现第二种状况，软件测试架构师能够考虑从以下几个方面来更新后续的测试策略：

• 增长相关内容的测试用例执行次数。
• 增强相关内容的回归测试。
• 对发现的缺陷进行逆向分析，增长探索式测试。

6.3.3 缺陷是否收敛

咱们在判断缺陷趋势是否收敛时，须要具有如下两个条件，缺一不可：

• “累积发现的缺陷趋势”变为凸函数。
• “累积发现的缺陷趋势”和“累积解决的缺陷趋势”两条曲线愈来愈靠近，最后逐渐趋于一点。

当咱们发现缺陷不收敛时，作好代码改动方面的控制，是一个很好的思路：

• 严格控制代码改动，非必要不改动。
• 作好代码的静态检查。
• 作好和修改相关的功能自测，避免由于缺陷修改而引入新的问题。

6.4　缺陷年龄分析

表11　缺陷年龄的定义

进行缺陷年龄分析，可以帮助咱们确认每一个可能引入缺陷环节、可能引入的缺陷是否都已经被有效去除。具体操做时，咱们经过如下简单的3个步骤来开展缺陷年龄分析活动。

6.4.1 肯定缺陷的缺陷年龄

若是你的项目有缺陷的管理工具（如bugzilla），能够增长缺陷年龄的选项。在开发修复缺陷的时候，能够对缺陷年龄进行选择。

若是没有缺陷管理工具也没有关系，你可使用相似表6-12的形式来肯定缺陷年龄。

表12　缺陷年龄肯定方法

6.4.2 统计出各种缺陷年龄的数量，绘制缺陷年龄分析图

表13　缺陷年龄的数量

图11　缺陷年龄分析图

6.4.3 进行缺陷年龄分析

咱们在进行缺陷年龄分析以前，须要先理解一下理想的缺陷年龄应该具备怎样的特色。

1）理想的缺陷年龄分析图

理想的缺陷年龄分析图应该是以下这样的。

（1）在缺陷的引入阶段就能及时发现该类缺陷，缺陷不会逃逸到下个阶段，如图12所示：

图12　引入阶段

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

咱们已经了解到测试不该该想到哪里就测到哪里，而应该进行分层测试：在每一个测试分层围绕不一样的测试目标，使用不一样的测试方法来进行测试。

（2）在特定的测试分层发现该层的问题，如图13所示。

图13　发现特定测试分层问题

对其余几类缺陷年龄，咱们的指望是：

• 没有继承或历史遗留引入的缺陷。
• 没有新需求或变动引入的缺陷。
• 没有缺陷修改引入的缺陷。

2）没有在特定的测试层次发现该层的缺陷

例如，在集成测试阶段，咱们但愿发如今编码阶段和设计阶段引入的缺陷，但实际上却发现了大量的在需求阶段引入的缺陷。这说明：

• 产品需求的质量不高，需求存在不清晰或错误的状况。
• 系统架构设计的质量不高。
• 需求质量不高，产品功能的质量也不会过高。
• 系统架构设计的质量不高，产品在非功能属性方面的质量也不会过高。

这就须要测试或整个研发团队来有针对性地进行改进。例如：

• 对需求再次进行检测，确保还没有集成的功能对应的需求的正确性。
• 分析架构设计中的问题，找出对非功能属性方面的主要影响，调整测试策略，尽可能提早并加大这些内容的测试力度。
• 调整测试策略，增长相关功能的测试力度和回归测试的规模。

3）继承或历史遗留引入的缺陷过多

当咱们发现测试中出现了不少由于继承或历史遗留引入的缺陷时，这就说明产品还存在一些“旧帐”还没有清理，这时咱们须要：

• 进行或从新进行老功能分析（详见6.7.2节），更新测试策略。
• 对这些缺陷进行分析，由此更新测试策略，进行探索式测试。
• 若是被继承的版本处于维护阶段，考虑这些缺陷是否须要在维护版本中解决，并发布补丁或升级包。
• 确认被继承的版本在维护阶段发现的其余缺陷，是否须要同步到当前新版本中。

图14清理“旧帐”

4）新需求或变动引入的缺陷过多

5）缺陷修改引入的缺陷过多

6.5　缺陷触发因素分析

缺陷的触发因素就是测试者发现缺陷的测试方法。缺陷触发因素分析，就是对测试中使用的测试方法进行分析。

对缺陷触发因素进行分析，可以帮助咱们确认产品测试是否已经进行得足够全面和深刻

和缺陷年龄分析方法相似，咱们也能够经过下面3个步骤来进行缺陷触发因素分析。

6.5.1 肯定缺陷的测试方法和测试类型

若是你的项目有缺陷的管理工具（如bugzilla），能够增长测试方法和测试类型的选项，在测试发现缺陷的时候来记录相关的信息。

果没有缺陷管理工具也没有关系，你可使用相似表6-14的形式，来肯定该缺陷的测试方法和测试类型。

表14 肯定缺陷测试方法和测试类型

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

图15　缺陷触发因素分析图

6.5.3 进行缺陷触发因素分析

在理想状况下，咱们但愿作出的缺陷触发因素图和测试策略是吻合的。例如，当前版本咱们的测试策略是：

对功能首先进行配置的遍历测试，须要保证新提交的命令行和之前已有的Web页面功能具备一致性；再进行基本功能测试，可以覆盖业务流程的基本路径；最后进行满规格的测试。

若是咱们持续对产品进行缺陷触发因素分析，参考历史数据，结合自身的经验，咱们还能够获得“不一样的测试方法发现缺陷的大体比值和分布”。固然，这个比值可能不是很准，可是也能够做为软件测试架构师对数据进行分析时的参考。

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

表15　产品质量评估表

7　风险分析技术

---

 返回

咱们将风险分析技术用在保证测试策略的顺利进行和基于风险来增强或下降测试投入上，涉及的主要技术为风险识别、风险评估、风险应对和老功能分析。

7.1　风险分析

此处咱们讨论的风险分析的对象是测试策略，目标是提早识别那些可能会阻塞测试策略顺利进行的问题，包括风险识别和风险评估两个部分。

7.1.1.风险识别

图16 风险识别的方法

举例：对测试设计进行风险识别

Step1：首先分析测试设计须要关注哪些内容。例如：

• 须要对某个重要的特性进行深刻的测试，须要可以经过路径分析法来对开发人员的设计流程进行全面的覆盖，不遗漏基本的流程。
• 须要可以经过功能交互分析对功能间的相互做用进行深刻的测试。
• 须要可以进行压力、稳定性和性能方面的测试。

Step2：分析上述内容都可以保质保量顺利地进行，须要哪些条件。例如：

• 条件1：开发可以提供相关的设计材料（如相关的概要设计文档），而且可以保证材料的内容是正确的。
• 条件2：有条件或者有机制可以保证开发人员和测试人员之间的有效沟通。
• 条件3：测试人员对产品的使用场景、多个特性都有必定的理解，可以进行全面的功能交互分析。
• 条件4：测试人员可以理解并掌握压力、稳定性和性能方面的测试方法，有能力结合测试方法和产品实现来进行测试设计。

Step3：逐一分析这些条件是否可以知足。假如条件1和条件4可能没法知足，那么识别出来的风险点就是：

• 风险1：开发可能会缺失重要的设计文档，或者一些设计文档更新不及时。
• 风险2：测试人员对压力、稳定性和性能方面的测试方法掌握不足，可能会出现测试设计遗漏。

须要特别说明的是，虽然此处咱们进行风险分析的对象是测试策略，围绕测试活动可否正常展开，但并不等于咱们只在测试内部识别风险点——咱们依然要从整个项目的角度来进行风险识别。咱们可使用表6-16风险识别清单，来帮助咱们进行风险识别。

表16　风险识别清单 

 

7.1.2 风险评估

风险评估的目标就是肯定风险优先级。

1）风险优先级正交表

表17 风险优先级正交表

7.2　风险应对

表18 常见风险及应对思路

7.3　老功能分析

7.3.1 差别性分析

差别性分析是指找出老功能在新版本和老版本上的差别。这些差别包括需求、设计、平台、实现等各类差别。

7.3.2 历史测试状况分析

历史测试状况分析是对老功能在老版本中的测试状况（包括测试策略、测试用例、缺陷）进行分析，以此来肯定老功能在新版本中须要采用怎样的测试策略。

1）确认老功能在新版本和老版本中的质量要求是否一致

2）进行测试方法分析

表19　分析角度

3）进行缺陷分析

表20　老功能历史缺陷分析点

4）对“组织和人”进行分析

表21　测试团队分析

8　分层测试技术

---

 返回

咱们将分层测试运用在测试目标的SMART化上和测试活动的安排上。

对V模型而言，每一个测试分层测试图测试的重点为：

8.1　V模型

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

8.2　设计测试层次

1.某通讯公司的测试分层

 

图17　某通讯公司的测试分层

和V模型相比，集成测试在本例中被分红了MST和BBIT；系统测试被分红了SDV、SIT和SVT。

• 模块级系统测试（MST）：保证软件开发项目组各个单元/模块之间的接口正确，以及对项目组级别的功能进行验证。
• Building Block Integrated Test（BBIT）：验证的是子系统之间的单元/模块的接口的正确性，也就是咱们常说的开发“联调”。
• 系统设计确认（SDV）：从系统的角度来验证功能的正确性。
• 系统集成测试（SIT）：从系统的角度来验证功能交互和非功能方面的正确性。
• 系统验证测试（SVT）：验证场景、解决方案的正确性。

为何此处的“测试分层”要这么复杂呢？这是由于在这个例子中，被测对象是通讯产品。咱们知道，通讯产品须要包含硬件、驱动和软件，业务也比较复杂，还会涉及不少协议和规范。在设计上经常会包含多个子系统，涉及不少接口。用户不只关注功能，还特别关注可靠性、性能等方面的质量，对产品质量总体要求很高。

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

图18 某公司在敏捷环境下的测试分层

和前面的介绍的测试分层相比，本例就显得简单多了：

• 单元测试（UT test）：针对代码或者组件的测试。
• 功能测试（function test）：针对产品功能方面的测试。
• 非功能测试（non-functional test）：指非功能方面的其余质量属性的测试。
• 探索测试（Explore test）：基于任务的测试。

这时被测对象是一个纯软件产品，根据用户的业务需求进行迭代开发，但整体来讲并不复杂，基本不涉及协议或规范。用户比较关注功能、易用性和性能，对可靠性方面的问题有必定的容忍性，总的来讲对质量的总体要求并不算过高，但愿产品可以快速交付。

在这样的背景下，快速评估产品是否可以发布，进行快速测试是有必要的。若是咱们仍是按照V模型中的测试分层来进行测试，就显得过重了。在这个测试分层中，咱们在单元测试层中测试代码、接口的质量；提交给测试后，在功能测试层中集中测试功能；待功能相对稳定后，在非功能测试层中再集中易用性、性能和可靠性等方面的内容；在探索测试层，再结合缺陷，进行补充测试和回归测试。