小微團隊怎麼玩轉App自動化測試

2017-3-21 | 暴打小女孩| 測試

前言

這篇博客，我會站在小微團隊的角度，介紹一下我對App自動化測試的一些見解。在幫助你下降對App自動化測試的指望的同時說服你開始實踐App自動化測試。

App自動化測試一直是小微團隊不多會去涉足的領域，在互聯網快速迭代這個大場景下，隨着業務發展，迴歸壓力逐漸增大。相信每次由於迴歸覆蓋不足而致使線上事故，懊惱鬱悶到要砸桌子的絕對不止我一個。

通常狀況小微團隊的測試包括迴歸測試都是人工進行的，一些偏離主流程卻又比較關鍵的業務每每是人工迴歸測試容易遺漏的。人力有窮盡，這個時候自動化測試這個念頭就從你的腦殼裏冒出來了，而後就是去研究嘛。但可能最終也就止步於研究了。不談自動化框架的搭建，種種細分的邊界case,一個必然很繁瑣的東西想想就更繁瑣了。若是你是App開發，原本業務開發上的人手就不是很充足，再去開發自動化腳本，有心無力！若是你是測試，每一個迭代的業務需求測試就填滿了你的排期，更況且承擔的可不僅是App測試任務。做爲小微團隊，自動化咱們也想，但咱們沒有資源……

首先咱們要明白App自動化測試並無你預想中的那麼強大，但若是你像我同樣面臨着迴歸測試痛點，它絕對能夠知足你的需求。沒有那麼強大，因此也沒有你預想中的那麼複雜，同時它的參與者也毫不只應限制在Tester或Developer上，因此在資源上你能夠有更靈活的調配。固然，自動化測試是一個長期的過程，它的將來，也毫不僅是迴歸……

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

大話App自動化測試

僅表明我的觀點，見識還淺，歡迎多多打臉。

現狀

先說點你們都知道的。以Android爲例，從2010年開始，Android開發環境以及其迅猛的態勢發展到今天，幾近趨於成熟，開發者的目光早已不在侷限於這單一的開發平臺，開始尋求Android，iOS在開發上的統一：ReactNactive,WEEX,H5……

開發環境已經成熟，但移動客戶端的測試環境卻有些滯後。這中間的幾座大山是不少團隊正在面對且駐足的：

1.App測試不像服務端測試一般只需對數據自己進行驗證便可，App涉及到界面展現及交互，自動化識別難度大。 2.互聯網企業一直都在追尋快速迭代，且App直接對接用戶，App的界面與邏輯變動更是屢見不鮮，編寫自動化測試腳本的穩定性不好，可能設計對界面的一次改動，以前與這個頁面掛鉤的全部腳本就都廢掉了。 3.Android iOS 雙平臺,web頁面。多平臺的狀況下想要依靠一套代碼進行自動化測試幾乎是不可能的。再考慮須要常常變動，你懂得。 4.比起人工來講，自動化測試可能須要爲種種邊界case編寫不少的腳本。同比人工測試，可能須要的只是事先設計幾個場景，其餘的異常邊界case經過測試中人爲觀察就行了。自動化測試成本倍增！

因此每每一個完善的移動自動化測試環境須要一個龐大的測試團隊支撐，但一個龐大的測試團隊只有大公司才能負擔的起。移動的自動化測試，一直都在被中小型的創業公司所忽略。小型公司開發自測了事，中型公司依靠測試人員人工操做進行驗證。

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

Just do it

上面說的這些現狀只能說是難題，也許如今討論解決這些問題還早了些。我以爲你有些東西還沒肯定清楚，要否則先跟着個人思路走一走？等下面一些事情都想明白了，也許這些問題能避也就避過了，須要硬上的，也有足夠心理準備了。

1.設定階段計劃試錯

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

但紙上談兵永遠也不會有結果，其餘大公司的借鑑意義也不是很強，由於這涉及到團隊、資源分配、業務變動頻度、測試工具、腳本開發的解耦程度等等。不過自動化測試是一個必然的趨勢，因此行動是最首要的！

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

