彩票走势图

API测试能否在COVID-19的新标准中添加效率调节器?

原创|使用教程|编辑:郑恭琳|2020-11-26 16:28:03.797|阅读 161 次

概述:

# 慧都年终大促·界面/图表报表/文档/IDE等千款热门软控件火热促销中 >>

相关链接:

对传统的软件交付方式的影响

随着组织继续应对COVID-19的影响,企业正在研究如何在“新现实”中重新定义测试实践。持续的大流行以多种方式损害了组织测试和交付软件的能力。

资源受限

首先也是最重要的一点是,由于许多工人根本无法以与办公室相同的能力在家工作,因此资源限制继续上升。此外,由于许多企业正在利用全球系统集成商的资源,因此不同地区已经建立了有关工作条件的特定规则。许多组织根本无法抗衡这种影响,因此领导者正在寻找解决方案,以更少的资源来实现相同的测试要求。

远程团队合作

接下来,组织需要考虑受约束的团队和远程团队的协作方式。有趣的是,持续的隔离状态如何造成不适感,从而严重影响远程工作的团队。这是因为,对于我们这些在办公室工作的人来说,走进某人的办公室并就最新版本进行对话太容易了。


社交互动的这种水平使我们能够讨论我们的日常任务以及对质量和过程的担忧。以纯远程身份工作会限制这些活动,并使我们处于完全孤立的状态,或者对于大多数组织而言,使我们完全分心。寻找与远程团队合作的正确方法是一项挑战,因此您需要在沟通不足和沟通过大之间取得平衡。拥有正确的协作软件、治理和最佳实践,可以帮助组织在新的现实中蓬勃发展。

软件交付机制

接下来,IT组织必须从根本上重新考虑其软件交付机制。对于向客户提供数字体验的组织而言,“移动优先”开始变得尤为重要。这一点特别重要,因为您无法在商店中与客户进行实际互动。它严重影响了呼叫中心。现在,数字化业务在很大程度上代表了您的品牌。一切都变成了纯数字领域:从通过应用程序订购食物、在线银行、订购和交付关键药品,甚至买衣服。组织需要能够快速发展并迅速将这些体验交付给这个瞬息万变的世界,以使他们与客户之间失去联系。

与此挑战相关的是组织必须考虑的实际交付机制。在为客户重新考虑和设计数字体验的同时,我们需要考虑如何通过DevOps管道开发、测试和交付数字内容。

转向云生态系统和低代码开发平台

COVID-19大流行促使许多组织通过将其软件转移到云生态系统和低代码开发平台中来实现其交付机制的现代化,以便地理上分离的开发人员和测试人员可以协作并迭代以提供最佳体验。

我们看到向SalesforceGuidewireMendix等平台的迁移正在增加。对于资源有限的组织来说,不仅可以实现快速交付,还可以利用这些平台固有的所有功能。

最重要的是,随着通过CI管道进行软件开发和部署的方式现代化,我们看到了向Azure运维,Pivotal CloudAmazon Web ServicesAWS)等云平台的迁移。

软件IT公司必须忍受。他们必须在有限的资源下,以更快的速度向客户提供高度互动的数字体验。但是必须付出一些。

通常,凭借这些竞争力,您最终会牺牲过程质量。与以往相比,确保质量至上至关重要,以确保通过数字体验与您直接互动的客户不会受到影响。在受限的环境中继续提供优质体验的最佳方法是为您的测试实践寻求“效率调节器”。


效率调节器为您节省时间

这些“效率调节器”是什么?它们有几种不同的形式:

  • 智能测试设计和优化
  • 对代码覆盖率的综合要求
  • 智能测试执行

智能测试设计与优化

在现代应用程序中要测试的东西太多了,包括前端UI,包括数据库在内的中间件服务,后端系统和第三方依赖项。这些每一层都增加了整个测试过程的复杂性。许多软件测试工具供应商提供解决方案来测试此体系结构。但是重要的是要确保您可以准确地完整地测试每个组件,从编写第一行代码到完成的应用程序中的智能UI测试,一直到整个过程。

