在手機(jī)應(yīng)用項(xiàng)目中建立符合持續(xù)交付的高標(biāo)準(zhǔn)自動(dòng)化測(cè)試

在手機(jī)應(yīng)用項(xiàng)目中建立符合持續(xù)交付的高標(biāo)準(zhǔn)自動(dòng)化測(cè)試Pleasenote:?

Thecontent

inthisslidesonlyrepresents

theviewoftheauthor,

notIBM.?

Therecommendedtechnical

solutionspresented

inthisslidesare

notguaranteed,

andtheauthororIBMtakes

noresponsibilityunderanycircumstances.持續(xù)交付https://www.thoughtwo/continuous-delivery自動(dòng)化在持續(xù)交付中的關(guān)鍵角色版本控制顧客反饋商業(yè)決策:何時(shí)交付部署至production環(huán)境持續(xù)整合建置PProvisio發(fā)布至測(cè)試環(huán)境發(fā)布至staging環(huán)境持續(xù)測(cè)試(自動(dòng)化)ProvisionProvision執(zhí)行測(cè)試并發(fā)布報(bào)告重點(diǎn)是隨時(shí)保持在能交付的狀態(tài)持續(xù)交付與傳統(tǒng)自動(dòng)化測(cè)試的區(qū)別?

傳統(tǒng)自動(dòng)化:?

一天跑一次，甚至兩三天才跑一次?

失敗了沒關(guān)系?

很多自動(dòng)化測(cè)試甚至是已經(jīng)處于每次跑必定失敗的狀況，長達(dá)一年以上?

通常不太在意代碼質(zhì)量跟架構(gòu)，甚至有不少的團(tuán)隊(duì)使用錄制工具建立測(cè)試?

不太在意測(cè)試覆蓋率，低于30%是非常常見的狀況?

跑很久無所謂，因?yàn)橐惶觳排芤淮纬掷m(xù)交付與傳統(tǒng)自動(dòng)化測(cè)試的區(qū)別?

持續(xù)交付自動(dòng)化?

一天跑十次甚至幾十次?

不允許非bug造成的失敗?

需要高覆蓋率，80%以上是基本要求?

需要以對(duì)待產(chǎn)品代碼級(jí)別的標(biāo)準(zhǔn)來要求代碼質(zhì)量與架構(gòu)?

需要在短時(shí)間內(nèi)結(jié)束?

真的失敗需要在短時(shí)間內(nèi)快速找出問題點(diǎn)?

測(cè)試報(bào)告的完整度與質(zhì)量非常重要持續(xù)交付自動(dòng)化的挑戰(zhàn)?

夠快?

非常穩(wěn)定?

失敗時(shí)能快速精準(zhǔn)找出問題要多快??

Build+UnitTest不能超過15分鐘，最好在十分鐘以內(nèi)?

AcceptanceTest最好在30分鐘以內(nèi)，最多不超過60~90分鐘要多穩(wěn)定??

1%失敗率很穩(wěn)定嗎??

假設(shè)每一個(gè)test

case有1%概率由非bug問題造成失敗?

100個(gè)test

case的test

suite跑一次完全沒失敗的概率是0.99^100=36%?

1000個(gè)test

case呢?幾乎每次都至少會(huì)有一個(gè)test

case失敗?

持續(xù)交付要求的穩(wěn)定是”完全不會(huì)因?yàn)榉莃ug問題失敗”?

事實(shí)上很難做到?

但至少每一個(gè)test

case非bug造成失敗率不能大于百萬分之一要能多快找出問題??

假設(shè)一天八小時(shí)內(nèi)跑十次，每次跑40分鐘?

每次跑的間隔平均是8*60/10=48分鐘?

所以如果失敗，只有8分鐘在下一次code

checkin之前找出問題?

或是一旦失敗就鎖死source

control不讓codecheckin，直到問題解決或是roll

back?

無論采取哪一種方法，找出問題都是分秒必爭(zhēng)有可能做到嗎??

夠快?

非常穩(wěn)定?

失敗時(shí)能快速精準(zhǔn)找出問題光是做到一項(xiàng)就是很大挑戰(zhàn)，何況是全部解決方法?

挑戰(zhàn)顯然是巨大的，因此解決方法也不可能只采用單一手段?

戰(zhàn)略面跟戰(zhàn)術(shù)面都必須要有各種方法，多管齊下戰(zhàn)略面?

最重要第一點(diǎn)，自動(dòng)化測(cè)試策略的制定?

戰(zhàn)略面一開始就錯(cuò)了，戰(zhàn)術(shù)面再怎么強(qiáng)還是全盤皆輸戰(zhàn)略面?