階段1：抽出一我的一個迭代的資源完成主流程業務的自動化測試case，試運行兩到三個迭代，並在這期間增長主流程異常case。利用這三個迭代來評估後續發展可行性！ 階段2-（階段1成功度過）：若是你認爲階段1的狀態還不錯，那麼在維護階段1成果的基礎上從剩餘業務場景中按照業務關鍵程度、變動頻率來選取一個新的業務，以一我的一個迭代一個業務的節奏編寫自動化測試case！ 階段2-（階段1過分失敗）：固然，通過三個迭代的評估，隨着異常case增多，同步維護難度愈來愈大，你可能認爲實行自動化測試的成本過大，但也不要輕易放棄這三個迭代的成果。請先利用編程思惟檢查全部的測試腳本，是否有抽取類似代碼，封裝特定View操做，抽離與業務無關指令的可能。同時考慮利用全組資源就此維護這套主流程自動化case。直到未來資源充足或找到更好的替代方案後進行階段3或從新階段1。 階段3：大概在5~8個迭代後，你成功撐過了階段2，說明你的自動化測試環境已經步入正軌，那麼這個時候能夠按照團隊資源狀況適當加快自動化case覆蓋率！

利用一人一個迭代的資源進行試錯，相信是你能夠接受的一個損失。固然，先不要急着作，你也許只是決定了要進行自動化測試，但仍是要定一些詳細的計劃和一些思想、實際行動上的準備！

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

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

1.黑盒測試仍是白盒測試 雖然是UI自動化測試，但也能夠分爲黑盒或白盒，這個取決你想要的測試精密度，也就是在這個時候，能夠初步肯定要使用什麼自動化測試工具。好比一般咱們爲了能夠雙平臺會選擇Appium這種能夠跨平臺的測試工具，但假如你有很高的測試要求，以Android爲例，建議你使用Android官方推薦的測試框架：Espresso，直接在Android工程項目中寫Test。 這樣說出來好像誰都明白，但若是你不能在前期就明確你的需求，可能會在後期帶來很大的困擾！選擇Appium，由於是黑盒，遇到某些特殊的場景或需求，致使個別case沒法測試。或者選擇了Espresso，但後來發現其實並無那麼精密的測試需求，致使後期沒法跨平臺或者認爲Espresso編寫成本太高，還很難移交給測試團隊。

2.前端UI仍是總體業務 舉個例子，搶單而且進行配送這個場景。發現一個訂單並點擊搶單，而後進行取餐，最後完成配送這一套只能用肉眼觀察到的UI層操做，咱們暫定爲這是前端UI邏輯。但在這一系列操做背後訂單狀態流轉引發其餘數據變更，好比：錢包數據變動，活動獎勵數據變動，欺詐單斷定等等這個範圍，就屬於總體業務範疇了。 而咱們須要如今肯定的，就是你想要達到的測試指望是UI測試，仍是總體業務測試。這直接決定了你測試腳本的複雜度。而個人建議是僅測UI邏輯，也是我想讓你下降指望一個點。

先肯定一個明確且簡單的目標，而後一頭扎進去。若是想的多了，困難也就多了，最後可能也就只是想一想了，這就是下面緊接着要說的點：下降指望！

3.下降指望

在人工（對着手機點點點）測試的環境下，咱們一般都是經過操做App進行各類case驗證，只要操做app驗證經過了那基本能夠肯定先後端沒什麼問題了。但這個前提是人工驗證是人腦加肉眼，它會有更準確的主觀判斷。 涉及到先後端交互會增長極大的複雜性，你的測試case不會無限多無限精細，但做爲人腦你能夠在有限的case執行中發現更多不符合常理的bug：文字不合理的折行，不許確的數值顯示，按鈕顏色不對，Toast展現數量有誤等等等。自動化測試會死板的跟着你寫的腳本走，你能保證你的case覆蓋到了全部了嗎？

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

首先要明確的一點，先後端自動化測試必定要分開，一套解決不了問題，這樣在前端測試中能夠忽略不少的case。 另外自動化測試是一個與項目成長同樣的長期過程，自動化徹底代替人工依然還須要走一段時間，你不要想着一步到位。 依然仍是會有不少的case要寫對吧？資源不夠咱們能夠先跑通主流程再說，跑通主流程也就意味着腳本依賴（環境搭建，view定位）已經較爲成熟了，其餘異常case腳本對着主流程腳本修改便可，這個咱們慢慢來嘛，並且這個時候你就能夠放開給別的開發或測試讓他們照貓畫虎了。這也就是咱們上面說的階段1。

