AI毫无意义——为什么我们需要在API测试中添加人工智能？

AI毫无意义——为什么我们需要在API测试中添加人工智能？

　　您可以使用人工智能帮助将 API 活动组织成有意义、可重复使用和可扩展的测试，而不是简单地采集、记录和重放流量。它是记录和重放测试的扩展，但具有更高的自动化程度。

　　之前，官方在 Parasoft SOAtest 中发布了一个名为 Smart API Test Generator 的新功能。我对此并不感冒。这项技术是一项合法的突破性技术——它使用人工智能将手动 UI 测试转换为自动 API 测试，因此您无需具备 API 测试的专业知识，甚至无需编写任何代码即可上手。它们都是无脚本的，并通过一个简单的 Chrome 插件激活，因此您无需安装大型工具集即可使用它。

　　但是，在我真正使用并熟悉这个功能之前，我的脑海中会不断地冒出这个问题：这与市场上现有的录制和播放技术有什么不同？我相信大多数测试人员或开发人员都会有同样的问题。

　　在录制和回放测试中添加 AI

　　答案是人工智能和机器学习……但为什么呢？为了AI，AI毫无意义——为什么我们需要在API测试中加入人工智能？嗯，我们需要它，因为记录和重放测试是不够的。我将进一步介绍这一点。

　　要真正扩大 API 测试的采用并解决保持测试团队与开发同步的问题，您需要更多！我们希望自动帮助用户识别捕获的 API 活动，并将它们组织成有意义、可重用和可扩展的测试，而不仅仅是采集、记录和重放流量。我们需要降低 API 测试的采用标准，让更多的测试人员参与进来。

　　但首先，让我解释一下为什么它如此重要。

　　为什么我们甚至需要 API 测试

　　从历史上看，组织将 UI 测试作为他们的主要测试实践，至少在最初是这样，因为它易于定义和执行，并且易于自动化。进入门槛非常低，可以扩展到大量的测试人员。

　　但是，仅依靠手动和 UI 测试的挑战是隐藏的成本。任何使用 Selenium 的人都知道，当 UI 发生变化时，事情会变得困难，您需要更新脚本。事实上，我们发现多达 80% 的测试时间花在执行手动 UI 测试或修复因应用程序更改而中断的自动 UI 测试上。最重要的是，UI 测试只能在完整的应用程序可用后进行——如果发现缺陷，返工成本很高，因为应用程序需要被拆卸、修复和重新组装才能继续测试。通常，这种后期周期缺陷检测会导致严重的发布延迟并增加测试的总成本。

　　使用 API 测试补充 UI 测试

　　为了补充和减少对 UI 测试的依赖，组织可以使用 API 测试，它通过提供可重复使用的可维护端到端解决方案来解决其中的许多问题，而不仅仅是用于功能测试。 API 测试在开发人员和测试人员之间建立了良好的沟通渠道，因为它们有助于以具体和现实的方式记录 API 的行为。将通过 API 测试发现的错误和安全漏洞的诊断和修复转移到生命周期的早期阶段，可以在实现计划和质量目标方面获得巨大回报。

　　然而，组织很难采用 API 测试，因为即使是伟大的 API 测试工具在历史上也没有提供足够的帮助。为了有效地使用 API 测试工具，测试人员需要熟悉他们想要测试的 API，包括相关应用程序如何使用 API，这需要专业技能和专业知识。而且开发人员没有时间去测试，所以避免了这种极其有益的做法——测试人员站不住脚，开发人员不想去做。

　　基于流量构建 API 测试（“记录和重放测试”）

　　为了解决这一挑战，功能测试自动化公司多年前就提出了记录API活动并根据流量创建API测试的想法。它的强大之处在于，它只需要记录应用程序和后端系统之间的事务即可捕获 API 的活动，包括 API 调用如何重新组织正在传递的数据。

　　使用这项技术，您可以记录后端系统中发生的事情。这有助于非技术用户了解调用了哪些 API，并对调用每个 API 时使用的数据有一个基本的了解；然而，简单的流量采集并不能帮助他们提高技能，也无法学习如何维护或扩展他们的测试。它无法教授他们使用 API 使用的所有不同消息格式和协议执行不同测试所需的技术技能，并且它本身无法提供足够的帮助来使非技术用户能够采用这种方法。流量记录和功能齐全的 API 测试程序之间还有很长的路要走。

