接口测试推荐：封装认证签名脚本，一行Skills搞定

刚接手接口自动化代码时，发现登录模块里躺着二十行RSA签名生成逻辑。订单模块同样二十行，变量名都没改。支付模块再来一份。

这并非复制粘贴的问题——是写脚本的人压根没考虑复用。

三年过去，局面改善了吗？

并没有。深入评估过七八个测试团队，每个团队的代码仓库里至少有三四套认证、签名、加密实现：HMAC-SHA256、MD5加盐、JWT、自定义非对称签名。每个接口都得带上这些逻辑，每个脚本都得重写一遍。

更要命的是，认证逻辑一旦变更——比如密钥轮换、算法升级——所有脚本都得改。漏改一个，那个脚本就永远飘红。

上个月，我把项目里所有认证、签名相关逻辑抽成了Skills。现在任何接口测试只需一行声明：@use_skill("auth_rsa")。签名参数自动注入，请求自动发送，响应自动验签。接口测试脚本从一百五十行降到了二十行。

这篇文章不讲空泛理论。直接拆解如何把认证、签名这类“横切关注点”封装成可复用的Skill。

一、每个接口测试脚本里，都有一段不敢动的签名代码

随便打开一个接口测试项目，大概率能看到这样的结构：

def test_create_order():# 二十行签名生成timestamp = str(int(time.time()))nonce = str(random.randint(100000, 999999))body = json.dumps({"product_id": 123, "quantity": 2})sign_string = f"{timestamp}{nonce}{body}"signature = hmac.new(secret_key, sign_string.encode(), hashlib.sha256).hexdigest()# 两行业务请求headers = {"X-Timestamp": timestamp, "X-Nonce": nonce, "X-Signature": signature}resp = requests.post("/api/order", data=body, headers=headers)# 二十行响应验签（有时还有）# ...

看出问题了吗？

真正描述业务意图的代码只有两行：post("/api/order", data=body)。其余四十行全是认证、签名、验签的杂音，并且在每一个测试函数里重复出现。

更难受的是，开发改了签名算法——从HMAC-SHA256换成SM3。你得在三十个测试文件里分别找到那段签名代码，逐个修改，还不一定全跑通。

很多人干脆不动。新接口直接复制旧接口的签名代码，改一改变量名就用。于是代码库里出现了三代签名算法并存的奇观。

本质问题是什么？

我们把本应属于“基础设施”的认证能力，硬编码进了业务脚本里。就像每个业务函数里都写一遍数据库连接池，没人会这么干。但在接口测试里，大家默认就这么干了。

观点句1：

二、认证不是业务，它是基础设施

搞清楚一个概念：什么是业务逻辑，什么是基础设施。

业务逻辑是“下单时要扣减库存”“支付成功后要发送通知”。认证签名是“每个请求都要携带的安全凭证”。前者每个接口都不同，后者整个系统都相同。

基础设施的特点是：可以被统一管理、统一变更、统一升级。数据库连接池是这样，日志是这样，认证也应该是这样。

但在大多数接口测试框架里，认证却被当作业务逻辑处理。每个测试函数都自己负责生成签名、构造认证头、验签。原因有两个。

第一，历史惯性。最早写第一个测试脚本的人图省事，把签名代码直接写在函数里。后来的人看到这个模式，照搬。

第二，工具限制。很多测试框架（比如requests原生用法）没有提供“全局请求拦截器”的概念。你想统一处理认证，只能自己封装一个session类。不是做不到，只是需要额外设计。

Skills-first模式提供了一个新的抽象：把认证能力封装成一个独立的Skill，然后通过声明的方式附加到任意接口测试上。

Skill在这里承担的角色是请求拦截器。它在请求发出前执行，可以修改请求头、请求体、甚至URL。同时它也可以在响应返回后执行，做验签、解密等后处理。

关键点：Skill不关心具体调用它的接口是什么。它只知道自己需要从当前上下文中拿到哪些数据（时间戳、随机数、请求体等），然后计算出签名，注入到headers里。

这种设计带来的效果是：接口测试脚本回归到只描述业务本身。认证的事情交给Skill。

观点句2：

三、Skill作为请求拦截器：注入、签名、发送

下面拆解一个认证Skill的完整技术实现。

核心架构如下：

Skill的定义规范

一个认证Skill需要实现两个接口：

class AuthSkill:def pre_request(self, context):# context包含：method, url, headers, body, params# 返回修改后的headers和bodytimestamp = str(int(time.time()))nonce = self._gen_nonce()body_str = json.dumps(context.body) if context.body else""sign = self._sign(f"{timestamp}{nonce}{body_str}")context.headers["X-Timestamp"] = timestampcontext.headers["X-Nonce"] = noncecontext.headers["X-Signature"] = signreturn contextdef post_response(self, context):# context包含：response对象# 可选：验签、解密响应体signature_from_server = context.response.headers.get("X-Signature")ifnot self._verify(context.response.text, signature_from_server):raise AuthFailedError("响应签名验证失败")return context

在测试脚本中的调用方式

测试脚本只需要声明依赖哪个Skill，以及传入必要的业务参数：

@use_skill("hmac_sha256_auth")def test_create_order(product_id, quantity):resp = api.post("/order", json={"product_id": product_id, "quantity": quantity})assert resp.status_code == 200

@use_skill装饰器做的事情：

1. 在函数执行前，实例化指定的AuthSkill
2. 将原始请求拦截，传入Skill的pre_request
3. 发送修改后的请求
4. 将响应传入Skill的post_response
5. 返回最终响应给测试函数

