测试过程改进的缺陷漏测分析(2)

图 -1 以一个虚拟产品的 Lotus Notes 漏测缺陷数据库作为示例。在本例中，对一个漏测缺陷采用三个标签项来跟踪其特征数据。第一个标签项用于描述缺陷的详细数据，这些数据来自于缺陷跟踪工具，它们从缺陷跟踪工具到漏测分析工具的输入和转换最好是自动完成。此外，还有一个较大的属性域用来描述缺陷的历史和概要，本图中没有显示出来该域。

图 -2

图 -2 演示的是 “ 开发分析 ” 标签项。针对开发过程，可以对漏测缺陷进行各种不同的分类。在本例中所示例的漏测缺陷被归类为 “ 设计评审过程 ” 遗漏。这个例子演示了对产品的开发过程变更创建 “ 概念评审 ” 的过程。 “ 捕获概率 ” 项用来评估变更实施后可能产生的效果，它能回答 “ 如果在开发过程中已经实施了该变更计划，这个缺陷被捕获到的可能性有多大？ ” ，对此本文将在后面的 “ 测量 ” 小节进行详细探讨。这个表格还设计了变更计划制订的预期日期项和实施该变更计划的预期日期项， Lotus Notes 系统会在该日期自动发送提示信息给变更计划的受理者。

图 -3

图 -3 演示的是 “ 测试分析 ” 标签项。在这里可以分析用户报告的缺陷是否真的是漏测，换句话说，确定测试过程中是否真的存在漏洞或者该缺陷是否真的值得解决。这是非常重要的。有一些用户发现问题的环境是非常特殊的或生僻的，还有些缺陷解决起来代价很大，并且很难被发现，漏测分析组需要确定是否有必要针对该漏测缺陷进行测试过程改进。如果发现问题的用户是非常重要的客户，并且该用户会经常使用该环境，那么即使发现问题的环境非常特殊，也需要改进测试环境，来尽量符合用户的使用环境。在上面的例子中，缺陷被归类到 “ 未执行的测试类型 ” ，该测试类型发生了漏测。在对数百个漏测缺陷进行统计分析后，如果发现 “ 未执行的测试类型 ” 比例很高，那么可能需要在整个开发过程中增加该类测试类型。这里 “ 捕获概率 ” 项和上面小节描述的含义一样。

11 测量

本节将给出关于测量的一些建议。首先，对于需要改进点，将给出能指导漏测分析组制订合适的改进计划的测量点；接下来，将给出一些评价漏测分析过程效果的方法。您可以采用其中部分或全部建议来建立自己的测量体系。

1 、测量驱动改进

将前面各分类数据和总数比较，得到各分类的比例。下面是一些例子：

图 -4 显示的是各代码模块（模块 A － Z ）漏测数占总的漏测数的比例。从该饼图上可以清楚地看出超过 50 ％的漏测来自于 B 、 C 、 D 、 E 四个模块，这个测量结果可以帮助漏测分析组决定是否对这四个模块的开发过程实施改进。

图 -4

图 -5

图 -5 分析了漏测缺陷对用户造成的不同影响，如业务中断、系统崩溃、或设备相关问题等。例如，如果 “ 影响 1” 是设备相关问题，那么被测软件所在的硬件平台可能需要进行改进；同样，如果蓝色部分是高严重等级的影响类型，那么可以看出漏测是高严重等级影响类型的具体比例是多少。

通过前面示例的数据库工具，还可以输出大量其他图表，上面所举的两个例子只是最常用的两种分析图。

2 、评价漏测分析效果

评价改进的效果需要有精确的数据和一致的分析报告，以下几个数据会被用到：

TFVUD 是用户发现缺陷数（ Total Field Valid Unique Defects ），即由用户发现的经过了确认的、非重复的、非用户错误操作的、非建议类型的所有缺陷；

PDD 是测试发现缺陷数（ Post Development Defects ），即在开发完成后的测试周期中发现的缺陷数，但它不包括那些向用户发布后发现的缺陷；

KLOC 表示千行代码。

利用上面数据可以得到以下分析数据：

TFVUD

-------------------

千行变更代码 & 新代码

应当在产品全生命周期中测量上面的值，用作一个版本和另一个版本在相同时间检查点上进行比较的评价指标。例如，一个季度中， 2.0 版本的该测量值应该比 1.0 版本低。进行该项测量的目的是减少单位代码规模中用户发现的的有效问题数。

PDD

-------------------

PDD+TFVUD

在产品全生命周期中同样应当测量上面的值，作为一个版本和另一个版本在相同时间检查点上进行比较的评价指标。例如，一个季度中， 2.0 版本的该测量值应该比 1.0 版本高。进行该项测量的目的是推动尽早地在开发过程中发现缺陷，从而降低缺陷的修复成本。

捕获概率

在数据库中有 “ 捕获概率 ” 的属性项（在前面小节进行了详细解释），这是对实施过程变更后防止同类问题再次漏测的效果的一项估计指标。该估计是计划预期效果的基础。通过对各变更的捕获概率取总后求平均，可以得到过程变更后的整体预期效果，这样就能对产品发布后用户问题数的降低程度进行合理的预期。

图 -6

上图中，模块 B 的开发过程的捕获概率为 35 ％，测试过程的捕获概率为 30 ％。如果开发过程在代码里产生了 100 个缺陷，那么根据捕获概率在开发阶段可能会发现 35 个缺陷，还有 65 个缺陷可能会遗漏到测试阶段，根据测试过程 30 ％的捕获概率，在测试阶段将可能发现 65*30 ％＝ 19.5 个缺陷，那么开发测试阶段总共大概能发现 55 个缺陷。这 55 ％的概率就是开发测试过程变更后的综合效果估计。用方程式表示上面的过程就是（ .35 ） +(1-.35)(.30) 或者 D+(1-D)(T) ，这里 D 是开发过程的捕获概率， T 是测试过程捕获概率。本图是基于代码模块的例子，其他分类也可以进行同样的评估工作，如下面图 7 。

图 -7

最后一步是通过对所有综合捕获概率取总后求平均，来预计有效用户缺陷数的减少。首先，选择一组和预期效果相关的重点漏测组。在本例中，假设重点漏测组包含 76 个漏测缺陷，如果针对这 76 个缺陷的综合捕获概率为 52.5% ，那么将能预防约 40 个缺陷漏测。假设一年的时间里会有 250 个漏测缺陷，前面 52.5% 的捕获概率是一个比较准的数据，那么将能预防 250 个漏测的 16 ％ ―― 约 40 个漏测缺陷，这是对下个版本将会减少的漏测数的最终预测，并且这是最小预测，因为我们只是对重点漏测组进行了预测，这对其他类型的问题可能不适用。如果我们没有作那样的假设，那么预测的漏测数的降低可能是不现实的 52.5% 。

12 总结

进行漏测缺陷分析的主要目的就是提高产品质量和用户满意度、降低修复用户发现缺陷的成本。这是通过推动尽可能在软件开发过程的早期发现缺陷来实现的。进行漏测分析活动的软件测试组将会帮助软件开发组改进质量，他们的测试过程将更加完善，测试环境也将更加符合用户实际环境。从漏测分析过程中收集的数据能为测试环境补充硬件等改进活动提供充分的理由。此外，漏测分析过程鼓励项目组间的交流和合作，开发更高质量的软件产品。它还能预测未来的漏测缺陷数，评价自身的效果，来证明所投入的资源是值得的。

查看本文来源