如何高质量的做BUG分析

简介: 如何高质量的做BUG分析

对于BUG分析,测试人员再熟悉不过了。但如果是面对大量的BUG,要如何有效的分析呢?有什么好的方案和行动项?今天聊聊这个话题。


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中的一个或者多个,需要根据实际情况来确认。


相关文章
|
8月前
|
测试技术
无法复现的bug,如何处理?
无法复现的bug,如何处理?
561 0
|
8月前
|
人工智能 网络安全 Python
一篇普通的bug日志——bug的尽头是next吗?
[bug 1] TypeError: ‘method’ object is not subscriptable 问题代码:
142 0
一篇普通的bug日志——bug的尽头是next吗?
|
运维 监控 前端开发
记一次线上 bug 的排查分析过程及总结
记一次线上 bug 的排查分析过程及总结
记一次线上 bug 的排查分析过程及总结
|
程序员
缺陷(bug)管理
理论上软件的缺陷是可修复的,不过有的修复成本比较高,不能追求软件的完美,根据风险来确定是否修复缺陷
|
SQL BI 数据库
记一次bug分析定位过程
其实很多时候,我们在测试过程中发现的很多bug,并不是由于开发人员编码能力不好,或者粗心大意造成,而是在项目开发实施过程中,没有遵循一些必要的项目流程,没有充分认识到质量的重要性;如果能做好这方面的工作,关注流程,而不是喊口号,人人重视质量,人人为结果负责,那么,会有很多问题、不只是bug,都将“被扼杀在摇篮里”......
记一次bug分析定位过程
|
Web App开发 关系型数据库 项目管理
|
编解码 Java 数据库连接
追踪Bug的五项原则
  一个远程办公的团队比坐在一个办公室里的团队需要更强的纪律。首先,我指的是沟通的纪律。在teamed.io, 我们已经远程开发软件有五年之久。我们通过问题清单系统(原文为ticketingsystem如Github, JIRA, Trac,Basecamp 等)来严格地管理任务,并且不鼓励任何不正式的沟通方式,如Skype, HipChat, 邮件或者电话。每一个ticket对我们来说都是一个有自己生命周期、参与者和目标的独立任务。这些年,我们有一些教训想分享给大家。如果你的团队也是远程办公,你会发现这些内容很有用。
152 0
|
运维 Cloud Native 测试技术
高质量的缺陷分析:让自己少写 bug
缺陷分析做得好,bug 写得少。阿里资深技术专家和你分享如何进行高质量的缺陷分析,总结了 5 个要点,通过缺陷分析消除开发中的各种盲点,打造一个学习型的团队。
高质量的缺陷分析:让自己少写 bug