400-188-1518测试范围说明书模板：纳入项与排除项怎么写
测试范围说明书模板的核心是一张范围清单表，固定四类栏目：纳入项、排除项、假设、待确认项。纳入项写清被测对象、测试类型、环境与数据范围、接口与集成边界；排除项写清不测的模块、不覆盖的测试类型、暂不验证的环境与数据；假设记录范围成立所依赖的前提；待确认项列出尚未定论、需要在评审中关闭的问题，并标注负责人与关闭时间。下面给出一份可直接复制填写的空白表，并配套字段说明、必填规则、完整示例与变更维护方法。
Table of Contents
要点总览（TL;DR）
- 测试范围说明书模板以一张范围清单表为核心，固定纳入项、排除项、假设、待确认项四类栏目，另加文档头锁定版本与评审信息。
- 纳入项写清被测对象、测试类型、环境与数据、边界说明；排除项写清排除对象、可核查的排除原因、替代验证方式与确认人。
- 假设是已默认成立的前提，待确认项是尚未定论的问题，两者分表登记，避免未决问题被当成既定前提。
- 纳入对象、测试类型、排除对象及原因、待确认项负责人与截止时间属于必填；环境细节、替代验证方式、关联需求编号可按项目规模裁剪。
- 范围变更时定位受影响条目、由原确认人确认、同步假设与待确认项并留下变更记录，评审建议设在提测前一周。
可复制空白模板：测试范围说明书范围清单表
先填文档头，再按四类子表逐条登记。文档头用于锁定这份范围说明对应哪个版本、由谁编写和评审、依据哪些需求；四类子表用统一编号，便于在评审和变更时引用具体条目。
文档头
| 字段 | 填写内容 |
|---|---|
| 项目/版本 | |
| 编写人 | |
| 评审人 | |
| 生效日期 | |
| 关联需求或迭代 |
纳入项
| 编号 | 纳入对象 | 测试类型 | 环境/数据 | 边界说明 | 负责人 |
|---|---|---|---|---|---|
| IN-01 | |||||
| IN-02 | |||||
| IN-03 |
排除项
| 编号 | 排除对象 | 排除原因 | 替代验证方式 | 确认人 |
|---|---|---|---|---|
| EX-01 | ||||
| EX-02 | ||||
| EX-03 |
假设
| 编号 | 假设内容 | 影响范围 | 若不成立的处理 |
|---|---|---|---|
| AS-01 | |||
| AS-02 |
待确认项
| 编号 | 问题描述 | 待确认方 | 截止时间 | 结论 |
|---|---|---|---|---|
| OP-01 | ||||
| OP-02 |
字段说明：每一列填什么、怎么判断填对了
模板能否发挥作用，取决于每列是否写到可核查的程度。以下口径可直接作为模板附注，与空白表和示例保持一致。
| 栏目 | 填写口径 | 判断填对的标准 |
|---|---|---|
| 纳入对象 / 排除对象 | 按模块、功能、接口、端到端流程等粒度描述，写清对象名称与所在系统 | 读者能据此判断某条用例是否落在范围内，不产生“大概包含”的歧义 |
| 测试类型 | 区分功能、性能、兼容、安全、回归等，与范围边界对应 | 同一对象若只做部分类型，能看出哪些类型在范围内、哪些在排除项中 |
| 环境/数据 | 说明设备型号或类型、系统版本、数据集来源与构造方式 | 执行人拿到该行即可准备环境，无需再口头询问 |
| 排除原因 | 写可核查的理由，如需求未变更、由上游系统保证、本期无改动 | 理由指向具体事实，而非“时间不够”这类无法复核的表述 |
| 替代验证方式 | 说明排除内容通过何种手段获得保障，如上游联调、线上监控、下期补测 | 排除项有明确的风险承接方或承接动作 |
| 假设 | 记录范围成立所默认的前提，如依赖服务接口保持稳定、测试数据可脱敏获取 | 前提一旦变化，能对应到受影响的纳入项 |
| 待确认项 | 记录尚未定论的问题，写明待确认方与截止时间 | 每条都有唯一责任人和可关闭的时间点 |
假设与待确认项的差别需要特别说明：假设是团队已经默认成立、并据此划定范围的前提，通常不需要再讨论，只需在前提变化时触发范围复核；待确认项是尚未有结论的问题，必须有人在截止时间前给出结论，结论可能改变纳入项或排除项。把两者混在一张表里，容易让“还没问清楚”的问题被当成既定前提，导致范围在评审后反复变动。
必填与选填：哪些栏目不能空
模板栏目齐全不等于每格都要填满。必填项决定范围是否可执行、可追责；选填项用于补充上下文，缺失时不影响范围成立。
| 栏目 | 必填/选填 | 说明 |
|---|---|---|
| 纳入对象 | 必填 | 范围的主体，缺失则整份说明失去意义 |
| 测试类型 | 必填 | 同一对象不同测试类型的覆盖差异必须显性化 |
| 排除对象及排除原因 | 必填 | 排除项是范围争议的高发区，原因缺失会让排除无法被确认 |
| 待确认项负责人与截止时间 | 必填 | 没有责任人和时间的待确认项无法关闭 |
| 环境细节 | 选填 | 可在测试计划中细化，范围说明只需写到环境类别 |
| 替代验证方式 | 选填 | 排除项已有明确承接方时可省略，风险较高的排除项建议填写 |
| 关联需求编号 | 选填 | 便于追溯，需求条目清晰时可补 |
必填项为空时，处理方式有两种：退回编写人补充，或在评审中当场记录为待确认项，指定负责人和关闭时间。两种方式都要求留下记录，避免空缺被默认为“不重要”。
项目规模不同，裁剪方式也不同。小型迭代可将四类子表合并为一张清单，用“类型”列区分纳入、排除、假设、待确认；中大型版本建议保留四张子表，并按模块或端到端流程分组；跨团队协作的版本还应增加确认人一列，让排除项有明确的对口确认方。
填写示例：一个版本迭代的完整范围说明
以下为演示情景，用于说明四类栏目的写法，字段与上一节说明逐项对应。
文档头：项目/版本为“订单中心 V3.2 迭代”；编写人为测试负责人；评审人为产品经理与开发负责人；生效日期为迭代提测前一周；关联需求为订单拆单与优惠券叠加两条需求。
纳入项示例
| 编号 | 纳入对象 | 测试类型 | 环境/数据 | 边界说明 | 负责人 |
|---|---|---|---|---|---|
| IN-01 | 订单拆单功能 | 功能、回归 | 测试环境，Android 与 iOS 各两台设备 | 覆盖单仓拆单与多仓拆单，不含跨境订单 | 测试A |
| IN-02 | 优惠券叠加计算 | 功能 | 测试环境，构造满减券与折扣券组合数据 | 覆盖两张券叠加，三张及以上不纳入 | 测试B |
| IN-03 | 下单主流程 | 端到端回归 | 测试环境，使用预置商品与用户账号 | 从加购到支付成功的完整链路 | 测试A |
排除项示例
| 编号 | 排除对象 | 排除原因 | 替代验证方式 | 确认人 |
|---|---|---|---|---|
| EX-01 | 支付网关对接 | 本期未改动支付逻辑，接口由支付团队维护 | 沿用上游联调结果，上线后观察支付成功率监控 | 开发负责人 |
| EX-02 | 历史订单查询性能 | 本期无相关改动，上期已完成压测 | 引用上期压测报告 | 产品经理 |
| EX-03 | iOS 低版本兼容 | 目标用户中该版本占比低于约定阈值 | 上线后通过崩溃率监控观察 | 产品经理 |
假设与待确认项示例
| 编号 | 假设内容 | 影响范围 | 若不成立的处理 |
|---|---|---|---|
| AS-01 | 库存服务接口在本迭代保持稳定 | IN-01、IN-03 | 接口变更时补充联调并重跑下单主流程 |
| AS-02 | 测试环境优惠券数据可按需构造 | IN-02 | 数据无法构造时改用预置券种并缩小组合范围 |
| 编号 | 问题描述 | 待确认方 | 截止时间 | 结论 |
|---|---|---|---|---|
| OP-01 | 三张券叠加是否属于本期需求 | 产品经理 | 提测前三个工作日 | 待关闭 |
| OP-02 | 拆单后运费计算规则是否同步调整 | 开发负责人 | 提测前两个工作日 | 待关闭 |
对照字段说明可以看出：IN-01 的边界说明明确了“不含跨境订单”，与 EX-01 的排除原因一样指向具体事实；AS-01 是已默认成立的前提，OP-01 是尚未定论的问题，两者分表登记，避免把未决问题当成前提。
调整与维护：范围变更时怎么改模板和内容
范围说明书在评审通过后进入受控状态，任何范围变化都应落到具体条目上，而不是口头调整。变更时按以下顺序处理：
- 定位受影响条目。新增内容登记为新的纳入项；取消的内容从纳入项移入排除项，并补写排除原因与替代验证方式。
- 由原确认人确认。排除项和范围收缩需由对应模块的确认人签字或留言确认，纳入项新增由测试负责人与产品经理共同确认。
- 同步假设与待确认项。前提变化时更新假设的影响范围；待确认项关闭后写入结论，并据此调整纳入项或排除项。
- 记录变更。在文档头下方保留变更记录，写明变更条目编号、变更原因、确认人和日期。
模板本身也需要版本管理。建议在模板文件名或文档属性中标注版本号，字段增删时保留旧版本，供历史版本迭代追溯。模板调整通常发生在复盘之后：若某类排除原因反复出现，可将其固化为下拉选项；若待确认项经常逾期，可增加“逾期处理”一列。
评审节点建议设在提测前一周，由测试负责人发起，产品经理、开发负责人和相关模块确认人参加，评审结论以签署或书面确认为准。范围说明书通过后，测试计划中的测试项、用例范围和环境准备均以其为输入；用例评审时逐条核对是否落在纳入项内，发现范围外用例时回到范围说明书补充条目或调整用例。
当范围清单需要多人协作维护时，可以把它作为文档或工作项放在协作工具中承载。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；测试计划可多维度概览并查看进度。将范围说明书与对应迭代、需求关联后，范围条目变更和评审记录可与测试计划、用例保持同一处追溯，减少范围说明与实际执行脱节的情况。具体承载方式以团队实际开通的模块和配置为准。
常见问题
小型迭代也要用四张子表吗，能不能合并成一张？
可以合并。小型迭代可将纳入、排除、假设、待确认合并为一张清单，增加一列“类型”区分条目归属，编号仍按 IN、EX、AS、OP 前缀区分，便于引用。合并后需要保留两个关键约束：排除项必须写排除原因，待确认项必须写负责人与截止时间。中大型版本或跨团队协作的版本建议保留四张子表，并按模块或端到端流程分组，减少评审时的来回核对。
排除项写“时间不够、本期不测”可以吗？
这类表述难以复核，评审时容易被反复追问。排除原因应指向具体事实，例如本期该模块无代码改动、由上游系统保证、上期已完成压测并有报告可引用。同时补上替代验证方式，说明风险由谁承接，例如上游联调结果、上线后监控指标或下期补测计划。排除项还需要确认人，让排除结论有明确的对口责任人。
待确认项在评审时还没关闭，范围说明书能签吗？
可以签，但要把未关闭的待确认项作为签署的附带条件记录下来，写明负责人、截止时间和逾期处理方式。签署后待确认项一旦得出结论，按结论调整纳入项或排除项，并留下变更记录。若某个待确认项可能显著改变范围，例如是否新增一类业务场景，建议先关闭该项再签署，避免范围在提测后大幅返工。
范围说明书和测试计划、用例范围是什么关系？
范围说明书界定测什么、不测什么，是上游输入；测试计划据此安排测试项、资源、环境与进度；用例范围再按纳入项逐条展开。用例评审时逐条核对是否落在纳入项内，发现范围外用例时回到范围说明书补充条目或调整用例，避免用例与范围两张皮。范围变更后，测试计划与用例范围同步更新。
范围清单需要多人协作维护时，怎么保证变更可追溯？
把范围清单作为文档或工作项承载，并与对应迭代、需求关联，变更条目、确认人和日期都留在同一处。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；测试计划可多维度概览并查看进度。这样范围条目变更与测试计划、用例保持同一处追溯，减少范围说明与实际执行脱节。具体承载方式以团队实际开通的模块和配置为准。
