一、背景

移動技術(shù)發(fā)展到現(xiàn)階段，原生、混合式技術(shù)發(fā)展的足夠成熟，可以無縫融合。而隨著移動技術(shù)的發(fā)展和革新，移動領(lǐng)域的測試技術(shù)和實(shí)踐也有了一定發(fā)展：工具不再像早期一樣幾家獨(dú)大，選擇性越來越多;從淺嘗輒止的實(shí)驗(yàn)階段到真實(shí)項(xiàng)目中的自動化測試落地。這些實(shí)踐在一定程度上提升了測試反饋效率，在迭代交付的過程中出色的完成了質(zhì)量保證的工作，但在相對漫長的實(shí)踐過程中，我們依然可以總結(jié)一些痛點(diǎn)：

1. 移動自動化測試的執(zhí)行效率遠(yuǎn)不及Web應(yīng)用

有過Web自動化測試經(jīng)驗(yàn)的同學(xué)對于Selenium肯定不會陌生，Web端的并發(fā)測試使得測試在有限資源的情況下按照我們的期望并發(fā)執(zhí)行。而且由于keychain等問題，很難在測試用例之間做到互不影響、對于測試環(huán)境的清理和準(zhǔn)備也有很大難度。

2. 很難全面覆蓋繁雜的測試設(shè)備

Web自動化測試關(guān)注的測試環(huán)境相對單純，針對不同項(xiàng)目、產(chǎn)品和市場，無非是對不同的瀏覽器和操作系統(tǒng)有不同程度的支持。而對于不同瀏覽器也有不同的driver來支持。而在移動測試中，很難做到對眾多廠商和不同操作系統(tǒng)設(shè)備進(jìn)行模擬。

3. 移動自動化框架很難支持到回歸測試顆粒度

在移動端(以iOS為例)，受限于Apple的機(jī)制，大部分框架很難覆蓋到與iOS系統(tǒng)/第三方App交互的場景，例如系統(tǒng)通知跳轉(zhuǎn)、實(shí)時通訊應(yīng)用信息發(fā)送等場景。而若無法覆蓋核心功能，那么自動化測試的落地實(shí)則是在給自己和團(tuán)隊(duì)挖坑，得不償失。

[[231999]]

這些問題在隨著WebDriverAgent的成熟以及XCode 9的新特性 —— Multiple concurrent simulators的出現(xiàn)，得到了極大程度的解決，我們可以像對Web應(yīng)用一樣，對移動端應(yīng)用在不同的simulator上并發(fā)執(zhí)行測試用例，極大提升了測試反饋效率。而且，測試人員不再受限從而可以編寫覆蓋率更高的測試用例。

二、除了普適性問題之外企業(yè)對移動測試方案潛在的需求

在項(xiàng)目的具體實(shí)施過程中，除了我們經(jīng)常被這些普遍存在的細(xì)節(jié)問題困擾之外，企業(yè)或組織級客戶已經(jīng)對移動端自動化測試提出了更高的要求。在一次機(jī)會給客戶講解移動端自動化測試趨勢時發(fā)現(xiàn)，新的框架的確會使客戶眼前一亮，但是，在實(shí)踐上的優(yōu)勢無非是你比其他人先研究了什么，這樣的領(lǐng)先微乎其微，在交流過程中觀察到客戶更大的痛點(diǎn)是:

如何同時覆蓋到更多物理設(shè)備?如何更好的構(gòu)建和重用基礎(chǔ)設(shè)施?如何跨地域高效使用測試資源?

帶著這幾個問題，我們對比了一些現(xiàn)有的可用方案，例如AWS device farm。Device farm是針對移動App提供的測試服務(wù)，用戶可以對在AWS托管的基于iOS和Android物理設(shè)備測試原生和混合應(yīng)用。用戶既可以使用各種測試框架來做自動化測試，也可以遠(yuǎn)程訪問設(shè)備進(jìn)行應(yīng)用程序的測試和調(diào)試。

但是該解決方案也是有一定局限性的，當(dāng)測試運(yùn)行期間同時執(zhí)行測試的設(shè)備***只有五個，而運(yùn)行測試的時間也被限制到60分鐘。當(dāng)然上述的限制可以根據(jù)需要適當(dāng)?shù)姆潘桑瞧髽I(yè)和用戶不得不承擔(dān)價值不菲成本。

