测试范围清单要解决的是“这次测什么、不测什么、凭什么这样定”三个问题。把纳入项、排除项、假设和待确认项放进同一张表，评审时才能逐条过。其中假设是已按此规划、需要回头验证的前提，待确认项是尚未决策、结论会直接改变范围的开放问题，两类记录分开列，责任人和关闭条件才写得清楚。
要点总览（TL;DR）
- 测试范围清单用一张表承载纳入项、排除项、假设、待确认项四类记录，用“范围类型”列区分，评审时按类型逐条过。
- 假设是已按此规划、需要回头验证的前提，写清验证方式与失效影响；待确认项是尚未决策、结论会改变范围的开放问题，写清责任人与截止时间。
- 最小可用清单保留编号、范围类型、模块/对象、内容描述、责任人五列；假设与待确认项必须补截止时间和影响。
- 待确认项关闭后按结论转为纳入项或排除项，在原条目上留痕，不删除原记录。
- 范围评审、用例评审、测试执行开始前是三个固定检查点，分别核对假设是否验证、待确认项是否关闭、排除项是否仍然成立。
可复制空白模板：测试范围清单表
下面这张表可以直接复制到文档或表格工具中填写。四类记录共用一套字段，用“范围类型”列区分，评审时可以按类型筛选，也可以按模块顺序通读。占位提示用方括号标出，填写时替换为实际内容。
| 编号 | 范围类型 | 模块/对象 | 内容描述 | 依据 | 影响 | 责任人 | 截止时间 | 状态 | 关闭结论/备注 |
|---|---|---|---|---|---|---|---|---|---|
| R-01 | [纳入/排除/假设/待确认] | [功能、接口、数据、测试类型] | [一句话写清测什么或不测什么；假设写前提内容；待确认写开放问题] | [需求编号、评审结论、历史缺陷、业务约定] | [对进度、质量、上线范围的影响] | [姓名或角色] | [日期或里程碑] | [开放/已验证/已关闭] | [结论、转为哪条记录、变更原因] |
| R-02 | |||||||||
| R-03 | |||||||||
| R-04 |
如果项目较小，可以把“影响”和“关闭结论/备注”合并为一列备注；如果涉及多个系统对接，建议在“模块/对象”后增加“关联系统”列。表头顺序保持稳定，后续版本对比时才容易看出变化。
字段说明：每一列填什么、怎么判断
模板的价值取决于填写口径是否统一。同一列在不同人手里写出不同含义，评审就会变成逐条追问。下表给出每个字段的判断标准，模板、说明和示例三处使用同一口径。
| 字段 | 填什么 | 判断口径 |
|---|---|---|
| 编号 | 类型前缀加序号，如 R-01、E-01、A-01、Q-01 | 前缀区分四类记录，编号一旦分配不再复用，便于引用和追溯 |
| 范围类型 | 纳入、排除、假设、待确认四选一 | 纳入是本次要测；排除是明确不测；假设是已按此规划但未证实的前提；待确认是尚未决策、结论会改变范围的开放问题 |
| 模块/对象 | 功能名、接口名、数据集、测试类型 | 写到可以定位的粒度，避免只写“支付模块”而无法判断具体范围 |
| 内容描述 | 纳入写测什么；排除写不测什么；假设写前提本身；待确认写待决策的问题 | 一条记录只写一件事，假设和待确认项不要混在同一行 |
| 依据 | 需求编号、评审结论、历史缺陷、业务方约定 | 写可回查的来源，不写“大家都知道”“按惯例” |
| 影响 | 对进度、质量、上线范围的影响 | 假设项写“若不成立会怎样”，待确认项写“结论不同会改变哪些范围条目” |
| 责任人 | 姓名或角色 | 假设项写验证人，待确认项写能拍板或能推动决策的人 |
| 截止时间 | 日期或里程碑 | 假设项写验证时间点，待确认项写必须给出结论的时间点 |
| 状态 | 开放、已验证、已关闭 | 假设项用“已验证/未成立”，待确认项用“开放/已关闭”，状态变化要能对应到关闭结论 |
| 关闭结论/备注 | 结论内容、转为哪条记录、变更原因 | 关闭时必填，写清“转纳入”“转排除”或“假设成立/不成立” |
假设与待确认项的区分可以这样判断：如果团队已经按某个前提排了测试范围和工作量，只是这个前提还没被证实，它属于假设；如果范围本身还悬着、等某个人给结论，它属于待确认项。假设写“验证方式”和“失效影响”，待确认项写“谁来定”和“什么时候定”。
必填与选填：哪些字段不能空
最小可用清单只需要保证每条记录能被评审、被追踪。字段取舍按项目规模和协作人数调整，但有几列缺失会让清单失去作用。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 编号 | 必填 | 评审、变更、缺陷回溯都要引用条目，没有编号无法定位 |
| 范围类型 | 必填 | 四类记录的处理方式不同，缺这一列就无法区分假设和待确认项 |
| 模块/对象 | 必填 | 范围必须落到可定位的对象上，否则无法判断覆盖是否完整 |
| 内容描述 | 必填 | 清单的主体信息 |
| 责任人 | 必填 | 假设需要有人验证，待确认项需要有人推动决策；纳入和排除项也应有归属人 |
| 截止时间 | 假设、待确认项必填 | 没有时间点的假设会一直悬着，没有截止时间的待确认项会拖到测试执行阶段才暴露 |
| 依据 | 建议必填 | 小项目可简写为需求编号；涉及多方协作时缺失依据容易在评审中反复争论 |
| 影响 | 假设、待确认项必填 | 用于判断优先级；纳入和排除项可简写 |
| 状态 | 建议必填 | 清单条目多时用于筛选未关闭项；条目少于十条时可暂不设 |
| 关闭结论/备注 | 关闭时必填 | 留痕用，避免同一问题反复讨论 |
字段缺失的风险很具体：没有责任人，假设无人验证，测试执行时才发现前提不成立；没有截止时间，待确认项在范围评审后长期开放，排期建立在未决策的假设上；没有依据，排除项在复盘时说不清为什么当时不测。项目规模小、参与人少时，可以合并“影响”和“备注”，但编号、类型、对象、描述、责任人五列建议始终保留。
填写示例：一份填好的范围清单片段
以下是一个演示场景：某内部订单系统本期增加批量导入功能，测试范围清单在范围评审前填写。示例中的项目、人名和时间均为示意，用于展示四类记录的写法差异。
| 编号 | 范围类型 | 模块/对象 | 内容描述 | 依据 | 影响 | 责任人 | 截止时间 | 状态 | 关闭结论/备注 |
|---|---|---|---|---|---|---|---|---|---|
| R-01 | 纳入 | 批量导入-文件解析 | 覆盖 CSV 与 Excel 两种格式的正常导入、字段缺失、格式错误提示 | 需求 ORD-112 第 3 节 | 核心路径，缺陷会阻断上线 | 测试负责人 | 本轮测试结束 | 开放 | |
| R-02 | 纳入 | 批量导入-权限 | 验证仅具备导入权限的角色可执行导入，无权限角色入口不可见 | 需求 ORD-112 第 5 节 | 涉及数据安全 | 测试负责人 | 本轮测试结束 | 开放 | |
| E-01 | 排除 | 批量导入-历史数据迁移 | 本期不测历史订单数据的迁移校验 | 范围评审结论 3 月 5 日 | 迁移由数据组单独安排，不在本期上线范围 | 数据组接口人 | — | 已关闭 | 转由数据组迁移专项覆盖 |
| A-01 | 假设 | 批量导入-文件大小 | 假设单次导入文件不超过 5 万行，按此规划性能测试用例规模 | 与产品经理口头确认 | 若实际上限更高，性能用例需扩充，测试周期增加约两天 | 性能测试人员 | 测试设计评审前 | 开放 | 验证方式：查阅产品配置与需求附录；失效则补充大文件用例 |
| Q-01 | 待确认 | 批量导入-重复数据 | 导入文件中存在重复订单号时，是覆盖、跳过还是报错，尚未决策 | 需求文档未写明 | 结论不同会改变异常场景用例数量和预期结果 | 产品经理 | 测试用例评审前 | 开放 | 关闭后按结论转为纳入项或排除项 |
对比 A-01 和 Q-01 可以看出写法差异：假设条目已经按“5 万行以内”规划了用例规模，需要写清验证方式和假设不成立时的代价；待确认条目是范围本身还没定，需要写清由谁在什么时间点给出结论。两者都带责任人，但假设的责任人是验证人，待确认项的责任人是决策人。
调整与维护：评审后如何更新清单
清单在范围评审时逐条过，评审后进入维护状态。维护的核心动作有三个：确认假设、关闭待确认项、记录变更。
评审时按类型逐条确认。纳入项确认对象和测试类型是否完整，排除项确认原因和后续归属是否写清，假设项确认验证方式和验证时间点是否可执行，待确认项确认责任人和截止时间是否明确。评审中当场能定的待确认项，直接写结论并关闭；定不了的，保留开放状态并确认截止时间不晚于用例评审。
待确认项关闭后，按结论转为纳入项或排除项，在原条目上写关闭结论并注明转为哪条编号，不删除原记录。假设项验证后标记“已验证”或“未成立”，未成立的假设要评估对已排范围的影响，必要时新增纳入项或调整排期。这样同一问题不会在后续评审中反复出现。
变更时更新版本并记录变更原因。建议在清单顶部保留版本号和修订记录，每次范围调整注明改了哪几条、为什么改、谁确认。测试执行阶段以最新版本为准，旧版本留存备查。范围评审、用例评审、测试执行开始前是三个固定检查点，分别核对假设是否验证、待确认项是否关闭、排除项是否仍然成立。
清单需要承载和协作时，可以放在团队已有的文档或工作项工具中。以 ONES 为例，测试用例与需求、任务关联，测试计划与迭代关联，范围清单中的纳入项和待确认项可以对应到具体需求与测试计划，评审结论和状态变化留在同一条记录上；测试计划支持多维度概览和进度查看，待确认项是否关闭、假设是否验证可以直接对照计划进度检查。清单本身仍以表格形式维护，工具承担的是关联、权限和跟踪，具体用法按团队现有流程安排。
常见问题
假设项验证后不成立，已经排好的测试范围怎么处理？
先评估影响面：这条假设支撑了哪些用例、哪些排期。假设不成立时，在原条目上标记“未成立”并写清实际前提，然后判断是否需要新增纳入项、调整用例规模或重排时间。如果影响只落在个别用例，补充用例并更新清单即可；如果影响性能或兼容性等整类测试，需要同步给项目负责人调整计划。原假设记录保留，不删除，便于复盘时说明范围为何变化。
待确认项到了截止时间还没有结论，清单上怎么记？
不要直接关闭，也不要把状态改成“已验证”。在原条目上更新截止时间并写明延期原因和新的决策时间点，同时评估这段等待期对测试设计的影响：相关用例可以先按最可能的结论编写，但要在用例中标注依赖该待确认项。如果延期已经影响用例评审或测试执行，需要升级给项目负责人，由其在范围层面决定是缩小范围还是推迟节点。
小项目参与人少，模板字段可以精简到什么程度？
编号、范围类型、模块/对象、内容描述、责任人五列建议始终保留，这五列决定了清单能否被评审和追踪。项目小、条目少于十条时，可以把“影响”和“关闭结论/备注”合并为一列备注，“状态”列也可以暂不设，用备注里的文字说明开放或关闭。假设和待确认项的截止时间不建议省略，没有时间点这两类记录容易一直悬着。
清单放在文档里还是工作项工具里更合适？
取决于清单需要承担多少跟踪工作。如果清单主要用于范围评审和存档，放在文档工具里以表格维护即可，版本和修订记录也容易保留。如果需要把纳入项、待确认项和具体需求、测试计划关联起来，跟踪状态变化和责任人，可以放在支持需求与测试计划关联的工作项工具中。以 ONES 为例，测试用例与需求、任务关联，测试计划与迭代关联，范围清单中的条目可以对应到具体需求与测试计划，评审结论和状态变化留在同一条记录上。清单本身仍以表格形式维护，工具承担关联与跟踪。
排除项写进清单后，后续还需要复查吗？
需要。排除项的依据可能随需求变更或排期调整而变化，测试执行开始前应复查一遍：原来不测的内容是否已经进入本期范围，排除原因是否仍然成立。复查发现变化时，新增一条纳入项并注明由哪条排除项转来，原排除项保留并写关闭结论。这样范围变化有据可查，复盘时也能说清当时为什么排除。
