API网关如何发展:更轻、更智能、云原生
质量保证测试人员的终极API指南
作为数据和持续连接的渠道,API 已成为质量保证不可或缺的一部分。 API 可以为质量保证测试人员带来真正的变革,但也并非没有复杂性。学习如何在 QA 测试中有效且安全地使用 API 有一定的学习曲线。这就是我们为 QA 测试人员和站点可靠性工程师编写本 API 指南的原因。我们将带您了解基础知识,然后分享一些 API 测试的最佳实践。
什么是 API?
API 代表应用程序编程接口。 API 允许不同的软件、应用程序或资源相互交互。每当应用程序发送请求或接收查询时,API 很可能负责。 API 通常遵循称为API 规范的标准化格式。这种标准化在自动化流程中发挥着重要作用,这也是 API 对 QA 工程师发挥作用的地方。
什么是 API 测试?
API 测试是测试 API 以确保其满足预期功能的过程。 API 测试评估安全性、性能和可靠性。 API 测试还可以检查 API 集成,验证 API 是否可以与特定资源或软件正确交互。
API 测试通常会模拟对 API 端点的一系列请求,以确保其行为符合预期。 API 测试在DevOps中很常见,允许开发人员在 UI 最终确定之前测试不同的组件。许多不返回相关结果的不良 API 请求也不会显示在 UI 层上。 API 测试可以让 QA 测试人员发现如果依赖 UI 可能会错过的缺陷。它还允许他们发出使用 UI 可能无法实现的请求,这对于API 安全至关重要。
API 测试对于使用微服务环境的企业尤其重要,因为 API 是将一项服务连接到另一项服务的基础设施。也许最重要的是,API 测试对于敏捷开发至关重要。在实践敏捷开发时,许多开发人员和工程师更喜欢 API 测试而不是 GUI 测试,因为它更快、更容易维护和实施。
在 API 测试中要寻找什么
与任何好的测试一样,API 测试需要明确定义的目标才能正常工作。理想情况下,质量保证工程师还应该了解 API 的行为方式,以便他们能够检测到何时发生异常。以下是 QA 测试人员在 API 测试之前应考虑的一些问题:
- 这个API有什么作用?
- 这个 API 应该如何表现?
- 可以测试哪些 API 端点?
- 预期错误的预期错误代码是什么?
- 不成功的请求正文中应传递什么错误消息?
- 应该使用哪些API测试工具?
一旦他们知道自己在寻找什么,质量检查工程师就可以开始编写代码来应用各种测试技术。一旦编写了测试,就可以对其进行评估:
- 回复时间
- 数据质量
- 授权验证
- HTTP 状态代码
- 错误代码
API 测试可以在端点、UI 和数据库上执行。质量保证工程师应该在认真开始 API 测试过程之前建立预期行为的基线,因为这可以提供与实际结果进行比较的东西。
API 测试示例
API 测试有多种不同的形式和规模。这些主要可以分为三个主要类别:功能测试、性能测试和安全测试。
API功能测试
功能 API 测试的一些示例可能包括测试已知正在工作的端点并确保返回200 OK
HTTP 状态。例如,当您使用以下请求查询 Stephen King 的OpenLibrary 作者搜索 API时:
https://openlibrary.org/search/authors.json?q=Stephen%20King
您会收到 200 OK 响应,因为请求格式正确,并且 OpenLibrary API 不需要授权。
另一项功能测试可能是尝试使用未经验证的凭据访问 API,以确保不可能进行未经授权的访问。此 API 测试还揭示了返回的内容,因此 QA 测试人员可以验证没有泄露敏感信息。例如,荷兰国立博物馆允许用户搜索其在线藏品,但需要 API 密钥才能完成查询。当您使用正确的凭据发出以下请求以查看 Rembrandt van Rijn 的所有作品时,您应该会收到200 OK
HTTP 响应。或者,当您输入未经授权的 API 密钥时,您应该会收到401 Unauthorized
错误。
https://www.rijksmuseum.nl/api/nl/collection?key=[api-key]&involvedMaker=Rembrandt+van+Rijn
功能测试还可以评估分页和速率限制是否按其应有的方式运行,或者在提交格式不正确的数据时 API 的行为方式。质量保证工程师还可以测试 API 是否可以支持各种 CRUD 命令。例如,分页的 API 测试可以检查以确保遵守限制并且没有超出查询的范围。
再次以国家博物馆 API 为例,我们知道荷兰艺术博物馆收藏了伦勃朗·凡·莱恩 (Rembrandt van Rijn) 的近 12000 件藏品。功能请求可以进行测试以确保对象在应该出现的时候出现。用于分页的功能 API 测试可能会指定页码以及每页返回的结果数。如果您故意超出资源范围(例如此查询),您应该得到一个空的 JSON 对象作为响应。
https://www.rijksmuseum.nl/api/nl/collection?[API-Key]&involvedMaker=Rembrandt+van+Rijn&p=600&ps=20
收到此响应表明 API 分页正在正常工作。
{"elapsedMilliseconds":0,"count":0,"countFacets":{},"artObjects":[],"facets":[]}
API性能测试
性能测试衡量 API 的行为方式。 API 测试可以检查性能时间、响应时间或压力测试,以了解 API 在遇到意外流量激增时的表现。它还允许 QA 测试人员测量延迟时间、错误响应时间,甚至返回数据库查询所需的时间。性能测试是验证优质用户体验 (UX) 的最重要的 API 测试类型之一。
衡量 API 在给定大负载时的行为方式的性能测试示例可能如下所示。以下是一个 API 调用,用于检索大都会艺术博物馆藏品中涉及向日葵的每个对象:
https://collectionapi.metmuseum.org/public/collection/v1/search?q=sunflowers
测量性能的 QA 测试人员可能会运行此查询来获取 API 行为方式以及返回的所有对象的基线评估。然后,他们可能会修改 API 调用以包含许多过滤器以查看 API 如何响应,如下所示。
https://collectionapi.metmuseum.org/public/collection/v1/search?q=sunflowers?foo1=bar1&foo2=bar2&foo2=bar2&foo3=bar3&foo4=bar4&foo5=bar5&foo6=bar6&foo7=bar7&foo8=bar8&foo9=bar9&foo10=bar10&foo5=bar5&foo6=bar6&foo7=bar7&foo8=bar8&foo9=bar9&foo10=bar10&foo5=bar5&foo6=bar6&foo7=bar7&foo8=bar8&foo9=bar9&foo10=bar10&foo5=bar5&foo6=bar6&foo7=bar7&foo8=bar8&foo9=bar9&foo10=bar10&foo5=bar5&foo6=bar6&foo7=bar7&foo8=bar8&foo9=bar9&foo10=bar10&foo5=bar5&foo6=bar6&foo7=bar7&foo8=bar8&foo9=bar9&foo10=bar10&foo5=bar5&foo6=bar6&foo7=bar7&foo8=bar8&foo9=bar9&foo10=bar10&foo5=bar5&foo6=bar6&foo7=bar7&foo8=bar8&foo9=bar9&foo10=bar10
然而,安全测试同样重要,因为它决定了 API 是否可以安全使用。一些常见的 API 安全测试包括授权验证、身份验证和令牌安全,以确保未经授权的用户无法访问 API。它还可以让 QA 测试人员模拟SQL 注入等常见攻击,或确保不会暴露敏感数据或实现任何跨源资源共享(CORS)。
API安全测试
API 安全测试可能更加复杂,因为它通常涉及运行一套测试。要了解如何运行您自己的安全测试,您可以从 Postman 的这个常见 API 漏洞模板开始,它可以为您提供一些想法来建模您自己的 API 测试。
当我们评估Icons8 (一个搜索网页设计图标的公共 API)时,通过了五个测试,返回以下代码:
PASS checks vulnerability with basic origin reflection
PASS checks vulnerability with trusted null origin
PASS checks vulnerability with trusted insecure protocols
PASS checks for response with valid access token
然而,发现了八个漏洞,如以下错误代码所示:
FAIL checks for Content-Security-Policy header | AssertionError: expected undefined to not equal undefined
FAIL checks for X-Frame-Options header | AssertionError: expected '' to equal 'DENY'
FAIL checks for Strict-Transport-Security header | AssertionError: expected '' to include 'max-age'
FAIL checks for X-XSS-Protection header | AssertionError: expected undefined to not equal undefined
FAIL checks for response with expired access token | AssertionError: expected 200 to be one of [ 401, 403 ]
FAIL checks for response without access token | AssertionError: expected 200 to be one of [ 401, 403 ]
API 测试工具
QA 测试人员可以编写自己的代码来测试 API,也可以使用现有的 API 测试工具。 Postman是 API 测试的热门选择,因为许多 API 开发人员都将他们的 API 可用于该平台。它也很容易使用,这要归功于光滑的 GUI,这使得技术背景较少的用户更容易使用它。然后,它使用用户输入的变量配置用户的所有 HTTP 请求,这有时会变得相当笨重。
Postman 创建集合的能力对于 API 测试也很有用,因为捆绑相关服务被认为是 API 测试的最佳实践。最后,Postman 可以用于自动化 API 测试,这对于最大限度地提高生产力非常有用。 Postman 甚至可以配置为在 API 测试完成时发送电子邮件,从而允许 QA 测试人员简单地设置测试,然后继续执行其他更紧迫的任务。
对于想要衡量 API 性能的 QA 测试人员来说, Apigee是一个不错的选择,因为它有一个可以自定义的详细仪表板。它还可以创建定制报告,使质量保证测试人员能够创建有关其测量内容的详细报告。
Apache 的 JMeter已在功能测试中变得流行。它具有对 CSV 文件的本机支持,让 QA 工程师尽可能快速高效地工作。它还可以轻松地与第三方应用程序集成,从而轻松合并到 CI 管道中。
质量保证测试人员的 API 最佳实践
最后,我们分享一些 API 测试的最佳实践,以便质量保证测试人员能够从他们的努力中获得最大收益。首先,QA 测试人员应该在认真开始 API 测试之前尽最大努力彻底理解 API 文档。正如我们之前提到的,了解 API 的行为方式有助于了解它是否按其应有的方式执行。
接下来,针对您能想到的尽可能多的场景运行 API 测试。您应该运行正确配置的测试,以确保 API 的行为符合其应有的方式。然后,创建带有故意错误的测试,以查看 API 如何响应。也尝试提出边缘情况,并为尽可能多的场景做好准备。
QA 测试人员还应该尽可能尝试自动化 API 测试,因为这可以让他们腾出时间来做更有意义的工作。 API 还应该在开发过程的不同阶段进行测试,以确保它们在API 生命周期的所有阶段保持安全并正常运行。
关于质量保证测试人员 API 的最终想法
API 不会消失。多年来,API 的采用率一直呈上升趋势。微服务、API优先、云原生也都是2024年流行的发展趋势。考虑到 API 在 DevOps 和敏捷开发中的重要性,可以肯定它们将成为可预见的未来开发环境的一部分。
认真掌握自己的技术并尽可能高效地交付最佳工作的质量保证测试人员应该尽一切努力掌握 API 测试。希望我们的 QA 测试人员 API 指南能够帮助您做到这一点!
原文链接:https://nordicapis.com/the-ultimate-api-guide-for-quality-assurance-testers/