测试架构师：6 版本测试策略和产品质量评估

测试架构师：6 版本测试策略和产品质量评估

2016-09-26

 

目录

1　开始
2　第一个版本测试策略
  2.1　测试范围以及和计划相比的偏差
  2.2　本版本的测试目标
  2.3　需要重点关注的内容
  2.4　测试用例的选择
  2.5　测试执行顺序
  2.6　试探性的测试策略——需要大家分工合作的地方
  2.7　接收测试策略
  2.8　回顾
3　跟踪测试执行
  3.1　跟踪测试用例执行情况
  3.2　每日缺陷跟踪
  3.3　调整测试策略
4　版本质量评估
  4.1　使用软件产品质量评估模型来进行质量评估
  4.2　版本质量评估中的缺陷分析
  4.3　调整测试策略
  4.4　建立特性版本质量档案
5　后面的版本测试策略
  5.1　回归测试策略
  5.2　探索式测试策略
6　阶段质量评估（包括发布质量评估）
  6.1　阶段质量评估项目
  6.2　非测试用例发现缺陷的原因分析
  6.3　组合缺陷分析
  6.4　遗留缺陷分析
  6.5　临近发布时的缺陷修复策略
  6.6　非必然重现bug的处理
  6.7　总结

 

从现在开始，我们的项目开始进入到测试执行阶段，我们的软件测试架构师也要开始进入到测试执行策略的工作中了，如图1所示。

图1　制定测试执行策略

1　开始

---

 返回

此时软件测试架构师手上应该有一份“版本计划”和“测试计划”（分别由开发人员和测试人员输出）。

具体来说，此时开发人员提供的“版本计划”应该是针对集成开发阶段的功能集成计划，包括划分了几个build、每个build计划合入哪些功能，以及每个build需要开发集成的时间。

“测试计划”是一个在集成测试、系统测试和验收测试分别需要测试多少个版本，以及每个版本包含的测试时间的计划，见表8-1。

表1　测试计划表

“测试计划”中也有简单的测试策略，主要用于标记每个版本的主要测试目标。

我们将“版本计划”和“测试计划”合并在一起，就得到了我们的研发计划全景图，如图2所示。

图2　研发计划全景图

总的来说，软件测试架构师在测试阶段的工作，其实就是围绕图3所示的几个活动循环展开的。

图3　软件测试架构师在测试阶段的工作

并且在每个测试分层结束的时候，软件测试架构师需要评估这个测试层级的质量目标是否达到，是否可以进入下一个层级的测试。在项目结束的时候，评估产品能否发布。

2　第一个版本测试策略

---

 返回

现在软件测试架构师要开始制定第一个版本测试策略了。由于测试策略是用来指导该如何进行测试执行的，测试策略的内容会很细、很具体。但是我们依然可以按照四步测试策略制定法中目标—风险—流程—顺序的思路来制定版本测试策略。

2.1　测试范围以及和计划相比的偏差

在版本测试策略中，软件测试架构师首先要明确的就是测试范围。需要注意的是，这里的测试范围，不是指开发计划要合入哪些功能，而是指开发能够真正提交，并且测试可测的功能。

我们还是以俄罗斯方块心项目的build1为例，如图4所示

图4　俄罗斯方块心项目的build1

假设在俄罗斯方块心项目的build1中，软件测试架构师通过评估，接收进行测试，他可以在版本测试策略中按图5所示这样描述版本的测试范围和偏差。

图5　版本的测试范围和偏差

2.2　本版本的测试目标

每一个版本测试策略都需要描述版本的测试目标。

对和进行功能测试，发现单运行正常值和边界值方面的缺陷。

对（本轮测试实际提交的是）只进行基本功能的验证，能够保证与和的集成测试就可以。
·对进行测试，发现、和在多运行方面的缺陷。

以测试对象–测试方法–测试结果这样的方式来描述测试目标的好处是：强调了这个版本测试的要求，比数字指标更易于被测试团队理解和执行。

2.3　需要重点关注的内容

软件测试架构师需要在每个版本测试策略中注明哪些是需要大家重点关注的内容。

