提到敏捷交付，我們總會說到持續(xù)集成，持續(xù)交付，持續(xù)發(fā)布，即頻繁地交付產(chǎn)品特性。而我們都知道要實現(xiàn)真正的持續(xù)交付，必然少不了兩個關(guān)鍵要素：

• 持續(xù)集成工具
• 自動化測試 ， 自動化的產(chǎn)品質(zhì)量反饋機制

只有測試不行，只有集成工具也不行，二者需合二為一，保持相同的步調(diào)，實現(xiàn)持續(xù)不斷的質(zhì)量反饋，方能實現(xiàn)保質(zhì)地持續(xù)發(fā)布。

自動化測試不只自動化工具

可以開門見山地說：Automation Test ≠ Automation Tools ≠ Continuous Test

根據(jù)我個人的項目經(jīng)驗，試著畫了下面這個圖來表達這三者的關(guān)系。

在提及自動化測試的時候，很多人會把工具的使用等同于自動化測試。自動化測試應(yīng)該是一個策略性的系統(tǒng)工程，不只有自動化工具。像我們的產(chǎn)品一樣，不僅要有技術(shù)語言，還要有產(chǎn)品架構(gòu)設(shè)計。自動化測試除了工具框架，還需要考慮：

項目的技術(shù)棧，產(chǎn)品架構(gòu)，開發(fā)流程，基礎(chǔ)設(shè)施，可靠的測試數(shù)據(jù)，穩(wěn)定干凈的測試環(huán)境，如何呈現(xiàn)測試報告，如何工程化測試配置，測試套件等等。

有了自動化測試還不夠，我們的目的是在持續(xù)交付的過程中實現(xiàn)快速頻繁的質(zhì)量反饋，我們需要持續(xù)不斷地測試（Continous Testing)。實現(xiàn)持續(xù)測試，不僅需要團隊從文化上去支持，真正做到全員對測試和質(zhì)量負責(zé)，創(chuàng)建Devops文化氛圍，打通開發(fā)-測試-運維的壁壘；還需團隊從技術(shù)上去儲備知識，比如云平臺、虛擬化技術(shù)，容器及相應(yīng)的編排技術(shù)，甚至網(wǎng)絡(luò)知識等等。

維基百科對自動化的解釋：

In software testing, test automation is the use of software separate from the software being tested to control the execution of tests and the comparison of actual outcomes with predicted outcomes.

從定義可以總結(jié)出自動化測試的兩個特點：

• 自動化測試本身也是軟件
• 自動化測試基于預(yù)期結(jié)果進行斷言

測試，質(zhì)量評估的重要手段之一，而自動化測試只是測試的一種具體實現(xiàn)方式而已。它能釋放QA的雙手和一部分大腦（這部分大腦，即know knowns），將對已知特性和既定邏輯流程的檢測交由計算機來完成。而QA去做更多需要思辨能力，分析判斷能力的事情。例如，通過向團隊提問，來澄清需求的unknowns；通過探索產(chǎn)品去拓寬對產(chǎn)品的knowns；抑或運用經(jīng)驗幫助團隊走出Unknown Unknowns 帶來的迷局。

維基百科對持續(xù)測試的解釋：

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.

從這個定義可以看出，持續(xù)測試的目的即在軟件交付的流水線中執(zhí)行自動化測試以提供對產(chǎn)品質(zhì)量的反饋。

想強調(diào)定義里的幾個關(guān)鍵字：automated tests, delivery pipeline, immediate feedback, business risks.

• automated tests 而不是automated test，一個產(chǎn)品只有一種，或者某一層級上的自動化測試是無法達到整體質(zhì)量評估的，持續(xù)測試需要不同類型的自動化測試在交付的不同階段為產(chǎn)品的不同層級提供反饋。
• delivery pipeline，immediate feedback，自動化測試一定是和交付流水線交合集成的，至少是同頻運行的，不是孤立的，只有這樣才能就團隊每一次的新變更對產(chǎn)品質(zhì)量的影響做出快速而及時的反饋。
• business risks，持續(xù)測試廣義上來說包含交付中的所有質(zhì)量反饋行為，既要測試左移，質(zhì)量內(nèi)建，也要測試右移，實現(xiàn)產(chǎn)品質(zhì)量主動監(jiān)控，不然無法識別業(yè)務(wù)風(fēng)險。

測試工具的選擇需要考慮項目的技術(shù)棧，也需要考慮QA自身的技術(shù)能力。

不管多火的工具，如果不能兼容項目的技術(shù)棧和基礎(chǔ)設(shè)施，那都無處發(fā)揮其優(yōu)勢，流行的不一定是適合項目的。

