缺陷漏测分析：测试过程改进

•  漏测的定义

所谓漏测，是指软件产品的缺陷没有被测试组发现而遗漏到了用户那里，却最终被用户所发现。如果产品在用户那里出现问题，产生的后果是非常严重的。在软件开发过程中，缺陷越早被发现，发现和解决缺陷所花的成本就越小。如果缺陷是在测试组测试中发现的而不是被用户使用时发现的，那么所花的成本将小得多。如果缺陷是被开发组在开发过程中发现的，那么所花的代价将更小。因此，进行漏测分析、预防漏测、促使缺陷尽可能在开发过程的早期被发现，是非常有意义的，它有利于降低软件产品成本、提高软件产品质量。

•  漏测分析的目的

进行漏测分析的目的是为了促进软件质量和开发测试过程得到持续改进。具体来讲，就是通过分析开发和测试过程中漏测的缺陷，制定相应的预防措施以避免今后再发生类似的漏测。测试过程的持续改进将提高测试环境的效果和测试执行的效率、降低遗留到用户处的缺陷数和缺陷解决成本，从而提升软件的质量、声誉和销售。在软件产品开发过程中重视漏测分析并参与到漏测分析工作中的团队越多，漏测分析的效果就越好。如果开发和测试团队都重视漏测分析、并密切配合进行漏测分析工作的话，漏测分析将取得非常好的效果。

在实际工作中，漏测分析过程应该重点关注那些普遍、严重而解决成本高的问题。具体来讲，漏测分析的目标是：

•  对漏测进行分类以便于更进一步深入的分析

•  对分类数据进行统计

•  在统计分析的基础上进行全过程的标识和变更

•  在对一些特殊的漏测项进行分析的基础上，对过程的一些局部进行标识和变更

•  运用度量数据说明过程变更的效果

•  如何进行漏测分析

漏测分析活动可以参照下面的建议进行。在熟悉了漏测分析流程以后，需要确定进行漏测分析活动的频度。为了取得较好的效果，最好是遵照一个时间表来定期进行漏测分析活动，一个月进行一次是一个比较合适的频度。

•  计划

这个过程是针对多项目组联合进行漏测分析而设置的，在联合项目组中实行该过程最有效。如果不可能组建联合项目组进行漏测分析，也可以修改该过程只在测试组内部实行。

制订计划如果不确定关注点的话，这个计划将难以有效实施。漏测分析要想取得理想的效果，就需要计划好进行漏测分析活动的确切的人员数目、活动时间。 过程执行的效果完全取决于执行它的方式，如果不切切实实的做好计划，你的过程将不会得到太多的改进。

实际进行漏测分析活动时，只选择漏测分类的一部分子集进行分析，将有利于更有效的进行漏测分析工作。进行漏测分类前，需要在计划中确定选择哪部分子集进行分析。例如，如果漏测的严重度等级分为一到四级，一级严重度最高，四级严重度最低，那么也许只分析一、二级的漏测最合适，这样可以避免在那些对用户无关紧要的漏测缺陷上花太多的无用功；也可以只分析那些被关闭和修复了的漏测缺陷，因为如果分析那些没有被关闭和修复的缺陷，可能会漏掉一些至关重要的信息；另外，还可以在进行漏测分析之前排除掉重复缺陷和那些由于用户错误操作引起的缺陷，这样就只需要分析那些有效的漏测缺陷，它们才能真正提供开发和测试过程需要改进的信息。

•  漏测分类

接下来需要将所有的漏测缺陷按照有意义的属性进行分类，当然，前提条件是已经有了一个包含了所有漏测缺陷详细信息的漏测列表。然后需要确定哪些属性分类是对分析有用的。下面给出一些漏测缺陷的属性的例子：

•  漏测产生活动（最有可能发现该漏测缺陷的活动）

•  开发阶段（原始需求评审、概念评审、设计评审、代码检视、单元测试、模块联调、信息资料开发）

