文章目录
-
- 如何描述一个bug
- [如何定义 bug 的级别](#如何定义 bug 的级别)
- [BUG 的生命周期](#BUG 的生命周期)
- 跟开发起争执怎么办（高频面试题）
如何描述一个bug
一个合格的bug描述应该包含以下几个部分：
- 发现问题的版本
- 问题出现的环境
- 错误重现的步骤
- 预期行为的描述
- 错误行为的描述
- 其他（每个公司的要求不太一样）
- 不要把多个 bug 放到一起
如何定义 bug 的级别
bug 的定义每个公司都不一样，在定义前需要看公司的规范。
bug 级别的样例：
- Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。
- Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。
- Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
- Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
BUG 的生命周期
每个公司、每一个工具对 bug 生命周期的定义都是不一致的，下面仅是一个常见的例子。
- New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
- Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
- Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
- Rejected：如果认为不是Bug，则拒绝修改。
- Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
- Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
- Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
跟开发起争执怎么办（高频面试题）
-
测试人员经常会遇到那些情况
- 这不是bug
- 这个bug的级别提高了（背的BUG太多，会影响绩效）
- bug影响不大，暂不修改。（不修改可能会产生线上的BUG）
-
如果遇到上面的这些情况，我们QA该如何应对？？
- 批判性思维
多反思自己，是不是Bug创建的时候描述不清楚 - 开发人员如果对Bug级别不认可，对Bug定级一定要有理有据。
测试人员要明确企业Bug定级规范，拿着规范跟开发人员沟通为什么要这样定级 - 提Bug必定会增加开发人员的工作量，如果对于小问题开发人员不想改：
此时就需要合理友好地进行沟通，站在用户的角度进行反问：如果您是用户，您能接受这样的功能吗？ - 不仅要能够发现问题，还要能够适宜地提出解决方案供开发参考，但是注意不能喧宾夺主。
- 如果确实是Bug，并且友好沟通已经不能解决问题，此时就召开Bug评审。
（参会人员：产品代表、开发代表、测试代表...） - Bug评审会讨论以下内容：
① 如何解决Bug
产品代表、开发代表、测试代表...） - Bug评审会讨论以下内容：
① 如何解决Bug
② 如何预防类似的Bug再发生
- 批判性思维
总结：
- 如何描述一个BUG
- 如何定义 bug 的级别
- BUG 的生命周期
- 跟开发起争执该怎么办？