测试计划编制从明确测试目标与范围开始，再识别风险、确定测试策略，随后安排测试层级与类型、资源与进度、准入准出与交付物，最后经评审基线化，并在需求或范围变化时更新。核心产物是一份可执行、可追踪、可评审的测试计划文档，配套风险清单、环境与数据准备清单和进度安排。本文按编制顺序展开每一步的输入、动作与输出，并给出填写示例和完成检查清单。
要点总览（TL;DR）
- 测试计划编制按“目标与范围—风险与策略—层级与类型—资源与环境—进度与准入准出—评审基线化”推进，每一步都留下可核对的产物。
- 测试目标从需求与验收标准提取，写成可验证的表述；范围同时记录纳入项与排除项，让评审者能提前提出异议。
- 风险按影响与概率分级，高等级风险对应更充分的测试层级与类型，并用风险—策略对应表记录责任人和验证方式。
- 资源安排覆盖人员角色与技能、环境、数据与外部依赖；进度以里程碑和准入准出条件为锚点，并预留缺陷修复与回归时间。
- 计划评审通过后由测试负责人定版基线化，需求、范围或风险变化时按约定责任更新并保留旧版本。
测试计划先写什么：核心答案与编制步骤
测试计划解决的是“这个版本要测什么、怎么测、谁来测、什么时候算测完”四个问题。它在项目或迭代启动、需求评审之后、测试执行之前编制；需求发生较大变更时重新修订。计划的价值在于把测试投入与风险对齐，让评审、执行和验收有共同依据，而不是执行前补一份形式文档。
编制顺序建议按“目标与范围—风险与策略—层级与类型—资源与环境—进度与准入准出—评审与基线化”推进。前一步的输出是后一步的输入，顺序颠倒容易导致策略脱离风险、进度脱离资源。下表给出每一步的输入、动作与输出。
| 步骤 | 输入 | 动作 | 输出 |
|---|---|---|---|
| 1. 明确目标与范围 | 需求文档、验收标准、项目目标、上一版本遗留问题 | 把需求转成可验证的测试目标，列出纳入与排除项 | 测试目标清单、范围边界说明 |
| 2. 识别风险与定策略 | 需求复杂度、架构说明、历史缺陷、外部依赖清单 | 收集风险、按影响与概率分级，为高等级风险匹配测试层级与类型 | 风险清单、风险—策略对应表 |
| 3. 确定层级与类型 | 风险—策略对应表、系统架构 | 确定单元、集成、系统、验收各层级的覆盖重点，以及功能、性能、兼容性等类型的取舍 | 测试层级与类型安排 |
| 4. 安排资源与环境 | 层级与类型安排、团队人员情况、环境现状 | 明确角色与技能需求、环境与数据准备项、工具与外部依赖 | 资源清单、环境与数据准备清单 |
| 5. 排进度与准入准出 | 资源清单、发布节奏、依赖条件 | 估算工作量，设里程碑，定义各阶段准入准出条件 | 进度表、准入准出标准 |
| 6. 评审与基线化 | 完整计划草稿 | 组织评审、修订、定版，约定变更更新责任 | 基线版测试计划 |
计划文档的最小结构可以对应上述步骤：文档信息与版本记录、测试目标、测试范围（纳入/排除）、风险与应对、测试策略（层级、类型、静态测试与回归安排）、资源与环境、进度与里程碑、准入准出标准、交付物与角色分工、变更记录。结构不必复杂，但每一项都要能对应到后续执行中的具体动作。
测试目标与范围如何界定
测试目标从需求与验收标准中提取，写成可验证的表述。例如“订单提交后 2 秒内返回结果，且金额计算与优惠规则一致”，比“保证订单功能质量”更可执行。每条目标应能对应到具体的验证方式：用例、检查项或度量指标。目标数量控制在能覆盖本次交付关键价值的范围内，过多会稀释测试重点。
范围界定要同时写纳入项和排除项。纳入项列出本次要覆盖的功能模块、接口、数据范围和测试类型；排除项写明本次不测的内容及原因，例如“本期不覆盖历史数据迁移，由数据团队单独验证”。排除项不是免责声明，而是让评审者有机会提出异议，避免执行阶段反复确认边界。
测试层级与类型的取舍依据风险和目标。单元测试由开发承担，重点覆盖核心算法与边界；集成测试关注模块间接口与数据流；系统测试验证端到端业务场景；验收测试对照验收标准确认交付。功能测试是基础，非功能类型按需选择：有性能指标的需求安排性能测试，涉及多端发布的需求安排兼容性测试，涉及权限与敏感数据的需求安排安全相关检查。静态测试（需求评审、设计评审、代码评审）成本低、发现早，应纳入计划而不是默认省略。
范围边界建议用一张表记录，便于评审和后续变更对照：
| 类别 | 内容 | 说明 |
|---|---|---|
| 纳入范围 | 功能模块、接口、测试类型、数据范围 | 逐项列出，标注对应测试目标 |
| 排除范围 | 不测内容及原因 | 写明由谁承接或后续何时覆盖 |
| 假设与依赖 | 依赖的外部系统、第三方服务、数据准备前提 | 标注可用时间与责任人 |
风险识别与测试策略怎么定
风险识别从几个稳定来源收集：需求变更频率与不明确之处、技术复杂度（新架构、新引入的组件）、外部系统与第三方依赖、历史缺陷分布、团队对该模块的熟悉程度、上线时间压力。识别时按“可能出什么问题、影响多大、发生概率多高”记录，形成风险清单，而不是只写一句“存在风险”。
风险分级后与测试投入对应。高影响高概率的风险，安排更充分的测试层级与类型，例如核心交易链路同时覆盖接口测试和端到端场景，并增加回归频次；中等风险按常规覆盖；低风险可采用抽检或依赖静态检查。分级标准要在计划中写明，避免评审时各人理解不一。
策略选择围绕三个问题：在哪个层级测最有效、用哪种类型测、什么时候测。接口问题在集成层测成本更低；业务规则组合在系统层用场景覆盖；性能瓶颈需要独立环境做专项测试；回归范围根据变更影响面确定，变更集中的模块扩大回归，稳定模块缩小回归。静态测试安排在需求与设计阶段，作为早期发现手段。
风险与策略的对应关系用表格记录，一行一个风险，写明等级、应对策略、责任人和验证方式。这张表是后续调整测试范围的依据：风险等级变化时，策略随之调整，并在变更记录中说明。
| 风险 | 等级 | 测试策略 | 责任人 | 验证方式 |
|---|---|---|---|---|
| 支付回调依赖第三方，超时场景未验证过 | 高 | 集成测试覆盖超时与重试，联调环境模拟异常返回 | 测试工程师 A | 异常场景用例通过率 |
| 优惠规则组合多，易出现金额计算错误 | 高 | 系统测试用场景组合覆盖，边界值单独设计用例 | 测试工程师 B | 规则组合用例全部通过 |
| 报表导出为既有功能，本期仅改样式 | 低 | 回归抽检主要导出格式 | 测试工程师 A | 抽检通过 |
资源、环境、数据与进度如何安排
人员安排写清角色与技能需求，而不只是人数。例如性能测试需要具备压测工具和结果分析经验的人员，安全相关检查需要相应技能；如果团队内不具备，要在计划中写明外部支持或培训安排。人员投入按阶段列出，避免执行高峰期才发现人手不足。
测试环境要逐项确认：环境类型（开发联调、测试、预发布）、部署版本、与生产环境的差异、可用时间窗口、申请与维护责任人。测试数据同样要提前准备：需要哪些业务数据、如何构造、是否涉及脱敏、数据量是否满足性能测试要求。环境和数据不到位是进度延误的常见原因，计划中应把它们列为有明确完成时间的准备项。
进度估算以里程碑和准入准出条件为锚点，而不是只排日期。典型里程碑包括：测试计划评审通过、用例评审完成、测试环境就绪、冒烟通过进入系统测试、回归完成、测试报告输出。每个里程碑标注前置条件和责任人。工作量估算可参考历史同类需求的用例数与执行效率，并预留缺陷修复验证和回归的时间。
依赖与外部条件单独记录：第三方接口的联调时间、上游系统的提测时间、运维的发布窗口、业务方的验收时间。每条依赖写明提供方、约定时间和延误时的应对方式，例如“接口联调延后则先执行不依赖该接口的用例”。
角色分工与交付物清单
测试计划由测试负责人编制，测试工程师参与策略与用例部分的输入，开发、产品/业务、运维参与评审。评审的重点分别是：开发确认技术风险与单元测试安排，产品/业务确认范围与验收标准一致，运维确认环境与发布窗口可行。评审通过后由测试负责人定版并维护变更。
各阶段交付物与责任人用 RACI 形式记录（R 负责执行，A 最终批准，C 需咨询，I 需知会），让每项工作有明确归属：
| 交付物 | 测试负责人 | 测试工程师 | 开发 | 产品/业务 | 运维 |
|---|---|---|---|---|---|
| 测试计划 | A/R | C | C | C | C |
| 风险清单与策略 | A | R | C | C | I |
| 测试用例 | A | R | C | C | I |
| 测试环境与数据 | A | R | C | I | R |
| 单元测试与提测说明 | I | C | R | I | I |
| 测试报告 | A | R | I | C | I |
计划变更时的更新责任要提前约定：需求变更由产品/业务提出，测试负责人评估影响并更新范围、风险与进度，涉及环境或发布窗口的变更同步运维。每次变更记录版本、变更内容、影响范围和确认人，保持计划与执行一致。
当测试计划、用例和进度需要在同一处承载时，可以把计划与迭代关联，用例分配到执行人，执行结果和缺陷在测试与研发之间流转。ONES 测试管理支持测试计划与迭代关联、多维度概览测试计划进度、将用例分配执行人，未通过的用例可快速创建缺陷任务，并支持为用例库和测试计划单独配置权限。这些能力适合承载计划评审后的执行跟踪环节；计划模板、评审流程与基线化的具体承载方式，以实际部署和产品当前功能为准。
示例：一个迭代的测试计划片段
以下为演示情景，用于说明填写方式，不代表真实项目数据。
背景与范围：某电商系统两迭代周期内上线“优惠券叠加使用”功能。纳入范围包括优惠券领取、叠加规则计算、订单金额展示、退款时的优惠分摊；排除范围包括优惠券发放活动的运营配置界面（由运营平台团队验证）和历史订单数据迁移。假设条件为支付接口沿用现有版本，不做改动。
目标与风险：目标写成“叠加规则下订单应付金额与优惠分摊金额计算正确，退款金额与实付一致”。风险识别出三项：规则组合多导致计算错误（高）、退款场景与订单状态耦合（高）、优惠券领取并发（中）。对应策略为：规则组合用系统测试场景覆盖并设计边界用例；退款场景覆盖部分退款、全额退款、退款后再次下单；并发领取做接口层并发测试。
资源与进度：测试工程师 2 人，其中 1 人负责接口与并发测试；需要测试环境一套，预置多状态订单数据；里程碑为第 3 天用例评审完成、第 4 天环境就绪、第 5 天冒烟通过进入系统测试、第 12 天回归完成、第 13 天输出测试报告。
准入准出：准入条件为提测版本冒烟用例全部通过、测试数据准备完成；准出条件为高等级风险对应用例全部通过、遗留缺陷无高优先级未关闭项、测试报告经评审。
这个片段的可迁移要点是：范围同时写纳入与排除，风险逐条对应策略，进度以里程碑和准入准出为锚点，每个数字都能在执行中核对。
完成检查：测试计划评审与基线
计划定稿前逐项核对以下清单，每项都能回答“是”才进入评审：
- 测试目标可验证，每条目标能对应到用例、检查项或度量指标。
- 范围同时列出纳入项与排除项，排除项写明原因和承接方。
- 风险清单按影响与概率分级，高等级风险均有对应策略、责任人和验证方式。
- 测试层级与类型的选择能从风险和目标找到依据，静态测试与回归安排已写明。
- 人员角色与技能需求、环境与数据准备项均有责任人和完成时间。
- 进度包含里程碑、前置条件和预留的缺陷修复与回归时间。
- 准入准出条件具体可判定，交付物清单与责任人明确。
- 外部依赖逐条记录提供方、约定时间和延误应对方式。
- 变更更新责任已约定，版本记录栏已建立。
一致性核对关注三组对应关系：目标与范围是否互相支撑，范围之外的目标不应出现在计划中；风险与策略是否一一对应，高等级风险不能只靠常规回归覆盖；准入准出与交付物是否匹配，准出条件要求的证据应在交付物清单中有对应项。
评审通过后由测试负责人定版并基线化，基线版本作为执行和验收的依据。后续出现需求变更、范围调整、风险等级变化或进度重大偏移时触发更新，更新后重新确认受影响部分的评审意见，并在变更记录中保留旧版本，便于追溯计划与执行之间的差异。
常见问题
测试计划应该在项目哪个阶段开始编制，需求还在变化时怎么办？
测试计划在项目或迭代启动、需求评审之后、测试执行之前编制。此时需求已有初稿和验收标准，足以支撑目标与范围的界定。需求仍在变化时，可以先基线化目标、范围、风险和准入准出这些相对稳定的部分，把受变更影响的具体用例范围和进度留到需求确认后补充，并在变更记录中写明本次基线的假设条件。需求发生较大变更时，由测试负责人评估影响，更新范围、风险与进度，再确认受影响部分的评审意见。
团队规模小、没有专职测试负责人时，角色分工怎么落地？
角色分工的核心是每项交付物有明确归属，人数少时可以一人承担多个角色。例如测试工程师同时承担计划编制与用例设计，开发负责人承担技术风险确认，产品负责人确认范围与验收标准。RACI 表中同一行可以出现多个字母，但“最终批准”一栏建议只保留一个责任人，避免评审意见无法收敛。外部支持如性能测试、安全相关检查，在计划中写明由谁提供、何时介入即可。
风险清单列了很多条，测试资源有限时怎么取舍？
先按影响与概率分级，把高影响高概率的风险对应到更充分的测试层级与类型，例如核心链路同时覆盖接口测试和端到端场景，并提高回归频次。中等风险按常规覆盖，低风险采用抽检或依赖静态检查。取舍结果要写进风险—策略对应表，注明哪些风险本期只做部分覆盖、原因是什么、遗留部分由谁在后续承接。这样评审时能对取舍本身形成共识，而不是在执行阶段临时压缩范围。
准入准出条件写到什么程度才算可判定？
准入准出条件要能直接用执行结果判断是否满足。例如准入写成“提测版本冒烟用例全部通过、测试数据准备完成”，准出写成“高等级风险对应用例全部通过、遗留缺陷无高优先级未关闭项、测试报告经评审”。避免“基本可用”“主要功能正常”这类无法核对的表述。每条条件最好对应交付物清单中的一项证据，准出时能直接找到用例执行记录、缺陷列表或测试报告。
计划基线化之后，什么情况需要重新评审而不是直接更新？
范围扩大或缩小、高等级风险等级变化、里程碑发生重大偏移、准入准出条件调整，这几类变化会影响其他角色的承诺，建议重新确认受影响部分的评审意见。仅涉及执行细节的调整，例如用例顺序、执行人微调，由测试负责人更新并在变更记录中说明即可。无论哪种情况，都保留旧版本和变更内容，便于追溯计划与执行之间的差异。
