制定测试计划的核心是先把测试对象和范围拆清楚，再按测试类型分配资源与时间，明确每类测试的输入、负责人、交付物和完成标志，最后用检查项确认计划可执行。一份可用的测试计划至少包含测试范围与不测范围、测试类型与对应策略、环境与数据准备、角色分工、进度与里程碑、风险与应对、准入准出标准。下面按字段、范围、资源、角色、示例、评审和自检七个环节展开。
要点总览（TL;DR）
- 一份可用的测试计划至少写清七项：测试范围与不测范围、测试类型与策略、环境与数据准备、角色分工、进度与里程碑、风险与应对、准入准出标准。
- 范围拆解从需求与架构出发，按功能、接口、性能、兼容性、安全等类型分别确定覆盖对象、测试深度和进入条件，并把不测项及原因写明。
- 资源估算可结合用例数、测试类型工作量和历史数据三种方法；环境与数据要写明准备时点和负责人，排期与开发提测节奏衔接并预留回归窗口。
- 计划定稿前经过评审，确认范围完整、资源可行、时间合理；需求变更或提测延期时按预设规则调整范围与排期，并记录偏差、同步相关角色。
- 用自检清单逐项核对范围、类型深度、负责人与环境时间、准入准出、风险应对和评审记录，全部通过再进入执行。
测试计划先写什么：核心结构与关键字段
测试计划是一份执行约定，需要回答“测什么、怎么测、谁来测、什么时候测、什么算测完”。字段缺失会直接导致后续排期和验收失去依据。建议先按最小字段集搭出文档骨架，再逐项填充。
| 字段 | 填写内容 | 负责人 |
|---|---|---|
| 测试范围与不测范围 | 本次覆盖的需求、模块、接口；明确排除项及原因 | 测试负责人 |
| 测试类型与策略 | 功能、接口、性能、兼容性、安全等类型，各自的深度与执行方式 | 测试负责人、测试工程师 |
| 环境与数据准备 | 所需环境、版本、测试数据来源与准备时点 | 测试工程师、运维或开发 |
| 角色分工 | 测试、开发、产品各自职责与对接人 | 测试负责人 |
| 进度与里程碑 | 提测时间、测试轮次、回归窗口、报告输出时间 | 测试负责人 |
| 风险与应对 | 识别出的风险项、影响、应对措施与触发条件 | 测试负责人 |
| 准入准出标准 | 开始测试的条件、结束测试的判定标准 | 测试负责人、产品 |
字段之间存在依赖：范围决定需要哪些测试类型，测试类型决定人力与环境投入，资源与时间再决定进度是否可行。填写时按这个顺序推进，可以避免先排期再补范围造成的返工。每个字段的填写人应在计划评审前确认，避免多人各写一版。
按测试类型拆解范围与策略
范围拆解的起点是需求文档和架构说明。逐条需求识别涉及的模块、接口和外部依赖，再判断需要哪些测试类型。功能测试覆盖业务规则与主流程；接口测试覆盖服务间调用与数据契约；性能测试针对高并发或大数据量场景；兼容性测试针对浏览器、终端或系统版本；安全测试针对权限、敏感数据和输入校验。
每类测试的深度依据三个因素判断：风险等级（影响用户量、资金或合规）、变更范围（新增、修改还是重构）、历史缺陷分布（该模块过去缺陷密度高的部分加测）。风险高且变更大的模块做深入测试，低风险的小改动以冒烟和回归为主。
| 测试类型 | 覆盖对象 | 深度 | 进入条件 |
|---|---|---|---|
| 功能测试 | 新增与变更需求的主流程、异常分支 | 核心流程全覆盖，异常分支按风险取舍 | 提测版本部署完成，冒烟通过 |
| 接口测试 | 新增或变更的服务接口 | 正常参数与关键异常参数 | 接口文档确认，联调环境可用 |
| 性能测试 | 高并发入口、批量处理任务 | 按预估峰值压测，关注响应时间与错误率 | 功能稳定，压测环境与数据就绪 |
| 兼容性测试 | 目标浏览器、终端、系统版本 | 覆盖主流版本，边缘版本抽测 | 功能测试通过，测试设备可用 |
| 安全测试 | 登录鉴权、权限控制、敏感数据 | 按合规要求与风险等级确定 | 相关功能开发完成 |
不测范围同样要写清楚，并注明原因，例如“本期不改动支付模块，不做支付回归”“性能压测安排在下一迭代单独执行”。明确排除项能防止执行中范围蔓延，也便于评审时确认取舍是否合理。各测试类型之间存在依赖：接口测试通常先于功能联调完成，性能测试需要功能稳定后开展，排期时应体现先后顺序。
资源、环境与进度如何排布
资源估算有三种常用方法，可结合使用：按用例数估算，用历史人均日执行用例数乘以用例总量；按测试类型工作量估算，分别给出功能、接口、性能等类型的工时；按历史数据估算，参考同类版本的实际投入。估算结果应包含用例设计、执行、缺陷跟踪和回归的时间。
环境与数据需要提前锁定准备时点和负责人。测试环境在提测前完成部署并验证可用；测试数据在用例设计阶段确定来源，涉及生产数据脱敏的提前申请；性能测试环境单独准备，避免与功能测试互相干扰。每项准备在计划中写明完成时间和责任人。
| 里程碑 | 时间点 | 完成标志 |
|---|---|---|
| 计划评审通过 | 开发中期 | 范围、资源、排期确认 |
| 用例设计完成 | 提测前 | 用例评审通过 |
| 环境与数据就绪 | 提测前 | 冒烟验证通过 |
| 第一轮测试完成 | 提测后约定天数 | 用例执行完成，缺陷提交 |
| 回归与准出 | 修复后约定窗口 | 回归通过，准出评审完成 |
排期要与开发提测节奏衔接：提测时间以开发实际完成度为依据，计划中写明提测准入条件，例如冒烟用例通过率达标才接收提测。测试轮次之间预留回归窗口，避免修复与验证挤在同一时段。
角色分工与交付物：谁在什么时点交什么
责任不清是计划落地失败的主要原因。计划中应把每个阶段的产出物对应到具体角色和验收人。
| 角色 | 职责 | 交付物 | 验收人 |
|---|---|---|---|
| 测试负责人 | 制定计划、组织评审、跟踪进度、输出报告 | 测试计划、测试报告 | 产品负责人、开发负责人 |
| 测试工程师 | 设计用例、执行测试、提交缺陷、回归验证 | 测试用例、缺陷清单 | 测试负责人 |
| 开发 | 按时提测、修复缺陷、提供环境支持 | 提测版本、修复记录 | 测试负责人 |
| 产品 | 确认需求口径、参与准出评审 | 需求确认结论、准出意见 | 测试负责人 |
评审与确认节点包括计划评审、提测确认和准出评审。计划评审确认范围与资源可行；提测确认核对准入条件是否满足；准出评审依据准出标准判断能否发布。每个节点写明参与人和确认方式，避免口头确认后无法追溯。
计划落到执行时，需要把范围、任务分配和进度对应到可跟踪的工作项上。ONES 测试管理支持测试计划与迭代关联，测试用例与需求、任务关联，形成测试流程闭环；测试计划提供规划和执行能力，并可多维度概览全部测试计划、查看进度。用例可分配执行人，未通过的用例可快速创建缺陷任务，缺陷在测试与研发团队间流转，缺陷也可关联至迭代。这些能力让计划中的分工和里程碑有对应的状态可查，评审时以工作项状态作为确认依据。
示例：一个版本迭代的测试计划怎么写
以下为演示情景，不对应真实项目。某版本迭代包含两项新功能（订单导出、消息提醒）和一项改动（登录流程调整），计划周期两周。
范围拆解：订单导出涉及导出接口与文件生成，安排功能测试和接口测试；消息提醒涉及推送服务，安排功能测试和兼容性测试（覆盖主流浏览器与移动端）；登录流程调整涉及鉴权逻辑，安排功能测试和安全测试（权限校验）。不测范围：支付模块本期无改动，不做回归；性能压测安排在下一迭代单独执行。
资源与进度：测试工程师两人，按用例数估算功能测试约六人日、接口测试两人日、兼容性测试一人日、安全测试一人日。测试环境在提测前两天部署完成，导出测试数据提前准备。里程碑：提测前完成用例评审和环境冒烟；提测后第三天完成第一轮测试；修复后预留两天回归；准出评审在回归通过当天进行。
风险与应对：推送服务依赖第三方通道，若通道不稳定则改用测试桩验证业务逻辑，通道联调单独安排；登录改动影响面广，若回归发现关联问题，扩大回归范围至账号相关功能，并同步调整准出时间。风险项写明触发条件和应对动作，执行中按条件判断是否启用。
计划评审与执行中的调整机制
计划评审围绕三个检查点展开：范围完整性，确认需求条目与测试类型一一对应，不测范围有明确理由；资源可行性，核对人力、环境、数据是否在计划时点可用；时间合理性，检查测试轮次与回归窗口是否留有余量，提测时间是否与开发节奏匹配。
需求变更或提测延期时，按规则调整：变更影响范围的，先更新范围与类型表，再评估工时和排期；提测延期的，顺延测试轮次但保留回归窗口，压缩范围需经产品确认。调整规则提前写进计划，执行时按规则处理，减少临时协商。
计划与执行的偏差要记录，包括延期原因、范围增减、资源变化，记录方式可以是计划文档的修订记录或工作项的状态变更。调整后同步给所有相关角色，并在下一次评审或站会上确认，确保各方按最新版本执行。
完成检查：测试计划可执行的自检清单
计划定稿前逐项核对下表，全部通过才视为可执行。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 范围与不测范围 | 需求条目均有对应测试类型，排除项有原因 | 测试负责人 |
| 测试类型与深度 | 每类测试写明覆盖对象、深度和进入条件 | 测试负责人 |
| 负责人、环境、时间 | 每类测试均有负责人、环境就绪时点和执行时间 | 测试工程师 |
| 准入准出标准 | 标准可判定，例如冒烟通过率、缺陷收敛条件 | 测试负责人、产品 |
| 风险与应对 | 风险项具体，写明触发条件和应对动作 | 测试负责人 |
| 评审确认 | 计划经过评审，参与人确认并留有记录 | 测试负责人 |
清单核对完成后，计划即可进入执行。执行中按评审与调整机制维护，版本结束时对照准出标准判断是否达到发布条件。
常见问题
测试计划里的“不测范围”一定要写吗？写了会不会显得测试覆盖不足？
建议写，而且要写原因。不测范围的作用是提前说明取舍，例如“本期不改动支付模块，不做支付回归”“性能压测安排在下一迭代单独执行”。评审时各方可以据此判断取舍是否合理，执行中也减少临时加测带来的范围蔓延。
写法上把排除项和理由放在一起，涉及风险较高的模块时补充说明后续安排，读者能看清这是有依据的取舍，而非遗漏。
需求在测试执行中途变更，原计划已经评审通过，应该怎么处理？
按计划中预设的调整规则处理：先判断变更是否影响测试范围，影响范围的更新范围与测试类型表，再重新评估工时和排期；不影响范围的，评估是否需要补充用例。调整后同步给开发、产品和测试相关角色，并在下一次评审或站会上确认按最新版本执行。
如果变更导致原定准出时间无法保证，把范围压缩或时间顺延作为选项提交产品确认，避免测试团队单方面承担。
团队规模较小，没有独立的测试负责人，计划由谁制定和评审？
可以由承担测试主责的工程师制定，评审邀请开发负责人和产品负责人参加，重点确认范围、提测准入条件和准出标准。角色表按实际人员填写，一人兼多个角色时在表中注明，避免出现无人认领的交付物。
小团队更需要把提测准入条件和回归窗口写清楚，这两项直接决定排期是否可行。
测试计划制定后，怎么跟踪执行进度和偏差？
把计划中的范围、任务分配和里程碑对应到可跟踪的工作项上，用状态反映执行情况。ONES 测试管理支持测试计划与迭代关联，测试用例与需求、任务关联，形成测试流程闭环；测试计划提供规划和执行能力，并可多维度概览全部测试计划、查看进度。用例可分配执行人，未通过的用例可快速创建缺陷任务，缺陷在测试与研发团队间流转，缺陷也可关联至迭代。
偏差记录写明延期原因、范围增减和资源变化，调整后同步相关角色，评审时以工作项状态作为确认依据。
性能测试、安全测试这类专项测试，需要和功能测试写在同一份计划里吗？
可以放在同一份版本测试计划中，按测试类型分列覆盖对象、深度、进入条件和负责人；专项测试依赖功能稳定或环境独立时，在计划中写明先后顺序和单独的时间窗口。例如性能测试安排在功能测试通过后、使用独立压测环境执行。
如果专项测试由独立团队承担，在角色表中写明对接人和交付物，避免与功能测试的排期互相挤占。
