对于电商系统前置依赖还算很小的啦，像我们游戏无论是 UI 还是接口自动化，都是数据构造麻烦，占用的整个用例编写时长一半或往上。比如一个球员升级的功能点，往往需要账号达到等级达到 xx，对应功能建筑等级达到 xx 并解锁了升级玩法，需要有满足要求的球员，升级球员所需要的几个材料数量够足。这些数据准备大部分是通过 sql 来重置少量使用接口处理。编写 UI 或接口 case 的同学都羡慕编写性能 case 的同学，相比之下性能 case 最简单。

用这种方式也是为难楼主了 但概率统计，直接调接口就好了呀。通过前端去操作，效率非常低。

下午体验了一波，能花式编写用例，几乎覆盖了 xmind/excel 的优点， 大赞。 无论是用来用例评审还是指定任务执行都不错，但任务系统稍微单一了些，只能用例集下新建任务，无法单任务关联多用例集，没有看板/用户权限差异化... @ 楼主的公司是只拿来做用例编写使用嘛

很好的分享， 我来手动点赞。业务场景的可视化与强大的谈判技巧让我感触颇深

你阅读的很仔细呀，因为帖子中尾部的示例代码是后来补上的，确实和一开始的构思流程图有差异。到了绑定自动化的方法时，可以继续选择动态生成，也可直接绑定指定的方法（通常是 click get_key exists..等） 不过选哪种都没关系嘛，这里主要是介绍这种属性拦截的思路，根据自己项目业务情况灵活使用咯。

查看下帖子尾部的示例

这和楼上的问题相同，都是前置页面/脏界面管理的问题。参考楼上的回复

不会每个 case 都走登录，我这里单独做了一套 case 前置场景自动跳转/异常自动恢复的机制（如何高效地从未知场景跳转至目标场景），本质是对所有业务界面 info 进行建模，生成一颗树，最后转化成查找两个节点的最短路径的问题

不难的 使用多进程，每个子进程都绑定一个设备到 driver 再把 driver 传给需要运行的脚本就好

楼主这个是想自动收集所有元素吗？ 好像没看到命名环节
如果是手动，那定位元素不要使用 airtestIDE 默认给的，在左侧树状图里自己手动 copy 就会简洁很多

看楼主这个 好像并不是减少用例执行时间（case 编写完毕后）。 而是减少或杜绝编写 case 时元素错误问题

官网上对比下 你家游戏引擎是否被 airtest 支持嘛，印象中绝大部分游戏都支持的

如果位置固定或变化有规律，试试固定坐标滑动？

你这么问估计你们 ui 自动化刚起步
你们经理这么做是想节省自动化组需要大量时间了解业务 - 编写用例的时间，直接拿功能组现成的用例转化成自动化 case。
但从人力投入角度来看，我觉得功能组同学写自动化 case 性价比最高。要促成这件事一需要提升功能组代码水平，二需要自动化组把系统全盘设计考虑清楚，通用的东西全部抽离到底层 自动生成模板 case 让整个过程变成做填空题 大幅降低功能组代码门槛

def allure_click(self, **kwargs):
with allure.step('步骤： 点击%s' % self._name):
UIObjectProxy.click(self, **kwargs)

这不就是嘛

针对元素唯一性问题，我这里通常是多片段来约束（一般是三层），如 poco().child().child(), (parent, sibling 等)，仔细找下绝大部分情况还是能找到有差异的 text. 如果最后还是不能确定唯一，那就单独处理吧，自己定义个符号来控制这类情况并在解析元素方法中实现它

恩 是的 airtest 下面的 poco 框架

手游，unity 3d
我们 UI 用例绝大部分是根据功能测试用例来的，各类异常路径也会尽量覆盖。
如果只是覆盖主流程，可能深度在 20-30% 左右吧
我们这里的深度大概到了 70% 上下

我们这样做等于骗过了 IDE，所以它不能智能提示。
目前没有什么好的办法，不过常用的方法也就几个咯，click /exists/swipe/get_text... 还好咯

如果无法识别控件，那就麻烦了。 我这里舍弃了图像识别的， 如果想了解图像识别经验可以问下猫哥咯 他那有做

1.“PO 模式不适合快速项目” -》个人觉得 UI 自动化不太适合快速项目咯
2.“但是自己写的代码自己看不懂就是问题了.这是涉及代码复杂度的问题. ” -》这跟 PO 模式没关系呀，代码复不复杂在于自己项目整体设计和个人风格。在我看来 PO 能让项目结构更清楚，至少 page-case 这部分是这样的
3..“我讨厌再分一级 PO 层.遇到可以公用部分” -》不知道是你那边 case 量比较少，还是 ui 改动确实极少，不然频繁 ui 改动带来的大量元素维护是一个很痛苦耗时的事情啊， po 分层能很大程度提高效率

1. “我们在做测试过程发现: 一直淹没在查找元素问题上. 60% 以上的时间在查找元素” -》我这边 50% 左右的时间是花费在构造业务数据，找元素大概占 20%-30% 吧
2. “如何做数据分离. (就像 robot-framework 哪样).” 这个可能出发点不同吧，我希望组员能先从写业务 case 再慢慢读懂整个系统接触更多代码慢慢提升技术而不是全部都封装成 web 工具/excel/yaml 形式，每天只用做填空题，换一家公司后和普通功能测试没什么差异

poco 有支持 coco 吧 你看看 https://poco-chinese.readthedocs.io/zh_CN/latest/source/doc/integration.html#cocos2dx-lua

有什么问题贴这里嘛 大家可以一起讨论