　　为什么录制和播放不够

　　这是我们开始考虑下一步以减少采用 API 测试的障碍的地方。我们在思考。仅仅记录测试人员的 UI 和目标应用程序之间的网络流量不足以帮助自动化 API 测试以实现其实用性。它可能类似于 MP3 录音。您可以播放它来收听歌曲，但它不收录有关歌曲如何创作或使用哪些乐器的任何信息。此歌曲无法修改或扩展。

　　通过简单的录音和回放测试，请考虑以下问题：

　　如果我的用户界面发生变化怎么办？

　　UI 在开发过程中不断变化，维护基于 UI 的测试自动化非常耗时。 UI只暴露了应用基本业务逻辑的某种表现形式，可能是有限的，依赖记录和重放既有局限性，又容易受到频繁变化的影响。

　　正确的流速是多少？

　　通过 UI 在系统级别测试应用程序会产生大量网络流量。即使是训练有素的眼睛，也很难确定哪些流量是发生在 UI 级别的实际测试情况的​​一部分。依靠人工解释网络流量既费时又容易出错。而且，它通常不归技能测试人员所有，因此他们必须依靠开发人员的帮助。

　　如何将这些测试步骤连接到项目？

　　从基本流量记录创建测试场景非常困难。如果创建场景需要多次测试，难度会成倍增加。由于依赖于原创测试的确切前提，因此通常很难通过重放交通记录来替换场景。此外，例如，不可能重复进行相同的测试，这对于创建性能或安全相关的测试很重要。

　　如何获取和重用知识？

　　流量日志只是测试会话期间所有网络活动的总和。对底层消息传递没有内在的理解，并且与 API 服务没有关系。没有这些，就不可能将这些录音扩展到其他用途，甚至无法进行更改以适应新的要求。它们通常会被及时冻结，仅在录制时有用。

　　回到人工智能

　　在这里，人工智能发挥了作用，因此不仅可以进行流量记录，还可以扩展到用户的真实运营价值。这就是我们开发智能 API 测试*敏*感*词*的原因，因此我们可以为新手 API 测试人员提供一个无需编写任何代码即可开始 API 测试的地方。因此，用户可以使用 Parasoft SOAtest 简单直观的界面，快速开始构建完整且有意义的测试程序，甚至可以将这些 API 测试扩展到安全和性能测试。

　　它是如何工作的？

　　在测试 UI 时，智能 API 测试*敏*感*词*会像流量采集器一样监控对应用程序进行的基本 API 调用，然后使用人工智能发现模式并了解这些 API 调用之间的关系。然后，它可以生成自动化 API 测试场景，执行与 UI 测试相同的操作，但完全自动化且易于扩展。

　　本质上，这是：

　　但为什么重要？以下是此方法提供的一些好处：

　　总而言之，该工具不仅可以根据对捕获的 API 活动的有意义的解释自动创建测试，而且还支持这些测试的轻松扩展和维护，因此其价值将在整个软件生命周期中翻倍。

　　现在让我们更进一步

　　所有这些本身都是好的。但更让我兴奋的是，Smart API Test Generator 可以帮助用户理解 UI 动作和 API 调用之间的部分关系，从而让测试人员更容易“熟练”并采用全面的 API 测试实践。由于 API 测试可以完全自动化且易于扩展，因此团队可以降低总体质量成本，同时避免延迟发布。

　　让我们分解一下。由于智能 API 测试*敏*感*词*承担了繁重的工作，它为测试人员提供了一个轻松、无脚本的地方开始构建 API 测试，从而减少 API 测试的技术入口点，让初学者进入 API 测试的世界和用户-友好的 Parasoft SOAtest 生态系统，用户将受益于易于采用和使用的强大可视化工具。

　　这是我要强调的部分

　　在系统和用户界面测试期间采集 API 活动流量不足以自动化 API 测试，但这是行业迄今为止所拥有的。对先决条件的依赖降低了这些录音的可重用性，并且几乎不可能扩展到其他目的。更何况很难从复杂的流量中创建有意义的测试场景，这是大多数测试人员不熟练的技能。

　　但这已经不重要了！*敏*感*词*钱中受益。这只会是一个越来越“人工智能”的时代！