The API Testing Checklist I Use for Every Endpoint

三年前，我在凌晨2点目睹了一个生产API的壮观失败，因为没有人测试发送格式为“32/13/2021”的日期字段会发生什么。级联效应以最糟糕的方式展现得如此美丽：47,000个失败的交易，愤怒的客户涌入支持渠道，还有一个想要答案但我没有的CEO。那个晚上改变了我对API测试的看法。

我是陈莎莎，我是一名做了八年的QA自动化工程师，最后五年专注于金融科技和医疗平台的API测试。我测试过从简单的CRUD端点到处理每日数百万美元的复杂支付处理API的一切。我学到的经验是：大多数API故障并不是奇特的边缘案例——它们是可以预测的问题，系统化的清单可以发现这些问题。

我今天分享的清单就是我在每个测试的端点中使用的确切清单。它在过去一年中至少为我的团队避免了十几个生产事件，并且它足够全面，让初级工程师可以跟随，同时又足够详细，可以捕捉到高级开发者遗漏的问题。这不是理论——这是经过数百个API实施精炼的战斗测试流程。

身份验证和授权：基础层

在我测试其他任何内容之前，我会验证安全边界。这不仅仅是检查身份验证是否有效——而是系统地探测每个身份验证场景和授权边界。我见过太多在有效凭证下工作正常，但在凭证缺失、格式错误或属于错误用户时崩溃或泄露数据的API。

首先，我完全不使用身份验证令牌进行测试。该端点应该返回401未授权状态，而不是500内部服务器错误，更不应该返回实际数据。我遇到过一些生产API，当没有提供身份验证令牌时返回完整的用户记录，因为开发者假设身份验证中间件会始终运行，但实际上并没有。

接下来，我用过期的令牌进行测试。这会捕捉到意想不到的许多问题，因为令牌过期逻辑往往位于与初始身份验证不同的代码部分。响应应该清楚地返回401并带有指示令牌已过期的消息，而不是模糊的“未授权”，这让客户端不知所措，是否应该刷新或重新验证。

然后我用一个格式错误的令牌进行测试——随机字符串、去掉字符的令牌、其他系统的令牌。API应该优雅地处理这些情况，而不暴露堆栈跟踪或内部错误详情。曾经我发现有一个API，当提供包含某些Unicode字符的令牌时会崩溃整个服务，因为JWT解析库没有正确处理编码。

授权测试令人感兴趣。我测试有效的令牌，尝试访问不应拥有访问权限的用户的资源。对于GET /users/123端点，我将以用户456身份进行身份验证，并尝试访问123的数据。响应应该是403禁止，而不是404未找到（这泄露了资源存在的信息），更不应该是包含数据的200。

我还系统地测试基于角色的访问控制。如果你的API有管理员、经理和用户角色，我会用每个角色测试每个端点。我维护一个矩阵电子表格：行是端点，列是角色，单元格包含预期的状态码。这会在它们到达生产之前捕捉到权限错误，而这些错误在生产中会成为安全漏洞。

请求验证：输入边界测试

输入验证是大多数API展示其真实质量的地方。设计良好的API会彻底验证每个输入字段，并返回清晰、可操作的错误信息。设计差的API要么接受垃圾数据，要么神秘崩溃。

"大多数API故障并不是奇特的边缘案例——它们是可以预测的问题，系统化的清单可以发现这些问题。"

我从必填字段测试开始。对于每个必填字段，我发送一个没有该字段的请求。API应该返回400错误请求，并清晰地说明缺少哪个字段。我看到过一些API返回“验证错误”，却没有指定是哪个字段失败，迫使开发者猜测15个字段中的哪些导致了问题。

然后我测试数据类型验证。如果一个字段期望一个整数，我会发送字符串、浮点数、布尔值、null、数组和对象。每个应该返回400错误，并附带明确的消息，比如“年龄必须是一个整数”，而不是“请求格式无效”。我曾经测试过一个电子商务API，发送字符串作为数量导致系统创建了零个商品的订单，打断了整个履行流程。

字符串长度验证至关重要，通常被忽视。我用空字符串、单个字符、最大长度的字符串、超出最大长度一个字符的字符串以及异常长的字符串（10,000个字符以上）进行测试。我曾因为向未正确验证的字段发送兆字节大小的字符串而使生产数据库崩溃，导致内存耗尽。

对于数值字段，我系统地测试边界值：零、负数、期望整数时的小数、大于最大整数值的数字、以及像Infinity或NaN这样的特殊值。我曾测试过一个支付API，它接受负支付金额，这将允许用户任意给他们的账户存入资金。

日期和时间验证值得特别关注，因为它始终存在问题。我测试无效日期（2月30日，第13个月）、各种格式（ISO 8601、Unix时间戳、人类可读字符串）、远在过去或将来的日期，以及时区边界情况。我在开头提到的凌晨2点事件？那是一次日期验证失败。

对于枚举字段，我使用有效值、无效值、大小写变体和null进行测试。如果API将“活动”和“非活动”视为状态值，我会尝试“ACTIVE”、“Active”、“pending”、空字符串和null。每个应该被接受（如果不区分大小写）或被拒绝，并清晰地列出有效选项的消息。

响应验证：确保数据完整性

测试返回的内容同样重要，和测试输入内容一样。我看到过一些完美接受请求的API，但返回不一致、不完整或格式错误的数据，这会破坏客户端应用程序。