业务背景

我这是一家手游公司， 前端使用 unity，appium 之类框架的都无法识别 unity 控件，最后得知网易 airtest 下面的 poco 框架可识别 unity 控件。
由于之前没有相关经验靠自己摸爬滚打，走了很多弯路，代码结构/框架也重构了几次（现在还想重构 ）。
在设计之初有过很多构想，觉得应该满足那些要求：

• 颗粒度尽可能小且 case 互不影响
• 可根据不同策略执行不同深度 case 集
• 负载均衡：收集可用测试机根据对应测试机执行快慢分发不同数量 case 任务
• 重复执行
• 失败重试（因业务特殊目前不准备失败重试，因为 case 前置数据准备是通过跑 sql 修改数据，但前端不会及时刷新，需要找到一个刷新点，主流的刷新点是重登， 从当前 case 界面-》跳转游戏主界面-》设置切换账号-》登录界面登录账号-》跳转游戏主界面-》跳转 case 指定界面，这个过程非常耗时，会大幅增加 case 执行时间）
• 让 case 编写者只需要关注业务
• 以最小的改动面对未来需求的变化
• ............... 还实现了很多哈 不一一列举

问题介绍

UI 自动化到底要不要用 Page Object 模式，以及 yaml 数据驱动？ 或者说我这个情况要不要使用 po 模式？

了解到 Page Object 模式很主流，很火。然后使用 yaml 数据驱动，很炫酷，高大上的样子（想立马就应用到项目中）
但任何技术最终还要是服务于业务，是要能解决某些或某类问题
这里以我对 po 模式非常浅显的理解和我当前的做法做了个对比：

单看表格可能看不懂哈，直接贴 python 代码如下：

省去了 case 前置界面准备，前置数据准备

代码内容大概是把一个战术技能从 0 级升级到 10， 并做相关断言

data_0 = [
    ['0', '每有一个进攻战术达到<color=#fca926>10级</color>，\n球队进攻<color=#fca926>+0</color>', '1', '15001', 9],
    ['1', '每有一个进攻战术达到<color=#fca926>10级</color>，\n球队进攻<color=#fca926>+1</color>', '2', '15002', 9],
    ['2', '每有一个进攻战术达到<color=#fca926>10级</color>，\n球队进攻<color=#fca926>+2</color>', '4', '15003', 9],
    ['3', '每有一个进攻战术达到<color=#fca926>10级</color>，\n球队进攻<color=#fca926>+4</color>', '6', '15004', 9],
    ['4', '每有一个进攻战术达到<color=#fca926>10级</color>，\n球队进攻<color=#fca926>+6</color>', '9', '15005', 9],
    ['5', '每有一个进攻战术达到<color=#fca926>10级</color>，\n球队进攻<color=#fca926>+9</color>', '12', '15006', 9],
    ['6', '每有一个进攻战术达到<color=#fca926>10级</color>，\n球队进攻<color=#fca926>+12</color>', '16', '15007', 9],
    ['7', '每有一个进攻战术达到<color=#fca926>10级</color>，\n球队进攻<color=#fca926>+16</color>', '20', '15008', 9],
    ['8', '每有一个进攻战术达到<color=#fca926>10级</color>，\n球队进攻<color=#fca926>+20</color>', '25', '15009', 9],
    ['9', '每有一个进攻战术达到<color=#fca926>10级</color>，\n球队进攻<color=#fca926>+25</color>', '30', '15010', 9],
    ['10', '每有一个进攻战术达到<color=#fca926>10级</color>，\n球队进攻<color=#fca926>+30</color>', '0', '0', 0],
]
@allure.story('战术素养')
@allure.title('升级常规进攻素养0-10级')
@user3ize('level, des, number, style, t_book', data_0)
def test_0(self, mt, level, des, number, style, t_book):
    poco = mt.poco
    poco("Content").child("TacticsStyleItem(Clone)")[0].click()                        #选中常规进攻素养
    assert poco("Content").child("TacticsStyleItem(Clone)")[0].child('GiftType').get_text().split('.')[1] == level
                                                                                       #检查当前进攻素养的等级是否正确
    assert poco("DetailPanel").child("CurrentEffect").child('Desc').get_text() == des  #断言当前进攻素养的文案内容是否正确
    if level != '10':
        poco("UpgradePanel").child("UpgradeBtn").click()                                #点击升级按钮
        poco("Content").child("TacticsStyleItem(Clone)")[0].click()                     #点击跳过动画
        assert mt.sql.select(SQL_1_0+style)[1][0] == t_book, SQL_1_0+style         #查看数据库对应类型道具应该减少一个
        assert poco("CurrentEffect").child('Desc').get_text().split('+')[1].split('<')[0] == number #升级后加成的数值是否正确
    else:
        assert poco("UpgradePanel").child("UpgradeBtn").child("Label").get_text() == "已满级"     #满级时应不能升级

疑惑

这样看来，po 模式会更加繁琐，笨重，好像 po 模式没有什么优势。 请有这方面经验的朋友解惑一下