Parag Kulkarni自2008年在印度SQS擔任測試自動化團隊的一名核心成員。他專攻使用各種工具的自動化。他的核心競爭力包括自動化框架設計和移動自動化。過去的八年，他廣泛涉及了CRM，出版，銀行和電信領域。
如今金融機構使用多渠道方法服務其顧客，且越來越多地都開始使用移動技術了。為金融服務業(yè)的顧客服務需要高度可靠的基層軟件。與顧客期望同步的需要，發(fā)布周期短暫且需要提供高質量的軟件等都是開發(fā)移動軟件中的難題——尤其像在app商店中，質量差的一眼看出來了且對銀行的聲譽有所影響。所以，測試尤其是回歸測試是app開發(fā)中重要的工作之一。但是如果不給你的顧客“銀行標準智能機”，你該如何滿足這些期望呢？使用多平臺方法的移動測試自動化是應對該挑戰(zhàn)的一個方法。本文中，我們將為你展示我們成功使用了該方法的一個實例項目的細節(jié)。
項目內容
一家奧地利銀行正在尋找移動自動化解決方案以在多個平臺（如Android和ios）上測試他們的多個app。他們也想很好地覆蓋其顧客們常使用的手機和平板�；谠撔畔�，我們想出了一個顧客移動測試策略來回答下列問題：
--必須要測試哪種app？
--必須要覆蓋哪些設備類型和型號？
--必須要覆蓋多少測試用例？
--迄今回歸測試發(fā)揮了多少作用——該作用如何作用于該項目的框架的？
我們的任務是實驗覆蓋了兩種app的移動測試自動化。第一種：web app，必須在手機或平板上測試，Android和iOS都要測試。第二種：混合型app，再次在Android和iOS上測試，要在四臺手機和四臺平板上測試。為什么會有這樣的區(qū)別？web app只依賴于web瀏覽器；而混合型app要考慮基礎系統(tǒng)的更多功能，因此它需要在更多的設備模型上更徹底地測試。設備是根據(jù)顧客對其所使用設備的分析而選擇的。
挑戰(zhàn)
我們正在進行擁有60個測試用例的回歸測試，其三分之二覆蓋了web app，剩下的三分之一覆蓋了混合型app�；貧w測試一年執(zhí)行四次，即，2種app，60個測試用例，1年4次。但單單如此并不是說你一開始要將這些測試用例自動化；它也可能表示完全相反的意思——堅持手動，進行群體測試——如果沒有下面幾個“但是”的話：
1.我們講的是銀行。銀行不熱衷將其測試外包到云或群體。一個測試服務供應商足夠了。
2.只覆蓋了60個測試用例的實驗一個季度進行一次——但它只是一個實驗�？傊�，我們將可以重復使用我們十多個app的測試代碼�？芍貜褪褂煤苤匾�！
至于所覆蓋的技術，我們必須在ios和Android平臺上測試app——當然，要用劃算的方法。
計劃
進行實驗不僅僅意味著將測試自動化。它還意味著進行一次精心研發(fā)的實驗，其結果將為長達一年的成功的測試自動化構建基礎。因此，在整個項目中我們的項目計劃有接下來的四個階段：
工具選擇是重要的理論步驟，挑選一個或幾個候選工具進行一次多因素的分析。第二階段是為特定項目或顧客選擇合適的工具并作出實際評價，設置和首次概念驗證。證明了技術上工具能夠用于項目中的話，進行實際自動化是為了試驗。只有在首次概念驗證中覆蓋了測試用例的選擇，自動化階段才能覆蓋完整的測試用例集。自動化意味著軟件工程，并不存在沒有測試的軟件工程（至少應該如此），所以自動化階段覆蓋了第一輪自動化測試用例的執(zhí)行。后一步終于可以證明該方法是否對管理服務方法有效，需要使軟件測試工業(yè)化，即用可預見方式使之變得標準且可執(zhí)行。
我們將七個預選工具縮小到（理論上）完全滿足顧客需求的一個。為了實踐證明理論，我們取60個測試用例中的9個代表，設置測試環(huán)境并進行概念驗證（PoC）。不論設置工作，常常，部分顧客背景下的概念驗證是一個要花上不少時間的實驗。你可以輕易地看見PoC的學習效果：沒必要進行第二次環(huán)境設置，有了PoC的實驗，我們可以輕松地從3周9個測試用例增加到4周60個。終這是實際項目中的自動化速度。實驗的后四周都被濃縮成標準的一周測試周期。
實施
實驗階段開始時我們有七個候選工具，我們終決定使用Calabash。Calabash是一個基于行為驅動開發(fā)（BDD）想法的開源測試框架。BDD將實際功能測試工作脫離了“代碼背后”。這樣可以將測試工作分給以下兩者：
--領域專家（SME）：SMEs很了解app的功能，但是多數(shù)情況下基本不了解代碼。
--測試自動化專家（TAE）：TAEs很了解代碼，但是多數(shù)情況下對app的預期行為了解的要少很多。
有了BDD工具，領域專家可以確定人類可讀形式的測試用例的功能。這樣一個“故事”擁有如下形式：
