API 测试入门指南
原文标题：From Shock to Acceptance: The Five Stages of API Testing
原文链接：https://dev.to/sergey_mogilevsky/from-shock-to-acceptance-the-five-stages-of-api-testing-2g7h
作者：Serhii Mohylevskyi
API 测试的重要性
我们经常害怕接触新事物和未知事物，但如果你更深入去探索，会发现其实并不可怕。在本文中，我将告诉你为什么 API 测试并不困难，以及这项技能将如何帮助你成为一名更优秀的 QA 专家。
当谈到团队中的 API 接口测试时，初级 QA 工程师通常会感到困惑，甚至看着服务器的方向都觉得可怕，更不用说向它发送请求了。在测试 UI 时，你会不由自主地成为产品的用户，并看到与潜在客户相同的图形界面。在浏览器的必填字段中输入文本就足够了，如果发生错误，你会收到可理解的错误提示。但是当你需要熟悉 API 时，它似乎需要不同的测试策略。你所需要的只是稍微多一点的技术知识：
- 了解客户端-服务器体系结构
- HTTP 协议的原理
- 了解 JSON 和 XML 数据传输格式当然，还要对自己抱有足够的信心。
为什么要测试 API
我们发现，微服务架构已成为当下最流行的软件架构。闭门造车的方法正在慢慢成为过去。如今，所有前沿的云解决方案都是在微服务架构上创建的。面对这类型产品的时候，你只能使用后台进行测试，因为它根本不会给你提供 UI 界面。
在一个单体应用中，前后端按照单一且不变的方式通过代码进行通信。这就像和你的同事一起打乒乓球，你们的角色定位是清晰的(两人互为对手)。微服务不同的地方在于：每个微服务都是一个独立的服务端，具有自己的逻辑。
比如，一个负责创建照片，另一个负责处理它们，第三个负责存储，第四个负责传输给用户。在这种情况下，原本两个人的乒乓球运动变成了多人的棒球运动：首先，你需要击球，然后追赶它、接住它。同样，微服务既可以是客户端，也可以是与其他“玩家”相关的服务端。
举个例子：有一个微服务可以对照片添加滤镜，另一个微服务可以存储文件。它们的通信有两种选择：
- 方式一：加滤镜服务调用存储服务，获取到所需的文件后，为照片添加滤镜。这里，滤镜微服务是客户端，储存微服务是服务端。
- 方式二：存储微服务获取它的一张照片并将其携带到滤镜微服务，以便确定将哪个滤镜应用于这张照片，滤镜微服务返回：嘿，盆友，是棕褐色。这是客户端和服务端颠倒的方式。
为了让微服务相互理解，它们提供了 API (应用编程接口)，这是一种特殊的软件接口。测试这些接口有助于确保程序实现预期目的，并可以与其它程序正确交互。即使你只具备较少的理论基础，也可以验证和自动化 API 测试。最重要的是找到合适的工具。
阶段 1：初识 API 测试
想象一下，QA 专家 John，他被告知要测试在医院软件中创建自定义卡的功能。但是该产品没有用户界面，并且数据来自第三方系统。也就是说，该功能的用户是另一个程序。在此之前，John 的整个职业生涯都在做纯手动的 UI 测试。因此，在这个测试阶段，他体验到的第一种情绪是感到迷惘：他面前没有熟悉的按钮和输入框。
译者注：与原文使用 Postman 为例不同，为了便于中国开发者本地化体验，本篇译文中将以 Apifox 为例，你可以自由选择你熟悉的开发工具或 API 客户端。
遇到这种情况，我们可以考虑使用一些常用的 API 接口测试工具。工具允许我们用比较容易理解的形式发出请求，并以它理解的语言将其传输到服务端。 要向服务器请求信息，你需要使用 HTTP 协议，这是客户端-服务器体系结构中的一种超文本传输格式。
HTTP 协议有不同类型的请求，有时客户端想要向服务器请求或发送一些东西，有时想从服务器中删除信息。最常见的是：GET、HEAD、POST、PUT、DELETE、CONNECTOPTIONS、TRACE、PATCH。这些方法定义了可对服务器进行的操作。
因此，我们选择发送请求的 URL 如下：
我们要告诉服务器的是请求 body，这个是可选的。在请求传输的方法中包含了传给服务端的关键信息。因此我们需要在 Path 参数中写入所需的链接，并在 body 中指示了有关医疗卡的信息：名字、姓氏、患者的年龄和诊断说明。Header 参数用来帮助服务器正确解密邮件。有时它与请求正文没有关联，或者根本不存在。通过在 Header 中指定“Accept”，我们让服务器知道客户端准备接收什么数据作为响应。如果你对任何信息感到满意，则 Header 应包含值“*/*”。
阶段 2：遭遇服务器报错
接下来 API 测试工具返回了一组文本、引号、逗号和其它字符。John 什么都看不懂，他很生气。服务端正在报错——到目前为止，他几乎不相信会有什么有用的结果。
HTTP 协议不仅描述了请求，还描述了服务器响应。“415”是状态码。服务器指示它收到了无法读取的数据。对于不同的情况，有许多状态码。“200 OK”是请求成功的指示符。所有互联网用户都知道 404 代码，这表示没有找到该资源。因此，我不会在状态码上纠结。你可以很容易地在搜索引擎上找到这些资料。
John 究竟哪里做得不对？最有可能的是，他没有正确设置文件的“打包”方式。JSON 和 XML 用于存储和传输数据，这两种格式是完全可互换的。仅仅通过文本来传达大量信息是很困难的。当然，如果数据不是用来给计算机读取的，那就可以通过文本来完成。计算机程序必须事先知道数据的格式和类型，如何在系统中找到并使用它们。你不能将 XML 或 JSON 发送到所有服务器，并相信这些信息一定会被理解。开发者在创建程序时已经规定了接收数据的格式。
John 通过搜索引擎，发现了他的服务端设定了用 JSON 格式的数据进行通信，他再次以所需的格式向相同的地址发送请求后显示成功了。服务器返回了另一组信息提示语，正因为我们使用了 API 测试工具，这些信息才得以正确地翻译出来。
因此，让我们总结一下：HTTP 协议定义了客户端和服务器之间的通信格式。当你要发送一个 HTTP 请求，你需要使用类似 Apifox 的 API 工具；客户端发送一条消息并接收适当的响应，与服务器的通信采用其中一种格式 —— JSON/XML；最后接收到的数据由软件来进行解密。
阶段 3：学习一门编程语言
要使 API 测试自动化，你需要掌握一种编程语言：Python、Java、C# 或项目中你喜欢或需要的任何语言。有的 QA 工程师可能会说：学习编程这也太难了吧！事实上，几行代码就足够了。要运行简单的自动化测试，你只需要掌握一门语言的基础。你还可以找到用于编写 HTTP 请求的库。无论如何，学习编程的基础知识将是对你的专业经验的一项重大投资。一开始会很困难，但我向你保证，你很快就会发现自己的 API 自动化测试的能力得到了一个巨大提升。
阶段 4：掌握自动化测试
我不再需要说服 John 理解 API 测试和自动化的好处，因为在我的 16 人团队中，有 5 人在测试 API Web 应用程序。很明显，已经越来越多人将自动化测试应用于工作中了。任何使用现代技术的网站或应用程序都有一个复杂的后端。开发人员很有可能会选择微服务架构来实现它。因此，在没有 API 自动化测试的情况下，你难以对它进行深入的测试。
阶段 5：稳扎稳打
工作没有捷径，无论是测试用户界面、增强现实、数据库、API 等等，方法通常是相同的。考虑测试用例和维护测试表的策略与普通手动 UI 测试中的策略几乎相同。对于 API 测试，需要上面提到的硬技能和工具。
如果你还没学会 API 自动化测试，那么当你以 QA 专业人员的身份开始职业生涯时，市场上的工作机会会非常少，因为你的能力限制了你的就业机会，排名靠前的项目是留给高度专业、能力扎实的人的。而这些优秀的项目，是每个人都梦寐以求的，对吧？ 要掌握测试，你不需要学习多年的理论，几个月的密集练习就足够了，跟随上面的进阶方案，努力成为一名优秀的 QA 工程师吧！
