从Bug中学习--Bug根因分析法

发表于:2019-1-18 14:14

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:stefan    来源:思否

#
Bug
#
bug
分享:
  一提起测试,大多数人很容易就会联想到Bug。的确,测试的日常工作离不开Bug,测试工作很重要的一部分就是发现Bug。但是,发现Bug、解决Bug,就足够了吗?肯定不是的。
  Bug是我们测试人员宝贵的财富,通过Bug我们可以获得经验,这种经验又能用在以后的测试中,帮助我们更早、更快地找到同类的Bug。
  Bug最大的价值不在于找到并解决它,而在于通过对Bug的分析,使我们增加一些经验、掌握一些规律,以便更好地进行测试。
  在对Bug进行分析时,一般很容易能想到的问题有:
  这个Bug是什么?
  为什么会出现这个Bug?
  实际上,如果做Bug分析,只做到这个层次,还远远不够,上面只对Bug产生的原因进行分析,除此之外,还要更加注意:
  Bug的发现阶段
  Bug的产生阶段
  在这方面,独立顾问邰晓梅老师总结了一套方法,即T-RCA缺陷根因分析法(T-RCA,Test Root Cause Analysis),主要目的是基于缺陷的过程改进(开发的改进、测试的改进、组织的改进),通过问10个问题来对Bug进行根因分析,看似很简单,实则重在引导和交流。
  我在T-RCA的基础上,结合自己的理解,认为分析Bug要分为四个步骤:
  第一步,认识Bug
  Bug是什么?(有什么影响?)
  为什么会出现Bug?(什么场景下会出现?)
  第二步,Bug的发现
  在哪个阶段发现的?
  应该在哪个阶段发现?
  为什么在这个阶段没有发现?
  如何才能在这个阶段发现?
  第三步,Bug的产生
  在哪个阶段产生的?
  为什么会在这个阶段产生?
  如何避免Bug的产生?
  第四步,Bug的改进
  如何改进,做到Bug预防?
  下面来详细说说。
  1、认识Bug
  在这一步骤中,要清晰全面地认识Bug,包括
  通过问“这个Bug是什么”,来清楚描述这个Bug,包括向开发人员提Bug时也要用到这个描述
  通过问“Bug有什么影响”,来判断这个Bug需要修复的优先级和影响的严重程度,对于优先级高的Bug要尽快上线,对于严重程度高的Bug可通过T-RCA方法进行根因分析
  通过问“为什么出现这个Bug”来快速找到原因,一般我们通过询问开发人员或自己定位得到这个原因,并且这个原因大多是代码层面的原因,要知道根因分析,不能止于代码层面
  通过问“什么场景下会出现”来复现Bug,并且最重要的是,可以反思自己在测试时是否遗漏了测试场景,测试覆盖是否不够
  这一步可以说是测试人员的基础能力,遇到Bug后我们自然而然就能想到的问题。对于大多数的Easy Bug,做到这一步也足够了,毕竟我们的测试总是要在有限的时间和资源下做平衡,分析Bug也不例外。
  Easy Bug,是指不需要精心的测试设计、不需要复杂的测试场景,就可以验证出来,随便找一个人来点点点,就可以发现的Bug。注意,验证和测试是完全不同的两个概念。但很可惜,大多数业务测试都是在做验证,而不是在做测试。
  2、Bug的发现
  在这一步骤中,要着重对Bug的发现进行分析,根据尽早测试原则,Bug发现越早,修复的成本也就越低,所以分析Bug的发现过程,也十分有价值。
  “Bug是在哪个阶段发现的”,软件研发的阶段,不论是瀑布式开发、迭代式开发,还是敏捷开发,细分下来大体可以是需求定义阶段、需求分析阶段、开发设计/测试设计阶段、开发编码阶段、联调阶段、 测试阶段、改Bug回归阶段、预生产环境测试阶段、部署上线阶段、线上释放阶段等等,越晚发现的Bug,更应该去反思为什么没有更早地发现它
  “Bug应该在哪个阶段发现”,较晚阶段的Bug应该尽早发现,早期阶段的Bug也不应该遗留到较晚阶段才发现,大多数人会认为Bug就是应该测试阶段发现的,但是如果可以做到今早发现,比如在需求分析阶段就从测试的角度提出一些风险,那规避风险的成本就会小得多
  “为什么在这个阶段没有发现”,对于线上Bug很容易理解,为什么这些Bug会被遗漏到线上,而不是在测试阶段就发现呢?通过问这个问题,我们能很好地反思我们的测试,究竟是在测试设计的时候没有考虑到这种场景,还是测试的时候巧合地漏掉了Bug,还是修改Bug时影响到了其他的业务逻辑而没有回归
  “如何才能在这个阶段发现?”,针对上面的问题,继续刨根问底,我们的测试永远有可以优化的地方
  3、Bug的产生
  这一步骤中是对Bug的产生进行分析,之所以把产生放到了发现的后面,是因为我认为Bug的发现相比于Bug的产生来说更重要。作为测试人员,你对发现Bug的控制,要更强于产生Bug,也就是说,预防Bug是很难做到的,而尽早发现Bug,却是我们都应该做到的。
  “在哪个阶段产生的”,有人会认为,Bug都是开发写出来的呀,自然就是开发阶段产生的,这就陷入了一个误区,我们做根因分析,就不能这么粗放地想当然,开发也不是拿到一个需求后上来就写代码的,也是需要分析、设计、code、review等几个阶段的,不同的开发人员之间还要经历联调阶段,所以搞清楚Bug的产生阶段,可以帮助我们更有针对性地注意在这个阶段做一些事情,来及时发现Bug
  “为什么会在这个阶段产生”,如果这个Bug不是代码Bug,而是开发从头就把需求理解错了,就要反思一下是不是我们需求细审时做得不够,是产品讲得不清楚, 还是测试没有提出一些有价值的风险?其他阶段如是,这也能帮助我们有针对性地改进
  “如何避免Bug的产生”,其实有不少的Bug都是可以避免的,比如作为测试在需求阶段从测试角度想到一些容易出Bug的风险或场景,作为开发在编码之后的自测做得更好等等
  4、Bug的改进
  在这一步中要考虑的就是通过分析了Bug的根因,认识到了我们测试的不足之后,就要想办法如何改进我们的测试过程,以帮助我们在以后的测试工作。比如是我们的需求阶段没有真正地理解需求,还是测试设计阶段遗漏了一些测试场景,还是测试阶段由于测试环境、测试数据等因素没有发现Bug,还是Bug回归阶段没有回归其他收到影响的模块等等。
  5、总结
  Bug根因分析法是很有价值的,但并不是每一个Bug都需要这样刨根问底的分析,也没有这样的精力和时间允许我们这样做。要选取那些有价值的Bug,分析完后真正能帮助我们思考和改进,比如我们公司,就会有分析线上Bug的这一环节,是因为线上Bug毕竟是遗留到了线上,普遍会具有一些价值。
  除了线上Bug,我们在测试中发现的Bug,如果比较有价值,能带给我们经验的提升,也是应该做根因分析的。所以,在进行Bug根因分析时,要以Bug的价值作为选取标准。
  作为测试人员,一直是在有限的时间和资源下进行平衡,不存在零Bug的软件,测试也是无穷无尽的,所以平衡资源一直是测试人员应该掌握的技巧,分析Bug也不例外,我们的最终目的不在于把Bug根因分析流程化,比如迭代开发中每个迭代都做一次,作为工作流程中的一环,而在于从Bug中进行反思、总结、学习、改进,以便更好地改进我们以后的测试工作。

     上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号