18｜接口自动化框架怎么设计？和 UI 自动化有什么不同？

开场先讲差异定位：接口自动化没有页面这个不稳定层，天然稳定、快、便宜——所以它敢追求覆盖率和执行频次，设计思路从 UI 的「保守覆盖」变成「尽量全量」，回归主力放这层。

回答思路

第一步：框架分层讲

层	内容
请求封装层	requests 的 session 封装、重试、超时、日志
用例层	pytest 组织、断言
业务层	登录、下单这类多接口组合的流程封装
数据层	参数文件、环境配置、测试数据库的造数和清理

四层和 UI 框架思想同源但重心不同——接口框架的重心在断言体系和数据管理。

第二步：断言讲三层

1. 状态码和业务码
2. 响应体字段断言（jsonpath 提取）
3. 数据库落库断言——第三层是接口测试的深水区，响应对了库没写对是常见漏网

能主动讲三层断言的，是真做过接口框架。

第三步：讲数据管理这个难点

前置数据用造数接口或工厂函数构造，用例跑完清理（teardown 或标记回收），多环境数据隔离——接口用例的 flaky 大半来自脏数据，这个归因讲出来很有分量。

收尾：讲和 UI 的配合

接口层覆盖逻辑分支，UI 层只做关键路径串接——两层各自出力，是分层策略在执行层的落地。

考察重点

维度	说明
企业动机	接口自动化是当前企业投入的主战场，测开岗面试必考。这题区分你是只做过 UI 录制改脚本的，还是能独立设计服务层测试体系的
过线标准	分层结构 + 三层断言（尤其数据库断言）
区分度	讲「脏数据是接口 flaky 主因」并给出造数清理方案的，是运营过规模化接口框架的
加分项	jsonpath 断言、造数工厂、环境隔离的工程细节
减分项	只会「requests 发请求断言返回码」，连响应体字段断言都不做——覆盖形同虚设

来源

整理自知识星球帖《面试情报 03｜自动化测试 20 题》，返回题库。