自动化测试调试过程：别让脚本跑着跑着就“失联”了

发布时间：2026-01-22 18:50:54 阅读：88 次

上周帮朋友排查一个接口自动化测试失败的问题，跑了200多条用例，其中3条总在凌晨两点报错——不是代码逻辑问题，是测试环境的Redis服务定时重启，而脚本没做重连机制。这种场景，在真实项目里太常见了：脚本写得挺溜，一跑就崩，崩得还悄无声息。

调试不是“看日志等报错”，而是主动设防

很多人把自动化测试调试当成“出了问题再翻日志”。但网络优化视角下，更该把它看作一次端到端的链路体检。比如HTTP请求超时，到底是被测服务响应慢？还是代理服务器拦截了？抑或是本地DNS缓存失效？光盯着测试框架报的“Connection refused”没用。

建议在关键步骤加轻量级埋点：

logger.info(f"[API_CALL] start: {url}, headers={masked_headers}")
response = requests.get(url, timeout=8)
logger.info(f"[API_CALL] status={response.status_code}, elapsed={response.elapsed.total_seconds():.2f}s")

这样出问题时，一眼看出是卡在发包前、等待响应中，还是解析返回体时挂了。

复现难？试试“可控扰动”法

有些问题只在CI流水线里出现，本地稳如泰山。别急着怀疑“环境不同”，先检查三件事：
• 本地运行时是否用了mock数据，而CI走的是真实网关？
• 测试账号在CI环境是否因并发登录被踢下线？
• 网络策略是否限制了CI机器的出口IP（比如某些短信验证码接口只白名单了办公区IP）？

与其反复部署看结果，不如在脚本里主动制造可控扰动：

# 模拟弱网延迟
import time
if os.getenv('CI') == 'true':
    time.sleep(0.5)  # 给网络留点喘息时间，避开瞬时抖动

截图和录屏，比日志更直给

UI自动化尤其明显。Selenium报“ElementNotInteractableException”，你翻10分钟日志，不如直接看失败时的截图——可能页面根本没加载完，或者弹窗遮挡了按钮。在pytest中加个简单钩子：

def pytest_runtest_makereport(item, call):
    if call.when == "call" and call.excinfo is not None:
        driver.save_screenshot(f"fail_{item.name}.png")

配上轻量录屏（比如用ffmpeg后台录浏览器窗口），问题定位速度能提一倍。

调试自动化测试，本质是在和不确定性打交道。网络波动、服务依赖、资源竞争……这些从来不是异常，而是常态。把调试过程本身当成可配置、可观测、可回溯的一环，脚本才能真正扛住生产环境的风浪。