前言

App自動化測試一直是小微團隊很少會去涉足的領域，在互聯(lián)網(wǎng)快速迭代這個大場景下，隨著業(yè)務發(fā)展，回歸壓力逐漸增大。相信每次因為回歸覆蓋不足而導致線上事故，懊惱郁悶到要砸桌子的絕對不止我一個。

一般情況小微團隊的測試包括回歸測試都是人工進行的，一些偏離主流程卻又比較關鍵的業(yè)務往往是人工回歸測試容易遺漏的。人力有窮盡，這個時候自動化測試這個念頭就從你的腦袋里冒出來了，然后就是去研究嘛。但可能最終也就止步于研究了。不談自動化框架的搭建，種種細分的邊界case,一個必然很繁瑣的東西想一想就更繁瑣了。如果你是App開發(fā)，本來業(yè)務開發(fā)上的人手就不是很充足，再去開發(fā)自動化腳本，有心無力!如果你是測試，每個迭代的業(yè)務需求測試就填滿了你的排期，更何況承擔的可不只是App測試任務。作為小微團隊，自動化我們也想，但我們沒有資源……

首先我們要明白App自動化測試并沒有你預想中的那么強大，但如果你像我一樣面臨著回歸測試痛點，它絕對可以滿足你的需求。沒有那么強大，所以也沒有你預想中的那么復雜，同時它的參與者也絕不只應限制在Tester或Developer上，所以在資源上你可以有更靈活的調配。當然，自動化測試是一個長期的過程，它的未來，也絕不僅是回歸……

最后我會為你安利一款偏冷的自動化測試工具：Calabash。并奉上Calabash入門教程博客和一點我的使用心得。介紹Calabash，是因為Calabash的特性在我個人看來更為適合資源緊缺的小微團隊。

大話App自動化測試

僅代表個人觀點，見識還淺，歡迎多多打臉。

現(xiàn)狀

先說點大家都知道的。以Android為例，從2010年開始，Android開發(fā)環(huán)境以及其迅猛的態(tài)勢發(fā)展到今天，幾近趨于成熟，開發(fā)者的目光早已不在局限于這單一的開發(fā)平臺，開始尋求Android，iOS在開發(fā)上的統(tǒng)一：ReactNactive,WEEX,H5……

開發(fā)環(huán)境已經(jīng)成熟，但移動客戶端的測試環(huán)境卻有些滯后。這中間的幾座大山是很多團隊正在面對且駐足的：

1.App測試不像服務端測試通常只需對數(shù)據(jù)本身進行驗證即可，App涉及到界面展示及交互，自動化識別難度大。 2.互聯(lián)網(wǎng)企業(yè)一直都在追尋快速迭代，且App直接對接用戶，App的界面與邏輯變更更是家常便飯，編寫自動化測試腳本的穩(wěn)定性很差，可能設計對界面的一次改動，之前與這個頁面掛鉤的所有腳本就都廢掉了。 3.Android iOS 雙平臺,web頁面。多平臺的情況下想要依靠一套代碼進行自動化測試幾乎是不可能的。再考慮需要經(jīng)常變更，你懂得。 4.比起人工來說，自動化測試可能需要為種種邊界case編寫很多的腳本。同比人工測試，可能需要的只是事先設計幾個場景，其他的異常邊界case通過測試中人為觀察就好了。自動化測試成本倍增!

所以往往一個完善的移動自動化測試環(huán)境需要一個龐大的測試團隊支撐，但一個龐大的測試團隊只有大公司才能負擔的起。移動的自動化測試，一直都在被中小型的創(chuàng)業(yè)公司所忽略。小型公司開發(fā)自測了事，中型公司依靠測試人員人工操作進行驗證。

自動化測試真的對于小微團隊緊閉大門嗎?

Just do it

上面說的這些現(xiàn)狀只能說是難題，也許現(xiàn)在討論解決這些問題還早了些。我覺得你有些東西還沒確定清楚，要不然先跟著我的思路走一走?等下面一些事情都想明白了，也許這些問題能避也就避過了，需要硬上的，也有足夠心理準備了。

1.設定階段計劃試錯

其實讓小微團隊面對自動化測試左右徘徊最大的一個問題就是：投入產(chǎn)出比! 很難去預估實行自動化測試后，在頁面頻繁變更與腳本的開發(fā)和維護之間，測試或開發(fā)人員會不會陷入泥潭。

但紙上談兵永遠也不會有結果，其他大公司的借鑒意義也不是很強，因為這涉及到團隊、資源分配、業(yè)務變更頻度、測試工具、腳本開發(fā)的解耦程度等等。不過自動化測試是一個必然的趨勢，所以行動是最首要的!

