1.如何描述一个 bug

发现问题的版本 -> 例如谷歌浏览器 111.0.5563.65（正式版本） （64 位）
发现问题的环境 -> windows10 家庭版.
发现问题的步骤 -> 例如在浏览器输入某某某链接, 然后在页面对应的搜索框中输入空格.
预期结果 -> 显示所有内容.
实际结果 -> 没有显示任何内容.
.......

2. bug 等级

bug 的等级分为崩溃, 严重, 一般, 次要.

崩溃

阻碍开发或测试工作的问题. 如：代码错误、死循环、数据库发生死锁等等.

严重

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失等等.

一般

功能没有完全实现但是不影响使用，功能存在缺陷但不会影响系统稳定性. 如 : 操作时间长、
查询时间长、格式错误、边界条件错误等等.

次要

不影响操作功能的执行的问题，或者是可以优化性能的方案等等. 如错别字, 界面格式不规范.

3. bug 的生命周期

1. New : bug 创建完成之后的初始状态.
2. Open : 确认是否是 bug.
3. Fixed : 开发人员修改 bug 后的状态, 等待测试人员回归测试.
4. Rejected : 开发人员认为不是 bug, 拒绝修改.
5. Delay : 认为暂时不需要修改或者暂时不能被修改, 则延迟修改
6. Closed : 修改后的 bug, 经测试人员的回归测试, 验证通过, 则关闭 bug.
Reopen : 如果经验证 bug 仍然存在, 则需要重新打开 bug, 开发人员需要重新修改.

上述几个状态就好比, 某一天你的女朋友发现你晚上偷偷溜去网吧打游戏了, 这个时候提出问题 :

4. 与开发产生争执怎么办

作为一名测试人员, 当我们给开发提 bug 的时候, 一般会遇到以下几种情况 :

• 这不是 bug

• 这个 bug 的级别太高了

• bug 影响不大. 暂时不修改

如何妥善处理

1. 先检查自身, 是否是 bug, 或者 bug 描述不清楚.
2. 检查之后确认真的是 bug, 可以站在用户的角度考虑问题.
可以反问 : 如果你是用户, 你能接受这样的实现吗 ?
3. bug 定级要有理有据, bug 等级对于开发人员来说是非常敏感的.
bug 等级越严重, 说明程序员在实现上出现的问题比较严重, 就可能上升到工作态度问题? 开发能力 问题 ?
4. 不光能提出问题, 最好也要能提出解决方案.
5. 组织 bug 评审 (对事不对人)
邀请代表人参加 : 产品代表, 开发代表, 测试代表
bug 评审会议要解决以下问题 :
1) 如何修改bug
2) 如何避免类似的问题发生