若是這些問題不能想通，你會發如今App自動化測試條件有限的狀況下，並不能實現你想要的結果，從而迫於壓力而放棄了。說服本身下降指望！

• 下降指望，先以迴歸爲目標
• 下降指望，先後端自動化測試都要有，一套解決不了問題
• 下降指望，客戶端自動化測試限制依然不少，人工測試驗證不能所有丟下
• 下降指望，一口吃不成個胖子，自動化測試也是須要慢慢迭代完善的，先跑通再關心驗證異常case。快速迭代，逐步完善

4.術業有專攻

也許你的團隊裏是開發或者測試中的某一方沒法承受壓力，從而開始探索App自動化測試。 開發去作自動化測試的優勢在於由於有更豐富的開發經驗，測試環境的搭建更爲熟練，且由於是本身寫的代碼，會更瞭解風險點在哪裏，能寫出有針對性的case。測試去作自動化測試的優勢在於發現更多的邊界場景，寫出更全面的測試case。

在自動化測試上，開發和測試各具不一樣的優點，但同時這也是對方的劣勢。

測試case必定要越全面越好，並且自動化測試自己就是一個工程項目，在寫腳本時，若是更多的考慮一些編程思想，合理的耦合和解耦，將會讓以後的腳本編寫更便捷。 因此，很是不建議自動化測試徹底單獨交給測試人員或開發人員來負責，最好是一種緊密合做的關係。同時也是應對資源不足的一個解決之道。雖是測試，但有開發的加入，會讓測試工程朝着更優的方向發展。

5.一個巴掌拍不響

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

自動化測試相比起人工測試，是很是死板的，那麼就須要很是「死板」的數據支持.若是是App開發（就像我）去作自動化測試這件事，難道全部數據我都要mock一遍嗎？雖然說先後端自動化應該分開，前面也說了應該只關心前端邏輯。但必定仍是要在真實的服務環境（測試環境，非生產環境）進行測試。 mock數據過於死板，不少case可能就沒法驗證了，好比註冊場景，要驗證註冊過的帳號沒法再註冊時的異常提示，mock數據顯然較難兼顧正常註冊和異常註冊兩種。並且在真實環境中測試，萬一測出來一個後端bug不挺好麼。 並且，手機淘寶這樣徹底2C的應用直接在生產環境測試好像沒什麼太大問題，但像蜂鳥配送這樣半2C的應用來講就比較尷尬，直接去搶線上單明顯不可能，那麼在測試環境這個訂單誰來發怎麼發呢？

因此這個時候你就不能本身單幹了，去找測試同窗，看能不能搞一個配合自動化測試的測試環境，拿搶單來講，我但願這個環境上永遠有好多單讓我搶。我就是搶單的app，沒單我還玩什麼。

若是測試同窗搞不定，那麼就去拉後端的同窗啦，我相信爲了項目愈來愈好，他們是不會拒絕你的。

自動化測試，不只是自動化測試工具就夠了，一樣還須要測試環境的支持。

小結

其實說了這麼多，就是想要你下降指望，並付諸行動。 App的自動化識別和多平臺天然會有大批的自動化工具幫你實現，而學會下降指望的同時也會下降腳本開發和維護的難度。

難道你還在糾結細分case太多的問題？先放一放又如何？反正你都裸奔這麼久了，穿褲子不也要先穿個褲衩才行麼，褲子慢慢來！ 或者你依然徘徊在投入產出比的問題上？買衣服不也要先試穿才知道碼號的嗎？

OK，下面咱們聊聊這個褲衩，和怎麼穿這個褲衩！

測試工具

作好了思想工做，具體實現仍是須要選擇一個具體的測試工具，工具沒有好壞，只有適不適合。 Calabash是我我的建議小微團隊使用的測試工具，由於其兼具門檻低、跨平臺、腳本維護容易的特性，而這正是小微團隊最急需的。 且其BDD（行爲驅動開發）的思想雖然有點烏托邦，但從遠瞻的角度來看，實現測試腳本先於程序開發編寫的這種先進項目管理可能性也大於其餘工具，讓測試不只僅是測試！