• 首先，在版本测试策略中，需要对提交的功能进行分析，提出需要测试团队重点关注的内容。
• 其次，需要确定本版本需要测试的功能的优先级表。

我们在制定总体测试策略的时候，已经根据质量目标和风险为产品的所有功能特性确定了测试优先级。但是到了实际测试执行的时候，特别是在功能集成开发阶段，一些功能特性可能会被开发人员分为几次提交，这就需要软件测试架构师根据版本的实际情况更新功能特性的优先级，并在版本测试策略中向测试团队说明。

例如，在“俄罗斯方块心”项目的总体测试策略中功能特性的优先级列表见表2（为了便于后文叙述，我在列表中加入了“计划提交版本”列）。

表2　功能特性的优先级列表

在版本测试策略中，由于build1中的功能，实际提交的是，我们在build1中仅对它进行基本功能的验证测试，因此在build1中我们可以考虑降低的测试优先级。

2.4　测试用例的选择

我们把测试用例分等级（level1~level？4）后，选择测试用例就变得简单多了。软件测试架构师可以根据版本的测试范围和测试目标，制定出需要选择哪些测试用例的策略，如表3所示。

表3　选择测试用例

2.5　测试执行顺序

不同的被测对象，在同一个版本中的测试执行顺序可能会不同。这就要求软件测试架构师，对不同的被测对象当前的质量情况，有比较好的把握能力，然后根据质量情况来确定不同的测试执行顺序，可以遵循如下原则：

• 质量情况越好，就可以考虑将更多的测试方法组合起来执行。
• 对刚提交的功能，在质量情况不好或质量情况不明的情况下，不建议使用组合测试方法进行测试。

来看一个相关的示例，见表4。

表4　确定测试执行顺序示例

除此之外，在版本执行策略中再强调一下阶段测试策略中的测试执行策略也是有必要的：

• 先执行高优先级特性的测试用例，再执行中、低优先级的测试用例。
• 先执行复杂的、难的测试用例，再执行简单的测试用例。

2.6　试探性的测试策略——需要大家分工合作的地方

2.7　接收测试策略

“接收测试”是指开发人员将版本转给测试人员时（图6），测试人员先对这个版本进行一次测试，确认版本没有阻塞测试的问题，能够按照测试策略完成测试。

图6 版本转给测试人员

接收测试有两种结果：“通过”和“不通过”。判断阶段测试是否通过的标准只有一个，就是“是否会阻塞后面的测试”。

• 接收测试“通过”意味着测试能够继续进行，
• 而接收测试“不通过”，并非意味着一定不能继续测试——我们需要考虑是否有规避问题的方法。如果存在规避方法，还是建议继续测试。

具体如图7所示。

图7　接收测试示意图

2.8　回顾

到目前为止，我们已完成了第一个版本测试策略的制定。让我们一起来回顾一下，在版本测试策略中需要考虑的主要内容：

• 测试范围和计划相比的偏差。
• 本版本的测试目标。
• 需要重点关注的内容。
• 测试用例的选择。
• 测试执行顺序。
• 试探性的测试策略。
• 接收测试策略。

3　跟踪测试执行

---

 返回

软件测试架构师跟踪测试执行的目的有3个：

• 确保测试团队是按照测试策略来执行测试的。
• 实时关注缺陷，通过缺陷分析来确认测试策略是否合适，是否需要调整。
• 关注项目中的实时风险，基于风险来调整测试策略。

3.1　跟踪测试用例执行情况

在版本测试时，很多人都会关注测试用例的执行情况，如测试经理、项目经理等。测试用例的进度、测试用例的结果（包括测试用例执行的通过率、失败率等）是他们主要关注的内容，我们可以使用表5~表6所示来收集和展示这些信息。

表5　按照每个版本统计的测试用例的执行情况表

表6 当前项目的整体进度表

这些表中的信息对软件测试架构师而言同样重要。要确保测试团队是按照测试策略来执行测试的，需要保证以下三点：

• 测试内容和测试策略中确定的范围、深度和广度一致。
• 测试执行的顺序和测试策略一致。
• 计划测试的内容能够被顺利执行。

