回顾校园生活中，我们参加每一场考试后都会对错题进行分析总结并补缺补漏，以便能更好地去应对更重要的考试。回到软件系统开发中，我们记录和跟踪缺陷的目的是什么，仅仅是为了在软件系统开发过程中跟踪 Bug 直至修复么？应该不止于此。我们也可以对项目缺陷进行分析，分析其共性进而分类，从而建立项目的 “错题集”，为下一次 “考试” 提供宝贵的经验。

如图 1-1 所示，通常一条缺陷记录会包含缺陷编号、缺陷标题、状态、缺陷描述、严重程度、优先级、开发负责人、测试负责人、缺陷类型、功能模块、对应版本和对应环境等信息。那么，我们可以从哪些方面来分析和总结项目的缺陷呢？

              图 1-1 软件缺陷记录示例

一、缺陷分析维度

如图 1-2 所示，我们可以按项目缺陷的严重程度维度来统计。图中分别展示了项目各个严重程度的缺陷数和缺陷占比。从图中可以看出该项目有 25 个严重程度为一般的 Bug，占 Bug 总数的 50%，严重程度为较小的 Bug 占据到了 28%，严重和致命程度的 Bug 占总的 22%。

              图 1-2 缺陷分析_严重程度维度

基于上述各类严重程度缺陷占比数据，我们可以怎么分析项目情况呢？从占比上看，本次项目的严重及以上的 Bug 占比不到总的 1/4，说明本次开发项目的整体提测质量还是比较高的。但是，从 Bug 总数上看，由于 Bug 总数较多，严重程度较小和一般的缺陷数达到了 39 个，将近总数 4/5。为什么会有这么多严重程度不高的 Bug？

我们可以继续从缺陷类型维度分析，如图 1-3 所示，这里我们可以看到，功能问题类的缺陷还是占据了一半以上，同时，界面和交互问题也占据了 28%，说明开发对于产品比较细节的功能点以及产品界面和交互重视和理解程度不够，导致提交测试的产品大问题不多，但是小问题不少。这部分问题是不是可以避免或者减少的呢？这就是我们要思考的了。

              图 1-3 缺陷分析_缺陷类型维度

为了减少下次同类问题频繁发生，我们可以在开发方案和测试要点评审节点明确各功能细节、界面和交互点。让开发人员在开发过程中尽量避免此类问题。

如图 1-4 所示，我们还可以从功能模块维度进度分析。从图中我们可以看到模块 B 和模块 C 的缺陷占据了总的 82%，相对于模块 A 和模块 D，我们可以理解为模块 C 和模块 D 的实现复杂度应该比较高。为了提高该模块的开发质量，这次版本交付后可以督促开发去做总结和复盘，同时下次产品迭代涉及到这两个模块的时候也要做好研发方案评审。

              图 1-4 缺陷分析_功能模块维度

如图 1-5 所示，除了从缺陷的各个角度去分析，我们也可以从开发负责人维度来分析。假定这个项目有四个开发人员共同开发，且分配给他们的任务在工作量和工作难度上没有太大的差异，从图中我们看出 RD_张开发任务的缺陷数远远少于其他三个开发人员，可以说明其对需求的理解以及开发的质量意识是比较高的。可以公开对其开发能力进行肯定，也可以让其总结和分享开发经验，引导其他开发人员进行改进。

              图 1-5 缺陷分析_开发负责人维度

二、总结

上文分析的缺陷数据并没有包含所有项目的缺陷情况，但是大家可以尝试去分析自己负责的模块或者是整个项目的缺陷数据，并思考可能影响项目质量的原因，进而采取一定的措施去改进。不太可能一步到位完成，但是可以持续改进，这样同样类型或者是重复出现的缺陷就会越来越少，我们也能有更多的精力去应对更有价值的缺陷。

原文地址：《漫谈测试成长之探索——缺陷分析》
更多测试成长探索系列文章：
《漫谈测试成长之探索——缺陷分析》
《漫谈测试成长之探索——测试排期》