# 六个字母，帮 FDE 摸清客户 API 的真实行为

> Amber Race 的课程把摸索陌生 API 拆成六项检查，再借 Newman 放进 CI，让探索所得变成安全网。

原文: https://fdetimes.net/zh/books-courses/poised-api-exploration-amber-race/

到客户现场的第一天，通常拿到的只有一个 base URL、一个 token 和一份过时的 API 文档。没人告诉你传错参数时系统会返回什么。

Amber Race 在 Test Automation University（Applitools）开设的课程 Exploring Service APIs through Test Automation，讲解为什么要测试服务 API，并在每节课中用实例教学。课程虽然从测试角度切入，教的却正是这最初几天最需要的能力：系统地摸清一个陌生的 API。

Race 是 Big Fish Games 的高级测试开发工程师（Senior Software Development Engineer in Test），在 Big Fish 和 Microsoft 从事测试工作超过 15 年。课程页面既没有给出发布年份，也没有标注时长。

课程分为四部分：API 测试入门；用 Postman 探索 API；分六章（3.1–3.6）讲解的 POISED 策略；编写测试，包括第一个测试、数据驱动测试、进阶技巧和 Newman。

对前线部署工程师（FDE）来说，这门课的价值不在 Postman，而在一种思路：写下第一行集成代码之前，先弄清客户系统如何应对错误输入、过期 token 和异常数据。

## 为什么要把 API 当作契约？

第 1 章开篇给出一个朴素的定义：API 是一段与另一段代码对话的代码。Race 由此引出核心观点：API 是让程序之间相互通信的契约。因此，测试 API 就是检查双方的约定是否依然成立。

这个视角改变了你在客户需求调研中提出的问题。不再问“这个 API 做什么？”，而是问“这个 API 承诺了什么，向谁承诺？”如果客户答不上来，这就是部署计划里应写下的第一个风险。

这一章的第二个观点更加犀利。Race 提醒，不能假定 API 总会按设计通过用户界面调用。

在企业环境里，这种情况每天都在发生：一段老旧的 cron 脚本、一套 ERP 系统，或者你正要构建的 Agent，都会直接调用 API，绕过 UI 默默完成的所有校验。

**要点:** 别信任界面：直接测试 API 承诺过的东西。

## POISED 把探索变成检查清单

在课程中，POISED 是一种测试覆盖的启发式方法，包含六个类别：Parameters、Output、Interop、Security、Errors、Data。Abstracta 博客上一篇独立文章认为这一方法由 Race 提出，并将 POISED 描述为评估系统质量和韧性时需要考虑的六个方面。

假设你要通过一个虚构的端点 `GET /shipments?from=&to=&page=` 与一家物流公司对接。下表是示意性示例，并非出自课程，展示六个类别如何落成具体测试。

| 类别 | 在虚构端点上的测试 | 想弄清什么 |
|---|---|---|
| Parameters | 省略 `from`，设置 `page=0`、`page=-1`、格式错误的日期 | API 是自己校验输入，还是依赖 UI |
| Output | 逐个字段与文档对照，找出可能为 null 的字段 | 你的代码将依赖哪些字段 |
| Interop | 不经过 UI，像其他系统那样直接调用 | 前面没有 UI 层时它如何表现 |
| Security | 使用过期 token、其他租户的 token | 数据是否会泄露到授权范围之外 |
| Errors | 主动触发 4xx 和 5xx 错误，阅读错误信息 | 错误是否清晰，是否暴露堆栈信息 |
| Data | 使用含特殊字符、不同时区的真实记录 | 真实数据是否与文档中的样例一致 |

最后一列值得带到与客户的会议上。其中每个空白格，都是上线生产环境之前客户方必须有人回答的问题。

## 怎样的学习顺序最省时间？

如果你已有几年软件工程经验并熟悉 Postman，可以快速浏览第 1 章，领会契约这一思路，跳过第 2 章大部分内容，把时间花在 POISED 的六章上。然后学习第 4 章，尤其是数据驱动测试，因为这样才能覆盖客户真实数据中的各种变化，而不必手写每个请求。

如果你从没写过 API 测试，就按课程顺序学习。第 2 章教的 Postman 技能足够让后面的示例不成障碍。

在 2016 年的一期 TestGuild 播客中，Race 对如何熟悉陌生 API 给出了简单的建议：动手去玩。POISED 则让这种“玩”变得有章法。

## 从探索到部署安全网

最后一章讲解 Newman：一个在命令行运行 Postman 集合的工具，需要 Node.js。Race 在课程结尾把集合放进 Jenkins 这类 CI 环境，让 API 检查成为构建的一部分。

对 FDE 来说，这是最重要的转变。第一周为理解客户系统而写的测试，正是三个月后客户悄悄修改 API 时发出警报的那批测试。客户一旦回答了表格最后一列中的某个问题，这个答案就应当变成 CI 中运行的集合里的一条断言。

在职业层面，可以把这门课变成能力证明。建一个小仓库：选一个公开 API，编写覆盖 POISED 全部六个类别的集合，并在 GitHub Actions 中运行 Newman。

在简历上，描述你如何探索陌生 API 的行为，再用自动化测试持续监控它。阅读 FDE 招聘启事时，留意关于对接客户系统的描述：面试时就在这里提到这个仓库。

不做探索就直接集成，等于押注客户的文档。Race 的六个字母，让你在不得不下注之前，就知道 API 实际上在做什么。

**本周动手试试:**

- 挑一个正在对接的真实端点，为 POISED 每个类别至少写一个测试。
- 先学课程第 3.1–3.6 章，再回到第 4 章学习数据驱动测试。
- 在命令行用 Newman 运行你的 Postman 集合，再把这条命令加入项目的 CI 流水线。

## 信源

- [exploring service apis through test automation (Test Automation University)](https://testautomationu.applitools.com/exploring-service-apis-through-test-automation/)

- [amber race (Test Automation University instructor)](https://testautomationu.applitools.com/instructors/amber_race.html)

- [Transcript lesson1.0 (Exploring Service APIs through Test Automation, Chapter 1)](https://testautomationu.applitools.com/exploring-service-apis-through-test-automation/chapter1.html)

- [Chapter 3.0: POISED API Testing Strategy (Test Automation University)](https://testautomationu.applitools.com/exploring-service-apis-through-test-automation/chapter3.0.html)

- [Heuristics in API Testing for Quality Software (Abstracta)](https://www.abstracta.us/blog/software-testing/heuristics-in-api-testing-for-quality-software)

- [Chapter 4.4: Newman (Test Automation University)](https://testautomationu.applitools.com/exploring-service-apis-through-test-automation/chapter4.4.html)

- [121: Testing Video Games Using API Automation with Amber Race (TestGuild)](https://testguild.com/podcast/121-testing-video-games-using-api-automation-amber-race/)