缺陷报告的要素有哪些
一份好的缺陷报告让开发不用问人就能复现问题：标题写清现象、模块、版本与频率；正文给出环境、前置数据、编号步骤、期望与实际结果，以及日志、截图、请求响应等证据。报告质量直接决定修复效率——信息缺一项，沟通就要多一个来回；缺复现条件，缺陷很可能被标成「无法复现」沉没。
基本信息
| 标题写法 | 包含现象、模块、版本与频率，便于检索与去重 |
|---|---|
| 环境信息 | 构建号、操作系统与浏览器版本、账号与配置 |
| 前置条件 | 测试数据准备情况与依赖的初始状态 |
| 复现步骤 | 从登录态开始的编号步骤，能一步步照做 |
| 期望与实际 | 两头都写：只说实际不写期望，等于没给判据 |
| 证据要求 | 日志、截图、请求响应与时间戳，按步骤编号对应挂上 |
标题对比
标题对比
弱：登录有问题
好：登录页校验码错误时提示为空白（v2.3.1，Chrome 126，必现）
# 好标题包含四件事：现象、模块、版本、复现频率典型使用场景
- 测试执行期间提交缺陷：按要素模板填写，减少往返沟通。
- 跨团队协作：开发、产品、运营各自能从报告里取到需要的信息。
- 回归核对：关闭前按复现步骤原样走一遍验证修复。
- 缺陷去重：标题可检索，避免同一问题重复登记三份。
- 根因分析：证据里的日志与时间戳支撑深层定位。
- 流程审计：报告规范度反映缺陷管理成熟度，可度量改进。
要素检查表
| 要素 | 要点 | 常见缺陷 |
|---|---|---|
| 标题 | 现象+模块+版本+频率 | 只写「有问题」，无法检索与去重 |
| 环境与版本 | 构建号与运行环境齐全 | 缺版本，开发在错误分支排查 |
| 前置数据 | 账号、订单号等准备清楚 | 步骤缺数据前提，别人复现不了 |
| 复现步骤 | 编号、最小化但完整 | 省略前置动作，跳步导致无法复现 |
| 期望与实际 | 给出明确判据 | 只描述实际现象，判不出是不是缺陷 |
| 证据 | 日志、截图、请求响应 | 只有口头描述，定位全靠猜 |
证据优先级：结构化日志与请求响应优于截图，截图优于口头描述；附证据时按步骤编号对应，开发不用自己找位置。
报告同时写给三类读者：开发照着修、产品照着判断影响、测试自己照着回归——写之前想清楚每一方需要的字段。
复现步骤应最小化：能三步复现就不要写十步，但删减以保持可复现为底线。