在最近的部署中，当我被问到“什么是API测试？”时，我正与客户一起制定API测试策略。那时我突然意识到，要描述API测试居然是一件如此具有挑战性的事情，即使你如实地描述了它，也往往听起来很无聊和复杂。

好吧，容我在这里告诉你，API测试并不乏味或复杂。它实际上非常有趣且功能强大，换一种思路和方式来理解它，可以释放你创建真正有效的测试策略的能力。要真正了解如何进行API测试，请继续阅读。

什么是API，如何使用？

在服务开发中，应用程序接口（API）是各种应用程序使用通常由协议定义的通用语言相互通信的一种方式。这些示例是用于RESTful服务的Swagger文档或用于SOAP服务的WSDL。甚至数据库都有接口语言，即SQL。

API就像UI允许人类与应用程序交互的方式一样，使机器之间能够高效地进行通信。

API之所以出色，是因为它们代表了构建块，开发人员可以使用它们轻松地组装各种交互，而不必在每次需要机器进行通信时都重写接口。另外，由于API具有协议，因此只要彼此之间按照API协议进行通信，就可以以完全不同的方式构建希望相互通信的应用程序。这使来自世界各地的不同组织的不同开发人员可以创建高度分布的应用程序，同时可以重复使用相同的API。

当用户与应用程序（即移动应用程序）的前端进行交互时，该前端对后端系统进行API调用，从而通过两种主要方式简化了开发过程：

1. 开发人员不必担心为每个移动设备或浏览器制作定制的应用程序。
2. 可以更新或修改不同的后端系统，而不必每次都重新部署整个应用程序。

结果，开发人员可以通过将单个服务集中于完成离散任务来节省时间，而不必花费时间将逻辑写入其应用程序。

标准API使用的一个很好的例子

亚马逊购物服务的文档化API使开发人员可以在创建应用程序时与亚马逊购物进行交互。开发人员可以在其用户体验的适当时间使用Amazon API，以创建无缝的客户旅程。

例如，这可能看起来像这样：

用户与用户界面进行交互，而应用程序与开发人员定义的后端Amazon API进行交互。只要基础API的行为符合预期，一切就可以很好地工作。

……但是如果量很大的话。

于是，我们得出了测试这些API的重要性。

什么是API测试？

那么如何执行API测试？它到底意味着什么？如何进行API测试？与仅在UI级别与应用程序进行交互的用户不同，开发人员/测试人员必须确保任何和所有基础API的可靠性。如果不对API本身进行测试，则开发人员和测试人员将被困于手动测试，就像用户在UI级别上对应用程序进行测试一样，等到整个应用程序堆栈都已构建之后才能开始测试。

相反，你可以改为通过以下方式执行自动API测试：在API级别测试应用程序，设计与基础API直接交互的测试用例，并以此获得众多优势（包括以稳定方式在易于自动化的层上测试业务逻辑的能力）。与手动测试（仅限于验证特定的用户体验）不同，API测试使你能够针对未知情况对应用程序进行防弹。

如何进行API测试？

不同类型的API测试——位置、原因和方式

进行API测试的最佳方法是从下至上构建可靠的测试实践。为此，一种设计测试策略的好方法是遵循Martin Fowler的测试金字塔。金字塔方法建议你在具有UI测试的单元测试的坚实基础之上，构建各种API测试（例如，协议、方案、性能等）。API测试允许你在单元测试无法达到的水平上测试应用程序逻辑。

这些测试策略是互补的。在应用程序的较低层进行更早的测试，可以帮助你“快速失败并尽早报错”，尽早在源头而不是在SDLC中发现缺陷。单元测试很重要，但是目前我们专注于API测试。你如何测试APIS？可以进行哪些测试？他们为什么重要？如何进行API测试？

你如何使用API？

下一节将介绍不同类型的API测试，包括在何处/为什么/如何使用它们。

协议测试

