在过去的两年中,我一直在使用Selenium。最近,我看到了对页面对象的更多引用。 (我将页面对象称为组织UI自动化代码的一种方式-而不是Selenium API中体现的接口或实现。)与仅使用功能集合相比,使用页面对象的优缺点是什么?请尝试说明优缺点。

#1 楼

优点:


代码库中测试代码和导航代码之间的清晰分隔。

易于理解的测试,例如-

Homepage.testLogin(username, password);



更简洁
selenium.type(username);
selenium.type(password);
selenium.click(submit);
selenium.waitForpageToLoad(waitPeriod);


易于维护,当UI更改时,您需要更改导航代码而不进行测试(提供的应用逻辑仍然相同,只是UI对象/导航发生了变化)

缺点:

我唯一能想到的是,页面对象的初始设计可能需要更多时间但痛苦绝对是值得的

评论


您可以使用函数执行相同的操作,而无需麻烦定义对象,因此我认为这不能回答问题。

–user246
2011年5月14日20:34

Tarun是页面对象是方法还是每个页面对象都有其成员函数?

– Rakesh Prabhakaran
2011年5月16日在1:48

@ user246-Tarun使用的示例为true,但通常情况下为true。 PageObjects确保一次定义一个对象,然后在其他地方重用它。如果在一个对象周围定义了多个方法,则标识该对象的代码部分将分散在整个代码中,这将造成维护的噩梦。

– Suchit Parikh
2011年5月17日在1:19

@Suchit也许这只是我们使用不同术语的问题。当您说“ PageObjects确保定义对象”时,您指的是什么对象?函数和封装逻辑的对象一样工作。如果需要继承或需要封装状态,则有一个使用对象的更强论据。但是,在我看来,大多数PageObjects基本上都是无状态的代理-只是函数的集合。

–user246
2011年5月17日13:43



仅当页面对象模型正确完成时,定义页面对象模型的痛苦才比维护一组功能的痛苦要小。

– dzieciou
2014年6月2日21:39

#2 楼

将函数放入PageObjects而不是拥有一堆静态函数有三个主要优点:


上下文。 LoginPage.clickNext()ItemDetails.clickNext()会立即告诉您查看测试时所处的页面,即使它们是从父类继承的相同方法也是如此。
PageObjectFactory可以自动初始化PageObject的成员变量,因此您不必每次与某事物进行交互时都执行find()。这可以使您的代码保持整洁,但是假设您使用PageObject范例,并且如果这样做,效果最好。
易于维护代码;如果您使用的是Java或.NET,则无论如何都必须将所有内容都放在一个类中,因此与将所有内容都放在同一静态类中相比,按页面将其分成逻辑分组会更容易。正确命名页面类可以使您轻松找到给定页面更改时需要更新的方法。

实际上,PageObjects主要是一种组织代码的方法,而不是太难或太复杂的实现方法。它们没有提供很多性能改进的方法,也没有提供其他您无法做的事情,但是它们使您的代码更整洁,更易于阅读和维护。

评论


为PageObjectFactory +1。注释WebElement允许您将页面元素的completex定位符与对其上的操作分开。

– dzieciou
2014年6月2日21:44

#3 楼

尽管Page Project Model有很多优点,但其中一些优点是:


简单明了的页面类,带有明智的方法名称。方法。像上面一样,这样您就不必记住任何事情。
只需查看方法名称即可对方法的功能有所了解。
使测试更具可读性。与上述selenium命令相比,您需要在selenium脚本中添加所有命令。在页面对象模型中,您需要放置方法名称。根据您对应用程序的理解而创建的方法,因此这些方法的名称更易读和易于理解。
保持干燥。
页面对象模型相信不要重复自己的原理。
测试的良好支持,因为所有内容都存储在一个地方。
易于创建新测试。实际上,可以由不了解自动化工具功能的人员来创建测试。

由于我实际上已经在项目中实现了它,因此肯定存在一些缺陷:
所有定位符都应保存在页面类文件中。
这种抽象导致页面类文件中出现一些混乱。
因此,您需要在页面顶部实现类似关键字驱动的内容对象模型以便充分利用优势。


#4 楼

优点:(OOP)将定义的对象与在方法中实现的对象分离。定义一次,多次使用。如果登录页面元素得到更新,则只需转到您的loginPage Page对象类,然后更新识别元素的方法

缺点:


花时间去构建基础结构(如前所述)
需要足够的编程技能来设计自动化套件(+或-取决于团队的编程技能)


评论


+1表示“易于维护”。我认为这两个缺点仅仅是投资易于维护的测试成本。永远不会有免费的午餐,只是必须确保这项投资带来的投资回报/收益,即维护成本比构建页面对象模型和雇用熟练工程师的成本要低。

– dzieciou
2014年6月2日在21:35



#5 楼

静态函数/单行变量

更容易在屏幕上一次阅读更多内容
更容易维护对cmparison更为可见的命名子类
可以具有全局作用域(通常很糟糕事物)

具有功能的PageObject类

更易于子类化,并使其以更模块化的方式混合到模块中
对类进行了命名和命名

我们用于识别页面元素的PageObject方法进行了许多转换!见下文。
我从中得到的是:

所使用的实际形式(变量,方法,yaml等)变得有些无关紧要。最后,这是我正在编辑的文件。
困难的部分是使用良好的命名和良好的选择器,这些选择器足够具体,而不必过于具体或难以编码,因此请集中精力
愿意重做和重做新数据出现时根据命名创建的任何结构
根据需要决定是使用一个中央文件还是一堆其他文件。我个人发现一个文件最容易维护。
使用变量或yaml文件在每个查找器中一行是一次查看最多选择器并能够将它们分组和命名的最简单方法没有重复和前后矛盾的有组织的时尚


我们的页面对象之旅:
最初,它们是javascript变量,作为文件包含在seleniumIDE中。
然后将其移动到文件中,并在rails应用程序的PageObject类中将其编码为ruby方法(类似于函数)。 />
var footer='div#footer';