测试范围要回答的是“测什么、不测什么、测到什么程度”。很多团队写范围时只留下一句“本次测退款功能”，评审时谁都能点头，执行时却各按各的理解推进。本文给出一份假设的“订单退款功能”测试范围填写范例，把模糊表述拆成可对照的条目，再逐项说明每个字段为什么这样写、哪些地方容易写空，最后整理成可以迁移到其他功能或迭代的填写步骤。
要点总览（TL;DR）
- 测试范围要写清三件事：测什么、不测什么、测到什么程度；本文用假设的订单退款功能给出一份可对照填写的完整范例。
- 范例覆盖范围声明与测试目标、纳入项与排除项对照、测试层级与类型分配、环境数据与依赖条件、风险优先级与完成标准五组字段。
- 纳入项从需求变更点和风险后果推导，排除项必须写明理由与后续归属，完成标准要写成第三方可判断的条件。
- 迁移到其他功能可按四步生成纳入项，并用固定句式填写排除项与边界项，评审时逐条核对条件是否齐备。
- 范例基于假设情景，涉及资金、医疗、隐私等受监管领域或接口为主的项目时，需要调整字段与加严要求。
示例目标：这份测试范围范例要解决什么问题
本文使用一个假设情景：某电商系统的订单退款功能进行一次迭代，涉及退款申请入口、退款金额计算、退款状态流转和退款结果通知。这个情景为演示而设，不对应任何真实客户、真实项目或真实测试结果，文中出现的数量、比例和时长均为示例设定，用于说明写法。
范例要示范的填写动作，是把“测退款”这类模糊表述拆成可执行的范围条目。拆解过程需要回答几个具体问题：这次迭代改变了哪些行为，哪些行为一旦出错影响最大，哪些部分由其他团队或其他轮次覆盖，需要什么环境和数据才能验证，什么条件下可以判定测试结束。这些问题的答案落到文档上，就构成一份可评审、可交接的测试范围。
范例的边界也需要提前说明。它不包含具体测试脚本的编写、安全攻击与渗透方法、源码级实现细节，也不涉及对单份需求文档本身质量的评审。这些内容分别属于测试设计、安全专项、开发实现和需求管理的工作，测试范围只界定测试工作的覆盖边界与完成条件。
完整示例：订单退款功能的测试范围填写范例
下面这份范例按常见测试范围文档的字段顺序填写，各字段之间保持自洽：纳入项都有对应的测试层级和完成标准，排除项都写明了理由和后续归属，环境与数据条件支撑纳入项的验证需要。
范围声明与测试目标
范围声明：本次测试覆盖订单退款功能迭代新增与变更的行为，包括退款申请提交、退款金额计算、退款单状态流转、退款结果通知四部分；验证这些行为在正常流程、边界金额和异常状态下的表现，确认与订单、支付、账户余额等相关模块的交互符合需求约定。
测试目标（示例）：
- 退款金额计算在整单退款、部分退款、含优惠券订单、含运费订单四类场景下结果正确。
- 退款单在“申请—审核—退款中—成功/失败”各状态之间按约定流转，异常中断后可恢复或可人工处理。
- 退款结果通知在成功与失败两种结果下均能触达用户，通知内容与退款单状态一致。
- 本次迭代变更点相关的回归范围明确，历史退款流程不受影响。
纳入项与排除项对照
| 类别 | 条目 | 说明 |
|---|---|---|
| 纳入 | 退款申请入口与表单校验 | 含必填项、金额上限、重复提交拦截 |
| 纳入 | 退款金额计算 | 整单、部分、优惠分摊、运费处理四类场景 |
| 纳入 | 退款单状态流转 | 正常流转路径与审核驳回、退款失败两类异常路径 |
| 纳入 | 退款结果通知 | 站内通知与短信通知的内容一致性 |
| 纳入 | 与订单、支付、余额模块的接口交互 | 仅验证退款侧发起的调用与返回处理 |
| 纳入 | 本次变更点相关回归 | 历史订单发起退款的兼容性 |
| 排除 | 支付渠道侧的退款到账时效 | 由支付团队与渠道方保障，本范围只验证我方发起与状态回写 |
| 排除 | 财务对账与结算报表 | 由财务系统专项测试覆盖，退款数据作为其输入另行联调 |
| 排除 | 退款相关的促销规则调整 | 本次迭代未变更促销规则，留待促销模块下一轮测试 |
| 排除 | 性能与容量测试 | 退款为低频操作，本轮不做专项压测，列入季度性能计划 |
测试层级与测试类型分配
| 纳入项 | 测试层级 | 测试类型 | 覆盖重点 |
|---|---|---|---|
| 退款金额计算 | 单元测试、接口测试 | 功能、边界值 | 金额精度、优惠分摊、运费取舍 |
| 退款申请表单 | 界面测试、接口测试 | 功能、异常输入 | 校验规则、重复提交 |
| 退款单状态流转 | 接口测试、端到端测试 | 功能、状态迁移 | 正常路径与两类异常路径 |
| 退款结果通知 | 端到端测试 | 功能、内容一致性 | 通知触达与内容核对 |
| 模块间接口交互 | 接口测试、联调测试 | 集成 | 调用参数、返回处理、超时与重试 |
| 变更点回归 | 端到端测试 | 回归 | 历史订单退款流程 |
环境、数据与依赖条件
- 环境：使用独立测试环境，支付模块对接渠道沙箱，通知服务使用测试号码与测试账号。
- 数据：准备整单、部分退款、含优惠券、含运费四类订单样本各若干，覆盖不同金额区间；准备处于不同历史状态的订单用于回归。
- 依赖：支付团队提供沙箱退款接口与状态回写说明；通知服务提供测试模板；账户余额模块提供测试账户。
- 前置条件：退款状态机定义与金额计算规则在测试开始前完成评审并冻结，变更需走范围变更记录。
风险优先级与完成标准
风险优先级（示例）：退款金额计算错误列为最高优先级，直接影响资金；状态流转卡单与通知内容错误列为高优先级，影响用户信任与人工处理成本；表单校验与回归项列为中优先级。
完成标准（示例）：
- 纳入项对应的测试用例全部执行完毕，最高与高优先级项无未关闭的严重缺陷。
- 中优先级项的遗留缺陷已记录，并有明确的处理计划与责任人。
- 四类金额场景的验证结果均有记录，计算结果与预期一致。
- 状态流转的正常路径与两类异常路径均完成验证，异常路径的人工处理方式已确认。
- 范围变更记录中的条目全部关闭或明确转出。
逐项解释：每个字段为什么这样填
纳入项从需求变更点和风险推导而来，而非把功能菜单逐条抄一遍。范例中先找出本次迭代真正改变的行为，再判断哪些行为出错后果最重，两者合起来构成纳入项的主体。金额计算和状态流转之所以进入纳入项，是因为它们同时满足“本次有变更”和“出错影响资金或用户信任”两个条件；表单校验进入纳入项，则是因为它拦截的是重复退款这类直接造成资金风险的操作。
排除项必须写明理由和后续归属，否则排除就等于遗忘。范例中支付渠道到账时效被排除，理由是我方无法控制渠道处理时间，后续归属写的是支付团队与渠道方；性能测试被排除，理由是退款为低频操作，后续归属写的是季度性能计划。这样写在评审时可以被质疑和确认，在执行时也不会有人误以为已经覆盖。
测试层级与类型跟着风险走。金额计算放在单元测试和接口测试，是因为这类逻辑适合用大量边界数据快速验证；状态流转放在接口测试和端到端测试，是因为它跨越多个模块，需要看完整链路；通知内容一致性放在端到端测试，是因为它依赖真实触达结果。层级分配的作用是让每类风险都有合适的验证手段，避免所有内容都堆在界面测试上。
环境与数据条件属于范围的一部分，因为它们决定了纳入项能否被验证。范例中列出沙箱接口、测试号码、四类订单样本，是为了让执行者提前知道缺什么、找谁要。如果这些条件不写进范围，测试开始后才发现数据造不出来，纳入项就会被动缩水，而范围文档上仍然写着“已覆盖”。
完成标准要写成可判断的条件，避免“测试通过”“基本稳定”这类无法核对的表述。范例中的每条标准都指向可观察的结果：用例执行完毕、缺陷状态、验证记录、变更记录关闭情况。可判断的标准让测试结束有明确依据，也让评审方能在开始前就对这些条件达成一致。
范围确定后，纳入项、排除项和完成标准需要在工作项与评审流程中落地，否则文档与执行容易脱节。在 ONES 中，可以把纳入项拆成测试工作项并关联对应需求，把排除项与变更记录作为独立条目跟踪，评审意见和完成标准的确认过程留在同一处，便于执行时对照和结项时核对。
可迁移规律：换一个功能怎么写出同样的范围
把范例迁移到自己的功能，可以按以下四步从需求与风险清单生成纳入项：
- 列出本次迭代的需求变更点，逐条标注“新增、修改、删除”，删除项也要确认是否有回归需要。
- 对每个变更点判断出错后果，按资金、数据、用户可见性、内部效率等维度标注影响程度。
- 把“有变更且影响较重”的条目列为纳入项主体，把“有变更但影响较轻”的条目列为纳入项中的低优先级部分。
- 检查纳入项是否都有对应的验证手段和数据条件，缺条件的要么补条件，要么调整为排除项并写明理由。
排除项与边界项可以用固定句式填写，减少漏写：
- “不覆盖〔内容〕，原因是〔理由〕，由〔团队或计划〕在〔时间或轮次〕覆盖。”
- “〔内容〕仅在〔条件〕下验证，〔条件〕之外的情况不在本次范围。”
- “〔内容〕依赖〔外部系统或团队〕，本次只验证我方侧的〔具体行为〕。”
范围评审时可以逐条核对以下问题：
- 每个纳入项能否对应到具体的需求变更点或风险判断？
- 每个排除项是否写了理由和后续归属？
- 最高优先级风险是否有明确的验证手段和完成标准？
- 环境与数据条件是否足以支撑全部纳入项？
- 完成标准是否每条都能被第三方判断为“达成”或“未达成”？
范围变更时需要记录变更内容、原因、影响到的纳入项或排除项、对完成标准的影响，并同步给评审参与方。变更记录本身也应纳入完成标准的核对范围，避免范围在执行中悄悄扩大或缩小而无人知晓。
适用边界：示例能照搬到什么程度
这份范例基于假设情景，其中的条目划分、优先级和完成标准只用于说明写法，不代表任何真实项目的测试结果或行业标准。照搬条目文字意义不大，可以迁移的是字段结构、推导方式和判断逻辑。
不同测试层级和行业合规要求下，需要调整的字段并不相同。涉及资金、医疗、隐私等受监管领域的项目，排除项往往不能由测试团队单方面决定，完成标准中也可能需要加入合规审查或审计留痕的要求；以接口为主的服务端项目，界面测试的比重会下降，接口与集成测试的条目需要更细。填写时应先确认所在领域的强制要求，再决定哪些字段需要加严。
范围文档与测试计划、需求评审各有职责边界。范围文档回答覆盖边界与完成条件，测试计划安排资源、进度和具体活动，需求评审关注需求本身是否清晰完整。三者可以互相引用，但不宜用一份文档承担全部职责，否则范围部分会被进度安排和需求讨论淹没，失去对照执行的作用。
出现以下情况时，需要重新界定范围而不是沿用旧模板：功能的核心行为发生变更，原有纳入项已不能代表本次风险；依赖的外部系统或团队发生调整，原有环境与数据条件失效；上一轮遗留缺陷改变了风险判断，原本低优先级的条目需要提升；合规或业务规则变化导致排除项不再成立。重新界定时保留旧版本作为对照，能让评审方看清变化了什么、为什么变化。
常见问题
测试范围文档和测试计划有什么区别，能不能合成一份？
两者回答的问题不同。测试范围界定覆盖边界与完成条件，说明测什么、不测什么、达到什么状态算结束；测试计划安排资源、进度和具体活动，说明谁在什么时间做什么。合成一份时，进度讨论容易挤占范围讨论，评审后范围部分往往只剩一句概括。
可行做法是范围文档先行评审并冻结，测试计划引用范围条目来排期和分配人力。范围发生变更时更新范围文档并记录，测试计划随之调整，两份文档保持引用关系即可。
需求还在变动，测试范围是不是要等需求完全确定再写？
不必等到需求完全冻结。可以在需求评审后先写出初版范围，把已确定的变更点列为纳入项，把尚未确定的部分标注为待定并写明确认时间与责任人。这样评审方能看到当前覆盖判断，也能看到哪些结论还依赖后续输入。
需求变动后按变更记录更新范围：写明变更内容、原因、影响到的纳入项或排除项，以及对完成标准的影响，并同步给评审参与方。范围文档保留版本对照，比反复口头同步更容易追溯。
排除项写多了，会不会被认为测试覆盖不足？
排除项写得清楚，评审时反而更容易达成一致。关键在于每条排除都带理由和后续归属，例如“由支付团队与渠道方保障”“列入季度性能计划”，让评审方知道这部分没有被遗忘，只是由其他团队或轮次覆盖。
需要留意的是，排除项不能由测试团队单方面决定，尤其是涉及资金、合规的内容，应与对应责任方确认后再写入。没有理由、没有归属的排除项才是真正的风险点。
完成标准里的缺陷数量怎么定才合理？
缺陷数量本身不是好的完成标准，容易在执行中被讨价还价。更可判断的写法是按优先级约定状态：最高与高优先级项无未关闭的严重缺陷，中优先级项的遗留缺陷已记录并有处理计划和责任人。
具体阈值需要结合项目风险承受度和发布节奏确定，由测试、开发和业务方在范围评审时共同确认。阈值一旦写入范围，执行中就按同一口径核对，避免临近发布时临时放宽。
范围确定后，怎么保证执行时不走样？
把范围条目落到可跟踪的工作项上是常见做法。纳入项拆成测试工作项并关联对应需求，排除项与变更记录作为独立条目跟踪，评审意见和完成标准的确认过程留在同一处，执行时对照、结项时核对。
在 ONES 中，测试工作项可以与需求、缺陷关联，范围条目和变更记录在同一工作空间内跟踪，减少文档与执行脱节的情况。具体配置方式按团队现有流程调整即可。
