項(xiàng)目從2009年開始啟動(dòng)，采用的是TDD的開發(fā)方式。在這之后的過程中，團(tuán)隊(duì)做過各種嘗試去調(diào)整自動(dòng)化測試的策略去更好的適應(yīng)不同階段項(xiàng)目的特征，比如調(diào)整不同類型測試的比例，引入新的測試類型等。
七年之癢 - 痛點(diǎn)
隨著項(xiàng)目走到了第七個(gè)年頭，一系列的變化在不斷發(fā)生，比如技術(shù)上引入了微服務(wù)、EventStore等，業(yè)務(wù)變得越來越復(fù)雜，子系統(tǒng)變得更多，更多的人員加入，開始實(shí)施按月發(fā)布等，這些因素交織在一起凸顯出自動(dòng)化測試的滯后。首先是從團(tuán)隊(duì)成員感知到的一些痛點(diǎn)開始的：
- 質(zhì)量下降 - 這個(gè)體現(xiàn)在部署到測試環(huán)境的代碼質(zhì)量較差，常常就是新版本部署上去之后某個(gè)核心功能被破壞，要么是新功能破壞了老功能，要么是bug的修復(fù)把其他功能破壞。
- 測試不穩(wěn)定 - QA有很長的時(shí)間在等待修復(fù)或新功能提交出包，而這個(gè)等待可能是幾個(gè)小時(shí)也有可能是幾天。除去網(wǎng)絡(luò)問題、部署流水線的復(fù)雜性等因素，自動(dòng)化測試的不穩(wěn)定性也導(dǎo)致出包的速度也受到了影響。大家往往更關(guān)注于怎么能把測試通過了能夠出一個(gè)包，而卻忽略了我們該怎么去處理一個(gè)不穩(wěn)定的測試。下圖的run2, run3正是大家在不斷的嘗試去rerun掛掉的測試。
- 團(tuán)隊(duì)越來越忙，開始陷入惡性循環(huán) - 隨著功能的逐漸增多，每個(gè)月上線的回歸測試列表越來越長，QA需要花更多的時(shí)間去做重復(fù)的回歸測試，新功能的測試和回歸測試的壓力都很大，甚至有的時(shí)候根本都沒有時(shí)間去review下一個(gè)階段的需求，更別提其他一些更有價(jià)值的事情。往往回歸測試做不完就不得不往下一個(gè)階段推，這種不斷往復(fù)導(dǎo)致大家對發(fā)布的產(chǎn)品信心嚴(yán)重不足。
在這種情況下，自動(dòng)化測試的有效性和完備性都受到了質(zhì)疑。本來期望自動(dòng)化測試能夠幫助我們構(gòu)建一張安全的防護(hù)網(wǎng)，保證主干業(yè)務(wù)不被破壞；隨著pipeline頻繁的去執(zhí)行，及時(shí)反饋問題，不要等到測試環(huán)境才暴露出來；同時(shí)能夠把QA重復(fù)的手工測試時(shí)間釋放出來，去做一些更有價(jià)值的事?？墒歉鶕?jù)團(tuán)隊(duì)所感受到的痛點(diǎn)，我們覺得自動(dòng)化測試已經(jīng)不僅沒有幫助我們，反而卻在一定程度上給團(tuán)隊(duì)帶來了干擾。
問題分析
自動(dòng)化測試到底出了什么問題？我們從現(xiàn)有UI測試入手開始分析，發(fā)現(xiàn)了以下典型現(xiàn)象：
最有價(jià)值的場景沒有被覆蓋
雖然有較多的測試場景，但是體現(xiàn)出核心業(yè)務(wù)價(jià)值的場景卻稀少。我們都知道80/20原則，用戶80%的時(shí)間在使用系統(tǒng)中20%的功能，如果大部分的UI測試是在測另外那80%的功能，這樣一個(gè)覆蓋給團(tuán)隊(duì)帶來的安全指數(shù)是很低的。
失效的場景
相關(guān)廠商內(nèi)容
《不一樣的技術(shù)創(chuàng)新》-阿里巴巴雙11背后的技術(shù)
杭州免費(fèi)沙龍：從技術(shù)實(shí)踐看如何提升企業(yè)研發(fā)效能
阿里專家現(xiàn)場分享如何提升企業(yè)研發(fā)效能？
看明略任鑫琦如何談關(guān)系挖掘算法
如何通過使用 AWS對IT資源實(shí)現(xiàn)高級(jí)別管控，并大規(guī)模實(shí)現(xiàn)更高級(jí)別的安全性？
功能已經(jīng)發(fā)生了變化，可是對應(yīng)的UI測試并沒有變，至于它為什么沒有掛掉，可能有一些僥幸的因素。比如現(xiàn)在點(diǎn)了確認(rèn)按鈕之后新增了彈窗，而測試并沒有關(guān)掉彈窗，而是通過URL跳轉(zhuǎn)到了別的頁面，也沒有驗(yàn)證彈窗的新功能是否工作，既有的實(shí)現(xiàn)方式確實(shí)會(huì)使得測試一直通過，但是沒有真的驗(yàn)證到正確的點(diǎn)。
重復(fù)的測試
同樣的測試在UI層跟API層的重合度較高，有的甚至是100%。比如搜索用戶的功能，分別去按照姓、名、姓的一部分、名的一部分、姓?名等等各種組合去驗(yàn)證。我們不太清楚在當(dāng)時(shí)是基于怎樣的考慮留下了這么多跟UT/API測試重復(fù)的用例，但是在現(xiàn)階段分析之后我們覺得這是一種沒必要的浪費(fèi)。
另外，不同的測試數(shù)據(jù)準(zhǔn)備都是UI測試執(zhí)行出來的，很多場景都用到了相同的步驟，我們覺得這也是一種重復(fù)，可以通過其他方式來實(shí)現(xiàn)。
解決問題
這些問題從某種角度上都暴露出了UI測試年久失修，沒有得到好的維護(hù)，而新功能的自動(dòng)化測試又在不斷重蹈覆轍，問題積攢到一起暴發(fā)出來使得大家開始重視自動(dòng)化測試。