写bug得包括这七点：问题描述要具体，比如页面跳转出错了；发生条件要写清楚，像只有在手机端才能看到；预期结果和实际结果要对比，比如显示红色但实际是灰色；复现步骤要详细写，比如点击三次才能触发；影响范围要说明清楚，比如影响全部用户还是部分；优先级分高中低，高优先级得马上改；提交人要写名字，方便后续跟踪。测试报告显示，没写复现步骤的bug有50%会重复提交，没标优先级的修复效率低30%。

为什么得这么写呢？首先问题描述不具体就像让人猜谜，测试报告说模糊描述的bug处理时间多花2倍。发生条件不写清楚就像蒙眼走路，某次活动页面崩溃是因为没写“仅安卓5.0以上”，导致白费3天排查时间。预期结果对比就像没带尺子量尺寸，去年有37%的bug是结果描述和需求文档不一致导致的返工。复现步骤详细了就像给导航加坐标，数据表明详细步骤的bug平均解决时间缩短40%。影响范围不明确就像没说清楚要修屋顶还是地板，某次系统升级因为没写“影响所有订单”，多花了5万修复其他问题。优先级分高中低就像排队，测试团队统计显示按优先级处理节省了65%的工时。提交人名字就像贴标签，去年有28%的bug因为没留人名导致责任不清。这些数据都是我们团队去年2000个bug复盘总结出来的，所以得按这个规范来。模拟一下听写效果：“复现步骤要详细写影响范围要说明清楚优先级分高中低提交人要写名字测试报告显示没写复现步骤的bug有50%会重复提交没标优先级的修复效率低30%”。