缺陷报告：复现信息、分级与验证模板

缺陷报告的作用

缺陷报告把“发现了问题”变成可复现、可分派、可验证的工作项。一份有效报告应让没有参加发现过程的人，知道在什么版本和条件下做了什么、实际发生了什么、原本应该发生什么。GitHub Issues 官方入门也将复现步骤、预期结果和实际结果列为缺陷描述的核心信息。

报告应先记录观察事实，再单独提出原因假设。例如，“点击保存后，刷新页面显示旧标题”是现象；“数据库没有更新”是尚需验证的解释。不要用未经证实的解释替代现象。

填写顺序

1. 固定版本和前置条件。 记录版本号、构建号或提交号，以及账户角色、配置、输入数据等必要条件。可重现用例尽量使用脱敏的最小数据。
2. 给出最短复现步骤。 从可确定的初始状态开始，一步一个动作；避免“随便操作一会儿”或依赖报告人私有环境。
3. 分开写实际与预期。 实际结果写观察到的内容；预期结果指出需求、接口约定或已经确认的产品行为。
4. 记录频率和影响范围。 用“同一构建下 10 次出现 3 次”比只写“偶尔”更有信息；明确统计条件，样本很小就不要推断总体概率。
5. 附上证据。 日志应带时间和相关请求标识；截图适合证明界面状态，不能独自证明后台原因。附件移除密码、令牌、个人数据和无关业务内容。

严重性与优先级

严重性描述缺陷造成的影响；优先级决定团队安排修复的顺序。两者有关联，但不是同一个字段。项目应统一分级含义，以下只是可采用的示例。

字段	示例等级	判断依据
严重性	阻塞、严重、一般、轻微	是否丢失数据、核心任务能否完成、是否存在可行绕过方式、受影响范围
优先级	立即、高、中、低	发布计划、用户影响、发生频率、修复依赖和风险

例如，一个只在停用旧功能中出现的严重问题，与一个即将公开演示的页面文字错误，修复顺序可能不同。优先级由实际目标和影响共同决定，不能仅凭报告人的措辞强弱来定。

可复制的完整模板

提交时至少填完标题、版本、前置条件、步骤、预期、实际和环境。尚未发生的修复或验证信息写“待处理”，不预填为通过。问题管理工具已经自动生成的编号、报告人和日期可以直接复用。

# [模块] 在什么条件下出现什么问题

## 基本信息
- 缺陷编号：
- 报告日期：
- 报告人：
- 发现版本／构建号／提交号：
- 模块或组件：
- 当前状态：新建
- 指派给：待分派

## 现象与影响
- 简要描述：
- 实际结果：
- 预期结果及依据：
- 受影响用户／数据／功能范围：
- 临时绕过方法：无／具体步骤

## 复现
- 前置条件：
- 最小输入或测试数据：
1. 填写第一步操作
2. 填写后续操作及输入
3. 填写触发问题的操作
- 重现频率：出现次数／尝试次数，以及测试条件
- 测试执行结果：通过／失败／阻塞
- 测试日期：

## 级别
- 严重性：
- 优先级：
- 分级理由：

## 环境
- 操作系统与版本：
- 浏览器／客户端与版本：不适用时注明
- 硬件／固件与版本：不适用时注明
- 网络条件：
- 相关配置、依赖版本和账户角色：

## 证据
- 日志、截图、录屏或最小示例：
- 发生时间及关联标识：
- 原因假设：尚未确认／具体假设及依据
- 备注和关联问题：

## 修复与验证
- 修复版本／构建号／提交号：待处理
- 修复说明与变更链接：待处理
- 验证环境及使用的数据：待验证
- 验证结果：通过／失败／阻塞／待验证
- 验证日期：
- 验证人：
- 回归范围及结果：
- 最终状态与关闭理由：

示例：把模糊现象写成可复现问题

下面是虚构示例，用于说明填写方法，不代表任何现有网站的实际故障。

字段	示例内容
标题	编辑器：修改标题后点击保存，刷新仍显示旧标题
版本	示例应用 demo-1.2.0，构建 example-042
前置条件	已登录编辑角色；测试笔记标题为“标题 A”；正文为空
步骤	打开测试笔记 → 只将标题改为“标题 B” → 点击保存并等待成功提示 → 刷新页面
实际结果	页面标题仍为“标题 A”
预期结果	按保存功能约定，应显示已保存的“标题 B”
频率	同一构建、同一测试环境下重复 3 次，出现 3 次
影响	该用例中标题修改未保留；正文保存和其他字段尚未测试
证据	保存前后截图、脱敏请求与响应、发生时间
原因假设	尚未确认；需区分请求未包含新标题、服务端未写入、读取旧数据等情况

这份报告没有把一次观察扩大成“所有笔记都无法保存”，也没有提前断定根因。修复者可以沿明确步骤复现，再缩小问题范围。

验证与关闭

“代码已修改”只说明实现发生了变化；“验证通过”还需要在明确的修复版本上执行原复现步骤。除此之外，应检查相邻行为是否受到影响。例如标题保存问题至少还应考虑空标题规则、只改正文、同时改标题和正文，以及保存失败时的提示。

常见状态可以是“新建 → 已确认 → 修复中 → 待验证 → 已验证 → 关闭”，实际项目也可能合并部分状态。无法复现、重复报告、行为符合既定需求等情况，应写明证据或关联项后关闭；不要把它们记成“已修复”。若相同问题在已验证版本再次出现，可以重新打开并补充新的版本、步骤和证据。

来源与修订

本页保留原始缺陷报告模板的全部字段，迁至软件工程测试分类。它是一份通用参考模板，不是具体项目的故障记录。