设计和优化这些必要测试的捷径是利用人工智能。组织正在寻找结合人工智能的智能解决方案,以优化测试创建过程。这可以采取智能代码扫描的形式,以识别代码编写过程中的不良做法,自动生成单元测试,识别API序列中的模式和关系,以创建全面的测试方案。最后,在UI层使用基于AI的自我修复功能来从更改的应用程序界面中恢复。

对代码覆盖率的全面要求

仅仅创建一堆测试是不够的。为了快速验证应用程序,您需要了解每个测试如何与业务需求相关联,以便您可以了解优先级以及优先级与基础代码的相关性,以便可以开始了解测试的完整性。

因此,对于受约束的测试团队来说,一个强大的效率修改器是建立一种测试实践,在该实践中,测试用例与业务需求和开发代码紧密耦合,以创建全面而全面的质量视图。

智能测试执行

现在,一旦您完成了一系列测试,并且了解了如何通过将测试结果与需求联系起来就可以从优先级的角度对测试结果进行操作,那么您就需要能够以最有效的方式执行那些测试。大多数组织会在一夜之间运行整个测试套件。然后,第二天花一半时间仔细研究这些结果,以尝试确定是否确实出现了问题或是否存在“自动化噪音”。

提高测试执行效率的最佳方法是执行智能测试执行。这仅是您需要运行以验证对应用程序所做的更改的那些测试用例的执行。通过使用诸如智能测试执行之类的技术,您可以:

  • 快速识别那些会影响更改的测试用例。
  • 将它们链接到相关需求。
  • 了解优先级。
  • 确切地告诉您的测试团队他们需要做什么。

上面列出了许多质量难题。这些测试实践中的许多实践已被广泛理解,例如测试数据库的能力或测试UI的能力。但是API测试是一门经常被忽视并留在应用程序测试后期的学科。


API测试的重点观点

API测试是在服务或组件级别验证应用程序中的接口的实践。这些API是机器彼此之间进行通信的机制,一旦将它们组合在一起,它们通常就成为应用程序的切入点。尤其是在当今面向服务或微服务体系结构的世界中,这一关键的集成点对于创建数字体验至关重要。

通常,移动应用程序只是一系列服务的前端,而这些服务就是为您提供关键业务价值的东西。因此,组织需要与其他测试技术同时创建全面的API测试实践。

这说起来容易做起来难,但是,因为大多数API接口的文档记录不充分,或者包含一系列隐藏的和未记录的API。对于测试团队来说,要了解如何按顺序测试所有API以及确保他们正确涵盖了正确的用例数量,确实是一个挑战。


如何将API测试纳入您的测试实践中

一旦组织决定接受API测试作为效率修改器,关键是要以有意义的方式开始。启动此过程的最佳方法是确定应用程序体系结构中可用API的清单。Parasoft SOAtest的智能API测试生成器使您可以通过记录应用程序与API服务之间的交互来发现API

该技术利用人工智能(AI)通过了解API序列中的模式和关系来提供有意义的API测试。然后,它使用它来创建自动运行的API测试,以连续运行以验证各种系统组件之间的交互。

同时,您可以使用创建纯Selenium UI级别测试。UI测试是整个测试实践的重要组成部分,但是纯粹以UI为中心的测试策略可能会引起可维护性问题。使用AI来识别测试脚本稳定性问题,并可以在运行时自我修复测试。

虽然这不是本次对话的重点,但将这两个组件组合在一起可以确保广泛地覆盖应用程序,并有助于您确信应用程序界面不会受到威胁。

如果您已经有现有的基于SeleniumUI测试,则可以使用提取相关的API调用并将其提供给API测试引擎。通过盘点可用接口并为这些接口创建自动化测试,您可以快速开始构建API测试实践。


我如何知道何时完成API测试?

这是一个非常复杂的问题。您怎么知道什么时候经过足够的测试?关于这个主题有很多争论,但是我认为它可以分解为三个指标。

  • 代码覆盖率
  • API覆盖率
  • 需求范围

