Salesforce上的UI测试自动化

测试自动化可能很棘手,测试和质量工程师在过渡到Lightning时,在与最佳实践保持一致、使用什么工具以及更新自动化方面费尽心思是很正常的。这篇博文介绍了Salesforce上UI测试自动化的情况,重点介绍了Salesforce测试的独特考虑因素和可用的解决方案,以便您能够就哪种UI测试自动化解决方案最适合您的Salesforce组织做出明智的决定。

在Salesforce平台上进行测试的独特考虑因素

Salesforce上的UI测试自动化在测试创建和测试维护方面都有一些独特的特点。

测试创建

在Lightning中,我们有意识地决定隐藏元素的标识符。这就避免了开发人员直接依赖可能会随着时间推移而演变的实现细节。虽然从开发的角度来看,这种不透明性提高了组件的长期可维护性,但它阻碍了UI测试自动化,因为在历史上,UI测试自动化一直依赖于这些类型的实现细节来识别页面上的视觉元素。

此外,Lightning Web Components还利用Shadow Document Object Model(Shadow DOM)作为隔离机制,防止组件之间相互影响。组件之间的Shadow DOM边界打破了传统的页面元素定位方式。

测试维护

Salesforce 致力于不断提高可用性,为客户提供新的、更有效的方式来实现其业务目标。此外,我们最近将页面从 Aura 迁移到 Lightning Web Components 的努力,使其底层结构发生了重大变化。所有这些变化的一个副作用是对测试维护的影响。由于这些改进修改了文档对象模型(DOM)的结构,因此依赖于DOM中具体实现细节的测试往往是脆弱的,需要在各个版本之间不断地更新。

解决办法

如果您希望在 Salesforce 上自动进行 UI 测试,您可以使用三种潜在的解决方案。对于每一种解决方案,我们都会介绍需要牢记的主要考虑因素。

来自独立软件供应商的商业现成产品

来自Salesforce生态系统的第三方付费解决方案可以让你通过“点击而非代码”来构建一套自动化的UI测试,可以说是UI测试自动化的一个非常不错的选择。负责这些解决方案的独立软件供应商会随着每一个Salesforce版本的发布而更新他们的工具链,以确保建立在其解决方案上的测试能够继续顺利运行。这些解决方案最适合拥有管理资源的客户,他们对基于点击的解决方案感到满意。

主要考虑因素

  • 客户负责通过No Code解决方案实施测试套件。
  • 测试维护成本降低了,因为供应商不断地更新他们的框架,以抽象出与每个Salesforce版本相关的页面变化。
  • 许可证的费用可能很高
  • 测试不能轻易移植到其他测试框架中(供应商锁定)。

与系统集成商合作构建自定义测试自动化基础设施

如果您拥有最少的内部工程和管理资源和/或现有的系统集成商关系,此解决方案可能适合您。作为 Salesforce 生态系统的一部分,有许多系统集成商合作伙伴为不希望在内部构建自己的软件解决方案的客户提供全面服务解决方案。对于没有必要的人员来构建和维护自己的测试自动化的客户来说,与系统集成商合作构建定制的测试自动化基础设施可能是最可行的解决方案。在 Salesforce 定制已经由系统集成商执行的情况下,扩展合同以包括 UI 测试自动化可能是一个合理的策略。

关键考虑因素

  • 由第三方咨询合作伙伴提供的全面服务解决方案。
  • 系统集成商服务可能会很昂贵
  • 对于已经与系统集成商合作的客户来说,增加UI测试自动化服务的边际成本可能低于与系统集成商建立新的合作关系的成本,而这种合作关系仅仅是为了测试自动化。
  • 系统集成商对测试的持续维护可能需要单独的服务合同。
  • 根据实现情况,测试可能会被移植到其他测试框架中。

开源测试框架

最后,我们的第三种也是最定制的解决方案是使用开源测试框架,是指当以上选项不够用,而你又有很多工程资源的时候。有多个开源测试框架可用于基于浏览器体验的UI测试自动化。我们简要讨论最常见的,但你可以探索和使用其他框架。

核心Selenium

Selenium WebDriver是W3C WebDriver规范中最流行的实现。尽管它很受欢迎,但它为测试自动化提供了赤裸裸的支持,并且经常需要额外的辅助工具来补充其基本功能。例如,与WebdriverIO相比,它没有内置对Shadow DOM的支持。寻求Shadow DOM支持的客户需要自己实现这些功能。

WebdriverIO

WebdriverIO是一个现代的、基于JavaScript的、基于WebDriver规范的测试框架,它提供了Selenium所没有的大量功能,包括作为一级公民的Page对象和Native Shadow DOM遍历。它提供了Selenium所没有的大量功能,包括作为一级公民的Page对象和Native Shadow DOM遍历。然而,它仍然需要大量和持续的工程投资。

关键考虑因素

  • 客户负责通过Pro Code技术实施和维护测试基础设施和测试套件(需要工程资源)。
  • 开源框架和工具是免费的
  • 从工程角度来看,测试套件的持续维护成本很高。
  • 测试可以移植到其他测试框架中,只需进行相对较小的修改。

经验教训

虽然在给定的Salesforce组织的UI测试自动化策略中需要考虑多种独特的因素,但Salesforce生态系统中有大量的解决方案。根据每个 Salesforce 客户的特点,决定使用哪种解决方案是不同的。

链接和资源

对于那些对使用开源测试框架感兴趣的人来说,这里有一些技术资源,可以帮助您克服在Salesforce平台上进行测试的一些独特考虑因素。

缺乏元素标识符

  • 自定义定位器的连锁化
  • 使用定位链查找子元素

影子DOM封装

  • WebdriverIO:影子DOM支持和可重用组件对象。
  • 使用Selenium处理阴影DOM的指南

不断变化的页面结构

  • WebdriverIO: 页面对象模式
  • 在Selenium测试中使用页面对象模式的入门方法

关于作者

乔纳森-欧(Jonathan Au)在Salesforce平台上推动各种大规模的战略计划。他热衷于技术的变革力量,并且是一个终身学习者。你可以在Trailblazer.me上关注他。

猜你喜欢

转载自blog.csdn.net/Pokemogo/article/details/114579471
今日推荐