缺陷积压清单用来把散落在各处的未关闭缺陷收拢到一张表里，按状态、优先级和滞留时长排出清理顺序。模板包含五组字段：标识与归属、缺陷描述、严重与优先级、修复与验证状态、滞留时长与清理动作。下面先给可复制的空白表，再逐列说明填写口径、必填范围，并用一条示例演示从发现到验证关闭的完整记录。
要点总览（TL;DR）
- 模板以一张可复制的空白表为核心，字段分为五组：标识与归属、缺陷描述、严重与优先级、修复与验证状态、滞留时长与清理动作。
- 必填字段保证每条积压缺陷能被定位、定级和排序，包括缺陷编号、标题、模块、责任人、复现步骤、严重程度、优先级、当前状态、发现日期、滞留天数和清理动作；其余字段按阶段逐步补齐。
- 组织清单时按状态分视图、按优先级排序、按滞留天数分档标记超期，组合规则为：先筛未关闭状态，再按优先级从高到低，同优先级内按滞留天数降序。
- 修复到验证的交接靠状态、修复版本、验证人和验证结果四个字段记录，验证不通过单独成组并退回责任人，避免退回记录被误认为仍在修复中。
- 清单上线后按是否影响定位、定级或排序判断字段增删，已关闭记录定期归档，并设固定评审节奏和字段管理员保持口径一致。
可复制空白模板：缺陷积压清单表
将下表复制到表格工具中即可开始填写。列名与后续字段说明一一对应，最后一行为空白填写位，复制时可整行保留，便于连续录入多条缺陷。
| 缺陷编号 | 标题 | 所属产品/模块 | 发现版本 | 责任人 | 复现步骤 | 实际结果 | 期望结果 | 影响范围 | 严重程度 | 优先级 | 是否阻塞发布 | 当前状态 | 修复版本 | 验证人 | 验证结果 | 关闭时间 | 发现日期 | 滞留天数 | 上次更新时间 | 清理动作 | 计划完成日 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
表格横向较宽，实际使用时可以把“复现步骤、实际结果、期望结果”三列合并为一个描述单元格，或在表格工具中设为自动换行。字段本身不减少，只调整展示方式。
字段说明：每一列记录什么、怎么填
同一张清单往往由测试、开发、产品多方共同填写，字段口径不统一会让清单失去排序价值。下面按五组说明每列的含义和填写要求。
标识与归属
- 缺陷编号：系统生成的唯一编号，手工维护时按“产品缩写-序号”规则递增，保证不重复、可引用。
- 标题：一句话说明现象，包含操作对象和异常表现，例如“订单导出超过500条时文件为空”。
- 所属产品/模块：填到能定位负责团队的层级，模块粒度以团队分工为准。
- 发现版本：首次发现缺陷的版本号或构建号，用于判断影响范围。
- 责任人：当前负责推进的人，随状态流转更换，待修复阶段为开发，待验证阶段为测试。
缺陷描述
- 复现步骤：按操作顺序编号写出，包含必要的前置数据和账号条件，使他人能独立复现。
- 实际结果：客观记录系统表现，附错误提示原文或截图位置。
- 期望结果：写明符合需求或设计的行为，避免只写“应该正常”。
- 影响范围：说明受影响的用户群、业务流程或数据量，为定级提供依据。
严重与优先级
- 严重程度：描述缺陷本身对系统造成的损害，通常分为致命、严重、一般、轻微四档，由缺陷性质决定，不随排期变化。
- 优先级：描述修复的紧迫性，分为高、中、低，可结合业务影响和发布计划调整。严重程度高但影响面小的缺陷，优先级可能低于严重程度一般却阻塞主流程的缺陷。
- 是否阻塞发布：填“是”或“否”，为“是”的缺陷进入发布前必须清零的集合。
修复与验证
- 当前状态：从待修复、修复中、待验证、验证不通过、已关闭中选一个，同一时刻只填一个。
- 修复版本：开发提交修复的版本号，验证时据此确认环境。
- 验证人：执行验证的测试人员，修复人不能同时担任验证人。
- 验证结果：填通过或不通过，不通过时在备注或描述中补充新现象。
- 关闭时间：验证通过并确认关闭的日期，未关闭留空。
滞留时长与清理动作
- 发现日期：缺陷首次记录的日期，作为计算滞留天数的起点。
- 滞留天数：当前日期减去发现日期，已关闭缺陷填关闭日期减去发现日期。表格工具中可用公式自动计算。
- 上次更新时间：该条记录最近一次字段变更的日期，用于识别长期无人推进的缺陷。
- 清理动作：写明下一步打算，例如“本周排入修复”“补充复现信息”“与产品确认是否降级”“关闭为重复缺陷”。
- 计划完成日：清理动作的承诺完成日期，逾期未完成需在评审中说明。
必填与选填：哪些字段不能空
清单能否用于排序，取决于最低字段集是否完整。缺少标识类字段无法定位缺陷，缺少定级类字段无法排序，缺少滞留类字段无法识别积压。下表给出必填与选填的划分及理由。
| 字段 | 必填/选填 | 原因或适用场景 |
|---|---|---|
| 缺陷编号 | 必填 | 唯一定位，评审和沟通都靠它引用 |
| 标题 | 必填 | 快速识别缺陷内容 |
| 所属产品/模块 | 必填 | 确定责任团队，支持按模块汇总 |
| 发现版本 | 必填 | 判断影响范围与回归范围 |
| 责任人 | 必填 | 每条积压缺陷必须有推进人 |
| 复现步骤 | 必填 | 无法复现的缺陷无法有效修复 |
| 实际结果、期望结果 | 必填 | 构成缺陷判定的基本事实 |
| 严重程度 | 必填 | 定级基础，影响排序 |
| 优先级 | 必填 | 排序主键 |
| 当前状态 | 必填 | 分组依据，决定清单视图 |
| 发现日期 | 必填 | 计算滞留天数的起点 |
| 滞留天数 | 必填 | 识别超期积压的核心指标，可由公式生成 |
| 清理动作 | 必填 | 让每条积压缺陷有明确去向 |
| 影响范围 | 选填 | 定级争议时补充，影响面明确的缺陷建议填写 |
| 是否阻塞发布 | 选填 | 有发布节点的团队建议填写 |
| 修复版本、验证人、验证结果、关闭时间 | 选填 | 进入修复和验证阶段后逐步补齐 |
| 上次更新时间 | 选填 | 用于识别长期停滞记录，可由系统自动维护 |
| 计划完成日 | 选填 | 纳入排期清理的缺陷建议填写 |
| 复现环境、关联需求、截图链接、备注 | 选填 | 环境相关缺陷、需求追溯和补充说明时使用 |
团队阶段不同，必填范围可以调整。项目初期缺陷量少，可先要求标识、描述、定级和状态字段；进入发布冲刺后，把“是否阻塞发布”和“计划完成日”提升为必填；维护期项目则可弱化发现版本，强化滞留天数和清理动作。调整时保持同一项目内口径一致，并在清单说明中记录变更日期。
按状态、优先级与滞留时长组织清单
字段填全之后，清单还需要分组和排序才能回答“先清哪些”。建议按状态分视图、按优先级定顺序、按滞留时长标超期，三个维度组合使用。
状态分组
把清单拆成待修复、修复中、待验证、验证不通过、已关闭五个视图。日常清理关注前四个，已关闭记录保留用于统计但不占用清理视线。验证不通过单独成组，避免缺陷退回后被误认为仍在修复中。
优先级与严重程度的关系
排序以优先级为主键，严重程度作为同优先级内的次级依据。优先级高且阻塞发布的缺陷排在最前；严重程度高但发生条件极端的缺陷，可在优先级中档内按影响范围微调。两个字段都填，才能在评审时解释排序理由。
滞留时长分档
按发现日期计算滞留天数，分为7天内、8至30天、30天以上三档，30天以上标记为超期。分档阈值可按发布节奏调整，迭代周期短的团队可把超期线设在14天。超期标记用于触发清理动作，不直接等同于提升优先级。
排序规则组合示例
- 先筛选当前状态为待修复、修复中、待验证、验证不通过的记录。
- 按优先级从高到低排序。
- 同一优先级内按滞留天数降序排列，超期记录置顶。
- 阻塞发布的缺陷单独筛选一遍，确保发布前清零。
验证环节的交接
修复人提交修复后，把状态改为待验证，填写修复版本并指定验证人；验证人确认通过则填验证结果并关闭，记录关闭时间；不通过则状态改为验证不通过，补充新现象后退回责任人。每次交接更新上次更新时间，使停滞记录能被识别。
当清单从表格迁移到缺陷跟踪系统时，状态流转和验证记录需要系统承载。ONES 测试管理解决方案覆盖缺陷管理流程，缺陷可关联至迭代；ONES Project 支持将 Bug 提交至对应项目或迭代，并统计缺陷状态分布，配合多重条件筛选查看不同状态的缺陷集合。字段映射时，可把清单中的状态分组对应到系统工作项状态，把验证人和验证结果记录在缺陷详情中，具体字段配置以团队实际环境为准。
填写示例：一条缺陷从发现到验证关闭
以下为演示情景，编号与版本均为示例数据。假设测试人员在订单模块发现导出异常。
| 字段 | 发现当天（待修复） | 修复提交后（待验证） | 验证通过后（已关闭） |
|---|---|---|---|
| 缺陷编号 | ORD-0132 | ORD-0132 | ORD-0132 |
| 标题 | 订单导出超过500条时生成空文件 | 同左 | 同左 |
| 所属产品/模块 | 订单中心/导出 | 同左 | 同左 |
| 发现版本 | V3.2.1 | V3.2.1 | V3.2.1 |
| 责任人 | 开发A | 测试B | 测试B |
| 复现步骤 | 1.登录测试账号；2.进入订单列表；3.筛选近30天订单；4.点击导出 | 同左 | 同左 |
| 实际结果 | 下载文件为0字节，无报错提示 | 同左 | 同左 |
| 期望结果 | 导出包含全部筛选结果的CSV文件 | 同左 | 同左 |
| 影响范围 | 近30天订单量超过500条的运营人员 | 同左 | 同左 |
| 严重程度 | 严重 | 严重 | 严重 |
| 优先级 | 高 | 高 | 高 |
| 是否阻塞发布 | 是 | 是 | 是 |
| 当前状态 | 待修复 | 待验证 | 已关闭 |
| 修复版本 | 空 | V3.2.2 | V3.2.2 |
| 验证人 | 空 | 测试B | 测试B |
| 验证结果 | 空 | 空 | 通过 |
| 关闭时间 | 空 | 空 | 2025-03-18 |
| 发现日期 | 2025-03-10 | 2025-03-10 | 2025-03-10 |
| 滞留天数 | 0 | 6 | 8 |
| 上次更新时间 | 2025-03-10 | 2025-03-16 | 2025-03-18 |
| 清理动作 | 排入V3.2.2修复 | 等待测试B在V3.2.2环境验证 | 已关闭，无需后续动作 |
| 计划完成日 | 2025-03-17 | 2025-03-18 | 2025-03-18 |
示例中选填字段“影响范围”用于支撑严重程度判定，“是否阻塞发布”为“是”使该缺陷进入发布前清零清单。若验证不通过，状态改为验证不通过，验证结果填不通过，责任人改回开发A，清理动作写“根据新现象继续修复”，滞留天数继续累计。
调整与维护方法
清单上线后需要随团队节奏调整，否则字段会越加越多、记录越积越旧。维护围绕字段增删、历史清理、数据同步和评审节奏四件事展开。
字段增删的判断标准
新增字段前先问：它是否影响缺陷的定位、定级或排序。影响定位的字段（如关联需求、复现环境）可加；影响定级的字段（如影响用户数）可加；只用于记录过程细节的内容放进备注，不单独设列。删除字段时确认没有视图或统计依赖它，删除前导出一次历史数据。
定期清理与归档
已关闭缺陷在清单中保留一个发布周期后移入归档表，归档表保留编号、标题、关闭时间和验证结果，供追溯使用。主清单只保留未关闭记录，使排序结果始终聚焦待清理项。归档频率与评审节奏一致，按月或按迭代执行。
与缺陷系统同步或手动更新
缺陷量小、团队尚未统一工具时，可手动维护表格，每次评审前由责任人更新一次。缺陷已录入跟踪系统时，优先从系统导出或按筛选条件生成清单，减少双份维护。选择同步方式时确认状态、责任人、验证结果三类字段能对应上，避免清单与系统记录不一致。
评审节奏与责任人
建议每周固定一次积压评审，由测试负责人主持，开发负责人和产品负责人参加，逐条确认超期缺陷的清理动作和计划完成日。清单维护设一名字段管理员，负责口径解释和字段变更记录。评审输出更新后的排序结果和本周清理目标，下次评审先核对上周目标的完成情况。
常见问题
缺陷积压清单和缺陷跟踪系统里的缺陷列表是什么关系，还需要单独维护表格吗？
两者记录的是同一批缺陷，区别在用途。系统里的缺陷列表是事实来源，清单是从中筛出未关闭记录后用于排序和评审的工作视图。缺陷已录入跟踪系统时，优先按筛选条件从系统导出清单，减少双份维护；缺陷量小、团队尚未统一工具时，可以手动维护表格，每次评审前由责任人更新一次。无论哪种方式，状态、责任人、验证结果三类字段要能对应上，避免清单与系统记录不一致。
滞留天数应该从发现日期算，还是从最近一次状态变更算？
模板默认从发现日期算起，反映缺陷从被发现到现在的总积压时长，适合识别长期未清理的记录。如果团队更关心“卡在当前环节多久”，可以另加一列“当前状态停留天数”，从最近一次状态变更日期算起，用于发现待验证环节堆积的情况。两列并存时，排序以总滞留天数为主，状态停留天数用于定位具体环节的堵点。已关闭缺陷的滞留天数按关闭日期减发现日期计算，不再随日期增长。
验证不通过退回后，滞留天数要不要清零重新计算？
不清零。滞留天数反映缺陷从发现到关闭的总时长，退回修复说明这条缺陷仍未关闭，天数继续累计。需要区分的是责任环节：状态改为验证不通过，责任人从验证人改回开发，清理动作写明根据新现象继续修复，计划完成日重新约定。这样在按滞留天数排序时，反复退回的缺陷会自然排到前面，提示团队关注修复质量，而不是把它当成新缺陷重新计时。
团队规模小、缺陷量少，必填字段可以精简到多少？
可以精简到能完成定位、定级、排序三件事的最低集：缺陷编号、标题、所属模块、责任人、复现步骤、实际结果、期望结果、严重程度、优先级、当前状态、发现日期、滞留天数、清理动作。修复版本、验证人、验证结果、关闭时间在进入修复和验证阶段后补齐；影响范围、是否阻塞发布、计划完成日按是否有发布节点决定。精简后要在清单说明中记录口径和调整日期，缺陷量增长或进入发布冲刺时再把字段加回来。
清单里的超期标记要不要直接触发优先级提升？
不建议自动提升。超期标记的作用是触发清理动作，让评审时逐条确认这条缺陷是排入修复、补充信息、降级还是关闭为重复，而不是替代优先级判断。优先级由业务影响和发布计划决定，一条滞留很久但影响面极小的缺陷，提升优先级会挤占真正阻塞主流程的修复资源。评审时可以约定：超期且阻塞发布的缺陷优先处理，超期但影响面小的缺陷给出明确去向即可。
