那份bug报告我至今记得。软件标题写着“登录按钮点击无反应”，测试优先级标了“紧急”，软件附了一张截图——按钮灰着，测试明显是软件禁用状态。开发看完直接把单子打回来，测试备注两个字：无效。软件提bug的测试人没注意到前置条件里写了“未勾选用户协议时按钮置灰”。这种事每周都在发生。软件

写bug报告不是测试写作文，不用铺垫情绪，软件不用交代心路历程。测试开发只想知道三件事：什么环境、软件怎么复现、测试实际结果和预期差在哪。软件我见过有人写了三百字描述自己点按钮时的心情，最后开发在评论区问“所以你到底用的哪个浏览器”。

标题是第一道过滤网。“支付失败”这种标题等于没写。改成“iOS 16 Safari 点击微信支付后页面白屏，控制台报 CORS 错误”，开发扫一眼就知道该查哪块代码。我习惯在标题里塞进平台、操作路径和错误现象，宁可长一点，也别让开发点进来才发现是另一个模块的问题。

复现步骤要像菜谱一样精确。别写“打开App进入设置页面”，要写“冷启动App → 底部Tab点‘我的’ → 右上角齿轮图标 → 通知设置 → 关闭‘接收推送’开关”。每一步都对应一个可点击的元素，别让开发猜。有人喜欢在步骤里夹带判断，比如“如果网络正常则继续”，这种分支逻辑直接拆成两个bug单，别混在一起。

实际结果和预期结果要分两栏写清楚。实际结果别写“页面显示异常”，写“页面顶部出现红色错误条，文案为‘网络请求超时’，但此时Wi-Fi信号满格”。预期结果别写“应该正常显示”，写“应展示用户头像和昵称，与设计稿v2.3一致”。开发最烦看到“不正常”三个字，你得告诉他什么才叫正常。

附件比文字更有说服力。录屏要带手指点击轨迹，截图要圈出问题区域，日志文件截取报错前后20行。我习惯把控制台报错完整复制到代码块里，别只截半句话。有一次前端开发说“你这报错不完整我没法查”，从那以后我连堆栈信息里的省略号都手动展开。

环境信息别偷懒。操作系统版本、浏览器版本、App构建号、测试账号角色、网络类型，这些字段少一个都可能让开发多花半小时排查。我见过一个bug只在4G网络下复现，Wi-Fi永远正常，提bug的人没写网络类型，开发查了一下午。

优先级和严重程度是两码事。严重程度看崩溃、数据丢失、核心流程阻断；优先级看业务影响面和修复成本。一个错别字严重程度低，但如果出现在支付成功页的金额旁边，优先级就得拉高。别动不动就标“致命”，开发会麻木的。

最后说个反直觉的：别在bug报告里教开发怎么改代码。你可以写“怀疑是接口返回的token过期时间字段类型不一致”，但别写“你应该把第87行的parseInt改成Number”。定位问题是开发的事，你负责把现场保护好。

写bug报告像写实验记录，客观、可重复、不带情绪。开发修完bug回头看你这份报告，能一次看懂，不用在IM里追问“你当时到底怎么操作的”，这就算合格了。