1. 课程导入
在自动化测试体系中，脚本“跑得通”只是起点，“跑得稳、跑得可解释、跑得可恢复”才是工程化落地的关键。很多团队都经历过类似场景：本地执行全部通过，接入 CI 后却因为网络抖动、环境未就绪、第三方接口超时、测试数据被并发污染而频繁失败；失败之后既没有重试，也没有恢复动作，最终只能靠人工反复点“重新运行”。本课程围绕测试脚本异常恢复与重试展开，目标不是简单教你在代码里加一个 try/except 或 retry 装饰器，而是建立一套从异常识别、分类、恢复策略、重试控制到可观测与复盘的完整方法论。
一、学习目标：从“会写脚本”到“会治理失败”
完成本课程后，你应当具备以下能力：
- 识别异常类型：能区分瞬时异常（网络抖动、限流、临时超时）、环境异常（服务未启动、端口占用、依赖缺失）、数据异常（脏数据、并发冲突、状态残留）与脚本缺陷（定位器失效、断言错误、逻辑分支遗漏）。
- 设计恢复策略：能针对不同异常选择等待重试、刷新页面、重建会话、清理数据、重启服务、跳过并标记等恢复动作，而不是“一律重试三次”。
- 控制重试边界：能设置最大重试次数、退避间隔、超时上限、幂等条件与熔断条件，避免重试放大故障。
- 建立可观测性：能记录异常上下文、重试次数、恢复动作、最终结果，并输出可检索的日志与报告。
- 形成复盘闭环：能通过失败聚类与根因分析，把“偶发失败”转化为“可修复问题”，持续降低脚本脆弱度。
核心判断：重试不是目的，恢复才是目的；恢复不是掩盖失败，而是让失败变得可控、可解释、可收敛。
二、核心价值：为什么异常恢复与重试值得单独学习
异常恢复与重试的价值体现在三个层面。第一，提升稳定性：在分布式、容器化、微服务与第三方依赖普遍存在的测试环境中，瞬时故障不可避免，合理的重试与恢复能显著降低误报率。第二，提升效率：减少人工介入与重复执行，让 CI 流水线更可信，测试结果更快被团队接受。第三，提升工程质量：当异常被分类、记录和复盘后，团队能识别出真正的薄弱环节，例如某个接口超时阈值不合理、某段测试数据未隔离、某个页面加载策略不稳定，从而推动被测系统与测试框架共同改进。
需要警惕的是，错误的重试会带来反效果：无差别重试可能掩盖真实缺陷，延长反馈周期；无限重试可能造成资源耗尽；重试非幂等操作可能产生重复下单、重复扣款等副作用。因此，本课程强调“先分类，再恢复；先设界，再重试”。
三、整体知识框架：四层能力模型
课程知识框架可以概括为四层：异常识别层、恢复策略层、重试控制层与观测复盘层。异常识别层解决“发生了什么”；恢复策略层解决“能做什么”；重试控制层解决“做多少次、间隔多久、何时停止”；观测复盘层解决“如何证明有效并持续改进”。四层之间不是线性顺序，而是闭环迭代关系。
四、方法流程：一次失败从发生到收敛的完整链路
为了让知识框架可操作，我们把一次脚本失败的处理过程拆成六步：
- 捕获异常：在关键操作周围捕获异常，保留堆栈、截图、请求响应、当前 URL、测试数据标识等上下文。
- 分类判定：根据异常类型、错误码、耗时、重试历史判断属于瞬时、环境、数据还是脚本缺陷。
- 选择恢复动作：瞬时异常可等待重试；环境异常可检查依赖并重启；数据异常可清理或重建数据；脚本缺陷应直接失败并标记。
- 执行重试控制：设置最大次数、退避策略、超时上限与幂等校验，避免无效重试与副作用。
- 记录与上报：输出结构化日志，记录重试次数、恢复动作、最终状态，并上报到测试报告或监控系统。
- 复盘与改进：对失败进行聚类，识别高频异常，推动修复定位器、调整超时阈值、隔离测试数据或优化环境启动流程。
五、案例场景：一个典型的 CI 偶发失败
假设某登录测试在 CI 中偶发失败，日志如下：
TimeoutError: waiting for selector "#login-btn" failed: timeout 5000ms
at LoginPage.clickLogin (login.page.js:42)
at LoginTest.successLogin (login.test.js:18)
retry: 0/3
url: https://test.example.com/login
env: ci-runner-07
如果直接重试三次，可能第二次通过，但问题被掩盖。更合理的处理是：先判断该异常属于“页面加载未完成”还是“定位器失效”。若伴随网络请求缓慢，可增加等待并重试；若每次都在同一位置失败，则说明定位器或页面结构已变化，应直接失败并修复脚本。通过记录重试次数与恢复动作，团队可以区分“环境抖动”与“脚本缺陷”，避免把真实问题当成偶发问题处理。
六、常见误区与复盘要点
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 所有异常统一重试三次 | 掩盖真实缺陷，延长反馈周期 | 先分类，仅对可恢复异常重试 |
| 重试间隔固定为 0 秒 | 加剧服务压力，放大故障 | 使用指数退避与随机抖动 |
| 重试非幂等操作 | 产生重复下单、重复扣款等副作用 | 重试前校验幂等条件或使用补偿机制 |
| 只记录“失败”，不记录重试过程 | 无法复盘，无法判断恢复是否有效 | 结构化记录重试次数、恢复动作与最终结果 |
| 无限重试直到通过 | 资源耗尽，流水线阻塞 | 设置最大次数、超时上限与熔断条件 |
学习建议：本课程后续章节会逐步展开异常分类、恢复动作、重试算法、日志观测与复盘方法。建议你在学习过程中同步梳理自己项目中的失败案例，按“异常类型—恢复动作—重试边界—观测指标”四列建立清单，边学边改，效果最好。
重要提醒：重试与恢复的目标是提升测试可信度，而不是让失败消失。任何一次重试都应当留下痕迹，任何一次恢复都应当可解释。没有观测的重试，等于把问题藏进黑盒。
本章作为课程导入，已经给出学习目标、核心价值、四层知识框架与六步方法流程。接下来你将沿着“识别—恢复—控制—观测—复盘”的路径，逐步掌握让测试脚本在复杂环境中稳定运行的关键能力。