敏捷测试策略要落到一个迭代里，关键是写清楚测什么、测到哪一层、谁来测、何时算通过。本文用一个假设的“订单优惠券”两周迭代，给出一份可直接对照填写的完整策略示例，逐项解释风险排序、层级分工和准入准出条件的填写依据，并说明换迭代时哪些字段保留、哪些需要改写。示例为演示情景，不代表真实客户案例。
要点总览（TL;DR）
- 示例以假设的“订单优惠券”两周迭代为背景，给出覆盖测试目标、成功标准、风险清单、层级分工、类型取舍、环境数据、人员安排、准入准出的完整填写样例。
- 风险排序决定投入分配：资金相关的计算与叠加退款组合列为P1，前移到单元与接口自动化；展示文案类P3只做基本检查。
- 测试层级按验证成本与发现时机分工：纯逻辑放单元测试，服务端行为放接口测试，跨页面状态与组合场景放界面和探索式测试。
- 换迭代时保留八个固定字段的骨架，替换风险清单、类型取舍和人员安排；迭代结束用实际缺陷对照风险排序，把结论带入下次填写。
- 示例适用于两周迭代、单一需求主题、常规发布节奏；人力变化、发布频率提高或合规要求较高时需要改写。
示例目标：这份敏捷测试策略要解决什么问题
先设定示例情景：某电商团队采用两周一个迭代的节奏，本迭代的需求主题是“订单优惠券”，包含优惠券领取、下单抵扣、叠加规则、过期与退款返还等改动。参与角色包括产品经理、开发、测试和运维支持人员，测试人力为两名测试工程师，其中一人兼职自动化维护。这个设定只用于演示填写方式，团队规模、系统架构和业务量均为假设。
这份策略要回答四个规划问题。第一，测什么：本迭代哪些改动和受影响范围需要验证。第二，测到哪一层：哪些逻辑靠单元测试和接口测试兜住，哪些必须走界面和探索式测试。第三，谁来测：开发、测试、产品各自承担哪些验证动作。第四，何时算通过：进入测试和结束测试分别需要满足什么可判断的条件。
需要区分的是，策略文档回答“怎么规划测试”，测试用例和自动化脚本回答“具体怎么执行”。示例中的风险等级、人力数字和时间安排都是演示值，真实项目应结合自身缺陷历史、需求复杂度和发布要求重新评估，不能直接照搬。
完整示例：订单优惠券迭代的敏捷测试策略
下表是一份填写完成的策略样例，覆盖目标、风险、层级、类型、资源和准入准出六个部分。读者可以把右列内容替换成自己迭代的信息，逐行对照填写。
| 策略字段 | 本迭代填写内容 |
|---|---|
| 迭代测试目标 | 验证优惠券在领取、下单抵扣、叠加、过期、退款返还五条主链路上的行为符合规则；确认改动未破坏原有下单与支付流程；迭代结束前完成回归并给出可发布结论。 |
| 成功标准 | 五条主链路在测试环境全部走通；高优先级风险项均有对应验证记录；遗留缺陷中无阻断级和严重级问题；回归范围内原有关键流程通过。 |
| 风险清单与优先级 | P1：优惠金额计算错误导致少收或多收；P1：叠加规则与退款返还组合出错造成资损。P2：领取并发下超发；P2：过期时间边界判断错误。P3：优惠券列表展示与排序异常；P3：提示文案不准确。 |
| 测试层级分工 | 单元测试：优惠计算函数、叠加规则判断、过期时间判断，由开发在提测前完成。接口测试：领取、抵扣、退款返还接口及组合场景，由测试维护自动化用例。界面测试：领取入口、下单页优惠展示、退款结果页。探索式测试：叠加与退款组合、并发领取、异常中断后的状态一致性。 |
| 测试类型取舍 | 功能测试全覆盖五条主链路；接口性能只对领取接口做一次并发验证，确认无超发；安全方面检查优惠券参数是否可被篡改；兼容性只覆盖主流机型和当前两个大版本；可用性检查优惠信息展示是否清晰。 |
| 环境与数据 | 使用独立测试环境，优惠券配置与生产规则保持一致；准备覆盖新老用户、不同券类型、临界过期时间的测试数据；支付环节使用沙箱通道；数据在迭代内每日重置一次，避免脏数据干扰。 |
| 人员与时间安排 | 开发负责单元测试与提测前自测；两名测试分工为一人主攻接口与自动化，一人主攻界面与探索式；产品经理参与验收确认规则理解一致；迭代第1周完成用例设计与接口用例补充，第2周集中执行与回归。 |
| 准入条件 | 需求规则已确认且无待定项；单元测试通过并在持续集成中可见；提测版本部署到测试环境且主流程可走通；测试数据准备完成。 |
| 准出条件 | 五条主链路执行完毕并留有记录；P1风险项全部验证通过；无阻断级和严重级遗留缺陷；回归范围内关键流程通过；产品经理完成验收确认。 |
这份样例的特点是每个字段都能被后续动作检验：风险项对应到具体验证方式，层级分工对应到责任人和完成时点，准入准出写成可以逐条勾选的条件。填写时如果某个字段写不出可判断的内容，通常说明该处的规划还不够具体。
逐项解释：每个字段为什么这样填
风险排序如何影响测试投入分配
示例把优惠金额计算和叠加退款组合列为P1，原因是这两类问题直接关联资金，一旦出错影响面大且修复成本高。对应的投入安排是：计算逻辑前移到单元测试和接口测试，用自动化反复验证；叠加与退款的组合场景安排探索式测试，由有经验的测试人员设计非常规路径。P3的展示和文案问题只做基本检查，不占用主要人力。风险排序的作用是让有限的两名测试把时间花在出错代价最高的地方，而不是平均分配。
测试层级如何按风险与成本分工
层级分工遵循两条依据：验证成本和发现问题的时机。优惠计算这类纯逻辑，单元测试运行快、定位准，放在最底层反复执行；接口层覆盖领取、抵扣、返还的服务端行为，适合用自动化守住主链路；界面层和探索式测试放在上层，处理跨页面状态、组合场景和规则理解偏差。这样安排后，底层问题在提测前暴露，测试人力集中在上层难以自动化的部分。示例中开发承担单元测试、测试承担接口与界面，责任边界与层级对应。
非功能测试在迭代内的取舍理由
两周迭代无法把所有非功能类型做全，示例只保留与本次改动直接相关的项：领取接口的并发验证对应超发风险，参数篡改检查对应优惠券被滥用的风险，兼容性只覆盖主流环境。性能压测、完整安全评估等没有放进本迭代，是因为本次改动不涉及整体架构调整，相关风险由专门的质量活动承担。取舍的判断标准是：该项非功能验证是否直接对应本迭代已识别的风险，对应则做，不对应则记录到后续安排。
准入准出条件如何写成可判断的表述
可判断的条件要能被第三方核对。示例中的准入条件写成“单元测试通过并在持续集成中可见”“主流程可走通”，而不是“开发自测充分”；准出条件写成“P1风险项全部验证通过”“无阻断级和严重级遗留缺陷”，而不是“质量达标”。每条条件都指向一个可查看的记录或状态，评审时逐条确认即可，减少“是否算通过”的争议。
策略确定后，风险项、测试任务、用例和缺陷需要在同一处承载，才能让准入准出条件有据可查。ONES 测试管理可以把测试计划、用例与需求、迭代关联，缺陷与用例执行结果形成记录，策略中的风险项和执行情况可以在迭代视图中对照查看。是否引入工具承载取决于团队已有的协作方式，策略本身的填写不依赖特定工具。
可迁移规律：换一个迭代怎么改这份示例
示例中稳定的部分是策略骨架：迭代测试目标、成功标准、风险清单、层级分工、类型取舍、环境数据、人员安排、准入准出。这八个字段在多数迭代中都需要回答，可以作为固定模板保留，每次迭代只更新内容。
随需求类型变化的调整点主要有三类。第一，风险清单随改动对象变化：如果下个迭代做的是报表导出，P1风险可能变成数据准确性 and 导出性能，层级分工相应把接口测试和性能验证前移。第二，测试类型取舍随改动性质变化：涉及权限或支付的迭代需要加强安全验证，纯展示类改动可以压缩非功能项。第三，人员与时间安排随迭代负载变化：当迭代内需求数量增加时，需要明确哪些需求只做冒烟验证、哪些做完整验证，并在策略中写清楚。
策略在迭代间的维护方式是保留骨架、替换内容、记录差异。每次迭代结束时，把实际发生的缺陷与当初的风险排序对照，检查是否有高风险项被遗漏或低风险项投入过多，把结论带入下一次填写。这样策略文档会逐步贴近团队的真实风险分布，而不是每次从零起草。
适用边界：哪些情况下这份示例需要改写
示例建立在两周迭代、单一需求主题、两名测试人力、常规发布节奏的前提上。出现以下变化时需要改写：团队规模明显扩大或测试人力只有一人时，层级分工和探索式测试的投入需要重新分配；发布节奏变为每日或每周多次发布时，准入准出条件要更依赖自动化门禁，手工回归范围需要压缩；涉及金融、医疗等合规要求较高的业务时，需要补充审计记录、数据脱敏和合规验证项，示例未覆盖这些内容。
示例也没有覆盖一些测试规划内容，包括跨迭代的长期质量目标、自动化测试框架选型、生产环境监控与线上问题回溯、多团队联合发布的协调安排。这些内容属于更大范围的质量规划，不宜塞进单迭代策略中。
最后要分清文档边界：策略文档说明测什么、测到哪一层、何时算通过；测试用例描述具体步骤和预期结果；自动化脚本是可执行的验证代码。三者层级不同，策略不应写成用例清单，用例也不承担策略的取舍判断。把这份示例当作填写参照，结合本团队的风险历史和发布要求调整，才能得到适合自己迭代的测试策略。
常见问题
敏捷测试策略和测试计划是同一份文档吗？
两者关注点不同。策略回答测什么、测到哪一层、谁来测、何时算通过，属于规划层面的取舍；计划更偏向把策略拆成具体的排期、任务和责任人。示例中的八个字段属于策略骨架，实际执行时通常再据此排出迭代内的任务时间表。团队规模较小时可以把两者合并在一份文档里，但取舍判断和排期信息建议分开表述，避免策略被日程细节淹没。
迭代内测试人力只有一人时，这份示例怎么调整？
示例按两名测试分工，一人主攻接口与自动化、一人主攻界面与探索式。只有一人时，需要先压缩范围：P1风险项对应的接口自动化优先保留，界面测试只覆盖主链路，探索式测试集中在叠加与退款组合这类高风险场景，P3的展示与文案检查可以改为抽检或由产品经理在验收时一并确认。同时把单元测试和提测前自测的责任明确压给开发，减少测试环节的重复验证。
准入准出条件写好后，评审时怎么避免争议？
关键是每条条件都指向可查看的记录或状态。示例把准入写成“单元测试通过并在持续集成中可见”“主流程可走通”，把准出写成“P1风险项全部验证通过”“无阻断级和严重级遗留缺陷”，评审时逐条核对记录即可。如果某条条件只能靠主观判断，例如“质量达标”，就把它改写成对应的缺陷等级要求或验证记录要求。条件确定后尽量在迭代内保持稳定，中途变更需要说明原因。
非功能测试在敏捷迭代里应该做到什么程度？
判断标准是该项验证是否直接对应本迭代已识别的风险。示例中领取接口的并发验证对应超发风险，参数篡改检查对应优惠券被滥用风险，因此保留；整体性能压测和完整安全评估与本次改动关联不大，记录到后续安排。如果下个迭代涉及权限或支付改动，安全验证就需要前移并加重。把取舍理由写进策略，后续迭代复盘时才能判断当时的判断是否合理。
策略文档和测试用例、自动化脚本的边界怎么划？
策略说明测什么、测到哪一层、何时算通过；用例描述具体步骤和预期结果；自动化脚本是可执行的验证代码。示例中的风险清单和层级分工属于策略，具体到某条优惠券叠加规则的输入输出组合则属于用例。把策略写成用例清单会让取舍判断被细节掩盖，把用例当成策略又缺少投入分配的依据。三者分层维护，策略在迭代间复用骨架，用例和脚本随需求更新。