下面我會對Calabash的特性作一個簡單介紹，詳述其優缺點，你能夠根據自身團隊經驗進行選擇是否使用，若是喜歡，文末會附上Calabash由淺入深的入門教程，加之更詳細的特性介紹和我本身的使用建議。

Calabash

談Calabash前，先要交代清楚Calabash是啥。

Calabash的核心是Cucumber，Cucumber是一個可以用天然語言編寫實例的協做工具，其核心思想是行爲驅動開發（BDD），迴歸測試是其天然而然的副帶結果。你能夠簡單的理解爲Calabash-android 或 Calabash-iOS是在Cucumber上進行了一次擴展，從而能夠對Android或iOS進行自動化測試。

在解釋一下BDD，我從網絡摘了一段介紹：你能夠在Cucumber中編寫用戶場景，讓它表現出業務規則而不只僅是UI功能。這樣你就可以讓業務分析師加入這個過程，在編碼工做開始前編寫場景。程序員們就可以按照這個清晰的規範進行編碼工做了。這種方式就是行爲驅動開發（BDD）。

OK，關於BDD咱們就此打住，畢竟仍是很將來的事情，下面咱們聊點實在的。

Calabash與appium，Espresso相似，都是經過腳本去操做界面，做出點擊、滑動等操做，同時能夠對界面的上UI組件進行必定識別。run起來就是那麼回事，模擬控制手機。主要是腳本的編寫上不一樣，咱們來看一下Calabash的腳本，相信我，愛上它，就從看到它腳本開始：

Feature: Login feature

  Scenario: 登陸測試用例

  	When I press view with id "account_edit"
  	Then I enter "15104053650流量" into input field number 1

  	Then I press "發送驗證碼"
  	Then I wait for 5 seconds

  	When I press view with id "verifying_code_edit"
  	Then I enter "306423" into input field number 2

  	Then I wait for 5 seconds

  	Then I press view with id "login_login"

複製代碼

我以爲我不須要再解釋這腳本的含義了，這就是大白話！！ Calabash最大的魅力在於，將難以理解的編程語言轉換爲誰均可以看得懂得天然語言。從而下降學習門檻和維護難度。 特色1：極高的可讀性，可讀性越高的測試腳本，意義越大。當測試腳本的編寫先於或與開發同步時，測試腳本也能夠成爲開發過程當中的設計文檔及參考手冊。

在可讀性很是高的基礎上，其編寫難度也變得很是的低。特色2：語法簡單易懂，誰都能寫。

同時可喜的是，這個代碼同時支持Android 和iOS，web也有必定的支持！RN就更不用說了，跑起來的RN就是原生代碼！WEEX還要再考察考察~在合理的解耦與耦合的狀況下，Android 和iOS只需提供一套各自的View定位封裝便可共用一套場景case腳本。特色3：支持多種平臺，代碼複用性強。

一段使用天然語言編寫的腳本，其底層固然要費一番功夫。上面咱們看到一段測試用例是使用Calabash預約義的Steps寫的一段測試用例。

而這些大白話同樣的Steps的實質是這樣的：

Then /^I press "([^\"]*)"$/ do |identifier|  # ---方法名
  tap_when_element_exists("* marked:'#{identifier}'")  # ---方法體
end
複製代碼

很傻瓜的解釋一下：你能夠很簡單的認爲上面這一段是一個函數、一個方法。 第一行就是一個天然語言夾雜着正則符號的方法名，方法名隨便起。第二行是用Ruby實現的方法體。 不要被這段代碼嚇到，在大部分時候，你都不須要接觸到這些大白話的具體實現（Ruby語言），而是直接用大白話寫小做文就行了。 預約義的Steps確定不能知足咱們的需求，因此Calabash靈活的支持不一樣程度自定義steps，樣子大概就像上面那樣，你能夠簡單理解爲Calabash支持不一樣程度的，代碼到天然語言的轉換。最大程度的知足業務需求。 正是這種靈活的轉換方式，讓咱們有了更多的想象：

