页面对象模型（POM）是一种用于组织自动化测试代码的架构模式，特别是在用户界面测试中。它建议为应用程序的每个页面逻辑创建单独的类或对象，定义处理元素及其操作的方法。
问题的历史： 以前，自动化测试是“随意”编写的——直接在测试中与元素定位器交互，这导致代码重复和难以维护。引入POM之后，可以将与特定页面相关的所有内容移入单独的类，使自动化测试更易维护。
问题： 在大型项目中，如果没有结构化测试，代码会迅速变得“杂乱无章”。界面的任何更改都需要更新大量测试，这导致维护成本高昂。
解决方案： POM允许集中管理操作和元素，减少重复，简化测试基础设施的扩展。例如，如果需要更改按钮的定位器，只需在一个地方——页面对象中进行修改，而不是在所有测试中。
关键特点：
可以不使用POM模式实现自动化测试吗？
可以，但这种方法会导致代码重复、高昂的维护成本和无法扩展。
每个页面元素都必须放入单独的Page Object吗？
不，Page Object创建用于逻辑页面，包括相关元素和操作，有时对较小的重复块可以使用单独的辅助实体（例如，组件）。
POM解决所有自动化测试的架构问题吗？
不，它有助于结构化与接口的交互逻辑，但不定义测试框架的完整架构，例如数据处理、报告生成和应用状态管理。
测试在未使用POM的情况下编写——所有操作都直接在测试方法中编写。结果，简单地更改一个页面按钮的id需要修改35个测试，其中许多变得不正确，而其他测试则完全无法运行。
优点：
缺点：
在新项目中，根据POM构建了测试：添加页面类，封装与元素的交互，使用继承来处理通用模式。
优点：
缺点：