只要我们选择的测试用例和测试策略是一致的，就能保证第一点。对软件测试架构师来说，需要在测试执行时保证第二点和第三点。显然这方面的信息并不能从表中的内容来直接获得，还需要软件测试架构师对表中的内容再进行一些分析和加工。

1.测试团队的测试执行顺序是否和测试策略相符

软件测试架构师可以通过按照每个版本统计的测试用例的执行情况表和测试用例执行情况详表来分析测试团队的测试执行顺序是否和测试策略相符。

1）测试团队是否按照特性的优先级顺序来执行测试用例

2）测试团队是否按照测试策略中的测试方法、测试顺序来执行测试用例

2.被阻塞的测试用例

3.2　每日缺陷跟踪

“缺陷”是测试的结果。对软件测试架构师而言，每天跟踪缺陷非常重要——因为他需要实时关注测试中的这几个问题：

• 缺陷的趋势是否正常？
• 是否存在因为缺陷修改引入的缺陷？
• 在本版本中必须解决哪些缺陷？
• 在本版本中需要解决哪些缺陷？

1.哪些缺陷必须在本版本中解决

在版本测试中，判断“哪些缺陷必须在本版本中解决”的标准只有一个，就是“会不会对后续的测试造成阻塞”。

2.哪些缺陷需要在本版本中解决

图8　几个概念之间的关系

换句话说，除了那些在版本中必须解决的缺陷外，我们还需要根据缺陷的严重性和缺陷的修改情况来选择一些缺陷，在本版本中优先解决：

• 缺陷的改动越大，越需要尽早解决。
• 如果缺陷涉及需求、方案、设计，需要尽早解决。
• 优先解决缺陷严重程度为“致命”和“严重”的缺陷。

3.缺陷趋势是否正常

1）预估“拐点”会在哪个版本出现

图9 预估缺陷趋势图

分析：

• 在集成开发和测试阶段，build1~build4都会有新的功能合入，而且随着功能的不断集成，系统越来越完整和复杂，测试方法也会从单功能测试，逐步转换为单功能+多功能测试，所以在build1~build4阶段，不应该出现拐点。
• build5是一个回归测试版本，此时没有合入新的功能，测试方法和build1~build4相比，也没有发生变化，所以集成开发和测试阶段的拐点（图9中的“拐点1”）应该出现在build5比较合适。
• 在系统测试阶段，ST1虽然也是功能测试，被测对象也没有发生变化，但是ST1在测试执行顺序、功能测试的复杂度上都会与集成开发和测试阶段有所不同，所以进入ST1阶段应该会比较快速地出现一个拐点（图9中的“拐点2”），开始又能大量发现系统的问题。
• ST2的测试方法和ST1的测试方法不同，不应该出现拐点。
• ST3和ST4都是探索式测试和回归测试，下一个拐点（图9中的“拐点3”）应该出现在ST3后期或者ST4初期比较合适。
• 进入验收测试阶段后，由于AT1的测试方法发生了变化，应该很快会出现一个新拐点（图9中的“拐点4”），但是这种缺陷上升的趋势不应该持续太久（毕竟我们已经经过了大量的测试，如果在验收测试阶段还能发现大量的问题，是非常不符合预期的），在AT1后期或在AT2前期就应该出现拐点（图9中的“拐点5”）。

2）判断当前版本的缺陷趋势是否正常

4.是否存在缺陷修改引入缺陷的问题

3.3　调整测试策略

图10 调整测试策略的整体思路

4　版本质量评估

---

 返回

4.1　使用软件产品质量评估模型来进行质量评估

但由于版本质量评估的评估对象是版本，我们的评估方法和关注重点还是会与阶段的质量评估或发布时的质量评估有所不同。

图11 复制质量评估模型

1.在版本质量评估中记录需求和实现的偏差

图12　功能有偏差的情况

我们往往会发现，除了这些在测试之前就能发现的偏差之外，还有很多偏差是在测试过程才能逐渐被发现的，如：

（1）需求理解方的错误导致功能实现上的错误。如图13所示。

图13 功能实现错误

（2）因为种种原因，该功能对应的需求并没有提交完，如图14所示。

图14　需求未提交完

