如何进行bug总结?

在项目过程中,测试同学会发现大量的bug,但同时也不可避免的会存在一些遗漏的bug。为了能够减少遗漏bug的现象,我们需要针对遗漏的问题进行总结,从教训中积累经验,总结方法,从而提高测试的覆盖度,提升产品的整体质量。

 

什么样的bug需要进行总结?

1.线上遗漏的bug

没有被测试发现而遗漏到线上的bug。其影响不言而喻,会直接影响用户的体验,影响产品的口碑,势必需要进行总结。

2.非线上遗漏的bug。

没有在规定的测试阶段发现,从而导致发现晚的bug,例如XX模块已经测试完毕,结果后来又发现该模块的新bug。这类bug会导致增加bug修改和验证的时间,从而有可能影响项目的整体进度,甚至导致项目delay。

 

什么时机进行bug总结?

1.项目上线后,应尽快进行bug总结,否则时间一长会出现遗忘的情况,包括测试和开发两方面,给总结操作带来不便。

2.遇到严重的或非常重要的遗漏bug,可随时进行单独总结,比如线上发现的严重问题。

 

总结什么内容?

总结bug的核心,是为了后续减少遗漏bug,提高测试覆盖度,提升项目质量。想要达到这个目的,首先需要分析bug的原因,尤其是遗漏原因;其次是确定后续的改进方案,避免类似的问题再次发生。

原因分析:

bug遗漏的原因一般分为几大类:

  • 非遗漏问题:bug总结时,出现概率最高的可能就是非遗漏问题,这类问题并不需要进行具体的总结,其中主要包含三类:

    • 不是问题:例如用户反馈的问题,但符合产品的需求要求,这种就属于不是问题。

    • 开发引入:例如我们测试完成的模块,开发修改bug,或在测试不知情的情况下修改了代码,引入的新bug。

    • 需变引入:例如我们测试完成的模块,发生了需变,导致新的bug产生。

  • 用例设计遗漏:bug是用例设计时没有覆盖到的场景,又可以细分为几类:

    • 基础用例设计不足:例如需求中详细说明的内容,没有在用例中提现。

    • 需求理解错误:例如需求理解错误,导致测试用例的预期结果不正确,而开发实现正好符合错误预期。

    • 模块间影响考虑不足:例如没有A模块与B模块有关联,会对B模块产生影响,但B模块的用例中未涉及到相应的场景。

    • 复杂路径无法覆盖:路径过于复杂,或者涉及较多层级的操作,例如经过10步操作后才会出现的bug。

    • 复杂场景考虑不足:例如两个或多个看似完全没有关系的场景,结合起来产生的bug。

    • 适配问题考虑不足:例如在某些特定的机型上出现的bug。

  • 用例执行遗漏:bug是执行用例过程中出现过,但没有被发现,可细分为2类:

    • 纯执行遗漏:测试用例中涵盖,但没有执行;或者执行了用例,也出现了问题,发现了问题但没有提交bug。

    • 敏感度不足:测试用例中涵盖,但没有明确说明,遇到了问题,但没有意识到是bug。例如同样都是头像,在A页面是个圆的,在B页面是个方的。

  • 重现率低的问题:重现几率较低的bug,无稳定复现的步骤。

  • 体验性或性能问题未关注到:需求中没有明确说明,也未在用例中涉及,但对用户体验有影响,后经其他方指出的bug。例如产品logo不够明确、使用过程中设备发热等。

改进方案:

针对bug遗漏的不同原因,也有不同的改进方案。

  • 非遗漏问题:这种类型,与测试无关,无需改进。

  • 用例设计遗漏:

    • 补充对应模块的测试用例,这个是基础。

    • 补充后的case是否具有通用性,如果有,那么需要应用到所有相关的模块中,并作为后续用例设计的经验积累。例如:锁屏后再解锁会导致某个页面控件的功能失效,那么各个页面都应该添加“锁屏后再解锁,检查控件可用”的case。

  • 用例执行遗漏:

    • 纯执行遗漏不可饶恕,除了自己做好备忘外,没什么更好的改进办法,这个层面出现问题,更多的应该是自我反思。

    • 如果是敏感度不足导致的遗漏,那么可以持续进行经验积累,提升自己对bug的认知。

  • 重现率低的问题:

    • 如果是能够找到具体原因的bug,那么应该深入挖掘,找到问题的本质原因以及重现步骤,然后再进行分析,对遗漏原因进行归类,然后再进行针对性的改进。

    • 如果是无法找到具体原因的bug,这块暂无有效的改进方法。

  • 体验性或性能问题未关注到:这类问题的改进方案跟敏感度不足的改进方案类似,需要持续的进行积累,提升自己的产品感觉。

 

其实对于bug总结,应该正面认识,并不是一味的追讨责任,而是更好的改进测试方法、提升测试是能力。认真做好bug总结,对测试团队、测试个人的能力提升,都有很大的帮助。

你可能感兴趣的:(开发出现错误解决方案)