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进行了一些移动端的扩展。

上一篇:Jdk1.8中的HashMap实现原理


下一篇:Golang踩坑录 两种方式来读取文件一行所导致的问题