无论是上述哪种情况，这些问题都只有在测试过程中才会被逐渐发现。这些问题在测试过程当做bug记录。这些缺陷往往由于不是当前版最紧急、必须解决的缺陷，而很容易被搁置下来，然后就被大家遗忘了。直到这些问题变得严重影响后续功能的集成，或是到了产品要发布的时候，我们才发现一些看起来“细枝末节”的功能模块还没有被开发。

因此，对软件测试架构师而言，在版本质量评估时对这类问题再进行梳理是非常有必要的。我们就只需要将这类问题从bug报告中筛选出来，并定期跟踪这些bug，关注它们的修复计划就可以了。对那些开发人员和测试人员争议较大、需要SE再进行澄清的需求，我们也需要进行记录（至少需要记录当前的进展），以便我们在结论确定后，第一时间知道该如何进行下一步的处理。
总的来说，在版本质量评估时，需求实现情况应该包含的内容如图15所示。

图15 需求实现情况包含的内容

举例：“俄罗斯方块心”项目build1版本质量评估示例

在“俄罗斯方块心”build1中，需求和功能实现的偏差为：

（1）功能在build1提交时为,完整的功能将在build2中提交。
（2）功能的需求未完全开发完，详见bug00032、bug00035。
（3）开发人员和测试人员对的需求实现存在争议（开发人员实际开发的功能为），经过SE对此功能需求进行再次澄清后，发现是开发人员在需求理解上存在一些误解，需要在build2中更新此功能，详见bug00047。

2.在版本质量评估中进行测试过程评估

实际上，我们在跟踪测试执行的过程中，已经对测试过程，包括测试用例、测试方法和测试投入进行了跟踪分析，在版本质量评估时，我们可以对版本的“测试过程”再进行回顾，总结经验教训。除此之外，在版本质量评估中，还有一项重要工作，就是对多个版本的测试用例执行情况进行分析。整个测试过程分析如图8-30所示。

图16　测试过程分析 

1）测试用例的通过率

在版本质量评估时，我们可以对测试用例首次执行通过率、累积执行通过率和累积执行率进行统计，见表8-21。

表7　测试用例通过率统计结果

质量指标是否有效，和我们在何时进行评估、评估对象的粒度、评估的目的息息相关。如果我们只是在版本发布的时候、在系统的层面来统计各种质量指标，据此给出产品能否发布的结论，确实不能让人信服。但如果我们能够在每个版本都统计相关的质量指标，评估对象的粒度也细化到功能特性，将“质量指标”作为“质量之尺”，让大家知道我们当前的质量离我们的目标还有多远，我们还需要做怎样努力，进行怎样调整，才能达到我们最终的质量目标，这样进行质量评估，才真正有用，并且能够被大家信服。

2）测试用例在多个版本中的测试结果

我们在进行测试用例累积通过率的统计时，并不能只关注50%、70%这样的统计数字，还需要注意分析测试用例在多个版本中的测试结果。

表8 测试用例在多个版本中的测试结果

我们对每个build的测试策略说明如下：

• 在build1中，我们的测试策略为执行“测试用例1”~“测试用例4”，不执行“测试用例5”和“测试用例6”。
• 在build2中，我们的测试策略为执行build1中测试结果为“失败”和“不执行”的测试用例，选择了“测试用例3”~“测试用例6”。
• 在build3中，我们的测试策略为执行build1和build2中测试结果为“失败”和“不执行”的测试用例，选择“测试用例3”和“测试用例5”。另外，我们还选择部分测试结果为“通过”的测试用例来进行“功能回归测试”，因此选择了“测试用例4”。

测试用例4”的测试结果，在build2中为“通过”，在build3中为“失败”，出现了反复。是什么原因导致测试用例的执行结果出现了反复？

比较常见的原因有新功能的合入对旧功能造成了影响或缺陷修改引入。

对这两种情况，软件测试架构师都可以从“开发修改”和“功能交互”的角度来有针对性地选择测试范围，由此来确定build4的回归测试策略：对已经执行“通过”的“测试用例1”“测试用例2”和“测试用例6”，在build4中是否需要再进行回归测试。

