UI自动化测试的Page Object模式
在UI级的自动化测试框架中,当页面样式改变或者页面元素属性改变,那么代码也要随之进行修改,如何做到高效快速的修改代码来适应这些改变呢,这个时候可以引入Page Object模式,也是页面对象设计模式。
什么是Page Object
Page Object模式是一种测试设计模式。简而言之,就是把页面对象和用例进行分离,将页面的元素定位和元素行为封装一个Page类,测试用例调用Page的页面行为操作。
Page Object 的通常做法是，将公共方法、逻辑操作（元素定位、操作步骤）、测试用例（测试业务）、测试数据和测试驱动（执行测试用例）相互分离
可以理解为将测试项目进行如下分层：
- 公共方法层，包括公共方法或基础方法
- 操作逻辑层，主要是将每一个页面或该页面需要测试的某个功能涉及到的元素设计为一个class
- 测试用例层，只需要调用逻辑操作层中对应页面的class即可
- 测试数据层，即测试数据分离，包括配置数据和测试数据，如：登陆账号密码
- 测试驱动层，执行整个测试并生成测试报告
整体思想是：让不同层去做不同类型的事情，让代码结构清晰，增加复用性。
一般分两层或三层（也有四层的）：
两层：对象逻辑层+业务数据层。
三层：对象库层+逻辑层+业务层。
四层：对象库层+逻辑层+业务层+数据层。
不同分层本质差不多
Page Object的优点:
- 1.创建可以跨多个测试用例共享的代码
- 2.减少重复代码的数量
- 3.如果用户界面发生变更后,只需要在一个地方维护即可.
| PO模式 | 当前搞法 | |
|---|---|---|
| 代码量 | 多 两倍以上 | 少 |
| 复杂度 | 较复杂 | 简单明了 |
| UI变化 | 修改简单 | 修改简单 |
上面这个表格可能对比不是很强烈哈
| PO模式 | 普通方式 | |
|---|---|---|
| 代码量 | N x a（a≥2) | N |
| 可阅读性 | 强 | 很差 |
| 维护性 | 强 | 差 |
所以整体来看：
- case 越多使用 PO 模式会使你的代码结构更清晰
- 元素复用越多 PO 模式下维护非常容易
- 逻辑复用越多 PO 模式下维护非常容易（如果逻辑复用多，需要多考虑逻辑层的颗粒度）
- 元素/逻辑/数据复用越多应选择更多层的 PO 模式
当然缺点就是代码量会增加
