当AI遇上API测试 — 敏捷开发已迎来革新时代！

本文的灵感来源于正在使用的一款自动化测试工具，我目前还处于边学习边运用的阶段，不过它的API测试功能令人惊叹（虽然我还没有完全摸透）。接下来，我将对这一功能的理解做一个简单的陈述。在其新版本中，通过创建一个简单且优雅的解决方案来帮助组织不仅开始使用API测试，而且还为支持敏捷开发的可扩展且可维护的API测试策略奠定了基础，从而消除了与API测试相关的复杂性。

使API测试更“容易”

当研发人员讨论开发这种新的测试自动化概念时，他们的首席执行官Elizabeth Kolawa有一个简单的准则。她说：“轻松一点。”这个简单的陈述变成了对与现代测试相关的当前挑战的深入分析，并得出了关键的认识：

软件测试行业中的工具并没有将重点放在敏捷世界的简单性上。

敏捷主要是针对发展的活动。用最基本的术语来说，敏捷是一种软件开发方法，传统上跨越项目持续时间的典型SDLC活动被分解成称为sprint的小块。通常，一个Sprint为2到3周，在Sprint中，开发活动集中于新功能和增强功能。

一个迭代看起来像这样：

迭代从设计和创建阶段开始，在此阶段中，新功能被分解为用户故事，确定范围，然后开发立即开始构建。在sprint结束时，可能有也可能没有释放活动，但是无论如何，都会获得反馈，然后开始另一个sprint，并且该过程一遍又一遍地重复。

敏捷使组织可以花钱，因为在每个sprint期间收集的反馈可以应用于下一个sprint，并有助于指导、调整和聚焦项目。这对开发非常有用，但是如果你查看sprint的测试部分，它会变得复杂起来。

由于逻辑原因，直到进入Sprint为止，Test才能访问测试新功能和增强功能。测试团队需要等到开发团队构建完所有功能之后，因此测试从一开始就总是落后于开发。

为什么测试不能跟上开发的步伐

随着sprint的继续和测试人员依赖UI测试（手动与用户界面进行交互），此问题只会加剧。 UI测试是最常见的测试实践，因为它易于使用——易于将UI中的操作与用户故事相关联，易于在众多测试人员中扩展，并且具有记录和回放功能（我之前有写过关于该功能的文章，不过当时没有留存需要的实操截图，并没有发布出来），进行第一轮自动化很容易。

但是UI测试存在很多问题：

• UI测试效率低下，存在隐性成本。UI测试的最根本挑战是，当将UI测试作为复制品进行开发时，修复缺陷所需的开发时间。通常，当测试人员开始缺陷发现过程时，他们从探索性测试开始（方法是在应用程序中搜索意外行为）。当发现缺陷时，他们需要对其进行复制以进行开发，这涉及编写“复制步骤”。当开发人员收到这些说明时，他们需要找到测试正在使用的应用程序的版本，将其使用起来，并逐步执行UI。如果缺陷重现，则他们必须将该缺陷与基础代码相关联以确定根本原因。开发工作开始进行，要求他们将应用程序拆开，修复缺陷，然后重新构建应用程序，然后再进行质量检查。这进一步延迟了软件交付过程并减慢了整个流程。
• 用户界面测试无法全面测试应用程序。在UI层进行的测试可以端对端地验证应用程序的流程，但不一定测试系统内部的整个宽度。通常，将新功能引入应用程序后，它需要更改或更新现有接口。使用新功能时，其中某些组件可能无法访问，但如果未经测试，则会给组织带来重大风险。
• 测试无权访问代码，因此他们很难将其在UI中执行的操作映射到基础源。结果，构建的测试无法提供完整的API覆盖率。事情经常被遗漏。当需要运行整个回归周期时，可能会发现关键缺陷。通常，这种后期周期缺陷检测会导致明显的发布延迟，并增加测试的总成本。
• 维护UI自动化很困难。测试难以跟上开发步伐的主要原因是因为花太多时间来管理损坏的UI测试。实际上，多达80％的测试时间花费在手动执行UI测试或修复由于应用程序更改而中断的自动UI测试上。

上述因素中的每一个都会导致sprint的显着延迟，但是考虑到传统项目周期的工作原理，则是一系列这些sprint，然后是强化或回归周期。

