如何描述一个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 的生命周期
• 跟开发起争执该怎么办？