特色4：Steps的開發與腳本的開發解耦分離，下降入門門檻，容納更多的腳本開發人員 再簡單解釋一下：先讓一部分(實際狀況多是一個)人學起來，寫出一個個大白話似的Steps。再接納另外一部分人進來，好比其餘的開發或測試人員，甚至是產品經理！直接用這些大白話寫測試case，熟悉了以後有想法的話再去學自定義Steps。甚至產品都不須要學自定義Steps,給開發提需求好了，當你有一個很是豐富的Steps庫的時候，你所煩的無窮無盡的邊界case，不過就是全民小做文~

特色5：自定義語法糖 Steps的方法名定義徹底自由，在帶來可讀性提升的同時也下降了Steps的記憶和腳本編寫速度。但這其實徹底依賴於你定義的規範，你徹底能夠自定義一套符合大多數人習慣的語法糖，從而在保證可讀性的同時固化大部分指令格式，提升Steps的記憶和腳本編寫速度。

還有哦，若是你一直抱怨如今正在使用的某種語言的某個語法多麼的沒人性，使用體驗糟糕透頂！如今好了，作好開發一套屬於本身的語言的準備了嘛？

特色6：維護簡單，我不知道小做文維護起來有什麼難的~

特色7：case也有設計感，不在那麼枯燥 在加一個最起碼我以爲很興奮的特色，考慮複用的話，自定義的Steps就要考慮與業務的解耦問題了，有的要解耦有的卻要耦合一點。並且若是爲了最小程度修改代碼從而保證Android iOS在代碼上通用，Android和iOS的開發上就會有更多的交流，測試腳本的編寫也會有更通用的設計。這裏面就有設計的快感了。

特色8：除模擬事件之外，Calabash還支持各類hook，如App生命週期的hook

特色9：豐富的元素定位輔助方法。 App自動化測試一個廣泛的痛點就是元素定位，Calabash有很是多的元素定位輔助方法，且都較爲簡單且無腦。

最後咱們在看一個從網上摘下來的一段Calabash腳本：

Feature： 登錄

  Scenario： 輸入正確的用戶名密碼可以正常登錄

  When 打開登錄頁面
  And    輸入用戶名XXX輸入密碼XXX
  And   點擊登錄
  Then  驗證登錄成功

複製代碼

徹底純中文的腳本編寫有木有？是不看起來屌屌的~恩，雖然博主自身並不建議這樣純中文的step定義，咱們就看看，你只要知道Calabash很強大就好了。

最後咱們總結一下Calabash的大方向的優勢：

• 極高的可讀性
• 語法簡單易懂，學習門檻低
• 一種語言支持多種平臺，代碼複用性強
• Steps的開發與腳本的開發解耦分離，下降入門門檻，容納更多的開發
• 自定義語法糖
• 小做文維護簡單
• case也有設計感
• 除模擬事件之外，Calabash還支持各類hook，如App生命週期的hook
• 很是多的元素定位輔助方法
• 對代碼無侵入性，純黑盒測試。
• 用Calabash搭一個自有的雲測平臺可行性很高

這只是大方向的幾個優勢，文末會奉上Calabash的入門文章，更詳細的介紹Calabash的各類特性，利用這些特性，你會發現Calabash有太多的想象。

Calabash缺點

說了那麼多優勢，缺點固然也是有的啦~咱們吐槽一下

資料、Demo稀少

Calabash大概有五年以上的歷史，最先的first commit是2012年2月份，對於一個技術工具來講，這已經能夠算是很老了，但Calabash依然是一個小衆產品，而後致使的問題是資料很是很是少……官方Github只給了很簡單很基礎的API，還基本沒有Demo,(官方Demo就幾行代碼~)

資料少也意味着後面有不少坑須要本身往過趟，不過有了文末的入門教程，快速上手應該是沒問題啦~

我大膽的懷疑了一下Calabash小衆的緣由，可能大廠仍是更鐘愛appium這種主流測試框架，畢竟語法複雜也意味着功能強大，而小廠呢，相比起維護一套自動化測試框架，不如就手點點人工測試好了，因此Calabash這樣的，就處於一個很尷尬的位置了（這篇文章不就是讓你破解這種尷尬的嘛！）

不支持跨進程

Calabash底層是Robotium，Robotium不支持跨進程操做，因此Calabash也不支持。當你跳出當前測試App時，calabash便沒法響應並作任何操做了。 在個別須要跨進程調用業務較多的App中，這個點是很痛的，甚至基本上就能夠放棄Calabash了。