你的團隊目前到底適不適合，只有試了才知道。不妨先設定幾個階段，然后用第一階段試錯：

階段1：抽出一個人一個迭代的資源完成主流程業(yè)務的自動化測試case，試運行兩到三個迭代，并在這期間增加主流程異常case。利用這三個迭代來評估后續(xù)發(fā)展可行性! 階段2-(階段1成功度過)：如果你認為階段1的狀態(tài)還不錯，那么在維護階段1成果的基礎上從剩余業(yè)務場景中按照業(yè)務關鍵程度、變更頻率來選取一個新的業(yè)務，以一個人一個迭代一個業(yè)務的節(jié)奏編寫自動化測試case!

階段2-(階段1過度失敗)：當然，經(jīng)過三個迭代的評估，隨著異常case增多，同步維護難度越來越大，你可能認為實行自動化測試的成本過大，但也不要輕易放棄這三個迭代的成果。請先利用編程思維檢查所有的測試腳本，是否有抽取相似代碼，封裝特定View操作，抽離與業(yè)務無關指令的可能。同時考慮利用全組資源就此維護這套主流程自動化case。直到將來資源充足或找到更好的替代方案后進行階段3或重新階段1。

階段3：大概在5~8個迭代后，你成功撐過了階段2，說明你的自動化測試環(huán)境已經(jīng)步入正軌，那么這個時候可以按照團隊資源情況適當加快自動化case覆蓋率!

利用一人一個迭代的資源進行試錯，相信是你可以接受的一個損失。當然，先不要急著做，你也許只是決定了要進行自動化測試，但還是要定一些詳細的計劃和一些思想、實際行動上的準備!

2.確定明確且簡單的目標

有了大的計劃，還要明確具體的需求，可選的需求大概有這么些：

1.黑盒測試還是白盒測試 雖然是UI自動化測試，但也可以分為黑盒或白盒，這個取決你想要的測試精密度，也就是在這個時候，可以初步確定要使用什么自動化測試工具。比如通常我們?yōu)榱丝梢噪p平臺會選擇Appium這種可以跨平臺的測試工具，但假如你有很高的測試要求，以Android為例，建議你使用Android官方推薦的測試框架：Espresso，直接在Android工程項目中寫Test。 這樣說出來好像誰都明白，但如果你不能在前期就明確你的需求，可能會在后期帶來很大的困擾!選擇Appium，因為是黑盒，遇到某些特殊的場景或需求，導致個別case無法測試?；蛘哌x擇了Espresso，但后來發(fā)現(xiàn)其實并沒有那么精密的測試需求，導致后期無法跨平臺或者認為Espresso編寫成本過高，還很難移交給測試團隊。

2.前端UI還是整體業(yè)務 舉個例子，搶單并且進行配送這個場景。發(fā)現(xiàn)一個訂單并點擊搶單，然后進行取餐，最后完成配送這一套只能用肉眼觀察到的UI層操作，我們暫定為這是前端UI邏輯。但在這一系列操作背后訂單狀態(tài)流轉引起其他數(shù)據(jù)變動，比如：錢包數(shù)據(jù)變更，活動獎勵數(shù)據(jù)變更，欺詐單判定等等這個范圍，就屬于整體業(yè)務范疇了。 而我們需要現(xiàn)在確定的，就是你想要達到的測試期望是UI測試，還是整體業(yè)務測試。這直接決定了你測試腳本的復雜度。而我的建議是僅測UI邏輯，也是我想讓你降低期望一個點。

先確定一個明確且簡單的目標，然后一頭扎進去。如果想的多了，困難也就多了，最后可能也就只是想想了，這就是下面緊接著要說的點：降低期望!

3.降低期望

在人工(對著手機點點點)測試的環(huán)境下，我們通常都是通過操作App進行各種case驗證，只要操作app驗證通過了那基本可以確定前后端沒什么問題了。但這個前提是人工驗證是人腦加肉眼，它會有更準確的主觀判斷。 涉及到前后端交互會增加極大的復雜性，你的測試case不會無限多無限精細，但作為人腦你可以在有限的case執(zhí)行中發(fā)現(xiàn)更多不符合常理的bug：文字不合理的折行，不準確的數(shù)值顯示，按鈕顏色不對，Toast展示數(shù)量有誤等等等。自動化測試會死板的跟著你寫的腳本走，你能保證你的case覆蓋到了所有了嗎?

