在提及自動化測試的時候，很多人會把工具的使用等同於自動化測試。自動化測試應該是一個策略性的系統化工程，不只有自動化工具。自動化測試要發揮其頻繁快速的質量反饋作用，還需要團隊從文化和技術上去建設和學習。
提到敏捷交付，我們總會說到持續整合，持續交付，持續釋出，即頻繁地交付產品特性。而我們都知道要實現真正的持續交付，必然少不了兩個關鍵要素：只有測試不行，只有整合工具也不行，二者需合二為一，保持相同的步調，實現持續不斷的質量反饋，方能實現保質地持續釋出。
可以開門見山地說：Automation Test ≠ Automation Tools ≠ Continuous Test根據我個人的專案經驗，試著畫了下面這個圖來表達這三者的關係。在提及自動化測試的時候，很多人會把工具的使用等同於自動化測試。自動化測試應該是一個策略性的系統工程，不只有自動化工具。像我們的產品一樣，不僅要有技術語言，還要有產品架構設計。自動化測試除了工具框架，還需要考慮：專案的技術棧，產品架構，開發流程，基礎設施，可靠的測試資料，穩定乾淨的測試環境，如何呈現測試報告，如何工程化測試配置，測試套件等等。有了自動化測試還不夠，我們的目的是在持續交付的過程中實現快速頻繁的質量反饋，我們需要持續不斷地測試（Continous Testing)。實現持續測試，不僅需要團隊從文化上去支援，真正做到全員對測試和質量負責，建立Devops文化氛圍，打通開發-測試-運維的壁壘；還需團隊從技術上去儲備知識，比如雲平臺、虛擬化技術，容器及相應的編排技術，甚至網路知識等等。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.
測試，質量評估的重要手段之一，而自動化測試只是測試的一種具體實現方式而已。它能釋放QA的雙手和一部分大腦（這部分大腦，即know knowns），將對已知特性和既定邏輯流程的檢測交由計算機來完成。而QA去做更多需要思辨能力，分析判斷能力的事情。例如，透過向團隊提問，來澄清需求的unknowns；透過探索產品去拓寬對產品的knowns；抑或運用經驗幫助團隊走出Unknown Unknowns 帶來的迷局。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.
從這個定義可以看出，持續測試的目的即在軟體交付的流水線中執行自動化測試以提供對產品質量的反饋。想強調定義裡的幾個關鍵字：automated tests, delivery pipeline, immediate feedback, business risks.- automated tests 而不是automated test，一個產品只有一種，或者某一層級上的自動化測試是無法達到整體質量評估的，持續測試需要不同型別的自動化測試在交付的不同階段為產品的不同層級提供反饋。
- delivery pipeline，immediate feedback，自動化測試一定是和交付流水線交合整合的，至少是同頻執行的，不是孤立的，只有這樣才能就團隊每一次的新變更對產品質量的影響做出快速而及時的反饋。
- business risks，持續測試廣義上來說包含交付中的所有質量反饋行為，既要測試左移，質量內建，也要測試右移，實現產品質量主動監控，不然無法識別業務風險。
測試工具的選擇需要考慮專案的技術棧，也需要考慮QA自身的技術能力。不管多火的工具，如果不能相容專案的技術棧和基礎設施，那都無處發揮其優勢，流行的不一定是適合專案的。在寫自動化之前，QA需要對專案的技術棧，開發流程，和基礎設施有基本的認識和了解；另外也需要了解和掌握各個工具之間的優劣，這樣才能為專案選擇最匹配的自動化工具。是不是像老生常談？但是別人告訴你的經驗和自己經歷的實戰真的兩種不同的收穫。就跟蹲家看電視和去現場看演唱會的區別一樣，別人的經驗之談總歸是別人的，自己走過的路才是自己的。這兩年Cypress真的很火，去年在專案上做UI自動化測試的時候，出於好奇也想實踐一把。實踐出真知，Cypress本身可以透過環境變數和plugin配置代理，但是不支援socks5的代理（客觀現狀是專案所有資產，包括測試環境都是透過socks5的代理連線），線上環境無法訪問。當時還試過將socks5的代理轉換成http代理，但因為Cypress本身是多執行緒的，而socks5只能截獲第一個程式的網路通訊， 即使能連通應用本身，Cypress也無法將測試過程視覺化的優勢發揮出來。人無完人，工具也一樣，只有適合你的才是好的。考慮自己也不會造輪子，喜歡拿來就用，加之專案上socks5代理約束，之後便轉用了CodeceptJS, 幾次嘗試下來，覺得非常滿足專案需要。下面羅列CodeceptJS 幾個好用的點，具體細節請移步官網。- 支援不同的helper: WebDriver, Puppeteer, Protractor, Nightmare, Testcafe， 我在專案上選用的是Puppeteer。
- 支援web也支援mobile，當時專案上的第一個產品是有手機端版本的， 這也是選擇這個工具的一個考慮。
- 封裝良好的頁面元素操作方法，拿來即用，對於不擅長編碼的我來說，非常友好。
- 因為專案產品是和礦場上爆破緊密相關的，很多產品都有礦場地圖展示和裝置視覺化，CodeceptJS 提供了現成的codeceptjs-resemblehelper以實現視覺上的迴歸測試。
- 最近發現它還支援API測試，包括REST和GraphQL的， 但是這部分特性尚未實踐。
由於團隊有完全的自由來選擇技術棧，在做第三個產品的時候， 我們的開發小哥哥就已經不滿足於只寫REST API了，第三個產品開始引入GraphQL。在以前的專案上用過REST Assured 做API測試，覺得也是好用的，但當時並沒有選用REST Assured, 因為在那時，剛好發現一枚ThouhgtWorks開發自己做的API功能測試工具 Pandaria。（這也從側面證明TW的開發很有質量意識）選擇這個工具，除了自己不會造輪子，除了它支援代理，更重要的是它基於Cucumber JVM，我個人以前的專案上用過cucumber，對gherkin語法還算熟悉，還有它能提供漂亮的測試報告。它既支援REST API的測試，也支援GraphQL 的測試，完美匹配我個人的技術和專案的實際情況。
在專案做第一個規範安全流程的產品時，MVP1(Minimum Viable Product) 一完成，該產品的介面自動化測試和端到端自動化測試便實現了，並整合到了產品CI/ CD 流水線上。後來由於客戶方硬體整合的問題，該產品基於MVP1進行了一次演進，從產品直接融入並規範安全流程換成了‘曲線救國’地強化安全流程，頁面和介面設計也有較大變動。由於產品流程設計上的變動導致之前的介面測試和端到端的自動化測試全部都失效，需要重新編寫和維護。這個經歷挺真實的，自動化是有好處，但是也是有代價的：在MVP1，特別是POC（Proof Of Concept)階段的產品建議不要急於做自動化，專案的初期更別嘗試做UI層面的自動化。當然對工具的spike是可以的，把框架搭建好，等待特性穩定了，就可以直接加測試用例了。 我們選擇自動化一定是要考慮專案是否存在客觀的現實需求，在動手實施具體的自動化測試之前，一定要對自動化測試的投入產出比做一次客觀理性地評估。如上圖所示，自動化測試的成本相對單次（或者少量的）手動測試來說是較高的，為了少量的測試活動而做自動化，投入產出比是很低的。需要QA根據專案進度，產品演程式度，測試策略，迴歸頻率等等做一個綜合評估，找到出圖中交集的點，即何時何種情況團隊和產品應該必須引入自動化測試了。因為自動化前期需要投入產品分析，工具框架選型，用例設計，資料環境準備等等，後期還需要持續不斷地投入人力進行及時的維護和更新以保證自動化測試的嚴密性和足夠的覆蓋率。
雖然敏捷強調質量全員負責，但我所待過的團隊，做過的專案，踐行得好的很少。幸運的是，現在團隊的質量意識都很好。但故事一開始不都是美好的，每個團隊都是在 “掉坑-反饋-調整磨合” 的迴圈裡走向成熟的。在交付一個微服務化的產品時，後端多個API，每個API有相應的API整合測試，產品還有UI測試，同時團隊還有額外的3個產品需要維護。每個產品都有自動化測試，前端的後端的。其中一個微服務實現的產品就有四套測試，而且後續還會增加視覺測試。在剛開始的時候，測試掛了沒人去看，也沒人去修。由於專案是基於Truck Based Development，為了保證測試的及時性，每天不是在加新用例的路上，就是在修各種測試的路上。UI測試相較於API測試更為脆弱，需要頻繁的維護成本，特別是專案基於主幹開發的團隊。那段時間感覺自己成了automation engineer，對產品新增的功能特性並不是非常清楚，對故事卡的可測性也沒及時作出反饋，感覺自動化並未真的達到釋放自己精力和時間的初衷。 如果只是QA一個人來維護管理，那麼這個QA一定做不了自動化以外的事情了。ThoughtWorks好多專案都只有一個QA，我們的這個QA是Quality Analyst， 並不是Automation Engineer。敏捷專案之下，QA的首要任務應該是驅動團隊各個角色對質量負責。為了提升團隊對自動化測試的重視程度， 如下是一些我個人在專案上實踐過的方法：- 為每套自動化測試編寫清晰的README, 保證團隊裡除你以外其他的小夥伴，也都清楚明白如何執行自動化測試。
- 除了實用的README引導團隊如何執行測試，視覺化良好的測試報告也非常必要。如下是我們專案上的測試報告：
- 讓UI測試更穩定，請求開發把頁面的關鍵元件元素加上ID 屬性，用唯一的ID去定位元素就穩定多了。
- 建議每個Dev提交程式碼前，在本地自行執行測試指令碼，保證自動化測試的及時性和正確性，並對新變更提供及時的質量反饋。
除了以上，專案還需要有高度視覺化或者能及時通知測試狀態的方式。專案上用的是Jenkins自帶的 Build Monitor View。將對專案pipeline的監控投影到電視上，並配置相應的提示音，能非常及時地讓團隊知道最新的構建，部署，測試狀態。如下是我們專案上當前的一個流水線dashboard：這些實踐都是對‘質量全員負責’最落地的踐行。我相信，每個團隊是不一樣的，但是敏捷QA的主要價值一定是能驅動團隊為質量作出改進和貢獻。敏捷QA是對專案流程質量，產品內部質量，產品外部質量都需要負責的，而自動化測試只是質量保證的一種措施而已而非唯一措施。‘質量全員負責’的團隊才能釋放出你們的QA，去做更多Quality Analysis的工作，比如提更多需要思辨能力的問題以實現產品風險的識別和管理，反思開發流程以促進團隊流程質量的提升，分析產品架構制定適合專案產品的整體測試策略等等。
持續測試除了自動化測試還需要QA和團隊具備Devops相關的技術。在專案上做自動化整合到流水線的時候，有遇到一些常見的在雲容器裡執行測試會遇到的問題。- 在容器裡安裝puppeteer之前，需要手動下載Chromium包以及相關的依賴。
- 在docker裡面啟動puppeteer，要麼配置一個puppeteer的user，要麼選擇去掉預設的沙盒環境。
- 當時還遇到因為docker預設的64MB記憶體空間不夠，Chrome渲染頁面崩潰。
雖然很多問題都是可以從網上找到答案，但是在解決問題的時候，通常需要我們瞭解工具框架的工作原理，否則連搜尋關鍵字可能都憋不出來。測試報告對於我們快速定位失敗根因有很大的幫助，好的測試報告可以直接揭示問題的根源。在雲端執行測試，我們通常希望測試工具能輸出可讀性強的測試報告以方便非技術人員閱讀，也希望測試工具能把執行過程的細節列印在console裡，以方便技術人員定位根因。像前面提到的CodeceptJS它就提供多種不同形態的執行，並且可以運用Mocha生成各種型別的測試報告。目前市面上的測試工具，都會有對第三方庫的依賴，特別是前端測試框架和工具，這個對QA或者團隊的技術寬度是有一定要求的。另外Jenkins有非常豐富的外掛庫，在選擇測試工具的時候可以把是否有Jenkins報告視覺化支援考慮進去。QA需要對Jenkins和測試工具都相當熟悉，還需要知道如何透過將某一測試工具生成的某種格式的測試報告整合在Jenkins上以方便一鍵獲取測試報告。像cucumber的測試報告外掛：有了這些外掛的輔助，在流水線上就一鍵可得測試報告，為‘質量團隊負責’提供了很好的契機。3）Pipeline as Code, 想要整合測試到流水線，不可避免是需要一些DevOps相關知識的。也許專案的需求是如何透過Jenkinsfile 並行執行各種測試，也許是透過Jenkinsfile傳遞測試相關引數以為雲上執行測試所用，還也許你需要在Jenkinsfile裡新增除錯資訊用以線上除錯，等等。雲上執行，我們還要學會如何在一個slave 上優雅地管理執行測試的容器，不出現容器佔用，slave記憶體不足，測試失敗之後報告不可得等等問題。所以只會自動化工具不夠，只有自動化測試也不夠。如果你們團隊開發們沒有DevOps的經驗，或者他們忙於特性開發，上線衝刺，那麼QA必須對Docker，Kubernetes 基本命令和用法有些瞭解。QA就是一個不分前後端，不挑技術棧，需要持續不斷學習的角色。
會自動化工具算是有了織網的道具，有自動化測試資產算是編出了能撈魚的網，而持續測試才能真正地實現持續交付，才算是把一張張過濾不同缺陷的網放置於了不斷提交變更的交付之流中。只有網而無法至於河裡，或者不知道於何處放置，那就只能站於岸邊時時撒網捕魚，不夠及時，也不算釋放了捕魚人（QA和團隊)。我們期望的是，各種不同的網（自動化測試資產），置於不同的河段（軟體產品的不同層級：函式級別？元件級別？介面級別？系統級別？），過濾不同的魚（缺陷），而不管是誰（團隊的所有角色）都可以去確認有沒有撈著魚（測試掛了嗎？為什麼掛？我們對目前的變更有足夠的信心嗎？），也需要所有人時時確認我們的漁網是不是破了？（測試覆蓋率不夠？斷言不嚴謹？測試用例過時？）。軟體交付是一項團隊工作，即便自動化測試也一樣需要全員協作。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31558019/viewspace-2741882/，如需轉載，請註明出處，否則將追究法律責任。
