一个测试工程师在Jira上敲下“新增”按钮的软件那一刻，他可能觉得自己是测试正义的化身。但他不知道的提交是，三小时后，软件开发会在群里甩出一句：“这根本不是测试bug，是提交你环境没配对。”

我见过太多这样的软件场景了。刚入行那会儿，测试我也以为提交bug就是提交把“预期结果”和“实际结果”填进去，然后点保存。软件后来才发现，测试写bug报告这件事，提交一半是软件技术，一半是测试沟通艺术。

标题不是提交摘要，是钩子

很多人写标题喜欢图省事：“登录功能有问题”。开发看到这种标题，第一反应不是去查，而是先来问你“具体什么问题”。你等于逼着对方多问一轮，浪费的是两个人的时间。

好的标题应该让人一眼就知道去哪找、找什么。比如“Chrome 120下点击‘忘记密码’后页面白屏，控制台报TypeError”。版本、操作路径、现象、关键线索，全在标题里了。开发扫一眼就知道该翻哪段代码。

我自己的习惯是，标题里尽量带上复现概率。偶现的问题写“偶现”，必现的写“100%复现”。别小看这两个字，它直接决定了开发排查时的心态——偶现bug他会怀疑环境，必现bug他会怀疑自己。

复现步骤要像菜谱，别像散文

我收到过这样的bug描述：“用户登录后进入个人中心，然后操作了一下，页面就崩了。”什么叫“操作了一下”？点了哪个按钮？输入了什么内容？前一步的页面状态是什么？这些全没有。

写复现步骤的时候，把自己想象成一个从没碰过这个系统的人。每一步只做一件事，写清楚点击了什么、输入了什么、看到了什么。如果涉及测试数据，把数据也贴上去。比如“用账号test01/123456登录，进入订单列表，筛选状态为‘已取消’，点击第一条记录的‘查看详情’”。

有个同事教我一招：写完步骤后，自己照着走一遍。如果哪一步你自己都要想一下“我当时是怎么操作的”，那就说明写得不清楚。

截图和日志比嘴管用

文字描述再详细，也不如一张截图。但截图也有讲究——别只截最终报错的那个画面，把操作路径上的关键页面也截下来。我一般会截三张：操作前、操作中、报错后。开发拿着这三张图，基本能还原出你当时在干什么。

日志更是硬通货。浏览器控制台的报错、服务端的traceback、网络请求的响应体，能贴就贴。注意别只贴最后一行“500 Internal Server Error”，把完整的请求URL、请求参数、响应头都带上。开发看到这些，省去的是来回问你的时间。

别把“我觉得”当“它坏了”

有一次我提了个bug，说“搜索结果排序不合理”。开发回了一句：“排序规则是产品定的，你去问产品。”我当时挺尴尬的。后来我学乖了，提bug之前先确认三件事：需求文档怎么写的、设计稿怎么画的、接口文档怎么定义的。如果这三样都跟实际表现不一致，那才是bug。如果只是我觉得“应该这样”，那叫建议，不叫bug。

还有一类情况是环境问题。本地缓存没清、测试数据被污染、依赖服务挂了，这些都会让你误以为发现了bug。提交之前刷新一下页面、换个浏览器、清一下缓存，能过滤掉至少三成的假bug。

优先级不是你觉得急就急

“这个bug很严重，赶紧修！”——这话开发听了只会翻白眼。严重不严重，得看影响范围。主流程走不通、数据丢了、安全漏洞，这些是P0。页面样式错位、文案有错别字，那是P3。你把自己当成用户，问一句：这个问题会让用户没法用，还是只是用得不太爽？

我见过一个测试把所有bug都标成“紧急”，结果开发直接按提交时间倒序修，最后上线前一周还在改按钮颜色，核心的支付回调超时反而没人管。

提交bug这件事，说到底是在替用户踩坑。你踩得越细，开发填得越快，用户摔得越少。别把它当成走流程，它就是你跟开发之间最直接的那座桥。