关键字：缺陷漏测 测试过程改进
• 漏测的定义 所谓漏测，是指软件产品的缺陷没有被测试组发现而遗漏到了用户那里，却最终被用户所发现。如果产品在用户那里出现问题，产生的后果是非常严重的。在软件开发过程中，缺陷越早被发现，发现和解决缺陷所花的成本就越小。如果缺陷是在测试组测试中发现的而不是被用户使用时发现的，那么所花的成本将小得多。如果缺陷是被开发组在开发过程中发现的，那么所花的代价将更小。因此，进行漏测分析、预防漏测、促使缺陷尽可能在开发过程的早期被发现，是非常有意义的，它有利于降低软件产品成本、提高软件产品质量。
• 漏测分析的目的
进行漏测分析的目的是为了促进软件质量和开发测试过程得到持续改进。具体来讲，就是通过分析开发和测试过程中漏测的缺陷，制定相应的预防措施以避免今后再发生类似的漏测。测试过程的持续改进将提高测试环境的效果和测试执行的效率、降低遗留到用户处的缺陷数和缺陷解决成本，从而提升软件的质量、声誉和销售。在软件产品开发过程中重视漏测分析并参与到漏测分析工作中的团队越多，漏测分析的效果就越好。如果开发和测试团队都重视漏测分析、并密切配合进行漏测分析工作的话，漏测分析将取得非常好的效果。
在实际工作中，漏测分析过程应该重点关注那些普遍、严重而解决成本高的问题。具体来讲，漏测分析的目标是：
• 对漏测进行分类以便于更进一步深入的分析
• 对分类数据进行统计
• 在统计分析的基础上进行全过程的标识和变更
• 在对一些特殊的漏测项进行分析的基础上，对过程的一些局部进行标识和变更
• 运用度量数据说明过程变更的效果
• 如何进行漏测分析
漏测分析活动可以参照下面的建议进行。在熟悉了漏测分析流程以后，需要确定进行漏测分析活动的频度。为了取得较好的效果，最好是遵照一个时间表来定期进行漏测分析活动，一个月进行一次是一个比较合适的频度。
• 计划
这个过程是针对多项目组联合进行漏测分析而设置的，在联合项目组中实行该过程最有效。如果不可能组建联合项目组进行漏测分析，也可以修改该过程只在测试组内部实行。
制订计划如果不确定关注点的话，这个计划将难以有效实施。漏测分析要想取得理想的效果，就需要计划好进行漏测分析活动的确切的人员数目、活动时间。 过程执行的效果完全取决于执行它的方式，如果不切切实实的做好计划，你的过程将不会得到太多的改进。
实际进行漏测分析活动时，只选择漏测分类的一部分子集进行分析，将有利于更有效的进行漏测分析工作。进行漏测分类前，需要在计划中确定选择哪部分子集进行分析。例如，如果漏测的严重度等级分为一到四级，一级严重度最高，四级严重度最低，那么也许只分析一、二级的漏测最合适，这样可以避免在那些对用户无关紧要的漏测缺陷上花太多的无用功；也可以只分析那些被关闭和修复了的漏测缺陷，因为如果分析那些没有被关闭和修复的缺陷，可能会漏掉一些至关重要的信息；另外，还可以在进行漏测分析之前排除掉重复缺陷和那些由于用户错误操作引起的缺陷，这样就只需要分析那些有效的漏测缺陷，它们才能真正提供开发和测试过程需要改进的信息。
• 漏测分类
接下来需要将所有的漏测缺陷按照有意义的属性进行分类，当然，前提条件是已经有了一个包含了所有漏测缺陷详细信息的漏测列表。然后需要确定哪些属性分类是对分析有用的。下面给出一些漏测缺陷的属性的例子：
• 漏测产生活动（最有可能发现该漏测缺陷的活动）
• 开发阶段（原始需求评审、概念评审、设计评审、代码检视、单元测试、模块联调、信息资料开发）
• 测试阶段（功能测试、系统测试、本地语言测试、设备驱动测试、安装测试、性能测试、异常测试）
• 产品模块（产生了漏测缺陷的代码模块）
• 模块 A 、 B 、 C 等
• 缺陷影响（对用户使用造成的影响）
• 系统崩溃、业务中止、数据完整性、命令失效、安装失败、设备 / 驱动、性能、文档、可用性等
• 引入版本（引入漏测缺陷的代码版本）
• 平台
• 严重级别
• 发现漏测的版本
漏测产生活动是指在软件开发测试过程中，某类被漏测的缺陷最应该在该活动中被发现。设置该项分类的目的是为了便于对产生了漏测的活动进行更进一步的细化分析。
产品模块是指被漏测的缺陷所在的代码模块。
缺陷影响是指漏测缺陷给用户使用时所带来问题的类型。
引入版本是漏测缺陷被引入时的代码版本，它应该是代码第一次引入该缺陷的版本。
平台是指产生漏测的平台或操作系统。
严重级别是指缺陷的严重程度度量，例如：致命、严重、一般、提示。如果你的缺陷跟踪过程还没有包含缺陷的这个属性，那么漏测分析过程应该明确地给出每个缺陷的严重级别。
发现漏测的版本是指该漏测初次被发现并被报告时的软件版本。
进行漏测分类活动时，最好将开发、测试、技术支持以及其他所有产品生命周期中相关部门的代表组织到一起对近期的漏测进行讨论，特别是技术支持人员能够提供很多非常详细的关于漏测缺陷的信息，这对漏测分类非常有帮助。
在项目组进行实际漏测分析活动时，也许不需要按照上面建议的一些属性进行分类，而需要采用其他一些分类标准，这时最好在项目组内集体讨论来决定哪些分类是最适用的。
在漏测缺陷分类活动结束后，需要对分类结果数据进行统计分析。例如，每个漏测缺陷对应了一个漏测产生的活动，这时可以考虑对该活动进行进一步的改进。
• 分析活动：跟踪工具
进行漏测分析时如果没有缺陷跟踪工具的支持是很困难的。应该采用工具来维护所有不同分类的漏测缺陷数据。 Lotus Notes 数据库就是一个不错的工具，它能很方便地将数据按各种不同的方式进行分割，这样你能够对同样一批数据创建各种视图，从而能够从各个角度进行统计分析。
• 分析活动：统计
统计分析是为了指导全流程过程改进。进行统计分析首先要确定进行统计分析的频度，一般一个季度进行一次统计分析比较合适。进行统计分析时，需要将某个分类的各分类项的数据一一和该分类的所有其它分类项数据进行比较，并且对所有的分类都要进行这样的操作。对那些相对总数比较大的分类项还要进行更进一步细分，进行更进一步的统计分析工作。
• 分析活动：全流程过程改进
进行统计分析的时候，漏测分析小组需要集合在一起，对统计分析结果进行讨论。基于统计分析结果可以得到各种趋势图，分析小组可以讨论全开发流程中需要改进的意见和方案，然后对那些需要改进的地方作出正式的改进建议，制定改进实施计划，并在随后的会议上，漏测分析小组对变更实施过程进行讨论。可以通过漏测分析数据库或者其他工具进行任务分配和跟踪。这里可以给出两个根据缺陷分析进行全流程改进的例子：第一个例子，如果在系统在故障处理时发现了很多的漏测缺陷，那么进行开发过程全流程改进时，可以考虑增加异常测试组，加强异常测试；第二个例子，如果用户在某硬件平台上使用软件的过程中发现了大量缺陷而测试组却没有该硬件平台，这时需要考虑改进硬件获取过程，增加测试的硬件平台。全流程改进会给软件企业带来巨大的影响，所以一定要取得管理层的支持和同意。
• 分析活动：局部过程改进
在联合项目组进行漏测分析时，对每个产生了漏测的活动都要选出代表（如：开发活动代表、测试活动代表、文档写作代表等等）。例如：针对 “ 漏测产生活动 ” 属性进行分类时，如果某漏测缺陷被分类到 “ 单元测试 ” ，那么该漏测缺陷应该由开发活动代表对其进行进一步的局部过程分析。所有这些缺陷都列在漏测分析数据库里，每个分类活动的代表应该列出归属该活动的所有漏测缺陷列表，然后提出这些活动的局部改进计划。举例来说，测试活动代表应该列出所有 “ 漏测产生活动 ” 为 “ 测试 ” 的漏测缺陷，并进行细分，然后将他们分配给测试工程师进行分析；测试工程师将针对所分配的漏测缺陷进行详细分析，找出漏测的原因，然后提出有针对性的改进计划来防止同类缺陷再次被漏测。这些改进计划应该在审核通过后实施，并且整个改进过程应该在数据库中进行跟踪，每个改进计划都应该能和单个缺陷漏测分析结果相对应，测试代表应该推动各改进计划的完成、审核和实施。这里要特别强调的是，这些改进计划不是用来修复缺陷的，因为这些被分析的漏测缺陷应该已经被修复好了，这些改进计划仅仅是在基于某个缺陷漏测原因分析的基础上重新确定测试过程（或开发过程等），它关心的是如何防止该类问题将来再次发生，而不是关心该特定的缺陷在将来是否会再出现（因为它已经被修复了）。例如，局部过程改进计划可以是补充以前没有考虑到的用例，也可以是在测试环境中增加特定的硬件使得测试环境更接近于用户使用环境。在考虑改进计划的时候应该鼓励创造性。
• 度量
漏测分析过程的最后一步是对改进过程的阶段性实施效果进行测量。本文后面部分将对此进行更详细的论述。
• 漏测分析举例
图 -1
* APAR 是描述缺陷属性的一个术语。
图 -1 以一个虚拟产品的 Lotus Notes 漏测缺陷数据库作为示例。在本例中，对一个漏测缺陷采用三个标签项来跟踪其特征数据。第一个标签项用于描述缺陷的详细数据，这些数据来自于缺陷跟踪工具，它们从缺陷跟踪工具到漏测分析工具的输入和转换最好是自动完成。此外，还有一个较大的属性域用来描述缺陷的历史和概要，本图中没有显示出来该域。
图 -2
图 -2 演示的是 “ 开发分析 ” 标签项。针对开发过程，可以对漏测缺陷进行各种不同的分类。在本例中所示例的漏测缺陷被归类为 “ 设计评审过程 ” 遗漏。这个例子演示了对产品的开发过程变更创建 “ 概念评审 ” 的过程。 “ 捕获概率 ” 项用来评估变更实施后可能产生的效果，它能回答 “ 如果在开发过程中已经实施了该变更计划，这个缺陷被捕获到的可能性有多大？ ” ，对此本文将在后面的 “ 测量 ” 小节进行详细探讨。这个表格还设计了变更计划制订的预期日期项和实施该变更计划的预期日期项， Lotus Notes 系统会在该日期自动发送提示信息给变更计划的受理者。
图 -3
图 -3 演示的是 “ 测试分析 ” 标签项。在这里可以分析用户报告的缺陷是否真的是漏测，换句话说，确定测试过程中是否真的存在漏洞或者该缺陷是否真的值得解决。这是非常重要的。有一些用户发现问题的环境是非常特殊的或生僻的，还有些缺陷解决起来代价很大，并且很难被发现，漏测分析组需要确定是否有必要针对该漏测缺陷进行测试过程改进。如果发现问题的用户是非常重要的客户，并且该用户会经常使用该环境，那么即使发现问题的环境非常特殊，也需要改进测试环境，来尽量符合用户的使用环境。在上面的例子中，缺陷被归类到 “ 未执行的测试类型 ” ，该测试类型发生了漏测。在对数百个漏测缺陷进行统计分析后，如果发现 “ 未执行的测试类型 ” 比例很高，那么可能需要在整个开发过程中增加该类测试类型。这里 “ 捕获概率 ” 项和上面小节描述的含义一样。
• 测量
本节将给出关于测量的一些建议。首先，对于需要改进点，将给出能指导漏测分析组制订合适的改进计划的测量点；接下来，将给出一些评价漏测分析过程效果的方法。您可以采用其中部分或全部建议来建立自己的测量体系。 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 。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
