转向微服务和API驱动的架构正在推动整个行业的重大创新，但也使企业面临隐患。人机界面（Web和移动UI）不再是主要业务风险所在。相反，最大的漏洞隐藏在API的非人机界面中。
因此，API测试已成为越来越多的关注点，但是我们始终都在听到“API测试又是什么，为什么我们需要它？”
快速总结是，应用程序编程接口（API）是应用程序使用由定义的合同管理的公共接口彼此通信的方式。采用API测试的背后推动力是能够以独立于UI的稳定方式测试应用程序的业务逻辑。与仅在前端进行测试相比，API测试可以进行更全面的测试，例如，可以进行性能和安全性测试。行业分析家和敏捷专家（例如Martin Fowler和Mike Cohn）都认为API测试是必经之路。那是什么使我们退缩呢？
测试无效的影响
软件团队希望花费理想的时间，而不仅仅是测试和调试，以最大化成功项目的潜力。但是，传统上，很难减少在测试和调试上花费的时间，因为在软件生命周期的后期（包括发行后）发现了许多严重的错误和安全漏洞。
下图说明了何时将缺陷引入到应用程序中，以及时间安排对每个阶段修复缺陷的成本的影响。您可以清楚地看到，后期缺陷的成本是巨大的——成本的增加来自多种因素（例如，诊断问题和确定根本原因所需的时间，参与该过程的人员数量，以及与缺陷修复相关的日益增加的复杂性（以及由此带来的风险）。
如果您想自己，“我以前见过”……您可能已经知道了！1996年，Capers Jones发布了此图表背后的研究报告，即使过去20年中软件开发实践发生了变化，但最新的研究报告仍然与今天相关。
我们想成就的地方：测试金字塔
那么我们是在哪里错了？我们采用的质量方法是错误的——我们需要查看上表，并寻找左移缺陷检测并尽早发现，更容易诊断和修复的缺陷的方法。深入的代码分析之类的技术可以在编写代码后立即发现嵌入在代码库中的安全性和可靠性问题，但是为了能够验证运行时或功能行为，我们需要花时间在创建和维护自动化测试上，并且，在敏捷的世界中，我们需要这些测试一旦创建便要连续执行，以使它们能够在实现新功能后“左移”检测并捕获回归。
花费时间和组织测试组合的理想方法通常表示为“测试金字塔”，如下所示，这是通过在开发时间轴上尽力推动尽可能多的测试工作来实现的。您从单元测试的基础开始，在那里发现的错误很容易修复，然后API，集成，组件测试以及系统和UI测试完善了金字塔的层次。
但是，尽管诸如测试驱动开发（TDD），早期单元测试以及软件测试中的更多自动化之类的做法已成为主流，但软件团队仍在后期UI和系统测试上花费过多时间。我们经常将当前的情况描述为倒金字塔形（冰激凌）。但是，仔细研究一下数据，我们发现该行业严重缺乏API测试，因此马提尼杯更合适：
不幸的是，测试金字塔的中间层通常没有使用，因为投资API测试具有明显的优势。例如，可以在软件开发生命周期的较早阶段进行测试（只要有API合同/定义可用），就可以更轻松地实现自动化，并且从根本上来说，它们对于应用程序UI/UX中传入的更改不那么脆弱。
通过将API测试组织到常见的用例中，可以创建场景级别的测试，并且API测试的自动化为早期和场景驱动的性能和安全性测试铺平了道路。最终，对API测试的投资使团队能够更好地管理变更并获得现代开发方法所承诺的敏捷性。经常进行早期测试，不喜欢什么？不幸的是，由于各种原因，团队正在努力实现API测试。
是什么约束了API测试？
越来越多地采用API测试的最大障碍是测试的实际创建。创建在API级别上起作用的有意义的测试并非易事，更不用说将它们串在一起以创建适当的测试方案了。在防止采用API测试方面，同样重要的是开发人员和测试人员之间存在的知识鸿沟。API测试需要测试人员通常缺乏的知识和能力，并且经理不想让开发人员进行集成或API测试。
开发人员从金字塔的底部开始工作，并且对单位级别的工作很满意。这是他们的代码（至少是他们的职责范围），单元测试似乎很自然地适合他们的工作流程。自动创建单元测试在此级别上提高了效率，并且软件行业了解需要在这里进行全面测试。
另一方面，测试人员是在UI级别的金字塔顶端进行工作的，其中用例和界面直观且易于映射到原始业务需求。他们对应用程序的看法是从外面看的。
API测试位于这两个角色之间，既需要有关接口设计的知识，又需要如何使用它们。测试人员通常无法在此级别上工作，将API视为代码，并且开发人员了解接口和API时，他们通常对接口如何与其他子系统结合使用没有完整的了解，因此将API测试视为功能测试，而不是其职责范围。
直到最近，还缺少测试工具自动化来帮助缩小单元和系统测试，开发人员和测试人员之间的差距。为了帮助软件行业更接近理想的测试金字塔并从我们今天看到的马提尼杯中发展出来，我们将Smart API Test Generator引入了Parasoft SOAtest，这是我们易于使用和使用的功能测试自动化工具。
放弃马提尼杯
Smart API Test Generator是Google Chrome网络浏览器的插件，可监视手动测试并使用人工智能创建自动API方案测试，从而降低了采用API测试所需的技术技能，并帮助您构建可扩展的API测试策略团队和组织。它是这样的：
智能API测试生成器会在您执行手动测试时监视后台流量，并将其发送到其人工智能引擎，该引擎可识别API调用，发现模式，分析API调用之间的关系，并自动生成完整的，有意义的API测试方案，不只是一系列API测试步骤。
使API测试更易于访问
Smart API Test Generator使API测试更易于测试团队使用，因为这些API测试方案是使用他们已经在做的测试实践创建的。与手动或什至自动UI测试不同，记录的API活动可以帮助测试人员与开发人员更好地协作，其单一工件可以被两个团队轻松共享和理解，并且比复杂的UI测试更能诊断出缺陷的根本原因这需要组装整个应用程序。
另一方面，仅进行UI测试时，开发人员和测试人员往往会在通信和调试技术中保持孤立状态——往往导致漫长的等待时间以及缺陷引入，缺陷检测和缺陷解决之间的反复。
API测试方案的强大功能
在UI测试期间记录的API交互需要某种形式的组织成场景或用例。SOAtest Smart API Test Generator的人工智能通过基于不同API调用之间的关系创建方案来提供帮助。
如果没有Smart API Test Generator的帮助，用户将不得不花时间研究他们的测试用例，寻找模式，以及手动建立关系以形成每个测试方案。此外，Parasoft SOAtest提供了一种直观的，由UI驱动的方法来描述断言，从而使测试人员无需编写任何代码即可执行复杂的断言逻辑。否则，用户将手工编写每个断言的代码，他们可能会错过一个断言或将其置为错误。然后，可以使用可视化工具和工具辅助逻辑来扩展这些API测试，从而创建更大范围的测试套件。
结论
尽管软件团队承认希望实现单元，API和UI测试的理想分布，但现实情况是，您的普通团队正在完成单元测试的平均工作，并且仍然依赖后期UI和系统测试。API测试提供了开发人员和测试人员之间理想的通信机制，并具有高度可维护的自动化水平，可以扩展到性能和安全性测试中。
将这些测试左移并在软件生命周期的较早时间执行它们意味着及早发现关键的安全性和体系结构缺陷，在这些缺陷中，它们更易于诊断且修复风险较小。利用Parasoft SOAtest的Smart API Test Generator提供的自动化功能，API测试更加容易访问，并且可以大大减少与创建有意义的测试方案相关的时间。