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


相关文章
|
测试技术
无法复现的bug,如何处理?
无法复现的bug,如何处理?
991 0
|
监控 数据挖掘 中间件
性能测试数据分析的第一步
性能测试数据分析的第一步
207 0
|
9月前
|
Web App开发 IDE 测试技术
Selenium:强大的 Web 自动化测试工具
Selenium 是一款强大的 Web 自动化测试工具,包括 Selenium IDE、WebDriver 和 Grid 三大组件,支持多种编程语言和跨平台操作。它能有效提高测试效率,解决跨浏览器兼容性问题,进行性能测试和数据驱动测试,尽管存在学习曲线较陡、不稳定等缺点,但其优势明显,是自动化测试领域的首选工具。
565 17
Selenium:强大的 Web 自动化测试工具
|
10月前
|
存储 缓存 监控
性能测试中关注的指标
性能测试关注多个层面的指标,包括系统层(CPU、内存、磁盘、网络)、中间件层(网关、数据库、缓存、MQ、分布式存储)、应用层(响应时间、吞吐量、应用资源、GC、错误信息)及业务层和发压机指标。这些指标帮助评估系统性能,识别潜在瓶颈,确保软件质量和用户体验。
719 5
太阳能光伏电池的simulink建模与仿真
本课题研究了太阳能光伏电池在不同光照温度和光照强度下的Simulink建模与仿真,分析了光伏电池的U-I特性和P-V特性曲线。通过MATLAB 2022a进行仿真,展示了不同温度下的特性曲线变化,揭示了温度对光伏电池性能的影响。核心原理包括光生电效应、PN结的形成与工作机理,以及载流子的产生、分离和收集过程。
|
监控 测试技术
软件测试中的风险管理:如何避免潜在缺陷
【8月更文挑战第5天】在软件开发的生命周期中,测试阶段扮演着至关重要的角色。本文将深入探讨软件测试中的风险管理,包括风险识别、评估和缓解策略。我们将通过具体案例分析,揭示如何在早期阶段预防和减少潜在的软件缺陷,以及如何通过有效的测试计划和执行来保障产品质量。文章旨在为读者提供一套系统的风险管理框架,帮助他们在软件开发过程中识别和应对各种测试风险。
438 3
|
存储 Oracle 关系型数据库
关系型数据库Oracle 空间不足
【7月更文挑战第16天】
175 2
|
存储 运维 自然语言处理
研发视角:一个需求应该怎么拆解与实现?
研发过程中,开发同学在接到一个需求后,必须要回答两个问题:做什么(WHAT)、怎么做(HOW)。本文就开发与测试在拆解需求时面临的共性问题,结合自己过往的经验,总结的一个实用的方法。本文不讨论技术选型,仅从思考逻辑上总结应该如何拆解与实现一个给定的需求。欢迎讨论。理解需求拆解的关注点以带UI的需求为示例,来看拆解需求过程中的关注点。看下图,停留20秒,思考两个问题:(1)从无到有实现以下需求对应的
75670 10
研发视角:一个需求应该怎么拆解与实现?
|
机器学习/深度学习 人工智能 运维
探索AI在软件测试中的应用和影响
【2月更文挑战第17天】随着人工智能(AI)的飞速发展,其在各个领域的应用已经引起了广泛的关注。特别是在软件测试领域,AI技术的引入不仅改变了测试方法,提高了测试效率,还为测试质量提供了新的保障。本文旨在探讨AI在软件测试中的应用及其对传统软件测试的影响,以期为软件测试行业提供新的思路。
|
缓存 Python
什么是Python中的描述符(Descriptor)?如何实现一个描述符?
什么是Python中的描述符(Descriptor)?如何实现一个描述符?
173 2