[51CTO.com 快译] 从基本概念上说, API 的作用是: 通过任何形式的通信手段, 促进两种不同应用程序之间实现交互. 例如, 在 web 应用上所使用到的 API, 我们往往称之为 "Web 服务". 如今, 随着应用技术的进步和种类的增多, API 已经成为了编程代码中的重要组成部分. 在开发各种应用项目时, 编程人员往往会通过使用 API 来与数据库或其他的模块进行通信. 这就是为什么作为测试人员的我们, 必须通过测试 API, 以求获得最大的测试覆盖率 (test coverage) 的原因.
而作为集成测试的一部分, API 自动化可以协助加速测试的进程并提高效率. 由于目前大多数公司都在业务层面上使用到了 RESTful 微服务和 API, 因此对于 API 的测试已经成为了任何发布测试计划中的关键环节之一.
简单来说, API 实际是一种服务, 它可以帮助两种不同的应用程序实现顺畅的相互通信. 大多数 API 被用于抽象各种业务逻辑, 并引导到应用程序访问其对应的数据库.
从逻辑上讲, 我们可以将整个软件系统分为三个层次:
1. 表示层 - 这是展示给最终用户的某个用户界面 (GUI). 质量保证人员(Quality Assurance,QA) 对于该层次进行功能测试.
2. 业务层 - 这是通过编写逻辑代码, 来实现各种应用的用户接口. 就实现技术而言, 各类代码和算法属于在这个层面上. 当然 API 也处于这个层次.
3. 数据库层 - 存储的是应用程序的各种数据信息.
换句话说, API 是软件互联世界的中枢神经. 它通过运用各种工具, 协议, 标准和代码集, 将数字世界 "粘合" 在一起. 由于 API 不但动态灵活, 而且功能强大, 因此它让各种软件产品更为简便, 更具有移动性, 不同组件能够以一种无缝集成的方式进行协同运作. 那么, 针对 API 的测试则可以从服务级别和集成级别两个方面进行展开.
API 的测试策略
就不同人员的关注点而言, 开发人员一般倾向于只测试他们正在开发的软件功能; 一般测试人员则只负责做功能性的单元测试, 以及端到端的协同测试. 然而在如今 DevOps 的持续开发与测试环节中, 测试人员更应该专注于在软件使用过程中所进行的各种 API 调用, 以便观察和记录在系统做出响应之前所接收的不同输出. 而且, 其中最重要的是: 应测试 API 在不同条件下是否能返回正确的响应或输出值. 一般而言, 此类输出可以被分为如下三类:
通过 (成功) 或失败状态
数据或信息
调用另一个 API
当然, 也可能根本没有任何输出, 或发生了完全不可预测的结果. 因此, 测试人员就要在整个应用程序的开发过程中起到关键性的作用, 他们需要通过数据驱动型测试, 来提高整体测试的覆盖率和准确性.
API 测试的类型
正如我们通常需要根据目标产品具有哪些功能, 提前设定好进行何种类型的测试一样, 测试人员往往也需要首先确定好将在 API 上执行哪种类型的测试. 如下是常见的 API 测试种类:
单元测试 - 测试单个操作的功能. 例如, Google 地图通过提供地理编码类型的 API, 以获取任意位置的经度和纬度. 其后台实际上是将地址信息作为输入, 并返回纬度和经度的数值. 那么在针对该 API 的单元测试中, 测试人员可以通过输入不同的位置信息来验证其各种输出结果.
功能测试 - 此类测试主要关注于 API 的本身功能, 即: 通过各种测试用例, 来验证 HTTP 响应的程序代码, 响应的准确性, API 可能返回的任何错误代码等方面.
负载测试 - 在有多个用户同时使用某个应用程序, 并引发了 API 需要处理大量数据的情况下, 此类测试是必需的. 它通过增加 API 的调用频率, 以暴露可能出现的崩溃, 或无法 "承压" 等状况.
安全测试 - 由于 API 会被用于在两个不同的应用程序之间创建连接, 而使用 API的核心目的就是为了将某个应用程序的数据库相对于另一个进行抽象或隐藏, 因此安全测试尤为重要. 测试用例一般包括: 授权检查, 会话管理等方面.
互操作性测试 - 此类测试的目的是保证 API 能够被应用程序按需访问到, 例如 SOAP API 就属于此类.
WS(Web Service)合规性测试 - 在对于 API 的测试过程中, 我们应当确保诸如: WS-Addressing,WS-Discovery,WS-Federation,WS-Policy,WS-Security 和 WS-Trust 等标准能够被正确地采用和实施.
渗透测试 - 这是从外部攻击源来查找 API 的漏洞.
Web 服务与 API 协议
上面我们提到了 Web 服务, 它主要是由两种类型的服务 (或称为协议) 所组成:
REST(Representational State Transfer) - 是一种轻量级的协议, 它使用 URL 来获取所有需要的信息. 与下面将要介绍的 SOAP 相比, 它不但更新了, 而且克服了 SOAP 上存在的所有问题. REST 使用如下四种 HTTP 方法来执行各项任务:
1. Get - 获取信息. 例如, 在位置映射的 API 中获取经度和纬度的信息.
2. Post - 在资源中插入一些数据.
3. Put - 更新目标资源.
4. Delete - 从资源中进行删除.
由于其架构简单且轻巧, 因此 REST 如今已被广为使用.
SOAP(Simple Object Access Protocol) API - 它使用 xml 来进行消息交换. 而执行该任务所需的所有信息, 都是由 Web 服务描述语言 (Web Service Description Language,WSDL) 所给定的. SOAP 的扩展性和与 xml 相关的标准性, 造成了 SOAP 相对来说比较 "重". 而它相比 REST 的优势在于: 它具有内置的错误处理功能, 并且可以与其他协议 (如 SMTP) 协同使用.
API 的测试步骤
市面上有许多针对 API 的测试工具. 在测试人员接手 API 之初, 他们应当先参考其相应的文档, 以判定目标是属于 REST, 还是 SOAP API, 或者它根本就不是基于 Web 的 API, 这些详细的信息都应当被记录在配套的文档之中. 因此, API 的测试基本流程为:
1. 参考文档(上面已经提及)
2. 先编写功能性, 或服务级别的相关用例
3. 编写各种集成测试
4. 在 API 足够稳定, 且完成了上述的测试步骤之后, 我们可以开始进行安全, 性能和负载类型的测试.
具体说来, 我们可以按照如下的顺序进行:
1. 典型的 API 文档一般会包含与 API 相关的所有信息, 其中包括: 请求的格式, 响应的类型, 错误的代码, 用到的资源, 必需的参数, 可选的参数, headers 等方面. 而对于这类文档, 我们则可以使用诸如开源的 swagger,Dapperdox 和 ReDoc 等工具来进行日常维护.
2. 之后我们就可以着手为 API 编写服务级别的测试用例了. 例如, 如果某个 API 使用了 n 个参数来获取响应, 其中 m 是必要参数, 而其他都是可选参数, 那么其对应的测试用例应该去尝试不同的参数组合, 以验证各种响应结果. 而另一种测试用例则可能需要验证 headers; 和在不启用身份验证的情况下运行 API, 以检验其产生的错误代码.
3. 接下来便是集成测试的步骤了. 您需要测试目标 API 的所有依赖项, 及其功能. 同时, 我们还可能需要测试该 API 的各种响应, 从其他 API, 或方法处预计返回的数据, 以及该 API 在失效时的各种状态与输出信息.
4. 一旦目标 API 的表现稳定, 并完成了所有功能性的测试, 那么测试人员就可以开始进行与负载, 安全和性能相关的各种深度测试了.
API 自动化测试工具
如今随着 DevOps 的盛行, 我们通常在每次进行发布之前, 都可能需要对一些测试用例, 如回归用例, 执行重复性的测试. 因此, 这就需要测试人员实现一些自动化的任务.
市面上有许多针对 API 自动化的工具, 我们在此列举几个典型的:
SOAP UI - 这是一款非常流行的 API 测试工具. 您可以使用 SoapUI 来对目标 API 执行功能性, 负载性, 安全性和合规性等测试.
Katalon Studio - 建立在 Selenium 和 Appium 基础之上的 Katalon Studio, 是一款免费的, 且功能强大的自动化测试工具. 它能够被用于执行 Web 测试, API 测试和移动测试.
Postman - Postman 是一款免费的工具. 您可以使用它来高效地开发和测试目标 API 的所有功能.
Jmeter - 虽然测试人员主要会将 Jmeter 用于性能和负载方面的测试, 但它在很大程度上也是可以被用到 API 的功能测试环节中.
RestAssured - RestAssured 实际上是一个基于 Java 的库, 因此它可以被用于测试各种基于 RESTful 的 Web 服务. 您可以将该库包含在现有框架中, 直接调用其对应的方法, 以获取 JSON 格式的响应, 并最终执行各种所需的操作.
下面, 我将通过一个实例来诠释 API 功能测试所需要遵循的基本步骤. 在该示例中, 我使用的是由 CloudQA 所提供的一款较为新颖且流行的工具 --TruAPI.
步骤 1
为了产生一个 API 请求, 您首先需要选择一种 Method Type, 并在此粘贴目标 API 的 URL. 您既可以按下发送按钮, 将请求发送到给目标 API; 也可以按下 Add API Test 按钮, 以保存该请求:
为了方便看到效果, 您可以试着使用如下 Method Type 和 API URL:
- Method Type: GET
- API URL:
第 2 步 - API 的请求信息:
大多数 API 都需要一些额外的输入, 才能执行对应的请求. 诸如: 参数, Headers,Body(JSON)等.
因此, 为了给请求添加各项参数, 您可以选择相应的 Parameters 选项卡, 然后点击 "Add Parameter" 按钮, 以添加所需的信息.
第 3 步 - 使用身份验证发送 API 请求:
如果您的目标 API 需要身份验证的话, 您可以选择 Authorization 选项卡, 从下拉列表中选择 BasicAuth(其默认设置为 Noauth), 然后输入用户名和密码, 那么您就可以发送带有身份验证的请求了.
相对应地, 每个 API 的响应也都包含不同的值, 例如: 状态代码, body,headers, 以及完成 API 请求的时间. 下面, 我们来对 API 的响应进行详细讨论.
添加断言(Assertions):
在自动化过程中, 使用断言来验证各种输出是非常重要的. 如果您想在 API Runner 中添加断言, 那么请选择 Assertions 选项卡. 在此, 您可以添加一到多个断言.
下面是添加断言的简单步骤:
1. 选择响应类型
2. 选择断言的条件
3. 输入需要检查的值
4. 完成断言的添加
变量:
Variables 选项卡可以被用于存储那些根据 API 请求所产生的响应接收值. 如果您想保存各种响应, 请选择 Variables 选项卡, 然后按照以下步骤进行操作:
1. 添加变量
2. 为变量命名, 以便其他团队容易理解
3. 输入来自响应 body 并存储着数值的 JSON 路径
4. 如果您想将变量中的存储值用作预期的断言, 则可以在任何其他 API 的请求中使用变量:_name
查看或执行某个已保存的 API 请求:
您可以在 API Runner 页面上, 使用 View Saved Tests 按钮, 来查看各种已保存的测试.
选中一到多个已保存的 API 测试, 并默认运行它们. 这些测试会显示上一次执行后的运行状态信息.
而结果将显示在 API 执行历史的记录中.
上面我们介绍的只是一个单独的 API 执行与自动化. 而在真实的场景中, 我们经常需要创建包含所有回归测试用例在内的 API 套件, 并将其作为回归测试的一部分来运行. 在敏捷开发的理念中, 准备好相应的套件是至关重要的, 只有这样才能更好地与持续集成 / 持续交付 (CI/CD) 进行整合.
另外, CloudQA 附带有丰富的说明文档. 而且 CloudQA 提供的所有工具都是与 "无代码自动化(Codeless automation)" 的理念相一致的. 这也就方便了那些手动测试人员的使用. 详细文档, 请参见: https://doc.cloudqa.io/TruAPI.html .
原文标题: The Know-Hows of API Testing, 作者: Ruchira Shukla
来源: http://www.tuicool.com/articles/7bqmqeU