3.在版本质量评估中进行缺陷分析

4.2　版本质量评估中的缺陷分析

每日缺陷跟踪没有分析过的内容包括缺陷密度、缺陷年龄（在每日缺陷跟踪中只关注了缺陷修改引入方面）和缺陷触发因素分析。

软件测试架构师在版本质量评估中进行缺陷分析，需要重点关注如下几个问题：

• 功能特性的缺陷密度是否正常？
• 缺陷年龄分析是否正常？
• 缺陷触发因素分析是否正常？

4.3　调整测试策略

图17　增加版本质量评估

4.4　建立特性版本质量档案

一个产品可能会有很多功能特性，对软件测试架构师而言，可能无法保证对每个功能特性都按照上述过程进行质量评估。所以对一个测试团队而言，各个测试负责人一起来建立一个特性版本质量档案，在档案中记录各个功能特性在每个版本中的质量情况，是一个不错的选择。

产品的特性版本质量档案，至少需要包含如下内容：

• 对当前测试覆盖度方面的记录，包括需求和实现的偏差。
• 对测试过程的分析和记录。
• 缺陷分析。

最后测试责任人还可以根据上面的情况，对产品功能特性当前的质量进行评估，评估其是否达到质量要求，以及和质量要求的主要差距在哪里，并据此总结出后续的测试建议。
在实际操作时，测试责任人可以直接在之前制定的总体测试策略的基础之上来建立特性版本质量档案，见表9。

表9 特性版本质量档案

5　后面的版本测试策略

---

 返回

到目前为止，我们的软件测试架构师已经完成了制定测试策略—跟踪测试执行—质量评估这样的一个完整循环。但是测试项目还没有结束，紧接着我们又会进入到下一个循环。

和第一个版本相比，后面的版本会考虑到实际的产品研发情况和测试情况，而对测试策略进行调整，因此，后面版本的测试策略除了考虑我们在8.2.8节中总结的内容外，还需要增加回归测试策略和探索式测试策略的内容——本章我们将来详细讨论需要如何制定它们。

5.1　回归测试策略

回归测试是一种“确认”性质的测试，测试目标有：

• 缺陷回归：确认测试中发现的缺陷被开发人员正确修复了。
• 功能回归：确认老功能不会因为新合入的功能而失效。
• 阶段回归：确认产品当前的质量达到该阶段的质量目标。

在项目不同的阶段，回归测试的目标会有所侧重，以“俄罗斯方块心”项目为例，回归测试在不同阶段的重点如图18所示。

图18 回归测试的重点

说明：

• 在集成开发和测试阶段，由于功能还会不断地添加进来，所以此时回归测试的重点为“缺陷回归”和“功能回归”。
• 在系统测试阶段，这时已经不会再添加新的功能了，所以回归测试的重点为“缺陷回归”。
• 在每个阶段结束的时候，会产生一个专门的回归测试版本，我们会在这个版本中对这个测试阶段进行整体的回归，确认是否达到该阶段的目标。

1.缺陷验证策略

我们将缺陷按照功能和非功能、是否有“用户可见的输入输出接口”分为三类，如图19所示。

 图19 缺陷的三类

较难于验证的是那些“底层或中间层类的缺陷”。由于它们位于系统的底层或中间层，很多功能都可能会调用它们，修改它们往往会影响较多的功能，还可能会影响系统的性能、可靠性等非功能。对这类问题，可以使用如下策略：

• 控制这类缺陷在设计修改和编码上的质量。例如，要求开发人员对修改方案进行讨论和评审，对修改代码进行走读，等等。
• 软件测试架构师（或由软件测试架构师指定专门人员）根据缺陷的修改方案来确定需要进行回归测试的内容

2.功能回归策略

• 1）新开发功能在合入版本后的回归测试
• 2）老功能回归测试

3.阶段回归策略

表10 不同阶段回归测试用例选择

 

5.2　探索式测试策略

1.将探索式测试和传统式测试结合起来

图20　“俄罗斯方块心”项目的测试

这个策略最大的坏处是缺陷可能会在探索测试阶段再集中爆发一次，使得缺陷迟迟不能收敛，造成测试项目延期。

图21　探索式测试

这个策略探索式测试会使得集成测试阶段变长。

图22　与图21相比的结果

2.探索式测试方法的选择策略

在4.5节中为大家介绍了很多探索式测试方法。我们可以大致按照如下顺序来选择探索式测试方法：

• 在集成测试时，先使用商业区测试法和娱乐区测试法，再使用历史区测试法和破旧区测试法。
• 在系统测试时，先使用历史区测试法和破旧区测试法，再使用商业区测试法和娱乐区测试法，最后使用旅馆区测试法和旅游区测试法。

3.探索式测试策略在版本测试策略中

图23　流程图

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

---

 返回

6.1　阶段质量评估项目

从前面的章节可以得知我们在跟踪测试执行和版本质量评估中一直在进行质量评估。这使得质量评估从一个阶段性的测试活动（很多测试团队可能只在版本快要发布的时候才开始进行质量评估），变成了每天、每个版本都在进行的活动，一旦发现了质量问题，就能在过程中实时调整测试策略，使得最后产品能够达到发布的质量目标。

虽然跟踪测试执行、版本质量评估和阶段质量评估都是根据质量评估模型在进行质量评估，但是它们各自的侧重点还是有所不同的。

• 跟踪测试执行关注测试过程，通过过程来保证质量，是使我们最终能够达到测试目标的基础。评估项目也主要是一些定性的分析。
• 版本质量评估关注的是每个版本的质量是否符合预期。评估项目包含定性分析和定量指标，但定性分析偏多。
• 阶段质量评估关注的是每个阶段的质量目标是否完成。评估项目包含定性分析和定量指标，但主要是定量指标。

表11　质量评估项目总结

1.确认总体测试策略中的质量目标是否完成

一个思路是，将质量目标划分为重要的、必须达成的质量目标和一般性的质量目标（后文我们统一称那些重要的、必须达成的质量目标为质量红线）。

2.重要的质量目标（质量红线）

表12 某产品质量红线

3.对未达到的一般性质量目标制订应对措施

• 1）非测试用例发现缺陷的原因分析
• 2）缺陷分析

4.遗留缺陷分析

6.2　非测试用例发现缺陷的原因分析

表13 分类参考

表14 测试团队分析参考模板

6.3　组合缺陷分析

 

图24 评估结果的决定

6.4　遗留缺陷分析

1. 缺陷对用户的影响程度
2. 缺陷发生的概率
3. 缺陷风险评估和规避措施
4. 不能遗留的缺陷

原则上，满足下述条件的缺陷不应该成为遗留缺陷：

• “致命”缺陷不应该作为遗留缺陷。
• 没有“规避措施”的“严重缺陷”不应该遗留。

6.5　临近发布时的缺陷修复策略

我们在确定遗留缺陷的过程中，一方面，由于不同人员对缺陷遗留的标准可能会有差别，难免又会临时决定要修改合入一些缺陷。另一方面，越到临近发布的时候，越需要控制缺陷修复的数量。

6.6　非必然重现bug的处理

在进行遗留缺陷分析时，我们讨论了缺陷发生的概率，对那些非必然重现的bug（指“无规律重现”和“无法重现”的bug），也需要定期进行跟踪和处理。

软件测试架构师和测试经理、开发代表等在测试团队、开发团队中对非必然重现的问题达成共识：

• 测试人员发现非必然重现的bug，也需要提bug。但是需要特别做好问题的记录，并在问题出现的第一时间找开发人员定位。
• Bug复现不仅仅是测试人员的工作，开发人员和测试人员可以一起复现bug。
• 未复现的bug不应该随便关闭。

对最后一点，那些一直未能复现的bug，需要软件测试架构师定期将这些bug汇总，选择优先级高的缺陷，组织开发人员和测试人员专门投入到复现问题，如果经过这样的专门复现依然不能复现，可以降低问题的优先级，直到bug的优先级降至最低，该bug才可以关闭。

在项目前期，对非必然重现bug的跟踪周期可以稍长一些，越到项目后期，越要加强对非必然重现bug的跟踪、复现工作。

6.7　总结

图25 发布阶段