API（应用程序编程接口）测试是一种直接在 API 级别执行验证的软件测试。它是集成测试的一部分，它确认 API 是否满足测试人员对功能、可靠性、性能和安全性的期望。与 UI 测试不同，API 测试是在没有 GUI 层执行操作的。
API 测试技巧
Web API 有两大类 Web 服务：SOAP 和 REST。SOAP（简单对象访问协议）是 W3C 标准定义的一种标准协议，用于发送和接收 Web 服务请求和响应。REST（表示状态传输）是使用 HTTP 的基于 Web 标准的体系结构。与基于 SOAP 的 Web 服务不同，没有针对 RESTful Web API 的正式标准。
以下是 API 测试的 10 条基本技巧：
了解 API 要求
在测试 API 之前，需要回答以下问题以彻底了解 API 的要求：
- API 的功能是什么？业务流程是什么？使用场景是什么？
通常，应用程序的 API 用于对资源进行操作。它们常用于读取，创建，更新。了解 API 的用途将为输入和输出准备好测试数据奠定坚实的基础。此步骤还可以帮助您定义验证方法。例如，对于某些 API，您将针对数据库验证响应。对于其他一些，最好根据其他 API 来验证响应。
例如，“创建用户” API 的输出将是 “获取用户” API 的输入以进行验证。“获取用户” API 的输出可以用作 “更新用户” API 的输入，依此类推。
指定 API 输出状态
您需要在 API 测试中验证的最常见的 API 输出是响应状态代码。
新 API 测试人员熟悉验证响应代码是否等于 200 以确定 API 测试是通过还是失败。这不是错误的验证。但是，它并不反映 API 的所有测试方案。
在通用标准中，所有 API 响应状态代码均分为五类。状态码的第一位数字定义响应的类别。后两位没有任何类别或分类作用。
第一位数有五个值：
- 1xx（信息性）：收到请求并继续进行处理
- 2xx（成功）：成功接收，理解并接受了请求
- 3xx（重定向）：需要采取进一步的措施来完成请求
- 4xx（客户端错误）：请求包含错误的语法或无法实现
- 5xx（服务器错误）：服务器无法满足看似有效的请求
API 的实际响应状态代码由构建 API 的开发团队指定。
专注于小型功能性 API
在测试项目中，总是有一些简单的 API，只有一个或两个输入，例如登录 API，获取身份令牌 API，运行状况检查 API 等。但是，这些 API 是必需的，被视为进入其他业务的 “门 API”。首先关注这些 API，将确保 API 服务器，环境和身份验证正常工作。
还应该避免在一个测试案例中测试多个 API。如果发生错误，这是很痛苦的，因为您将不得不按顺序调试 API 生成的测试数据。保持测试尽可能简单。在某些情况下，如果需要调用一系列 API 来实现端到端测试流程，这些任务应该在所有 API 都经过单独测试之后完成。
分类 API
一个测试项目可能有几个甚至数百个用于测试的 API。强烈建议将它们分类，以更好地进行测试管理。它需要采取额外的步骤，但是将大大帮助您创建具有高覆盖率和集成度的测试方案。
同一类别的 API 共享一些公共信息，例如资源类型，路径等。以相同的结构组织测试将使您的测试在集成流程中可重复使用和扩展。
利用自动化功能进行 API 测试
尽可能早地利用自动化进行 API 测试。以下是自动化 API 测试的一些重要好处：
- 测试数据和执行历史记录可以与 API 信息一起保存。这使得以后重新运行测试变得更加容易。
- API 测试稳定且较少更改。API 反映了系统的业务规则。API 的任何更改都需要明确的要求；因此，测试人员始终可以及时了解更改并进行调整。
- 与 Web UI 测试相比，测试执行速度要快得多
- API 测试被视为灰盒测试，用户可以在其中发送输入数据并获取输出数据以进行验证。数据驱动方法的自动化（即在同一测试场景中应用不同的数据集）可以帮助增加 API 测试覆盖率
- 数据输入和输出遵循某些特定的模板或模型，因此您只能创建一次测试脚本。这些测试脚本也可以在整个测试项目中重复使用
- API 测试可以在软件开发生命周期的早期进行。具有模拟技术的自动化方法可以帮助在开发实际的 API 之前验证 API 及其集成。因此，减少了团队内部的依赖性。
选择合适的自动化工具
利用 API 测试的自动化功能的另一步骤是从市场上的数百种选择中选择最合适的工具或一组合适的工具。选择 API 自动测试工具时，应考虑以下一些标准：
- 该工具是否支持测试您的 AUT（被测应用程序）正在使用的 API / Web 服务类型？如果您在 AUT 使用 SOAP 服务时所选的工具支持测试 RESTful 服务，则没有任何意义。
- 该工具是否支持您的 AUT 服务所需的授权方法？以下是您的 API 可以使用的一些授权方法：No Auth、Bearer Token、Basic auth、Digest Auth、NTLM Authentication、OAuth 1.0、OAuth 2.0、Hawk Authentication、AWS Signature。这是一项必不可少的任务，因为你无法在未经授权的情况下开始测试 API。
- 该工具是否支持从 WSDL，Swagger，WADL 和其他服务规范中导入 API / Web 服务端点？这是一项可选功能。但是，如果您要测试数百个 API，这一点非常重要。
- 该工具是否支持数据驱动的方法？这也是一项可选功能。
- 最后但并非最不重要的一点是，除了 API 测试之外，您是否还需要执行其他类型的测试，例如 WebUI 或数据源？API 测试在数据源和 UI 之间的业务层执行。所有这些层都必须进行测试是正常的。支持所有测试类型的工具将是理想的选择，这样您的测试对象和测试脚本可以在所有层之间共享。
选择合适的验证方法
当响应状态代码告诉请求状态时，响应主体内容就是 API 通过给定输入返回的内容。API 响应内容因数据类型和大小而异。响应可以是纯文本，JSON 数据结构，XML 文档等。它们可以是简单的几个单词的字符串（甚至为空），也可以是一百页的 JSON/XML 文件。因此，必须为给定的 API 选择合适的验证方法。
通常，有一些验证 API 响应正文内容的基本方法：
- 将整个响应正文内容与预期信息进行比较，此方法适用于具有静态内容的简单响应。日期时间，增加的 ID 等动态信息会在断言中引起麻烦。
- 比较响应的每个属性值，对于 JSON 或 XML 格式的响应，很容易获得给定键或属性的值。因此，此方法在验证动态内容或单个值而不是整个内容时很有用。
- 比较匹配与正则表达式，与验证单个属性值一起，此方法用于验证具有特定模式的数据响应以处理复杂的动态数据。
每种验证方法都有其优点和缺点，并且没有 “一刀切” 的选项，需要选择最适合您的测试项目的解决方案。
创建正面和负面的测试
API 测试需要正向测试和反向测试，以确保 API 正常运行。由于 API 测试被视为一种灰盒测试，因此两种类型的测试均由输入和输出数据驱动。
正向测试
- 验证 API 是否已接收输入并按要求中指定的那样返回预期的输出。
- 验证是否按要求指定返回了响应状态代码，无论它返回的是 2xx 还是错误代码。
- 用最小的必填字段和最大的字段指定输入。
反向测试
- 当预期的输出不存在时，请验证 API 是否返回了适当的响应。
- 执行异常输入验证测试。
- 使用不同的授权级别验证 API 的行为。
现场测试流程
建议在测试过程中安排每天的 API 测试执行。由于 API 测试执行快速，稳定且足够小，因此很容易以最小的风险将更多测试添加到当前测试过程中。这只有通过具有以下功能的自动 API 测试工具才能实现：
- 使用内置测试命令进行测试计划
- 与测试管理工具和缺陷跟踪工具集成
- 与各种领先的 CI 工具进行持续集成
- 可视日志报告生成
测试过程完成后，每天都可以得到这些测试的结果。如果发生失败的测试，则可以立即检查输出并验证问题以找到适当的解决方案。
不要小看 API 自动化测试
API 测试流程非常简单，只需三个主要步骤：
- 发送带有必要输入数据的请求
- 获取具有输出数据的响应
- 验证响应是否按要求返回
API 测试最重要的部分既不是发送请求也不是接收响应。它们是测试数据管理和验证。通常，测试一些第一个 API（例如登录，查询一些资源等）非常简单。因此，API 测试任务很容易被低估。在常规手段方法无法达到你的目的时，使用编程技能可以极大拓展 API 测试的边界。
- 郑重声明：文章首发于公众号 “FunTester”，禁止第三方（腾讯云除外）转载、发表。
技术类文章精选
- java 一行代码打印心形
- Linux 性能监控软件 netdata 中文汉化版
- 性能测试框架第二版
- 如何在 Linux 命令行界面愉快进行性能测试
- 图解 HTTP 脑图
- 将 swagger 文档自动变成测试代码
- 基于 java 的直线型接口测试框架初探
- Selenium 4.0 Alpha 更新日志
- Selenium 4.0 Alpha 更新实践
- 如何统一接口测试的功能、自动化和性能测试用例