分析现象发现问题
看到这些现象，我们就会问：真正的问题是什么？通常地，图表本身只能提供一些现象和事实，并不能告诉我们问题是什么。具体问题的分析还需要借助很多要素和信息。如从现象 1（模块 4 的缺陷总数最多，模块 1 的最少）本身来看，出现这种情况的相关因素有很多：
从模块本身的角度考虑，与模块本身逻辑复杂程度相关；
从开发角度考虑，与模块开发质量，开发人员对需求的熟悉程度相关；
从测试角度考虑，与测试覆盖率，测试人员经验等相关；
从项目管理角度考虑，与开发测试周期长短，资源多少，环境等因素相关。
这就需要结合项目的其他信息，挖掘问题的根源，才能透过现象看到本质。
假设通过对上述元素的相关信息的调研，我们得出下表的分析结果：
| 模块 1 | 模块 2 | |
| 模块逻辑复杂程度 | 简单 | 复杂 |
| 模块开发质量 | 高 | 中等 |
| 开发人员对需求的熟悉程度 | 熟悉 | 一般 |
| 测试覆盖率 | 高 | 较高 |
| 测试人员经验 | 丰富 | 丰富 |
| 开发测试周期长短 | 短 | 长 |
| 开发测试资源 | 充足 | 不充足 |
| …… |
根据上表所示，度量人员就能分析出两模块缺陷数量差异的原因，分析结果也能在一定程度上为处于项目不同角色的人员提供改进过程的依据。
缺陷趋势图
解读图表
以第二章的第三节创建的缺陷趋势图表 (Defect Submit/Resolve Rate Daily) 为例，如图 9，图中折线的个数是状态和测试类型迭代属性值的乘积。从图例可看出，定义状态是所选择的值：提交（submitted）和已解决（resolved）；测试类型（Test type）有三种值：FVT，SVT 和 Accessibility。因此折线的个数是 6。图中蓝色折线表示在指定时间段内，功能测试中每天缺陷的提交数量。
列举现象
通过解读图中蓝色折线，我们就能够发现很多现象，如：
现象 1：缺陷提交的数量在 12 月底，1 月上旬某天，2 月上旬某天出现峰值
现象 2：1 月中旬到 2 月下旬这段时间所有类型的缺陷提交数和解决数都趋于零。
……
分析现象发现问题
针对现象 1，我们可以根据追溯缺陷个数峰值出现当天（12 月 31 日）的历史事件，去解析软件过程度量软件质量。假如通过查找项目日志等发现 12 月 31 日，是第一个用于功能测试的 build 产生。通过查询和总结当天提交的缺陷，发现大部分缺陷都是关于模块 A 的，那么我们就可以将问题定位于这个 build 的模块 A。
针对现象 2，通过追溯项目日志，发现这段时间是春节假期，因此缺陷提交数和解决数都趋于零。
提供指导
根据上述两个现象的问题定位，我们可以提出以下问题并给出建议：
作为开发人员，需要专注在哪里？
当某个 build 产生前，需要更加有效的验证测试。
对于模块 A，也许需要总结一下出现大量缺陷的原因，再进行其他模块的设计和开发作为经验参考。
作为测试人员，需要专注在哪里？
尽可能在较长的假期前验证所有缺陷，以提高测试用例的通过率，加快项目进度，并尽早发现问题和解决问题。
缺陷状态跟踪图
解读图表
以第二章的第三节创建的缺陷状态跟踪图表 (Defect Opened Rate Tracking) 为例，如图 12。
此图表中，横坐标为 0-1 的柱状图表示处于打开状态持续时间在 1 周以内的缺陷个数。不同的颜色表示不同的测试类型（TestType）。
列举现象
通过解读图表，我们就能够发现如下现象：
现象 1：处于打开状态持续时间在 1 周以内的缺陷个数最多
现象 2：测试类型为 Prod 的缺陷处于打开状态持续时间最长。
……
分析现象发现问题
针对现象 1 和现象 2，我们可以判断出来 FVT 阶段的缺陷处理和解决的速度是较快的；而 Prod 测试的缺陷则解决时间较长。
如果迭代的属性是模块，那么我们也可以分析出来哪些模块的缺陷解决速度较快，哪些较慢。
对于这些解决速度较慢的缺陷，我们就能有针对性地进一步分析其原因，根据原因提出解决方案以便于在今后的项目中避免类似问题的发生。
  |
|
结束语
本文主要介绍了应用 IBM Rational ClearQuest 生成缺陷数据图表的步骤和应用典型的缺陷图表对测试过程进行度量的基本方法。通过基于不同缺陷图表所反映出来的各类趋势和现象进行分析总结，挖掘可能引起这些趋势和现象的原因，结合项目执行的实际情况剖析问题的根源，可以使项目组及管理人员获得正确的信息来改进测试过程，减少研发、测试中的重复工作和预测项目风险。
文章来源于领测软件测试网 https://www.ltesting.net/
