自动化测试基础

接口测试到底测什么

很多人刚接触接口测试时，以为就是对着文档发几个HTTP请求，看看返回码是不是200。嗯，这想法太天真了。我早期踩过这个坑——有一次接口返回了200，但响应体里的数据完全是错的，结果线上用户数据全乱套了。

接口测试，说白了就是验证系统之间的“通信契约”是否被正确遵守。你想想看，前端调后端、微服务调微服务、第三方调你的API，每个接口都像一个合同：你给什么入参，我应该返回什么。合同没按着签，系统随时会崩。

具体测什么？我习惯从三个层面拆解：

• 功能正确性：入参合法时返回正确结果，入参非法时有合理错误提示。
• 数据一致性：操作数据库的接口，增删改查之后数据还得对得上。
• 协议兼容性：请求头、Cookie、编码、超时这些细节，少一个都可能出问题。

自动化测试的价值，不是“省时间”那么简单

有些人认为自动化测试就是为了节省手工测试时间。其实不然。真正做过项目的人都知道——自动化测试的投入成本并不低，前期写脚本、维护数据、搭CI，都需要人力和时间。

那它的价值在哪？我个人体会最深的三点：

1. 回归能力：每次改代码，跑一遍自动化用例，心里有底。我经历过一个项目，手工回归要两天，自动化之后只用二十多分钟。
2. 覆盖深度：手工测不完的场景，比如参数组合、压力边界、并发异常，自动化可以轻松覆盖。
3. 可复现性：发现Bug后，把自动化用例锁定，开发修复后一跑就知道修没修好。不需要人工重复操作。

常用工具——Postman 和 Python requests

Postman：手快的人先跑起来

Postman 是我做接口探索测试的首选。它不需要写代码，点点点就能发请求、看响应、保存用例。适合快速验证接口是否通、参数是否对。

但注意，Postman 的自动化能力有限。虽然它支持 Collection Runner 和 Newman（命令行工具），但参数化、断言、失败重试这些做起来比较别扭。我建议用它做前期验证，真正的自动化还是得上代码。

场景	Postman	Python requests
快速测试	非常方便	需要写脚本
参数化驱动	支持但有限	灵活
集成CI/CD	通过Newman	原生支持
强断言/复杂逻辑	弱	强
团队协作	有工作空间	代码仓库管理

Python requests：脚本化的力量

Python 的 requests 库是接口自动化的标配。简洁、易用、文档好。配合 pytest 或 unittest，就能搭出一套完整的测试框架。

看一个最简单的例子：

import requests

response = requests.post(
    url="https://example.com/api/search",
    headers={"Content-Type": "application/json"},
    json={"keyword": "密文", "page": 1}
)

assert response.status_code == 200
data = response.json()
assert "result" in data
print("测试通过")

这段代码干了什么？发了POST请求，塞了JSON体，检查了状态码，还验了返回字段。很直观。

但真实场景远不止这么简单。比如：

• 需要先登录拿，然后再传参数。
• 接口有IP白名单，本地跑不了，得部署到测试环境。
• 返回的数据可能加密，得先解密再断言。

这些，requests 都能配合 pytest fixtures、yaml配置、加密库 搞定。

知识体系：从概念到落地

下面这张图，是我自己画的学习路线。为什么要画这个？因为我刚学的时候，东西太杂，容易迷失方向。有了图，心里就清楚每一步该做什么。

做自动化，先想清楚这几点

我不是说一上来就写脚本。那样做，大概率后期维护成本爆炸。我建议开始之前先想清楚：

• 测什么接口？ 核心业务接口优先，边角料接口手工测就好。
• 用哪套数据？ 环境独立数据？还是共享数据？我经历过共享数据导致用例互相干扰，最后改成每条用例独立造数据。
• 谁来维护？ 团队里要有一个人负责框架和脚本规范，不然每个人写出来的风格都不一样。