【测试篇】测试眼里的 BUG

本文主要是介绍【测试篇】测试眼里的 BUG，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

如何描述一个bug

一个合格的bug描述应该包含以下几个部分：

1. 发现问题的版本
2. 问题出现的环境
3. 错误重现的步骤
4. 预期行为的描述
5. 错误行为的描述
6. 其他（每个公司的要求不太一样）
7. 不要把多个 bug 放到一起

如何定义 bug 的级别

bug 的定义每个公司都不一样，在定义前需要看公司的规范。

bug 级别的样例：

1. Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。
2. Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。
3. Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
4. Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

BUG 的生命周期

每个公司、每一个工具对 bug 生命周期的定义都是不一致的，下面仅是一个常见的例子。

• New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
• Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
• Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
• Rejected：如果认为不是Bug，则拒绝修改。
• Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
• Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
• Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。

跟开发起争执怎么办（高频面试题）

1. 测试人员经常会遇到那些情况

   • 这不是bug
   • 这个bug的级别提高了（背的BUG太多，会影响绩效）
   • bug影响不大，暂不修改。（不修改可能会产生线上的BUG）

2. 如果遇到上面的这些情况，我们QA该如何应对？？

   1. 批判性思维
      多反思自己，是不是Bug创建的时候描述不清楚
   2. 开发人员如果对Bug级别不认可，对Bug定级一定要有理有据。
      测试人员要明确企业Bug定级规范，拿着规范跟开发人员沟通为什么要这样定级
   3. 提Bug必定会增加开发人员的工作量，如果对于小问题开发人员不想改：
      此时就需要合理友好地进行沟通，站在用户的角度进行反问：如果您是用户，您能接受这样的功能吗？
   4. 不仅要能够发现问题，还要能够适宜地提出解决方案供开发参考，但是注意不能喧宾夺主。
   5. 如果确实是Bug，并且友好沟通已经不能解决问题，此时就召开Bug评审。
      （参会人员：产品代表、开发代表、测试代表…）
   6. Bug评审会讨论以下内容：
      ① 如何解决Bug
      产品代表、开发代表、测试代表…）
   7. Bug评审会讨论以下内容：
      ① 如何解决Bug
      ② 如何预防类似的Bug再发生

总结：

• 如何描述一个BUG
• 如何定义 bug 的级别
• BUG 的生命周期
• 跟开发起争执该怎么办？

这篇关于【测试篇】测试眼里的 BUG的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---