缺陷版本影响清单用来回答一个具体问题：某个缺陷在哪些版本上造成了什么影响、需要谁在什么时候处理。它按“一个缺陷在一个版本上的一个影响对象”逐行记录，适合在缺陷确认后、修复排期前填写。下面先给出可直接复制的空白表，再说明字段口径、必填规则、完整示例，以及按团队情况调整和维护的方法。
要点总览（TL;DR）
- 缺陷版本影响清单按“缺陷×版本×影响对象”逐行记录，同一缺陷影响多个版本或多个对象时拆成多行，保证每行可独立追溯。
- 核心字段包括缺陷标识、缺陷描述、发现版本、影响版本、影响对象类型与名称、影响程度、影响范围判定依据、关联需求/变更单、处置动作、责任人、计划完成时间和状态。
- 缺陷标识、缺陷描述、发现版本、影响版本、影响对象、影响程度、责任人、状态建议设为必填；影响范围判定依据在严重及以上时必填，处置动作在进入修复中后必填。
- 填写顺序是先固定缺陷与版本口径，再补齐影响对象和判定依据，最后用状态字段闭环跟踪；发现版本与影响版本要分开记录。
- 字段可按项目规模和发布节奏裁剪，但需保留能回答“影响哪个版本、哪个对象、谁来处理、处理到哪一步”的字段，并指定维护人定期评审归档。
可复制空白模板：缺陷版本影响清单表
将下表复制到文档或表格工具中即可使用。表头保持一行，每条记录占一行。记录粒度固定为“缺陷×版本×影响对象”：同一缺陷影响两个版本，就写两行；同一版本影响两个模块，也写两行。这样每一行都能独立追溯，不会因为合并单元格丢失信息。
| 序号 | 缺陷标识 | 缺陷描述 | 发现版本 | 影响版本 | 影响对象类型 | 影响对象名称 | 影响程度 | 影响范围判定依据 | 关联需求/变更单 | 处置动作 | 责任人 | 计划完成时间 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
如果团队已有缺陷编号体系，“序号”可以省略，直接用缺陷标识作为行索引。表格之外建议加一行表头信息：清单名称、统计截止版本、维护人、最后更新时间。这四项帮助后来接手的人判断清单是否仍然有效。
字段说明：每个字段记录什么、怎么填
字段设计围绕一条链路展开：缺陷是什么、在哪个版本被发现、影响哪些版本和对象、影响多大、挂回哪个上游需求或变更、由谁怎么处置、当前到哪一步。下表逐字段说明含义与填写口径，示例值取自后文的完整示例，便于对照。
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 缺陷标识 | 缺陷的唯一编号或链接 | 使用缺陷管理系统中的编号，保证能反查原始记录；手工清单需团队内唯一 | BUG-2317 |
| 缺陷描述 | 一句话说明缺陷现象 | 写“什么条件下出现什么错误结果”，不写根因分析；控制在便于扫读的长度 | 订单金额满减后，导出报表金额仍按原价计算 |
| 发现版本 | 缺陷首次被发现的版本 | 填测试或客户实际使用的版本号，精确到构建号更佳 | V3.2.0 |
| 影响版本 | 经判断需要修复或验证的版本 | 逐版本判断后填写，一个版本一行；不确定的版本先标注“待确认”并指定确认人 | V3.2.0、V3.1.5 |
| 影响对象类型 | 受影响对象的类别 | 从模块、接口、数据、客户、文档等固定选项中选择，团队先约定选项集 | 数据 |
| 影响对象名称 | 具体受影响的模块、接口或数据范围 | 写到可定位的粒度，如“报表导出服务”“订单金额字段” | 报表导出服务 |
| 影响程度 | 影响严重性的分级 | 使用团队统一分级，如阻断、严重、一般、轻微；分级标准需事先定义 | 严重 |
| 影响范围判定依据 | 支撑影响程度和影响版本判断的事实 | 写可核验的依据：复现步骤、影响数据量、涉及客户数、代码变更范围等 | 影响近30天导出报表，涉及2个客户 |
| 关联需求/变更单 | 缺陷影响所挂靠的上游对象 | 填需求编号或变更单编号；无关联时写“无”，不留空 | REQ-118、CR-042 |
| 处置动作 | 计划采取的修复或缓解措施 | 写具体动作，如“修复计算逻辑并补回归用例”“对已导出数据做修正脚本” | 修复计算逻辑，补导出回归用例 |
| 责任人 | 该行记录的处置负责人 | 填到具体个人，不填团队名；跨版本时可分版本指定 | 张明 |
| 计划完成时间 | 该行处置的预期完成日期 | 与版本发布计划对齐；无明确日期时写目标版本 | V3.2.1 发布前 |
| 状态 | 该行记录的当前进展 | 使用固定状态集，如待确认、已确认、修复中、待验证、已关闭 | 修复中 |
| 备注 | 补充信息 | 记录例外情况、依赖项或沟通结论 | 需与财务确认历史数据修正范围 |
发现版本与影响版本的区别需要特别强调：发现版本回答“在哪里被发现”，影响版本回答“哪些版本需要修复或验证”。一个缺陷可能只在最新版本被发现，但影响多个历史版本；也可能在旧版本发现，新版本已修复。两者分开记录，修复排期才不会漏版本。
必填与选填：哪些字段不能空
必填字段的作用是保证每一行都能被追溯和闭环。缺陷标识、缺陷描述、发现版本、影响版本、影响对象类型、影响对象名称、影响程度、责任人、状态这九项建议设为必填。缺少其中任何一项，这一行要么无法定位缺陷，要么无法判断影响，要么无法跟踪到关闭。
| 字段 | 必填/选填 | 说明 |
|---|---|---|
| 缺陷标识 | 必填 | 追溯起点，缺失则整行失效 |
| 缺陷描述 | 必填 | 便于非原始提交人理解 |
| 发现版本 | 必填 | 确定问题出现的时间点 |
| 影响版本 | 必填 | 修复排期的直接依据 |
| 影响对象类型 | 必填 | 支撑分类统计 |
| 影响对象名称 | 必填 | 定位到具体模块或数据 |
| 影响程度 | 必填 | 决定优先级 |
| 影响范围判定依据 | 建议必填 | 影响程度为严重及以上时必填 |
| 关联需求/变更单 | 选填 | 无关联时写“无” |
| 处置动作 | 选填 | 状态进入“修复中”后必填 |
| 责任人 | 必填 | 每行需有明确负责人 |
| 计划完成时间 | 选填 | 进入排期后必填 |
| 状态 | 必填 | 闭环跟踪的核心字段 |
| 备注 | 选填 | 按需填写 |
必填字段缺失时的处理规则：不允许留空提交。缺陷标识缺失的行直接退回提交人补全；影响版本暂不确定的，填写“待确认”并在备注中写明确认人和确认时间，状态置为“待确认”；影响对象名称无法定位的，先按最接近的模块记录并标注待细化。这样清单始终没有“无法追溯的空行”，同时保留继续推进的空间。
字段可以按场景裁剪。小规模项目或单版本发布，可以省略“关联需求/变更单”和“计划完成时间”，用版本发布计划代替；面向客户的缺陷通报场景，则需要保留“影响范围判定依据”和“备注”，并补充客户名称。裁剪的原则是：删掉字段后，这一行是否仍能回答“影响哪个版本、哪个对象、谁来处理、处理到哪一步”，能回答即可裁剪。
填写示例：一条缺陷的完整影响记录
以下示例为演示情景，用于说明字段如何配合，不代表真实项目数据。假设缺陷 BUG-2317 在 V3.2.0 测试中被发现，经排查影响 V3.2.0 和 V3.1.5 两个版本，影响对象为报表导出服务中的订单金额数据。
| 序号 | 缺陷标识 | 缺陷描述 | 发现版本 | 影响版本 | 影响对象类型 | 影响对象名称 | 影响程度 | 影响范围判定依据 | 关联需求/变更单 | 处置动作 | 责任人 | 计划完成时间 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | BUG-2317 | 订单金额满减后，导出报表金额仍按原价计算 | V3.2.0 | V3.2.0 | 数据 | 报表导出服务-订单金额字段 | 严重 | 复现步骤已确认；影响近30天导出报表，涉及2个客户 | REQ-118 | 修复计算逻辑，补导出回归用例 | 张明 | V3.2.1 发布前 | 修复中 | 需与财务确认历史数据修正范围 |
| 2 | BUG-2317 | 订单金额满减后，导出报表金额仍按原价计算 | V3.2.0 | V3.1.5 | 数据 | 报表导出服务-订单金额字段 | 严重 | V3.1.5 分支代码存在相同计算逻辑，已用同一用例复现 | REQ-118 | 同步修复至维护分支，验证后随补丁发布 | 李华 | V3.1.6 补丁发布前 | 待确认 | 维护分支负责人确认中 |
逐字段对应说明：缺陷标识和缺陷描述两行相同，因为它们是同一个缺陷；发现版本相同，说明缺陷首次在 V3.2.0 被发现；影响版本不同，因此拆成两行，分别对应两个需要修复的版本；影响对象类型和名称相同，说明两个版本受影响的是同一处数据逻辑；影响程度相同，但判定依据不同，第一行依据是实际复现和客户影响，第二行依据是代码分支比对和同一用例复现；关联需求相同，说明两行挂回同一个上游需求；处置动作、责任人、计划完成时间和状态按版本分别指定，因为两个版本的修复节奏和负责人不同。
多版本影响的写法要点：不要在一个单元格里堆叠多个版本号，也不要合并两行的处置信息。每个版本独立一行，责任人和状态可以不同，这样版本发布前逐行核对时不会遗漏。影响对象与判定依据要一一对应：判定依据写的是哪个对象、哪个范围的事实，影响对象字段就填对应的名称，避免依据写“报表问题”而对象填“订单模块”这类错位。
调整与维护方法：按团队情况裁剪并保持清单可用
清单的价值在于长期可用，而不是一次填完。调整从字段和行粒度两个方向入手，维护则围绕更新时机、责任人和评审节奏展开。
字段裁剪与新增的判断依据：先看团队是否已有承载该信息的系统。缺陷编号、状态、责任人如果已在缺陷管理工具中维护，清单中可以只保留引用，减少重复录入；如果团队需要对外通报或做版本发布评审，则应增加“影响范围判定依据”“客户名称”“计划完成时间”等字段。新增字段的判断标准是：该字段是否会影响修复排期、发布决策或对外沟通，会则加，不会则放入备注。
行粒度与版本口径的调整：默认按“缺陷×版本×影响对象”一行一条。项目规模较小、单版本发布时，可以简化为“缺陷×影响对象”，在影响版本列写全部受影响版本；但一旦进入多版本并行维护，应恢复逐版本一行，否则补丁发布时容易漏版本。版本口径需团队统一：使用对外版本号还是内部构建号，发现版本和影响版本是否采用同一口径，这些应在清单表头注明。
清单更新时机与责任人：缺陷状态变化、影响版本增减、处置动作调整、版本发布前后，都是更新时点。建议指定一名清单维护人负责格式和完整性，每行责任人负责自己记录的内容准确。版本发布评审前，维护人逐行核对状态，未关闭的行需说明原因。
归档与定期评审：每个版本发布后，将已关闭的记录归档到对应版本目录，保留只读副本；未关闭记录转入下一版本清单继续跟踪。建议每个迭代或每月做一次评审，检查是否有长期停留在“待确认”或“修复中”的行，确认影响范围判定依据是否仍然成立。评审结论记录在表头信息中，便于后续追溯。
当清单需要与缺陷、版本、需求和变更单联动时，可以把清单作为评审视图，底层数据仍放在管理工具中。ONES Project 适配缺陷管理、迭代管理等场景，支持缺陷跟踪管理并统计缺陷状态分布，也支持一键提交 Bug 至对应项目或迭代，便于把清单中的缺陷标识、影响版本和状态与实际记录对应起来；ONES Wiki 支持文档关联任务并插入工作项列表，适合承载清单文档并与缺陷记录保持关联。具体字段配置和关联方式需按团队实际使用的产品版本确认。
常见问题
缺陷在多个历史版本都存在，但只在最新版本被发现，清单该怎么记？
发现版本填实际发现问题的版本，影响版本按排查结果逐版本填写，每个需要修复或验证的版本单独一行。发现版本与影响版本本来就是两个口径：前者回答“在哪里被发现”，后者回答“哪些版本需要修复或验证”。如果某个历史版本是否受影响尚未确认，影响版本先写“待确认”，在备注中写明确认人和确认时间，状态置为“待确认”，确认后再补全或删除该行。
清单里的“关联需求/变更单”找不到对应对象时怎么处理？
没有关联对象时在字段中写“无”，不留空，这样能区分“已确认无关联”和“还没填”。如果缺陷确实由某次需求实现或变更引入，但一时找不到编号，可以先写疑似关联的对象名称并在备注中标注待核实，由清单维护人在评审时补齐。关联字段的作用是把缺陷影响挂回上游对象，本文只记录关联关系，需求覆盖矩阵和跨对象变更治理不在本文展开。
小团队或单版本发布，清单可以精简到什么程度？
可以省略“关联需求/变更单”和“计划完成时间”，用版本发布计划代替排期信息；面向客户的通报场景则相反，需要保留影响范围判定依据和备注，并补充客户名称。裁剪的判断标准是：删掉字段后，这一行是否仍能回答“影响哪个版本、哪个对象、谁来处理、处理到哪一步”。一旦进入多版本并行维护，应恢复逐版本一行，避免补丁发布时漏版本。
清单长期使用后，怎么避免出现大量停留在“待确认”或“修复中”的行？
建议每个迭代或每月做一次评审，逐行检查长期未推进的记录，确认影响范围判定依据是否仍然成立，未关闭的行需说明原因。同时指定一名清单维护人负责格式和完整性，每行责任人负责自己记录的内容准确。版本发布后，已关闭记录归档为只读副本，未关闭记录转入下一版本清单继续跟踪，评审结论记录在表头信息中便于后续追溯。
清单需要和缺陷系统、需求、变更单联动时，怎么落地？
可以把清单作为评审视图，底层数据仍放在管理工具中，清单只保留缺陷标识、影响版本和状态等引用字段，减少重复录入。ONES Project 适配缺陷管理、迭代管理等场景，支持缺陷跟踪管理并统计缺陷状态分布，也支持一键提交 Bug 至对应项目或迭代；ONES Wiki 支持文档关联任务并插入工作项列表，适合承载清单文档并与缺陷记录保持关联。具体字段配置和关联方式需按团队实际使用的产品版本确认。
