一. 如何创建Bug

创建Bug的要素：
问题出现的版本、问题出现的环境、出现步骤、预期结果、实际结果等。
提Bug：

标题：问题以及造成的影响
问题出现的版本：可以写浏览器版本【如果是QQ等的就写QQ版本，但是web项目是没有版本的】
问题出现的环境：硬件环境+软件环境（如果软件环境在问题版本中写了，这里就不用写了）
问题出现的步骤：其实也就是实际操作的步骤，用序号进行标注
预期结果：
实际结果：
Bug归属：前后端等（如果是后端出现问题，主要就是接口）
Bug等级：

补充：如果我们要检测的产品有很多版本，只需要关注用户使用较多的版本。通常情况下，企业都会有数据监控后台，能够监控当前产品的用户所使用的版本/环境。

二．Bug的级别

Bug存在不同的严重级别：崩溃、严重、一般、次要。

在公司中见到的Bug级别可能会更多，与这里的不一样，但是“万变不离其宗”。具体分类根据公司的规定。

Bug样例（仅供参考，具体以公司实际为准）

1）Blocker（崩溃）：
阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。
如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。
2）Critical（严重）：
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
3）Major（一般）：
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）
4）Minor（次要）：
界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

① 不同的Bug等级，惩罚机制不一样。
② 不同的Bug等级，也跟开发人员的开发质量有直接关系，也就是开发能力。
测试人员要先检查项目是否具有可测试性：冒烟测试
① 如果该项目有明显/主功能错误，或者是主流程走不通，测试人员进行项目的打回。
② 在测试人员测试之前，开发人员要进行单元测试、集成测试。

三．Bug的生命周期

测试人员在执行测试的过程中，如有发现Bug，就需要在Bug管理平台来创建Bug。（Bug生命起源）
Bug的状态：
① New：测试人员创建一个Bug
② Open：开发人员要去确认是否是Bug，是Bug则状态改为Open，不是就拒绝（Reject）
③ Fixed：开发人员在修复完成之后将Bug状态改为Fixed
④ Reject：开发人员确认不是Bug
⑤ Delay：确认是Bug之后，如果Bug优先级比较低且开发人员不能立即修复Bug，状态修改为delay
⑥ Closed：Bug确认修复完成之后，测试人员将Bug状态修改为closed
⑦ Reopen：Bug确认未修复完成，测试人员将Bug状态改为reopen

3.Bug状态转换图：

四．跟开发起争执怎么办【高频面试题】

原则：对事不对人

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