背景
UI自动化是提高测试效率不可少的手段。闲鱼UI自动化之前的情况是脚本维护成本较高，因此减少脚本投入的成本作为提高自动化效率的第一步。
设计思路
1、monkey大家都了解，毫无顺序的随机乱点，可以用来测app的稳定性，如果能记录monkey点击的元素，那就相当于有了自动化脚本里面的操作步骤
2、有了操作步骤后，我们还需要预期结果才能算一条完整的用例，如果能把点击后，界面的元素记录下来，我们就可以作为预期结果来使用
3、然并卵，这样的脚本根本没用，范围不可控，操作路径又太长，没有mock服务端数据脚本根本跑不起来
4、改进策略，脚本按页面的维度来设计，只针对当前页面点击，跳出去后返回到当前页面继续点击下一个元素
具体实现
01 遍历实现 获取页面元素 1、页面元素获取，使用appium自带方法getpagesource获取 2、 获取界面元素的同时需要获取页面名称，作为唯一标识，Android端能获取activity，ios只能采用hook方式拼接页面名称 3、将页面元素+页面名称记录页面操作
1、页面判断，不在当前页面，或者appcrash等异常，重启app回到该页面，或者back会页面2、读取元素包括，id，name，bounds，封装使用id，xpath点击方式，找不到id，就用xpath点击，保底方法3、过滤不可点击的元素，能区分出来不可点击的元素（本地有记录，但是不对它进行点击）4、元素属性文件解析，直接生成可点击的属性，如id，xpath等5、页面元素点击完后，判断是否要滑动屏幕从新加载元素，页面保持不变
记录操作步骤
1、获取到的页面元素是xml格式的，本地不做转换，保存在本地时就保留xml格式，以元素名称命令2、调用手机截屏操作，截图保存本地，以点击元素命名3、保留一个文件一直记录操作步骤，从遍历开始到结束一直记录4、缓存记录已点击的元素，防止重复点击
异常处理
1、app异常2、跳出app3、手机断开，服务断开
目前开源的框架appcrawler已支持这些功能，只需要针对操作步骤解析生成脚本就行，如果有资源可以自己重新做一套遍历框架。
脚本按页面划分
1、如果按业务划分脚本，脚本操作步骤会很长，没有mock数据支持，脚本成功率很低
2、记录 页面名称-页面可点击元素--点击后页面元素（或者页面截图，可以用图片识别能力来做结果比对）
3、细分按模块，每个模块脚本归为一类，目前我采用统一标识moduleName值，1代码模块1，2代表模块2，如果脚本更新，只需要把模块对应的moduleName值变更下（每次脚本更新，之前的脚本保留，新的脚本改下模块值就可以）
脚本存入数据库
1、数据存入mongdb，对应关系表如下
执行框架
基于appium框架，完善数据驱动的自动化执行框架
封装获取设备的方法
1、获取本地连接的设备，设备号，带入appium启动app 2、带入设备号，带入appium启动app
数据库脚本读取
1、mongdb链接，读取
封装case执行类
1、 数据驱动执行，指定casename，预期结果，操作步骤，截图等 2、 封装连接数据库方法，获取数据库页面元素，存入数组，读取数组数据作为脚本，每一个元素作为一个脚本执行，对应的元素执行失败，不影响其它元素执行 3、统一的去除弹框，针对app登录方法
报告生成
1、报告展示（成功脚本，失败脚本，操作步骤截图，手机日志）
效果
目前采用遍历的方式，我们脚本从原有的120个增加到247个，通过率提高到98%左右，覆盖11个主干页面，每次版本，纯手工更新脚本需要半天时间，现在1小时内可以完成更新，目前发现有效问题15个。
畅想
通过遍历生成脚本，使用成本不高，每次在新版本发布后，可以针对对修改过的页面进行遍历，收集更新脚本，目前最大的工作量是脚本需要筛选一次，将部分动态变化的脚本去掉，运行更加稳定。每次版本更新发布，自动遍历修改过的页面，自动更新脚本，零成本脚本生成到运行出结果。
你可能还喜欢
已开源|2亿用户背后的Flutter应用框架Fish Redux
老代码多=过度耦合=if else？阿里工程师这么捋直老代码
