测试组的录表小林上周提了个bug，开发修完随手在群里回了句“已解决”。模板三天后版本上线，录表同一个功能又炸了。模板翻聊天记录才发现，录表没人记得当时到底改了什么、模板影响范围有多大。录表这种事我见得太多了——不是模板技术不行，是录表根本没把bug当回事去记录。

一份能用的模板bug记录表，核心就三件事：让提的录表人说清楚，让修的模板人看明白，让后面的录表人查得到。

别搞那些花里胡哨的模板字段

很多团队一上来就整几十个字段，什么严重等级、录表优先级、复现概率、模块分类、关联需求……填完一张表比写代码还累。结果就是没人认真填，全填“一般”“偶现”“其他”。

我见过最离谱的一张bug表，光“问题类型”下拉菜单就有47个选项。开发点开一看直接关掉，转头在群里问“你说的那个bug具体啥情况”。

字段控制在10个以内。必须有的：标题、复现步骤、预期结果、实际结果、环境信息、截图或日志、提交人、提交时间、状态、处理人。就这些。其他信息在沟通中补，别指望一张表装下所有。

<table> <tr><th>字段</th><th>说明</th></tr> <tr><td>标题</td><td>一句话说清“在哪、做什么、出了什么错”</td></tr> <tr><td>复现步骤</td><td>编号写，每步一个动作</td></tr> <tr><td>预期结果</td><td>你认为应该发生什么</td></tr> <tr><td>实际结果</td><td>实际发生了什么，带报错信息</td></tr> <tr><td>环境</td><td>系统、浏览器、App版本、测试账号</td></tr> <tr><td>附件</td><td>截图、录屏、日志文件</td></tr> <tr><td>状态</td><td>新建/处理中/待验证/已关闭/重开</td></tr> </table> 

标题写不好，后面全是坑

“登录有问题”——这种标题等于没写。哪里有问题？是闪退、报错、还是按钮点不动？

好的标题长这样：“iOS 16 Safari 点击微信登录按钮无响应，控制台报 CORS 错误”。谁看都知道去哪查、查什么。

我自己的习惯是标题里塞进三个要素：平台/环境 + 操作路径 + 现象。哪怕多打几个字，也比后面来回问强。

复现步骤不是写小说

有人写复现步骤像写日记：“我先打开App，然后想了想点了我的页面，哦对了之前我还切了个账号……”这种没法用。

直接编号：

1. 打开App，进入“我的”页面
2. 点击右上角设置图标
3. 选择“账号与安全”
4. 点击“更换手机号”
5. 输入新手机号，点击获取验证码
6. 页面白屏，控制台报500错误

每一步一个动作，不掺废话。如果复现概率不是100%，在后面加一句“10次里出现3次”。

状态流转要卡死

最怕的状态是“已解决”——谁解决的？怎么解决的？验证了没有？

我要求团队用这几个状态，不允许自己发明：

• 新建：测试提的，还没人认领
• 处理中：开发认领了，正在查
• 待验证：开发说修完了，等测试确认
• 已关闭：测试验证通过
• 重开：验证不通过，打回去

关键在“待验证”和“已关闭”之间必须由测试操作。开发自己改完直接关掉？不行。我见过太多次开发说“修好了”，结果测试一验根本没修对，或者修A坏B。

留一个“备注”字段给未来

修完一个bug，顺手在备注里写一句根本原因。比如“用户token过期后未清除本地缓存导致死循环”。

这句话三个月后可能救你一命。下次遇到类似问题，搜一下备注就能找到线索。不写的话，同样的坑换个地方再踩一遍。

我现在的习惯是每周五花20分钟翻一遍本周关闭的bug，把备注里写着“根因不明”或者空白的挑出来，找对应开发补上。不补？下周周会上直接投屏。

bug记录表不是什么高深工具，它就是团队记忆的底稿。写清楚了，省下的是所有人的时间。