RF|RobotFrameWork+APPIUM实现对安卓APK的自动化测试----第二篇【原理】

接着上一篇,我们开始聊聊APPIUM的框架和运行模式。废话不多说直接上图。
RF|RobotFrameWork+APPIUM实现对安卓APK的自动化测试----第二篇【原理】
文章图片


【RF|RobotFrameWork+APPIUM实现对安卓APK的自动化测试----第二篇【原理】】RF|RobotFrameWork+APPIUM实现对安卓APK的自动化测试----第二篇【原理】
文章图片




1.首先自动化脚本通过RobotFrameWork将命令传递给Appium的客户端;
2.然后【Appium的客户端】将接受到的命令发送给【Appium的服务端】;
3.【Appium服务端】将脚本中的代码命令转换成手机模拟器所能识别的命令通过【ADB】发送给【模拟器】,从而控制被测试的应用软件。
然后摘抄了一段源自网络的Appium的理论知识:
Appium原理小结

Api接口调用selenium的接口,android底层用android的instrumentation(API2.3+ 通过绑定另外一个独立的selendroid项目来实现的)、uiautomator接口(API4.2+),ios底层用ios的uiautomation接口。
Client/ServerArchitecture
Appium server是用node.js写的,安装node.js可以直接用npm命令或dmg,server端功能:监听一个端口,接收client发送来的command,翻译这些命令,把这些command转成移动设备可以理解的形式发送给移动设备,然后移动设备执行完command后把执行结果返回给appium server,appium再把执行结果返回给client。
Client其实就是发起command的设备,一般来说就是执行代码的机器,执行appium测试代码的机器,可以把client理解成代码,这些代码可以是java、python、ruby、js,只要实现了webdriver标准协议就可以。
跨语言:只要支持selenium webdriver api和这种语言相关的client libraries就可以。Server放在任意机器上,哪怕是云服务器都可以(appium和webdriver天生适合云测试)。
Session
session就是一个会话,在webdriver/appium,你的所有工作永远都是在session start后才可以进行的。一般来说,通过POST /session这个URL,然后传入Desired Capabilities就可以开启session了。
开启session后,会返回一个全局唯一的sessionid,以后几乎所有的请求都必须带上这个session id,因为这个seesion id代表了你所打开的浏览器或者是移动设备的模拟器。
进一步思考一下,由于session id是全局唯一,那么在同一台机器上启动多个session就变成了可能,这也就是selenium gird所依赖的具体理论根据。
Desired Capabilities
Desired Capabilities携带了一些配置信息。从本质上讲,这个东东是key-value形式的对象。你可以理解成是java里的map,python里的字典,ruby里的hash以及js里的json对象。实际上Desired Capabilities在传输时就是json对象。
Desired Capabilities最重要的作用是告诉server本次测试的上下文。这次是要进行浏览器测试还是移动端测试?如果是移动端测试的话是测试android还是ios,如果测试android的话那么我们要测试哪个app? server的这些疑问Desired Capabilities都必须给予解答,否则server不买账,自然就无法完成移动app或者是浏览器的启动。
Appium Clients
原生的webdriver api是为web端设计的,appium官方提供了一套appium client,为不同的语言的开发者可以测试自己的app,测试的时候,一般要使用这些client库去替换原生的webdriver库。算是client对原生webdriver进行了一些移动端的扩展。


好啦,第二篇就写这么多吧,重头戏还在后面了,第三篇我将给大家展示这个框架是怎么使用的,也就是如何实现Appium的自动化测试。最后小碎嘴一下,天气好冷啊~大家注意多保暖。



    推荐阅读