软件测试之—-如何提交高质量bug！！

你是否遇到这样的场景h4>

我想很多测试同学都遇到过这种问题，我也以前遇到这种问题，不过经过几年的打磨，现在极少数出现了，不能说百分百不出现，因为人与人之间的沟通理解肯定还是会有一些误差的。

现在的我，测试过程中，养成了几个习惯，希望可以帮到一些同学们：

1. 每一个bug都是在进行3/4遍相同操作后，才确定提交，保证我所提供的复现步骤精准，必现
2. 发生bug时，习惯性抓包，利用F12抓包，或者利用wireshark抓包
3. 发现bug，阅览运行日志，因为有这个习惯，我多次通过阅览log，帮开发找到了问题所在，当时那几个bug打印的日志是info类型
4. 每次出现异常，我都会记录在草稿上，持续跟踪；只是那些偶现的bug，都是因为没有找到复现步骤而已
5. 定期review bug，不是我闲着没事，而是针对容易发生bug的模块提高警惕，再次测试。
6. 在产品提测前，做好测试准备，分析需求文档。

bug标题： 1.BUG简洁描述，语句不宜太长；2.BUG标题尽量指明模块是前端还是后端，是pc端还是移动端，是android端还是ios端，或者是”个人中心”模块还是”设置”模块等等…；3.BUG标题能见题明意，能让开发一眼就能明白问题现象和可能原因。

严重等级： 开发根据bug的严重等级，可合理的安排修复工作，也可作为评估该项目质量的重要依据

致命：导致系统无法正常工作的bug。系统崩溃、数据丢失、数据毁坏、非法退出、内存溢出，500错误等。

严重：对系统功能影响较大的bug。比如错误结果、遗漏功能、数据丢失等

一般：表现为实现不符合需求/设计，但对系统而言影响一般的bug。

轻微：小问题、UI错误，文案提示，不影响功能，代码规范。

优先级： 优先级的高低是必填项，也跟严重等级挂钩存在的，直接决定bug需要在什么时间内修复

高：一般为严重bug，且需要尽快修复，最好是在下一个测试版本中得到修复并验证通过

中：流程类bug，且复现步骤不繁琐，易出现，会影响功能使用。产品发布前需修复并验证通过

低：针对轻微类型bug，或偶现bug和复现步骤繁琐，产品使用中不易出现，不影响主功能使用。可根据修复难度而选择性修复，该类bug可能会在代码重构或review时被修复

测试数据： 提供测试数据可方便开发更直接的重现bug，减少多余的交流时间，也可以证明测试同学的专业性，有理有据的表达bug。

测试环境： 为了更加清晰的描述bug，大可在提交bug的同时，将当时的测试环境也一并描述。比如（wifi环境，4g/5g，局域 /外 ，公 /私 等等…）

测试版本： 用来区分当前测试版本的版本 ，在提交bug时也要描述准确。

复现步骤： 需要写明操作步骤，如果遇到不太好描述的可结合视频，截图来提高描述清晰度；使开发可以根据你提供的操作步骤准确的复现出异常现象

bug现象：
1.bug现象可以用文字直接描述；
2.可提供发生异常时的截图；
3.发生异常时请求与响应的数据，最好直接截图；
4.提供发生异常时的日志；
5.抓包的数据