测试策略与计划要分两层做：策略先回答“测什么、为什么测、测到什么程度”，依据业务目标和风险确定测试范围、层级、类型与准入准出；计划再把策略落到“谁在什么时间用什么环境测哪些对象”，明确阶段、资源、进度、交付物和变更机制。本文按“先风险分析、再定策略、最后排计划”的顺序，给出可套用的结构、模板和完成检查清单，适用于版本迭代或项目级测试规划。
要点总览（TL;DR）
- 测试策略与计划分两层：策略回答测什么、为什么测、测到什么程度，计划回答谁在什么时间用什么环境测哪些对象，先定策略再排计划。
- 测试范围与优先级由风险分析决定，从业务影响、变更范围、历史缺陷、技术复杂度、外部依赖五个角度识别，用影响×概率排序形成风险清单。
- 策略文档要写出取舍：可衡量的质量目标、测试层级与类型组合、静态与维护测试安排、准入准出标准，以及写明理由的不测范围。
- 计划把策略拆成用例设计、环境准备、执行、回归、报告等活动，任务到人、时间可排、依赖落实，并设置10%–20%缓冲和变更触发条件。
- 用完成检查清单逐项核对，重点看计划活动能否追溯到策略中的风险与目标，评审与更新机制是否建立。
先分清策略与计划：两层各自回答什么问题
把排期表当策略、把原则口号当计划，是测试规划最常见的两类偏差。策略是方向性文件，回答“测什么、为什么测、测到什么程度”；计划是执行性文件，回答“谁在什么时间用什么环境测哪些对象”。两者先后关系明确：先有策略确定范围和标准，计划才有依据去拆任务、排时间。
策略相对稳定，通常按产品线或项目阶段更新，重大业务变化、架构调整或质量事故后才需要修订。计划随版本滚动，每个迭代或版本发布前编制，执行中根据进度和风险变化调整。策略为计划提供约束，计划为策略提供落地证据，二者通过评审和度量形成闭环。
| 维度 | 测试策略 | 测试计划 |
|---|---|---|
| 核心问题 | 测什么、为什么测、测到什么程度 | 谁在什么时间用什么环境测哪些对象 |
| 主要输入 | 业务目标、风险分析结果、质量要求、历史缺陷数据 | 测试策略、版本范围、需求清单、资源与环境条件 |
| 主要输出 | 测试目标、范围与优先级、层级与类型组合、准入准出、不测范围 | 阶段划分、任务与责任人、环境与数据、进度与依赖、交付物 |
| 负责人 | 测试负责人主导，产品、开发、架构参与评审 | 测试负责人或测试组长编制，项目团队确认 |
| 更新频率 | 按产品阶段或重大变化修订，相对稳定 | 按版本或迭代滚动更新，执行中动态调整 |
第一步：用风险分析确定测试范围与优先级
测试范围要有依据，最可靠的依据是风险。风险分析的目标是产出一份可排序、可追溯的风险清单，让“哪些模块测深、哪些只做冒烟”有明确理由，而不是凭经验平均用力。
风险来源可以从五个角度识别：业务影响，即功能失效对收入、合规、用户体验的损害程度；变更范围，即本次版本改动了哪些模块和接口；历史缺陷，即过去缺陷密集或反复出问题的区域；技术复杂度，即新架构、新依赖、并发或数据一致性等难点；外部依赖，即第三方服务、上下游系统交付的稳定性。逐项列出后，用“影响×概率”打分或高/中/低分级排序。
| 风险项 | 影响 | 概率 | 等级 | 对应测试措施 | 责任人 |
|---|---|---|---|---|---|
| 支付流程改造 | 高（涉及资金） | 中 | 高 | 接口集成测试+端到端场景+异常分支+回归 | 测试负责人A |
| 权限模型调整 | 高（涉及数据安全） | 中 | 高 | 权限矩阵用例+越权测试+多角色验收 | 测试工程师B |
| 报表样式微调 | 低 | 低 | 低 | 冒烟+界面检查 | 测试工程师C |
| 第三方物流接口升级 | 中 | 中 | 中 | 契约测试+异常返回模拟+联调 | 测试工程师D |
由风险推导测试深度：高风险模块安排更完整的层级覆盖（单元、集成、系统、验收）和更多测试类型（功能、性能、安全、兼容），并纳入每轮回归；中风险模块做核心路径与集成验证；低风险模块以冒烟和界面检查为主。风险清单要指定责任人和复核时间，执行中发现新风险时及时补充并调整措施。
第二步：把风险转成测试策略的核心内容
策略文档写得空泛，往往是因为只写了原则没有写取舍。一份可执行的策略，每个章节都应能对应到具体的风险项和可检查的标准。以下是策略文档的章节骨架与填写要点。
测试目标与质量目标
目标要与业务目标对齐并可衡量。例如“支付相关缺陷在发布前拦截率不低于95%”“核心链路P95响应时间不超过500毫秒”“高危权限缺陷零遗留”。避免写“保证质量”这类无法验证的表述。
测试层级组合
明确单元、集成、系统、验收各承担什么，避免重复与遗漏。单元测试由开发负责，覆盖核心逻辑与边界；集成测试验证模块间接口与数据流；系统测试覆盖端到端业务场景与非功能属性；验收测试由产品与业务方确认需求满足度。每一层写清入口条件、责任人和退出标准。
测试类型组合
功能、性能、安全、兼容、易用等类型按风险取舍，不追求全覆盖。高风险且涉及资金的模块必须做安全与性能验证；面向多端的版本安排兼容性测试；内部工具类需求可缩减易用性测试。每类测试写明触发条件、执行方式和负责角色。
静态测试与维护测试
静态测试包括需求评审、设计评审、代码走查，安排在对应阶段前置执行。维护测试针对线上问题的修复验证和回归，明确修复验证流程、回归范围和发布条件。
准入准出与缺陷处理原则
准入标准说明什么条件下可以开始测试，如提测版本通过冒烟、环境就绪、需求文档确认。准出标准说明什么条件下可以发布，如高等级缺陷清零、用例执行率与通过率达到约定值、回归完成。缺陷处理原则明确分级定义、修复时限和遗留缺陷的审批方式。
不测范围与理由
明确写出本次不测的内容及原因，例如“旧版客户端不再维护，不做兼容测试”“第三方支付页面由供应商负责，仅验证跳转与回调”。不测范围经评审确认后作为范围基线，防止执行中范围蔓延。
第三步：把策略拆成可执行的测试计划
计划的任务来源是策略确定的范围和层级类型组合。按版本或迭代拆解测试活动，典型活动包括用例设计与评审、环境与数据准备、测试执行、回归、测试报告与复盘。每项活动要有负责人、起止时间、前置依赖和产出物。
工作量估算有三种常用方法：按用例数估算，用历史人均日执行用例数推算；按历史执行效率估算，参考同类版本的实际投入；按风险加权估算，高风险模块乘以更高系数。三种方法可结合使用，估算结果保留缓冲，通常为总工期的10%–20%，用于应对缺陷修复回归和环境问题。
| 活动 | 负责人 | 起止时间 | 依赖 | 产出 | 状态 |
|---|---|---|---|---|---|
| 用例设计与评审 | 测试工程师B | 第1–3天 | 需求文档确认 | 用例集与评审记录 | 未开始 |
| 测试环境与数据准备 | 运维/测试工程师D | 第2–4天 | 部署包就绪 | 可用环境与测试数据 | 进行中 |
| 冒烟测试 | 测试工程师C | 第4天 | 提测版本 | 冒烟结果 | 未开始 |
| 系统测试执行 | 测试团队 | 第5–10天 | 冒烟通过 | 执行记录与缺陷单 | 未开始 |
| 回归测试 | 测试团队 | 第11–13天 | 缺陷修复完成 | 回归报告 | 未开始 |
| 测试报告与复盘 | 测试负责人A | 第14天 | 回归通过 | 测试报告 | 未开始 |
资源与依赖要写清人员分工、测试环境与数据来源、上下游交付时间点。进度安排标注关键里程碑，如提测日、冒烟通过日、准出评审日。计划变更设置触发条件，例如需求范围变更超过约定比例、提测延迟超过两天、发现阻断性缺陷，触发后由测试负责人评估影响并走审批，更新计划版本并通知相关方。
角色分工与各阶段交付物
策略与计划的制定不是测试团队单独完成的事，需要产品、开发、运维在各自环节提供输入并参与评审。职责清晰，交付物才有质量保证。
| 角色 | 在策略与计划中的职责 | 主要交付物 |
|---|---|---|
| 测试负责人 | 主导风险分析与策略编写，编制计划，组织评审，跟踪准出 | 风险清单、测试策略、测试计划、测试报告 |
| 测试工程师 | 参与风险识别，设计用例，执行测试，提交与跟踪缺陷 | 测试用例、执行记录、缺陷单 |
| 开发 | 提供变更范围与技术风险输入，完成单元测试与缺陷修复 | 变更说明、单元测试结果、修复记录 |
| 产品 | 确认业务目标与需求优先级，参与策略与验收标准评审 | 需求文档、验收标准、评审意见 |
| 运维 | 提供环境与部署支持，参与发布准出确认 | 环境就绪确认、部署记录 |
策略评审由测试负责人组织，产品、开发、架构参与，关注范围是否有依据、层级类型是否有遗漏、准出是否可验证。计划评审由项目团队参与，关注任务是否到人、时间是否可排、依赖与环境是否落实。各阶段交付物要有完成标志：风险清单经评审签字、策略文档版本归档、计划表状态更新、测试报告经准出评审确认。
当风险项、测试任务、用例和准出状态需要在同一处流转时，可以借助测试管理工具承载。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；支持测试计划的规划和执行，并可多维度概览全部测试计划、查看进度；未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转；还支持自动生成测试报告和自定义报告模板。这些能力对应的是计划执行阶段的跟踪与交接，策略文档和风险清单的编写仍以文档评审方式组织。
示例：一个版本迭代的策略与计划如何落地
以下为演示场景，用于说明从风险到策略再到计划的完整链路，数据为示意，不代表真实项目。
场景设定：某电商系统一次版本发布，包含支付流程改造和权限模型调整，同时有报表样式微调和第三方物流接口升级。
风险识别与排序：支付流程改造影响高、概率中，定为高风险；权限模型调整影响高、概率中，定为高风险；物流接口升级影响中、概率中，定为中风险；报表样式微调定为低风险。
据此形成的策略要点：支付模块安排接口集成测试、端到端场景测试、异常分支测试和安全测试，纳入每轮回归；权限模块设计权限矩阵用例和越权测试，安排多角色验收；物流接口做契约测试和异常返回模拟；报表仅做冒烟和界面检查。准出标准定为高危缺陷清零、支付与权限用例执行率100%、回归通过率不低于98%。不测范围写明旧版客户端兼容测试和第三方支付页面内部逻辑。
对应的计划安排：第1–3天完成用例设计与评审，第2–4天准备环境与测试数据，第4天冒烟，第5–10天系统测试执行，第11–13天回归，第14天出报告并复盘。测试团队三人按模块分工，支付与权限各配一名主测，物流与报表由第三人兼顾，预留两天缓冲应对缺陷回归。
执行中的调整与复盘：执行到第7天发现支付回调存在时序缺陷，触发计划变更，追加两天专项验证并顺延回归。复盘时将该缺陷类型补充进风险清单模板，作为下个版本的风险识别输入。
完成检查：策略与计划是否可执行
策略与计划编制完成后，用以下清单逐项核对，全部满足才进入执行。
- 策略目标可衡量，每个目标有对应的验证方式。
- 测试范围有风险清单支撑，高风险项有明确的测试措施。
- 测试层级与类型组合无遗漏，各层入口与退出标准清晰。
- 准入准出标准可验证，缺陷分级与遗留审批方式明确。
- 不测范围已写明理由并经评审确认。
- 计划任务全部到人，每项活动有起止时间和产出物。
- 工作量估算有依据，缓冲时间已设置。
- 环境、数据与上下游依赖已落实并有确认人。
- 关键里程碑明确，计划变更的触发条件与审批方式已约定。
- 计划中的每项活动能追溯到策略中的风险或目标。
- 策略与计划均已评审，版本归档，更新机制已建立。
检查中发现缺项，回到对应步骤补充，而不是在执行中临时补救。策略与计划的价值在于让测试投入有依据、执行有节奏、结果可验证，检查清单正是这一目标的最后一道保障。
常见问题
测试策略多久更新一次，计划又该多久调整？
策略按产品阶段或重大变化修订，例如业务目标调整、架构升级、质量事故之后，平时保持稳定。计划按版本或迭代滚动编制，执行中遇到需求范围变更、提测延迟或阻断性缺陷时调整。判断标准是：策略变化意味着范围和标准变了，计划变化只影响任务和时间安排。策略频繁改动说明风险分析不扎实，计划长期不更新则说明跟踪机制缺失。
团队规模小、没有专职测试负责人时，策略和计划由谁来做？
可以由测试骨干牵头，产品与开发共同参与。策略中的质量目标和准出标准需要产品确认，技术风险与单元测试安排需要开发输入，环境依赖需要运维支持。小团队可以把策略写得精简，保留目标、范围、层级类型、准出和不测范围五部分，计划用一张表覆盖活动、负责人、时间和产出即可。关键是评审环节保留，避免策略只代表测试一方视角。
风险清单做完之后，怎么保证执行阶段不偏离？
把风险项与测试措施、责任人绑定，并在计划中体现为具体活动。执行中定期核对高风险项的措施是否完成、结果是否符合预期；发现新风险时补充清单并评估是否调整计划。准出评审时逐项确认高风险项已覆盖。风险清单如果只停留在文档里，不进入计划和评审，就会与实际执行脱节。
策略和计划需要哪些评审，评审不通过怎么办？
策略评审由测试负责人组织，产品、开发、架构参与，关注范围是否有风险依据、层级与类型是否有遗漏、准出是否可验证。计划评审由项目团队参与，关注任务是否到人、时间是否可排、环境与数据是否落实。评审不通过时记录缺项，回到对应步骤补充后重新评审，不带着未确认的范围或标准进入执行。
测试计划执行中进度落后，应该压缩测试范围还是顺延发布？
先看落后原因和风险分布。如果落后集中在低风险模块，可以缩减其测试深度，保留冒烟与核心路径验证，高风险模块的措施不削减。如果高风险模块本身无法按期完成，应把情况提交准出评审，由产品、开发和测试共同决定顺延发布或分批上线。压缩范围的决定要记录在计划变更中，并说明对风险的影响，避免事后无人知晓。
