确定测试范围，核心是把“要验证什么、不验证什么、依据是什么”写成一份可评审的边界清单。做法上，先以需求与设计为输入，拆出功能、接口、数据、非功能与回归五类对象，再按风险与变更影响排序，明确纳入项、排除项及排除理由，最后落到用例集、环境与准入准出条件，由产品、开发、测试三方评审确认。范围会在需求澄清、提测、变更三个节点滚动校准。
要点总览（TL;DR）
- 测试范围要回答五个问题：测什么对象、测到什么程度、不测什么及理由、依据哪份输入、由谁确认，五类对象按功能、接口、数据、非功能、回归逐类清点。
- 拆解按四步推进：收集需求与设计输入、按业务链路拆功能点与接口、按风险与变更影响定测试深度、形成范围基线并同步到用例集与环境。
- 范围由产品、开发、测试三方共同确认：产品定业务边界与优先级，开发说明技术影响面，测试负责拆解、风险排序与文档编写，排除项须有风险接受人。
- 范围条目可关联到需求、任务与用例，评审与变更通过状态流转留痕，范围调整后同步更新用例集与提测准入条件。
- 定稿前逐项核对：纳入项有依据与深度、排除项有理由与接受人、五类对象无整类缺失、已三方评审、已映射用例与环境。
先定边界：测试范围要回答的五个问题
一份能直接用于执行的测试范围说明，需要回答五个问题：测什么对象、测到什么程度、不测什么及理由、依据哪份输入、由谁确认。这五个问题对应范围清单的五个字段，缺任何一项，范围都会在执行阶段被反复追问。
对象划分建议固定为五类，便于逐类清点，避免遗漏：
- 功能：新增或变更的业务功能点，按业务链路组织，如“订单提交—支付回调—退款申请”。
- 接口：系统间或服务间的调用契约，包括请求参数、返回结构、异常码与超时处理。
- 数据：数据流向、字段映射、迁移与初始化数据、边界值与脏数据处理。
- 非功能：性能、兼容性、安全、可用性等与业务功能正交的验证项，按本次变更是否触及决定纳入深度。
- 回归：受改动影响的老功能，范围由变更影响面推导，而非全量重跑。
“测到什么程度”用测试深度表达，建议分三档：冒烟（主链路可通）、核心（主链路加关键分支与异常）、全量（含边界、异常与兼容组合）。深度与对象绑定，同一对象在不同迭代可以有不同深度。
纳入项与排除项都要写理由。纳入项的理由指向需求条目或风险判断；排除项的理由指向“本次未改动”“影响面已由上游验证覆盖”“业务确认可延后”等具体依据，并指定风险接受人。没有风险接受人的排除项，在评审时视为未决项，不能进入基线。
| 字段 | 填写内容 | 示例 |
|---|---|---|
| 对象类别 | 功能/接口/数据/非功能/回归 | 接口 |
| 对象描述 | 具体功能点、接口名或数据范围 | 支付回调接口 v2 |
| 纳入/排除 | 二选一，排除须填理由 | 纳入 |
| 依据 | 需求编号、设计文档、缺陷记录 | 需求 REQ-231、接口文档 3.2 节 |
| 测试深度 | 冒烟/核心/全量 | 核心 |
| 确认人 | 产品、开发或风险接受人 | 产品负责人、后端负责人 |
从需求到范围：四步拆解操作
拆解过程按四步推进，每步都有明确的输入、动作、输出与完成标志，前一步的输出即后一步的输入。
第一步：收集输入
输入包括本轮需求文档、设计稿与接口文档、上一轮遗留缺陷与线上问题记录、变更清单。动作是逐份通读并标注疑点，输出是一份“输入清单加疑点列表”。完成标志是每份输入都有版本号，疑点已分配给对应责任人澄清。
第二步：按业务链路拆对象
以用户可感知的业务链路为主线，把需求拆成功能点，再向下挂接接口与数据流向。动作是画出链路草图，在每个节点标注涉及的接口、读写的数据表与外部依赖。输出是“功能点—接口—数据”三层对照表。完成标志是每个功能点都能追溯到需求条目，每个接口都能说明调用方与被调方。
第三步：按风险与变更影响排序
对每个对象评估两个维度：业务影响（出错后的用户与资金损失）与变更影响（本次改动的代码与配置范围）。两个维度都高的对象定为全量，单高的定为核心，都低的定为冒烟或排除。输出是带深度的对象清单。完成标志是每个对象的深度都有排序依据，没有“凭感觉”的档位。
第四步：形成范围基线
把对象清单整理成范围说明，同步到用例集与环境准备：纳入项对应到具体用例，排除项登记到排除清单，环境需求按接口与数据依赖列出。输出是范围基线文档、用例映射表与环境清单。完成标志是三方评审通过，基线版本号确定，后续变更走变更记录。
角色分工与交付物：谁定、谁审、谁执行
范围由测试单方拍板，执行阶段必然出现“这个也要测”的追加。合理做法是三方各担一段，交接物明确。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 产品 | 确认需求优先级与业务边界，判定哪些场景本轮可延后 | 需求优先级清单、业务边界说明 |
| 开发 | 说明技术影响面、改动文件与接口变更、依赖的外部系统 | 变更影响说明、接口变更清单 |
| 测试 | 拆解对象、做风险排序、编写范围说明并组织评审 | 范围清单、用例映射表、排除项登记 |
评审时逐条过纳入项与排除项，排除项必须当场确认风险接受人。评审结论记录在范围说明的版本记录中，写明日期、参与人与结论。变更发生时，由提出方补充变更原因，测试更新范围清单并标注受影响用例，产品与开发确认后升版。留痕的关键是每次变更都能回答“谁在什么时候因为什么改了范围”。
示例：一次版本迭代的范围确定过程
以下为演示情景，用于说明方法如何落地，非真实项目数据。
背景：某迭代包含两项内容，一是新增“优惠券叠加使用”功能，二是改造老“订单结算”页的金额计算逻辑，涉及前端展示与后端计价服务。
拆解后得到对象清单：功能类包括优惠券选择、叠加规则校验、结算金额展示；接口类包括计价服务新增的叠加计算接口、优惠券查询接口的返回结构变更；数据类包括优惠券状态流转与订单金额字段；非功能类包括结算页在弱网下的加载表现；回归类包括不使用优惠券的普通下单链路、退款金额计算。
风险排序结果：计价接口与金额展示业务影响高、变更影响高，定为全量；优惠券查询接口返回结构变更影响面中等，定为核心；弱网加载本次未改动前端框架，定为冒烟；历史优惠券的批量迁移脚本不在本轮上线范围，列为排除项，理由是本轮不执行迁移，风险接受人为产品负责人。
基线同步：全量项对应到计价与结算的用例集，核心项补充接口契约用例，冒烟项保留主链路用例；环境上需要一套带优惠券测试数据的结算环境，并在提测准入中增加“计价接口契约测试通过”作为前置条件。范围说明升版后，用例映射表与环境清单同步更新，后续若叠加规则调整，从变更记录追溯到受影响的用例范围。
范围在协作工具中的承载与流转
范围清单如果只存在文档里，评审结论与变更记录容易与需求、用例脱节。把范围条目挂到工作项上，可以让“范围—需求—用例—计划”保持同一条链路。
具体做法是：范围清单中的每个对象条目，关联到对应的需求或研发任务；纳入项进一步关联到测试用例，排除项保留在清单中并标注风险接受人。评审时通过工作项状态流转记录“待评审—已确认—变更中”的过程，变更原因写在状态变更说明里。范围调整后，受影响的用例集与提测准入条件同步更新，测试计划按新范围重新分配执行人。
ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；测试计划可多维度概览并查看进度，用例可分配执行人；同时支持为用例库、测试计划单独配置权限。这些能力可以承载上述“范围条目关联需求、用例随范围调整、计划按范围执行”的流转。范围清单本身是否需要专门字段或模板，需结合团队实际配置确认。
完成检查：范围是否可执行的判断标准
范围定稿前，逐项核对以下条目，全部通过才进入执行。
- 每个纳入项都写明了依据（需求编号、设计文档或缺陷记录），并标注了测试深度。
- 每个排除项都有具体理由，并指定了风险接受人，无未决项。
- 五类对象（功能、接口、数据、非功能、回归）均已清点，没有整类缺失。
- 范围说明已经过产品、开发、测试三方评审，版本号与评审记录完整。
- 纳入项已映射到具体用例，用例集覆盖范围清单中的全部对象。
- 环境需求按接口与数据依赖列出，提测准入条件已包含范围相关的前置项。
- 变更触发条件明确：需求澄清、提测、变更三个节点均安排重新校准，并有变更记录模板。
检查中发现排除项缺少风险接受人，或纳入项找不到对应用例，说明范围尚未定稿，应回到拆解或评审环节补齐，而不是带着缺口进入执行。
常见问题
需求文档本身写得不够细，还能确定测试范围吗？
可以，但要把缺口显式记录。做法是把需求中不明确的地方整理成疑点列表，分配给产品与开发澄清，澄清结论作为范围条目的依据写入清单。对于澄清前无法判断的对象，先按风险维度给出暂定深度，并在范围说明中标注“待澄清”，评审时逐条确认。这样范围仍然可执行，同时把不确定性留在明面上，避免执行阶段临时追加。
范围评审时产品和开发对排除项有分歧，怎么处理？
把分歧落到具体依据上讨论：排除项的理由应指向“本次未改动”“影响面已由上游验证覆盖”或“业务确认可延后”这类可核对的事实，而不是笼统判断。若仍无法达成一致，可由业务方指定风险接受人并记录在清单中，或将该对象降级为冒烟深度纳入。评审结论与参与人写入版本记录，后续出现问题时可以回溯当时的判断依据。
迭代中途需求变更，已经定稿的测试范围怎么调整？
由变更提出方补充变更原因，测试据此更新范围清单，标注受影响的对象与用例，产品与开发确认后升版。调整时重点看两处：新增或修改的对象是否需要提高测试深度，以及原有排除项是否因变更重新进入范围。更新后的范围同步到用例集与提测准入条件，测试计划按新范围重新分配执行人，变更记录保留在版本说明中。
小团队人手有限，五类对象都要逐类清点吗？
五类划分的作用是防止整类遗漏，清点动作可以简化但不能跳过。人手紧张时，功能与回归按业务链路合并清点，接口与数据只列本次改动涉及的部分，非功能项按变更是否触及决定是否纳入。每类的条目可以少，但要在清单中体现“已考虑”的痕迹，例如写明“本次未涉及数据迁移”。范围说明的字段仍保留依据、深度与确认人，保证执行时有据可查。
范围清单在协作工具里怎么和用例、计划保持同步？
把范围条目关联到对应的需求或研发任务，纳入项进一步关联测试用例，排除项保留在清单中并标注风险接受人。评审与变更通过工作项状态流转记录，变更原因写在状态变更说明里。范围调整后，受影响的用例集与提测准入条件同步更新，测试计划按新范围重新分配执行人。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，测试计划可多维度概览并查看进度，用例可分配执行人，能够承载这条链路；范围清单是否需要专门字段或模板，需结合团队实际配置确认。
