测试范围清单模板：纳入、排除、假设与待确认项怎么列

2026年11月6日

测试范围清单要解决的是“测什么、不测什么、凭什么这样定”在团队里说不清的问题。一份可用的清单用同一张主表承载纳入项、排除项、假设和待确认项：纳入与排除写清对象和边界，假设写成“若某条件成立则范围如何”的可验证陈述，待确认项写成带责任人和截止时间的开放问题，并注明未确认时对测试执行的影响。下面给出空白模板、字段口径、必填规则、完整示例和更新方法。

Table of Contents

要点总览（TL;DR）

测试范围清单用一张主表承载纳入、排除、假设、待确认四类记录，用“范围类型”列区分，编号前缀固定为 R/E/A/Q，便于跨文档引用。
假设写成“若某条件成立，则某对象纳入或排除”的可验证陈述，同时给出验证动作；待确认项写成“问题 + 责任人 + 截止时间 + 未确认时的处置”。
进入范围评审的最低完整度：每条记录具备编号、范围类型、对象、边界描述、依据来源和状态；假设与待确认项额外具备责任人和截止时间。
假设验证后转为纳入或排除项，待确认项关闭时把结论落到新记录上；每次评审通过冻结版本，变更记录保留变更前后内容与原因。
清单可由测试负责人维护完整度，假设和待确认项由各自责任人推进，发布前确认没有停留在待评审状态的记录。

可复制空白模板：测试范围清单主表

主表采用一行一条记录的平铺结构，四类内容通过“范围类型”列区分，避免拆成多张表后彼此失去关联。下表可直接粘贴到文档或表格工具中，按需增删行。

编号	范围类型	对象	边界描述	依据来源	影响	验证方式	责任人	状态	截止时间	备注
R-001	纳入
R-002	纳入
E-001	排除
E-002	排除
A-001	假设
A-002	假设
Q-001	待确认
Q-002	待确认

四类记录放在同一张表里，好处是假设被证伪时可以直接看到它牵连了哪些纳入项和排除项；如果拆表维护，这种关联容易在版本更替中丢失。状态列统一使用“草稿、待评审、已确认、已关闭、已失效”五个值，四类记录共用同一套状态词，减少理解成本。

字段说明：每一列填什么、怎么判断填对了

字段口径统一后，不同角色填出来的清单才能直接比对。下表逐列说明含义、填写口径和常见错误。

字段	含义	填写口径	常见错误
编号	记录的唯一标识	类型前缀加三位序号，全表不重复	复用旧编号，导致引用指向错误记录
范围类型	记录属于哪一类	只能填纳入、排除、假设、待确认之一	把待确认项直接写成纳入项，掩盖未决问题
对象	范围指向的功能、模块、接口、数据或环境	写到可识别的层级，如“订单退款接口”“移动端登录”	只写“核心功能”“相关模块”这类无法定位的表述
边界描述	该对象测到什么程度、从哪里开始不测	纳入项写覆盖的操作路径与数据条件；排除项写清排除的具体部分	纳入项只写对象名，排除项只写“不测”
依据来源	这条判断来自哪里	需求文档条目、接口约定、架构说明、会议结论或历史缺陷	留空或写“大家都知道”
影响	该记录对测试执行或交付结论的作用	写具体后果，如“未覆盖则退款金额异常无法在上线前发现”	写“影响较大”这类无法判断程度的词
验证方式	假设如何被证实或证伪	写可执行的动作和判定标准，如“查看接口文档确认是否支持部分退款”	写“后续确认”而没有具体动作
责任人	对该记录负责的人	写具体姓名或岗位，假设和待确认项必填	写“测试组”“相关同事”
状态	记录当前处理阶段	从草稿、待评审、已确认、已关闭、已失效中选一个	长期停留在草稿，评审时无法判断是否已处理
截止时间	需要得出结论的最晚时间	待确认项必填，写到具体日期	写“尽快”“上线前”
备注	补充信息	记录关联编号、讨论链接或临时处置	把关键结论只写在备注里，主字段留空

假设与待确认项的写法差异

假设是团队已经倾向接受、但需要验证的条件，写法是“若……成立，则……纳入/排除”。例如“若支付网关在测试环境支持沙箱回调，则退款回调链路纳入本轮范围”。这句话包含条件、验证动作和范围结论三部分，任何人拿到都能判断它是否成立、成立后范围怎么变。

待确认项是尚未形成倾向的开放问题，写法是“问题 + 责任人 + 截止时间 + 未确认时的处置”。例如“优惠券叠加规则是否在本轮范围内，责任人张某，截止 3 月 12 日；未确认前按不叠加场景设计用例，确认后再补充”。两者的区别在于：假设已有默认结论，验证是为了确认；待确认项没有默认结论，必须有人推动形成结论。

