在执行脚本前,需确定被测终端是否可以与Appium server进行通讯,验证被测app是否能被调起,Appium desktop提供的会话检查器可以满足此需求。Appium desktop会话管理器提供了一个编辑器可以生成desired_caps。SoloPi提供的converter转换后该变量需要根据实际重新赋值,参数包含platformName,platformVersion,deviceName,appPackag,appActivity,automationName等,具体如下
1、deviceName可以通过命令adb devices获取。
2、appPackag、appActivity获取前,测试手机连接电脑,启动被测APP,执行以下命令:
adb shell dumpsys activity |find "mFocusedActivity"(注:android 7.0以下)或adb shell dumpsys window w|findstr \/|findstr name=(注:android 7.0及以上)。执行后获得appPackage 和 appActivity ,其中appPackage = com.android.bankabc,
appActivity=com.alipay.mobile.quinox.LauncherActivity。
需要注意的是,对于有启动页的app来说,appActivity需要设置启动页的值,也就是说在启动页打开后立即使用adb shell命令。目前Appium 1.51.1和安卓10使用uiautomator2有兼容性问题,automationName使用uiautomator1。启动Appium desktop打开会话管理器,将上述值填入,编辑器自动生成JSON格式的字符串,该JSON串需要赋值给desired_caps变量,如下图所示,会话管理器启动后,如显示Appium编辑窗口,即证明连接成功。
SoloPi Converter将导出的JSON文件转换为Appium脚本,转换后的代码需要简单修改即可执行,需要修改的内容如下。
SoloPi转为的Appium脚本缺少关键参数,首先将上文中的JSON赋值给desired_caps,定义remote server,测试用的一部安卓10系统的手机存在兼容问题,这里指定automationName为uiautomator1。
此段代码由转换工具自动生成,获得的SCREEN可供测试人员后续使用,如无需要可将该段代码注释以避免编译失败。通过使get_screenshot_as_file获取设备屏幕截图后得到其width, height值,存入SCREEN变量中。这里脚本的临时存储路径默认为“/tmp/xxx.png”,修改为本地实际路径即可。
① 在原代码中使用tag_name定位元素,该函数是通过H5的tag标签查找,测试过程中转换时选择的是classname,需要修改。此处生成的代码首先获取app当前节点类型的rect属性(该属性获取元素的大小和维度,这里没直接使用返回屏幕大小的相关函数,可能为了考虑app在窗口模式运行/或是有底部bar的情况),为后续屏幕滑动的相关参数提供基础。
② 下图中自定义函数swipe将Appium框架的滑屏函数swipe进行封装,Appium框架函数swipe的参数包括startx、starty、endx、endy,duration,其中startx,starty,endx,endy需要输入屏幕的像素坐标。SoloPi原始脚本中记录的起始和终止位置的坐标偏移区间为[0,1](该值表示位置相对屏幕中心点的偏移量,默认屏幕左上角为(0,0)、右下角为(1,1))。
在原始代码中,结束滑动的坐标值出现了负数,手动将其改为正确的值,这里最好手工debug获得满意的位置。
自定义swipe方法将参数传送给了load_x_y加工成屏幕像素坐标,将2组偏移值用load_x_y处理,得到滑动的实际像素坐标值(fx,fy)和(tx,ty)。
注:在load_x_y中,rect.left和rect.top也是转换工具自动生成的,从步骤①返回的字典中并无此项,要删除。在索引width、height值时,也要改为字典的取值方式。此外,swipe中的driver参数也要删除。
③修改具体执行步骤,从Appium 1.5开始已经移除对by_name的支持。
assert driver.find_element_by_android_uiautomator('text(\"尊敬的用户,您好\")').text == "尊敬的用户,您好"
执行过程可以通过写日志的方式来记录,但对于移动端判断错误具体发生的情况来说,并不是最优。对每一步骤执行后进行截图保存,更有利于测试人员定位问题原因。执行过程中,通过增加一个截图函数放在每一步的后面。测试结束后,截图即可自动生成在文件夹中。
使用jenkins之前,需要先在远程机器上使用PyCharm执行,验证客户端与
服务器端的联通性,然后启动jenkins,通过建一个空项目,并为测试用例的目录建立一个环境变量,便于后续修改。然后输入编译命令,保存该项目后编译,结果执行成功。
需要注意的是,脚本中截图路径要改为jenkins服务器的路径,而非Appium server服务器上的路径,这取决于jenkins是否和Appium server部署在一起。
上述的操作中,只使用了1台android设备,下面介绍多台设备执行的方法。首先验证和服务器的联通性,修改desired_caps,使用2台安卓设备,分别为安卓7.0和10.0,首先使用会话编辑器做联通性验证。
使用命令查看2台设备已经连接到Appium server后,启动2个Appium server,每个server与其中一台手机通讯,如果4台手机,需要启动4个Appium server。启动2个Appium时,要对第二个Appium设置独立的端口。服务器正常启动后,执行脚本中,用例主流程定义在run方法里,run方法包含3个参数,url和desired_caps是启动会话必须的参数,picloc是指定截图生成的位置。
通常编写多线程或者多进程多做使用threading和multiprocess来实现,2种方法,如图所示:
上述代码执行后,实际是按CPU时间分片来执行的,如果代码逻辑很短,或执行很快,就会立即得到结果,如果代码执行效率很慢,最后的结果实际上是在串行操作。上述代码中,MEIZU和honorV20在实际执行过程中,MEIZU会先执行一遍,然后honorV20才会执行,循环反复。
因此,这里使用concurrent.futures模块下的ProcessPoolExecutor进程池,该方法可以利用多核cpu的优势,让脚本并行执行。Submit将实例提交到进程池中,如果CPU有空闲核心,就会调度进程执行。
主函数如下,这里需要注意的是,当多台设备并行执行的时候,需要在 desired_caps中指定参数udid,通过adb devices获取,newCommandTimeout指服务器新获得命令的超时时间:
执行后,可以看到进程完成不是“串行”执行的,最后的执行结果,两台机器可以同步一起执行,并将截图保存在各自的文价夹中。
本文主要从实践操作的角度,以手机银行界面测试为例,比较详细地描述了基于SoloPi执行过程录制转为Appium脚本的过程,并对需要使用的工具和环境、参数等配置进行了说明。通过将Appium脚本集成式jenkins,实现了脚本的自动化部署及自动化执行和结果存储,并描述了单机执行和多机执行的实践过程。
手机银行测试的方式方法需要在实践中不断探索,优秀的互联网测试前沿技术和工具,对商业银行的引领和借鉴意义正在不断加强,希望本文的测试实践能够对移动端APP界面级测试提供有益借鉴,促进测试领域不断开拓新思路,新境界。
成都创新互联公司长期为近1000家客户提供的网站建设服务,团队从业经验10年,关注不同地域、不同群体,并针对不同对象提供差异化的产品和服务;打造开放共赢平台,与合作伙伴共同营造健康的互联网生态环境。为金寨企业提供专业的成都网站制作、成都网站设计、外贸营销网站建设,金寨网站改版等技术服务。拥有10多年丰富建站经验和众多成功案例,为您定制开发。
加我VX:17324089390 回复关键词“测试”领取限量软件测试学习资料哦~~
当前标题:实战演练:10分钟玩转Appium脚本转换+自动化测试实例
URL链接:
http://6mz.cn/article/jiepgc.html