在测试的每个步骤中，测试都在努力跟上开发的步伐——但是由于传统上使用的测试技术，他们永远无法获得所需的全部和完整的全面测试。

看起来像这样：

通常，他们将能够验证新特性和功能，但无法完成完整的测试范围。

对于许多测试人员而言，这令人沮丧，但这不是他们的错——鉴于工具市场中存在的功能，这是在所难免的。危险的部分是，如果没有这些质量实践，缺陷就会渗入生产并侵蚀从敏捷中获得的可观收益。

API测试呢？它可以节省敏捷性吗？

大家都认为，与UI测试相比，API测试可以更精确地找出缺陷的根本原因，因为API测试更接近代码，更易于自动化，并且更能抵抗应用程序更改。同样，API测试提供了一种更好的缺陷再现形式，以及开发和测试之间的通信，因为测试工件代表了这两个领域的融合。（在最近的文章中，我探讨了API测试，它是什么以及如何构建全面的API测试策略。你可以阅读以获取更多信息关于这种极其有效的测试实践。）

在API层进行测试是进行敏捷开发的好方法，特别是因为在经过压缩的时间轴下，它可以使测试人员验证功能，并且API测试具有高度可重用性。

此外，API测试具有以下优势，可以简化并支持敏捷测试：

与UI测试相比，缩短了缺陷修复时间

如果API测试失败，则可以肯定地知道在代码中哪里查找。开发人员喜欢从测试人员那里获得API测试，因为开发人员可以直接针对他们的应用程序执行它们，而无需连接整个环境。他们可以在开始修复缺陷时不断地重新运行它们。

缩短的缺陷修复时间意味着，通常提供API测试和UI测试时，开发可以更快地修复错误。考虑敏捷性涉及的时间范围时，这正是我们所需要的。一旦发现缺陷，就会向开发人员提供API测试，他们可以使用它来查找、修复和验证缺陷，而无需重新构建整个应用程序，从而节省了大量时间。这正是我们敏捷所需的速度。

API测试是“自动化就绪”

API表示在应用程序后台进行的无形通信。通讯的无形特性有助于自动化过程。使应用程序达到可以在API级别开始与之交互的程度所需要的复杂性要比完整站立整个应用程序所需的复杂度要小得多，因此你可以在UI级别进行操作。

因此，可以在SDLC的早期阶段轻松地以自动化方式运行API测试。我的大多数客户都在运行单元测试的同时运行它们，这取决于代码签入的功能。这些API测试运行还可以以更简单的方式与错误跟踪系统相关联，以便在解决缺陷后，可以轻松地在开发和测试之间来回传递随附的API测试。这极大地减少了整个移交过程，因为测试人员可以从错误跟踪系统收到有关缺陷已解决的通知，并查看自动化测试，而不是提交缺陷，提供重现步骤，然后等待开发中的新构建，验证分辨率的案例。这些API测试可以轻松地内置到回归套件中，并可以重复使用。

API测试比UI测试更能适应变化

作为研究的一部分，我们发现80％的开发时间都花在了管理和更新因更改而中断的UI测试上。变更是敏捷的主要杀手，但是由于增加了代码签入和敏捷引入的时间框架，变更是不变的。

如果组织完全依赖UI测试，则应用程序更改可能会毁灭性的，因为为验证关键功能而构建的许多测试用例都只是停止工作。敏捷性的主要原则之一是能够打开一角钱，这意味着UI和功能一直在变化，而支持和维护这些测试的负担可能会给测试团队带来巨大压力。另一方面，API测试甚至看不到用户界面。API还具有内置的特定版本控制功能，该功能使测试人员可以在应用程序进行更改时保持稳定性。此外，API是通过服务合同定义的，可以在应用程序进行这些更改时用来更新测试用例。

API测试可以使组织能够在开发的早期阶段轻松测试应用程序，并在开发和测试之间提供有效的通信机制，从而高度抵抗变更，从而节省敏捷性。将API测试作为测试策略基础的组织可以利用他们提供的敏捷性来真正应对测试挑战。

那么为什么组织API不进行测试？

即使具有API测试带来的所有好处，业界仍然专注于UI测试：

