【发布时间】:2017-12-09 11:49:30
【问题描述】:
有没有一种方法可以自动测试 Adobe AEM 工作流程?
我查看了Hobbes.js,但据我所知,没有提到工作流程。如果它处理跨多个用户的工作流,这将是理想的。
我认为这对 Cucumber 来说可能太具有挑战性并且难以可靠地工作。我也考虑过Prosper,但这本质上是模拟框架。
【问题讨论】:
标签: testing automated-tests workflow aem
有没有一种方法可以自动测试 Adobe AEM 工作流程?
我查看了Hobbes.js,但据我所知,没有提到工作流程。如果它处理跨多个用户的工作流,这将是理想的。
我认为这对 Cucumber 来说可能太具有挑战性并且难以可靠地工作。我也考虑过Prosper,但这本质上是模拟框架。
【问题讨论】:
标签: testing automated-tests workflow aem
测试工作流程可能很棘手,但有可能。如果您考虑一下,它与测试任何其他 Web 应用程序并没有太大区别。您只需要一种方法来控制浏览器、在帐户之间切换并以易于理解的方式管理可能复杂的测试场景。
在我看来是 Hobbes 的主要问题的另一个关键要求是测试代码需要能够从命令行轻松执行并生成有用的报告以供以后使用。没有这个,就很难将此类测试集成到 CI 服务器上的任何自动化管道中。
我目前的项目团队在测试定制的审批和复制工作流程方面取得了一些成功。与我们实际定制工作流程所花费的时间相比,编写测试花费了很多时间,但测试是稳定的。
我们的方法依赖于基于浏览器的 Author 实例测试,使用 Selenium Web Driver Java(用于浏览器控制)、Google Guice(用于管理复杂的页面对象图形和各种实用功能)和 JUnit/Cucumber控制测试场景。
主要挑战之一是 WYSIWYG AEM 创作界面在加载速度方面往往表现得不是很可靠。有很多动态部分,其中一些是基于 ajax 调用的。
如果您使用带有 ExtJS 前端和很多很多 iframe 的 Classic UI,那么这项任务尤其困难。在我看来,使用 Touch UI,定位正确的界面元素要容易得多。
也就是说,在您能够有效地编写测试代码之前,您必须付出很多努力来弄清楚这些接口的怪癖。
我工作的公司注意到,根据我们在众多 AEM 项目中的经验,我们构建了一个框架,让人们无需考虑大部分样板代码。它提供了开箱即用的接口,用于与 AEM UI 的关键元素进行交互。
我们在 Apache 2.0 许可下开源了它。它被称为山猫。随时查看the project's Github page 并查看simple example project。
山猫也在 Cognifide 之外被采用。这个blog by liatrio 很好地总结了他们发现特别有用的功能。
【讨论】: