robotFrameWork APPIUM實現對安卓APK的自動化測試

標籤：json對象   命令   語言   轉換   blog   返回   無法   發送   center   

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進行了一些移動端的擴充。

Robotframework自動化測試案例樣本：

 

 

robotFrameWork APPIUM實現對安卓APK的自動化測試