API表示2个或更多应用程序之间的协议。协议描述了如何与接口交互、可用的服务以及如何调用它们。该协议很重要，因为它是沟通的基础。如果协议有问题，那么别的什么都没有用了。

API测试的第一个也是最基本的类型是协议测试，它测试服务协议本身（Swagger，PACT，WSDL或RAML）。这种类型的测试可以验证协议是否正确编写，并且可以由客户使用。该测试通过创建一系列可以拉入协议并验证以下条件的测试来工作：

• 服务协议是按照规范写的
• 消息请求和响应在语义上是正确的（模式验证）
• 端点有效（HTTP，MQ / JMS主题/队列等）
• 服务协议没有改变

我认为这些是你的第一个“烟雾测试”。如果这些测试失败，则实际上没有理由继续测试该特定服务。如果这些测试通过，则可以继续测试API的实际功能。

组件测试

组件测试就像API的单元测试一样——你想采用API中可用的各个方法，并分别测试其中的每个方法。通过对服务协议中可用的每种方法或资源执行测试步骤来创建这些测试。

创建组件测试的最简单方法是消耗服务协定，并让它创建客户端。然后，你可以使用正负数据对每个单独的测试用例进行数据驱动，以验证返回的响应具有以下特征：

• 请求有效载荷格式正确（模式验证）
• 响应有效载荷格式正确（模式验证）
• 响应状态符合预期（200 OK，返回了SQL结果集，甚至是一个错误，如果你要这样做）
• 响应错误有效负载包含正确的错误消息
• 响应与预期的基线匹配。这可以采取两种形式：
  • 回归/差异——响应有效负载在每次调用之间看起来完全相同（自上而下的方法，实际上是你捕获响应的快照并每次都对其进行验证）。这也可能是识别API更改的重要催化剂（稍后会详细介绍）。
  • 断言——响应中的各个元素都符合你的期望（这是针对响应中特定值的更浅显、自下而上的方法）。
• 服务在预期的时间内响应

这些单独的API测试是你可以构建的最重要的测试，因为它们将在所有后续测试技术中得到利用。当你可以在以后所有不同类型的测试中简单地引用这些单独的API调用时，为什么还要重建测试用例呢？这不仅提高了一致性，而且简化了进行API测试的过程。

场景测试

大多数人在考虑API测试时都会想到场景测试。在这种测试技术中，你将各个组件测试组装成一个序列，就像我上面为Amazon服务描述的示例一样。

获取序列有两种很棒的技术：

1. 查看用户故事，以识别正在进行的各个API调用。
2. 练习UI并捕获对基础API的流量。

通过场景测试，你可以了解是否可能通过将不同的数据点组合在一起而引入缺陷。

与客户合作时，我遇到了一个非常有趣的示例。他们采用了一系列服务来呼叫客户的财务资料、可用帐户、信用卡和最近的交易。这些API调用中的每个调用都是单独工作的，但是当你按顺序将它们放在一起时，它们就会开始报错。造成这种情况的原因是一个简单的时间戳，从一个API调用返回时，它的格式与后续请求中期望的格式不同。他们在进行单元测试或冒烟测试时没有意识到这一点，因为他们断言返回时间戳时未指定格式。直到测试整个场景后，才可以清楚地发现，将时间戳从一个呼叫转移到另一个呼叫会导致故障。

场景测试的另一个好处是，当你以未预期的方式使用API时，可以验证预期的行为。发布API时，你将向外界提供一系列构建模块。你可能具有将这些块组合在一起的规定技术，但是客户可能会有无法预料的需求，并且意外地将API组合在一起以暴露应用程序中的缺陷。为了防止这种情况，你会想到使用API的不同组合创建许多方案测试，以使应用程序免受重大故障的影响。

由于组件测试构成了场景测试的基础，因此组织通常拥有大量的场景测试。它们是在引入新功能以模拟客户使用新功能的旅程时构建的。这样一来，你确实可以减少测试时间，因为你只需要为新功能构建测试，并且你知道自己拥有可靠的基础测试库来捕获任何意外情况。

