测试同学在禅道里点下“提交Bug”按钮之前，禅道程最好先确认一件事：你复现的提交步骤是不是真的能稳定触发问题。上周我们项目组就闹过笑话，禅道程前端小李提了个“登录按钮点击无反应”的提交Bug，开发老张查了半天，禅道程最后发现是提交小李自己浏览器开了广告拦截插件，把请求给拦了。禅道程这种Bug提上去，提交除了浪费双方时间，禅道程没别的提交用处。

禅道的禅道程Bug提交入口藏在“测试”视图下的“Bug”菜单里，点“提Bug”就能打开表单。提交表单字段不少，禅道程但真正决定这个Bug能不能被快速处理的提交，就那么几个。禅道程

所属产品、所属模块、影响版本——这三项必须填对。产品选错，Bug直接进了别的项目组，等人家找过来问“这什么东西”，你再去改，流程已经拖了半天。模块定位不准，开发得自己猜问题出在哪个功能块。影响版本更关键，不填的话，开发不知道从哪个分支开始查，尤其是多版本并行开发的时候，瞎查一通。

Bug标题要一句话说清问题现象和触发条件。别写“有个Bug”或者“页面报错”，这种标题在列表里毫无辨识度。好的标题像“订单列表页翻到第3页时点击导出按钮报500错误”，开发扫一眼就知道去哪找代码。

严重程度和优先级是两码事。严重程度看问题对系统的影响，比如崩溃、数据丢失算致命，界面错位算轻微。优先级看修复的紧急程度，有时候一个界面错位优先级反而高，因为老板明天要演示。这两项填反了，开发可能先修了不着急的，把线上正在出问题的晾在一边。

复现步骤是Bug单的灵魂。写清楚：从哪个页面开始，点了什么按钮，输入了什么数据，看到了什么结果，期望的结果是什么。别写“跟之前那个Bug一样”，也别贴一大段日志就完事。日志放附件里，步骤写在正文。步骤要编号，一步一行，别挤成一团。

附件能加截图就加截图，能录屏就录屏。文字描述再详细，也不如一张标注了错误位置的截图来得直接。禅道支持粘贴截图，Ctrl+V就行，别偷懒。

提交之前，用搜索功能查一下，这个Bug是不是已经有人提过了。重复Bug被合并，提Bug的人脸上不好看。搜索关键词用报错信息里的核心词，或者功能模块名。

提交之后，Bug状态默认是“激活”，指派给对应的开发。如果不知道指派给谁，先给测试负责人或者开发负责人，让他们转。别把Bug挂在自己名下不管，那跟没提一样。

开发修复后会把状态改成“已解决”，并填写解决方案，比如“已修复”“设计如此”“重复Bug”“无法重现”等。这时候测试要验证，验证通过就关闭，验证不通过就重新激活，并在备注里写清楚为什么没通过。别只写“还是有问题”，要写“在同样的步骤下，第3步点击导出按钮仍然报500错误，附件是新截图”。

有个细节很多人忽略：关闭Bug的时候，禅道会要求填写“关闭原因”。选“已解决”还是“重复Bug”还是“不予解决”，这个记录会影响后续的统计报表。选错了，月底看Bug趋势图的时候数据就对不上。

还有，别在Bug单的评论里跟开发吵架。有问题当面说，或者拉个群说。禅道的评论记录是留痕的，写上去就删不掉。我见过两个同事在Bug评论里互相阴阳怪气，后来被项目经理截图发到大群，场面极其尴尬。

流程本身不复杂，复杂的是人。把该填的填清楚，该验证的验证到位，禅道里的Bug单就是项目质量的真实记录。糊弄它，最后糊弄的是自己。