組織，流程與文化?

開發(fā)團(tuán)隊(duì)寫自動(dòng)化測(cè)試?

很多公司直接要求現(xiàn)有的手動(dòng)測(cè)試團(tuán)隊(duì)負(fù)責(zé)開發(fā)自動(dòng)化測(cè)試?

自動(dòng)化測(cè)試質(zhì)量是否高，跟產(chǎn)品代碼的可測(cè)試性關(guān)聯(lián)也很高?

新的story無法馬上就有自動(dòng)化測(cè)試，而是要等幾星期到幾個(gè)月?

術(shù)業(yè)有專攻,寫好代碼不是幾星期就能會(huì)的事?

Wholeteamapproach?

測(cè)試團(tuán)隊(duì)負(fù)責(zé)手動(dòng)測(cè)試，測(cè)試案例review與工具平臺(tái)開發(fā)維護(hù)?

以對(duì)待production代碼的態(tài)度對(duì)待自動(dòng)化測(cè)試代碼戰(zhàn)略面?

流程上必須要確保pipeline紀(jì)律的嚴(yán)格執(zhí)行?

就算有全世界最好的自動(dòng)化測(cè)試，沒人看沒人用的話也只是廢物?

測(cè)試失敗必須立刻解決非常重要?

文化?

持續(xù)改進(jìn)的文化?

維持持續(xù)交付pipeline的決心戰(zhàn)略面:Behavior-DrivenDevelopment?

Project

Manager與其他主管最常問的問題:我們自動(dòng)化測(cè)試有哪些，覆蓋的哪些scenarios??

請(qǐng)他們?nèi)タ创a?行不通?

解決方案:Automationasdocument戰(zhàn)略面?

工欲善其事，必先利其器?

年年都有新的測(cè)試工具，因此要時(shí)時(shí)更新知識(shí)?

測(cè)試工具最好要能?

自動(dòng)處理UI的延遲，讓測(cè)試代碼中不需要寫sleep?

簡(jiǎn)單易懂?

夠穩(wěn)定?

夠快?

官方支持優(yōu)先，其次才考慮開源第三方軟件?

當(dāng)官方版很差時(shí)，沒別的選擇只能用開源第三方軟件?

但一旦官方版達(dá)到一定水平以上，開源軟件就可以功成身退了?

Android就用Espresso，iOS就用XcodeUITest?

Espresso出來，Robotium就再見了。XcodeUITest出來，KIF就被淘汰了。戰(zhàn)略面:寫Test

Case的大原則?

非到萬不得已，絕對(duì)不寫sleep?

Sleep是不穩(wěn)定測(cè)試的最大來源?

Callback->PeriodicPoll->Sleep?

每個(gè)Test

Case必須能獨(dú)立執(zhí)行，不依賴其他TestCase幫它設(shè)定環(huán)境，也不影響其它Test

Case?

避免過度復(fù)雜的測(cè)試代碼?

雖然說要用產(chǎn)品代碼級(jí)別要求代碼質(zhì)量，但還是稍有不同，如何拿捏很重要?

避免復(fù)雜類別架構(gòu)，if/else與switch?

使用viewid或是accessibilitylabel/id定位view?

字符串會(huì)變?

坐標(biāo)更容易變戰(zhàn)略面:Page

ObjectPattern?

Proposedby

MartinFowler?

Picture

from

Roger

Almeida’s

blog:http://roger-almeida.blogspot.tw/2012/01/object-pattern-webdriver-spring.html戰(zhàn)略面:限制測(cè)試Scope?

UnitTest只應(yīng)該測(cè)試單一method?

不連網(wǎng)?

不連數(shù)據(jù)庫?

不調(diào)用任何硬件功能如GPS，震動(dòng)等等?

Mock第三方軟件或是OSAPI的調(diào)用?

Acceptancetest應(yīng)該只測(cè)試單一component?

不是integration

test?

Client或是Server，而不是endto

end?

Mockclient或mockserver?

或是把client跟server放在同一臺(tái)機(jī)器上戰(zhàn)術(shù)面:避免Runtime決定測(cè)試路徑?

怎么處理這問題??

If(waitfor(menuexists)){click(“ViewResults”);}?

這樣做對(duì)嗎??

我們是不是忘了一件事??

在寫測(cè)試案例時(shí),我們肯定知道這時(shí)候它會(huì)走哪條路?

既然如此何必runtime判斷?

takeSurvey(StringsurveyName,booleanmenuWillPopup){…..If(menuWillPopup){click(“ViewResults”);}}戰(zhàn)術(shù)面:Incremental

Periodic

Poll戰(zhàn)術(shù)面:即使是UI測(cè)試，還是要盡量減少UI動(dòng)作?