支持多Skill链式组合

有些系统需要多层认证。比如先做JWT鉴权，再对请求体做签名。这时候可以把多个Skill串起来：

@use_skill("jwt_auth")@use_skill("payload_signature")def test_pay():# ...

执行顺序：先最内层的Skill，然后向外层。每个Skill都可以修改请求和响应。

这种设计解决了两个实际问题：

• 认证逻辑变化时，只改Skill实现，所有测试脚本零改动
• 新接口接入认证，只需要加一行装饰器，不需要复制任何代码

观点句3：

四、三个真实场景的代码对比

选三个典型的认证场景，看传统写法 vs Skill写法的差异。

场景一：HMAC-SHA256签名（最常见）

传统写法（每个接口）：

timestamp = str(int(time.time()))nonce = str(random.randint(100000, 999999))body = json.dumps({"amount": 100})sign_str = f"{timestamp}{nonce}{body}"sign = hmac.new(secret, sign_str.encode(), hashlib.sha256).hexdigest()headers = {"X-Timestamp": timestamp, "X-Nonce": nonce, "X-Signature": sign}resp = requests.post("/api/pay", data=body, headers=headers)

Skill写法：

@use_skill("hmac_sha256")def test_pay():resp = api.post("/pay", json={"amount": 100})assert resp.status_code == 200

代码行数：传统25行，Skill方式3行（不含Skill定义）。

场景二：OAuth 2.0 Client Credentials

传统写法（先拿token，再带token请求）：

def test_get_user():# 获取tokenauth_resp = requests.post("/oauth/token", data={"grant_type": "client_credentials","client_id": "xxx","client_secret": "yyy"})token = auth_resp.json()["access_token"]# 业务请求headers = {"Authorization": f"Bearer {token}"}resp = requests.get("/api/user", headers=headers)# token过期还要处理刷新逻辑...

Skill写法：

@use_skill("oauth2_client")def test_get_user():resp = api.get("/user")assert resp.status_code == 200

Skill内部处理了token的获取、缓存、自动刷新、过期重试。

场景三：国密SM2/SM3签名（金融常见）

传统写法需要引入复杂的加密库，十几行甚至几十行代码。Skill封装后，业务脚本完全无感知。

一个可传播的对比数据

我们统计了单个项目中认证相关代码的重复率。重构前，15个接口测试文件，认证代码总行数超过600行。重构后，认证Skill一个文件120行，每个测试文件减少40行重复代码。总量从600行降到120 + 15*10 = 270行。净减少55%。

更重要的是，后来开发把签名算法从HMAC-SHA256升级到SM3，改动只发生在Skill内部，测试团队零改动。

五、封装认证Skill的三个层级

不是所有认证逻辑都需要做成通用Skill。有人过度设计，把简单的Basic Auth也封装成Skill，反而增加了理解成本。

根据复杂度和复用频率，可以分三个层级落地。

第一层：函数级复用（最低成本）

如果认证逻辑很简单（比如固定的API Key），而且只在两三个测试文件中使用，没必要做Skill。写一个公共函数即可。

def add_auth_headers(headers):headers["X-API-Key"] = "fixed_key"return headers

这不算Skill，但已经比到处复制强。

第二层：请求级拦截器（大多数场景适用）

认证逻辑涉及动态参数（timestamp、nonce、签名计算），并且要被五个以上接口使用。这时候值得封装成真正的Skill。

核心是设计好Skill的输入输出。一个好的认证Skill应该做到：

• 不依赖全局变量（密钥通过配置注入）
• 不硬编码算法（支持策略模式切换不同签名方式）
• 能够独立测试

第三层：多Skill组合（企业级复杂场景）

有些系统同时使用多种认证机制。比如内部服务之间用mTLS，对外部请求用JWT，对敏感操作再加一层签名。

这时候需要支持Skill链。每个Skill只做一件事，执行引擎按顺序调用。调试时也可以单独关闭某个Skill来定位问题。

避坑指南

踩过两个常见的坑，提醒一下。

第一个坑：Skill里不要做重操作。比如每次请求都去读密钥文件或调远程服务获取token。应该做缓存，token过期再刷新。

第二个坑：不要为了统一而统一。有的接口不需要认证（比如健康检查），有的接口用不同的认证方式。Skill框架要支持“跳过认证”和“覆盖认证”。实现一个@use_skill(None)用来显式关闭继承的认证。

六、你的代码库里，还有多少“不敢删”的重复代码？

写这篇文章的时候，随手打开一个旧项目的测试目录。grep -r "hmac" . | wc -l，结果是47。47处HMAC签名代码，分布在14个文件里。

将其中一个文件里的签名代码删掉，换成一行@use_skill，跑测试。全绿。

然后批量替换了剩下的13个文件。总共花了四十分钟。这四十分钟省下的，是未来每一次签名算法变更时的一整天。

现在轮到你了。

打开你正在维护的接口测试项目，搜索sign、signature、hmac、jwt、token这些关键词。看看有多少个文件在重复做同一件事。

然后问自己一个问题：

如果明天后端通知你，认证算法要换，从A换成B。你需要改动多少个文件？

如果你的答案不是“1个”，那么你的测试框架里，已经有了技术债务。

至于怎么把这1个写得足够通用、足够健壮、足够让团队里其他人直接用——那是另一个话题了。评论区聊聊，你遇到的最离谱的重复代码是什么样的？

来源：互联网