制定测试计划的核心，是把测试目标、范围、风险、策略、资源和进度写成一份可执行、可检查的文档。先明确本次要验证的质量目标与不测范围，再识别风险并据此确定测试层级、类型和优先级，随后安排人员、环境、数据与时间，最后约定准入准出标准、缺陷处理方式和变更机制。计划需要在需求变化和风险变化时更新，并通过评审与执行反馈验证其可操作性。下文按字段、策略、角色、排期、示例和检查六个环节展开。
要点总览（TL;DR）
- 测试计划先写清七个字段：目标、范围、风险、策略、资源、进度、准入准出，每个字段都要写到可判断“做没做到”的程度。
- 测试策略从目标拆风险，再按风险高低分配测试层级、类型和覆盖深度，避免笼统的“全面测试”。
- 计划由测试负责人起草、组织评审，产品、开发、业务方提供输入并参与评审，执行阶段各角色按交付物清单交接。
- 进度从开发里程碑倒推，回归窗口要预留；准入准出条件写成可逐项核对的形式，并指定核对人。
- 计划写完后用一致性、资源就绪、条件可判断等核对项过一遍，需求或风险变化时更新版本并记录变更。
测试计划先写什么：一份可执行计划的核心字段
测试计划的第一版不必追求篇幅，先把七个字段写清楚：目标、范围、风险、策略、资源、进度、准入准出。每个字段都要能回答一个具体问题，并且写到别人可以据此判断“做没做到”的程度。字段之间要相互对应，例如目标里写了支付成功率，策略和准出条件里就应有对应的验证方式与阈值。
| 字段 | 填写要点 | 示例 |
|---|---|---|
| 测试目标与质量目标 | 用可验证的表述写清本次要证明什么，避免“保证质量”这类无法判断的写法 | 本次版本核心下单链路在峰值 500 并发下订单创建成功率不低于 99.5%，支付回调处理时延 P95 小于 2 秒 |
| 测试范围与不测范围 | 列出纳入测试的需求、模块、接口和端；同时写明本次不测的内容及原因，防止验收时争议 | 范围：下单、支付、退款三个模块及对应接口；不测：历史订单数据迁移，由数据团队单独验证 |
| 风险与优先级 | 列出可能影响质量或进度的风险项，标注影响程度与发生可能性，给出应对动作 | 风险：第三方支付沙箱不稳定，影响支付用例执行；应对：提前申请备用沙箱，支付用例优先安排 |
| 测试策略 | 说明测试层级、测试类型、静态测试和维护测试如何组织，以及各自的覆盖重点 | 单元测试由开发负责；集成测试覆盖订单与支付接口；系统测试覆盖主流程与异常分支；验收测试由业务方执行 |
| 资源、环境、数据与进度 | 写清人员角色、环境数量与准备时间、测试数据来源，以及与开发里程碑对齐的时间点 | 测试环境 2 套，支付沙箱 1 套；测试数据从脱敏生产数据生成；系统测试在开发提测后第 2 天开始 |
| 准入准出标准 | 用可判断的条件描述何时可以开始测试、何时可以结束测试 | 准入：提测版本冒烟通过率 100%，接口文档与变更说明齐全；准出：P0/P1 缺陷清零，P2 缺陷有明确处理计划 |
| 交付物 | 列出计划执行过程中要产出的文档与记录，并指定责任人 | 测试用例集、测试数据说明、缺陷记录、测试报告、上线风险评估 |
填写顺序建议从目标和范围开始，因为风险和策略都依赖这两项。范围写得越具体，后续的策略选择和排期越容易收敛。计划文档本身要有版本号和修改记录，便于执行过程中追溯。
从目标到策略：按风险确定测什么、测多深
测试目标确定后，下一步是把目标拆成风险项，再按风险高低分配测试深度。笼统写“全面测试”会让计划失去排期依据，也无法在资源紧张时做出取舍。可行的做法是先识别风险，再为每类风险指定测试层级、测试类型和覆盖深度。
识别功能与非功能风险
功能风险来自需求变更频繁的模块、逻辑复杂的计算规则、与外部系统交互的接口、历史缺陷集中的区域。非功能风险来自性能峰值、并发场景、安全敏感数据、兼容性要求、可用性和恢复能力。识别时可以让产品、开发、测试各自列出最担心的三个问题，再合并去重，形成风险清单。每个风险项标注影响程度（高、中、低）和发生可能性，两者组合决定优先级。
按风险分配测试深度
| 风险等级 | 典型情形 | 测试深度与安排 |
|---|---|---|
| 高 | 核心交易链路、资金相关计算、外部支付接口、峰值并发 | 覆盖正常与异常分支，安排接口自动化回归、性能测试和安全测试，用例评审由开发与产品共同参与 |
| 中 | 辅助功能、内部管理页面、低频操作 | 覆盖主流程与关键异常，以手工测试为主，必要时补充接口测试 |
| 低 | 文案展示、样式调整、影响面小的配置项 | 冒烟验证或抽查，结合静态检查确认 |
测试层级的分工
单元测试由开发在编码阶段完成，重点验证函数与类的逻辑；集成测试验证模块之间、服务与外部系统之间的接口契约和数据传递；系统测试从用户视角验证端到端流程；验收测试由业务方确认需求是否被满足。计划中要写明每个层级由谁负责、在什么时间点执行、以什么结果作为完成标志，避免同一内容在多个层级重复测试而挤占高风险项的测试时间。
静态测试与维护测试的位置
静态测试包括需求评审、设计评审、代码走查和文档检查，成本低且能提前发现问题，适合安排在开发提测之前。维护测试针对已有功能的回归验证，计划中要说明回归范围如何选取：与本次变更相关的模块必须回归，核心链路每次版本都纳入回归集，低频模块可按季度轮换。策略与目标的对应关系要能说清：目标中的每一项质量指标，都能在策略中找到对应的验证活动和判断依据。
角色与交付物：谁写计划、谁评审、谁执行
测试计划通常由测试负责人起草，测试工程师参与策略和用例部分的编写，开发与产品提供风险和范围输入。评审由测试负责人组织，产品经理、开发负责人和业务方代表参加，批准人对计划的完整性和可执行性负责。执行阶段，测试工程师按计划执行用例并记录结果，开发负责缺陷修复，产品负责需求澄清和验收确认。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 测试负责人 | 起草计划、组织评审、跟踪进度与风险、维护计划变更 | 测试计划、进度跟踪记录、测试报告 |
| 测试工程师 | 设计用例、准备测试数据、执行测试、提交并跟踪缺陷 | 测试用例集、测试数据说明、缺陷记录、执行记录 |
| 开发负责人 | 提供提测版本与变更说明、修复缺陷、支持环境问题排查 | 提测说明、缺陷修复记录 |
| 产品经理 | 确认需求范围与优先级、参与用例评审、澄清需求疑问 | 需求说明与变更记录、验收结论 |
| 业务方 | 参与验收测试、确认业务规则与验收标准 | 验收意见 |
跨角色交接要约定明确时点：提测时开发提交版本与变更说明，测试负责人确认准入条件后回复是否接收；用例评审在提测前完成，评审意见形成记录并关闭；测试报告在准出评审前发出，缺陷处理结论随报告一并确认。交接以书面记录为准，口头确认后补记录，避免后续对范围和时间产生分歧。
进度、资源与准入准出如何落到计划里
进度安排从开发里程碑倒推：提测时间确定后，向前安排用例设计与评审、环境准备、数据准备，向后安排系统测试、回归测试、验收测试和上线窗口。每个测试活动写明开始时间、结束时间、负责人和完成标志。测试时间要留出缺陷修复后的回归窗口，不能把回归安排在提测最后一天。
资源准备项
- 人员：明确各测试类型的执行人，以及高峰期是否需要借调或加班安排。
- 环境：列出所需环境数量、配置要求、准备完成时间和维护责任人；涉及外部系统时提前确认联调窗口。
- 测试数据：说明数据来源、脱敏方式、生成时间和覆盖场景，指定数据准备责任人。
- 工具与账号：提前申请测试账号、权限和必要的测试工具，避免执行当天才发现无法访问。
准入准出条件的写法
准入条件描述开始测试的前提，例如提测版本冒烟通过、变更说明和接口文档齐全、测试环境可用、测试数据就绪。准出条件描述结束测试的判断依据，例如高优先级缺陷全部关闭、中优先级缺陷有明确处理计划、核心用例执行率与通过率达到约定值、测试报告完成评审。条件要写成可以逐项核对的形式，并指定核对人。
缺陷分级与变更机制
缺陷分级按影响程度约定：导致核心流程中断或数据错误的为最高级，影响主要功能但有临时绕行方案的次之，界面与文案问题归为一般级。每级约定响应时限和修复时限，以及准出时各级缺陷的允许状态。计划变更的触发条件包括需求范围调整、提测时间推迟、环境长时间不可用、发现重大风险项。触发后由测试负责人更新计划版本，记录变更内容和影响范围，通知相关角色确认。
示例：一个版本迭代的测试计划怎么写
以下示例为演示情景，用于说明填写过程，不代表真实项目数据。
背景与目标：某电商系统进行订单模块版本迭代，新增优惠券叠加使用和部分退款功能。测试目标为：优惠券叠加规则在 12 种组合下计算结果正确；部分退款金额计算准确，退款成功后订单状态与金额同步更新；核心下单链路在 300 并发下成功率不低于 99%。
风险识别与策略：高风险项为优惠券叠加计算规则复杂、退款涉及资金计算、与支付网关交互；中风险项为订单列表展示调整；低风险项为页面文案修改。对应策略：叠加规则采用等价类与边界值设计用例，由开发补充单元测试；退款金额计算安排接口测试并核对账务流水；支付交互安排集成测试与异常场景模拟；下单链路安排性能测试；文案修改做冒烟检查。回归范围包括下单、支付、退款主流程，历史订单查询做抽查。
资源与进度：测试工程师 2 人，测试环境 1 套，支付沙箱 1 套，测试数据由脱敏生产数据生成。第 1 至 2 天完成用例设计与评审，第 3 天准备环境与数据，第 4 天提测并执行冒烟，第 5 至 9 天执行系统测试与接口测试，第 10 天执行性能测试，第 11 至 12 天回归与验收，第 13 天出测试报告。
准入准出与交付物：准入条件为冒烟用例全部通过、变更说明与接口文档齐全、测试数据就绪。准出条件为最高级与次高级缺陷全部关闭、一般级缺陷有处理计划、核心用例通过率 100%、性能指标达标、测试报告完成评审。交付物包括测试用例集、测试数据说明、缺陷记录、性能测试结果和测试报告。
取舍说明：本次未安排安全测试，原因是变更不涉及认证与权限逻辑，安全测试按季度单独执行；历史订单数据迁移不在本次范围，由数据团队验证。把有限时间集中到优惠券计算和退款资金链路上，是因为这两处出错会直接影响用户资金和账务对账。
完成检查：测试计划评审与执行前的核对项
计划写完后，用下面的清单逐项核对，确认具备执行条件再进入评审。评审通过的标准是所有核对项都有明确结论，未决项有责任人和完成时间。
| 核对项 | 判断标准 |
|---|---|
| 目标与范围一致 | 每个质量目标都有对应的测试范围，不测范围写明了原因和承接方 |
| 风险与策略对应 | 每个高风险项都有对应的测试层级、测试类型和覆盖深度，没有只列风险不给动作的条目 |
| 角色与交付物明确 | 编写、评审、批准、执行的责任人都已指定，交付物有名称和提交时点 |
| 资源与环境就绪 | 人员、环境、数据、账号的准备项有责任人和完成时间，外部依赖已确认 |
| 准入准出可判断 | 条件写成可逐项核对的形式，核对人和判断时点明确 |
| 进度可排期 | 测试活动与开发里程碑对齐，回归窗口已预留，关键路径上的依赖已识别 |
| 变更机制可用 | 变更触发条件、更新方式、通知对象和记录位置已约定 |
评审参与方包括测试负责人、测试工程师、开发负责人、产品经理和业务方代表，评审结论记录为通过、有条件通过或不通过，有条件通过时列出待办项和关闭时间。执行过程中，出现需求变更、提测推迟、环境故障或发现新的高风险项时更新计划，更新后在修改记录中写明版本、变更内容、影响范围和确认人。每个测试阶段结束时对照计划检查执行偏差，偏差较大的部分在下一版本计划中调整测试深度和资源安排。
当测试计划需要多人协作编写、评审意见需要留痕、执行进度需要与需求和缺陷关联跟踪时，可以把计划文档、测试用例、缺陷和版本里程碑放在同一协作空间中管理。ONES 支持项目工作项、文档协作与评审记录的管理，测试团队可以在其中维护计划版本、分配测试任务、跟踪缺陷状态，并按里程碑查看执行进展，使计划中的角色分工和准出条件有对应的记录可查。
常见问题
测试计划需要写到多细才算可执行？
判断标准是别人能否据此判断“做没做到”。目标要带可验证的指标，范围要列出模块和接口并写明不测内容，准入准出条件要能逐项核对。计划不必一次写全所有细节，用例设计、测试数据说明等可以在计划框架下继续细化，但目标、范围、风险、策略、资源和准出条件这几项要在评审前定下来。
项目时间紧，测试计划可以省略哪些内容？
时间紧时可以压缩篇幅，但不宜省略风险与策略的对应关系，也不宜省略准入准出条件。可以简化的部分包括：低风险模块的用例设计细节、非核心功能的测试数据说明、部分交付物的模板化描述。取舍的依据是风险高低——把有限时间集中到高风险项上，同时在不测范围里写明哪些内容本次不覆盖、由谁承接，避免验收时产生争议。
需求在测试执行中途变更，计划怎么处理？
先判断变更是否影响目标、范围或准出条件。影响范围时，由测试负责人更新计划版本，记录变更内容、影响范围和确认人，并通知产品、开发和业务方。影响较小的情况可以在执行记录中备注，不必每次升版。若变更导致原定测试时间不足，应同步调整测试深度或资源安排，并把调整理由写进修改记录，便于后续复盘。
敏捷迭代周期短，还需要单独写测试计划吗？
短周期迭代可以把计划写得更轻，例如在迭代说明中固定目标、范围、风险、测试类型和准出条件几项，随迭代走查同步确认。关键是保留风险与策略的对应关系和准出判断依据，而不是套用完整文档模板。多个迭代共享的回归范围、环境安排和缺陷分级约定，可以放在团队级约定中，迭代计划只引用不重复。
测试计划评审没通过，常见原因有哪些？
常见原因包括：目标写成“保证质量”这类无法判断的表述；风险清单只列问题不给应对动作；准入准出条件模糊，无法逐项核对；资源与环境准备没有责任人和完成时间；测试活动与开发里程碑脱节，回归窗口没有预留。评审结论可以记为有条件通过，把待办项和关闭时间列清楚，关闭后再进入执行。