可验证的假设要避免三种写法：条件不可观测（“若系统稳定”）、结论不指向范围（“若接口正常则继续测试”）、验证动作缺失（“假设数据库有测试数据”）。改成“若测试库中存在近 30 天订单数据，则历史订单查询纳入范围，验证方式为查询测试库数据量并截图记录”，就同时具备条件、结论和验证动作。

必填与选填：哪些字段缺失就不能进入评审

清单进入范围评审前，需要达到的最低完整度是：每条记录都有编号、范围类型、对象、边界描述和依据来源；假设和待确认项额外具备责任人、状态和截止时间。缺这些字段，评审只能讨论印象，无法形成可执行的结论。

字段	必填/选填	理由或适用场景
编号	必填	后续引用、变更记录和缺陷关联都依赖它
范围类型	必填	决定该记录按哪套规则处理
对象	必填	没有对象就无法判断范围是否合理
边界描述	必填	范围清单的核心信息，缺失等于没有范围
依据来源	必填	评审时需要核对判断是否有出处
影响	选填	排除项和待确认项建议填写，用于排优先级
验证方式	假设必填	没有验证方式的假设无法被证实或证伪
责任人	假设、待确认必填	纳入和排除项可填模块负责人
状态	必填	评审需要区分已处理和未处理记录
截止时间	待确认必填	没有时间的开放问题会一直悬空
备注	选填	用于关联编号、讨论记录和临时处置

缺失必填项时，不建议在评审会上现场补。处理方式是：由记录提出人补齐后重新提交，评审只对完整记录给出结论；确实无法当场补齐的，降级为待确认项，补上责任人和截止时间，并写明未确认期间测试按什么口径执行。这样既不阻塞评审，也不让不完整的信息混入已确认范围。

填写示例：一份完整的测试范围清单

以下示例假设一个电商订单模块的版本测试，演示四类记录如何在同一张表中配合使用。示例中的对象、时间和人名均为演示情景。

编号	范围类型	对象	边界描述	依据来源	影响	验证方式	责任人	状态	截止时间	备注
R-001	纳入	订单退款接口	覆盖全额退款、部分退款、重复退款拦截三条路径，含成功与失败返回	需求文档 4.2 节	退款金额错误会直接影响资金结算	—	李某	已确认	—	关联 Q-001
R-002	纳入	移动端登录	覆盖账号密码登录、验证码登录及登录态过期后的重新登录	需求文档 2.1 节	登录异常会阻断全部移动端功能验证	—	王某	已确认	—
E-001	排除	历史订单数据迁移	本轮不验证迁移脚本，仅验证迁移后新订单查询；迁移数据一致性由数据组单独验证	项目周会结论	若迁移数据有误，需在数据组验证结果中体现	—	数据组	已确认	—
E-002	排除	第三方支付渠道对账	不覆盖渠道侧对账文件生成，仅验证系统内对账结果展示	接口约定文档	渠道侧问题由对接方负责，测试结论中注明	—	李某	已确认	—
A-001	假设	退款回调链路	若支付网关在测试环境支持沙箱回调，则退款回调链路纳入本轮范围；否则仅验证主动查询结果	与支付网关对接记录	回调未覆盖时，异步到账异常可能漏测	在测试环境发起一笔退款，观察是否收到回调并记录时间	李某	待评审	3 月 10 日	关联 R-001
A-002	假设	优惠券叠加	若产品确认本轮仅支持单券使用，则叠加场景排除；若支持叠加，则补充组合用例	需求文档 5.3 节表述不明确	叠加规则影响订单金额计算	向产品负责人确认规则并留存书面回复	王某	待评审	3 月 11 日	关联 Q-002
Q-001	待确认	退款审批流	大额退款是否需要审批、审批节点是否在本轮上线，尚未确定	需求评审遗留问题	未确认前不设计审批流用例；若上线则需追加一轮回归	产品负责人给出书面结论	张某	待评审	3 月 12 日	关联 R-001
Q-002	待确认	优惠券叠加规则	多张优惠券能否同时使用、叠加顺序如何计算，需求文档未写明	需求文档 5.3 节	未确认前按单券场景执行，叠加场景暂不纳入	产品负责人补充需求说明	张某	待评审	3 月 11 日	关联 A-002

示例中 A-001 展示了假设的完整写法：条件是可观测的沙箱回调，结论明确指向纳入或排除，验证方式是一个具体动作。Q-001 展示了待确认项的处置口径：未确认前不设计审批流用例，确认上线后追加回归，这样测试执行不会因为问题悬空而停摆。A-002 与 Q-002 互相关联，说明同一议题可以先以假设形式给出默认结论，同时保留待确认项推动最终决策。

