实例！软件缺陷数据度量和分析

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

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

 

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

• 该项目为一个COTS产品的定制性二次开发项目
• 项目周期计划为4个月，实际完成时间为6个月
• 项目是一个总体人员不到10人的小型项目
• 采用持续集成，高速迭代的研发方式

 

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

　　

　　

　　缺陷到达率指的是单位时间内，报出缺陷的数量。 上图按照每月报出的缺陷数量进行了统计，并且按严重级别进行了分类。

　　解析：

　　① 缺陷到达率在前四个月内呈明显下降趋势

　　② 五月份的缺陷量回升主要体现在低严重级缺陷数量上

　　③ 缺陷数的严重级别成正态分布

　　④ 六月份缺陷明显回升

 　　

　　结合着项目的实际我们对这个报表进行分析：后两个月的bug数量上升主要是因为在这段时间我们的测试分别引入了集中的回归测试和验收测试（我们将UAT测试中，客户报出的bug导入到了我们的缺陷管理系统内）。客户报出的缺陷方面，严重级偏高，这可能是因为客户对于缺陷严重级别的理解，与我们研发团队的理解并不一致所造成的。我们有可能需要跟客户就这个方面进行更好的交流和沟通。

 

　　2.　　缺陷移除率分析：

　　

　　

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

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

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

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

　　

　　

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

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

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

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

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

 

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

 

　　3.　　缺陷分布率分析

　　

　　

　　缺陷分布率指的是针对不同的功能模块，所报出的缺陷数量。 上图是一个小型电子商务平台的缺陷分布率情况。

　　解析：

　　① 商品浏览模块报出的总体缺陷量较多

　　② 支付模块报出严重缺陷较多

 

　　这个图表在直观度上有所欠缺，而且也不能最准确的表述各模块的质量特征。这里我们可以做一次加权处理：比如不同严重级的缺陷，给他不同的分数，进行二次计算，再来重新统计。

　　例：严重缺陷权值5，关键缺陷权值3，其他权值1，得出：

　　

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

 

　　4.　　缺陷修复率分析

　　

　　缺陷修复率指的在一定单位时间内，报出的，被修复的以及遗留的缺陷数量的对比。这是比较直观的一种报表。

　　

　　解析：

　　① 缺陷报出数量在经历了稳定下降之后，在项目后期迎来了回升

　　② 开发团队的bug修复能力在4月份出现滑坡，据调查是因为开发核心人员受到了抽调

　　③ 项目收尾时的bug遗留数量不容乐观，主要是由于最后两个月报出bug数量激增造成

　　

　　通过这样报表展示和分析，我们也可以得出一些有用的结论：比如我们是否应该考虑将回归测试的动作前移；又比如我们可以发现团队核心成员的稳定性是一个项目成功的重要要素。

 　　

　　其他还有很多形式的统计报表我们可以考虑，比如：

　　5.　　缺陷修复轮次统计

　　

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

　　

　　解析：　

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

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

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

 

　　6.　　缺陷有效率统计

　　

　　缺陷有效率指的是我们报出的缺陷中间，有效缺陷的百分比。

　　

　　解析： 可以明显看到，测试环境问题已经很大程度影响到了测试的有效率

 

　　7.　　阶段缺陷分布统计

　　

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

　　

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

 

　　8.　　缺陷类型分布统计

　　

　　

　　解析： 大部分缺陷类型集中为功能性，可能揭示了我们在其他质量指标的关注不足

 

　　9.　　测试活动缺陷率统计

　　

 

　　解析：

　　① 系统测试的效率并没有我们想象中的那么高（200多个缺陷中，只有不到40%来源于系统测试阶段）

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

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

 

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

　　

　　还有几点问题要谈到：

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

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

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