使用 RestAssured 进行 API 测试

前言

本文将借助 RestAssured 工具，向大家介绍如何进行 API 测试，从而在团队中开启接口自动化之路。

本文的示例代码使用的是 Java 语言。尽管本文的首要读者是 Java 研发人员，但道理是相通的，其他语言的研发人员也能从中受益。

What

什么是 API 测试？简单来说，可以认为是针对 Controller 层的测试，但不是 Mock，而是会真实地处理请求，与数据库或外部服务进行交互。

Why

为什么要做 API 测试呢？

考虑有过这样的场景：

• 加一个新功能，自测没问题，结果被测试人员发现一个旧模块出了问题，感到措手不及
• 后端写好了接口，前端还没开发好界面，于是感觉不方便自测，因为没有界面，只好催前端快去做页面

API 测试就是来解决上述问题的。做 API 测试的原因有：

• 必要性：做回归测试，避免添加新功能时破坏旧功能。
• 便利性：方便本地调试，不用部署到线上，依赖界面去测试。
• 资产化：让测试用例变成资产，与团队共享。

当然，要做好 API 测试，还要接受这样的认知： 接口自动化测试并不仅仅是测试人员事情，研发人员也有责任把它做好。 否则，研发人员难免会觉得这不关我的事, 从而不愿意写这种代码。 建议研发人员从以下方便思考其好处，提升行动的积极性：

• 减少阻塞，接口自测不再依赖前端
• 提高效率，本地就能自测，不用把应用部署到线上环境
• 提高质量，减少部署到研发环境、前端一调用接口就 500 的情况

为什么不用Postman

Postman 确实是符合直觉的接口调试的第一选项。 但注意，调试不等于测试。

Postman 在实践过程中，最大的问题在于，无法将测试用例有效地资产化:

• 你会在 Postman 里写断言吗？很少吧，你其实是在用肉眼去检查接口成功与否，这本质还是手工测试
• 你的 Postman 数据能与团队共享吗？不能吧，大多数人的 Postman 数据是在本地的，也不会去付费创建一个团队以共享数据
• 你的 Postman 数据在有版本管理吗？没有吧，大多数人的 Postman 数据是与源代码分离的，不利于维护与管理

另外，如果要与 CI 结合，Postman 的数据更适合使用 Node.js 的 Newman。

考虑源代码是 Java，使用 RestAssured，编写 API 测试代码用同一种语言，可以减少使用者的心智负担较轻；并且与源代码放在同一个 Git 仓库中，易于管理。

因此，我仍然会使用 Postman，但更多是把它应用在出现线上问题时，直接复制一个 cURL 用来复现、排查问题的情况。