接口测试入门：从请求到断言

应用程序接口（API）让不同软件交换数据。测试一个 HTTP 接口时，测试者准备输入请求，再依据接口约定检查响应。为了避免向真实服务发送请求，本文用保留示例域名 example.com 说明测试思路；示例请求不会在页面中自动运行。

先写清楚测试用例

测试用例可以包括前置条件、请求方法和路径、输入数据、预期状态与预期响应。比如一个虚构的只读资料接口：

请求：GET https://api.example.com/v1/notes/42
预期：状态码 200
预期：Content-Type 为 application/json
预期：响应 JSON 包含 id 与 title 字段

域名、路径和标识符均为演示内容；真实测试需要对照目标接口文档，并使用获准的测试环境。

把预期写成断言

断言是程序化检查结果的规则。常见检查包括：

• 状态码符合当前场景预期，而不是只检查“有响应”。
• 响应头中的媒体类型与接口约定相符。
• JSON 能被解析，必需字段存在且类型正确。
• 错误输入返回文档规定的错误结构，不泄露不必要的内部细节。
• 涉及分页、排序或权限时，检查对应的边界条件。

覆盖正常路径和边界

除典型成功请求外，可根据接口契约检查不存在的资源、缺少必填参数、格式错误的输入、分页边界等情况。测试数据要保持可重复，并避免在未经授权的生产系统上执行有副作用的操作。

记录结果便于复查

简短报告通常记录环境、请求要点、预期、实际结果和复现条件。不要把密码、访问令牌、个人数据或完整敏感响应直接放进报告；确需诊断时，应按团队规则脱敏。