我目前正计划为我们的中型项目（50个开发人员，10个qa）制定一个Selenium测试策略。我想过使用PageObject模式来创建一个很好的抽象和许多可重用的组件。
然而，另一位同事认为，由于测试的性质，它们应该尽可能简单，并且由于它们易腐烂的性质而在整个地方进行复制粘贴。
我们都非常擅长OOP和清洁代码，我们知道PageObject模式是要走的路，但是，我无法预见它对于一个大项目的表现如何（假设20000次硒测试）
我使用PageObject的论据：
他关于复制粘贴驱动测试的论点：
问题是：鉴于项目的规模很大，采用什么方法是可行的？
答案 0 :(得分：1)
在规模上，两者的组合最好。在您测试的任何页面上只会有有限数量的元素。这些元素都将具有定位器，并将以某种组合方式用于实现您的工作流程。拥有定义这些元素及其定位器的页面对象将极大地帮助维护测试，因为它可以避免元素的重复，并且可以更快地向选择器传播小的更改。
然而，拥有大部分内部页面对象项目的逻辑的所有/大部分逻辑很快就会变得非常复杂，并且在此之后人们无论如何都会最终复制内容。将逻辑留在测试中而不是页面对象可能会更简单，即使重复是开销。这种方法可以提供页面对象的一些好处，而不会产生很多复杂性和开销，听起来你的团队可能没有足够的能力来处理。
如果有的话，以这种方式工作对于你的质量保证比在没有任何页面反对的情况下工作更简单。一旦页面的包装器被写入（其中许多可以预先完成），他们将不必执行诸如选择选择器和遵循元素的命名约定等事情。
显然，理想的解决方案是让你的QA能够轻松地理解（希望）经过深思熟虑且一致的抽象模式，但是如果这不是一个选择那么公平。
之前我曾经使用过我的页面对象和我的步骤定义之间的层（当时我使用的是黄瓜），这个层被称为业务逻辑层或类似的东西。这一层提供的方法抽象出一些更常见的用户活动（例如登录，导航到页面），提供一种方法来避免最常用活动的代码重复，而不试图从测试中抽象出所有其他代码