需要，但不是绝对必须“全部剥离”，关键看你们的自动化目标、团队规模以及接口的变化频率。更准确的做法是：把“可复用的能力”从“业务用例”里抽出来，让用例尽量只表达业务意图。
推荐的思路：分层解耦
你可以把接口自动化大致拆成三层（或四层）：
-
业务用例层（case）
- 只写：做什么业务、输入什么参数、期望什么结果
- 不关心：怎么签名、怎么加 header、怎么发请求、怎么处理重试等
-
接口/请求封装层（service/client）
- 把“请求怎么发”统一封装
- 例如：
userLogin()、createOrder()这种方法（本质是对 endpoint 的封装）
-
公共能力层（utils / hooks）
- 抽出所有通用方法：鉴权、签名、加密、header 组装、通用校验、日志、token 刷新、重试、超时处理等
-
配置/数据层（config/data）
- 基础配置：baseUrl、环境切换、超时时间、证书、账号/权限
- 数据：用例参数、测试数据、期望值（可从文件/DB/Excel 生成）
- 关键点是：用例不要散落硬编码配置
为什么要剥离？
在 API 自动化“普及且重要”的情况下，常见痛点是：
- 环境切换（dev/test/prod）导致大量改代码
- 鉴权方式改了（token/签名/加密/渠道号）要改很多 case
- header/traceId/重试策略/通用断言散落各处，维护成本高
- case 越写越像“脚本”，可读性下降，后来人改不动
把这些从 case 中剥离出来，收益通常是：
- 可维护性：公共变动集中在一处
- 复用性：同一个鉴权/请求逻辑被复用
- 可读性：case 更像规格/业务流程
需要剥离到什么程度（实用标准）
你可以按“是否会被复用 / 是否经常变动”判断：
-
应该剥离：
- 鉴权、签名、公共 header/traceId
- 请求发送方式（统一封装）、通用重试/错误处理
- 通用断言（状态码、字段非空、schema 校验等）
- 环境配置（baseUrl、密钥、开关）
-
不必过度剥离：
- 只有某一个用例才用一次的特殊逻辑（可以放在 case 或该接口的局部封装）
- 极其业务化、不可复用的组合步骤（仍可留在用例层表达业务）
也就是说：剥离“共性能力”，保留“业务意图”。
一个简单例子（表达方式）
- case：
- “登录成功后，查询用户信息并校验字段”
- 封装层：
-
login()、getUserInfo()负责发请求与基础处理
-
- 公共能力层：
-
signRequest()、buildHeaders()、extractToken()、retryOn5xx()等
-
这样 case 里就不需要出现“怎么签名/怎么构造 header”的细节。
你要的“case只为业务服务”怎么落地
建议你们制定一个团队约定：
- case 文件里只允许出现：参数组织、调用接口方法、断言
- 封装层负责：请求、鉴权、header/body 编排、通用异常处理
- config/data 负责：环境与数据来源
如果你愿意，我可以按你们的技术栈（例如：Python+requests/pytest、Java+RestAssured、Postman/Newman、Go、Node等）给一个更贴近落地的目录结构和代码模板。你们现在用什么语言/框架？API 鉴权方式是 token 还是签名（如 HMAC）？
