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

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

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

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

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

查看下帖子尾部的示例

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

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

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

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