6） Issue Waiting Reason（缺陷等待原因分布图）：

　　说明：Waiting for build指的是缺陷已经解决，等待Build发布

　　分析：

　　Waiting for information/Waiting for review两项数值如果较高的话，说明spec定义出现了空缺的地方，无据可循。

　　第二部分：分阶段来统计和分析数据所包含的信息

　　对于采用瀑布模型的软件开发，过程的迭代，也使缺陷不断的被注入，并不断的被发现。众所周知，缺陷是越早发现越好，越是到后来，修改缺陷导致的代码变更会越大，从而软件质量得不到很好的保证。那么在里程碑和里程碑之间我们的工作做的充分了吗？有多少缺陷我们没有及时的发现并修正，从而流入到了下一阶段呢？ 这些信息我们怎么去度量和分析呢？

　　1. 缺陷注入-发现矩阵：

　　普通的软件开发过程会经历需求分析（对应需求评审）、设计、编码（对应单元测试）、系统集成（对应系统测试）等多个阶段。现所在的公司的流程是Spec审核、FS Alpha、FS RC 、APP RC，原理上还是一致，这里就以此过程来说明缺陷注入矩阵的数据分析（注：以下数据均为人为编制，暂没有从Bug库中进行收集统计）。

表1 缺陷注入-发现矩阵

　　引出重要的一个概念：阶段缺陷移除率。

　　阶段缺陷移除率=（本阶段发现的属于本阶段功能的缺陷数/最终统计的所有属于本阶段功能的缺陷数）x100%

　　阶段缺陷移除率可以有效的衡量测试用例是否充分，测试效率是否充足。如在上图中spec中所隐含的缺陷在spec发布到测试组内部时，通过阅读只发现了10个缺陷，本阶段的缺陷移除率只有20%，而在FS Alpha测试中陆续发现了20个缺陷，这就说明在spec审核阶段测试进行的不够充分。

　　说明：基于上图中的数据，需要开发能在当前测试阶段提供哪些功能点已经可测试，哪些功能点Blocked。

　　2. DRM模型

　　该模型分析了缺陷注入、缺陷发现、阶段测试有效性三者之间的关系。什么是阶段测试有效性？

　　阶段测试有效性=本阶段测试发现的缺陷数/（前多个阶段注入的缺陷总数+本阶段注入的缺陷数-前多个阶段发现的缺陷总数）x100%

　　同样采用缺陷注入-发现矩阵中所使用的表格数据，FS Alpha阶段测试的有效性=80/（50+100-10）x100%=57%；FS RC阶段测试的有效性=90/（50+100+70-10-80）=69%。

　　阶段测试有效性和阶段缺陷移除率采用的源数据相同，只不过后者更多的考虑到了累计效应，当然累计效应的影响也是我们需要尽可能避免的，不然初始时的缺陷在测试的最后阶段才发现，成本是非常高的。