测试策略与计划解决的是“测什么、测到什么程度、由谁在什么时间完成”的问题。有效的做法是先写清质量目标与验收口径，再按风险排序划定范围与深度，把范围分配到测试层级和类型，最后落实为含资源、进度、准入准出的计划表，并在执行中跟踪调整。以下按这四步展开，附计划表模板、角色分工、完整示例和完成检查清单。
要点总览（TL;DR）
- 测试策略与计划从质量目标和验收口径开始，把业务目标转成可验证、可判断的完成标准，再据此取舍范围与资源。
- 测试范围与深度由风险决定：按业务影响、变更频率、复杂度和历史缺陷评级，高风险区域投入更完整的场景、异常、非功能与回归验证。
- 把范围分配到单元、集成、系统、验收等层级，并组织功能、非功能、静态与维护测试，避免同一问题在多个层级重复验证。
- 测试计划表需写明范围、层级类型、负责人、环境数据、时间窗、前置依赖与准入准出条件，并与迭代或版本节奏衔接。
- 执行阶段跟踪执行率、缺陷趋势与阻塞项，按触发条件调整计划，准出前用完成检查清单逐项核对。
先定测试目标与验收口径
测试策略的起点是目标，测试目标从业务目标和需求中提炼。业务目标说明这次交付要解决什么问题，需求说明系统应具备什么行为，测试目标则把两者转成“需要被验证的质量主张”。例如业务目标是降低订单错发率，需求中包含地址校验与库存锁定规则，测试目标就可以写成“验证地址异常与库存并发场景下订单不被错误提交”。目标写得越具体，后续范围取舍越有依据。
验收口径回答“怎样算通过”。它需要可衡量或至少可判断，避免“体验良好”“基本可用”这类无法核对的表述。常见的验收口径包括：关键业务流程在约定场景下全部通过；缺陷收敛到约定等级和数量；性能指标达到约定阈值；回归范围覆盖全部高风险模块且无新增严重缺陷。验收口径同时是完成定义的一部分，应与产品、开发在计划阶段达成一致，而不是测试结束时再讨论。
本节的可交付物是测试目标与验收口径清单，建议包含四列：目标编号、对应业务目标或需求、验证方式、通过标准。清单条目控制在可管理的数量，每条都能对应到后续的风险项和测试活动。
按风险排序确定测试范围与深度
测试资源有限，范围与深度应由风险决定。风险识别通常看四个维度：业务影响，即该功能失效对用户、收入、合规的损害程度；变更频率，即近期改动多、需求迭代快的模块；复杂度，即逻辑分支多、依赖多、并发或数据一致性要求高的部分；历史缺陷，即过去缺陷集中或反复出问题的区域。四个维度可以分别打高、中、低，再合成风险等级。
风险等级直接对应测试深度。高风险区域安排更完整的场景覆盖、边界与异常测试、必要的非功能验证和回归；中风险区域覆盖主流程与关键分支；低风险区域以冒烟和基本功能确认为主。这样做的目的是把人力投向失效代价最高的地方，而不是平均用力。
| 风险等级 | 判定参考 | 测试深度 | 投入倾斜 |
|---|---|---|---|
| 高 | 核心业务链路、近期大改、逻辑复杂、历史缺陷多 | 主流程+异常+边界+非功能+回归 | 优先分配资深测试人员与独立环境 |
| 中 | 一般业务功能、改动适中 | 主流程+关键分支 | 常规人力，按迭代节奏安排 |
| 低 | 展示类、低频使用、改动小 | 冒烟与基本功能确认 | 合并执行，减少重复投入 |
风险清单应随需求变更更新。每次迭代开始前复核一次，新增或变更的需求重新评级，避免计划沿用上一轮的判断。风险清单与测试深度对照表是本节的主要产出，也是后续分配测试层级和资源的输入。
把范围拆到测试层级与测试类型
范围确定后，需要回答“在哪一层测、用哪类测试测”。测试层级一般分为单元测试、集成测试、系统测试和验收测试。单元测试由开发负责，验证函数与模块内部逻辑；集成测试验证模块之间、服务与外部依赖之间的交互；系统测试从整体验证端到端业务流程；验收测试由产品与业务方参与，确认需求被满足。层级划分的意义在于让不同问题在最合适的层次暴露，减少重复验证。
测试类型按关注点组织。功能测试验证系统行为是否符合需求；非功能测试覆盖性能、安全、兼容性、可用性等质量属性，规划时要明确指标、场景和数据条件，例如并发用户数、响应时间阈值、目标浏览器与设备范围。静态测试包括需求评审、设计评审和代码审查，能在早期发现缺陷，成本低于运行期测试；维护测试针对上线后的缺陷修复和回归，需要明确回归范围与触发条件。
| 测试层级/类型 | 主要职责 | 负责人 | 规划要点 |
|---|---|---|---|
| 单元测试 | 模块内部逻辑正确性 | 开发 | 覆盖率目标、关键分支 |
| 集成测试 | 模块与依赖间交互 | 开发/测试 | 接口契约、异常与超时 |
| 系统测试 | 端到端业务流程 | 测试 | 高风险场景优先 |
| 验收测试 | 需求满足确认 | 产品/业务 | 验收口径与数据准备 |
| 非功能测试 | 性能、安全、兼容性 | 测试/专项人员 | 指标、场景、环境条件 |
| 静态测试 | 需求、设计、代码审查 | 产品/开发/测试 | 评审节点与检查项 |
| 维护测试 | 缺陷修复与回归 | 测试 | 回归范围与触发条件 |
分配时遵循一条原则：能用低层级发现的问题不放到高层级重复验证，高风险区域在多个层级都应有覆盖。产出物是测试层级与类型分配表，把风险清单中的每一项映射到具体层级和类型，并标注负责人。
测试计划表怎么写：资源、进度与准入准出
测试计划表把策略转成可执行的安排。关键字段包括：测试范围（对应风险清单条目）、测试层级与类型、负责人、所需环境与数据、时间窗、前置依赖、准入条件、准出条件、当前状态。范围字段直接引用风险编号，保证计划与风险排序一致；环境字段写明版本、配置和数据准备责任人，避免执行时才发现环境不可用。
准入条件规定“什么情况下可以开始测试”，例如需求与设计评审通过、开发自测完成、构建版本可部署、测试环境就绪。准出条件规定“什么情况下可以结束测试”，例如计划内用例执行完成、严重与主要缺陷关闭或经评估接受、回归通过、验收口径逐条确认。准入准出条件写在计划表里，评审时共同确认，执行中按条件判断，减少口头约定带来的争议。
计划要与迭代节奏衔接。按迭代组织的团队，可以把测试活动拆到需求评审、开发联调、系统测试、验收、上线回归几个节点，每个节点标注起止时间和负责人；按版本发布的团队，则以版本里程碑为锚点倒排测试时间窗。无论哪种节奏，计划表都应保留调整记录，说明变更原因和影响范围。
角色分工与各阶段交付物
测试负责人统筹策略与计划：组织风险识别、编写测试策略说明与计划表、协调环境与人力、跟踪执行并主持准出评审。开发负责单元测试与集成测试的设计执行，参与风险识别中的复杂度与历史缺陷评估，配合缺陷定位与修复。产品负责确认业务目标与验收口径，参与验收测试，对范围取舍中的业务优先级给出判断。
| 阶段 | 测试负责人 | 开发 | 产品 | 交付物 |
|---|---|---|---|---|
| 目标与口径 | 组织编写 | 提供技术约束 | 确认业务目标与验收标准 | 测试目标与验收口径清单 |
| 风险排序 | 汇总评级 | 评估复杂度与历史缺陷 | 评估业务影响 | 风险清单与深度对照表 |
| 层级与类型分配 | 制定分配表 | 承担单元与集成测试 | 参与验收测试安排 | 测试层级与类型分配表 |
| 计划编写 | 编写计划表 | 确认自测与环境依赖 | 确认验收时间窗 | 测试计划表 |
| 执行与跟踪 | 跟踪进度与缺陷 | 修复缺陷 | 参与验收与范围调整 | 执行记录、缺陷清单 |
| 准出评审 | 主持评审 | 提供修复说明 | 确认验收结论 | 准出结论与完成检查表 |
交接点集中在三处：计划评审时确认范围、资源与准入准出；执行中每日或每轮同步缺陷与阻塞；准出评审时对照验收口径逐条确认。每个交接点都应有明确记录，便于后续追溯。
示例：一个迭代的测试策略与计划
以下为演示情景，用于说明方法如何串联，不代表真实项目数据。某团队本迭代要上线订单地址校验与库存锁定功能，业务目标是降低错发率。测试目标定为：验证地址异常输入与库存并发场景下订单不被错误提交；验收口径为关键场景全部通过、无新增严重缺陷、下单主流程回归通过。
风险排序结果：库存并发扣减评为高风险，原因是逻辑复杂、涉及数据一致性且历史缺陷集中；地址校验评为中风险，改动明确但影响面有限；订单列表展示评为低风险。据此，高风险区域安排并发场景、异常与边界测试，并在集成层和系统层双重覆盖；中风险覆盖主流程与常见异常输入；低风险仅做冒烟确认。
计划表填写示例：范围为库存并发扣减，层级为集成与系统测试，负责人为测试A，环境为预发布环境加并发压测数据，时间窗为迭代第6至第8天，准入条件为接口联调完成且自测通过，准出条件为并发场景全部通过且无严重缺陷。地址校验安排在第5至第6天，订单列表冒烟安排在第8天。执行中若并发测试发现数据一致性问题，触发计划调整：延长该区域时间窗，压缩低风险区域投入，并同步产品确认是否影响上线范围。
执行跟踪、调整与完成检查
执行跟踪看几个关键指标：计划用例执行率、通过率、缺陷发现与关闭趋势、严重缺陷数量、阻塞项数量、环境可用情况。跟踪的目的是尽早发现偏差，例如执行率落后于时间窗、缺陷集中在某个模块、环境反复不可用。发现偏差后按触发条件调整计划：范围变更导致风险重评、严重缺陷未收敛、环境或依赖延迟、时间窗被压缩。调整时记录原因、影响范围和新的准出判断，避免计划与实际脱节。
完成检查在准出评审前逐项核对，确认测试工作可以结束。检查清单如下：
- 测试目标与验收口径逐条确认，结论有记录；
- 高风险区域按计划深度完成，覆盖场景无遗漏；
- 计划内用例执行完成，未执行项有说明和风险评估；
- 严重与主要缺陷关闭，遗留缺陷经产品确认接受；
- 回归范围覆盖高风险模块，回归结果通过；
- 非功能指标达到约定阈值，测试环境与数据条件已记录；
- 准入准出条件逐项核对，准出结论由测试负责人与产品共同确认。
当测试计划、缺陷和执行记录分散在文档与表格中时，跟踪成本会明显上升。ONES 可以把测试计划作为工作项管理，关联需求、缺陷与版本，缺陷状态和严重等级在执行过程中持续更新，准出评审时直接查看计划完成情况与缺陷收敛趋势，让策略、计划与执行记录保持在同一处可追溯。是否引入工具承载，取决于团队规模与协作复杂度；小团队用表格加定期同步也能完成同样的闭环。
常见问题
测试策略和测试计划有什么区别，需要分别写吗？
测试策略回答“测什么、测到什么程度、为什么这样取舍”，内容包括质量目标、风险排序、测试层级与类型的选择原则；测试计划回答“谁在什么时间、用什么环境、按什么条件开始和结束”，落点是范围条目、负责人、时间窗和准入准出。两者可以合并在同一份文档中，但内容要分开写清楚：策略部分相对稳定，跨迭代沿用并按风险变化修订；计划部分按迭代或版本单独编写。团队规模较小时，用一页策略说明加一张计划表即可，不必追求文档厚度。
需求频繁变更时，风险排序和计划怎么保持有效？
把风险清单和计划表做成可更新的活文档，而不是一次评完就归档。每次需求变更时做三件事：判断变更是否影响已有风险项的评级，新增需求补入风险清单并重新评级，检查计划表中的范围、时间窗和环境依赖是否需要调整。变更导致高风险区域扩大时，优先保障该区域的测试深度，压缩低风险区域的投入，并把取舍结论同步给产品和开发。计划表保留变更记录，写明原因和影响范围，准出评审时据此判断测试是否充分。
非功能测试在计划里怎么安排，容易漏掉什么？
非功能测试要在计划阶段就明确指标、场景、数据条件和环境，例如并发用户数、响应时间阈值、目标浏览器与设备范围、安全测试的覆盖边界。容易漏掉的是环境与数据准备：性能测试需要接近生产的配置和足量数据，兼容性测试需要目标设备清单，这些依赖要写进计划表并指定责任人。另一个常见问题是把非功能测试全部压到系统测试后期，一旦指标不达标，修复和复测时间不足。建议在高风险模块的集成阶段就安排初步验证，系统测试阶段做完整确认。
小团队人手有限，测试策略与计划可以简化到什么程度？
可以保留核心动作、压缩文档形式。目标与验收口径写成几条可判断的标准；风险清单只列高、中、低三档并注明理由；计划表保留范围、负责人、时间窗、准入准出四类关键字段；完成检查用一张短清单在准出前逐项确认。简化的是记录载体，风险排序、层级分配和准出判断这些动作仍然要做，否则范围取舍和完成判断会失去依据。团队规模扩大或协作方增多时，再逐步补充环境管理、变更记录和缺陷趋势跟踪。
测试计划执行中严重缺陷迟迟不收敛，应该怎么处理？
先确认缺陷的性质和影响范围：是否集中在高风险模块、是否涉及数据一致性或核心链路、修复方案是否明确。然后按触发条件调整计划：延长相关区域的测试时间窗，暂缓低风险区域的验证，把人力集中到缺陷验证与回归；同时同步产品评估是否影响上线范围或需要分批发布。若修复周期超出迭代窗口，需要在准出评审中明确遗留缺陷的等级、影响和接受方，并记录在完成检查表中。调整的原因和结论要留痕，便于后续复盘。