與AWS device farm類似，SauceLabs和Xamarin也提供類似的平臺，那SauceLabs的服務(wù)舉例，如果想使用***運(yùn)行時間，支持24個并發(fā)運(yùn)行設(shè)備，模擬器用戶需要每月承擔(dān)3576刀，而如果想使用真實(shí)設(shè)備進(jìn)行測試，大概需要每月花費(fèi)7200刀。這種昂貴的成本對于企業(yè)很難承受，而且重要的是這種資源是無法復(fù)制，企業(yè)不得不持續(xù)為云服務(wù)支付高昂的費(fèi)用。

[[232000]]

安全性也是企業(yè)需要考慮的問題，用戶不得不在云測試平臺上傳自己的IPA或APK。我們當(dāng)然可以信賴AWS的安全機(jī)制。一些對安全性要求較高的企業(yè)來說，更想規(guī)避這樣的風(fēng)險。

三、打造私有移動真機(jī)測試平臺

通過分析，對于客戶的需求大概涵蓋幾點(diǎn)：真實(shí)設(shè)備、并發(fā)、成本、安全、可重用。鑒于這些需求，我們把目標(biāo)進(jìn)行拆分：

1. 設(shè)備管理——服務(wù)發(fā)現(xiàn)與注冊

在該實(shí)例中我們使用WebDriverAgent作為測試框架，需要運(yùn)行在每一個物理設(shè)備上，我們可以把這些物理設(shè)備當(dāng)作Agent集群。這些集群設(shè)備就是我們運(yùn)行WebDriverAgent的服務(wù)終端，我們可以通過很簡單的程序讓W(xué)ebDriverAgent自動在設(shè)備上運(yùn)行。通過服務(wù)發(fā)現(xiàn)與注冊機(jī)制，把WebDriverAgent服務(wù)注冊在通過Ansible管理的Proxy上。而服務(wù)發(fā)現(xiàn)與注冊不單單解決了復(fù)雜的設(shè)備管理，而且可以解決分布式團(tuán)隊(duì)合作時設(shè)備跨地域有效利用的問題。

[[232001]]

2. 平臺數(shù)據(jù)可視化

對于一個測試平臺來說，如何把所有可用的服務(wù)(機(jī)器)、服務(wù)狀態(tài)、自動重啟和crash報告等數(shù)據(jù)可視化給企業(yè)終端用戶，是極為重要的。那老牌Apache zookeeper來說，提供了友好的服務(wù)可視化管理功能并且可以根據(jù)用戶需求進(jìn)行二次開發(fā)。重要的是，這些底層基礎(chǔ)設(shè)施服務(wù)可以在之后的任何一個移動測試項(xiàng)目中被重用。

3. 自動化測試運(yùn)行和報告生成

自動化測試平臺雖然提供了強(qiáng)大的服務(wù)(設(shè)備)管理、服務(wù)可視化等功能。而自動化測試的核心需求依然是如何保障測試的獨(dú)立性、穩(wěn)定性、易維護(hù)性、重用性和覆蓋率。通過WebDriverAgent跨語言測試框架，我們可以像架構(gòu)Web自動化測試一樣來開發(fā)針對移動端的測試工程。但需要注意的是移動測試不同的是真實(shí)物理設(shè)備，而不是計(jì)算機(jī)的某個進(jìn)程。另外，如何接觸測試場景的相互依賴、保證測試間的獨(dú)立性，以及如何清理測試環(huán)境，需要大家在進(jìn)行移動端架構(gòu)的時候事先考慮。

這樣一來，我們?nèi)绻梢越鉀Q這三個問題，就可以不受昂貴的成本限制，為企業(yè)量身定做適合自己的業(yè)務(wù)規(guī)模的移動測試私有云了，不但為企業(yè)和組織機(jī)構(gòu)構(gòu)建了大型測試服務(wù)平臺，同時也解決了之前提到的普適性問題。

四、總結(jié)

隨著DevOps的發(fā)展，軟件工程的開發(fā)、部署、上線、應(yīng)急預(yù)案等都被自動化監(jiān)控和處理。如果我們依然停留在“成熟”的解決方案而缺少思考，那么留給QA/測試人員的發(fā)展空間越來越少。

我們需要通過對測試技術(shù)細(xì)節(jié)的不斷歸納、對比和練習(xí)，抓住領(lǐng)域發(fā)展趨勢和真正的客戶訴求，結(jié)合其他非測試技術(shù)，幫助自己在測試技能上有所突破，同時幫助自己提升構(gòu)思和落地解決方案的能力。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文