回顾校园生活中，我们参加每一场考试后都会对错题进行分析总结并补缺补漏，以便能更好地去应对更重要的考试。回到软件系统开发中，我们记录和跟踪缺陷的目的是什么，仅仅是为了在软件系统开发过程中跟踪Bug直至修复么？应该不止于此。我们也可以对项目缺陷进行分析，分析其共性进而分类，从而建立项目的“错题集”，为下一次“考试”提供宝贵的经验。
如图1-1所示，通常一条缺陷记录会包含缺陷编号、缺陷标题、状态、缺陷描述、严重程度、优先级、开发负责人、测试负责人、缺陷类型、功能模块、对应版本和对应环境等信息。那么，我们可以从哪些方面来分析和总结项目的缺陷呢？
一、缺陷分析维度
如图1-2所示，我们可以按项目缺陷的严重程度维度来统计。图中分别展示了项目各个严重程度的缺陷数和缺陷占比。从图中可以看出该项目有25个严重程度为一般的Bug，占Bug总数的50%，严重程度为较小的Bug占据到了28%，严重和致命程度的Bug占总的22%。
基于上述各类严重程度缺陷占比数据，我们可以怎么分析项目情况呢？从占比上看，本次项目的严重及以上的Bug占比不到总的1/4，说明本次开发项目的整体提测质量还是比较高的。但是，从Bug总数上看，由于Bug总数较多，严重程度较小和一般的缺陷数达到了39个，将近总数4/5。为什么会有这么多严重程度不高的Bug？
我们可以继续从缺陷类型维度分析，如图1-3所示，这里我们可以看到，功能问题类的缺陷还是占据了一半以上，同时，界面和交互问题也占据了28%，说明开发对于产品比较细节的功能点以及产品界面和交互重视和理解程度不够，导致提交测试的产品大问题不多，但是小问题不少。这部分问题是不是可以避免或者减少的呢？这就是我们要思考的了。
为了减少下次同类问题频繁发生，我们可以在开发方案和测试要点评审节点明确各功能细节、界面和交互点。让开发人员在开发过程中尽量避免此类问题。
如图1-4所示，我们还可以从功能模块维度进度分析。从图中我们可以看到模块B和模块C的缺陷占据了总的82%，相对于模块A和模块D，我们可以理解为模块C和模块D的实现复杂度应该比较高。为了提高该模块的开发质量，这次版本交付后可以督促开发去做总结和复盘，同时下次产品迭代涉及到这两个模块的时候也要做好研发方案评审。
如图1-5所示，除了从缺陷的各个角度去分析，我们也可以从开发负责人维度来分析。假定这个项目有四个开发人员共同开发，且分配给他们的任务在工作量和工作难度上没有太大的差异，从图中我们看出RD_张开发任务的缺陷数远远少于其他三个开发人员，可以说明其对需求的理解以及开发的质量意识是比较高的。可以公开对其开发能力进行肯定，也可以让其总结和分享开发经验，引导其他开发人员进行改进。
二、总结
上文分析的缺陷数据并没有包含所有项目的缺陷情况，但是大家可以尝试去分析自己负责的模块或者是整个项目的缺陷数据，并思考可能影响项目质量的原因，进而采取一定的措施去改进。不太可能一步到位完成，但是可以持续改进，这样同样类型或者是重复出现的缺陷就会越来越少，我们也能有更多的精力去应对更有价值的缺陷。
作者简介：Chaofan，爱测角成员之一，专注探索和分享软件质量保障。
如果需要上文缺陷分析模版文件，可以浏览原文获取。
原文地址：《漫谈测试成长之探索——缺陷分析》
标签：分析,模块,漫谈,开发,测试,维度,缺陷,Bug From： https://www.cnblogs.com/itestcorner/p/16611246.html