关于bug的生命周期的几个阶段

Posted 2020-11-01 bella-xia

对于一名测试人员，bug的生命周期一般分为：发现bug → 提交bug → 验证bug → 关闭bug

具体可分为三个阶段：

第一阶段：发现bug

场景：

"测试不就是发现bug吗，有什么技术含量？”

思考:

当发现一个bug，除了尽快报告问题以外，我们还能做哪些事情？

回答：

 测试人员发现bug，花些时间细细品味

1)  这个bug复现的必要条件是什么？

2)  除了发现bug的这条路径，是否还有更多的路径也会导致相同的问题？

3)  bug是否存在可能影响其它数据或者其它应用的副作用？

4)  其它功能模块是否也存在类似问题？

5)  bug的复现路径是否在用户可达之路上？

6)  复现bug的路径是否在测试用例中？有没有可借鉴性？

 

通过以上分析，我们可能获得以下额外收获：

1)  通过bug的定位，确认必现路径、可能的原因，帮助开发快速定位、解决问题

2)  通过bug的路径、影响范围等分析，发掘更多的隐藏bug

《探索式测试》-恶邻测试法：重灾区往往会有更多的bug

3)  通过分析操作路径，补充测试用例，扩展测试用例范围、思路

 

第二阶段：提交bug

场景:

      测试人员提交bug，没有详尽说明，开发无从下手，并找不出bug原因，决定不与修改

思考：如何才能提交一个有效的bug？

回答：

1.   确保bug有效。

    1）不要因为环境问题或者是操作错误引起“bug”

    2）不要提交一些重复的bug

2.   写好bug描述。

    1）bug描述精确、没有歧义，详细简洁的测试步骤。

    2）保证各个字段内容与实际现象一致。比如：版本、复现率等

    3）对于复现率低的问题，尽可能提供一些可参考信息：截图、视频、日志、可能的步骤、可能原因等（如果你能通过各种手段定位到问题的原因，开发大神也会对你刮目相看的）

    4）对于特殊的测试场景，附带相关的数据，比如1024kb的图片等

 

第三阶段：验证bug

场景：

      对于测试新手而言，对于bug验证，往往是按照步骤验证复现，如果没有问题就关闭了

思考：如何做好bug的回归验证？

回答：

1.  确认好bug的复现前提及操作步骤。

2.  确认bug产生的原因及修复方法。

   1） 明确bug产生的原因，触类旁通，分析其他模块可能存在的问题

   2 )  通过bug产生的原因，积累测试经验，扩展测试思路

   3） 通过bug的修改方法，分析修改是否能修复问题？是否回引发其他问题？

   4） 积累bug经验，在后续相关问题发现时，快速定位问题，提供解决思路

3.  确认bug的回归范围及用例。

     在了解清楚bug产生的原因及修复方法基础上，再根据业务关联、功能模块关联确认回归范围，确保bug修复全面且没有引起新的bug

第四阶段：关闭bug

   如果测试人员经过再次测试之后确认bug 已经被解决之后，就将bug的状态设置为“Closed”