這也是談到自動化測試，好多人都會拋出的一個疑問，那么多異常case怎么寫啊，想想都累，考慮一下投入產(chǎn)出比要不還是人工測試吧。

首先要明確的一點，前后端自動化測試一定要分開，一套解決不了問題，這樣在前端測試中可以忽略很多的case。 另外自動化測試是一個與項目成長一樣的長期過程，自動化完全代替人工依然還需要走一段時間，你不要想著一步到位。 依然還是會有很多的case要寫對吧?資源不夠我們可以先跑通主流程再說，跑通主流程也就意味著腳本依賴(環(huán)境搭建，view定位)已經(jīng)較為成熟了，其他異常case腳本對著主流程腳本修改即可，這個我們慢慢來嘛，而且這個時候你就可以放開給別的開發(fā)或測試讓他們照貓畫虎了。這也就是我們上面說的階段1。

如果這些問題不能想通，你會發(fā)現(xiàn)在App自動化測試條件有限的情況下，并不能實現(xiàn)你想要的結果，從而迫于壓力而放棄了。說服自己降低期望!

• 降低期望，先以回歸為目標
• 降低期望，前后端自動化測試都要有，一套解決不了問題
• 降低期望，客戶端自動化測試限制依然很多，人工測試驗證不能全部丟下
• 降低期望，一口吃不成個胖子，自動化測試也是需要慢慢迭代完善的，先跑通再關心驗證異常case?？焖俚鸩酵晟?/li>

4.術業(yè)有專攻

也許你的團隊里是開發(fā)或者測試中的某一方無法承受壓力，從而開始探索App自動化測試。 開發(fā)去做自動化測試的優(yōu)點在于因為有更豐富的開發(fā)經(jīng)驗，測試環(huán)境的搭建更為熟練，且因為是自己寫的代碼，會更了解風險點在哪里，能寫出有針對性的case。測試去做自動化測試的優(yōu)點在于發(fā)現(xiàn)更多的邊界場景，寫出更全面的測試case。

在自動化測試上，開發(fā)和測試各具不同的優(yōu)勢，但同時這也是對方的劣勢。

測試case一定要越全面越好，而且自動化測試本身就是一個工程項目，在寫腳本時，如果更多的考慮一些編程思想，合理的耦合和解耦，將會讓之后的腳本編寫更便捷。 所以，非常不建議自動化測試完全單獨交給測試人員或開發(fā)人員來負責，最好是一種緊密合作的關系。同時也是應對資源不足的一個解決之道。雖是測試，但有開發(fā)的加入，會讓測試工程朝著更優(yōu)的方向發(fā)展。

5.一個巴掌拍不響

首先再次明確我的一個觀點：在沒有足夠的資源的情況下，移動客戶端自動化測試，主要針對的應該是回歸測試。

自動化測試相比起人工測試，是非常死板的，那么就需要非常“死板”的數(shù)據(jù)支持.如果是App開發(fā)(就像我)去做自動化測試這件事，難道所有數(shù)據(jù)我都要mock一遍嗎?雖說前后端自動化應該分開，前面也說了應該只關心前端邏輯。但一定還是要在真實的服務環(huán)境(測試環(huán)境，非生產(chǎn)環(huán)境)進行測試。 mock數(shù)據(jù)過于死板，很多case可能就無法驗證了，比如注冊場景，要驗證注冊過的賬號無法再注冊時的異常提示，mock數(shù)據(jù)顯然較難兼顧正常注冊和異常注冊兩種。而且在真實環(huán)境中測試，萬一測出來一個后端bug不挺好么。 而且，手機淘寶這樣完全2C的應用直接在生產(chǎn)環(huán)境測試好像沒什么太大問題，但像蜂鳥配送這樣半2C的應用來說就比較尷尬，直接去搶線上單明顯不可能，那么在測試環(huán)境這個訂單誰來發(fā)怎么發(fā)呢?

所以這個時候你就不能自己單干了，去找測試同學，看能不能搞一個配合自動化測試的測試環(huán)境，拿搶單來說，我希望這個環(huán)境上永遠有好多單讓我搶。我就是搶單的app，沒單我還玩什么。

如果測試同學搞不定，那么就去拉后端的同學啦，我相信為了項目越來越好，他們是不會拒絕你的。

自動化測試，不僅是自動化測試工具就夠了，同樣還需要測試環(huán)境的支持。

小結

其實說了這么多，就是想要你降低期望，并付諸行動。 App的自動化識別和多平臺自然會有大批的自動化工具幫你實現(xiàn)，而學會降低期望的同時也會降低腳本開發(fā)和維護的難度。