01
BUG分析简单可以分为两类：宏观BUG分析和微观BUG分析。
宏观BUG分析：在某个迭代或者版本的周期内（或者更长时间），对BUG产生的原因、修复周期、累积趋势进行分析。总结分析bug和测试过程问题，形成的质量报告不仅能准确评估过去产品质量，还能为未来产品提出改进建议，持续推进产品质量的不断提高和完善。
微观BUG分析：指深入分析某个bug产生的根因、探讨后续如何避免。
02
众所周知，早期发现并修复bug所需的资源更少。因此，我们应该尽早预防和发现bug，而不仅仅是修复它们。适当借鉴过去的经验是一种较好的预防bug方法。通过分析现有的bug，找到引起它们的根本原因和流程中的缺陷，并思考如何从各个方面进行优化改进，可以有效地预防bug，降低质量风险，提高产品质量。
这，是我们进行BUG分析的原始动力，也是让我们不迷失在茫茫BUG之海中的锚点。
03
常见的BUG分析有以下几种方法：
分类法：对所有的BUG进行分类，识别出共性的问题。根据分析的角度不同，也会有不同的分类方法，下面是笔者常用的分类方法，仅供参考：
- 发生阶段：冒烟测试、迭代测试、SIT测试、UAT测试、生产；根据BUG的发生阶段，我们可以观察BUG是否收敛，如果整体趋势是收敛的，那么分析的重点就可以放到UAT和生产的具体BUG上。如果发现BUG没有收敛，或者趋势不明显，那就要优先分析流程和测试策略，这时候去分析某个BUG的根因意义就不大了。
- 产生原因：这个就有很多维度，比如需求问题、设计问题、编码问题、接口问题、数据问题等等；根据产生的原因，我们可以观察BUG集中发生在哪个阶段，大概的原因是什么。有助于研发去规范和改进研发过程，毕竟这是BUG产生的直接原因。
分类法适用于宏观BUG分析，有助于我们从整体审视BUG的生命周期，发现流程性的问题，而不是只关注某个BUG。
根因法：针对某类或者某个具体的BUG，进行刨根问底，找到BUG的根源。常用的方法有5Y法和5M1E法。
- 5Y法：是一种问题解决技术，旨在找出一个问题的根本原因。它通过连续追问"为什么"来深入挖掘问题的本质，直到找到最终的根本原因。让问题不浮于表面。（较常见，就不举例了哈）
- 5M1E法：是一种用于问题解决和过程改进的工具，它通过分类和归类来识别和分离影响某个过程的因素。5M1E代表的是材料、方法、人力、机器、测量/环境和效应，其中效应是该模型中最重要的一个部分。（文末有个具体的案例）
对于根因分析法，分析到什么程度才是“根因”呢：最直接的指标就是产生的结果是否是“可行动的”。如果一个结果是不可行动的，往往意味着深度或者抽象不够。
04
在实践过程中，我们经常会发现，虽然我们经常进行根因分析和复盘，但问题往往总是在重复，每次分析到最后，原因总是那几个，然后就逐步放弃这件事。笔者认为，最核心的问题在于我们缺少对PDCA中A（Act 行动）的确认，分析只留在当时，而没有持续跟踪改进。
经过分析或者复盘后，我们的流程是否发生了变化？研发过程是否发生了变化？哪些检查项被集成到流程中?有什么好的研发方法被推广了？还是什么都没发生。
当下次进行BUG分析前，是否确认之前的行动项已经被落地，同类型的BUG是否得到了收敛？如果没有，请不要再投入精力去做分析。请把上一次的行动项做好。
05
附：关于5M1E分析法的一个案例，假设一款软件出现了一个常见的问题：某个功能无法正常使用：
明确问题：某个功能无法正常工作。
识别过程：确定该功能所在的开发流程和测试流程。
分类：将过程中的所有因素按照5M1E分类，如下所示：
材料 (Material): 程序代码、测试数据等
方法 (Method): 开发和测试方法、流程等
人力 (Manpower): 开发和测试人员的技能水平、经验等
机器 (Machinery): 开发和测试设备、硬件环境、软件环境等
测量/环境 (Measurement/Environment): 测试工具、开发环境、测试环境等
效应 (Effect): 缺陷或错误的产生会影响什么
分析：分析每个因素如何影响该问题，并确定其中的关键因素，如下所示：
材料: 程序代码可能存在缺陷或bug，导致程序不能正常工作。
方法: 可能没有足够的测试覆盖率或测试用例来检测程序的缺陷或bug。
人力: 测试人员可能没有足够的经验或技能来检测程序的缺陷或bug。
机器: 测试环境可能与实际环境不匹配，导致未发现问题。
测量/环境: 可能使用的测试工具或开发环境存在问题，无法正确检测问题。
效应: 该缺陷或错误导致了产品质量问题，影响了客户满意度和公司品牌形象。
5M1E法给出了更聚焦的分析方向，可以多尝试使用，分析时，原因可能是5M中的一个或者多个，需要根据实际情况来确认。
