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