我想知道Selenium用于自动化大规模SaaS产品的最佳设计模式。
寻找你对此的所有评论。
对于大规模应用程序,我更喜欢在页面对象文件中保留我的xpath用于web元素。但我的主管要求我将xpath保存在Properties文件中,我们应该访问每个xpath的Properties文件。这是将xpath保存在大规模SaaS应用程序的属性文件中的好方法吗?
答案 0 :(得分:0)
你的leed希望你实施Object Repository Pattern。
我认为这个想法与HP QTP(QuickTest Professional)一样久远 - 它被广泛使用 - 但我可能错了,它只是我的意见。
简而言之(从以上链接引用):
对象存储库是我们可以存储对象的集中位置 信息,它充当测试脚本和应用程序之间的接口 以便在执行期间识别对象。
我们始终建议将外部文件用于对象存储库,而不是对对象及其属性进行硬编码 直接进入我们的代码。如果你问我这是为什么?原因是 它减少了维护工作量并提供了积极的投资回报率 例如,我们的应用程序中的任何对象属性都会发生变化 在测试中,我们可以在外部对象存储库中轻松更改它 文件,而不是搜索和执行该对象的更新 单独在代码中
想象一下你有一个网页,它有多个网页 部分,多个框架和数百个Web元素。显然你 一旦你输入了页面名称就不要这样了,它会给你全部 网页上提供的元素。如果元素很少,那就是 没有相同的结构是好的,但如果有很多,那么它是 建议将您的网页划分为不同的部分,例如 页眉,页脚,左侧导航,中心内容和右侧导航。 然后将每个WebElement分类在其父元素下。
我认为这种模式与页面对象模式并不矛盾,它们可以很好地协同工作。它为项目带来了更大的透明度,并迫使开发人员/测试人员保持更好的项目可读性,这有助于将来维护项目。
但上述只是一点理论,有人可能会问这种模式在现实生活中有何帮助?
考虑一个简单的例子。假设有一段代码:
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();
}
我已经看过这样的代码一百次了。您对此代码有何看法?
是的,它遵循众所周知的页面对象模式。但这太可怕了
看看这段代码,你能猜出它在做什么吗? Definitelly No.
当此代码因第二个元素的UI更改而中断时,您将在日志中收到什么错误消息?最有可能是这样的:
org.openqa.selenium.TimeoutException: Timed out after 30 seconds
waiting for visibility of element located by By.selector: //li[ *[ text() = 'New York' ]]
您能猜到,只查看此错误消息,它关注的应用程序的哪个部分以及可以在代码中找到的位置? 不。
一个自动化工程师可以在代码中查找堆栈跟踪,但是一个不知道java,selenium等的初级测试人员无法修复它只查看错误和打印屏幕(如果可用)。
在许多情况下,为了修复错误,自动化工程师需要在本地计算机上运行此测试用例来复制问题。
如何使用Object Repository Pattern? 可以有一个属性文件,如下所示:
....
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),更正过程文件中的选择器,并在没有自动化工程师帮助的情况下自行解决问题,而根本不需要触摸代码。
从您的视角来看,后者(对象存储库)是一个更好的解决方案,因为它可以雇用更多的初级测试人员和更少的自动化工程师并降低成本。