内容简介:背景设计思路
背景
UI自动化是提高测试效率不可少的手段。 闲鱼UI自动化之前的情况是脚本维护成本较高,因此减少脚本投入的成本作为提高自动化效率的第一步。
设计思路
1、monkey大家都了解,毫无顺序的随机乱点,可以用来测app的稳定性,如果能记录monkey点击的元素,那就相当于有了自动化脚本里面的操作步骤
2、有了操作步骤后,我们还需要预期结果才能算一条完整的用例,如果能把点击后,界面的元素记录下来,我们就可以作为预期结果来使用
3、然并卵,这样的脚本根本没用,范围不可控,操作路径又太长,没有mock服务端数据脚本根本跑不起来
4、改进策略,脚本按页面的维度来设计,只针对当前页面点击,跳出去后返回到当前页面继续点击下一个元素
具体实现
0 1
遍历实现
获取页面元素
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、跳出app
3、手机断开,服务断开
目前开源的框架appcrawler已支持这些功能,只需要针对操作步骤解析生成脚本就行,如果有资源可以自己重新做一套遍历框架。
0 2
脚本处理&归类
脚本按页面划分
1、如果按业务划分脚本,脚本操作步骤会很长,没有mock数据支持,脚本成功率很低
2、记录 页面名称-页面可点击元素--点击后页面元素(或者页面截图,可以用图片识别能力来做结果比对)
3、细分按模块,每个模块脚本归为一类,目前我采用统一标识moduleName值,1代码模块1,2代表模块2,如果脚本更新,只需要把模块对应的moduleName值变更下(每次脚本更新,之前的脚本保留,新的脚本改下模块值就可以)
脚本存入数据库
1、数据存入mongdb,对应关系表如下
0 3
脚本执行&报告生成
执行框架
基于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?阿里工程师这么捋直老代码
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 案例分析丨成本降低 20%、流程缩短 10%,希捷如何让智能制造从自动化迈向智能化
- 降低模块间耦合
- 谈谈业务容器化 ———— 降低接入成本
- 如何降低程式碼複雜度 ?
- RDS性能降低 - 复盘 - Honeycomb
- 是什么降低了你的velocity?
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Test Driven Development
Kent Beck / Addison-Wesley Professional / 2002-11-18 / USD 49.99
Quite simply, test-driven development is meant to eliminate fear in application development. While some fear is healthy (often viewed as a conscience that tells programmers to "be careful!"), the auth......一起来看看 《Test Driven Development》 这本书的介绍吧!