划定测试范围边界，先以需求、变更单和风险清单为输入，按“纳入—待定—排除”三类逐项判定并写明依据；再把范围假设和排除项分别登记，标注责任人与复核时点；最后合并为可评审的范围基线，经需求、开发、测试三方确认后冻结版本，后续变更走变更记录。本文给出可直接套用的判定表、假设表、排除项表与完成检查清单。
要点总览（TL;DR）
- 划定范围边界从需求文档、变更单、接口说明、历史缺陷与风险清单、环境说明五类输入出发，明确功能、接口、环境、测试类型四个判定维度。
- 把范围拆成可独立判定的最小对象，按纳入、待定、排除三类逐项归类，每项记录对象、分类、依据、责任人、复核时点五个字段。
- 范围假设单独登记，写明影响范围、验证方式、验证时点和责任人；假设被推翻时回查判定表，同步调整范围与排除项。
- 排除项要写清排除内容、理由、风险接受人和复核时点，并注明后续补测的版本或触发条件。
- 范围说明、判定表、假设表、排除项表加评审记录合并为带版本号的范围基线，三方确认后冻结，后续变更走变更记录并更新版本号。
划定范围边界前先准备哪些输入
范围边界来自对输入材料的逐项判定，材料不齐时先列为待定项，避免把“没看到”当成“不需要测”。开始判定前，测试负责人应收集以下材料，并登记来源与责任人。
| 材料 | 用途 | 来源与责任人 |
|---|---|---|
| 需求文档（含验收标准） | 确定功能点清单与判定“纳入”的基本依据 | 需求负责人 |
| 变更单 | 识别本次版本新增、修改、删除的功能，确定回归范围 | 需求负责人、开发负责人 |
| 架构与接口说明 | 拆分接口与依赖系统，判断哪些接口需要覆盖 | 开发负责人 |
| 历史缺陷与风险清单 | 识别高风险模块，作为提高测试深度的依据 | 测试负责人 |
| 环境与数据说明 | 确认测试环境、版本、数据可用性，形成环境类假设 | 测试负责人、运维或环境管理员 |
同时要明确本次版本的范围口径，即判定对象覆盖四个维度：功能（哪些功能点）、接口（哪些内外部接口）、环境（哪些环境与版本组合）、测试类型（功能、性能、兼容性、安全等分别做不做）。口径不写清，后续判定会各说各话。
输入不全时，把缺失材料对应的对象列入“待定”，记录缺失内容和补齐责任人，并设定补齐时点。待定项在补齐前不默认纳入，也不默认排除，防止范围被悄悄放大或缩小。
按纳入、待定、排除三类逐项划定范围
把范围拆成可判定的最小对象，再逐项归类。拆分粒度以“能独立判定、能独立指派责任人”为准：功能按需求条目拆，接口按调用关系拆，环境按部署组合拆，测试类型按类别拆。
三类判定依据如下：
- 纳入：本次变更直接影响、验收标准明确要求、或历史缺陷集中且风险高的对象。依据写明需求条目编号或风险条目。
- 待定：输入缺失、需求口径未确认、依赖方未答复的对象。依据写明待确认事项与责任人。
- 排除：本次版本不涉及、明确不在验收范围、或经风险接受人同意不测的对象。依据写明排除理由，并转入排除项登记表。
每项记录五个字段，形成范围判定表：
| 对象 | 分类 | 依据 | 责任人 | 复核时点 |
|---|---|---|---|---|
| 订单导出功能 | 纳入 | 变更单 CR-102，验收标准第 3 条 | 测试工程师 A | 用例评审前 |
| 第三方支付回调接口 | 待定 | 接口文档未更新，待开发确认 | 开发负责人 | 版本启动后第 2 天 |
| 旧版报表页面 | 排除 | 本版本下线，不再维护 | 需求负责人 | 基线评审时 |
判定完成后做一次完整性核对：需求条目、接口清单、环境清单中的每一项都应出现在判定表中，没有归类的对象视为遗漏，补判后再进入下一步。
如何记录范围假设并标注验证方式
范围假设是范围成立所依赖、但尚未被证实的前提。把它单独登记，是为了在前提不成立时能及时调整范围，避免假设被当成既定事实执行。
常见假设分四类：外部依赖（第三方系统按约定时间提供联调环境）、数据可用性（测试数据已脱敏且覆盖关键场景）、环境与版本（测试环境版本与发布版本一致）、需求理解口径（某条验收标准的解释方式）。
每条假设登记以下字段：
| 假设内容 | 影响范围 | 验证方式 | 验证时点 | 责任人 |
|---|---|---|---|---|
| 支付回调接口在测试环境可用 | 支付相关 6 个功能点 | 发起一笔沙箱交易验证回调 | 用例执行前 | 测试工程师 B |
| 测试数据覆盖近 12 个月订单 | 报表统计类功能 | 抽样核对数据量与时间跨度 | 测试准备阶段 | 测试负责人 |
假设被推翻时，按影响范围回查判定表：受影响对象从“纳入”改为“待定”或“排除”，同步更新排除项与风险接受人，并在变更记录中写明调整原因和确认人。
如何记录排除项并说明排除理由
排除项要写到“排除什么、为什么排除、谁接受风险、何时复核”四个要素齐全，使排除可追溯、可复核。排除不等于产品不支持该能力，只表示本次版本不覆盖。
排除项分三类：不测的功能（本版本未变更且低风险）、不覆盖的接口与环境（如特定浏览器、特定部署组合）、不执行的测试类型（如本版本不做性能压测）。
| 排除内容 | 排除理由 | 风险接受人 | 复核时点 |
|---|---|---|---|
| IE 浏览器兼容性 | 用户占比低于约定阈值，本版本不做适配 | 产品负责人 | 下个版本规划时 |
| 历史订单迁移脚本 | 已在上个版本完成并验证 | 测试负责人 | 基线评审时 |
排除项要与后续回归衔接：注明该对象在哪个版本或触发条件下补测，例如“下个版本功能变更时纳入回归”。这样排除项在版本演进中仍有明确去向，不会长期悬空。
角色分工与各环节交付物
范围划定涉及四类角色，职责与交付物按下表分工，交接时点与评审节点对齐。
| 角色 | 职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 测试负责人 | 组织判定、汇总判定表、维护假设与排除项、发起评审 | 范围判定表、假设表、排除项表、范围基线 | 版本启动时启动，评审前提交 |
| 需求负责人 | 确认需求口径、判定功能类对象、确认排除理由 | 需求条目与验收标准确认意见 | 判定阶段与评审时 |
| 开发负责人 | 提供接口与环境信息、确认技术类待定项 | 接口清单、环境说明、待定项答复 | 判定阶段第 2 天前 |
| 风险接受人 | 对排除项与高风险不测项签字确认 | 排除项确认记录 | 基线评审时 |
评审由测试负责人组织，需求、开发、测试三方参加，确认方式为逐项核对判定表、假设表、排除项表并签字或在工作项中确认。评审未通过的项回到待定，补齐后再评审。
范围基线、假设与排除项需要在文档与工作项中承载并留痕时，可以在 ONES 中把范围说明写成文档、把待定项与排除项建成工作项，指定责任人与复核时点，评审意见和变更记录随工作项保留，便于后续版本追溯。
示例：一次版本测试范围基线的形成过程
以下为演示情景，用于说明流程，非真实项目数据。
某订单系统发布 V2.3，输入包括变更单 CR-102（新增订单导出、调整支付回调）、需求文档、接口说明、历史缺陷清单（支付模块缺陷占比偏高）以及测试环境说明。
判定结果示例：订单导出功能纳入，依据 CR-102 与验收标准；支付回调接口待定，因接口文档未更新；旧版报表页面排除，因本版本下线；性能测试类型排除，因本版本无性能相关变更，风险接受人为产品负责人。
假设登记两条：支付回调接口在测试环境可用（影响 6 个功能点，用例执行前由测试工程师 B 验证）；测试数据覆盖近 12 个月订单（测试准备阶段由测试负责人抽样核对）。
评审时开发负责人补齐接口文档，支付回调接口由待定转为纳入；三方确认判定表、假设表、排除项表后冻结基线 V1.0，评审意见与确认记录一并归档。版本中期接口文档再次变更，走变更记录，重新确认后基线升为 V1.1。
形成可评审的范围基线并管理变更
范围基线由四部分合并而成：范围说明（口径与判定规则）、范围判定表、假设表、排除项表，外加评审记录。每份文档标注版本号与日期，基线整体给一个版本标识，例如 V1.0。
评审要点包括：判定对象是否覆盖全部需求与接口；待定项是否都有责任人和补齐时点；排除项是否都有理由与风险接受人；假设是否都有验证方式。四项齐全且三方确认，基线通过并冻结。
基线冻结后，范围变更按变更记录处理：记录变更对象、原因、提出人、影响的范围条目，重新走一次判定与确认，更新基线版本号。变更未确认前，执行仍以当前冻结版本为准。
完成检查：范围基线是否可用
基线提交评审前，用以下清单逐项核对，全部满足即可视为可执行、可评审：
- 需求条目、接口清单、环境清单中的每个对象都已在判定表中归类，无遗漏。
- 每个待定项都有责任人、补齐内容和补齐时点。
- 每条假设都有影响范围、验证方式、验证时点和责任人。
- 每个排除项都有排除理由、风险接受人和复核时点，并注明后续补测衔接。
- 评审记录包含参与方、确认方式与结论，变更记录包含变更原因与重新确认人。
- 基线文档有版本标识和日期，与判定表、假设表、排除项表版本一致。
常见问题
需求文档本身写得含糊，范围判定还能往下做吗？
可以继续，但要把含糊的部分显式转为待定项。做法是把该需求条目列入判定表的“待定”分类，依据栏写清含糊点，例如验收标准未定义边界值或异常场景，责任人填需求负责人，复核时点设为用例评审前。待定项在补齐前既不默认纳入也不默认排除，避免范围被悄悄放大或缩小。若到复核时点仍未澄清，由测试负责人升级到需求负责人和风险接受人，决定是缩小范围还是延后该功能。
排除项被风险接受人签字后，后续版本还需要重新评估吗？
需要。排除项登记表里的复核时点就是为这件事准备的。常见做法是给每个排除项写明补测衔接条件，例如“下个版本该功能有变更时纳入回归”或“用户占比超过约定阈值时重新评估”。到了复核时点，测试负责人核对条件是否触发：触发则重新走一次判定，把对象从排除改为纳入或待定；未触发则更新复核记录并顺延。这样排除项在版本演进中有明确去向，不会长期悬空，也不会被误读为产品不支持该能力。
范围基线冻结后，开发中途提出接口变更，怎么处理才不影响执行？
按变更记录处理，执行仍以当前冻结版本为准。具体动作是：记录变更对象、原因、提出人和受影响的范围条目；对受影响对象重新做一次纳入、待定、排除判定；同步检查相关假设是否失效、排除项是否需要调整；三方重新确认后更新基线版本号，例如从 V1.0 升为 V1.1。变更未确认前，测试按 V1.0 执行，避免边改边测导致范围失控。若变更影响面大，可以先把受影响对象转为待定，待确认后再恢复执行。
待定项一直补不齐，评审还能通过吗？
可以带条件通过，但要把待定项的处理方式写进评审结论。常见做法是给每个待定项设定最晚补齐时点，并明确超期后的默认处理：要么缩小范围转为排除并由风险接受人签字，要么延后该对象的测试并在基线中标注。评审记录里写明这些条件和责任人，基线照常冻结。这样既不让个别待定项卡住整体评审，也保证待定项有明确出口，不会在执行阶段变成无人负责的空白。
范围判定表要拆到多细才算够？
以“能独立判定、能独立指派责任人”为粒度标准。功能按需求条目拆，接口按调用关系拆，环境按部署组合拆，测试类型按类别拆。拆得太粗会出现一个条目里既有纳入又有排除，无法指派；拆得太细会带来大量重复记录，维护成本高于收益。判定完成后做一次完整性核对：需求条目、接口清单、环境清单中的每一项都应出现在判定表中，没有归类的对象视为遗漏，补判后再进入假设与排除项登记环节。
