requests封装接口客户端：从脚本到小框架

2022年2月记录，分类「接口测试」。内容按测试执行视角整理，尽量把背景、操作和验收口径讲清楚。

为什么要封装

最开始我写接口脚本就是 requests.get/post 到处飞，能跑，但维护很痛。接口多了以后，鉴权、超时、日志、重试、断言都重复，所以我把它收敛成一个小客户端。

这类问题如果只写结论，过一段时间就很难复用，所以我把判断依据也留了下来。

封装边界

• session 里统一处理 base_url、headers、token 和超时。
• 请求前后记录 method、url、参数、耗时、traceId，失败时输出完整上下文。
• 业务接口再薄封一层，让用例表达创建订单、查询账单这种动作。

class ApiClient:
    def request(self, method, path, **kwargs):
        resp = self.session.request(method, self.base_url + path, timeout=8, **kwargs)
        self.logger.info("%s %s %s", method, path, resp.status_code)
        return resp

核心片段

• 新增接口用例不再重复写登录和 headers。
• 接口失败能看到请求参数、响应体和耗时。
• 公共封装不夹带业务断言，避免越写越重。

如果要自动化，我会先挑稳定、关键、失败后能定位的部分，不急着全量脚本化。

使用后的变化

接口客户端的价值不是炫封装，而是把不该重复的细节藏起来，把业务意图露出来。如果放到流水线里，建议先从最小冒烟开始，再逐步扩大覆盖。