PO 模式分层管理， case 都在业务层

0、UI 自动化框架：Airtest/Poco
1、产品名：手游
2、UI 自动化的用例覆盖率：这个很难出来精准数值，大概覆盖了 80% 左右的功能，每个功能深度大概 60-70% 左右，还在持续堆 case
3、UI 自动化用例数：1000+ （case 最小颗粒度/互相独立，一般四台机器一起跑，耗时 50min 上下出报告）
4、最近一个月的平均稳定性：一般在 95% 以上（有定制失败重跑 稳定性能到 98% 上下）PS：这里的稳定性是指版本需求变动或版本 BUG 外的 case 未通过数/总 case 数。
5、目标稳定性：感觉保持现状就不错

有两个方向咯
一：默认绑定一些常规方法
二：就是你这种，通过自带参数来指定绑定方法，不过这样代码量多了很多

my_loc.click 不需要挡截了呀
挡截 my_loc 解析 webelement 后应返回一个对应元素的可操作对象，而这个对象是自带 click get_text set_text 之类的方法

你去了解下getattribute的使用吧
访问类里面的任何属性都会先调用它，我们通过重写getattribute来达到挡截的效果

target_page = getattr(page, item)

page：为目标 page.py 文件， item 为目标文件下的具体类名
然后通过 getattr 方法拿到目标类
最后 target_page(self._driver) 来实例化具体类的对象

你哪里不清楚，给你回复吧

现在这个项目有一千 +case 了，优化之后的 po 模式用起来很舒服

老模块稳定性在 95% 以上，加上自定义的重跑机制，感觉还不错。新模块还在调优中，每个模块覆盖深度在 70% 左右（剩余部分交给人工）

1.我这里没有把 page 设计成单例，这里看你框架怎么设计的了，各有不同
2.我这里的界面非常多，考虑到智能跳转找最短路径，异常时尝试切换账号或重启 app 等容错机制等设定，我把界面跳转抽离出来了。把各个界面看成一个节点，以 homepage 为根结点，形成一颗树。最终不同界面跳转就变成找一颗树中两个节点的最短路径了

这个自己去解析，你是 web 就解析成 web appium 就是解析成 appium 的可操作对象，我这里是使用的 poco 控件识别框架，所有解析出来的就是 poco 对象

代码已补上

好，明天把代码贴上去

敲错啦，应该是 target_page 。已经修改

解包的意思，可以粗劣的认为是去掉 “（）”

恩 你这是两层 PO 了

不是哦 这里是参考的这个思路 很棒

用例数量：

哈哈， 用例数量其实还挺多的，游戏业务较复杂，大多时间花费在前置数据准备，目前一共有三四十个模块， 一个模块大概有八九十条左右（模块大小数量也不一定，在 case 稳定性允许的前提下尽可能覆盖更广更深，所以各种异常情况也会覆盖）。已写完十几个模块，五台手机一起跑大概一小时左右跑完，预计所有 case 写完后 8 台机器一跑 两三小时的样子

设计问题

当前设计暂时还没发现什么大问题，相反现在的 case 如果有异常可以直接 copy 代码到 airtest IDE 里面快速调试很方便。

协作

按照我的计划，可能两人一组负责前期 case 的堆积（迭代了好几年的项目），后期留下一人维护

感觉图片识别 准确率 和效率 都是瓶颈 另外 case 多了后 海量图片的储存都很担忧 ， 所有没有使用 airtest 下面的图片识别 只用了 poco

恩 以务实为主， 但想把框架设计的更好，就还是需要借助外界 行业的力量 碰到好的思路 方法 就想看能不能把它融入到项目中

多谢 ，回答的详细，但感觉还是没 get 到点哈。可能还需要更多坑的洗礼才会明白

一机多控是空间识别， 我这里前端是 unity 的，貌似识别不了。还有其他办法吗