测试人员怎么对待Bug

1. • 测试人员如何描述发现的Bug

咱们提Bug至少要包含这个问题出现的版本，问题出现的环境，问题出现的步骤，预期结果，实际结果。但不限于标题，bug归属，bug等价等等

举个栗子😁

很容易发现二维码被登入页面挡住，对于这个bug，要怎么描述呢？

1. • 首先是标题

二维码被登入页面遮挡，导致二维码扫描失败

2. • 问题出现的版本

谷歌浏览器版本 108.0.5359.125（正式版本） （64 位）

3. • 问题出现的环境

windows11

注意：环境分为软件环境，硬件环境。如果是web项目，需要描述浏览器版本，客服机的操作系统；如果是app项目，需要描述机型，操作系统等等

4. • 问题出现的步骤

1.打开谷歌浏览器，输入网址；2.页面渲染完成，结果和预期不符

5. • 预期结果

二维码与登入板块不出现遮挡，二维码可以正常扫描

6. • 实际结果

二维码被遮挡，扫描失败

7. • bug归属

前端问题

8. • bug等级

次要

2. • 如何定义bug级别呢？

前言：bug每个公司的定义都不一样，具体看公司的规范

一般是崩溃，严重，一般，次要。

崩溃：连测试都测不了，直接系统崩溃，死机，死循环，数据库数据丢失
严重：能测试但主要功能丢失，用户数据丢失，与需求严重不符
一般：功能没完全实现但不影响使用，如操作/查询时间长，格式错误，边界条件错误，删除没确认框
次要：界面布局，性能缺陷，建议类问题。如错别字，格式不规范，页面遮挡，描述不清等等

3. • bug的生命周期是什么？

在了解生命周期之前，需要理解一些的概念

1. new:测试人员创建一个bug

2. open：开发人员确认是bug

3. fixed:开发人员对bug进行修复

4. rejected:开发人员不认为是bug

5. delay:开发人员确认是bug，由于bug等级低或有更重要的事情不能立即修复

6. reopen：bug被修复但是修复错误或引起其他bug，测试人员把bug状态改为reopen

7. closed:bug确认修复成功，测试人员把bug转态改为closed

生命周期流程图

测试人员发现bug标记为new ,开发人员对这个bug进行确认，如果认为不是rejected，如果是标记open.确认以后对bug进行修复fixed或者有更重要的事情去做就delay，过段时间还是得fixed。修复后经测试人员确认，如果还有bug,就要重新修复reopen。bug修复成功后标记closed

4. • 跟开发产生争执怎么办

作为测试人员在找bug过程中避免不了和开发人员冲突，所以应该怎么办呢？

1. 评判性思维：多反思自己，是不是bug创建的时候描述不清楚

2. 如果开发人员对bug级别不认同：测试人员要明确企业对bug定级规范，拿着标准跟开发人员进行沟通，告诉他为什么这样定级

3. 如果开发人员认为小问题不想解决：测试人员要和开发人员友好沟通，站在用户的角度反问他如果你是用户，你能接收这样的功能吗？

4. 咱们不仅能够提出bug,最好也能给出解决方案

5. 如果确实是bug，和开发人员沟通已经不能解决问题，只能召开bug评审