当清单需要多人同时维护状态、责任人和截止时间时，可以把主表放进 ONES 工作项或文档中承载：每条记录对应一个工作项，状态字段与工作项状态联动，责任人通过指派体现，截止时间进入日程提醒，范围评审时按状态筛选出待评审和待确认记录集中讨论。这样清单从静态表格变成可跟踪的记录，假设被证伪时也能直接关联到受影响的纳入项。

调整与维护：范围变化时如何更新清单

范围清单在测试过程中会持续变化，维护规则要回答三件事：状态怎么流转、结论怎么落位、变更怎么留痕。

假设与待确认项的状态流转

假设的流转路径是：待评审 → 已确认（验证成立，转为纳入或排除项）或已失效（验证不成立，按预设的另一分支调整范围）。待确认项的流转路径是：待评审 → 已关闭，关闭时必须写明结论，并把结论落到一条新的纳入项或排除项上，原待确认项保留编号并标注“已关闭，结论见 R-00X”。

状态变更需要同时更新三处：本条记录的状态、受影响的纳入或排除项的边界描述、变更记录中的一行说明。只改状态不改关联记录，是范围漂移最常见的来源。

版本与变更记录

建议在主表之外维护一张变更记录表，字段包括：变更日期、变更编号、变更类型（新增、修改、关闭）、变更前内容、变更后内容、变更原因、提出人、评审人。清单本身按版本号管理，如 V1.0 为首次评审通过版本，V1.1 为假设验证后的调整版本。每次评审通过后冻结一个版本，后续修改在新版本上进行，便于回溯某一轮测试实际依据的范围。

评审节点与更新频率

清单至少在两个节点更新：范围评审前完成一轮完整填写，测试执行中期做一次假设与待确认项的清理。测试执行期间，新增的待确认项应当天登记，不积压到评审会；假设的验证结果在截止时间当天更新状态。版本发布前，所有待确认项必须关闭或明确转为下一轮范围，清单中不应留有状态为待评审的记录。

如果团队使用 ONES 承载清单，变更记录可以直接复用工作项的操作历史，评审节点对应迭代或里程碑的检查项，发布前按状态筛选即可确认是否还有未关闭的待确认项。清单的维护责任建议落在测试负责人身上，假设和待确认项的具体推进由各自责任人完成，测试负责人只负责在评审节点检查完整度和状态一致性。

常见问题

假设验证后不成立，清单里应该怎么处理？

假设被证伪时，把该条状态改为“已失效”，并按假设中预设的另一分支调整范围：原本“若成立则纳入”的对象改为排除项，或反之。同时更新受影响的纳入项、排除项的边界描述，并在变更记录中写明验证结果和调整原因。原假设记录保留编号，备注中注明“已失效，结论见 E-00X 或 R-00X”，便于回溯范围变化过程。

待确认项在截止时间前没人回复，测试还能继续吗？

可以继续，前提是清单里已经写明未确认时的处置口径。例如“未确认前按单券场景执行，叠加场景暂不纳入”，测试就按这个口径推进，不因问题悬空而停摆。截止时间到达仍未确认时，由责任人升级给决策方，或把该待确认项转为下一轮范围，并在清单中记录处置结果。发布前所有待确认项必须关闭或明确转出，不能保留待评审状态。

纳入项和排除项需要写到多细？

写到评审时能判断范围是否合理的程度即可。对象要可识别，如“订单退款接口”“移动端登录”，避免“核心功能”这类无法定位的表述；边界描述要说明覆盖哪些操作路径和数据条件，排除项要写清排除的具体部分以及由谁负责。过细会拖慢填写，过粗则评审只能讨论印象。可以先用一轮评审检验粒度，再统一团队口径。

清单需要每个迭代都重新建一份吗？

不必每次重建。可以按版本延续使用：上一轮已确认的纳入项和排除项作为基线，新迭代只增删变化部分，假设和待确认项重新登记。每次评审通过后冻结一个版本号，后续修改在新版本上进行。这样既能复用已有结论，也能回溯某一轮测试实际依据的范围。跨迭代长期有效的排除项，建议在备注中注明适用版本或有效期。

多人同时维护清单时，怎么避免状态和结论不一致？

关键是让状态变更和关联记录更新同步完成。可以约定：状态变更时同时更新受影响的纳入或排除项边界描述，并在变更记录中留一行说明；评审前由测试负责人按状态筛选，检查是否还有待评审记录以及假设是否都有验证结果。若清单放在 ONES 工作项或文档中承载，状态、责任人和截止时间可以直接沿用工作项字段，操作历史作为变更记录，减少两处维护带来的不一致。