收益：
- 能够在状态代码、模式/合约、业务规则和否定/授权层上利用人工智能支持进行深入的 API 测试
- 能够从示例响应生成 JSON 模式，并避免仅查看具有类型和命令式验证的状态代码的伪信心
- 能够使用合成数据测试授权和 IDOR 等安全场景，并且仅在授权范围内用于防御目的
大多数现代软件通过 API（应用程序编程接口——两个软件根据特定合约进行通信的接口）在后台相互通信。当移动应用程序将商品添加到购物车时，它实际上会向服务器上的 API 发送请求。 API 测试检查此对话是否正确、安全且一致，无论接口如何；它比 UI 测试更快、更稳定、更深入。人工智能 (AI) 在 API 测试中非常高效：它根据 API 定义生成测试，提取响应模式（定义数据结构的契约），列出边缘情况。但同样需要注意的是：人工智能不知道 API 的真正业务规则；往往会产生仅确认“200 返回”的肤浅测试。您的工作是确保测试验证实际的合同和业务逻辑。
在本单元中，您将学习如何使用 Postman、REST Assured 和模式验证等方法来设置 AI 支持的深度 API 测试。
API测试层数
考虑多个深度的 API 测试，人工智能在每一层提供不同的帮助：
1. 状态码和基本响应。请求是否返回预期的 HTTP 状态代码（200/201 表示成功，400/401/404 表示错误）？这是最表面的一层；人工智能很容易生产，但单独会带来错误的信任。
2. 模式/合约验证。响应的结构是否符合合同 - 是否存在预期字段，其类型是否正确，是否缺少必填字段？ AI 可以根据示例响应生成 JSON 架构（定义 JSON 文档结构的标准），并且测试可以根据该架构进行验证。这比手动编写基于字段的断言要健壮得多。
3.业务规则验证。真正的值在这里：“对于1000 TL的订单，折扣字段应该是100”，“已取消的订单不能再次取消”。只有当你给它规则时，人工智能才会验证这些；如果你不给它，它就会跳起来。
4.消极和安全。 401 表示无效令牌，403 表示访问其他人的数据，清除 400 表示错误的正文。授权测试（验证用户只能访问自己的数据）是 API 安全的核心，用于防御目的。
提示：在未告知 AI“不仅验证状态代码，还验证响应架构和那些业务规则”的情况下，请勿请求测试。否则，您将留下显示“200 返回，通过”的测试，但不会注意到 API 返回损坏的数据。
弱提示/强提示
弱：“为这个 API 编写测试。”
强：“为 POST /order 端点编写 REST Assured (Java) 测试。协议：productId 和数量在正文中是必需的；成功时返回 201 和 {orderId,total,discount,status}。业务规则：超过 1000 TL 折扣 10%；如果数量<=0，则为 400；如果令牌无效，则为 401；当查看其他用户的订单时，为 403。测试：(1) 状态代码，(2) 响应 JSON 架构验证，(3) 折扣业务规则，(4) 将每个断言绑定到显式业务规则；不要只检查 200/201。”
强大的提示给出了合约、业务规则、安全场景、模式验证期望。
合同测试：防止团队之间的分裂
在微服务架构（应用程序被划分为彼此独立并与 API 通信的小服务的结构）中，更改服务的响应格式会默默地中断与其连接的其他服务。契约测试（验证提供者服务和消费者服务之间的 API 契约双方都没有被破坏的测试）可以及早发现此类破坏。这个想法是这样的：消费者将他期望从生产者那里得到的响应形式定义为“合同”；对于每次更改，制造商都会测试其是否仍然遵守本协议。因此，当字段的名称或类型发生变化时，消费者会在管道崩溃之前通知管道。
在此背景下，人工智能加速了两项任务：起草一份反映消费者对现有 API 响应的期望的合同，以及预先标记更改可能会违反哪些合同条款。但合同本身是一个商业决策：专家确定哪些领域真正关键，哪些变化将破坏向后兼容性——老消费者继续工作。 AI写合同；你是批准它的人。
提示：在 API 中删除字段或更改字段类型几乎总是重大更改。添加新字段通常是安全的。让 AI 将更改分类为“破坏性或安全”，可以提供快速的预发布安全检查。
Postman 还是基于代码？
标准
邮差/纽曼
REST 确保/代码（Java、C#、JS）
学习
简单、直观
需要代码知识
版本控制
集合 JSON
直接在源代码中
复杂的逻辑
有限（JS 脚本）
完整的编程能力
CI/CD 集成
与纽曼
直接依赖于构建
模式验证
带测试脚本
强大的库
团队规模
小/中
大、成熟
人工智能为两者生成代码；明确你想要哪一个。
四个可复制模板
1）基于合约的API测试：
您的角色：高级 API 测试工程师。使用 [工具/语言] 为以下端点编写测试：[方法 + 路径]。合同：[必填字段、成功代码、响应结构]。业务规则：[规则]。测试层：(1) 状态代码 (2) 响应模式验证(3) 每个业务规则 (4) 否定 + 授权。将每个断言链接到相关规则/合同条款。
2) 从样本响应生成模式：
从下面的示例 API 响应生成 JSON 架构。指定必填字段、类型、格式限制（日期、电子邮件、数字范围）。然后给出一个针对此模式进行验证的测试示例。响应示例：[粘贴 JSON]
3）否定和授权场景：
为端点[端点]生成负面和安全测试用例。包括：缺失/必填字段、错误类型、值太大、令牌无效/过期、访问未经授权的资源（IDOR — 通过更改 ID 访问他人的记录）、速率限制。指定每个场景的预期状态代码和错误正文。注意：只会在我自己的API上进行测试，已授权。
4）伪信任控制：
查看此 API 测试。如果服务器返回正确的状态代码但 FALSEbody/data，此测试是否会捕获？如果没有，请添加架构和业务规则验证。测试：【粘贴测试】
三个迷你箱子
案例 1 — 模式验证的威力。一个团队仅在使用 AI 生成的测试中检查状态代码。在一个版本中，API 开始错误地将总计字段作为文本返回（“1200”）；测试保持绿色，因为它仍然返回 200。移动应用程序崩溃了。使用“从示例响应生成模式”模板添加类型验证后，立即捕获了相同的错误。
案例 2 — 权威差距 (IDOR)。一位专家在AI生成的“否定场景和授权场景”之间进行了IDOR测试：他用用户A的token请求用户B的订单ID。API返回的数据为200和B，这是一个严重的授权漏洞。这项防御性测试在上线之前就阻止了数据泄露。
案例 3 — 业务规则绕过。 AI为折扣端点生成了8个测试；所有人都检查了 200，没有人核实折扣金额。专家将业务规则添加到提示中并进行了复制。新测试显示，在 1000 TL 限额时折扣计算不正确（折扣也适用于 999 TL）。合同控制不够；业务规则控制是必须的。
常见错误
- 只看状态码。说“200已返回并已过去”；没有看到腐败的身体（虚假信任）。
- 绕过架构验证。不检查字段类型和义务；类型更改会悄无声息地进行。
- 请求测试而不提供业务规则。人工智能不知道规则；它只产生技术控制。
- 忘记负面和权利场景。安全漏洞（IDOR、未经授权的访问）只能通过这些测试来发现。
- 使用真实/生产代币和数据。使用专用媒体和合成数据进行测试；请勿将真正的钥匙插入车辆。
- 未经授权的安全测试。仅在您自己的 API 上并获得许可时运行授权测试。
总之
API 测试可以快速、深入地验证软件的语音，无论接口如何。人工智能;合约测试在从示例响应生成 JSON 模式和负面/安全场景方面非常有效。但仅检查状态代码的肤浅测试给出了伪信心。需要所有四个层：状态代码、模式验证、业务规则、否定和授权。将业务规则和合同及时写入；仅在授权的情况下使用合成数据执行安全测试。
应用任务
从您自己的项目中选择一个 API 端点。让 AI 使用“基于合约的 API 测试”模板编写四层测试。然后使用“从样本响应生成模式”添加类型/强制验证并应用“伪信任检查”。在您自己的测试环境中运行至少一个 IDOR/授权场景。报告您发现的任何违反合同或业务规则的行为；如果找不到任何内容，请针对故意乱码的响应运行测试以证明它捕获了它。
清单
- [ ] 我涵盖了四个测试层（案例、模式、业务规则、否定/授权）。
- [ ] 我明确地将契约和业务规则交给了AI。
- [ ] 我设置了验证响应模式（字段、类型、命令式）的测试。
- [ ] 我已经尝试过至少一种防御性授权/IDOR 场景。
- [ ] 我使用测试环境和合成数据而不是真实的令牌/数据。
- [ ] 我通过“伪置信度检查”证明每个测试都能捕获损坏的响应。