我应该使用PageObject模式，还是应该在Selenium中复制粘贴选择器和逐步操作？

我目前正在为我们的中大型项目50个开发人员，10个qa计划一个硒测试策略。我考虑使用PageObject模式创建一个很好的抽象和许多可重用的组件

然而，另一位同事认为，由于测试的性质，它们应该尽可能简单，并且由于其易腐性，应该到处粘贴副本

我们都非常擅长OOP和干净的代码，我们知道PageObject模式是一条路要走，但是，我无法预见它在一个大项目中的表现，比如说20000个selenium测试

我对使用PageObject的看法：

在产品抽象之后 PageObject是必需的，这样就不会导致可维护的混乱 轻松响应产品中的广泛变化 他对复制粘贴驱动测试的观点：

PageObject至少需要中等水平的编程技能和概念，而我们的测试主要由QA工程师编写，开发经验有限 测试是易腐的。它们的生命周期非常短 一个抽象会引入复杂性，并且在20000个测试的级别上很难维护 抽象可能会偏离用户的实际行为 任何想编写测试（主要是QA）的人都必须理解抽象，而不仅仅是使用基本的selenium命令。此外，selenium测试代码库可能会自行成为一个项目，您甚至可能希望对其进行单元测试：

---

问题是：考虑到项目的规模，什么方法是可行的？

在规模上，两者的结合是最好的。您正在测试的任何页面上的元素数量都是有限的。这些元素都将具有定位器，并将以某种组合方式用于实现您的工作流。拥有定义这些元素及其定位器的页面对象将极大地帮助您高效地维护测试，因为它将避免元素的重复，并使向选择器传播小的更改更快

然而，在页面对象中拥有一个如此庞大的项目的所有/大部分逻辑很快就会变得非常复杂，维护起来会非常困难，而之后人们无论如何都会复制东西。在测试中保留逻辑而不是页面对象可能会更简单，即使复制是一种开销。这种方法可以提供页面对象的一些好处，而不会带来很多复杂度和开销，听起来您的团队可能无法很好地处理这些问题

如果有什么不同的话，那么以这种方式工作对于您的QA来说将比没有任何页面反对的工作更简单。一旦为一个页面编写了一个包装器，其中很多可以提前完成，他们就不必做选择符和遵循元素命名约定等事情

显然，理想的解决方案是让您的QA能够轻松地理解一个经过深思熟虑且一致的抽象模式，该模式将位于此之上，但如果这不是一个选项，那么就足够公平了

---

我以前在页面对象和步骤定义之间使用过一个层，当时我正在使用cucumber，这个层称为业务逻辑层或类似的层。这一层提供了一些方法，这些方法抽象出一些更常见的用户活动，例如登录、导航到页面，提供了一种避免最常用活动的代码重复的方法，而无需尝试从测试中抽象出所有其他代码。

为什么生命周期很短？为什么不让他们检查在添加新功能时没有任何损坏？你的同事是绝对正确的..当项目很大..然后PageObjects不适合自动化..最后它变成了许多维护代码..随意..而我建议使用混合框架