Page Object 模式很火，UI 自动化测试到底要不要用？怎么用？

本文作者为霍格沃兹测试学院第 9 期学员 zzt

业务背景

我们是一家手游公司，前端使用 Unity。Appium 之类框架的都无法识别 Unity 控件，最后得知网易Airtest 下面的 poco 框架可识别 Unity 控件。

由于之前没有相关经验靠自己摸爬滚打，走了很多弯路，代码结构/框架也重构了几次（现在还想重构😂 ）。在设计之初有过很多构想，觉得应该满足那些要求：
颗粒度尽可能小且case互不影响

可根据不同策略执行不同深度case集

负载均衡：收集可用测试机根据对应测试机执行快慢分发不同数量case任务

重复执行

失败重试 （因业务特殊目前不准备失败重试，因为case前置数据准备是通过跑sql修改数据，但前端不会及时刷新，需要找到一个刷新点，主流的刷新点是重登，从当前case界面-》跳转游戏主界面-》设置切换账号-》登录界面登录账号-》跳转游戏主界面-》跳转case指定界面，这个过程非常耗时，会大幅增加case执行时间）

让case编写者只需要关注业务

以最小的改动面对未来需求的变化

…
还实现了很多，这里不一一列举.

问题来了

了解到 Page Object 模式很主流，很火。然后使用 yaml 数据驱动，很炫酷，高大上的样子（想立马就应用到项目中）。
但 UI 自动化测试到底要不要用 Page Object 模式，以及 yaml 数据驱动？或者说我这个情况要不要使用 PO 模式？

任何技术最终还要是服务于业务，是必须要能解决某些或某类问题的。这里以我对 PO 模式非常浅显的理解和我当前的做法做了个对比：

单看表格可能看不懂哈，直接贴 Python 代码（省去了case前置界面准备，前置数据准备）：

代码内容

代码主要是把一个战术技能从0级升级到10， 并做相关断言。