Gartner调查API测试、虚拟服务和持续性测试.docxVIP

Gartner 调查：API 测试、虚拟服务和持续性测试 随着敏捷开发实践的成熟，以及DevOps 原则开始渗入到我们企业的文化当中，公司组织们意识到了加速软件交付的明显的机遇。然而，当你加速任何过程的时候，不成熟的实践领域和障碍就变得愈发明显。这就像以5 英里每小时和以 50 英里每小时的速度通过一个减速带的区别一样，当以 50 英里每小时的速度通过减速带时，将会发出非常刺耳的碾轧声。加速任何业务流程都会暴露出束缚整个组织使其低速运行的限制组件。在加速 SDLC（系 统开发生命周期）方面，测试已经成为充分利用迭代方法开发软件的最大障碍。对于使用这种变革开发策略的组织来说，必须从自动测试向持续性测试转变。描述自动测试和持续性测试的区别似乎像是一种语义上的界定，但是自动功能测试和执行持续性测试进程之间的差距是相当可观的。 在自动测试和持续性测试之间存在着许多细微的差别影响着两者的转换。在这篇文章中， 我们聚焦三个主要的区别： 调整测试和商业风险 对完整测试环境的普遍访问 在 API/消息层的极端的自动化测试 调整测试和商业风险 从自动化到持续性转变的最根本的要求是调整测试和商业风险。特别是在DevOps 和持续性软件的交付上，快速有信心的软件发布要求对将要发布的软件相关的商业风险进行即时反馈。鉴于成本上升和软件失败的冲击，发布一款扰乱现有用户体验或是引进使组织暴陷入安全、可靠和合规风险中的新特征的代价是难以承受的。为了避免这种情况，组织需要从确 认自底层向上的要求延伸到评估与首要的商业目标相关的系统需求。 对完整测试环境的普遍访问 进行有效测试的最大限制之一是访问完整的测试环境，包括无数个与测试应用程序 （AUT）相交互的独立的系统。考虑到现今应用程序的复合性，几乎不可能实现一个完整的 测试环境。而这正是虚拟服务发挥作用之处。虚拟服务使你可以模拟像API 驱动程序，基于云的应用程序和服务导向式架构等基于多种组件的应用程序中特定组件的行为。通过模拟测 试程序（AUT）与缺失的或不可用的依赖性的相互作用，虚拟服务帮你确保数据、性能和和 行为在不同测试中的一致性。此外，它还能帮助你“左移”测试，在迭代和缺陷很容易快速修复的时候，每一次循环的开始都会非常容易。 作为一般规则，如果不能在生产中测试，你也应该针对可以访问的最接近生产的环境进 行测试。然而，这就在成本、安全和隐私领域非常具有代表性地提出了一个相当大的挑战。使用诸如虚拟服务这样的模拟技术，允许你绕开不可控的独立系统的限制，以便于进行有意 义的端对端测试。 在API/消息层的极端自动化测试 在 API/消息层(服务、消息队列、数据库抽象层等)的测试，提供了几个不同的优点以确保在DevOps 速度下的持续性测试。 稳定性：尽管 GUI 测试经常由于不合逻辑的应用更改而失败，在API/消息层的失败代表性地传递了一个应用程序逻辑的基本缺陷——一些可能影响核心用户体验的东西。如果你配置了一个测试组件，却不能作为一个调度队列的“门”进行服务，确保每一个错误指向一个妨碍进行的问题是非常重要的。 速度：传统的测试方法主要依赖人工测试和自动GUI 测试，要求频繁的更新，无法跟上DevOps 所需的速度。测试被推迟到 GUI 可用的时候，经常延误测试的进程。此外，众所周知，GUI 测试非常脆弱而且每一次应用程序更改都需要重大的更新。API 测试可以被定义为一旦服务描述（如Swagger 或 RAML）可用，（API 测试）在实施测试进程中可以比GUI 测试更早地执行，而且需要最小限度的维护。 精确的风险评估：在现今的应用程序中，GUI 层暴露的功能只是冰山一角。应用程序逻辑的核心被 API/消息层所控制。没有在API/消息层对关键用户的穷举调试，很难确信现今的高度分布式的系统能够起到期待中的作用。 从自动测试进化到 DevOps 持续性测试 下载一个从自动测试升级到DevOps 持续性测试的免费副本，再现高德纳公司在关于“为什么 API 持续性测试和虚拟服务对于加速和自动化创新及市场细分型软件的交付是必不可少的”的调查和看法。这个新的长达11 页的报告涵盖了： 自动化测试和连续性测试的三个关键区别 为什么服务虚拟和API 测试对于连续性测试是至关重要的——并且，怎样为它们制作一个商业实例 关于连续性测试、DevOps、集合和持续交付等的首要问题（和答案）