测试篇(二)： 如何合理的创建bug、bug的级别、bug的生命周期、跟开发产生争执怎么办

一、如何合理的创建bug

创建Bug的目的就是为了能够让其他人可以尝试复现
一个合格的bug应该包含以下一个要素：

1. 发现问题的版本
   例如Web程序对应的浏览器版本，或某个应用程序的版本(QQ的版本)
2. 问题出现的环境
   如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位
3. 错误重现的步骤
   使Bug重现的最短步骤
4. 预期行为的描述
   用户希望程序所表现出的行为
5. 错误行为的描述
   描述错误的现象，crash等可以上传log，UI问题可以截图
6. 其他
   一些其他的要求，例如故障的分类：功能故障、界面故障、兼容性故障等；优先级的分类：严重的Bug优先处理

二、bug的等级

bug等级的定义每个公司都不一致，在定义级别之前需要查看公司规范。但大体上可划分为以下四个等级

1. Blocker（崩溃）
   阻碍开发或测试工作的问题，造成系统崩溃，死机，死循环，导致数据库丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等

2. Critical（严重）
   系统主要功能丧失、数据库保存调用错误、用户数据丢失、一级菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出等，如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算错误，数值计算统计错误

3. Major（一般）
   功能没有完全实现但是不影响使用，功能菜单存在缺陷但是不影响系统稳定性。如：操作时间过长、查询时间长、格式错误、边界条件错误、删除没有确认框等

4. Minor（次要）
   界面、性能缺陷、建议类问题、不影响操作功能的执行，可以优化性能的方案等。如：错别字、页面显示重叠、描述不清楚、光标位置不对等

【为什么需要提bug等级？】

首先bug的等级和优先级有关，例如崩溃、严重级别的bug要优先处理，此外出现线上问题需要进行问题定级，定级会涉及到对应的惩罚范围，同时出现线上问题后需要开线上问题复盘会议(批斗大会)

三、bug的生命周期

每个公司、每个工具对bug生命周期的定义都是不一致的，下面只是其中一种

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

四、和开发产生争执怎么办

作为一名测试人员，一般会遇到以下几种情况：

• 这不是bug
• 这个bug的级别太高了
• bug影响不大，暂不修改

遇到争执不要怕，记住批判性思维：清楚–准确、切题–深刻，有意义，有逻辑性–公正、全面

1. 先检查自身，是否bug描述不清楚
2. 站在用户的角度考虑问题，反问开发人员，如果你是用户，你能接受这样的实现吗？
3. bug的定级要有理有据
   bug等级越严重，说明程序员在实现的时候出现的问题比较严重，就可能上升到工作态度和能力问题，bug等级对开发人员来说是非常敏感的
4. 提高自身的技术和业务水平，不光能提出问题，最好也能提出解决方案
   不仅能提出问题，还能给出解决方案，这样会让人更信服。例如，在工作中，会发现同一个bug，初级测试工程师和资深测试工程师提出，两者结果完全不同，两者的最大的差别在于资深工程师往往能给出解决方案。

案例：
某网站经常隔几天访问时会出现500错误，但是之后就不会复现。
测试人员会提出问题：网站偶发性出现500错误。
开发人员回答：不常见，不影响使用，暂不修改
资深测试人员提出问题：网站偶发性500错误，查看日志，是由于mysql数据库8小时超时问题造成。需要修改连接池配置定期校验连接
开发人员处理：修改xml，增加校验配置项

4. 组织bug评审
   如果已经经过了多轮沟通，但是开发人员仍然拒不接受，此时可以发起bug评审
   bug评审应该包括如何处理bug和分析bug产生的原因，找出预防的对策
   （1）决定如何处理bug，需邀请测试代表、开发代表、产品经理经理参加；测试代表主要从bug的具体表现，严重程度等方面提供信息，并提出自己对bug的处理意见。需要注意的是，测试人员不应该一味的要求对bug进行修改，因为修改可能带来回归的风险，同时带来的回归测试的工作量，如果时间比较紧迫，修改后剩余的时间若不足以做一次回归测试，可能不修改更好；
   开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围，可能引发的风险等，如果决定修改，还要讨论出修改的初步方案
   产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见
   （2）分析bug产生的原因，找出预防对策
   找出错误的根源，制定出相应的预防措施，确保同类型的bug不再出现