ui 基于jenkins_7个重要考虑因素，助你成功选型UI测试工具

最新推荐文章于 2024-05-13 16:24:12 发布

weixin_39695306

最新推荐文章于 2024-05-13 16:24:12 发布

阅读量95

点赞数

文章标签： ui 基于jenkins

本文链接：https://blog.csdn.net/weixin_39695306/article/details/111681958

版权

在过去的几年中，UI测试的活动有所增加。新的令人兴奋的工具已进入市场，带来了各种创新方法，使传统上相当复杂的过程变得简单。

过去，我们只有大型解决方案，例如IBM Rational Suite或Mercury/HP/MicroFocus QTP/UFT。现在，我们看到许多人从“传统”测试自动化工具转向诸如Selenium之类的开源替代方案，或由mabl，Selenic或Functionize之类的新型创新AI驱动的解决方案或框架。这种转变引起了很多炒作，但它也植根于解决常见的抱怨和挑战，如果您采用的是新工具，则需要确保解决。

7个重要考虑因素，助你成功选型UI测试工具

但是，当然，这不只是挑选“最佳人选”并前往城镇而已。无论您是决定自己构建框架，拥有最终控制权，还是决定进入拥有高级功能(如自我修复或并行执行)的专有框架，任何解决方案中都应具备七个重要因素考虑。

1.是Selenium吗？

听起来像是个问题，对不对？不是。对于希望自动进行Web UI测试但又不想被锁定在供应商平台中的组织，Selenium已迅速成为事实上的标准。

7个重要考虑因素，助你成功选型UI测试工具

作为一个社区，Selenium开放源代码项目将商业供应商和开放源代码纯粹主义者聚集在一起，使之成为我们行业中最强大的框架之一——并且正在被大量使用。

根据我们的研究，超过64％的用户正在使用Selenium进行UI测试自动化。你是？

这是必须考虑的因素。您在使用Selenium吗？如果不是这样，那么现在正是考虑未来的好时机，以及您希望未来的测试计划有多灵活。现在市场上的许多解决方案都具有类似Selenium的功能或基于Selenium的，专注于导入/导出纯Selenium测试的价值。但是它们不能在纯Selenium上运行，也不能执行纯Selenium，因此您必须在其技术的限制内工作。

2.是否使用页面对象模型？

页面对象模型是一种UI测试设计范例，用户可以在其中定义与它们所在的页面相关联的UI元素。如果您还不熟悉，这是有关页面对象模型的精彩教程。为了主动解决可维护性问题，您希望UI测试利用此页面对象模型范式，因为由于元素位置被定义在一个位置，然后在整个测试套件中加以利用，使得维护脚本更加容易。

7个重要考虑因素，助你成功选型UI测试工具

页面对象方法功能强大，因为它有助于解决应用程序更改时的可维护性问题。在页面对象模型中，页面上的元素是在一个位置定义的，因此，如果您确定某个特定的Web元素已经移动，则不必遍历整个脚本来更新每个单独的定位器。页面对象模型使您可以为页面上的元素提供单一的事实来源，从而使所有这些工作更加自动化。

3.是否推荐智能定位器？

7个重要考虑因素，助你成功选型UI测试工具

执行UI测试时发生的大多数维护问题源于由于应用程序UI更改而中断的测试用例。因此，在设计UI测试时要做的最重要的事情之一就是建立一种方法来为每个元素定位器创建可靠性和稳定性。

一些新的UI测试工具正在采用独特的创新方法，使用各种不同的术语，即“智能定位器”或“魔术绑定”。无论如何，在为单个元素定义多个定位器或采用最佳定位器定义策略方面，您有很多潜力可以从所有这些创新中受益。

4.测试脚本可以自我修复吗？

自我修复听起来像是在做梦，在这种情况下，我们的自动化测试会自动识别故障发生的位置，然后自行解决问题。疯狂的是，这实际上在许多流行的UI测试工具中都是现实的。通过利用智能定位器，这些UI测试工具可以在运行时尝试不同的定位器或在UI中自动识别按钮的方式。

现在，我已经下定决心，在任何UI测试解决方案中，我都将其视为严格的必要条件，因为最终我们将尝试减少测试流失和总体测试周期。如果您已经创建了数千个UI测试并且每天晚上运行它们，那么您就不希望其中的一半中断，因为有人将按钮从“添加”更改为“购物车”，然后又添加到了“购物篮”。

5.它可以集成到我现有的工具链中吗？

在您的软件开发组织中，您可能已经在某种类型的IDE(即Eclipse，IntelliJ)中编写代码，并且可能正在使用Jenkins之类的构建系统来构建该代码。这些框架将在您的整个组织中建立，它们都是经过实践检验的框架，因此对于将UI测试解决方案集成到已构建的框架中而言，这显然是有益的。

许多UI测试工具都是各自独立的工具，因此可能确实很棒，因为这意味着它们专注于构建可解决所有这些挑战并最终控制生成的测试脚本的解决方案。但是供应商锁定(我将在后面再讨论)是危险的，并且我们已经看到组织正因为这个原因而放弃大型解决方案。由于开发人员和测试人员比以往任何时候都更加精通技术，因此他们希望访问其测试脚本。因此，当您查看UI测试工具时，可以看到您的测试脚本是否可以移植，不仅可以与必须集成到DevOps管道中的其他脚本一起使用，还可以真正地集成到现有框架中。

6.是否提供支持？

用户体验在B2C Web应用程序中尤其重要，在该应用程序中，令人困惑的UI或不可靠的客户体验会迅速影响收入，并且组织意识到确保体验的无缝性至关重要。随着每天涌现出新项目并且测试要求如此之高，尤其是在转向敏捷时，能够使自己摆脱困境可能意味着准时发布和错过窗口之间的区别。您的UI测试工具将帮助您验证关键的客户体验-但是，如果您尝试做某事并且无法弄清楚，让供应商的支持团队为您提供畅通无阻的选择是您可以做出的选择，随时随地都有。

有一些开放框架可以很容易地集成到您现有的框架中，但是如果没有强大的支持，当在关键版本发布之前出现问题并且没有人负责时，会发生什么？Selenium是一个很好的例子-尽管它功能强大，并且拥有出色的社区支持，但是当出现问题时，没有人可以打电话。

7.您可以避免供应商锁定吗？

正如我之前所说，在过去几年中，有20多种新的UI测试工具进入了市场。接下来的五个代表什么？毫无疑问，我们现在所做的一切都会改变，尤其是从UI测试的角度来看。必然会出现一些令人兴奋的新事物，因此现在考虑我们如何促进迁移过程非常重要。这样做的关键是确保您引入的任何解决方案都不会将您锁定在专有框架中。

由于Selenium可以在任何管道中轻松执行并以代码形式实现，因此它具有很高的灵活性。一些新的解决方案已考虑到这一点，并使用导入/导出机制来允许您切入和退出其工具，但是导入和导出需要验证其是否有效。这并不像您想的那么容易。在我看来，如果供应商对其功能有信心，则应提供此功能。当您查看UI测试工具时，您可以问：“我是否被其框架所束缚？”