测试架构师：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）功能的需求未彻底开发完，详见bug0003二、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 发布阶段