用于大规模应用的Selenium自动化的最佳设计模式

Question

我想知道用于自动化大规模SaaS产品的Selenium的最佳设计模式。

期待您对此的所有评论。

对于大型应用程序，我更喜欢将web元素的xpath保留在页面对象文件中。但是我的领导希望我将xpath保存在属性文件中，我们应该访问每个xpath的属性文件。对于大规模的SaaS应用程序，这是一个将xpath保存在属性文件中的好方法吗？

Answer 1

您的leed希望您实现Object Repository Pattern。

我认为这个想法和HP QTP (QuickTest专业版)一样古老，因为它被广泛使用-但我可能错了，这只是我的观点。

简而言之(引用上面的链接)：

对象存储库是一个集中的位置，我们可以在其中存储对象信息，它充当测试脚本和应用程序之间的接口，以便在执行期间识别对象。

我们总是建议使用外部文件作为对象存储库，而不是将对象及其属性直接硬编码到我们的代码中。如果你问我为什么会这样？原因是，由于它减少了维护工作，并提供了积极的ROI，例如，在我们的测试应用程序中，任何对象属性都发生了更改，我们可以很容易地在外部对象存储库文件中更改它，而不是在代码中单独搜索和更新该对象

想一想这样一个场景，你有一个网页，它有多个部分，多个框架和数百个WebElements。显然，你不希望一旦你输入了页面名称，它就会给你提供网页上所有可用的元素。如果元素很少，可以使用相同的结构，但如果有很多元素，则建议将页面划分为不同的部分，例如页眉、页脚、左导航、居中内容和右导航。然后将每个WebElement归类到它们的父元素下。

我认为这个模式与Page Object模式并不矛盾，它们都可以很好地协同工作。它为项目带来了更大的透明度，并迫使开发人员/测试人员保持项目更好的可读性，这有助于在未来维护它。

但以上只是理论上的一点，有人可能会问，这种模式在现实生活中是如何帮助的？

考虑一个简单的例子。假设有一段代码：

public class SomePageObject{
   .....
   .....
   public void doSomething(String value){
      findElement( By.xpath("//*[ @class='left-content']//button[ contains( ., 'list-selector' )]") ).click();
      wait.until( ExpectedConditions.visibilityOfElementLocated( By.xpath( String.format( "//li[ *[ text() = '%s' ]]", value ))).click();
}

这样的代码我已经看过上百次了。你觉得这段代码怎么样？

是的，它遵循众所周知的Page Object模式。但这是可怕的。

看这段代码，你能猜出它在做什么吗？定义No.

当此代码由于第二个元素的UI更改而中断时，您会在日志中得到什么错误消息？很可能是这样的：

org.openqa.selenium.TimeoutException: Timed out after 30 seconds 
waiting for visibility of element located by By.selector: //li[ *[ text() = 'New York' ]]

只看这条错误消息，您能猜到它涉及应用程序的哪一部分吗?在代码中可以找到它的位置吗？No.

自动化工程师可以在查看堆栈跟踪的代码中找到它，但不了解java、selenium等的初级测试人员不能仅查看错误和printscreen (如果可用)来修复它。

在许多情况下，为了修复错误，自动化工程师需要在本地计算机上运行此测试用例以复制问题。

它看起来像是使用对象存储库模式吗？

可以有一个如下所示的属性文件：

....
orderPage.citySelectButton=//*[ @class='left-content']//button[ contains( ., 'list-selector' )]
orderPage.citySelectListElement=//li[ *[ text() = '%s' ]]
...
...

代码可能如下所示：

public class SomePageObject{
   .....
   .....
   public void doSomething(String value){

      objRepoFacade( "orderPage.citySelectButton" ).click();
      objRepoFacade( "orderPage.citySelectListElement", value ).wait().click();
      ...
    )
}

日志中的错误消息可能如下所示：

RuntimeException: time out waiting for element: orderPage.citySelectListElement
located by By.selector: //li[ *[ text() = 'New York' ]]

现在，即使是初级测试人员，只看着这个错误消息，也能够很容易地猜测错误发生在应用程序的哪个部分，以及确切地说哪个元素被破坏了。测试人员可以训练如何使用开发人员控制台(F12)检查页面上的元素，更正procerties文件中的选择器，并在没有自动化工程师的帮助和根本不接触代码的情况下自行修复问题。

从您的leed的角度来看，后者(对象存储库)是一个更好的解决方案，因为它可以雇佣更多的初级测试人员和更少的自动化工程师，并降低成本。