测试计划模板用一张主表加四张附表就能落地：主表记录计划基本信息、范围、策略、进度、资源与风险，四张附表分别承载测试范围清单、测试类型与策略、进度与里程碑、风险与应对。本文直接给出可复制的空白表，再逐字段说明填写口径、划分必填与选填、演示一份完整填好的计划，并说明模板如何随项目演进调整。适合测试负责人、项目经理和需要评审测试计划的研发同学直接取用。
要点总览（TL;DR）
- 模板由一张主表加四张附表组成：主表写基本信息、范围、策略、进度、资源与风险摘要，附表分别承载范围清单、测试类型与策略、进度与里程碑、风险与应对。
- 必填项以“缺了就无法评审、执行或追踪”为判断标准，主表保留计划名称、版本、关联需求、目标、范围、准入准出、起止日期、负责人与评审记录。
- 小项目可合并附表三为里程碑列表、附表四只留三列；常规项目五表完整使用；大型项目增加风险分级与触发信号，并按系统拆分范围。
- 填写时先完成附表再回填主表摘要，保证主表与附表口径一致；示例中范围、策略、里程碑、风险四组字段逐项对应。
- 模板本身要有版本号、变更记录和季度复盘节奏，字段增删需说明服务于评审、执行还是追踪，计划变更后同步更新对应附表。
可复制空白测试计划模板
模板由五张表组成。主表是计划的“封面与摘要”，评审人先看主表就能判断这份计划是否完整；四张附表承担细节，供执行阶段逐项对照。复制时建议保留表头，按项目实际增删行，不要改动字段名称，否则后续与字段说明、填写示例对不上。
主表：测试计划基本信息
| 字段 | 填写内容 |
|---|---|
| 计划名称 | |
| 计划编号 / 版本 | |
| 关联需求 / 迭代 | |
| 测试目标 | |
| 测试范围概述 | |
| 不测试范围 | |
| 测试策略概述 | |
| 准入条件 | |
| 准出条件 | |
| 开始 / 结束日期 | |
| 关键里程碑 | |
| 测试负责人 | |
| 测试人员与分工 | |
| 测试环境 | |
| 测试数据 | |
| 主要风险 | |
| 依赖与假设 | |
| 评审记录 |
附表一：测试范围清单
| 序号 | 功能 / 模块 | 需求编号 | 范围说明 | 优先级 | 是否纳入本轮 | 备注 |
|---|---|---|---|---|---|---|
附表二：测试类型与策略
| 测试类型 | 覆盖对象 | 执行方式（手工 / 自动化） | 进入时机 | 完成标准 | 负责人 |
|---|---|---|---|---|---|
附表三：进度与里程碑
| 阶段 | 起止日期 | 交付物 | 负责人 | 前置依赖 | 状态 |
|---|---|---|---|---|---|
附表四：风险与应对
| 风险描述 | 影响范围 | 可能性 | 影响程度 | 应对措施 | 责任人 | 触发信号 |
|---|---|---|---|---|---|---|
字段说明：每个字段填什么、怎么填
字段说明的作用是让不同人填同一张表时口径一致。下面按主表、附表分别解释，并单独说明几组容易混淆的字段。
主表字段的填写口径
| 字段 | 填什么 | 填写口径 |
|---|---|---|
| 计划名称 | 版本或迭代名 + 测试计划 | 包含可识别的版本信息，便于检索 |
| 计划编号 / 版本 | 编号与版本号 | 计划修订后递增版本号，旧版本保留 |
| 关联需求 / 迭代 | 需求单号、迭代名称 | 写可追溯的标识，不写“本期需求”这类模糊描述 |
| 测试目标 | 本轮要验证的质量目标 | 用可判断的表述，如“核心下单链路通过回归” |
| 测试范围概述 | 纳入测试的功能与模块 | 与附表一保持一致，主表只写摘要 |
| 不测试范围 | 明确排除的内容及原因 | 写清排除项，避免评审时对覆盖产生分歧 |
| 测试策略概述 | 测试类型组合与侧重 | 与附表二对应，主表写结论 |
| 准入条件 | 开始测试需满足的条件 | 如构建可部署、冒烟通过、环境就绪 |
| 准出条件 | 判定测试完成的条件 | 如用例执行率、遗留缺陷等级与数量 |
| 开始 / 结束日期 | 计划起止时间 | 与附表三的里程碑首尾一致 |
| 关键里程碑 | 3–5 个关键节点 | 只写影响决策的节点，细节放附表三 |
| 测试负责人 | 一名责任人 | 对计划整体负责，不写团队名 |
| 测试人员与分工 | 人员及负责模块 | 与附表二的负责人字段对应 |
| 测试环境 | 环境名称与地址说明 | 写清环境用途和差异，如预发环境 |
| 测试数据 | 数据来源与准备方式 | 说明是否需要脱敏或造数 |
| 主要风险 | 影响计划达成的风险 | 与附表四对应，主表列前两三项 |
| 依赖与假设 | 外部依赖与前提假设 | 假设不成立时需触发计划修订 |
| 评审记录 | 评审时间、参与人、结论 | 记录通过或需修改，作为计划生效依据 |
附表字段的填写口径
附表一的“范围说明”写该模块本轮测到什么程度，例如“主流程 + 异常分支”；“是否纳入本轮”用是/否标记，排除项在主表“不测试范围”中同步说明。附表二的“进入时机”写触发条件而非日期，如“冒烟通过后”；“完成标准”写可核验的结果，如“用例全部执行且无高等级遗留缺陷”。附表三的“前置依赖”写清上游交付物，状态用未开始、进行中、完成三档即可。附表四的“触发信号”写可观察的预警，如“提测延期超过两天”，便于风险发生时及时响应。
容易混淆的字段如何区分
- 测试范围与测试类型：范围回答“测哪些功能”，类型回答“用什么方式测”。同一模块可以出现在范围清单里，同时在策略表中对应功能测试、接口测试等多种类型。
- 准入与准出：准入是开始测试的门槛，准出是结束测试的门槛，两者方向相反，不能互相替代。准入不满足时测试不应启动，准出不满足时计划不能关闭。
- 测试目标与完成标准：目标描述质量意图，完成标准是可核验的判定条件。目标可以概括，完成标准必须能对照检查。
- 风险与依赖：依赖是已知前提，风险是可能影响计划的不确定事件。依赖失效往往转化为风险，需要在附表四中补充应对。
必填与选填：按项目规模裁剪模板
必填项的判断标准只有一条：缺少它，计划就无法被评审、执行或追踪。满足这条标准的字段保留，其余按项目规模裁剪。
必填字段清单
| 所在表 | 必填字段 | 保留理由 |
|---|---|---|
| 主表 | 计划名称、版本、关联需求 / 迭代、测试目标、测试范围概述、不测试范围、准入条件、准出条件、起止日期、测试负责人、评审记录 | 构成计划可评审、可追踪的最小信息集 |
| 附表一 | 功能 / 模块、是否纳入本轮、优先级 | 范围可核对，避免覆盖争议 |
| 附表二 | 测试类型、覆盖对象、完成标准 | 策略可执行、结果可判定 |
| 附表三 | 阶段、起止日期、交付物、负责人 | 进度可跟踪、责任可落实 |
| 附表四 | 风险描述、应对措施、责任人 | 风险有归属、有动作 |
选填字段与适用场景
| 字段 | 适用场景 |
|---|---|
| 测试环境、测试数据 | 环境复杂或数据需专门准备时填写 |
| 依赖与假设 | 存在跨团队依赖或外部前提时填写 |
| 测试人员与分工 | 多人协作、分工需要明确时填写 |
| 附表二执行方式、进入时机 | 自动化与手工混合、进入条件需要约定时填写 |
| 附表三前置依赖、状态 | 阶段间存在强依赖、需要周度跟踪时填写 |
| 附表四可能性、影响程度、触发信号 | 风险较多、需要分级管理时填写 |
不同项目规模的裁剪建议
- 小项目（单人或两三人、周期两周内）：保留主表必填项与附表一、附表二的核心列，附表三可合并为里程碑列表，附表四只保留风险描述、应对措施、责任人三列。
- 常规项目（跨角色协作、一个迭代以上）：五张表完整使用，选填字段按实际情况补充，附表三增加状态列用于周度同步。
- 大型项目（多团队、多系统联调）：在完整模板基础上增加风险分级与触发信号，附表一按系统拆分，附表三细化到阶段交付物验收，主表评审记录保留每轮修订结论。
裁剪的原则是删列不删类：范围、策略、进度、风险四类信息在任何规模下都应保留，只是承载的详细程度不同。
填写示例：一份完整填好的测试计划
以下示例为演示情景，用于说明字段之间的对应关系，不代表任何真实项目数据。
主表示例
| 字段 | 填写内容 |
|---|---|
| 计划名称 | 订单中心 V2.3 版本测试计划 |
| 计划编号 / 版本 | TP-ORDER-023 / V1.1 |
| 关联需求 / 迭代 | 需求 REQ-1042、REQ-1051；迭代 Sprint 18 |
| 测试目标 | 验证订单创建与支付回调链路在并发场景下的正确性 |
| 测试范围概述 | 订单创建、支付回调、订单查询三个模块，详见附表一 |
| 不测试范围 | 历史订单数据迁移，由数据团队单独验证 |
| 测试策略概述 | 功能测试为主，接口测试覆盖回调，性能测试验证并发，详见附表二 |
| 准入条件 | 构建部署成功、冒烟用例全部通过、测试环境可用 |
| 准出条件 | 用例执行率 100%，无未关闭的高等级缺陷，中等级缺陷有明确处理计划 |
| 开始 / 结束日期 | 3 月 4 日至 3 月 15 日 |
| 关键里程碑 | 3 月 6 日完成冒烟与主流程，3 月 12 日完成回归，3 月 15 日出具测试报告 |
| 测试负责人 | 测试负责人 A |
| 测试人员与分工 | A 负责订单创建与支付回调，B 负责订单查询与回归 |
| 测试环境 | 预发环境，与生产配置一致，支付使用沙箱 |
| 测试数据 | 使用造数脚本生成订单数据，用户信息脱敏 |
| 主要风险 | 支付沙箱不稳定、回调依赖第三方联调排期，详见附表四 |
| 依赖与假设 | 依赖支付团队 3 月 5 日前提供沙箱账号 |
| 评审记录 | 3 月 1 日评审，参与人：产品、研发、测试；结论：通过，补充性能测试范围后生效 |
附表一示例：测试范围清单
| 序号 | 功能 / 模块 | 需求编号 | 范围说明 | 优先级 | 是否纳入本轮 | 备注 |
|---|---|---|---|---|---|---|
| 1 | 订单创建 | REQ-1042 | 主流程 + 库存不足等异常分支 | 高 | 是 | |
| 2 | 支付回调 | REQ-1042 | 成功、失败、重复回调 | 高 | 是 | 依赖沙箱 |
| 3 | 订单查询 | REQ-1051 | 列表与详情，含分页 | 中 | 是 | |
| 4 | 历史订单迁移 | — | 数据迁移校验 | 中 | 否 | 数据团队负责 |
附表二示例：测试类型与策略
| 测试类型 | 覆盖对象 | 执行方式 | 进入时机 | 完成标准 | 负责人 |
|---|---|---|---|---|---|
| 功能测试 | 订单创建、订单查询 | 手工 | 冒烟通过后 | 用例全部执行，主流程无阻塞缺陷 | A |
| 接口测试 | 支付回调接口 | 自动化 | 接口联调完成后 | 成功、失败、重复回调场景全部通过 | A |
| 性能测试 | 订单创建并发 | 自动化 | 功能回归通过后 | 目标并发下响应时间与错误率达标 | B |
附表三示例：进度与里程碑
| 阶段 | 起止日期 | 交付物 | 负责人 | 前置依赖 | 状态 |
|---|---|---|---|---|---|
| 冒烟与主流程 | 3 月 4 日–3 月 6 日 | 冒烟结果、主流程用例记录 | A | 构建部署完成 | 完成 |
| 功能与接口测试 | 3 月 7 日–3 月 11 日 | 用例执行记录、缺陷清单 | A、B | 沙箱账号就绪 | 进行中 |
| 回归 | 3 月 12 日–3 月 14 日 | 回归结果 | B | 缺陷修复完成 | 未开始 |
| 测试报告 | 3 月 15 日 | 版本测试报告 | A | 回归通过 | 未开始 |
附表四示例：风险与应对
| 风险描述 | 影响范围 | 可能性 | 影响程度 | 应对措施 | 责任人 | 触发信号 |
|---|---|---|---|---|---|---|
| 支付沙箱不稳定 | 支付回调测试 | 中 | 高 | 提前申请备用沙箱，接口测试先行 | A | 连续两次回调失败 |
| 第三方联调排期延后 | 接口测试进度 | 中 | 中 | 先用手工桩验证，联调后补测 | 测试负责人 A | 3 月 5 日未拿到账号 |
示例与字段说明逐项对应：主表的“测试范围概述”对应附表一的纳入项，“测试策略概述”对应附表二的类型组合，“关键里程碑”对应附表三的阶段节点，“主要风险”对应附表四的前两行。读者填写时可先完成附表，再回填主表摘要，保证主表与附表口径一致。
调整与维护：模板如何随项目演进
模板的价值在于长期复用，前提是模板本身有版本、有变更理由、有评审节奏。下面四条规则可以直接作为维护清单使用。
模板版本与变更记录
模板文件头部保留版本号、修订日期、修订人和变更摘要。每次修改字段名称或增删列，递增版本号并记录原因，例如“V1.2：附表四增加触发信号列，用于风险预警”。旧版本保留归档，已按旧版填写的计划不强制迁移，新计划使用新版。
字段增删的判断标准
- 连续两个项目都手工补充同一信息，说明该信息应固化为字段。
- 某字段连续三个项目留空或填写内容雷同，考虑降为选填或删除。
- 字段名称引起过评审歧义，优先改名并同步更新字段说明与示例。
- 新增字段必须说明它服务于评审、执行还是追踪中的哪一环，三者都不服务的字段不加入。
计划变更后的同步更新动作
范围变化时先改附表一，再回填主表范围概述与不测试范围；进度调整时改附表三，同步主表起止日期与关键里程碑；风险状态变化时更新附表四的应对措施与责任人，主表主要风险随之调整。每次变更在计划版本号上递增，并在评审记录中写明变更原因，避免计划与执行脱节。
模板评审与复用节奏
建议每个季度或每完成三个项目后做一次模板复盘，检查字段使用率、评审中反复出现的疑问和裁剪情况，形成一次小版本更新。项目启动时从最新版本复制，不在项目内直接改模板原件。计划评审与进度跟踪如果放在协作工具中进行，可以把主表作为计划文档、附表作为结构化条目管理。ONES 的测试管理支持测试计划与迭代关联、多维度概览测试计划进度，也支持为用例分配执行人并按用户组配置权限；未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，测试报告可按模板自动生成。将模板中的范围、进度与风险条目落到这类工作项上，评审记录和状态更新就有了统一入口，具体配置以实际产品为准。
常见问题
小项目只有两三个人、周期两周内，测试计划模板可以精简到什么程度？
可以保留主表必填项和附表一、附表二的核心列。附表三合并为里程碑列表，只写阶段、日期、交付物和负责人；附表四保留风险描述、应对措施、责任人三列。范围、策略、进度、风险四类信息仍需保留，只是详细程度降低。裁剪时删列不删类，避免评审时对覆盖范围产生分歧。
测试计划评审通过后，需求范围又变了，模板里的哪些表要跟着改？
先改附表一的范围清单，标记新增或移出的模块，再回填主表的测试范围概述与不测试范围。如果范围变化影响排期，同步调整附表三的阶段与日期，并更新主表起止日期和关键里程碑。每次变更递增计划版本号，在评审记录中写明变更原因，让计划与执行保持一致。
准入条件和准出条件经常被填成同一类内容，怎么区分？
准入是开始测试的门槛，例如构建可部署、冒烟通过、环境就绪；准出是结束测试的门槛，例如用例执行率达标、无未关闭的高等级缺陷。两者方向相反，不能互相替代。填写时把准入写成“满足什么才能开始”，把准出写成“达到什么才能关闭计划”，并确保准出条件可以对照检查。
测试计划里的范围和进度能否放到协作工具里管理，而不是只留一份文档？
可以。把主表作为计划文档，附表一的范围条目、附表三的阶段任务、附表四的风险条目分别落到工作项上，评审记录和状态更新就有统一入口。ONES 的测试管理支持测试计划与迭代关联，并可多维度概览测试计划进度；未通过的用例可快速创建缺陷任务，在测试与研发团队间流转。具体配置以实际产品为准。
模板用了一段时间后，怎么判断某个字段该删还是该保留？
看使用情况：连续两个项目都手工补充同一信息，说明应固化为字段；某字段连续三个项目留空或填写内容雷同，可降为选填或删除；字段名称引起过评审歧义，优先改名并同步更新字段说明与示例。新增字段要说明它服务于评审、执行还是追踪，三者都不服务的字段不加入。
