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

Thecontent

inthisslidesonlyrepresents

theviewoftheauthor,

notIBM.?

Therecommendedtechnical

solutionspresented

inthisslidesare

notguaranteed,

andtheauthororIBMtakes

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

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

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

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

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

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

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

跑很久無所謂，因為一天才跑一次持續(xù)交付與傳統(tǒng)自動化測試的區(qū)別?

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

一天跑十次甚至幾十次?

不允許非bug造成的失敗?

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

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

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

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

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

夠快?

非常穩(wěn)定?

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

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

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

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

假設(shè)每一個test

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

100個test

case的test

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

1000個test

case呢?幾乎每次都至少會有一個test

case失敗?

持續(xù)交付要求的穩(wěn)定是”完全不會因為非bug問題失敗”?

事實上很難做到?

但至少每一個test

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

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

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

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

checkin之前找出問題?

或是一旦失敗就鎖死source

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

back?

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

夠快?

非常穩(wěn)定?

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

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

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

最重要第一點，自動化測試策略的制定?

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

組織，流程與文化?

開發(fā)團隊寫自動化測試?

很多公司直接要求現(xiàn)有的手動測試團隊負(fù)責(zé)開發(fā)自動化測試?

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

新的story無法馬上就有自動化測試，而是要等幾星期到幾個月?

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

Wholeteamapproach?

測試團隊負(fù)責(zé)手動測試，測試案例review與工具平臺開發(fā)維護?

以對待production代碼的態(tài)度對待自動化測試代碼戰(zhàn)略面?

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

就算有全世界最好的自動化測試，沒人看沒人用的話也只是廢物?

測試失敗必須立刻解決非常重要?

文化?

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

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

Project

Manager與其他主管最常問的問題:我們自動化測試有哪些，覆蓋的哪些scenarios??

請他們?nèi)タ创a?行不通?

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

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

年年都有新的測試工具，因此要時時更新知識?

測試工具最好要能?

自動處理UI的延遲，讓測試代碼中不需要寫sleep?

簡單易懂?

夠穩(wěn)定?

夠快?

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

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

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

Android就用Espresso，iOS就用XcodeUITest?

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

Case的大原則?

非到萬不得已，絕對不寫sleep?

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

Callback->PeriodicPoll->Sleep?

每個Test

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

Case?

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

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

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

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

字符串會變?

坐標(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)略面:限制測試Scope?

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

不連網(wǎng)?

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

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

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

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

不是integration

test?

Client或是Server，而不是endto

end?

Mockclient或mockserver?

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

怎么處理這問題??

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

這樣做對嗎??

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

在寫測試案例時,我們肯定知道這時候它會走哪條路?

既然如此何必runtime判斷?

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

Periodic

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

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

上傳一文檔

->編輯文檔描述

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

->刪除文檔?

測試案例2?

上傳一文檔

->在文檔上留言

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

->刪除文檔?

同樣的動作，只需要在UI測試一次就夠了?

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

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

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

->尋找商品

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

->輸入地址電話

->選擇以信用卡付款

->付款

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

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

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

但自動化測試中,我們有別的選擇?

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

測試工具也是人寫的軟件，也會有bug?

等測試工具沒問題才開始自動化測試?那永遠都不會開始?

手機上常見的測試工具bug?

點不準(zhǔn)?

點了沒作用?

動畫導(dǎo)致時間差?

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

滑動失敗?

解決方法?

重試?

還原后重試?

關(guān)掉動畫重試測試步驟?

Espresso的重試?

自己寫的重試重試測試步驟?

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

測試失敗時只有幾分鐘時間找出問題?

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

BDD中每一步的描述?

每一步之下細(xì)項動作的記錄?

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

報告要能分component列表,讓人一眼就看出失敗出在哪個component?

常見的反應(yīng)?

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

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

跟所有Agilepractice一樣,持續(xù)交付的自動化測試永遠可以有改進空間?

如同對待production代碼一樣的對待自動化測試代碼,持續(xù)改進它,才是最重要的?

只有使用技術(shù)跟工具，而沒有將持續(xù)改進的文化深植到團隊中，只能事倍功半??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