模板
教程
环境
性能
功能
管理
缺陷度量结果分析带来的思考
1 核心发现
该核心系统从报告第一个缺陷到生产上线历时30个月，期间累计报告有效缺陷2300余个。通过分析，发现该项目呈现出以下有趣的现象:
1) 团队核心人员变动对团队生产率影响巨大，存在“双凹”现象。
2) 团队交付模式依旧呈现瀑布式，表现为开发前半期缺陷报告占总数不足5%。
3) 80/20法则显现，报告缺陷数量TOP5的人员贡献超过2/3。
4) 缺陷分类工作未受到足够重视，缺陷严重级别的分布呈现为钻戒型。
5) 缺陷重开现象普遍，约3/4以上人员涉及缺陷重开。
6) 约50%缺陷在4天内修复，但严重缺陷修复速率与一般缺陷差距不明显。
2 缺陷报告发现
缺陷是通过测试活动被发现然后确认得到的，是测试活动的宝贵资产。通过时间、角色等维度，从缺陷到达率、缺陷报告人分布、缺陷引入阶段等度量指标进行了分析。
（一） 缺陷到达率分析
缺席到达率(Bug Arrival Rate)是指在单位时间内所报告的缺陷数量。首先按月度统计了当月报告的缺陷数和累计占比，并按照“缺陷严重级别”进行了分类，得到如图1 所示的月度缺陷到达率。
图1 缺陷到达率(月度)
缺陷涌入的高峰出现在项目重要里程碑阶段
以最后一个缺陷上报时间为T月,则第一个缺陷上报于（T-29）月。发现（T-12）月以317个缺陷排名第一，是月度均值(81.4)的3.9倍，而（T-25）月以202个缺陷排名第二。通过咨询项目经理，了解到前者是该核心系统的业务试用验收月，而后者为仿真并行上线月，两者均是该项目的重要里程碑节点。
发布前累计缺陷到达率已收敛
从图2和图3中均可看出，累计缺陷到达率指标在项目结束前的一个季度甚至半年前就开始收敛。（T-3）月累计缺陷到达率为98.5%。（T-7）月严重缺陷的累计缺陷到达率98.9%。该指标的收敛为结束测试和产品发布提供了很好的质量依据。如果按历年统计团队缺陷探测率能力基线为98.5%,则（T-3）月该项目已经达标。
测试团队的缺陷到达率存在“双凹”现象
从图1可以看出，（T-12）至（T-20）月之间“月度总记”的曲线存在着一个明显内凹。进一步分析原因，按照测试、开发(包括需求、开发)等角色对缺陷到达率进行了细分，如图2。
图2 缺陷到达率-开发/测试-按月
图2更加明显地看出，以（T-12）月为中轴，存在着左右两个内凹，分别是：T-20~T-12月、T-12~T-9月这两个区间。尤其是在（T-12）的前后几个月间，甚至还出现过测试人员报告缺陷的数量低于开发人员的现象。通过对项目经理和测试团队负责人的询问，了解到测试团队在此期间出现过团队核心成员的离职以及团队切换的情况。这充分说明保持团队，尤其是核心人员稳定的重要性。而在（T-8）月之后，随着现有测试团队的全面介入，测试团队报告缺陷数量再次超过开发，且测试整体占比也同样上升，体现了现有测试团队的成熟能力。据此，将整个项目的测试活动分为3个阶段，如表1所示。
表1 项目测试活动阶段划分
开发团队前14个月的缺陷数量不足2%
图2中表明“开发整体占比”的曲线在前期一直接近于0，因此增加了“累计占比”的统计，如图3所示。
图3 缺陷到达率-开发/测试-累计
由此数据可以了解到从（T-30）年至（T-16）的14个月之间，开发报告的缺陷数量为9个，分别占同期全部缺陷的0.8%和全部开发报告缺陷的1.56%。说明从开发测试的角度看，研发流程依旧呈现典型的瀑布式流程。
（二） 缺陷报告人分布分析
按照统计，发现前后共计38人报告过该核心系统的缺陷，其中开发（含需求）12人，测试26人，呈现出广泛的参与性。并且需求人员也报告了大量的缺陷，充分体现了全员参与测试的重要性和培养测试团队业务思维角度的必要性。
TOP5的捉虫能手贡献了超过69%的缺陷
图4表明缺陷数量排名前5的人员所发现的缺陷占比超过69%。而这种现象在角色分类统计中更加明显，TOP5的测试/开发人员报告的缺陷占各自角色报告缺陷的占比分别为85%和87%。根据数据分析发现缺陷是一项专门技能，发掘和培养善于发现缺陷的人员对测试团队而言至关重要。
图4缺陷报告TOP5占比
开发（含需求）发现缺陷占比达到了24%
该核心系统的开发过程中，开发人员大量参与测试，报告缺陷的人数为12个，缺陷总数为576个，占全部缺陷数的24%。从开发(含需求)报告缺陷的人数(X)、缺陷的数量（Y）以及与同期测试报告缺陷数量的占比(面积)这三个方面进行比对（图5、表2），可以分析出，在第一阶段，开发报告缺陷数量偏少，参与人数也偏少，而后期无论在人数和缺陷数量及占比上都有大幅增长。
图5 开发(含需求)格阶段报告缺陷
表2各阶段开发报告缺陷占比
需求人员在缺陷报告方面成绩显著
2名需求人员报告缺陷387个，其中一位报告缺陷330个，位列“TOP5-全部”的第2位和开发(含需求)人员的第一位，充分体现了需求人员参与测试的重要性和培养测试团队业务思维角度的必要性。
（三） 缺陷级别分析
缺陷分布呈现钻戒型严重缺陷占比后期过低
如图6所示，一般缺陷的占比为78%，单一类型占比过重，整个项目的缺陷分布呈现为钻戒型。
图6 缺陷严重级别占比
对于严重缺陷，如果根据之前三个阶段的划分，严重缺陷的数量在三个阶段分别为157，23，7。随着项目的推进，“优化改进”、“轻微缺陷”占各自阶段的百分比不断增大（图7），而“严重缺陷”的占比则不断下降，符合产品质量提升规律。但从增速/降速的角度进行对比，前两者缺陷增大的速率在1-2倍之间，而“严重缺陷”从阶段2到阶段3下降了1.8倍，从阶段1到阶段2却下降了5倍。分析认为“严重缺陷”的占比下降过于迅速，一方面因为产品质量的确是提升了，但结合“一般缺陷”的过重占比，也建议测试进一步与需求、开发进行缺陷分类(Triage)的活动，进一步明晰缺陷严重级别，便于安排资源进行缺陷修复等活动。
图7不同阶段缺陷分布
（四） 缺陷模块分析
第2/3阶段TOP5模块缺陷数量占同期总缺陷数的50%
在项目第2/3阶段累计报告缺陷1233个。同期报告有缺陷的模块34个，其中TOP5模块累计报告缺陷617个，占同期报告总缺陷数的50%。该项目第1阶段因某些原因有大量缺陷没有填写模块字段。
表3TOP5缺陷模块
该核心系统的缺陷在模块上的群聚效应是较为明显，建议系统后续进行改造时将上述TOP5作为关注的重点。
3 缺陷修复发现
与缺陷修复相关的指标包括了缺陷修复速率以及缺陷重开率等指标,是团队技术能力体现的重要度量指标。
（一） 缺陷修复速率分析
累计未修复缺陷总数与项目关键里程碑相关
作为一种技术债(Technical Debt), 未修复缺陷的数量一方面体现着产品的质量，另一方面也预示着团队后续所需要付出的时间和人力成本。经统计，该核心系统累计修复缺陷2353个，月均修复78.4个，每个月的缺陷新增/修复情况如图8。
图8 缺陷修复进展
从累计未修复缺陷分析，（T-12）月以113个未修复缺陷排名第一，可推测彼时该核心系统的产品质量处于最低谷。而该月和次月的每月修复缺陷数量达到了200左右，还出现了修复缺陷数量超过报告缺陷数量(>40)的现象。而在（T-7）月，团队又迎来了缺陷修复的最后一个高峰。随后随着新特性开发的结束，新报告缺陷的数量也迅速收敛，累计未修复缺陷数量也随之收敛为0。
80%缺陷在一个冲刺内修复
据严重级别对修复时间进行了统计排序（图9），可以分析出，约50%的缺陷在4天内得到了修复，80%的缺陷在15天内得到了修复，且后续的修复率曲线非常平坦。如果每个冲刺(Sprint)周期为2周，也就意味着有20%左右的缺陷不能在一个冲刺周期内得到修复。因此，要达到某些敏捷团队中的DoD所宣称的"修复该冲刺中发现的缺陷"是一个非常高的标准。
图9 缺陷修复速率(天)
严重缺陷修复率曲线相对前高后低但差异不明显
分析发现“严重缺陷”的修复速率曲线呈现出“前高后低”的现象，表明开发团队对其的重视程度更高，因此早期修复率较高。可能因为某些严重缺陷修复难度更大，因此后期修复率上升较其它级别的缺陷更缓慢。从整体分析，严重缺陷的修复率曲线与其它类型差距并不大，达到80%的修复率花费了13天，和整体（15天）相比差距很小。因此，建议该团队可否考虑更重视对于严重缺陷的修复速率的提升。
（二） 缺陷重开率分析
精益思想认为，返工是一种浪费，倡导一次性将事情做正确。可以通过“缺陷重开率”这一指标来度量开发人员一次性正确修复缺陷的能力。
缺陷重开是一个普遍现象
通过统计，累计有384个缺陷发生过“reopen”，剔除无效及不解决的缺陷，重开过的缺陷数量为333个，占全部修复缺陷2357的14.1%，涉及28人，为全部参与修复缺陷人数38人的73.7%。且修复缺陷超过3个以上的，修复人员出现重开缺陷的概率达到了100%，可见这是非常常见且分布面很广的现象。
建议后续对于部分缺陷修复耗时长、数量多、一次性修复率低的人员进行根因分析，以进一步提高产品质量和缺陷修复的质量。
原文转自：https://mp.weixin.qq.com/s/xqcGaGBleTCGGm8a2aICkA