以蜂鳥衆包爲例，須要跨進程的業務有分享和拍照（拍照調用了系統相機），分享對於蜂鳥衆包來講是一個很邊界的業務，暫不討論，但拍照影響到了主流程。 不過若是修改拍照爲自定義相機，而是不調用系統相機的話，將不會存在這個問題，而且能夠解決不一樣手機系統相機樣式不一樣，腳本須要進行兼容的困擾。因此即便是爲了測試而對業務代碼作了這種程度的改動，也是值得的！

另外經過最近研究發現，**Calabash支持跨進程彷佛也是有但願的！**Espresso實現跨進程操做的方式是調用了uiautomator的API。而Calabash做爲開源項目，想要修改其源碼也是徹底OK的。 以Android爲例，其內部核心是經過java調用Robotium API實現的，因此咱們只要修改其源碼調用uiautomator的API便可實現跨進程。恩……實現思想是這樣的，只是不知道官方爲何沒有這樣去作，具體狀況還待研究……（2015年末以前Calabash相關的博客中能夠很容易的找到修改其源碼進行功能擴展的博客，但Calabash在2015年年末將Calabash的源碼抽離到了另外一個項目中，因此這些博客中提到方案便沒法使用了，後續的具體實現方式還待研究，詳情會在文末的教程中提到）

不夠嚴謹的天然語言

可能大部分人會對Calabash這樣的天然語言抱有懷疑，認爲Calabash這樣Cucumber風格的語言（就是上面的咱們看到的測試腳本）不夠嚴謹。沒法向代碼那樣簡練且規範嚴格，在某種程度也下降了編寫速度，且很是不夠嚴謹易錯度高！

首先要澄清一點的是，Java、Python等隸屬編程語言，而Cucumber風格的腳本更傾向因而一種描述性語言。他們是兩種不一樣的領域。

因此不能站在編程語言的角度去要求Cucumber風格的腳本的嚴謹程度，而「嚴謹」也不過是做爲編程人員的一種慣性思惟。

而從記憶與編寫速度考慮，還記得咱們上面曾說到的語法糖嗎？不恰當的定義Steps確實會致使這樣的問題。舉個例子吧

#我跳過歡迎界面
Then I skip welcome page
#我完成登陸操做
Then I have finished the login
複製代碼

上面是兩個濫用天然語言特性的自定義操做。若是你的全部測試腳本都是這樣寫的，雖然讀起來沒有問題，但寫起來就徹底離不開文檔了。下面看一下較爲建議的寫法：

#我跳過歡迎界面
Then I pass "welcome" scenario
#我完成登陸操做
Then I pass "login" scenario
複製代碼

兩個Steps的實際含義其實僅只是直接經過某種操做，若是咱們規範的定義適合本身的語法糖，很是雜亂的腳本將變得頗有規律可循，保證可讀性的同時你只需記住幾個特定的指令，從而提升腳本編寫速度。

固然，確實是由於Calabash過於寬鬆的語法，致使這個致命的缺點須要經過嚴格的管理進行約束，稍有不慎會埋有禍根。因此這確實是Calabash的缺點之一。

End

最後，雖然我我的建議使用Calabash，但對於小微團隊，合適的纔是最好的！ 資源緊張狀況下想要實行自動化測試，個人建議是在提升人效的基礎上調動更多的人力來分攤壓力。那麼這對低學習門檻和低推廣成本的要求就會很高，因此學習門檻和推廣成本應該是你選擇自動化工具最須要考察的點。

正是由於Calabash的特性很是契合這兩點，我纔會極力推薦，同時若是你想在將來的某一天嘗試一下BDD這種思想，或者想讓產品經理參與到這個環節作一些嘗試，一樣是很是建議使用Calabash的。固然若是你有較爲寬鬆的資源、或者追求更加工程化的自動化測試，還能夠選擇Appium這樣主流的測試工具。仍是那句話：合適的纔是最好的！

最後，奉上Calabash的入門博客：

---

《Calabash探索1-Run Calabash》

《Calabash探索2-Calabash用法詳解》

《Calabash探索3-Calabash進階》

《Calabash探索4-Calabash踩坑總結》