Bug报告写得清楚，修复就能少走弯路。本文提供一份可直接复制使用的Bug报告模板，把现象、复现、环境、影响、证据五类信息固定为字段，并逐项说明填写口径、必填与选填的划分，附一条完整填写示例和模板维护方法，适合研发、测试与业务反馈转记场景使用。
要点总览（TL;DR）
- 模板按基本信息、复现信息、影响与分级、证据与流转四组组织，共15个字段，可整表复制到文档、工单或缺陷管理工具中使用。
- 必填字段为标题、发现版本与环境、复现步骤、预期结果与实际结果、严重程度；界面类缺陷还需附截图或录屏。
- 复现步骤一步一个动作并写出具体输入数据，预期结果引用需求或用例依据，实际结果原样记录提示文案与页面状态。
- 严重程度描述缺陷对功能与数据的破坏程度，优先级描述修复紧迫性，两者分开填写并各自给出理由。
- 模板调整需经评审并同步更新模板、字段说明与示例，每季度或每个大版本复盘字段填写率与被退回比例。
可复制空白Bug报告模板
下面这张表按四组信息组织：基本信息、复现信息、影响与分级、证据与流转。使用时整表复制到文档、工单或缺陷管理工具中，逐行填写即可。表格中的“填写提示”列是给填表人的引导，正式提交前可以删除。
| 信息组 | 字段名 | 填写栏 | 填写提示 |
|---|---|---|---|
| 基本信息 | 标题 | 一句话说清“在什么场景下发生了什么问题” | |
| 缺陷编号 | 由缺陷管理系统自动生成，手工记录时按团队规则编号 | ||
| 发现版本与环境 | 版本号、操作系统、浏览器或设备、测试/生产环境 | ||
| 提交人与提交日期 | 填写发现人和首次记录时间 | ||
| 复现信息 | 前置条件 | 复现前需要满足的账号、数据、配置状态 | |
| 复现步骤 | 按操作顺序编号，一步一个动作 | ||
| 预期结果 | 依据需求或常识，系统应该表现成什么样 | ||
| 实际结果 | 系统实际表现，含报错文案或异常现象 | ||
| 影响与分级 | 严重程度 | 描述缺陷对功能与数据的破坏程度 | |
| 优先级 | 描述修复的紧迫性与排期顺序 | ||
| 影响范围 | 受影响的用户、模块、数据量或业务流程 | ||
| 证据与流转 | 附件证据 | 截图、录屏、日志、请求响应，按规则命名 | |
| 复现概率 | 必现、偶现或特定条件下出现，注明尝试次数 | ||
| 处理人与状态 | 当前负责人与流转状态 | ||
| 关联需求或用例 | 对应的需求编号、测试用例编号 |
如果使用纯文本形态，可以按“字段名：内容”逐行书写，字段顺序与上表保持一致，便于他人阅读和后续录入系统。两种形态的内容应完全对应，不要一边填表一边另起一套字段。
每个字段填什么：字段说明与填写口径
模板能否发挥作用，取决于每个字段是否按统一口径填写。以下逐项说明含义、写法要求与常见错误。
标题与基本信息
标题要让没看过缺陷的人一眼判断问题所在，推荐结构为“场景＋操作＋异常现象”，例如“结算页提交订单后提示‘系统繁忙’且订单未生成”。避免只写“下单报错”“页面有问题”这类无法定位的标题。发现版本与环境要写到可复现的粒度：版本号、操作系统、浏览器及版本、设备型号，涉及服务端的补充接口环境。环境信息缺失是缺陷被退回补充的最常见原因之一。
前置条件与复现步骤
前置条件写清复现前系统需要处于什么状态，例如“账号已绑定手机号且购物车中有两件商品”。复现步骤按操作顺序编号，一步只写一个动作，涉及输入数据时把具体数据写出来，不要写“随便输入一些内容”。步骤数量以他人能独立照做为标准，通常三到八步；步骤过多时检查是否混入了无关操作。
预期结果与实际结果
预期结果要有依据，优先引用需求文档、设计稿或测试用例的条款，没有明确依据时说明依据的是通用交互常识。实际结果如实记录看到的提示文案、页面状态和数据变化，报错信息原样粘贴，不要概括成“报错了”。预期与实际要一一对应，避免预期写三点、实际只写一点，导致修复人无法判断差异范围。
严重程度与优先级
这两个字段口径不同，不能互相替代。严重程度描述缺陷本身对功能和数据的破坏程度，由缺陷性质决定，例如导致数据丢失、核心流程阻断、界面文案错误分属不同等级。优先级描述修复的紧迫性和排期顺序，受发布计划、影响用户量、是否有临时规避方案影响。一个严重程度高的缺陷，如果已有临时方案且不影响本次发布，优先级可以排后；一个严重程度低的文案错误，如果出现在对外首页，优先级也可能提前。具体分级标准由团队在缺陷分类规范中定义，本文只强调两者分开填写、分别给理由。
附件证据
证据类型包括界面截图、操作录屏、客户端或服务端日志、接口请求与响应。截图要包含能定位问题的上下文，例如页面地址、时间、账号标识；日志截取异常发生前后的一段，不要只贴一行报错。命名建议采用“缺陷编号_证据类型_序号”，如“BUG-1024_截图_01”，便于在附件列表中排序和检索。涉及用户隐私的数据在提交前脱敏。
流转字段
提交人记录发现者，便于后续澄清细节；处理人记录当前负责人，状态记录缺陷所处环节，如待确认、已确认、修复中、待验证、已关闭。流转字段的价值在于让每个缺陷都有明确的责任人和下一步动作，避免记录后无人跟进。状态选项由团队统一定义，个人不要自行新增状态名称。
必填与选填：按提交场景划分字段等级
所有字段都强制填写会拖慢提交速度，全部选填又会导致信息残缺。建议按下面的分级执行，并根据场景调整松紧。
| 字段 | 等级 | 理由与适用场景 |
|---|---|---|
| 标题 | 必填 | 检索与分派的第一依据，任何场景都不能空 |
| 发现版本与环境 | 必填 | 决定能否复现，缺失时修复人无法判断问题范围 |
| 复现步骤 | 必填 | 缺陷报告的核心，偶现问题也需写明尝试过程 |
| 预期结果与实际结果 | 必填 | 界定问题性质的依据，缺一不可 |
| 严重程度 | 必填 | 影响排期与资源投入，提交时先给初判，确认阶段可修正 |
| 附件证据 | 必填（界面类缺陷） | 截图或录屏能显著降低沟通成本；纯逻辑或数据问题可用日志替代 |
| 缺陷编号 | 系统生成 | 由工具自动分配，手工记录时按团队规则补填 |
| 前置条件 | 选填 | 复现依赖特定账号、数据或配置时转为必填 |
| 优先级 | 选填 | 可由提交人初判，最终以排期评审结论为准 |
| 影响范围 | 选填 | 涉及多模块、多用户或资金数据时建议填写 |
| 复现概率 | 选填 | 偶现缺陷建议填写，注明尝试次数与出现次数 |
| 关联需求或用例 | 选填 | 有明确需求或测试用例时填写，便于追溯 |
| 处理人与状态 | 流转时填写 | 提交时可为空，进入处理环节后由系统或负责人更新 |
紧急上报场景下，允许先提交标题、环境、实际结果和证据四项，复现步骤与预期结果在约定时限内补齐，并在记录中标注“信息待补”。外部反馈转记场景下，反馈人往往无法提供版本和步骤，转记人应代为补充可获取的环境信息，把用户原话放入实际结果，并注明“来源：用户反馈，待复现”。缺失必填项时，不建议直接拒收，可以由接收人标记为“待补充”并指定补充责任人，超过约定时间仍未补齐再关闭或退回。
完整填写示例：一条登录失败缺陷
以下示例为演示情景，字段与第一节模板一一对应，展示各字段如何协同表达一个缺陷。
| 字段 | 填写内容 |
|---|---|
| 标题 | 移动端App使用手机号验证码登录，输入正确验证码后提示“验证失败”并停留在登录页 |
| 缺陷编号 | BUG-1024 |
| 发现版本与环境 | App 3.2.1（Android 13，机型示例A）；服务端为预发布环境 |
| 提交人与提交日期 | 测试同学甲，2025-03-11 |
| 前置条件 | 账号已注册且绑定手机号；手机可正常接收短信；App为全新安装 |
| 复现步骤 | 1. 打开App进入登录页；2. 选择“验证码登录”；3. 输入已注册手机号并点击获取验证码；4. 在60秒内输入收到的6位验证码；5. 点击“登录” |
| 预期结果 | 验证通过，进入App首页，登录状态保持 |
| 实际结果 | 页面提示“验证失败，请重试”，仍停留在登录页；重复操作3次结果一致；同一账号在网页端验证码登录正常 |
| 严重程度 | 高：核心登录流程阻断，移动端用户无法进入App |
| 优先级 | 高：影响本次版本发布，暂无临时规避方案（网页端可用） |
| 影响范围 | Android端全部用户；iOS端未验证 |
| 附件证据 | BUG-1024_录屏_01（完整操作过程）；BUG-1024_日志_02（客户端登录请求前后日志，已脱敏）；BUG-1024_截图_03（错误提示页面） |
| 复现概率 | 必现，尝试5次均失败 |
| 处理人与状态 | 处理人：客户端开发乙；状态：已确认 |
| 关联需求或用例 | 需求REQ-208“验证码登录”；用例TC-311 |
这条示例中，复现步骤与预期、实际结果形成对照：步骤4和5是触发点，预期写的是登录成功的完整结果，实际写的是提示文案、页面停留状态以及重复验证情况。严重程度依据“核心流程阻断”判定，优先级依据“影响发布且无规避方案”判定，两者理由分开陈述。证据按“编号_类型_序号”命名，并注明日志已脱敏，方便修复人直接取用。
模板的调整与维护方法
模板用久了容易出现两种问题：字段越加越多，填表人开始跳过；或者长期不更新，字段与实际流程脱节。建议把调整纳入固定机制。
新增字段的判断与评审
新增字段前先回答三个问题：这个信息是否已有字段可以承载；缺失它是否导致过缺陷被退回或返工；由谁在什么环节填写。三个问题都有明确答案再提交评审，由测试、研发和项目负责人共同确认，避免个人按习惯加字段。评审通过后同步更新模板、字段说明和示例，三者保持一致。
命名与选项值统一
字段名称、状态下拉选项、严重程度等级由团队维护一份字段字典，所有项目和文档引用同一份字典。修改选项值时保留旧值的映射关系，历史记录不因改名而失去含义。新增状态前确认现有状态无法表达该环节，避免出现“修复完成”和“已修复”并存的情况。
版本记录与定期复盘
模板每次调整记录版本号、变更内容、生效日期和负责人，旧版本归档备查。建议每季度或每个大版本结束后复盘一次：统计各字段的实际填写率、因信息缺失被退回的比例、哪些字段长期为空。连续多个周期无人填写的选填字段可以考虑移除或改为条件必填；反复因缺失导致返工的字段则提升为必填。
当缺陷记录落到可跟踪的工作项上时，模板字段可以对应到缺陷工作项的属性。ONES Project 适配缺陷管理等研发场景，支持一键提交 Bug 至对应的项目或迭代中，记录和跟踪缺陷修复情况，并可统计缺陷状态分布；与 TestCase 数据互通，便于从测试用例直接提交缺陷。团队可以把本文模板中的标题、环境、复现步骤、预期与实际结果、严重程度等字段作为提交时的填写约定，再结合项目实际配置工作项属性。字段自定义与必填校验的具体配置方式，以所使用版本的实际能力为准。
常见问题
偶现缺陷无法稳定复现，复现步骤该怎么写？
偶现缺陷同样要写步骤，重点是把尝试过程记录完整：按实际操作顺序列出步骤，在复现概率字段注明尝试次数与出现次数，例如“尝试10次出现3次”。同时补充出现时的环境状态、操作时间点和相关日志，便于修复人对照日志定位。复现概率属于选填字段，偶现场景建议填写，它直接影响修复人对问题性质的判断。
紧急上报时信息不全，是先提交还是等补齐再提交？
紧急场景下允许先提交标题、环境、实际结果和证据四项，复现步骤与预期结果在约定时限内补齐，并在记录中标注“信息待补”。这样既保证问题及时进入处理流程，也留下补齐的责任约定。接收人应指定补充责任人，超过约定时间仍未补齐再考虑关闭或退回，避免记录长期停留在信息残缺状态。
外部用户反馈的问题，版本和复现步骤都拿不到，怎么转记成Bug报告？
转记人应代为补充可获取的环境信息，把用户原话放入实际结果，并注明“来源：用户反馈，待复现”。版本号、设备型号等能问到的尽量问清，问不到的留空并在记录中说明。这类记录在确认阶段由测试人员尝试复现后再补全步骤，转记时不必强行编造细节。
模板字段和缺陷管理工具里的工作项属性怎么对应？
可以把模板中的标题、环境、复现步骤、预期与实际结果、严重程度等字段作为提交时的填写约定，再对应到工具中缺陷工作项的属性。ONES Project 适配缺陷管理等研发场景，支持一键提交 Bug 至对应的项目或迭代中，记录和跟踪缺陷修复情况，并可统计缺陷状态分布；与 TestCase 数据互通，便于从测试用例直接提交缺陷。字段自定义与必填校验的具体配置方式，以所使用版本的实际能力为准。
团队觉得字段太多填起来麻烦，可以删掉哪些？
优先检查选填字段的实际使用情况：连续多个周期无人填写、也未因缺失导致返工的字段，可以考虑移除或改为条件必填。必填字段中的严重程度、复现步骤、预期与实际结果不建议删除，它们直接决定缺陷能否被准确定位和排期。删减前先统计因信息缺失被退回的比例，确认删掉后不会推高返工率。
