bug报告模板

上周三凌晨两点，报板测试组的告模小陈在群里甩了张截图：用户头像全变成了灰色方块。开发老张回了句“重启试试”，报板运维李哥直接发了服务器负载曲线——CPU飙到98%。告模这就是报板一个典型bug现场，而写报告的告模人如果只写“头像显示异常”，这锅得再炖三天。报板

我见过最离谱的告模bug报告来自某电商后台：“点提交没反应”。没了。报板开发拿着这张纸条像算命的告模，从按钮样式查到接口超时，报板最后发现是告模运营把商品下架了。另一个极端是报板二十页的Word文档，带目录和修订记录，告模最后结论是报板“建议优化代码质量”。写报告的人得明白：你不是在写小说，也不是在写判决书。

标题要像急诊分诊单

“登录页验证码不刷新”比“登录模块异常”有用十倍。如果bug出现在支付流程，标题直接写“微信支付回调后订单状态仍为待支付”。别用“偶现”“疑似”这种词开头，把确定的事实放前面。我习惯在标题里塞进版本号，比如“v2.3.1安卓端购物车数量角标不更新”——开发扫一眼就知道该翻哪天的提交记录。

环境信息不是填空题

“Windows 10”太笼统。是专业版还是家庭版？补丁打到几月？浏览器是Chrome 118还是119？我们组里有个经典案例：某bug只在iOS 15.4的Safari上出现，因为那个版本对CSS的:has()选择器支持有缺陷。写环境时把设备型号、系统版本、网络类型（4G/WiFi/弱网）全列上。如果是服务端问题，把请求的traceId贴出来，比说一百句“接口报错”都管用。

复现步骤别写“然后”

“打开APP，然后点我的，然后往下滑，然后点设置”——这种“然后”体看着累。直接编号：

1. 冷启动APP（版本3.2.0）
2. 未登录状态下点击“我的”
3. 在登录页输入已注册手机号，获取验证码
4. 输入错误验证码点击登录

关键在第四步之后：是弹窗提示“验证码错误”但页面卡死，还是直接闪退？把预期结果和实际结果分两行写。我见过有人把“预期结果”写成“应该正常”，这等于没说。正常是什么？是跳转到首页，还是停留在登录页并清空输入框？

附件比描述更诚实

录屏文件别超过15秒，聚焦在bug发生的那几秒。截图用红框圈出异常位置，别发全屏截图让人找茬。日志文件截取关键报错行，比如“java.lang.NullPointerException at OrderService.java:217”。如果是前端问题，把Console面板的报错和Network面板的失败请求一起截。有次我收到一份报告，附件是段屏幕录像，里面测试人员边操作边自言自语：“哎你看又白了，这破玩意儿”——比任何文字描述都直观。

严重程度自己先掂量

别把所有bug都标“致命”。判断标准很简单：影响多少用户？有没有绕过方案？会不会丢数据？支付金额算错是P0，个人中心头像不显示是P3。我们内部有个土办法：如果这个bug发生在你给老板演示的时候，你会不会冒冷汗？会，就往上调一级。另外，别在报告里写“建议尽快修复”——优先级由产品和开发定，你只需要把事实摆清楚。

最后说个真事。上个月有个新来的测试，报告里写了句“该问题在小米10上必现，但同事的小米11正常”。开发一看，直接去查机型适配代码，两小时就修完了。好的bug报告不是八股文，是给修车师傅递扳手——你得告诉他哪个螺丝松了，而不是说“车有点不对劲”。