Bug 回报的艺术：让开发者秒懂的 Bug Report 写法

1. Bug Report 是 QA 的名片

2. 完美的 Bug Report 模板

• 标题

  [模组] 简洁描述问题

• 严重度

  P0 / P1 / P2 / P3

• 环境

  OS / 浏览器 / App 版本 / 测试环境

• 前置条件

  需要什么状态才能重现

• 重现步骤

  1-2-3 步骤清楚可重现

• 预期 vs 实际结果

  应该发生什么 vs 实际发生了什么

• 附件

  截图 / 录影 / Log

• 备注

  发生频率、相关 ticket 等

3. 严重度分级标准

• P0 - Blocker

  系统无法使用、资料遗失、安全漏洞。例：登入功能完全失效、付款扣错金额

• P1 - Critical

  主要功能异常，无 workaround。例：搜寻结果错误、无法完成核心流程

• P2 - Major

  功能有问题但有 workaround。例：汇出功能失败但可用其他方式取得资料

• P3 - Minor

  不影响功能的小问题。例：文字错字、对齐微调、非核心页面样式

4. 好 Bug Report vs 坏 Bug Report

5. Bug 回报的沟通技巧

• 客观描述

  描述「发生了什么」而不是「谁做错了」

• 提供上下文

  这个 bug 影响多少使用者？有没有 workaround？

• 主动追踪

  修复后主动验证，确认问题已解决

• 分辨 bug vs feature

  不确定是 bug 还是设计如此？先问再报

6. Bug 追踪工具推荐

• Jira

  业界标准，功能强大但学习曲线高

• Linear

  现代化介面，速度快，适合中小团队

• GitHub Issues

  与程式码库整合，适合开源专案

• Bugzilla

  老牌工具，稳定可靠

• Notion

  灵活的资料库，适合小团队快速上手

7. QA 和开发的关系