在项目组进行实际漏测分析活动时，也许不需要按照上面建议的一些属性进行分类，而需要采用其他一些分类标准，这时最好在项目组内集体讨论来决定哪些分类是最适用的。
在漏测缺陷分类活动结束后，需要对分类结果数据进行统计分析。例如，每个漏测缺陷对应了一个漏测产生的活动，这时可以考虑对该活动进行进一步的改进。
? 分析活动：跟踪工具
进行漏测分析时如果没有缺陷跟踪工具的支持是很困难的。应该采用工具来维护所有不同分类的漏测缺陷数据。 Lotus Notes 数据库就是一个不错的工具，它能很方便地将数据按各种不同的方式进行分割，这样你能够对同样一批数据创建各种视图，从而能够从各个角度进行统计分析。
? 分析活动：统计
统计分析是为了指导全流程过程改进。进行统计分析首先要确定进行统计分析的频度，一般一个季度进行一次统计分析比较合适。进行统计分析时，需要将某个分类的各分类项的数据一一和该分类的所有其它分类项数据进行比较，并且对所有的分类都要进行这样的操作。对那些相对总数比较大的分类项还要进行更进一步细分，进行更进一步的统计分析工作。
? 分析活动：全流程过程改进
进行统计分析的时候，漏测分析小组需要集合在一起，对统计分析结果进行讨论。基于统计分析结果可以得到各种趋势图，分析小组可以讨论全开发流程中需要改进的意见和方案，然后对那些需要改进的地方作出正式的改进建议，制定改进实施计划，并在随后的会议上，漏测分析小组对变更实施过程进行讨论。可以通过漏测分析数据库或者其他工具进行任务分配和跟踪。这里可以给出两个根据缺陷分析进行全流程改进的例子：第一个例子，如果在系统在故障处理时发现了很多的漏测缺陷，那么进行开发过程全流程改进时，可以考虑增加异常测试组，加强异常测试;第二个例子，如果用户在某硬件平台上使用软件的过程中发现了大量缺陷而测试组却没有该硬件平台，这时需要考虑改进硬件获取过程，增加测试的硬件平台。全流程改进会给软件企业带来巨大的影响，所以一定要取得管理层的支持和同意。
? 分析活动：局部过程改进
在联合项目组进行漏测分析时，对每个产生了漏测的活动都要选出代表(如：开发活动代表、测试活动代表、文档写作代表等等)。例如：针对 “ 漏测产生活动 ” 属性进行分类时，如果某漏测缺陷被分类到 “ 单元测试 ” ，那么该漏测缺陷应该由开发活动代表对其进行进一步的局部过程分析。所有这些缺陷都列在漏测分析数据库里，每个分类活动的代表应该列出归属该活动的所有漏测缺陷列表，然后提出这些活动的局部改进计划。举例来说，测试活动代表应该列出所有 “ 漏测产生活动 ” 为 “ 测试 ” 的漏测缺陷，并进行细分，然后将他们分配给测试工程师进行分析;测试工程师将针对所分配的漏测缺陷进行详细分析，找出漏测的原因，然后提出有针对性的改进计划来防止同类缺陷再次被漏测。这些改进计划应该在审核通过后实施，并且整个改进过程应该在数据库中进行跟踪，每个改进计划都应该能和单个缺陷漏测分析结果相对应，测试代表应该推动各改进计划的完成、审核和实施。这里要特别强调的是，这些改进计划不是用来修复缺陷的，因为这些被分析的漏测缺陷应该已经被修复好了，这些改进计划仅仅是在基于某个缺陷漏测原因分析的基础上重新确定测试过程(或开发过程等)，它关心的是如何防止该类问题将来再次发生，而不是关心该特定的缺陷在将来是否会再出现(因为它已经被修复了)。例如，局部过程改进计划可以是补充以前没有考虑到的用例，也可以是在测试环境中增加特定的硬件使得测试环境更接近于用户使用环境。在考虑改进计划的时候应该鼓励创造性。
? 度量
漏测分析过程的最后一步是对改进过程的阶段性实施效果进行测量。本文后面部分将对此进行更详细的论述。
文章来源于领测软件测试网 https://www.ltesting.net/
