----------- Get the result ------------ %s", res)
"""這里的res是我們平滑升級的時候需要返回結果為TRUE才會繼續下面走。"""
六、查看測試報告（部署到jenkins會通過控制臺查看）
提到敏捷交付，我們總會說到持續集成，持續交付，持續發布，即頻繁地交付產品特性。而我們都知道要實現真正的持續交付，必然少不了兩個關鍵要素：
只有測試不行，只有集成工具也不行，二者需合二為一，保持相同的步調，實現持續不斷的質量反饋，方能實現保質地持續發布。
可以開門見山地說：Automation Test ≠ Automation Tools ≠ Continuous Test
根據我個人的項目經驗，試著畫了下面這個圖來表達這三者的關系。
在提及自動化測試的時候，很多人會把工具的使用等同于自動化測試。自動化測試應該是一個策略性的系統工程，不只有自動化工具。像我們的產品一樣，不僅要有技術語言，還要有產品架構設計。自動化測試除了工具框架，還需要考慮：
項目的技術棧，產品架構，開發流程，基礎設施，可靠的測試數據，穩定干凈的測試環境，如何呈現測試報告，如何工程化測試配置，測試套件等等。
有了自動化測試還不夠，我們的目的是在持續交付的過程中實現快速頻繁的質量反饋，我們需要持續不斷地測試（Continous Testing)。實現持續測試，不僅需要團隊從文化上去支持，真正做到全員對測試和質量負責，創建Devops文化氛圍，打通開發-測試-運維的壁壘；還需團隊從技術上去儲備知識，比如云平臺、虛擬化技術，容器及相應的編排技術，甚至網絡知識等等。
維基百科對自動化的解釋：
In software testing, test 買粉絲mation is the use of software separate from the software being tested to 買粉絲ntrol the execution of tests and the 買粉絲parison of actual out買粉絲es with predicted out買粉絲es.
從定義可以總結出自動化測試的兩個特點：
維基百科對持續測試的解釋：
Continuous testing is the process of executing 買粉絲mated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.
從這個定義可以看出，持續測試的目的即在軟件交付的流水線中執行自動化測試以提供對產品質量的反饋。
想強調定義里的幾個關鍵字：買粉絲mated tests, delivery pipeline, immediate feedback, business risks.
不管多火的工具，如果不能兼容項目的技術棧和基礎設施，那都無處發揮其優勢，流行的不一定是適合項目的。
在寫自動化之前，QA需要對項目的技術棧，開發流程，和基礎設施有基本的認識和了解；另外也需要了解和掌握各個工具之間的優劣，這樣才能為項目選擇最匹配的自動化工具。是不是像老生常談？但是別人告訴你的經驗和自己經歷的實戰真的兩種不同的收獲。就跟蹲家看電視和去現場看演唱會的區別一樣，別人的經驗之談總歸是別人的，自己走過的路才是自己的。
這兩年 Cypress 真的很火，去年在項目上做UI自動化測試的時候，出于好奇也想實踐一把。實踐出真知，Cypress本身可以通過環境變量和plugin配置代理，但是不支持socks5的代理（客觀現狀是項目所有資產，包括測試環境都是通過socks5的代理連接），線上環境無法訪問。當時還試過將socks5的代理轉換成買粉絲代理，但因為Cypress本身是多線程的，而socks5只能截獲第一個進程的網絡通信， 即使能連通應用本身，Cypress也無法將測試過程可視化的優勢發揮出來。人無完人，工具也一樣，只有適合你的才是好的。
考慮自己也不會造輪子，喜歡拿來就用，加之項目上socks5代理約束，之后便轉用了CodeceptJS, 幾次嘗試下來，覺得非常滿足項目需要。下面羅列CodeceptJS 幾個好用的點，具體細節請移步 官網 。
由于團隊有完全的自由來選擇技術棧，在做第三個產品的時候， 我們的開發小哥哥就已經不滿足于只寫REST API了，第三個產品開始引入GraphQL。在以前的項目上用過REST Assured 做API測試，覺得也是好用的，但當時并沒有選用REST Assured, 因為在那時，剛好發現一枚ThouhgtWorks開發自己做的API功能測試工具 Pandaria 。（這也從側面證明TW的開發很有質量意識）選擇這個工具，除了自己不會造輪子，除了它支持代理，更重要的是它基于Cucumber JVM，我個人以前的項目上用過cucumber，對gherkin語法還算熟悉，還有它能提供漂亮的測試報告。它既支持REST API的測試，也支持GraphQL 的測試，完美匹配我個人的技術和項目的實際情況。
在項目做第一個規范安全流程的產品時，MVP1(Minimum Viable Proct) 一完成，該產品的接口自動化測試和端到端自動化測試便實現了，并集成到了產品CI/ CD 流水線上。后來由于客戶方硬件集成的問題，該產品基于MVP1進行了一次演進，從產品直接融入并規范安全流程換成了‘曲線救國’地強化安全流程，頁面和接口設計也有較大變動。由于產品流程設計上的變動導致之前的接口測試和端到端的自動化測試全部都失效，需要重新編寫和維護。
這個經歷挺真實的，自動化是有好處，但是也是有代價的： 在MVP1，特別是POC（Proof Of Concept)階段的產品建議不要急于做自動化，項目的初期更別嘗試做UI層面的自動化。當然對工具的spike是可以的，把框架搭建好，等待特性穩定了，就可以直接加測試用例了。
我們選擇自動化一定是要考慮項目是否存在客觀的現實需求，在動手實施具體的自動化測試之前，一定要對自動化測試的投入產出比做一次客觀理性地評估。如上圖所示，自動化測試的成本相對單次（或者少量的）手動測試來說是較高的，為了少量的測試活動而做自動化，投入產出比是很低的。需要QA根據項目進度，產品演進程度，測試策略，回歸頻率等等做一個綜合評估，找到出圖中交集的點，即何時何種情況團隊和產品應該必須引入自動化測試了。因為自動化前期需要投入產品分析，工具框架選型，用例設計，數據環境準備等等，后期還需要持續不斷地投入人力進行及時的維護和更新以保證自動化測試的嚴密性和足夠的覆蓋率。
雖然敏捷強調質量全員負責，但我所待過的團隊，做過的項目，踐行得好的很少。幸運的是，現在團隊的質量意識都很好。但故事一開始不都是美好的，每個團隊都是在 “掉坑-反饋-調整磨合” 的循環里走向成熟的。
在交付一個微服務化的產品時，后端多個API，每個API有相應的API集成測試，產品還有UI測試，同時團隊還有額外的3個產品需要維護。每個產品都有自動化測試，前端的后端的。其中一個微服務實現的產品就有四套測試，而且后續還會增加視覺測試。
在剛開始的時候，測試掛了沒人去看，也沒人去修。由于項目是基于 Trunk Based Development ，為了保證測試的及時性，每天不是在加新用例的路上，就是在修各種測試的路上。UI測試相較于API測試更為脆弱，需要頻繁的維護成本，特別是項目基于主干開發的團隊。那段時間感覺自己成了買粉絲mation engineer，對產品新增的功能特性并不是非常清楚，對故事卡的可測性也沒及時作出反饋，感覺自動化并未真的達到釋放自己精力和時間的初衷。
如果只是QA一個人來維護管理，那么這個QA一定做不了自動化以外的事情了。ThoughtWorks好多項目都只有一個QA，我們的這個QA是Quality Analyst， 并不是Automation Engineer。敏捷項目之下，QA的首要任務應該是驅動團隊各個角色對質量負責。
為了提升團隊對自動化測試的重視程度， 如下是一些我個人在項目上實踐過的方法：
除了以上，項目還需要有高度可視化或者能及時通知測試狀態的方式。
項目上用的是Jenkins自帶的 Build Monitor View。將對項目pipeline的監控投影到電視上，并配置相應的提示音，能非常及時地讓團隊知道最新的構建，部署，測試狀態。
如下是我們項目上當前的一個流水線dashboard：
這些實踐都是對‘質量全員負責’最落地的踐行。我相信，每個團隊是不一樣的，但是敏捷QA的主要價值一定是能驅動團隊為質量作出改進和貢獻。
在項目上做自動化集成到流水線的時候，有遇到一些常見的在云容器里運行測試會遇到的問題。
1）測試工具相關的
雖然很多問題都是可以從網上找到答案，但是在解決問題的時候，通常需要我們了解工具框架的工作原理，否則連搜索關鍵字可能都憋不出來。
2）測試報告可視化相關的
測試報告對于我們快速定位失敗根因有很大的幫助，好的測試報告可以直接揭示問題的根源。在云端運行測試，我們通常希望測試工具能輸出可讀性強的測試報告以方便非技術人員閱讀，也希望測試工具能把運行過程的細節打印在買粉絲nsole里，以方便技術人員定位根因。
像前面提到的CodeceptJS它就提供多種不同形態的運行，并且可以運用Mocha生成各種類型的測試報告。目前市面上的測試工具，都會有對第三方庫的依賴，特別是前端測試框架和工具，這個對QA或者團隊的技術寬度是有一定要求的。
另外Jenkins有非常豐富的插件庫，在選擇測試工具的時候可以把是否有Jenkins報告可視化支持考慮進去。QA需要對Jenkins和測試工具都相當