python 接口自动化测试开发

写接口自动化测试最尴尬的不是不会 requests，而是用例写到几十条就开始互相污染：环境切不干净、跑一次要等半天、失败了看不出是代码错还是接口慢。这篇按工程视角把目录结构、用例组织、超时与并发、失败降级、日志与结果评测串成一条线，给的是可以照着搭的顺序，不是概念科普。协议兼容和客户端配置不在本文范围，那两块站内另有文章讲透了。

接口自动化测试真正卡人的地方，通常不是不会用 requests，而是用例写到几十条之后开始互相污染：环境切不干净、跑一次要等半天、失败了也看不出是代码写错了还是接口本身慢。这篇按工程视角，把目录结构、用例组织、超时与并发、失败降级、日志和结果评测串成一条能照着走的线，讲的是怎么搭、先搭哪一步。

下面的顺序建议不要跳：骨架没定就先写用例，后面一定要返工。协议兼容、客户端配置这些不在本文范围，站内另有文章已经讲透，这里只聊 Python 工程侧的组织方式。

先定工程骨架，别一上来就写用例

骨架的目标只有一个：改一个接口地址时只动一处，加一个接口时只加一个文件。如果每次加接口都要翻 utils 和 config，说明分层其实没切干净，早晚会出问题。

• 接口定义和用例分开写，用例里不出现裸 URL 和硬编码密钥
• 环境用一份 config 加上环境变量覆盖，本地、测试、预发各一份值，谁也不用去改别人的代码
• 请求层统一封一个 client：超时、重试、鉴权头、日志埋点全放这层，用例只调业务方法
• 判断标准：新增一个接口时只改 api 层加一份用例文件，才算分层合格

用例怎么组织：按业务链路分，不按接口数量分

很多人习惯按 Controller 或者接口数量一个文件一个文件写，结果一跑就是几十条互相依赖的用例。更稳的切法是按业务链路组织：下单链路一组、支付链路一组、查询链路一组，每组内部再分核心和边界。

冒烟集

只覆盖核心链路，几分钟内能跑完，适合每次提交触发

全量集

覆盖边界和异常分支，按需要或定时触发

数据隔离

用 fixture 现造现删，不靠执行顺序保证数据干净

数据驱动

只用在参数组合多的场景，入参和期望放外部文件，代码里循环读

• 参数组合少的用例直接写死反而更好读，别为了优雅硬上数据驱动
• 造不出干净数据的链路，先别做成自动化，硬做只会让报告长期飘红
• 强依赖第三方回调或人工审核的链路，维护成本往往高过收益，先用半自动脚本兜住
• 以上判断在接口本身幂等、可重复调用时最成立；写操作不幂等时，隔离策略要单独设计

超时和并发：先量基线，再定参数

超时别拍脑袋。先用站内测速工具量出接口的延迟分布，再按这个基线往上留余量，连接超时和读取超时分开设，读超时通常要留得比连接超时宽。基线是会变的，具体数字到站内测速页面看当时的结果，不要拿记忆里的旧值套。

1. 先量基线挑业务低峰期，对目标接口连续请求若干次，记录中位延迟和尾巴延迟，心里有数再写超时值
2. 再定超时连接超时设短，读取超时按尾巴延迟留余量，两者都写进 config，不要散落在用例里
3. 区分两种并发一是测被测接口的并发能力，二是加速跑用例；后者用测试框架自带的并行参数控制进程数就够了
4. 写操作不开并发只对查询类用例开并发，涉及写操作的用例并发跑会互相踩数据

失败降级与日志：让每次失败可复盘

失败信息写得不清楚，等于每天晚上都在重新排查同一个问题。断言挂掉的时候，至少要把请求出参、响应体、耗时三段打出来。只打一句 assert 报错，第二天连自己都看不懂当时发生了什么。

• 网络类失败和业务类失败分开处理：前者重试要有上限，后者直接失败，重试只会掩盖真实缺陷
• 日志统一记 URL、请求 id、状态码、耗时、重试次数，按天切文件，避免 CI 日志刷屏
• 降级口径要团队统一：被测服务不可用时，是跳过、标记阻塞还是直接失败，写进文档
• 报告里分清通过、失败、跳过、阻塞四类，只看通过率会掩盖大量被跳过的用例

一条看不懂的失败日志，比十条飘红的用例更浪费时间。

结果怎么评测，怎么持续维护

报告是给团队看的，不是给自己看的。维护动作不写进流程，用例集三个月就会变成没人看的摆设。下面这几条建议按季度过一遍。

1. 清理僵尸用例长期失败的用例要么修，要么删，留着只会让人不再打开报告
2. 挂进流水线冒烟集和全量集分开触发，别让每次提交都等全量跑完才出结果
3. 结构改动后回归接口结构或调用方提示词改过之后，抽样跑一批历史用例看有没有回归，思路可参考站内提示词版本回归测试那篇
4. 定期核对基线与限额超时值和并发阈值过一段时间就要重新量、重新核对，站内的测速和限额页面是现成的参照