API测试的目标

概述

首先，API 测试的主要目标就是测试接口本身。这意味着我们需要测试 API 中的每个 URL 或端点，包括所有可能的输入参数，同时还要验证这些端点请求所返回的响应。例如，我们必须确认每一个承诺提供的端点都真实存在，并且能够正确接收输入、产生预期的输出。但这仅仅是个开始。

测试 API 的行为

除了测试接口外，我们还需要确保 API 的实际行为符合预期——这些预期来源于对 ALPS 描述文档和 OAS 文档的理解。例如，某个 API 可能规定：每次请求信用评级时，返回值必须在 1 到 10 之间。如果该 API 返回了 0 或 13，这就属于不符合预期的行为。

另一个 API 可能规定：不允许创建两个具有相同 companyName 值的记录。这意味着任何试图违反此规则的操作，都应被 API 拒绝写入重复记录，并返回 HTTP 状态码 400 Bad Request。

此外，我们可能还会遇到支持通过 HTTP 请求来审批采购订单的 API，如下所示的 curl 示例：
curl http://api.example.org/purchases/ -X PUT -d status=approved

然而，当某条订单记录中缺少有效的 salesPerson 字段值时，API 不应允许任何人进行审批操作。我们期望在所有必要信息未完整提供前，任何审批尝试都会触发 HTTP 400 Bad Request 响应。

验证 API 是否表现出符合预期的行为，是高质量 API 测试的关键所在。围绕这一理念，已经形成了一套完整的实践方法和工具体系，被称为行为驱动开发（BDD）。

行为驱动开发（BDD）由 Dan North 于 2006 年提出。North 对当时测试驱动开发（TDD） 的设计和使用方式感到不满，因此提出了一个全新的测试视角。他的目标是让测试的设计与实现过程不仅限于程序员，也能被更广泛的团队成员所理解和参与。

TDD 可被视为一种以代码为中心、旨在提升代码质量的实践，而 BDD 则侧重于改善整个系统的行为表现。正如 North 所言：“行为驱动开发是一种‘由外向内’的方法论。” 尽管 North 最初是为了改进编码过程而设计 BDD，但这种模型在构建 API 测试时同样非常有效。其中一个关键原因就在于其“由外向内”的测试理念——当我们面对 API 时，唯一的测试入口就是其外部接口本身。

在聚焦接口测试的过程中，关注预期行为是构建高质量测试策略的有效途径。这也引出了我们在设计测试时依赖的另一项重要原则：区分“正常路径”（happy-path）和“异常路径”（sad-path）测试。

同时测试正常路径与异常路径

测试正常路径和异常路径的一种常见做法，是验证接口是否按设计执行功能。例如，我们应该能够获取客户列表、根据特定属性过滤列表、添加新客户、编辑客户信息，甚至将其从存储中删除。从逻辑上讲，我们可以将这些期望转化为简单的测试用例，并通过执行测试来验证这些期望是否得到满足。

例如，以下是一组用于验证上述功能的请求：

• http://localhost:8181/list/
• http://localhost:8181/filter?status=active
• http://localhost:8181/ -X POST -d \ id=q1w2e3r4&status=pending&email=test@example.org
• http://localhost:8181/status/q1w2e3r4 -X PATCH -d status=active
• http://localhost:8181/q1w2e3r4 -X DELETE

每一个请求都代表对我们某一项期望的测试。本质上，我们期望这些请求都能成功执行。按照 HTTP API 的术语，服务器应返回 200 OK 状态码以及正确的响应正文。这类测试被称为正常路径测试（happy-path tests）。当它们全部通过时，一切顺利，皆大欢喜。

然而，我们对客户 API 还有另一类重要的期望。例如，我们期望 API 能够阻止用户在未提供所有必填字段的情况下新增客户记录；防止插入重复的客户数据；并对各字段的数据类型进行校验，避免将字符串写入数值型字段，或向邮箱字段写入非法格式的字符串等。这些属于异常路径测试（sad path tests）。按照 HTTP API 的规范，此类请求应当返回 400 Bad Request 或其他 4xx 类状态码。验证 API 是否能有效阻止不合法或不良操作的发生，同样是测试过程中不可或缺的一环。