在寫自動化之前，QA需要對項目的技術(shù)棧，開發(fā)流程，和基礎(chǔ)設(shè)施有基本的認識和了解；另外也需要了解和掌握各個工具之間的優(yōu)劣，這樣才能為項目選擇最匹配的自動化工具。是不是像老生常談？但是別人告訴你的經(jīng)驗和自己經(jīng)歷的實戰(zhàn)真的兩種不同的收獲。就跟蹲家看電視和去現(xiàn)場看演唱會的區(qū)別一樣，別人的經(jīng)驗之談總歸是別人的，自己走過的路才是自己的。

這兩年Cypress真的很火，去年在項目上做UI自動化測試的時候，出于好奇也想實踐一把。實踐出真知，Cypress本身可以通過環(huán)境變量和plugin配置代理，但是不支持socks5的代理（客觀現(xiàn)狀是項目所有資產(chǎn)，包括測試環(huán)境都是通過socks5的代理連接），線上環(huán)境無法訪問。當(dāng)時還試過將socks5的代理轉(zhuǎn)換成http代理，但因為Cypress本身是多線程的，而socks5只能截獲第一個進程的網(wǎng)絡(luò)通信， 即使能連通應(yīng)用本身，Cypress也無法將測試過程可視化的優(yōu)勢發(fā)揮出來。人無完人，工具也一樣，只有適合你的才是好的。

考慮自己也不會造輪子，喜歡拿來就用，加之項目上socks5代理約束，之后便轉(zhuǎn)用了CodeceptJS, 幾次嘗試下來，覺得非常滿足項目需要。下面羅列CodeceptJS 幾個好用的點，具體細節(jié)請移步官網(wǎng)。

• 支持不同的helper: WebDriver, Puppeteer, Protractor, Nightmare, Testcafe， 我在項目上選用的是Puppeteer。
• 支持web也支持mobile，當(dāng)時項目上的第一個產(chǎn)品是有手機端版本的， 這也是選擇這個工具的一個考慮。
• 封裝良好的頁面元素操作方法，拿來即用，對于不擅長編碼的我來說，非常友好。
• 因為項目產(chǎn)品是和礦場上爆破緊密相關(guān)的，很多產(chǎn)品都有礦場地圖展示和設(shè)備可視化，CodeceptJS 提供了現(xiàn)成的codeceptjs-resemblehelper以實現(xiàn)視覺上的回歸測試。
• 最近發(fā)現(xiàn)它還支持API測試，包括REST和GraphQL的， 但是這部分特性尚未實踐。

由于團隊有完全的自由來選擇技術(shù)棧，在做第三個產(chǎn)品的時候， 我們的開發(fā)小哥哥就已經(jīng)不滿足于只寫REST API了，第三個產(chǎn)品開始引入GraphQL。在以前的項目上用過REST Assured 做API測試，覺得也是好用的，但當(dāng)時并沒有選用REST Assured, 因為在那時，剛好發(fā)現(xiàn)一枚ThouhgtWorks開發(fā)自己做的API功能測試工具 Pandaria。（這也從側(cè)面證明TW的開發(fā)很有質(zhì)量意識）選擇這個工具，除了自己不會造輪子，除了它支持代理，更重要的是它基于Cucumber JVM，我個人以前的項目上用過cucumber，對gherkin語法還算熟悉，還有它能提供漂亮的測試報告。它既支持REST API的測試，也支持GraphQL 的測試，完美匹配我個人的技術(shù)和項目的實際情況。

選擇合適的時候做自動化, 避免不必要的浪費。

在項目做第一個規(guī)范安全流程的產(chǎn)品時，MVP1(Minimum Viable Product) 一完成，該產(chǎn)品的接口自動化測試和端到端自動化測試便實現(xiàn)了，并集成到了產(chǎn)品CI/ CD 流水線上。后來由于客戶方硬件集成的問題，該產(chǎn)品基于MVP1進行了一次演進，從產(chǎn)品直接融入并規(guī)范安全流程換成了‘曲線救國’地強化安全流程，頁面和接口設(shè)計也有較大變動。由于產(chǎn)品流程設(shè)計上的變動導(dǎo)致之前的接口測試和端到端的自動化測試全部都失效，需要重新編寫和維護。

這個經(jīng)歷挺真實的，自動化是有好處，但是也是有代價的： 在MVP1，特別是POC（Proof Of Concept)階段的產(chǎn)品建議不要急于做自動化，項目的初期更別嘗試做UI層面的自動化。當(dāng)然對工具的spike是可以的，把框架搭建好，等待特性穩(wěn)定了，就可以直接加測試用例了。

