Python异常处理在自动化框架里的落点

2022年1月记录，分类「python基础」。这篇按当时的测试现场整理，重点放在目标、动作和可复用的检查点。

改动目标

以前框架里异常处理写得比较散：接口报错、断言失败、环境不可用都抛成一类，报告里看不出到底是产品问题还是脚本问题。后来我把异常分成业务失败、环境失败、脚本失败三类，定位速度明显快很多。

我当时想确认的不是工具能不能跑，而是这个点能不能稳定地变成测试资产。

我怎么拆

• 请求层只负责抛出带上下文的异常，不在这里判断业务通过与否。
• 断言层把响应体、数据库结果、日志 traceId 一起写进失败信息。
• pytest hook 里统一截图、保存请求响应和标记失败类型。

class ApiAssertError(AssertionError):
    def __init__(self, message, *, request_id=None, payload=None):
        super().__init__(message)
        self.request_id = request_id
        self.payload = payload or {}

代码落点

• 报告里能区分接口 500、业务码不对、测试数据不存在。
• 失败后可以直接拿 request_id 去日志平台追。
• 环境不可用不计入业务缺陷，避免误伤版本质量。

这些点后面会进用例或检查单，尤其要补齐账号、数据、环境版本和日志关键字。

复盘

异常处理不是为了把代码写漂亮，而是为了让失败现场能交接。这个点做好以后，新人看报告也能判断下一步找谁。后面遇到类似需求，可以先按这个结构跑一遍手工验证，再决定是否自动化。