👑目录
什么是bug❓
如果软件有明确的需求规格说明书并且是正确的，那么程序的行为与规格说明不一致的部分就是bug。
当出现需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是bug
描述bug的必要元素⭐
目的：为了让开发人员知道如何复现bug
描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果
若是web系统，这里的版本是浏览器的版本；若是app，则版本就是软件的版本。
bug级别📚
bug级别一般分为：崩溃、严重、一般、次要
对于不同的企业来说，bug等级可能稍有不同，但万变不离其宗
bug的生命周期❤️
new：新发现的bug，没有经评审决定是否指派给开发人员进行修改。
open：确认是bug，并且认为需要进行修改，指派给相应的开发人员。
rejected：开发人员认为不是bug，拒绝修改。
fixed：开发人员修改后标识成修改状态，有待测试人员的回归测试验证。
delay：如果认为暂时不需要修改或暂时不能修改，则延后修改。
closed：修改状态的bug经过测试人员的回归测试验证通过，则关闭bug。
reopen：如果经验证bug仍然存在，则需要重新打开bug，开发人员重新修改。
与开发产生争执怎么办（高频考题）🆘
当我们因为向开发人员提出bug而和他们产生争执该怎么做？
1、先检查自身，看看是否bug描述不清楚或者是不是在测试过程中出现了误操作
2、站在用户角度考虑并抛出问题
"如果你是用户，你会接受这样的功能/界面/使用吗？"
3、bug定级要有理有据：将bug定级描述文档拿出来，将bug的表现和bug定级描述文档进行匹配，说服开发人员
4、提高自身技术和业务水平，做到不仅能提出问题，最好也能给出解决方案（建议，不是命令）
5、bug评审（++最后说++）
如果确实是bug，当和开发沟通无果，那就召开bug评审。
bug评审额外还需要三个代表来参加：测试代表、开发代表、产品代表
bug评审主要解决两个问题：
决定如何处理bug；
分析缺陷产生的原因，找出预防的对策。