Senenity/JS框架，该框架提倡使用“屏幕播放”模式，该框架被建议作为Page Objects的更好替代。 /> #1 楼
在英国Selenium会议上，有一个关于“屏幕播放”模式的演示，请参阅“屏幕播放模式”-一种“页面对象| SOLID”替代品。安东尼·马卡诺（Antony Marcano）我们拥有庞大的技术生态系统（60多个应用程序），所有内容都基于Page Object模型。我们尝试了“屏幕播放”模式，并从中学习了很多东西，以及它在何处变得越来越不有效。
恕我直言，这只是在需要时应用的另一种工具。页面对象模型之所以有效，是因为它非常灵活，并且如果在大型SUT上使用，则效果最好。将屏幕播放模式少量地应用到存在明确定义的需求和用例的稳定或较小的系统上，效果最佳。
问题不是哪个模式更好？页面对象模型或屏幕播放模型都是工具。问题如下：哪个对测试您的产品更好？您是否有一个支持屏幕播放模式需求作为输入的开发环境？ （即明确的要求，用例等），您是从头开始实施自动化吗？还是您在追赶和/或迁移？这些问题本身不会消除一个或另一个模式。我们不在这里查看OR语句，它是具有权重和余额的AND语句。您想做出明智的决定，并牢记6个月的目标/计划。
在我们的项目中，我们将Screen Play应用于一个复杂的项目，然后是一个简单的项目。从简单开始；有很多东西要学习，要遵循SOLID原则，要练习以保持结构纯净并经常重构。
上面提供的参考文献也是一个很好的起点。
#2 楼
关键区别在于，剧本模式组织页面对象剧本模式试图解决开发大多数UI接受测试自动化（包括何时引入新功能）时最终会遇到并解决的问题，挑战和解决方案。 Page Object模式，然后使用它面临挑战，因为简单地需要组织和安排代码和数据，这往往导致需要编程语言和框架。我已经看到它叫做“使用SOLID设计原则对页面对象进行无情的重构会导致什么”
剧本模式也称为“旅程设计模式”，是SOLID设计原则在自动验收测试中的应用。它使用以参与者为中心的模型进行测试，测试的重点是用户如何与应用程序交互以实现目标，而不是在页面对象模型中如何使用“页面”。
在剧本模式中，每个参与者有能力和问题，例如查询宁静的Web服务。参与者还可以执行诸如将项目添加到网页上的列表之类的任务。为了实现这些任务，他们执行诸如单击或键入之类的操作。参与者还可以询问有关应用程序状态的问题，例如页面上某个字段的内容或通过查询Web服务。
我亲眼看到引入了Page Object模式，最初不到30个页面定位器。随着时间的流逝，（单个文件）标识符和操作数增加到近500行。因为它们“都在一个地方”，这意味着随着时间的流逝，坏事发生了。具体来说：
文件中有大约6个重复项
我们有大约12个未使用的页面对象用于已删除测试的测试，这些对象留下了孤立的页面对象
我们不立即知道是否更改了Page Object会破坏其他测试
我们不知道它是否已共享并用于测试之外的测试中
评论
Iv's看到“开始相当简单，然后随着时间的推移...”连续3个组织。我已将其添加到“体验”寄存器中。东西，你必须学习艰苦的道路，否则，你会信任一个好的老师。
–迈克尔·杜兰特（Michael Durrant）
17年5月29日在14:15
我能想象。我的建议是利用经验来改进您的框架，并尝试在任何地方使用它，并对使用该框架的人员暗示严格的编码准则。
– FDM
17年5月29日下午14:19
是的实际上，我开始发现对测试进行测试（认为是linters）会更有效，以确保我们的Page Objects中没有重复项或孤立项。在PR期间进行手动眼球检查尚未解决，根据我的经验证明这种方法不可靠。许多人为因素和组织因素在起作用。自动化一切！ ;）
–迈克尔·杜兰特（Michael Durrant）
17年5月29日在14:33
@MichaelDurrant感谢您的回答，学到了一些新知识！绝对是针对测试的测试！我一直在使用github.com/alecxe/eslint-plugin-protractor朝这个方向发展-我添加了一些棉绒规则，用于检查重复的定位器，无效的定位器，在定位器内部使用引导程序或特定于角度的属性等-在我们内部的Protractor / JS自动化项目中工作得很好，有助于尽早发现很多问题。顺便说一句，还有一个非常新鲜的项目：bitbucket.org/leon_manukyan/trit，旨在检查测试的质量。
– alecxe♦
17年5月29日在16:05
@alexce-哦，多么甜蜜！我还要感谢您发布问题和设计模式，并感谢您发表最新评论。我不知道所有这些东西（我的答案直接来自今天的研究！），除了我在工作场所与骗子和孤儿一起经历的经历之外，因此我从发布这个问题的过程中学到了很多东西！
–迈克尔·杜兰特（Michael Durrant）
17年5月29日在17:56
#3 楼
预先免责声明：我不同意以下引用的内容。我相信，体面的POM框架可以导致非常可读和可维护的测试。阅读此页后，意图很清楚。根据源代码：
尽管Page Objects减少了代码重复并鼓励了在单个项目和单个测试套件中进行跨测试的重用，但
设计仍不足如果我们需要跨多个项目和团队启用代码重用。当然，这会影响可伸缩性。
SPP定义了常规任务，能力和动作；因为它们未链接到特定页面，所以它们可以更容易地在项目中重复使用。如果您将常规操作（例如登录）作为单独的程序包提供，所有项目都可以重用，则也可以使用POM轻松完成。
此外，每个页面的事实对象与Protractor API紧密耦合：元素和by-特定于浏览器的全局函数
实例-使得无法按原样使用此设计进行
多浏览器测试（聊天系统，工作流系统，多人游戏等）。
Actor.named('James').whoCan(BrowseTheWeb.using(protractor.browser));
通过缓冲使用WebDriver作为一项功能（请参见代码），它们的框架不仅严格地与WebDriver技术耦合。其他功能可能会允许更广泛的测试变化（游戏，聊天系统等）。
更不用说了，即使从原始测试脚本中提取了Page对象之后，在Cucumber步骤中还剩下许多低级的Protractor / WebDriver API调用。它们很重要，因为它们涉及管理浏览器窗口和
与Cucumber回调同步WebDriver控制流，但是
也使实现的业务逻辑模糊。
/>
同样，SPP模式应该可以更好地将业务逻辑与技术实现分离。但是，在我的框架中，我的测试方法中几乎有零个技术调用。该框架掩盖了所有复杂性。
Page对象还引入了一个更细微的问题。顾名思义，“页面对象”是在用户界面级别上根据用户操作的字段，按钮和链接来进行推理的。这
也会影响您对应用程序的思考方式。 Page Objects不会使您主要关注用户需要使用
应用程序做什么，而是使您专注于用户如何与各个页面进行交互。结果，测试变得紧密地耦合到用户界面的结构，从而使它们更脆弱，并且更容易受到UI更改的影响。 >作者在这里建议，使用SPP与使用POM相比，您对测试的看法会有所不同，并且前面提到的广义任务和问题在UI更改时更为健壮，因为它们与UI动作的耦合并不严格。
由于Page Object具有两个不同的概念，所以有两个原因可能需要更改它。页面结构可能已更改，或者测试可能需要描述与该页面的新用户交互。在这两种情况下，对page
对象的故意或意外更改都可能会对使用它的现有测试产生负面影响。给定页面对象描述的交互和页面元素越多，出现问题的可能性就越高。
再次，作者建议，由于SPP，更改将减少影响。但是，UI的更改需要更改Task / Question，这也可能会影响正在使用的每个测试吗？！
#4 楼
我担任质量检查工程师已有7年了，发现使用PageObject框架本身会产生很多重复的代码。例如，如果您的应用程序有一个登录页面和一个案例创建页面，那么整个套件中的每个测试案例都将包含执行以下操作的代码。登录到应用程序
单击“创建案例”按钮
进入数据
单击保存按钮
这是应用程序中每个测试用例中至少存在4行重复代码。现在，您可以通过创建一个名为LoginAndCreateCase（）的帮助程序方法来解决此问题，但是如果您遵循传统的页面对象模型，则不清楚应在何处放置此新方法。将与执行特定任务相关的代码与该代码分开，以直接与应用程序UI进行交互。用户可以在您的应用程序上执行的高级操作的这些列表是Tasks。
如果您从事Selenium测试用例足够长的时间，很可能您已经不知道这样做了。每次在页面对象中创建一个与多个元素交互的方法时，都可以按照编剧模式将代码转换为Task。
评论
我希望有人能详细回答您的问题，但是我认为我会坚持使用非常易读的测试来制作我的超卓Selenium框架。视频给人留下了深刻的印象。