获取代码覆盖率

代码覆盖率在很大程度上很容易获得。您可以使用代码级监视器来对应用程序进行检测,并通过API来执行应用程序。代码级监视器将识别与之交互的类和方法,并将该信息传递回您的报告和分析引擎中。

就其本质而言,API不会通过API公开所有可用的代码功能,因此您的组织需要确定API可以访问哪些代码。掌握了这些信息后,就可以为要通过API测试实现的代码覆盖率级别设置一个阈值。通常,达到80%是一个不错的水平。

获取API覆盖率

代码覆盖只是故事的一部分。您还希望查看API覆盖率。API覆盖率是一种指标,用于指示在可访问的可用API总数中,您的自动化API测试中测试了其中的多少API。在许多情况下,尽管您实现了较高的代码覆盖率,但由于您尚未验证某些关键的API,因此在应用程序中仍有风险。

也许这些关键的API仅涉及代码的一小部分,因此它们在整个代码覆盖范围中迷失了,但是由于它们涉及关键的组成部分,因此如果行为不当或被故意滥用,则会带来巨大的风险。

通过在服务定义中可用的服务(例如Swagger,开放式API等)与在API测试中访问的那些端点之间得出差异,可以通过自动化测试解决方案实现API覆盖。通过此度量,您将能够查看所覆盖的服务总数与可用服务总数之间的关系。通常,取决于API的大小,达到90%是一个不错的水平。

获取需求范围

最后,我们需要讨论需求范围。尽管代码覆盖率和API覆盖率表明了您正在触摸的应用程序所占的百分比,但它们并没有表明它是否能达到您对客户的期望。

需求覆盖是将需求与测试方案相关联的过程。您必须确定自动化测试方案可以从技术层面验证用例。然后,您将能够通过执行了解是否满足您的所有要求。如果没有,哪些要求仍然存在?他们的业务重点是什么?

有人认为需求覆盖率是这三种技术中最重要的-理想情况下是100%覆盖率。但是,实际上,必须结合使用所有三个指标才能充分了解何时具有可接受的发布风险级别。


如何缩短缺陷识别与修复之间的差距?

在远程工作环境中,持续反馈至关重要。我们必须能够以有意义的方式并尽快地应对数字体验中出现的质量问题。由于API表示您可以最接近代码而无需实际查看源代码,因此它们代表了质量工程的良好第一道防线,以识别何时将缺陷引入到应用程序中并有可能传播给用户。自动化的API测试可让您持续验证API。可能作为CI/CD管道中的构建步骤。确保此过程可扩展的关键是接受智能测试执行。

如前所述,智能测试执行是一个笼统的术语,是指仅执行验证更改所需的测试的过程。这些更改可能来自代码或要求。

通过在CI/CDDevOps流程中执行智能测试执行,您可以执行适当的API测试以验证不断变化的体系结构。通过不为每个构建执行完整的测试套件,您可以显着减少从缺陷检测到修复之间的时间。在资源有限的世界中,这些快速的反馈周期至关重要。


总结

世界已经改变。面对现实吧。在可预见的将来会是这样。但是我们不需要把这个看作烦恼的时间。相反,我们可以将其用作数字转换的机会。

通过向内看我们的质量流程并确定要添加效率调节器的领域,我们可以以更有利的位置摆脱这一大流行。API测试是组织可以采用的许多实践之一,可以为我们的应用程序的可靠性和可扩展性提供有价值的见解。

要了解有关构建API测试实践的更多信息,请观看我们的点播网络研讨会




标签:

本站文章除注明转载外,均为本站原创或翻译。欢迎任何形式的转载,但请务必注明出处、不得修改原文相关链接,如果存在内容上的异议请邮件反馈至chenjj@pclwef.cn


为你推荐

  • 推荐视频
  • 推荐活动
  • 推荐产品
  • 推荐文章
  • 慧都慧问
扫码咨询


添加微信 立即咨询

电话咨询

客服热线
023-68661681

TOP