【测试篇】测试眼里的 BUG

文章目录

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

总结：

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