软件测试23-知其然知其所以然：聊聊API自动化测试框架的前世今生

在上一篇文章中，我以一个简单的 Restful API 为例，分别介绍了 cURL 和 Postman 的使用方法，相信你已经对 API 测试有个感性认识了。

但是，我们不能仅仅停留在感性认识的层面，还需要熟悉并掌握这些测试方法，完成相应的 API 测试工作。所以，也就有了我今天分享的主题，希望可以通过对 API 自动化测试框架发展的介绍，让你理解 API 测试是如何一步一步地发展成今天的样子，以“知其所以然”的方式加深你对 API 自动化测试的理解。

接下来，我将会遵循由简入繁的原则，为你介绍 API 测试框架，以发现问题然后解决问题的思路为主线，展开今天的分享。

早期的基于 Postman 的 API 测试

早期的 API 测试，往往都是通过类似 Postman 的工具完成的。但是，由于这类工具都是基于界面操作的，所以有以下两个问题亟待解决：

1. 当需要频繁执行大量的测试用例时，基于界面的 API 测试就显得有些笨拙；

2. 基于界面操作的测试难以与 CI/CD 流水线集成。

所以，我们迫切需要一套可以基于命令行执行的 API 测试方案。这样，API 测试可以直接通过命令行发起，与 CI/CD 流水线的整合也就方便得多了。

基于 Postman 和 Newman 的 API 测试

于是就出现了集成 Postman 和 Newman 的方案，然后再结合 Jenkins 就可以很方便地实现 API 测试与 CI/CDl 流水线的集成。Newman 其实就是一个命令行工具，可以直接执行 Postman 导出的测试用例。

用 Postman 开发调试测试用例，完成后通过 Newman 执行，这个方案看似很完美。但是在实际工程实践中，测试场景除了简单调用单个 API 以外，还存在连续调用多个 API 的情况。

此时，往往会涉及到多个 API 调用时的数据传递问题，即下一个 API 调用的参数可能是上一个 API 调用返回结果中的某个值。另外，还会经常遇到的情况是，API 调用前需要先执行一些特定的操作，比如准备测试数据等。

因此，对于需要连续调用多个 API 并且有参数传递的情况，Postman+Newman 似乎就不再是理想的测试方案了。

基于代码的 API 测试

为了解决这个问题，于是就出现了基于代码的 API 测试框架。比较典型的是，基于 Java 的 OkHttP 和 Unirest、基于 Python 的 http.client 和 Requests、基于 NodeJS 的 Native 和 Request 等。

小型的互联网企业，往往会根据自己的业务需求&#x