3. 测试脚本常见异常类型
在自动化测试脚本的执行过程中，异常几乎不可避免。真正决定脚本健壮性的，不是“能否一次跑通”，而是“异常发生时能否被准确识别、分类并采取正确的恢复策略”。如果对所有异常都统一重试，往往会把真正的产品缺陷掩盖掉；如果对所有异常都直接失败，又会造成大量误报。因此，识别异常类型是异常恢复与重试机制的第一道关口。
异常识别的核心原则：先判断异常是“环境/基础设施类”还是“业务/断言类”。前者通常可重试，后者往往需要人工介入或直接判定失败。
一、五类常见异常的特征与识别方法
测试脚本中的异常可以按来源分为五类：网络超时、元素定位失败、数据依赖缺失、环境不稳定、断言失败。它们在外在表现、日志特征、可恢复性上都有明显差异。
| 异常类型 | 典型特征 | 日志/报错关键词 | 可恢复性 |
|---|---|---|---|
| 网络超时 | 请求长时间无响应、连接被重置、响应时间突增 | Timeout、ETIMEDOUT、Read timed out、Connection reset | 高，可重试 |
| 元素定位失败 | 页面已加载但找不到目标元素、元素被遮挡、iframe 未切换 | NoSuchElement、ElementNotVisible、StaleElementReference | 中，需等待或刷新 |
| 数据依赖缺失 | 前置数据未生成、账号被占用、接口返回空数据 | NullPointer、data not found、404、empty result | 低，需修复数据 |
| 环境不稳定 | 服务偶发 502/503、数据库连接池耗尽、容器重启 | 502 Bad Gateway、Connection refused、Service Unavailable | 中高，可重试 |
| 断言失败 | 实际结果与预期不符、数值偏差、状态码错误 | AssertionError、expected: X but was: Y | 低，通常为真实缺陷 |
二、异常识别流程
识别异常不能只看异常名称，而要结合“发生阶段 + 报错信息 + 上下文状态”三者综合判断。下面这张图展示了从异常捕获到分类判定的完整信号链，帮助你在脚本中建立清晰的判断路径。
三、典型场景与代码识别示例
以 Python + Selenium 为例，可以通过捕获不同异常类型并匹配关键词来分类。下面是一段简化的异常分类代码：
from selenium.common.exceptions import (
TimeoutException, NoSuchElementException,
StaleElementReferenceException
)
import requests
def classify_exception(exc):
msg = str(exc).lower()
if isinstance(exc, (TimeoutException, requests.Timeout)):
return "NETWORK_TIMEOUT" # 可重试
if isinstance(exc, NoSuchElementException):
return "ELEMENT_NOT_FOUND" # 等待或刷新
if isinstance(exc, StaleElementReferenceException):
return "ELEMENT_STALE" # 重新定位
if "502" in msg or "503" in msg or "connection refused" in msg:
return "ENV_UNSTABLE" # 可重试
if "assert" in msg or "expected" in msg:
return "ASSERTION_FAILED" # 人工介入
if "null" in msg or "not found" in msg or "404" in msg:
return "DATA_MISSING" # 修复数据
return "UNKNOWN"
识别时优先看异常类型（如 TimeoutException），再看消息关键词（如 502、null）。类型优先于关键词，避免误判。
四、误区与复盘
在实际项目中，异常识别最常见的误区有三个：
- 把所有异常都当成可重试异常。断言失败如果被重试，可能连续多次失败后仍被标记为“环境问题”，从而掩盖真实缺陷。
- 只看异常名称，不看上下文。同样是 NoSuchElementException，可能是页面未加载完（可等待），也可能是元素真的被删除了（需修复脚本）。
- 忽略异常发生的时间点。在登录阶段超时和在断言阶段超时，恢复策略完全不同。前者可重试登录，后者应检查业务逻辑。
建议在脚本中为每个异常记录：发生阶段、异常类型、关键日志、重试次数、最终结果。这些字段是后续复盘和优化重试策略的基础数据。
复盘时，可以按“异常类型 → 发生频率 → 恢复成功率 → 是否掩盖缺陷”四个维度统计。如果某类异常重试成功率长期低于 30%，说明它大概率不是环境问题，而应转为人工排查。通过持续的分类与复盘，测试脚本的异常恢复机制才能从“盲目重试”走向“精准恢复”。