当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测试相关的复杂性，下降了其采用的障碍，并帮助组织引入了可管理、可维护和可扩展的测试策略。本身也来尝试一下吧！