缺陷调研 告_实例！软件缺陷数据度量和分析

缺陷 告，是软件测试这个职位最重要得产出之一。甚至对软件测试这个行业你可以用比较狭隘的描述去定义他为：‘测试就是为了找到缺陷’。 测试人员 出的缺陷，可以很好的反应产品中的问题，修复了这些问题，就可以有效的降低产品风险。其实缺陷 告不单单能帮助研发团队发现问题，他也可以起到重要的过程反馈作用。

缺陷 告是我们测试 告的两大核心要素之一，他与测试执行情况一起组成了我们测试 告的主要内容。那么缺陷 告，我们应该 告一些什么，是不是仅仅是缺陷数量呢们今天就来说说怎么用‘量化分析’的形式，来制作我们的缺陷 告。

我们用一个实际项目缺陷 告来阐述这个课题，这个项目情况是这样的：

该项目为一个COTS产品的定制性二次开发项目

项目周期计划为4个月，实际完成时间为6个月

项目是一个总体人员不到10人的小型项目

采用持续集成，高速迭代的研发方式

1.　我们要看到的第一个 表叫做‘缺陷到达率 告’，见下图：

缺陷移除率指的是我们在研发各阶段明确和解决的本阶段引入的缺陷的比例。

在软件测试的基础理论里面我们强调，软件测试应该尽早的介入项目，一般要求在需求分析阶段就进行参与，并且我们要用静态测试的方法去对各阶段的产出进行测试。在本阶段我们就应该去追求去尽量明确本阶段所产生的问题缺陷。而缺陷移除率表现的就是我们在当阶段明确发现该阶段引入的缺陷及问题的能力，反过来他又能体现出有多少问题被从一个阶段遗留到了下一阶段。

比如说，在需求阶段，我们的产出：需求文档里面就引入了10个缺陷，我们在当阶段通过需求评审测试等工作，发现并明确其中的2个缺陷。那么该阶段的缺陷移除率就是2/10=20%。而缺陷遗留率就是(10-2)/10=80%，有80%的缺陷被遗留进了下一个阶段。

更直观的来说我们还可以做出下面的表格和图表：

解析：对我们以上的 表进行分析，我们可能可以得出以下结论：

① 需求阶段缺陷移除率较低，说明需求评审工作的缺失

② 验收阶段 出需求问题数量可观，说明需求团队与用户的沟通不畅

③ 单元测试整体发现缺陷数过低

④ 测试以外的人员缺陷 告数较低

除此之外，通过实际项目调查我们发现，实际团队除测试小组的其他人员有着不爱 bug的倾向。实际上，一个项目的质量是应该与团队所有人员都息息相关的，而不仅仅是测试团队的任务。我们是不是应该更鼓励项目其他方面人员去主动提交缺陷，是值得我们思考的一个问题。

3.　　缺陷分布率分析

可以看到支付模块的占比上升了，他与浏览展示模块构成项目质量指标最值得关注的两大部分，从而可以指导我们测试资源的投入。

4.　　缺陷修复率分析

缺陷修复轮次统计通过统计缺陷被激活的次数，来观察缺陷都需要经过多少轮的修复才能被关闭这样的数据。

解析：

① 项目大部分缺陷经历了多次修复

② 反映了开发与测试团队存在一定程度的沟通问题

③ 部分原因在于测试团队的测试描述不充分

6.　　缺陷有效率统计

阶段缺陷分布指的是在一定时间阶段内，我们汇 的bug严重级别上又怎样的分布情况。

解析： 5月份有明显的次严重级bug数上升 6月份有最严重级bug数上升

8.　　缺陷类型分布统计

解析：

② 外部测试的缺陷数令人担忧(指的实际上UAT测试的结果)

③ 回归测试和探索性测试发现了系统测试没有发现的问题，说明他们都是非常有效而且必要的测试活动

以上我们讨论了在测试缺陷数据度量上，我们能够去考虑的 表统计的类型的思路，也结合着实际项目状况对每个 表进行了一定的解析。实际工作中，我们还可以做出很多别的类型的 表，只要我们认为该方面的统计数据可以给我们带来有用信息和思考的，我们都可以去对他进行汇 。

还有几点问题要谈到：

首先：我们的这个实例里，采样样本数量是偏小的，造成的问题是数据随机性会偏大，有可能出现失真的情况。如果项目规模够大，采样样本更多，我们的缺陷数据度量分析就能更准确的反映项目测试过程状态已经我们的产品质量特性。

其次：如果我们总是在项目结尾阶段才去做缺陷数据度量，那么他对于项目反馈的作用就非常有限了–毕竟项目都已经收尾了。其实我们在谈到测试 告时，应该知道测试 告不单单只有测试完成 告，还有测试过程 告。如果我们在测试过程 告里就引入缺陷数据度量，那么我们就能更好的对测试和研发过程进行反馈，从而达到过程改进的效果。

最后：如果想要在测试 告时，能够收集到更多有用的缺陷数据，就要求我们在缺陷所包含的信息进行更详细的定义。比如说要求开发在解决缺陷的同时，明确的填入该缺陷所产生的根源阶段，这样我们才能统计出我们在第二个节点做出的缺陷泄露率/移除率 告。

相关资源：地摊叫卖广告软件 商场促销 文字转换声音 卖场叫卖语音广告制作