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

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

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

 

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

• 该项目为一个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测试的结果）

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

 

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

　　

　　还有几点问题要谈到：

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

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

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