性能测试

在特定于性能的测试环境中，性能测试通常会降级到测试过程的结尾。这是因为性能测试解决方案往往很昂贵，需要专门的技能，并且需要特定的硬件和环境。这是一个大问题，因为API具有必须满足的服务级别协议（SLA），才能发布应用程序。如果你等到最后一刻进行性能测试，则无法满足SLA可能会导致巨大的发布延迟。

在流程的早期进行性能测试，可以使你在运行完整的回归周期之前发现与性能相关的问题。如果你到目前为止一直遵循测试过程，那么实际上将非常容易，因为你拥有执行性能测试所需的所有基础测试用例。你可以简单地进行场景测试，将其加载到性能测试工具中，然后以更多的用户数量运行它们。如果这些测试失败，则可以将失败的原因追溯到各个用户，并更好地了解将受到的影响。然后，管理人员可以利用这种了解来决定是否发布应用程序。

安全测试

安全测试对组织中的所有利益相关者都很重要。如果暴露并利用了安全漏洞，则可能导致严重的声誉损失和财务损失。就像用户会意外地使用你的API一样，用户也可能有意尝试利用你的API。黑客可以掌握你的API，发现漏洞并加以利用。

为了防止此类行为，你需要构建测试案例以尝试执行这些类型的恶意攻击。你可以利用现有的测试用例来执行此操作，因为方案测试可以将攻击向量提供给应用程序。然后，你可以重新使用此攻击媒介来发起渗透攻击。一个很好的例子是将不同类型的参数模糊测试或SQL注入攻击与方案测试结合在一起。这样，通过应用程序传播的任何更改都将由你的安全测试选择。要了解有关API安全测试的更多信息，请查看这篇文章并持续关注。

全渠道测试

由于应用程序与之交互的多个接口（移动，Web，API，数据库等），如果单独测试其中的任何一个，你将遇到测试覆盖率的空白，而忽略了这些接口之间复杂的交互的精妙之处。

全渠道测试通过将API和数据库测试交织到移动和Web UI交互的验证中，全面覆盖了应用程序的许多界面，以确保彻底覆盖测试范围。这意味着要进行一个正在使用其中一个接口并与另一个接口进行协调的测试——执行Web（Selenium）或Mobile（Appium）之类的UI测试，并将它们与你的API或数据库测试中的任何一个交织在一起，从系统通过测试执行。借助有效的全渠道测试，你可以创建稳定、可重用的测试案例，这些案例可以轻松实现自动化。

管理变更

更改是应用程序风险的最重要指标之一。变更可以多种形式发生，包括：

• 服务的协议消息格式更改
• 从API添加或删除的元素
• 底层代码更改会影响返回的数据格式
• 重新架构服务以将其分解为多个部分（随着组织转向微服务，这种情况极为普遍）

发生更改时，你需要构建测试用例以识别更改并提供补救计划。使用提供分析以解决这些更改的影响的解决方案，将使你了解发生了什么更改并确定受影响的特定测试的目标。

然后可以以模板的形式捕获更改，以使用新功能更新任何基础组件或方案测试。由于其余测试引用了这些测试，因此更改的影响将减少。

总结

建立可靠的自动化API测试策略是确保你的应用程序“今天和昨天一样工作”的最佳方法（这不仅仅是一个容易理解的短语而已）。API测试允许你构建一个可靠的框架来识别应用程序多层中的缺陷。这些测试可以全部自动化并且可以连续运行，因此你可以确保应用程序符合业务期望，同时也能保障功能的精确。由于API测试的工作水平远低于UI测试的水平，因此你知道你需要保持一致性，并且所构建的测试将持续很长时间。

加油吧，少年！你准备开始API测试了吗？但在此之前你还需要弄清楚要使用什么工具。有兴趣的朋友请持续关注后续文章，了解如何为你的组织选择最佳的API测试解决方案。