测试策略与计划解决两个不同层面的问题：策略回答“测什么、测到什么程度、风险如何覆盖”，计划回答“谁在什么时间用什么环境做到什么标准”。本文按六步流程说明如何从质量目标推导到可执行的排期，并给出各类测试的规划取舍、角色分工、示例片段和发布前检查清单。文中不涉及自动化脚本编写、安全攻击技术细节，也不讨论单份需求文档的质量评审。
要点总览（TL;DR）
- 策略与计划分工明确：策略回答测什么、测到什么程度、风险如何覆盖，计划回答谁在什么时间用什么环境做到什么标准，先定策略再排计划。
- 制定主线分六步：明确质量目标与业务风险、确定范围与分层比例、编排阶段与环境资源、定义准入准出与缺陷规则、落实角色分工与交付物、评审发布并约定滚动更新。
- 各类测试按风险等级和变更影响面分配深度，接口层承担主要覆盖量，端到端只保留核心链路，性能、兼容、安全测试提前排入版本计划。
- 角色与交付物一一对应：测试负责人主导策略与计划，测试工程师编写用例范围说明，开发确认分层承诺，产品确认质量目标，运维保障环境。
- 发布前用检查清单核对目标可追溯、范围写明、准出可判定、资源落实、职责明确、更新机制约定，存在阻断项时不宜发布执行。
先定策略再排计划：核心答案与操作步骤
策略与计划是上下游关系，不能合并成一份文档草草了事。策略确定测试对象、覆盖深度和风险应对方式，相对稳定，随版本或重大需求变化而修订；计划把策略落到具体迭代或发布周期，明确时间、人力、环境和准出标准，随排期滚动更新。先有策略，计划才有取舍依据；只有计划没有策略，容易出现“什么都测一点、关键风险没人管”的局面。
以下六步构成一条完整的制定主线，每步都给出输入、动作、输出和完成标志，可以按顺序执行，也可以在已有文档上逐项补齐。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 明确质量目标与业务风险 | 产品目标、需求清单、历史缺陷与线上事故记录、业务方关注点 | 列出本版本必须保障的质量属性（如交易正确性、页面响应时间、数据一致性），按发生概率和影响程度给风险排序 | 质量目标清单、风险登记表（含等级） | 每条质量目标都能对应至少一个风险项，风险项有明确等级和责任人 |
| 2. 确定测试范围与分层比例 | 风险登记表、系统架构与模块划分、变更影响分析 | 划定测与不测的边界，按单元、接口、界面、端到端四层分配投入比例，说明每层覆盖哪些风险 | 范围说明（含不测范围）、分层比例说明 | 高风险项均有对应测试层承接，不测范围写明理由 |
| 3. 编排阶段、里程碑与环境资源 | 范围与分层结论、研发排期、环境与数据现状 | 划分测试阶段（如冒烟、系统、回归、验收），设定里程碑时间点，列出所需环境、测试数据和工具资源 | 阶段计划表、环境清单、资源需求 | 每个阶段有起止时间和责任环境，环境可用时间早于对应测试开始时间 |
| 4. 定义准入准出与缺陷处理规则 | 阶段计划、质量目标、历史缺陷数据 | 为每个阶段写明进入条件（如冒烟通过率、提测文档齐全）和退出条件（如用例执行率、遗留缺陷等级分布），约定缺陷分级、修复时限和复测流程 | 准入准出标准、缺陷处理规则 | 每条标准可判定通过或不通过，不存在“基本完成”这类模糊表述 |
| 5. 落实角色分工与交付物 | 准出标准、团队人员构成 | 把编写、评审、执行、环境保障等职责分配到具体角色，列出各阶段交付物及提交时间 | 角色职责表、交付物清单 | 每项交付物有唯一负责人和评审人，无职责悬空项 |
| 6. 评审发布与滚动更新 | 策略与计划初稿、评审意见 | 组织产品、开发、测试、运维共同评审，确认后发布；约定需求变更、风险升级、排期调整时的更新触发条件和更新方式 | 评审记录、发布版本、更新机制说明 | 各方确认签字或书面认可，更新触发条件写入文档 |
六步中最容易被跳过的是第一步和第四步。质量目标模糊会导致范围无限扩张，准出标准模糊会导致“测到什么时候算完”反复扯皮。建议把这两步的产出作为评审重点，其余步骤围绕它们展开。
各类测试如何规划：范围、深度与分层安排
测试类型的规划依据是风险等级和变更影响面，而非平均用力。同一版本内，核心交易链路的接口测试可以做深做全，边缘配置页面做冒烟级覆盖即可。判断深度时可以问三个问题：该模块本次改动多大、出问题后影响多少用户或多少资金、历史上该模块缺陷密度如何。三个问题答案都指向高风险的，深度和频率都应提高。
测试分层解决的是“在哪一层发现缺陷成本最低”的问题。单元测试由开发负责，覆盖核心逻辑与边界条件；接口测试覆盖服务间契约与数据流转，是多数业务系统投入产出比最高的一层；界面测试覆盖关键用户路径和交互；端到端测试只保留少量核心场景，用于验证整体链路。分层比例没有统一数值，常见做法是接口层承担主要覆盖量，端到端控制在核心链路范围内，避免端到端用例膨胀导致维护成本失控。
| 测试类型 | 触发条件 | 深度安排 | 负责人 | 主要产出 |
|---|---|---|---|---|
| 功能测试 | 每个有需求变更的版本 | 核心功能全路径覆盖，次要功能按风险抽样 | 测试工程师 | 功能用例范围说明、执行记录 |
| 接口测试 | 服务接口新增或变更、上下游依赖调整 | 核心接口覆盖正常、异常与边界入参，契约变更需全量回归 | 测试工程师，开发配合提供契约 | 接口用例集、契约核对记录 |
| 性能测试 | 关键链路逻辑变更、数据量级变化、大促或上线前容量评估 | 按业务峰值设定目标，覆盖基准、负载与稳定性场景 | 性能测试工程师 | 性能方案、压测报告与结论 |
| 兼容性测试 | 前端框架升级、目标终端或浏览器范围变化 | 按用户占比选取主流终端组合，覆盖关键页面 | 测试工程师 | 兼容矩阵、问题清单 |
| 安全测试 | 涉及认证授权、支付、个人信息处理的变更，或按合规周期安排 | 覆盖权限校验、输入校验、敏感数据暴露等检查项，深度测试按需安排 | 安全测试人员或外部评估方 | 安全检查记录、风险项与修复确认 |
| 回归测试 | 每次提测与发布前 | 基于变更影响分析选取关联模块，核心链路必测，其余按风险抽样 | 测试工程师 | 回归范围清单、执行结果 |
回归范围的选择建议以“变更影响链”为依据：从改动点出发，沿调用关系和数据流向找出受影响模块，再叠加历史缺陷高发区。全量回归只在版本跨度大或架构调整时采用，日常迭代用影响分析缩小范围，可以显著缩短回归周期。性能、兼容、安全测试的规划时点应提前到版本排期阶段，这类测试需要独立环境和较长时间窗口，临时插入往往挤占功能测试时间。
角色及交付物：谁写、谁评审、谁执行
策略与计划的制定涉及多个角色，职责不清最常见的后果是文档写完没人认、准出标准没人守。基本分工是：测试负责人主导策略编写与整体计划，对质量目标和准出标准负责；测试工程师参与范围与用例范围说明的编写，负责执行与结果反馈；开发负责人确认分层安排和单元、接口测试的覆盖承诺，并提供变更影响信息；产品负责人确认质量目标和验收标准，参与策略评审；运维负责环境与数据准备，确认环境可用时间。
| 交付物 | 编写责任 | 评审责任 | 执行/维护责任 | 提交时点 |
|---|---|---|---|---|
| 测试策略文档 | 测试负责人 | 产品、开发、运维负责人共同评审 | 测试负责人维护，版本变更时修订 | 版本启动前 |
| 测试计划 | 测试负责人或模块测试骨干 | 测试负责人审核，项目经理确认排期 | 测试工程师按计划执行 | 提测前，随排期滚动更新 |
| 用例范围说明 | 测试工程师 | 测试负责人评审，产品确认验收覆盖 | 测试工程师执行并更新 | 提测前 |
| 环境清单 | 测试负责人汇总，运维提供环境信息 | 运维确认可用性 | 运维保障，测试反馈异常 | 阶段开始前 |
| 风险登记表 | 测试负责人 | 策略评审时共同确认 | 各风险责任人跟踪关闭 | 随策略同步发布，持续更新 |
评审时点建议设两个：策略评审放在版本启动前，重点确认质量目标、风险等级和分层安排；计划评审放在提测前，重点确认时间、环境、人力和准出标准。签核方式可以是会议纪要加文档确认，关键是留下可追溯的记录，后续出现范围争议时有据可查。
当策略、计划、用例范围和环境信息分散在多个文档和表格中时，版本对齐容易出错。ONES 测试管理可以把测试计划与需求、迭代关联，用例范围与执行结果在同一处记录，评审意见随工作项流转，便于在需求变更时快速定位受影响的计划与用例。对于需要跨角色确认准出标准的团队，这种关联能减少“文档是最新的、执行用的是旧版”这类问题。
示例：一个迭代的测试策略与计划片段
以下示例为演示情景，假设某电商系统进行一个两迭代周期的版本开发，涉及订单结算逻辑调整和优惠券规则新增，团队规模与具体排期按实际情况替换。
策略部分写法：
- 质量目标：结算金额计算准确无误；优惠券叠加规则符合产品定义；结算页在业务峰值流量下响应时间满足既定目标。
- 风险登记：结算逻辑变更影响资金准确性，定为高等级；优惠券规则组合多、边界复杂，定为高等级；结算页样式调整影响面小，定为低等级。
- 范围与分层：结算与优惠券核心逻辑由单元测试和接口测试重点覆盖；结算页关键路径做界面测试；端到端只保留“下单—支付—结算”一条主链路；历史订单查询等未改动模块不纳入本次功能测试范围，发布前做冒烟级回归。
- 不测范围：后台运营配置页面的视觉细节、非目标浏览器的兼容性。
计划部分写法：
- 阶段安排：第一迭代完成接口测试与单元测试覆盖，第二迭代前两周完成功能测试与集成验证，最后一周完成回归、性能验证与验收。
- 环境与人力：结算相关测试使用独立测试环境，数据由运维在第一迭代结束前准备完毕；接口测试由两名测试工程师承担，性能验证安排一名性能测试人员，安全测试按合规要求安排检查。
- 准入准出：提测准入要求冒烟用例通过率达到约定比例、接口文档更新完毕；退出标准为核心用例全部执行通过、高等级缺陷全部关闭、遗留缺陷有明确处理计划并经产品确认。
示例中的取舍理由值得注意：把资源集中在资金准确性和规则复杂度两个高风险点上，对低风险的样式调整只做冒烟覆盖；性能验证提前排入计划而不是上线前临时补做；不测范围明确写出，避免评审时反复讨论。
完成检查：发布前逐项核对
策略与计划达到可执行状态，可以用以下清单逐项核对。每项给出通过标准和阻断项，存在阻断项时不宜发布执行。
| 检查项 | 通过标准 | 阻断项 |
|---|---|---|
| 目标与风险可追溯 | 每条质量目标和风险项都能对应到具体测试类型或测试活动 | 存在高等级风险无任何测试活动承接 |
| 范围写明 | 测与不测的范围均有文字说明，不测范围给出理由 | 范围描述只有“全面测试”等笼统表述 |
| 准入准出可判定 | 每个阶段的进入和退出条件均为可量化或可判定的表述 | 退出条件依赖主观判断且无确认人 |
| 资源落实 | 环境、测试数据、人力均有明确提供方和可用时间 | 关键环境无提供方或可用时间晚于测试开始时间 |
| 角色与交付物明确 | 每项交付物有唯一编写人和评审人，执行责任到人 | 关键交付物无评审人或多人共同负责且未区分主次 |
| 更新机制约定 | 写明需求变更、风险升级、排期调整时的更新触发条件和更新方式 | 文档无版本记录和更新责任人 |
核对完成后，建议把清单与策略、计划一并归档，作为后续版本修订的基线。版本执行过程中若触发更新条件，按约定方式修订并记录变更原因，使策略与计划始终与当前风险和排期保持一致。
常见问题
策略文档和测试计划应该多久更新一次？
更新频率由触发条件决定，而非固定周期。策略相对稳定，通常在版本启动前或重大需求、架构调整时修订；计划随排期滚动更新，需求变更、风险升级、环境或人力变化时即时调整。建议在文档中写明更新触发条件和更新责任人，并保留版本记录，使执行方始终使用最新版本。
小团队人手有限，六步流程能否简化？
可以合并步骤，但不宜省略关键产出。常见做法是把质量目标与风险登记合并为一份简短清单，把角色分工并入计划文档，评审与计划确认一次会议完成。需要保留的是风险与测试活动的对应关系、可判定的准出标准、环境与人力落实这三项，它们直接决定计划能否执行。团队规模越小，越需要把不测范围写清楚，避免范围随讨论不断扩张。
需求在迭代中途变更，已经评审过的计划怎么处理？
先判断变更是否影响已识别的高等级风险或准出标准。若影响，按约定的更新机制修订范围、用例范围说明和排期，并记录变更原因；若不影响，在计划中登记变更即可，不必整体重排。关键是变更后重新确认受影响的测试活动是否仍有人力和环境承接，避免计划名义上更新、执行仍按旧版进行。
性能、兼容、安全测试没有独立环境怎么办？
这类测试对环境和时间窗口要求较高，规划阶段就应把环境需求列入清单，与运维确认可用时间，并尽量安排在功能测试高峰之前或之后错峰执行。若确实无法获得独立环境，可缩小验证范围，优先覆盖关键链路和已知高风险点，同时在风险登记表中记录环境限制带来的残余风险，由相关责任人确认接受。
准出标准里的遗留缺陷如何处理才算可接受？
可接受与否取决于缺陷等级分布和业务影响，而非单纯数量。常见做法是：高等级缺陷必须全部关闭；中等级缺陷需有明确修复计划和责任人，并经产品负责人确认；低等级缺陷可带入下个版本，但需登记跟踪。准出评审时应逐条确认遗留缺陷的影响范围和规避措施，形成书面结论，避免发布后责任不清。