假設(shè)以下測(cè)試案例，測(cè)試目標(biāo)為一cloud同步服務(wù)?

上傳一文檔

->編輯文檔描述

->將文檔與另一人共享->上傳同一文檔的更新

->刪除文檔?

測(cè)試案例2?

上傳一文檔

->在文檔上留言

->將文檔公開給所有人看

->刪除文檔?

同樣的動(dòng)作，只需要在UI測(cè)試一次就夠了?

第二個(gè)以后的測(cè)試案例，測(cè)試過的步驟都透過API執(zhí)行戰(zhàn)術(shù)面:跳過已經(jīng)被其他測(cè)試案例測(cè)試過的步驟?

假設(shè)以下測(cè)試步驟,目的為測(cè)試購物網(wǎng)站是否能正確使用信用卡付款?

登入在線購物網(wǎng)站

->尋找商品

->找到商品,確認(rèn)數(shù)量,放入購物車,結(jié)賬

->輸入地址電話

->選擇以信用卡付款

->付款

->確認(rèn)付款完成?

同樣的購物網(wǎng)站可能有數(shù)百個(gè)測(cè)試案例,前面幾步都完全一樣?

手動(dòng)測(cè)試沒有別的方法準(zhǔn)備測(cè)試數(shù)據(jù)?

但自動(dòng)化測(cè)試中,我們有別的選擇?

用API或是直接callproductioncode產(chǎn)生我們要的測(cè)試數(shù)據(jù)戰(zhàn)術(shù)面:對(duì)付工具的不穩(wěn)定?

測(cè)試工具也是人寫的軟件，也會(huì)有bug?

等測(cè)試工具沒問題才開始自動(dòng)化測(cè)試?那永遠(yuǎn)都不會(huì)開始?

手機(jī)上常見的測(cè)試工具bug?

點(diǎn)不準(zhǔn)?

點(diǎn)了沒作用?

動(dòng)畫導(dǎo)致時(shí)間差?

長按變短按,短按變長按?

滑動(dòng)失敗?

解決方法?

重試?

還原后重試?

關(guān)掉動(dòng)畫重試測(cè)試步驟?

Espresso的重試?

自己寫的重試重試測(cè)試步驟?

或是直接將這些代碼包裝成一個(gè)genericmethod戰(zhàn)術(shù)面:詳細(xì)的測(cè)試報(bào)告?

測(cè)試失敗時(shí)只有幾分鐘時(shí)間找出問題?

報(bào)告應(yīng)該要有?

BDD中每一步的描述?

每一步之下細(xì)項(xiàng)動(dòng)作的記錄?

更細(xì)的UIlifecycle記錄,如Espresso中的activitylifecycle如果是UI測(cè)試:失敗測(cè)試的屏幕截圖,最好有完整的videoreplay?

報(bào)告要能分component列表,讓人一眼就看出失敗出在哪個(gè)component?

常見的反應(yīng)?

測(cè)試能跑就好,為什么要我寫一堆Log??

為什么還要規(guī)定Log的規(guī)范,會(huì)不會(huì)太麻煩?持續(xù)改進(jìn)?

跟所有Agilepractice一樣,持續(xù)交付的自動(dòng)化測(cè)試永遠(yuǎn)可以有改進(jìn)空間?

如同對(duì)待production代碼一樣的對(duì)待自動(dòng)化測(cè)試代碼,持續(xù)改進(jìn)它,才是最重要的?

只有使用技術(shù)跟工具，而沒有將持續(xù)改進(jìn)的文化深植到團(tuán)隊(duì)中，只能事倍功半??CopyrightIBMCorporation2016.Allrightsreserved.Theinformationcontained

inthesematerialsisprovidedfor

informationalpurposesonly,

andisprovidedASISwithoutwarranty

ofany

kind,express

orimplied.

Any

statement

ofdirectionrepresentsIBM'scurrentintent,

issubjectto

changeorwithdrawal,andrepresentonlygoalsandobjectives.

IBM,theIBMlogo,

andotherIBMproductsandservicesaretrademarksoftheInternationalBusinessMachinesCorporation,intheUnitedStates,othercountriesorboth.Othercompany,

product,orservicenamesmay

betrademarksorservicemarksofothers.?Statement

ofGoodSecurityPractices:ITsystem

securityinvolves

protectingsystemsandinformationthroughprevention,detectionandresponseto

improperaccessfromwithinandoutsideyourenterprise.Improperaccesscanresultininformationbeingaltered,destroyed,

misappropriatedormisusedorcanresultindamageto

ormisuseofyoursystems,

includingfor

usein