我們選擇自動化一定是要考慮項目是否存在客觀的現(xiàn)實需求，在動手實施具體的自動化測試之前，一定要對自動化測試的投入產(chǎn)出比做一次客觀理性地評估。如上圖所示，自動化測試的成本相對單次（或者少量的）手動測試來說是較高的，為了少量的測試活動而做自動化，投入產(chǎn)出比是很低的。需要QA根據(jù)項目進度，產(chǎn)品演進程度，測試策略，回歸頻率等等做一個綜合評估，找到出圖中交集的點，即何時何種情況團隊和產(chǎn)品應(yīng)該必須引入自動化測試了。因為自動化前期需要投入產(chǎn)品分析，工具框架選型，用例設(shè)計，數(shù)據(jù)環(huán)境準備等等，后期還需要持續(xù)不斷地投入人力進行及時的維護和更新以保證自動化測試的嚴密性和足夠的覆蓋率。

自動化測試和產(chǎn)品代碼一樣重要，需要全員負責(zé)。

雖然敏捷強調(diào)質(zhì)量全員負責(zé)，但我所待過的團隊，做過的項目，踐行得好的很少。幸運的是，現(xiàn)在團隊的質(zhì)量意識都很好。但故事一開始不都是美好的，每個團隊都是在 “掉坑-反饋-調(diào)整磨合” 的循環(huán)里走向成熟的。

在交付一個微服務(wù)化的產(chǎn)品時，后端多個API，每個API有相應(yīng)的API集成測試，產(chǎn)品還有UI測試，同時團隊還有額外的3個產(chǎn)品需要維護。每個產(chǎn)品都有自動化測試，前端的后端的。其中一個微服務(wù)實現(xiàn)的產(chǎn)品就有四套測試，而且后續(xù)還會增加視覺測試。

在剛開始的時候，測試掛了沒人去看，也沒人去修。由于項目是基于Trunk Based Development，為了保證測試的及時性，每天不是在加新用例的路上，就是在修各種測試的路上。UI測試相較于API測試更為脆弱，需要頻繁的維護成本，特別是項目基于主干開發(fā)的團隊。那段時間感覺自己成了automation engineer，對產(chǎn)品新增的功能特性并不是非常清楚，對故事卡的可測性也沒及時作出反饋，感覺自動化并未真的達到釋放自己精力和時間的初衷。

如果只是QA一個人來維護管理，那么這個QA一定做不了自動化以外的事情了。ThoughtWorks好多項目都只有一個QA，我們的這個QA是Quality Analyst， 并不是Automation Engineer。敏捷項目之下，QA的首要任務(wù)應(yīng)該是驅(qū)動團隊各個角色對質(zhì)量負責(zé)。

為了提升團隊對自動化測試的重視程度， 如下是一些我個人在項目上實踐過的方法：

• 為每套自動化測試編寫清晰的README, 保證團隊里除你以外其他的小伙伴，也都清楚明白如何運行自動化測試。
• 除了實用的README引導(dǎo)團隊如何運行測試，可視化良好的測試報告也非常必要。如下是我們項目上的測試報告：

• 讓UI測試更穩(wěn)定，請求開發(fā)把頁面的關(guān)鍵組件元素加上ID 屬性，用唯一的ID去定位元素就穩(wěn)定多了。
• 建議每個Dev提交代碼前，在本地自行運行測試腳本，保證自動化測試的及時性和正確性，并對新變更提供及時的質(zhì)量反饋。

除了以上，項目還需要有高度可視化或者能及時通知測試狀態(tài)的方式。

項目上用的是Jenkins自帶的 Build Monitor View。將對項目pipeline的監(jiān)控投影到電視上，并配置相應(yīng)的提示音，能非常及時地讓團隊知道最新的構(gòu)建，部署，測試狀態(tài)。

如下是我們項目上當(dāng)前的一個流水線dashboard：

這些實踐都是對‘質(zhì)量全員負責(zé)’最落地的踐行。我相信，每個團隊是不一樣的，但是敏捷QA的主要價值一定是能驅(qū)動團隊為質(zhì)量作出改進和貢獻。

敏捷QA是對項目流程質(zhì)量，產(chǎn)品內(nèi)部質(zhì)量，產(chǎn)品外部質(zhì)量都需要負責(zé)的，而自動化測試只是質(zhì)量保證的一種措施而已而非唯一措施。‘質(zhì)量全員負責(zé)’的團隊才能釋放出你們的QA，去做更多Quality Analysis的工作，比如提更多需要思辨能力的問題以實現(xiàn)產(chǎn)品風(fēng)險的識別和管理，反思開發(fā)流程以促進團隊流程質(zhì)量的提升，分析產(chǎn)品架構(gòu)制定適合項目產(chǎn)品的整體測試策略等等。

