测试范围说明书模板以一张范围界定表为核心，按“纳入项—排除项—假设—待确认项”四类字段逐条列出，每条写清对象、边界条件、责任人和确认状态。纳入项回答这次测什么，排除项回答这次明确不测什么，假设记录范围成立所依赖的前提，待确认项记录尚未定论、需要在评审前闭环的问题。下面给出可直接复制的空白表、字段口径、必填规则和一份完整填写示例。
要点总览（TL;DR）
- 模板以“纳入项—排除项—假设—待确认项”四张表为核心，表头记录项目、版本、编制人、评审日期和文档状态。
- 纳入项写到功能模块、接口、终端或数据范围层级，并用边界条件限定版本、环境、配置和数据量；范围对象、测试类型、责任人为必填。
- 排除项必须写明排除对象和具体排除理由，涉及资金、权限、数据一致性的高风险排除项还要填写替代验证方式。
- 假设记录已默认成立的前提并写明失效后的处理，待确认项记录尚未定论的问题，须有具体确认对象和早于评审的截止时间。
- 模板按项目类型裁剪列但保留四类字段结构，版本变更时更新条目并标注“已变更”，每版结束后复盘排除项是否被真正覆盖。
可复制的测试范围说明书空白模板
先填写表头信息，再分别填写四张表。四张表共用一套编号规则，建议按“IN-01、EX-01、AS-01、TBD-01”前缀区分，便于在评审和后续版本中引用。
表头信息区
| 字段 | 填写内容 |
|---|---|
| 项目名称 | |
| 版本号 | |
| 编制人 | |
| 评审日期 | |
| 参与评审角色 | |
| 文档状态 | 草稿 / 评审中 / 已确认 / 已变更 |
纳入项表
| 编号 | 范围对象 | 边界条件 | 测试类型 | 责任人 | 确认状态 |
|---|---|---|---|---|---|
| IN-01 | 待确认 / 已确认 | ||||
| IN-02 | |||||
| IN-03 |
排除项表
| 编号 | 排除对象 | 排除理由 | 替代验证方式 | 责任人 |
|---|---|---|---|---|
| EX-01 | ||||
| EX-02 | ||||
| EX-03 |
假设表
| 编号 | 假设内容 | 影响范围 | 失效后的处理 |
|---|---|---|---|
| AS-01 | |||
| AS-02 |
待确认项表
| 编号 | 问题 | 待确认对象 | 截止时间 | 状态 |
|---|---|---|---|---|
| TBD-01 | 开放 / 已闭环 | |||
| TBD-02 |
纳入项与排除项的字段说明
字段填得是否合格，判断标准是同一个人隔一周再看，仍能准确知道测什么、不测什么、由谁负责。下面逐字段给出填写口径和常见反例。
| 字段 | 填写口径 | 反例 |
|---|---|---|
| 范围对象（纳入项） | 写到功能模块、接口、终端或数据范围层级，例如“订单退款接口”“iOS 客户端登录模块”“历史订单数据迁移” | “订单系统”“客户端”这类笼统名称，无法判断具体测哪一块 |
| 边界条件 | 写明版本、环境、配置、数据量等限定，例如“仅 v3.2 灰度环境，单笔退款金额≤5万元” | “正常环境”“常规数据”，没有可核对的限定值 |
| 测试类型 | 功能、接口、兼容性、性能、安全、数据迁移等，按实际执行方式填写 | 只写“测试”，无法安排执行人和环境 |
| 责任人 | 填具体执行或牵头人，不填部门名 | “测试组”“相关同事” |
| 确认状态 | 待确认、已确认、已变更三态，评审后统一更新 | 空白或长期停留在待确认 |
| 排除对象 | 与纳入项同一粒度，明确到模块、接口或终端 | “其他功能”“剩余部分” |
| 排除理由 | 写具体原因，例如“本期需求未改动该模块”“依赖的第三方沙箱未就绪”“风险由供应商合同约束覆盖” | “暂不测试”“时间不够” |
| 替代验证方式 | 说明排除后由谁在哪个环节覆盖，例如“由供应商验收报告覆盖”“下个版本回归时补测”“线上监控告警兜底” | 留空或写“无需验证” |
| 假设内容 | 已默认成立、当前不再讨论的前提，例如“测试环境数据库与生产同版本” | 把尚未定论的问题写进假设 |
| 影响范围 | 假设失效时波及哪些纳入项，填编号 | 写“影响整体” |
| 失效后的处理 | 写明补救动作和触发人，例如“环境版本不一致时，由环境负责人 2 个工作日内升级并通知重跑 IN-03” | “另行处理” |
| 待确认对象 | 填具体人或角色，例如“产品经理”“接口提供方” | “相关方” |
| 截止时间 | 填到日期，且早于范围评审日期 | “尽快”“评审前” |
假设与待确认项的区分是模板能否发挥作用的关键。假设是团队已经默认成立、当前不再讨论的前提，写进假设表是为了在它失效时有人负责补救；待确认项是尚未定论、必须有人给出结论的问题，写进待确认表是为了在评审前闭环。把未定论的问题塞进假设，风险就会被“默认成立”掩盖。
必填与选填：哪些字段不能空
模板被填成空壳，通常是因为必填边界不清。下表给出最低填写要求，空缺时按对应规则处理，而不是留白通过评审。
| 表 | 必填字段 | 选填字段 | 空缺时的处理 |
|---|---|---|---|
| 纳入项 | 范围对象、测试类型、责任人 | 备注、关联需求编号、参考文档链接 | 缺范围对象或测试类型的条目不进入评审；缺责任人的由测试负责人当场指定 |
| 排除项 | 排除对象、排除理由 | 替代验证方式（按风险定必填）、备注 | 排除理由为空视为无效排除，需补理由或改为纳入项；高风险排除项必须填写替代验证方式 |
| 假设 | 假设内容、影响范围 | 验证方式、备注 | 缺影响范围的假设无法评估失效后果，评审前补齐 |
| 待确认项 | 待确认对象、截止时间 | 关联条目编号、备注 | 缺截止时间的待确认项由主持人指定日期，逾期未闭环则在评审记录中标注风险 |
替代验证方式是否必填，按排除项的风险等级判断：涉及资金、权限、数据一致性的排除项必须填写；纯展示类、影响面小的排除项可以选填，但仍建议注明由哪个环节覆盖。选填字段的作用是建立追溯关系，关联需求编号和参考文档链接能让范围条目在需求变更时被快速定位。
填写示例：一个版本的范围说明书
以下示例为演示情景，用于说明四类字段如何配合，不代表任何真实项目。背景设定：某电商系统 v3.2 版本，涉及订单、退款、会员三个模块，测试类型包括功能、接口与数据迁移。
表头
| 字段 | 内容 |
|---|---|
| 项目名称 | 电商系统订单域改造 |
| 版本号 | v3.2 |
| 编制人 | 测试负责人 A |
| 评审日期 | 2025-06-10 |
| 参与评审角色 | 产品经理、开发负责人、测试负责人、运维代表 |
| 文档状态 | 评审中 |
纳入项
| 编号 | 范围对象 | 边界条件 | 测试类型 | 责任人 | 确认状态 |
|---|---|---|---|---|---|
| IN-01 | 订单退款接口 | v3.2 测试环境，单笔退款金额≤5万元，含部分退款场景 | 接口测试 | 测试工程师 B | 已确认 |
| IN-02 | 会员等级权益计算模块 | 仅覆盖新增的成长值折算规则，历史等级数据不重算 | 功能测试 | 测试工程师 C | 已确认 |
| IN-03 | 历史订单数据迁移 | 迁移 2023-01 至 2024-12 的订单，抽样 5000 条核对字段一致性 | 数据迁移测试 | 测试工程师 B | 待确认 |
排除项
| 编号 | 排除对象 | 排除理由 | 替代验证方式 | 责任人 |
|---|---|---|---|---|
| EX-01 | 支付渠道对接 | 本期未改动支付渠道代码，渠道方也未发布新版本 | 由支付渠道方季度验收报告覆盖，运维在发布前核对渠道健康状态 | 开发负责人 D |
| EX-02 | Android 客户端兼容性 | 本期仅发布 iOS 端改动，Android 包未重新构建 | 下个版本回归时补测，线上崩溃监控兜底 | 测试工程师 C |
假设与待确认项
| 编号 | 假设内容 | 影响范围 | 失效后的处理 |
|---|---|---|---|
| AS-01 | 测试环境数据库与生产同版本 | IN-01、IN-03 | 版本不一致时由环境负责人 2 个工作日内升级，并通知重跑相关用例 |
| 编号 | 问题 | 待确认对象 | 截止时间 | 状态 |
|---|---|---|---|---|
| TBD-01 | 历史订单迁移是否包含已关闭订单 | 产品经理 E | 2025-06-08 | 已闭环：确认包含 |
| TBD-02 | 退款接口并发上限的验收标准 | 开发负责人 D | 2025-06-09 | 开放 |
示例中 IN-03 的确认状态为待确认，对应 TBD-01 的结论；AS-01 失效时直接指向 IN-01 和 IN-03，责任人和处理时限都写清楚。评审时只需检查待确认项是否全部闭环、假设是否仍成立，范围边界即可定稿。
模板的调整与维护方法
模板需要随项目类型和版本演进，但四类字段的结构应保持稳定，否则跨版本对比范围变化会失去基准。以下要点可作为裁剪与维护的操作清单。
- 按项目类型裁剪列，不裁剪结构。接口类项目可增加“接口版本”“鉴权方式”列；数据迁移类项目可在纳入项增加“数据量级”“校验规则”列；移动端项目可增加“终端型号”列。纳入项、排除项、假设、待确认项四张表始终保留。
- 版本变更时重新确认范围。需求新增或删减后，更新对应条目的边界条件与确认状态，新增条目沿用编号规则续编，已失效条目保留并标注“已变更”，不直接删除，便于追溯。
- 与测试计划和需求评审衔接。范围说明书在需求评审后编制，作为测试计划的输入；测试计划中的测试策略、资源安排应与纳入项和排除项一一对应。评审记录中注明范围说明书的版本号和确认日期。
- 定期复盘排除项。每个版本结束后回看排除项是否被替代验证方式真正覆盖，是否出现“排除了但线上出问题”的情况，把遗漏的覆盖环节补进下一版模板或流程。
- 记录模板变更。模板本身的列增删、字段口径调整，在模板文件头部保留变更记录，写明变更日期、变更内容和批准人，避免不同项目使用不同口径的模板却互不知情。
当范围条目需要在多人之间流转确认时，可以把纳入项和排除项作为工作项登记，责任人、确认状态和截止时间随条目一起跟踪，评审结论回写到文档中。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，也支持为不同用户组配置权限、为用例库和测试计划单独配置权限，适合把范围条目与后续用例、计划放在同一流程中管理；具体承载方式需按实际版本确认。
常见问题
排除项写了理由，评审时还是被要求补替代验证方式，判断标准是什么？
按排除项的风险等级判断。涉及资金、权限、数据一致性的排除项，替代验证方式为必填，因为这类问题一旦在线上暴露，损失难以回退；纯展示类、影响面小的排除项可以选填，但仍建议注明由哪个环节覆盖。替代验证方式要写到“谁、在哪个环节、用什么方式覆盖”，例如由供应商验收报告覆盖、下个版本回归补测或线上监控告警兜底，写“无需验证”等于没有交代。
需求在版本中期发生变更，范围说明书应该怎么改？
更新对应条目的边界条件和确认状态，新增条目沿用原编号规则续编。已失效的条目保留并标注“已变更”，不直接删除，这样跨版本对比时能看出范围是怎么变化的。范围变更后需要重新确认，并在评审记录中注明范围说明书的版本号和确认日期，避免测试计划仍按旧范围安排资源。
假设和待确认项看起来很像，实际填写时怎么区分？
看当前是否已经形成共识。假设是团队已经默认成立、当前不再讨论的前提，例如“测试环境数据库与生产同版本”，写进假设表是为了在它失效时有人负责补救，所以要填影响范围和失效后的处理。待确认项是尚未定论、必须有人给出结论的问题，例如“迁移是否包含已关闭订单”，要填具体确认对象和截止时间。把未定论的问题写进假设，风险会被“默认成立”掩盖。
小版本或维护类项目，四张表都要填吗？
四类字段的结构建议保留，内容可以精简。小版本纳入项可能只有两三条，排除项也可能只有一条，但排除理由和责任人仍要写清。假设表在环境稳定、依赖未变时可以只保留关键前提；待确认项表即使只有一条，也要写明确认对象和截止时间。结构保留的价值在于跨版本对比时口径一致，裁剪掉整张表会让后续版本失去参照。
范围说明书里的条目怎么和后续用例、测试计划对应起来？
靠编号建立追溯关系。纳入项编号可以写进用例的关联字段或测试计划的章节标题，排除项编号在复盘时用于核对替代验证是否落实。当条目需要在多人之间流转确认时，可以把纳入项和排除项作为工作项登记，责任人、确认状态和截止时间随条目一起跟踪，评审结论回写到文档。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，也支持为不同用户组、用例库和测试计划分别配置权限，适合把范围条目与后续用例、计划放在同一流程中管理；具体承载方式需按实际版本确认。
