前言

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

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

首先我們要明白App自動(dòng)化測(cè)試并沒有你預(yù)想中的那么強(qiáng)大，但如果你像我一樣面臨著回歸測(cè)試痛點(diǎn)，它絕對(duì)可以滿足你的需求。沒有那么強(qiáng)大，所以也沒有你預(yù)想中的那么復(fù)雜，同時(shí)它的參與者也絕不只應(yīng)限制在Tester或Developer上，所以在資源上你可以有更靈活的調(diào)配。當(dāng)然，自動(dòng)化測(cè)試是一個(gè)長(zhǎng)期的過程，它的未來，也絕不僅是回歸……

最后我會(huì)為你安利一款偏冷的自動(dòng)化測(cè)試工具：Calabash。并奉上Calabash入門教程博客和一點(diǎn)我的使用心得。介紹Calabash，是因?yàn)镃alabash的特性在我個(gè)人看來更為適合資源緊缺的小微團(tuán)隊(duì)。

大話App自動(dòng)化測(cè)試

僅代表個(gè)人觀點(diǎn)，見識(shí)還淺，歡迎多多打臉。

現(xiàn)狀

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

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

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

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

自動(dòng)化測(cè)試真的對(duì)于小微團(tuán)隊(duì)緊閉大門嗎?

Just do it

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

1.設(shè)定階段計(jì)劃試錯(cuò)

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

但紙上談兵永遠(yuǎn)也不會(huì)有結(jié)果，其他大公司的借鑒意義也不是很強(qiáng)，因?yàn)檫@涉及到團(tuán)隊(duì)、資源分配、業(yè)務(wù)變更頻度、測(cè)試工具、腳本開發(fā)的解耦程度等等。不過自動(dòng)化測(cè)試是一個(gè)必然的趨勢(shì)，所以行動(dòng)是最首要的!

你的團(tuán)隊(duì)目前到底適不適合，只有試了才知道。不妨先設(shè)定幾個(gè)階段，然后用第一階段試錯(cuò)：

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

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

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

利用一人一個(gè)迭代的資源進(jìn)行試錯(cuò)，相信是你可以接受的一個(gè)損失。當(dāng)然，先不要急著做，你也許只是決定了要進(jìn)行自動(dòng)化測(cè)試，但還是要定一些詳細(xì)的計(jì)劃和一些思想、實(shí)際行動(dòng)上的準(zhǔn)備!

2.確定明確且簡(jiǎn)單的目標(biāo)

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

1.黑盒測(cè)試還是白盒測(cè)試 雖然是UI自動(dòng)化測(cè)試，但也可以分為黑盒或白盒，這個(gè)取決你想要的測(cè)試精密度，也就是在這個(gè)時(shí)候，可以初步確定要使用什么自動(dòng)化測(cè)試工具。比如通常我們?yōu)榱丝梢噪p平臺(tái)會(huì)選擇Appium這種可以跨平臺(tái)的測(cè)試工具，但假如你有很高的測(cè)試要求，以Android為例，建議你使用Android官方推薦的測(cè)試框架：Espresso，直接在Android工程項(xiàng)目中寫Test。 這樣說出來好像誰都明白，但如果你不能在前期就明確你的需求，可能會(huì)在后期帶來很大的困擾!選擇Appium，因?yàn)槭呛诤校龅侥承┨厥獾膱?chǎng)景或需求，導(dǎo)致個(gè)別case無法測(cè)試。或者選擇了Espresso，但后來發(fā)現(xiàn)其實(shí)并沒有那么精密的測(cè)試需求，導(dǎo)致后期無法跨平臺(tái)或者認(rèn)為Espresso編寫成本過高，還很難移交給測(cè)試團(tuán)隊(duì)。

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

先確定一個(gè)明確且簡(jiǎn)單的目標(biāo)，然后一頭扎進(jìn)去。如果想的多了，困難也就多了，最后可能也就只是想想了，這就是下面緊接著要說的點(diǎn)：降低期望!

3.降低期望

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

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

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

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

• 降低期望，先以回歸為目標(biāo)
• 降低期望，前后端自動(dòng)化測(cè)試都要有，一套解決不了問題
• 降低期望，客戶端自動(dòng)化測(cè)試限制依然很多，人工測(cè)試驗(yàn)證不能全部丟下
• 降低期望，一口吃不成個(gè)胖子，自動(dòng)化測(cè)試也是需要慢慢迭代完善的，先跑通再關(guān)心驗(yàn)證異常case。快速迭代，逐步完善

4.術(shù)業(yè)有專攻

也許你的團(tuán)隊(duì)里是開發(fā)或者測(cè)試中的某一方無法承受壓力，從而開始探索App自動(dòng)化測(cè)試。 開發(fā)去做自動(dòng)化測(cè)試的優(yōu)點(diǎn)在于因?yàn)橛懈S富的開發(fā)經(jīng)驗(yàn)，測(cè)試環(huán)境的搭建更為熟練，且因?yàn)槭亲约簩懙拇a，會(huì)更了解風(fēng)險(xiǎn)點(diǎn)在哪里，能寫出有針對(duì)性的case。測(cè)試去做自動(dòng)化測(cè)試的優(yōu)點(diǎn)在于發(fā)現(xiàn)更多的邊界場(chǎng)景，寫出更全面的測(cè)試case。

在自動(dòng)化測(cè)試上，開發(fā)和測(cè)試各具不同的優(yōu)勢(shì)，但同時(shí)這也是對(duì)方的劣勢(shì)。

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

5.一個(gè)巴掌拍不響

首先再次明確我的一個(gè)觀點(diǎn)：在沒有足夠的資源的情況下，移動(dòng)客戶端自動(dòng)化測(cè)試，主要針對(duì)的應(yīng)該是回歸測(cè)試。

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

所以這個(gè)時(shí)候你就不能自己?jiǎn)胃闪耍フ覝y(cè)試同學(xué)，看能不能搞一個(gè)配合自動(dòng)化測(cè)試的測(cè)試環(huán)境，拿搶單來說，我希望這個(gè)環(huán)境上永遠(yuǎn)有好多單讓我搶。我就是搶單的app，沒單我還玩什么。

如果測(cè)試同學(xué)搞不定，那么就去拉后端的同學(xué)啦，我相信為了項(xiàng)目越來越好，他們是不會(huì)拒絕你的。

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

小結(jié)

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