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