API测试核心转变：从确认到质问

当有人从测试用户界面转向测试 API 时，工具变了，但更艰难的调整是他们提出的问题。UI 测试倾向于问"屏幕是否做了正确的事"。API 测试则问"一份契约在全世界抛出的各种情况下是否还能站得住脚"。工程师一旦内化了这个转变，就能很快上手。没有完成这个转变的人，往往写出的 API 测试实际上是没有屏幕的 UI 测试。

定义是最简单的部分

如果你去查"什么是 API 测试"，会得到一个简洁的答案：它是一种直接针对软件组件间接口进行测试的实践，层级在请求与响应，而不是通过用户界面。这种定义是正确的，但光靠它几乎毫无用处，因为它只告诉你"在哪里测"，却不告诉你"在那里该如何思考"。

从"它能工作吗"到"什么可能出错"的思维转变

真正重要的思维跳跃是从确认走向追问。UI 测试通常确认一条已知路径产生了已知结果。好的 API 测试则要追问这个端点：字段缺失时会发生什么？请求体格式错误时呢？Token 过期了呢？值恰好卡在允许边界上呢？请求被重复发送了呢？屏幕隐藏了大部分这些情况，因为界面会礼貌地约束用户能提交什么。但在 API 层，没有任何东西约束调用方，所以测试者必须想象客户端可能做出的所有丑陋行为——无论有意还是无意。

一旦你开始问"什么可能出错"，很快就会发现这个问题不是一个问题，而是裂变成多个问题。

API 测试的各种类型就是从这里来的。它们不是学术分类。每种类型都对应着你所担心的某一种失败。功能测试担心的是错误的响应。集成测试担心的是服务之间互相误解。负载与性能测试担心的是压力下的行为。安全测试担心的是滥用。契约测试担心的是一次静默的变更打破了消费者。命名一种类型，实际上是在命名一种恐惧。

新手容易卡住的地方

我看到人们卡住的地方，是对响应状态码的处理——把它当作答案。200 感觉就是成功，有一段时间这足以让整个测试套件看起来全是绿的。但状态码健康而响应体错误或畸形，恰恰是 API 测试存在要去捕获的那种失败，而如果你只检查状态码，这种失败就完全不可见。需要尽早培养的习惯是对响应的结构和内容做断言，而不仅仅是断言"有响应到达"。

这个转变值得让人不适的原因在于杠杆效应。在 API 层级运行的测试直接触达真实的业务逻辑，中间没有浏览器挡着，而且当它失败时通常能自己说明原因。完成这个跳跃的工程师发现，他们可以用更少、更不脆弱的代价覆盖更多有意义的行为——这是他们在 UI 层永远做不到的。问题变了，整个测试的经济学也随之改变。

如果只能给刚接触这个领域的人一件事，那不会是工具或框架，而是一个问题。别再问"这个端点能工作吗"，开始问"当有人用你没有预料到的方式访问它时，什么可能出错"。一旦这个问题成为你手中握着的那个问题，API 测试所有有用的东西——类型、断言、工具——就会自然地随之而来。