测试篇(二)： 如何合理的创建bug、bug的级别、bug的生命周期、跟开发产生争执怎么办
目录
- 一、如何合理的创建bug
- 二、bug的等级
- 三、bug的生命周期
- 四、和开发产生争执怎么办
一、如何合理的创建bug
创建Bug的目的就是为了能够让其他人可以尝试复现
一个合格的bug应该包含以下一个要素：
- 发现问题的版本
例如Web程序对应的浏览器版本，或某个应用程序的版本(QQ的版本) - 问题出现的环境
如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位 - 错误重现的步骤
使Bug重现的最短步骤 - 预期行为的描述
用户希望程序所表现出的行为 - 错误行为的描述
描述错误的现象，crash等可以上传log，UI问题可以截图 - 其他
一些其他的要求，例如故障的分类：功能故障、界面故障、兼容性故障等；优先级的分类：严重的Bug优先处理
二、bug的等级
bug等级的定义每个公司都不一致，在定义级别之前需要查看公司规范。但大体上可划分为以下四个等级
-
Blocker（崩溃）
阻碍开发或测试工作的问题，造成系统崩溃，死机，死循环，导致数据库丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等 -
Critical（严重）
系统主要功能丧失、数据库保存调用错误、用户数据丢失、一级菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出等，如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算错误，数值计算统计错误 -
Major（一般）
功能没有完全实现但是不影响使用，功能菜单存在缺陷但是不影响系统稳定性。如：操作时间过长、查询时间长、格式错误、边界条件错误、删除没有确认框等 -
Minor（次要）
界面、性能缺陷、建议类问题、不影响操作功能的执行，可以优化性能的方案等。如：错别字、页面显示重叠、描述不清楚、光标位置不对等
【为什么需要提bug等级？】
首先bug的等级和优先级有关，例如崩溃、严重级别的bug要优先处理，此外出现线上问题需要进行问题定级，定级会涉及到对应的惩罚范围，同时出现线上问题后需要开线上问题复盘会议(批斗大会)
三、bug的生命周期
每个公司、每个工具对bug生命周期的定义都是不一致的，下面只是其中一种
● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
●Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测试验证通过，则关闭Bug。
●Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
四、和开发产生争执怎么办
作为一名测试人员，一般会遇到以下几种情况：
- 这不是bug
- 这个bug的级别太高了
- bug影响不大，暂不修改
遇到争执不要怕，记住批判性思维：清楚–准确、切题–深刻，有意义，有逻辑性–公正、全面
- 先检查自身，是否bug描述不清楚
- 站在用户的角度考虑问题，反问开发人员，如果你是用户，你能接受这样的实现吗？
- bug的定级要有理有据
bug等级越严重，说明程序员在实现的时候出现的问题比较严重，就可能上升到工作态度和能力问题，bug等级对开发人员来说是非常敏感的 - 提高自身的技术和业务水平，不光能提出问题，最好也能提出解决方案
不仅能提出问题，还能给出解决方案，这样会让人更信服。例如，在工作中，会发现同一个bug，初级测试工程师和资深测试工程师提出，两者结果完全不同，两者的最大的差别在于资深工程师往往能给出解决方案。
案例：
某网站经常隔几天访问时会出现500错误，但是之后就不会复现。
测试人员会提出问题：网站偶发性出现500错误。
开发人员回答：不常见，不影响使用，暂不修改
资深测试人员提出问题：网站偶发性500错误，查看日志，是由于mysql数据库8小时超时问题造成。需要修改连接池配置定期校验连接
开发人员处理：修改xml，增加校验配置项
- 组织bug评审
如果已经经过了多轮沟通，但是开发人员仍然拒不接受，此时可以发起bug评审
bug评审应该包括如何处理bug和分析bug产生的原因，找出预防的对策
（1）决定如何处理bug，需邀请测试代表、开发代表、产品经理经理参加；测试代表主要从bug的具体表现，严重程度等方面提供信息，并提出自己对bug的处理意见。需要注意的是，测试人员不应该一味的要求对bug进行修改，因为修改可能带来回归的风险，同时带来的回归测试的工作量，如果时间比较紧迫，修改后剩余的时间若不足以做一次回归测试，可能不修改更好；
开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围，可能引发的风险等，如果决定修改，还要讨论出修改的初步方案
产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见
（2）分析bug产生的原因，找出预防对策
找出错误的根源，制定出相应的预防措施，确保同类型的bug不再出现