•  测试阶段（功能测试、系统测试、本地语言测试、设备驱动测试、安装测试、性能测试、异常测试）

•  产品模块（产生了漏测缺陷的代码模块）

•  模块 A 、 B 、 C 等

•  缺陷影响（对用户使用造成的影响）

•  系统崩溃、业务中止、数据完整性、命令失效、安装失败、设备 / 驱动、性能、文档、可用性等

•  引入版本（引入漏测缺陷的代码版本）

•  平台

•  严重级别

•  发现漏测的版本

漏测产生活动是指在软件开发测试过程中，某类被漏测的缺陷最应该在该活动中被发现。设置该项分类的目的是为了便于对产生了漏测的活动进行更进一步的细化分析。

产品模块是指被漏测的缺陷所在的代码模块。

缺陷影响是指漏测缺陷给用户使用时所带来问题的类型。

引入版本是漏测缺陷被引入时的代码版本，它应该是代码第一次引入该缺陷的版本。

平台是指产生漏测的平台或操作系统。

严重级别是指缺陷的严重程度度量，例如：致命、严重、一般、提示。如果你的缺陷跟踪过程还没有包含缺陷的这个属性，那么漏测分析过程应该明确地给出每个缺陷的严重级别。

发现漏测的版本是指该漏测初次被发现并被报告时的软件版本。

进行漏测分类活动时，最好将开发、测试、技术支持以及其他所有产品生命周期中相关部门的代表组织到一起对近期的漏测进行讨论，特别是技术支持人员能够提供很多非常详细的关于漏测缺陷的信息，这对漏测分类非常有帮助。

在项目组进行实际漏测分析活动时，也许不需要按照上面建议的一些属性进行分类，而需要采用其他一些分类标准，这时最好在项目组内集体讨论来决定哪些分类是最适用的。

在漏测缺陷分类活动结束后，需要对分类结果数据进行统计分析。例如，每个漏测缺陷对应了一个漏测产生的活动，这时可以考虑对该活动进行进一步的改进。

•  分析活动：跟踪工具

进行漏测分析时如果没有缺陷跟踪工具的支持是很困难的。应该采用工具来维护所有不同分类的漏测缺陷数据。 Lotus Notes 数据库就是一个不错的工具，它能很方便地将数据按各种不同的方式进行分割，这样你能够对同样一批数据创建各种视图，从而能够从各个角度进行统计分析。

•  分析活动：统计

统计分析是为了指导全流程过程改进。进行统计分析首先要确定进行统计分析的频度，一般一个季度进行一次统计分析比较合适。进行统计分析时，需要将某个分类的各分类项的数据一一和该分类的所有其它分类项数据进行比较，并且对所有的分类都要进行这样的操作。对那些相对总数比较大的分类项还要进行更进一步细分，进行更进一步的统计分析工作。

•  分析活动：全流程过程改进

进行统计分析的时候，漏测分析小组需要集合在一起，对统计分析结果进行讨论。基于统计分析结果可以得到各种趋势图，分析小组可以讨论全开发流程中需要改进的意见和方案，然后对那些需要改进的地方作出正式的改进建议，制定改进实施计划，并在随后的会议上，漏测分析小组对变更实施过程进行讨论。可以通过漏测分析数据库或者其他工具进行任务分配和跟踪。这里可以给出两个根据缺陷分析进行全流程改进的例子：第一个例子，如果在系统在故障处理时发现了很多的漏测缺陷，那么进行开发过程全流程改进时，可以考虑增加异常测试组，加强异常测试；第二个例子，如果用户在某硬件平台上使用软件的过程中发现了大量缺陷而测试组却没有该硬件平台，这时需要考虑改进硬件获取过程，增加测试的硬件平台。全流程改进会给软件企业带来巨大的影响，所以一定要取得管理层的支持和同意。

原文转自：http://www.ltesting.net