我们认为这是因为测试人员不知道如何测试API和/或不知道他们的应用程序如何使用API。从何处着手开始对应用程序进行API测试并不清楚，而了解如何以有意义的方式将所有“难题”组装在一起需要应用程序领域知识。

由于组织仍倾向于利用集中式测试实践，因此测试人员需要对所有不同的应用程序界面有深入的了解，并知道如何正确地将它们组合在一起。这不是一件简单的任务。

API测试仍然被认为是无人区。在最近的调查中，我们询问了一系列负责组织中API测试的开发人员和测试人员。

• 70％的测试人员表示开发负责API测试。
  • 为什么？“开发团队创建了API，并且在构建API时，他们还应该构建API测试以验证它们是否按所述方式工作”
• 80％的开发人员表示测试负责API测试
  • 为什么？“我们创建这些API是面向外部的，并通过服务合同对其进行了记录。测试团队应参加并验证API是否按照说明进行工作”

如你所见，对于谁最终负责API测试，无法落地。我们也一直在解决这个问题。我们认为API测试是开发人员和测试人员以不同形式承担的责任，但正是这种脱节导致API测试覆盖率较低。

API级别的测试需要专门的技能和工具，才能获得全面的测试范围。这不是直观的。市场上有一些工具正在尝试帮助组织制定API测试策略，但是绝大多数工具都需要大量的技术知识来构建全面的API测试。此外，测试人员仍然需要了解API的工作原理，这需要领域知识。结果，组织倾向于为API测试做最少的工作，这与敏捷性的需求背道而驰。

用于测试自动化的人工智能

为什么是AI，为什么是现在？解决此行业问题的唯一方法是构建可消除API测试复杂性的工具。

智能API测试生成器

作为该软件工具的重要组件之一，智能API测试生成器是从头开始构建的，可帮助降低API测试的复杂性。Smart API Test Generator是适用于Chrome的插件，该插件使用人工智能将手动UI测试转换为自动化API测试，从而降低了采用API测试所需的技术技能，并帮助组织制定可扩展的全面API测试策略。

那么它是怎样工作的？

将UI活动转换为自动API测试

Smart Generator在执行手动测试时监视后台流量，分析该流量，并使用人工智能自动构建一组有意义的API测试方案。在构建这些API测试时，智能生成器首先识别API调用，然后发现模式并分析它们之间的关系，以便它可以生成完整的API测试方案，而不仅仅是一系列API测试。

减少了API测试的学习难度

Smart Generator为测试人员提供了一个轻松的地方来开始构建API测试，因此他们不必触摸与手动构建API测试相关的困难活动，即找到正确的服务定义，了解数据有效负载或对测试进行测试并再次了解请求和响应之间的关系，以便你可以开始建立断言。

取而代之的是，智能生成器会根据测试人员在使用UI时观察到的活动自动完成所有这些繁重的工作。一般而言，这可以帮助新手用户更好地了解API测试，因为他们可以将在UI中执行的活动映射到已创建的API测试，并更好地了解UI与基础API调用之间的关系，从而有助于推动未来的API测试工作。

帮助用户建立全面的API测试策略

尽管API测试是最有效的软件测试方法之一，但许多组织尚未成功采用该方法，因为它需要专门的技能和工具。为了帮助组织采用全面的API测试实践，它还提供了易于使用的可视化工具，使API测试初学者可以在比其他工具更少的时间内开始创建强大的API方案。智能生成器弥合了差距，使新手用户进入了API测试世界。

那么这是什么意思？

敏捷开发可以帮助组织更快地向市场交付高质量的软件，但是由于缺乏所需的技术来帮助组织快速全面地测试其应用程序，因此，加速交付所带来的风险侵蚀了Agile的潜在利益。现在该是组织提高对API测试的了解的时候了。

可靠的API测试策略将使组织能够从其敏捷转换中获得最大价值。为了实现这一点，测试工具应该对我们有用，而我们正在使用的软件的最新版本正是这样做的。其新的组件Smart API Test Generator降低了与API测试相关的复杂性，降低了其采用的障碍，并帮助组织引入了可管理、可维护和可扩展的测试策略。自己也来尝试一下吧！