持續(xù)測試除了自動化測試還需要QA和團隊具備Devops相關(guān)的技術(shù)。

在項目上做自動化集成到流水線的時候，有遇到一些常見的在云容器里運行測試會遇到的問題。

1）測試工具相關(guān)的

• 在容器里安裝puppeteer之前，需要手動下載Chromium包以及相關(guān)的依賴。
• 在Docker里面啟動puppeteer，要么配置一個puppeteer的user，要么選擇去掉默認的沙盒環(huán)境。
• 當(dāng)時還遇到因為docker默認的64MB內(nèi)存空間不夠，Chrome渲染頁面崩潰

雖然很多問題都是可以從網(wǎng)上找到答案，但是在解決問題的時候，通常需要我們了解工具框架的工作原理，否則連搜索關(guān)鍵字可能都憋不出來。

2）測試報告可視化相關(guān)的

測試報告對于我們快速定位失敗根因有很大的幫助，好的測試報告可以直接揭示問題的根源。在云端運行測試，我們通常希望測試工具能輸出可讀性強的測試報告以方便非技術(shù)人員閱讀，也希望測試工具能把運行過程的細節(jié)打印在console里，以方便技術(shù)人員定位根因。

像前面提到的CodeceptJS它就提供多種不同形態(tài)的運行，并且可以運用Mocha生成各種類型的測試報告。目前市面上的測試工具，都會有對第三方庫的依賴，特別是前端測試框架和工具，這個對QA或者團隊的技術(shù)寬度是有一定要求的。

另外Jenkins有非常豐富的插件庫，在選擇測試工具的時候可以把是否有Jenkins報告可視化支持考慮進去。QA需要對Jenkins和測試工具都相當(dāng)熟悉，還需要知道如何通過將某一測試工具生成的某種格式的測試報告集成在Jenkins上以方便一鍵獲取測試報告。 像cucumber的測試報告插件：

像Allure的測試報告插件：

有了這些插件的輔助，在流水線上就一鍵可得測試報告，為‘質(zhì)量團隊負責(zé)’提供了很好的契機。

3） Pipeline as Code, 想要集成測試到流水線，不可避免是需要一些DevOps相關(guān)知識的

也許項目的需求是如何通過Jenkinsfile 并行運行各種測試，也許是通過Jenkinsfile傳遞測試相關(guān)參數(shù)以為云上運行測試所用，還也許你需要在Jenkinsfile里添加調(diào)試信息用以線上調(diào)試，等等。

云上運行，我們還要學(xué)會如何在一個slave 上優(yōu)雅地管理運行測試的容器，不出現(xiàn)容器占用，slave內(nèi)存不足，測試失敗之后報告不可得等等問題。

所以只會自動化工具不夠，只有自動化測試也不夠。如果你們團隊開發(fā)們沒有DevOps的經(jīng)驗，或者他們忙于特性開發(fā)，上線沖刺，那么QA必須對Docker，Kubernetes 基本命令和用法有些了解。QA就是一個不分前后端，不挑技術(shù)棧，需要持續(xù)不斷學(xué)習(xí)的角色。

最后用個比喻結(jié)束這篇文章

會自動化工具算是有了織網(wǎng)的道具，有自動化測試資產(chǎn)算是編出了能撈魚的網(wǎng)，而持續(xù)測試才能真正地實現(xiàn)持續(xù)交付，才算是把一張張過濾不同缺陷的網(wǎng)放置于了不斷提交變更的交付之流中。

只有網(wǎng)而無法至于河里，或者不知道于何處放置，那就只能站于岸邊時時撒網(wǎng)捕魚，不夠及時，也不算釋放了捕魚人（QA和團隊)。

我們期望的是，各種不同的網(wǎng)（自動化測試資產(chǎn)），置于不同的河段（軟件產(chǎn)品不同層級：函數(shù)級別？組件級別？接口級別？系統(tǒng)級別？），過濾不同的魚（缺陷），而不管是誰（團隊的所有角色）都可以去確認有沒有撈著魚（測試掛了嗎？為什么掛？我們對目前的變更有足夠的信心嗎？），也需要所有人時時確認我們的漁網(wǎng)是不是破了？（測試覆蓋率不夠？斷言不嚴謹？測試用例過時？）。

軟件交付是一項團隊工作，即便自動化測試也一樣需要全員協(xié)作。

文/ThoughtWorks郭泰瑜