敏捷测试策略要回答的核心问题，是测试如何随迭代推进：每个迭代测什么、谁来测、什么时候测、达到什么条件算通过。本文给出一份假设团队的完整示例方案，覆盖测试分层、迭代节奏、准入准出、缺陷分级与回归、环境数据、度量复盘，并逐项说明填写理由与可迁移规律。示例方案中的测试计划、用例与缺陷记录，可以在ONES中承载并与需求和迭代关联。
要点总览（TL;DR）
- 示例方案以两周迭代、12人团队、Web端SaaS为假设背景，覆盖测试分层、迭代节奏、准入准出、缺陷分级与回归、环境数据、度量复盘六部分。
- 测试分层按反馈速度与风险划分：单元与接口测试由开发承担主要责任，UI测试与探索式测试由测试主导，每层都有明确覆盖对象与执行时机。
- 提测准入与迭代准出写成可核验条目，缺陷按影响范围与阻塞程度分级，回归范围由变更影响面推导，减少主观判断。
- 换团队时可照搬分层责任、准入准出结构、缺陷分级逻辑；迭代长度、自动化比例、回归深度需按发布节奏调整。
- 强监管产品、硬件依赖或长周期集成场景需补充追溯证据或改按里程碑组织测试，示例中的团队设定与指标仅用于演示。
示例目标：这份敏捷测试策略要解决什么问题
本文示例设定一个假设团队：产品形态为面向企业用户的Web端SaaS应用，研发团队约12人，其中专职测试2人，开发8人，产品经理与设计师各1人；采用两周一个迭代，迭代末发布到生产环境，紧急修复走独立热修流程。团队已有基础自动化能力，接口自动化覆盖核心链路，UI自动化覆盖少量主流程。以上设定仅用于演示，不代表任何真实客户情况。
这份策略要回答四个问题，也是判断一份敏捷测试策略是否可执行的四个标准：
| 问题 | 策略中对应的内容 | 判断标准 |
|---|---|---|
| 测什么 | 测试分层与各层覆盖对象 | 每类风险都有明确的测试层承接，不出现无人负责的区域 |
| 谁来测 | 各层责任人与协作分工 | 开发、测试、产品在迭代各节点的测试动作清晰可查 |
| 什么时候测 | 迭代内测试节奏与提测节点 | 测试活动与开发节奏对齐，不集中在迭代末尾 |
| 测到什么程度算通过 | 提测准入、迭代准出与缺陷分级 | 通过条件可核验，不依赖个人主观判断 |
需要说明的是，下文方案是示例，用于展示一份策略写完整后是什么样子；其中的数字、角色和节奏都服务于演示，读者应把它当作模板参照，而非经过验证的最佳实践。
完整示例：一个两周迭代的敏捷测试策略方案
测试分层与责任划分
示例团队按“反馈速度与风险覆盖”设置四层测试，每层有明确的覆盖对象和责任人：
| 测试层 | 覆盖对象 | 责任人 | 执行时机 |
|---|---|---|---|
| 单元测试 | 核心业务逻辑、工具函数、边界条件 | 开发 | 编码过程中，随提交运行 |
| 接口测试 | 服务间契约、核心业务链路、异常返回 | 开发编写，测试维护用例集 | 每日构建与提测前 |
| UI测试 | 主流程页面、关键交互路径 | 测试 | 提测后、回归阶段 |
| 探索式测试 | 新功能场景、跨模块组合、易用性问题 | 测试主导，产品参与验收 | 提测后至迭代结束 |
迭代内测试节奏
两周迭代按以下节点安排测试动作，测试活动从需求阶段即开始介入：
- 需求澄清（迭代第1—2天）：测试参与需求评审，输出验收要点与测试风险清单，标记需要提前准备环境或数据的场景。
- 开发中（第3—7天）：开发同步编写单元测试与接口用例；测试编写新功能用例，更新回归用例集，准备测试数据。
- 提测（第8天）：开发提交提测申请，满足准入条件后测试开始执行。
- 测试与修复（第8—11天）：测试执行新功能用例与探索式测试，缺陷当日提交并跟踪修复；开发修复后由测试验证关闭。
- 回归与发布（第12—14天）：执行回归范围，完成准出检查，输出测试报告，随迭代发布。
提测准入与迭代准出条件
| 节点 | 条件 | 不满足时的处理 |
|---|---|---|
| 提测准入 | 需求范围内的功能开发完成；单元测试与接口测试通过；无阻塞级缺陷；提测说明包含变更点与自测结论 | 退回开发，测试不启动正式执行，避免无效等待 |
| 迭代准出 | 新功能用例全部执行完毕；阻塞级与严重级缺陷清零；一般级缺陷有明确处理计划；回归范围内用例通过；测试报告已输出 | 延期发布或缩小发布范围，由产品与测试共同确认 |
缺陷严重程度分级与回归范围
| 级别 | 判定依据 | 处理要求 |
|---|---|---|
| 阻塞级 | 主流程无法走通，或测试无法继续 | 当日修复，修复前暂停相关测试 |
| 严重级 | 核心功能结果错误、数据异常、影响多个用户角色 | 迭代内必须修复，修复后纳入回归 |
| 一般级 | 非核心路径错误、有可接受的替代操作 | 迭代内尽量修复，未修复则记录处理计划 |
| 轻微级 | 文案、样式、体验类问题 | 进入待办池，按优先级排期 |
回归范围由变更影响面推导：本次迭代改动的模块及其直接依赖模块为必回归范围；涉及公共组件、权限或数据结构的改动，扩大到调用方模块；未改动模块按季度做一次全量回归抽查。
测试环境与测试数据
示例团队维护两套环境：集成环境供日常提测与联调使用，每日从主干构建；预发环境与生产配置一致，用于发布前验证。测试数据按场景准备：基础账号与组织数据由测试维护固定数据集，涉及金额、权限等敏感场景使用独立测试租户，避免相互污染；每次迭代开始前检查数据集是否仍满足新功能需要。
迭代度量与复盘
示例团队只跟踪四个指标：提测准入一次通过率、迭代内缺陷发现与修复的分布、回归用例通过率、线上缺陷数量。迭代结束后由测试在复盘会上说明指标变化及原因，重点讨论准入被退回、缺陷集中出现的环节，并据此调整下一迭代的用例范围或节奏安排。
逐项解释：每个字段为什么这样填
测试分层按风险与反馈速度划分。单元测试运行最快、定位最准，适合承接逻辑正确性；接口测试介于逻辑与界面之间，能覆盖服务间契约和异常路径；UI测试运行慢、维护成本高，只覆盖主流程；探索式测试补足脚本难以覆盖的场景组合与体验问题。这样分层后，越靠下的层承担越多确定性检查，越靠上的层把人力留给需要判断力的测试。
准入准出条件与迭代节奏对齐。提测准入设在迭代中段，是为了让测试有足够时间执行，而不是在最后两天集中挤压。准入条件写成可核验的条目（功能完成、自动化通过、无阻塞缺陷），使“能不能提测”有共同依据。准出条件区分缺陷级别，阻塞级与严重级清零保证发布底线，一般级允许带计划发布，避免因小问题无限延期。
缺陷分级按影响范围与阻塞程度，而非主观严重感。“我觉得这个很严重”难以在团队间对齐。示例用两个客观维度判定：是否阻塞测试或主流程，影响的是单点还是多角色、多数据。级别直接对应处理时限和是否纳入回归，使缺陷流转有统一规则。
回归范围由变更影响面推导。全量回归在两周迭代里成本过高，只测改动点又容易漏掉依赖影响。示例以“改动模块＋直接依赖＋公共组件调用方”划定范围，把回归深度与变更风险挂钩，未改动部分用周期性抽查兜底。
度量项控制在少数几个可观察指标。指标过多会变成填表负担，且难以指导行动。示例选取的四个指标分别对应准入质量、迭代内缺陷节奏、回归有效性和发布后质量，每个都能在复盘中引出具体改进动作。
可迁移规律：换团队时哪些能照搬、哪些要改
示例方案中有一部分是通用骨架，换团队后基本可以直接沿用；另一部分与团队节奏强相关，需要按自身情况调整。
| 内容 | 处理方式 | 说明 |
|---|---|---|
| 分层责任划分 | 可照搬 | 按反馈速度分层、明确每层责任人的思路适用于多数产品团队 |
| 准入准出条件结构 | 可照搬 | 条件条目可按团队实际增删，但“可核验、有退回处理”的结构保留 |
| 缺陷分级逻辑 | 可照搬 | 按影响范围与阻塞程度判定，级别数量可按团队习惯设为三级或四级 |
| 迭代长度与测试节点 | 需调整 | 一周迭代需压缩澄清与执行窗口，测试左移程度更高；三周以上迭代可增加中期回归 |
| 自动化比例 | 需调整 | 自动化基础薄弱的团队先保证接口层覆盖，UI自动化按主流程逐步补充 |
| 回归深度 | 需调整 | 高频发布团队需要更细的变更影响分析，低频发布团队可保留更完整的回归集 |
三种典型情形的调整方向：单人测试团队应压缩分层，把接口测试与探索式测试作为主力，UI测试只保留发布前冒烟；多团队协同场景需要先约定跨团队的接口契约测试责任和缺陷交接规则，再谈各团队内部节奏；每日或每周高频发布的团队，应把回归范围判定做成发布检查单，由变更记录自动带出必测项，减少人工判断。
适用边界：这份示例在什么情况下不适用
示例方案面向常规业务功能的迭代测试。以下情形需要补充或替换相应内容：
- 强监管或安全关键类产品：医疗、金融、工业控制等领域通常对测试证据、可追溯性和独立验证有额外要求，示例中的准入准出条件不足以覆盖合规审计需要，应补充需求到用例到结果的追溯记录和评审留痕。
- 硬件依赖或长周期集成场景：需要真实设备、外部系统联调或长周期稳定性验证的项目，测试周期难以压缩进两周迭代，应按集成里程碑组织测试，迭代内只保留可独立验证的部分。
- 示例未覆盖的内容：具体测试脚本与自动化代码实现、攻击技术与安全测试细节、源码级实现方案，以及单份需求文档的质量评审，均不在本文范围内，需要参考对应主题的方法。
此外，示例中的团队规模、角色配置和指标数值仅用于演示，直接套用时应以本团队的实际人员、发布频率和风险分布为准重新设定。
把示例方案落到协作工具里
示例方案要真正执行，需要让测试分层、准入准出、缺陷分级和回归范围在团队日常使用的工具中有承载位置，而不是停留在文档里。ONES测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环，适合把上述方案中的管理动作固定下来。
具体承载方式可以按以下流程组织：测试在需求澄清阶段编写用例并组织进用例库，用例属性可按业务场景自定义，便于标记所属测试层与回归范围；每个迭代建立测试计划并与迭代关联，把用例分配给执行人，测试负责人通过多维度视图查看全部计划进度。提测准入与准出条件以工作项状态流转和检查项体现：开发提交提测时更新状态并附自测结论，测试确认条件满足后进入执行；准出时核对缺陷状态与回归结果再流转到发布。执行中未通过的用例可快速创建缺陷任务，缺陷在测试与研发之间流转，严重程度与回归范围作为字段记录，便于筛选和统计。迭代结束时，测试报告可自动生成，缺陷分布统计帮助复盘定位问题集中环节；报告模板支持自定义组装，以适配不同业务场景。
这样安排后，示例方案中的每个字段都能对应到具体的工作项、状态或报告，策略从一份文档变成团队每天可查、可执行、可复盘的协作规则。
常见问题
团队只有一名测试人员，这份示例方案还能用吗？
可以用，但需要压缩分层。单人测试团队难以同时维护UI自动化和完整回归集，建议把接口测试与探索式测试作为主力：接口用例由开发编写、测试维护用例集，UI测试只保留发布前的冒烟路径。准入准出条件保留结构，条目按实际可核验的范围精简，避免设置无人执行的检查项。
迭代周期从两周改为一周，测试节奏要怎么调？
一周迭代里，需求澄清与用例编写需要更早介入，部分用例可在需求评审后即开始设计；提测节点相应前移，回归范围要更依赖变更影响分析而非全量执行。示例中的“第8天提测”这类节点需整体压缩，测试左移程度更高。若团队自动化基础薄弱，可先保证接口层覆盖，再逐步补充UI主流程。
准入条件被频繁退回，是条件定得太严还是开发自测不足？
先看退回原因分布：若集中在自动化未通过或阻塞缺陷，说明开发自测环节需要加强，可在提测说明中要求附自测结论；若集中在需求理解偏差，说明澄清阶段验收要点没有对齐。准入条件本身应保持可核验，调整方向是补充前置动作，而非放宽条目。复盘时把退回原因作为固定讨论项，能帮助定位是流程问题还是个别情况。
示例中的缺陷分级和回归范围，在ONES里怎么记录和统计？
ONES测试管理支持未通过的用例快速创建缺陷任务，缺陷任务可在测试与研发团队间流转，并提供项目缺陷分布统计。严重程度与回归范围可以作为缺陷任务的字段记录，便于筛选和汇总。提测准入与准出的具体检查项配置方式，建议结合团队实际工作项状态设计，以工具中可用的状态流转和字段为准。
强监管产品直接套用这份示例会缺什么？
主要缺测试证据的追溯与留痕。医疗、金融、工业控制等领域通常要求需求到用例到执行结果可追溯，并有评审与独立验证记录。示例中的准入准出条件只覆盖功能与缺陷状态，需要补充追溯记录、评审留痕和报告归档要求，具体口径以所在行业的合规要求为准。
