建站
咨詢
售后
建站咨詢
新聞中心
之前寫過一篇文章，提到了一些分布式自動(dòng)化測試和容器化技術(shù)結(jié)合的架構(gòu)設(shè)想。但是目前來說，分布式運(yùn)行并不是難點(diǎn)，亟需解決的問題是針對特殊平臺(tái)和復(fù)雜場景下的測試，例如復(fù)雜業(yè)務(wù)場景下iOS平臺(tái)的自動(dòng)化測試。
為饒陽等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及饒陽網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)、饒陽網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！
移動(dòng)應(yīng)用特點(diǎn)是簡單易用和UI簡潔，以便用戶在移動(dòng)端完成一件事的路徑盡可能短。所以一般情況下，我們遇到的iOS APP場景相對于Web應(yīng)用要簡單一些。所以一般情況下iOS自動(dòng)化測試并不會(huì)遇見復(fù)雜場景，測試反饋時(shí)間短，效率相對較高。對運(yùn)行環(huán)境來說，只需要相應(yīng)版本macOS系統(tǒng)以及Xcode環(huán)境即可。
但是，對于大型企業(yè)的移動(dòng)應(yīng)用，例如電商平臺(tái)、共享出行平臺(tái)等，牽扯到的主要幾個(gè)問題：
1. 大規(guī)模的測試用例導(dǎo)致測試反饋時(shí)間太長
說到這個(gè)問題，就要說到現(xiàn)在主流的移動(dòng)端自動(dòng)化測試框架Appium和Calabash。我所經(jīng)歷過的大部分項(xiàng)目，無外乎使用其一。
但在Xcode 7之后，iOS Simulator變得越來越慢(做iOS的同學(xué)們應(yīng)該都有體會(huì))，更不幸的是，在iOS 10、Xcode 8之后，Apple棄用了UIAutomation，導(dǎo)致大量高效、常用的API無法使用。
并且迄今為止，Appium沒有針對iOS 10平臺(tái)發(fā)布一個(gè)正式版本的lib和APP，這就導(dǎo)致一些用戶無法使用inspector定位元素(使用ARC的用戶除外)，雖然官方建議不要使XPath進(jìn)行元素定位，但有的時(shí)候我們不得不這么做。***殺器是iOS自動(dòng)化受到Apple的單例限制(一臺(tái)物理主機(jī)同一時(shí)間有且僅有一個(gè)Instrument)。
這些種種最終導(dǎo)致了iOS自動(dòng)化測試時(shí)間太長，更不用談及多種iOS設(shè)備的兼容性問題了，自動(dòng)化實(shí)現(xiàn)過程成本過高，令大部分組織和團(tuán)隊(duì)食之無味、棄之可惜。
2. 復(fù)雜場景無法在一臺(tái)機(jī)器上進(jìn)行測試
對于復(fù)雜場景的應(yīng)用來說，我們很難通過現(xiàn)有框架同時(shí)在一臺(tái)物理機(jī)上控制多個(gè)不同的模擬器，也無法隨意的切換到系統(tǒng)級(jí)控件去查看APP觸發(fā)的通知等等。你可以通過一些合法途徑使用虛擬化做iOS端的并發(fā)測試(切記合法途徑)。
但這樣還是逃不掉物理機(jī)龐大的開銷以及虛擬機(jī)的性能損耗問題，拋開這個(gè)問題不講，單從復(fù)雜場景來說，例如出行平臺(tái)，你需要一臺(tái)機(jī)器作為乘客發(fā)布訂單，還需要多個(gè)擁有不同地址定位的車主來測試訂單推送優(yōu)先級(jí)等。對于這種復(fù)雜場景來說Appium控制起來就很難了。
3. 測試場景需要切換不同APP
如今很多的APP功能不單單是在應(yīng)用本身，可能還需要跟系統(tǒng)應(yīng)用以及其他應(yīng)用進(jìn)行交互，例如用戶在被測APP中執(zhí)行某個(gè)操作之后，需要檢查notification，或者在測試的過程中需要切換無網(wǎng)絡(luò)環(huán)境，從而測試APP的不同行為。
想到這些復(fù)雜場景和各種坑之后，估計(jì)打算做iOS測試的同學(xué)心里開始打退堂鼓了。下面我們來一步步逐一解決這些問題：
問題一：解決Instrument單例的限制
對于這個(gè)問題困擾了很久，那業(yè)界領(lǐng)先的互聯(lián)網(wǎng)公司又是怎么做的呢?有一次看到Uber的Showcase，在一臺(tái)機(jī)器上啟動(dòng)了5、6臺(tái)模擬器，用不同類型的賬號(hào)登錄(乘客、車主)每個(gè)模擬器做不同的行為。由于是在物理機(jī)上的對iOS模擬器的操作，速度和性能都得到了很好的保證。他們是怎么解決Instrument的限制呢?
我們可以通過使用Apple私有API，同時(shí)操作不同型號(hào)的模擬器，對多個(gè)不同的Simulator進(jìn)行批量化操作，例如啟動(dòng)、重置、安裝、運(yùn)行等操作:
問題二：解決復(fù)雜場景下控制不同iOS模擬器的不同行為
xcodebuild命令使我們可以把WebDriverAgent運(yùn)行在我們想要的設(shè)備上，但如果使用Apple的命令，還是只能在單個(gè)設(shè)備上安裝運(yùn)行，之前運(yùn)行的多臺(tái)設(shè)備都會(huì)自動(dòng)關(guān)掉，而只會(huì)保留命令中的destination，默認(rèn)啟動(dòng)8100端口去檢測這臺(tái)設(shè)備：
如果這樣的話，那我們之前做的所有工作不就沒有任何意義了嗎?別急，我們已然可以通過Apple提供的資源，對不同的設(shè)備啟動(dòng)不同的進(jìn)程端口進(jìn)行監(jiān)聽。
這時(shí)我們可以通過curl命令launch我們需要的進(jìn)行測試的APP，可以輕而易舉的拿到當(dāng)前運(yùn)行APP的session:
- curl -X POST '-H "Content-Type: application/json"' -d "{\"desiredCapabilities\":{\"bundleId\":\"com.apple.Preferences\"}}" http://localhost:8101/session
- response：{
- "value" : {
- "sessionId" : "94A6580F-1F0F-4411-AC64-3E2525BBA5E1",
- "capabilities" : {
- "device" : "iphone",
- "browserName" : "Settings",
- "sdkVersion" : "10.1",
- "CFBundleIdentifier" : "com.apple.Preferences"
- }
- },
- "sessionId" : "94A6580F-1F0F-4411-AC64-3E2525BBA5E1",
- "status" : 0}
同時(shí)，對于不同的設(shè)備，我們可以通過HTTP server啟動(dòng)inspector來幫助我們進(jìn)行APP中的元素定位，即使是系統(tǒng)應(yīng)用：
問題三：解決不同測試場景需要APP的切換
有了第二個(gè)問題的解決方案，只要執(zhí)行相似的curl命令，就可以拿到不同的APP以及不同的sessionId。
是時(shí)候放棄Appium了?
通過Uber的Octopus框架以及Appium正在使用的WebDriverAgent, 不難發(fā)現(xiàn)此方案的推廣速度以及樂觀的前景。我們可以使用不同curl命令對不同的Simulator以及APP進(jìn)行query、tap、typing以及touch id等操作，這與Appium提供的那些我們最常使用的API的等價(jià)的，并且由于不需要先去調(diào)Appium API 而直接去通過WebDriverAgent與元素進(jìn)行交互，使得測試執(zhí)行速度上有不同程度的提高，又由于自身強(qiáng)大的控制力以及靈活性，使其可以輕松進(jìn)行并發(fā)操作和復(fù)雜業(yè)務(wù)場景支持，我們只需要把不同的curl命令進(jìn)行封裝，結(jié)合各自APP的業(yè)務(wù)場景便可以輕松完成。
帶來的成本?
可以說大部分團(tuán)隊(duì)沒有引入移動(dòng)端自動(dòng)化的原因，最主要的無外乎編寫成本高，UI變化快。個(gè)人認(rèn)為這個(gè)方案帶來的成本比其帶來的價(jià)值要大得多。不再需要QA再去學(xué)習(xí)新的語言來編寫腳本，所有與APP元素的交互都可通過HTTP請求來完成，元素信息通過易讀的JSON來呈現(xiàn)。我們可以通過任何語言和框架用編寫后端自動(dòng)化測試的方式完成iOS的自動(dòng)化測試。
下面通過測試ThoughtWorks的StartKit做一個(gè)簡單的登錄頁面的測試Demo(請?jiān)谠睦稂c(diǎn)擊鏈接)，并且我們已經(jīng)在超過三個(gè)項(xiàng)目中使用過該測試方案。
總結(jié)
由于項(xiàng)目因素，我們實(shí)踐的場景會(huì)相對受限，長時(shí)間如此可能會(huì)影響我們解決問題的思路，我們應(yīng)該不時(shí)的跳出自己工作之外去思考，把簡單的事情做的復(fù)雜，這樣才可以在碰到復(fù)雜問題的時(shí)候，做的簡單。
【本文是專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】
新聞標(biāo)題：復(fù)雜業(yè)務(wù)場景下如何進(jìn)行iOS端自動(dòng)化測試
標(biāo)題網(wǎng)址：http://www.5511xx.com/article/cdhcihs.html
