專案實施DevOps時，我們是如何做測試的
DevOps是一系列軟體開發實踐，強調開發人員(Dev)和運維人員(Ops)之間的溝通合作，通過自動化流程，使得軟體構建、測試、釋出更加快捷、頻繁和可靠。
正如我們所知，DevOps最近幾年很風靡，很多企業正在如火如荼的推行它。然而，你可曾想過，從傳統到敏捷、再到DevOps，開發模式的不斷革新對測試提出了怎樣的挑戰？
最近我們專案在實施DevOps，因此想趁熱打鐵，就DevOps模式下如何做測試，談一談自己的認知。
DevOps有什麼特徵
DevOps是一系列軟體開發實踐，強調開發人員（Dev）和運維人員（Ops）之間的溝通合作，通過自動化流程，使得軟體構建、測試、釋出更加快捷、頻繁和可靠。
1. DevOps強調一種文化
在很多企業中，開發和運維人員通常隸屬於不同部門，有著不同的工作環境，採用不同的溝通方式，使用不同的開發或運維工具，並且有著不同的業務目標，這使得他們之間形成一道參不透的牆。
DevOps實際是一種文化上的變遷，強調開發、運維、測試等環節之間的溝通合作。意在幫助這些人向著一個共同的目標努力：儘可能為公司提供更多價值。為了支援這種合作的發生，需要在團隊內部文化和企業組織文化兩個層面做出努力。
2. DevOps是一種實踐
所謂DevOps，就是將敏捷方法延伸到Production!
DevOps主要是為了將敏捷開發實踐擴充套件到運維階段，進一步完善軟體構建、驗證、部署、交付等流程，使得跨職能團隊能夠完成從設計到生產支援等各環節的工作。
3. DevOps包含一系列工具鏈
DevOps是一種融合了一系列基本原則和實踐的方法論，並從這些實踐中派生出了各種工具。這些工具體現在軟體開發和交付過程的不同階段：
-
編碼：程式碼開發和審閱，版本控制工具、程式碼合併工具
-
構建：持續整合工具、構建狀態統計工具
-
測試：通過測試和結果確定績效的工具
-
打包：成品倉庫、應用程式部署前暫存
-
釋出：變更管理、釋出審批、釋出自動化
-
配置：基礎架構配置和部署，基礎架構即程式碼工具
-
監視：應用程式效能監視、終端使用者體驗
DevOps對測試提出了哪些挑戰
剛參加工作時，我參與了某Audi系汽車電子的軟體研發，採用的是傳統瀑布開發模式。在整個專案生命週期中，前半部分設計和編碼，後半部分用來測試。然而我在東家工作了兩年，也沒能等到產品交付到使用者手上。直到去年，我們的軟體才得以量產並投入市場。在這4年中，產品從未交到使用者手上，因此無法驗證它所帶來的價值，也沒有任何機會得到使用者反饋從而適應變化。
後來，我又參與一個銀行專案，我們採用敏捷的開發模式，全功能團隊，開發測試並行，每2-3周就交付一個版本。但因為沒有真正釋出到生產環境，我們仍然無法及時得到有效的使用者反饋。
現在，我們採用DevOps的優秀實踐，開發和運維協同工作。每個迭代完成，或者每修復一個線上缺陷就立即部署到生產環境。這樣，我們就能夠迅速從使用者處獲得反饋並且快速做出響應。
通過參與傳統、敏捷和DevOps的專案，我深深地感受到流程的改進對團隊以及專案的產出和質量所帶來的改變。
3. DevOps包含一系列工具鏈
DevOps是一種融合了一系列基本原則和實踐的方法論，並從這些實踐中派生出了各種工具。這些工具體現在軟體開發和交付過程的不同階段：
-
編碼：程式碼開發和審閱，版本控制工具、程式碼合併工具
-
構建：持續整合工具、構建狀態統計工具
-
測試：通過測試和結果確定績效的工具
-
打包：成品倉庫、應用程式部署前暫存
-
釋出：變更管理、釋出審批、釋出自動化
-
配置：基礎架構配置和部署，基礎架構即程式碼工具
-
監視：應用程式效能監視、終端使用者體驗
DevOps對測試提出了哪些挑戰
剛參加工作時，我參與了某Audi系汽車電子的軟體研發，採用的是傳統瀑布開發模式。在整個專案生命週期中，前半部分設計和編碼，後半部分用來測試。然而我在東家工作了兩年，也沒能等到產品交付到使用者手上。直到去年，我們的軟體才得以量產並投入市場。在這4年中，產品從未交到使用者手上，因此無法驗證它所帶來的價值，也沒有任何機會得到使用者反饋從而適應變化。
後來，我又參與一個銀行專案，我們採用敏捷的開發模式，全功能團隊，開發測試並行，每2-3周就交付一個版本。但因為沒有真正釋出到生產環境，我們仍然無法及時得到有效的使用者反饋。
現在，我們採用DevOps的優秀實踐，開發和運維協同工作。每個迭代完成，或者每修復一個線上缺陷就立即部署到生產環境。這樣，我們就能夠迅速從使用者處獲得反饋並且快速做出響應。
通過參與傳統、敏捷和DevOps的專案，我深深地感受到流程的改進對團隊以及專案的產出和質量所帶來的改變。
Laurent提出一個測試左移和右移的概念:
-
測試左移，就是指在開發階段之前定義測試。
-
測試右移，就是直接在生產環境中監控，並且實時獲取使用者反饋。
在敏捷開發的生命週期中，我們通過每一次迭代來豐富和更新產品，以使其最大限度地符合客戶對系統的需求。當時測試的關注點基本停留在開發階段，以保證產品達到上線標準。引入DevOps之後，我們不僅要關注產品的質量是否達標，還需要使價值假設得到及時的驗證。因此，我們不僅要將測試左移，在開發環境驗證功能的可用性，還要進行測試右移，通過監控產品在生產環境的運作情況，來驗證其價值並獲得反饋，從而持續改進。基於這些理解，我在專案上做了初步的嘗試並取得良好的效果。我將這些嘗試和實踐總結為以下幾點：
1.如何保證新功能得以實現？
在開發環境，我們開發新功能，並且通過測試保證其達到產品驗收標準。
首先，使用BDD（Behavior Driven Development，BDD）的方式定義使用者需求，這樣用特定的語言來描述使用者行為，能夠使各個角色（測試、開發、產品負責人、市場等）對業務價值達成一致的理解，從而使其從需求到最後的測試驗證，進行高度的協作和溝通，最後交付最有價值的功能。同時，QA能夠提前Review故事卡，補充驗收標準。除此之外，BDD方式的使用者需求可以直接指導測試，後續我會寫到。
其次，採用單元測試來驗證最基本的程式碼邏輯。在編寫單元測試時，建議Dev和QA Pair工作。單元測試可以認為是編碼的一部分，要對系統的程式碼邏輯有深入的瞭解，因此，Dev是最合適的人選，而QA可以幫助測試覆蓋的更全面。
最後，每一個功能都要嚴格按照故事卡的AC（Acceptance Criteria）進行驗收，並採用探索性測試方法來對新功能進行無死角測試。
2.怎樣驗證新功能的價值？
我們將新功能部署到生產環境以後，接下來就應該衡量業務價值是否達到預期。
驗證預期的一個好方法是衡量使用者的行為變化。比如：在上傳圖片的功能後面添加了一個預覽按鈕，但使用者卻極少用它，很可能是因為使用者根本不需要這個按鈕，或者按鈕放在了不恰當的位置導致使用者不方便使用，亦或是按鈕樣式不夠友好，導致使用者沒有慾望使用它。這時候，該按鈕的業務價值就沒有真正達到，是時候調整一下了。
3.如何確保已有功能不被破壞？
在軟體開發中，任何程式碼都不可能完全獨立存在，一行程式碼的變更也有可能導致系統的全面崩潰。那麼，如何保證在開發新功能的同時，已有功能不被破壞？換句話說，如何做到全面的迴歸測試？人力是最高成本，也有現實的侷限性，比如，人手不夠，重複做同樣的事情人會變得煩躁，手不夠快導致效率低下等。因此，自動化測試才是不二選擇。
將BDD需求直接轉化為自動化測試用例。每個測試用例都應該講一個關於應用程式的故事。當一個測試用例使用一致的業務術語定義時，它的可讀性會比較高，且容易自動化。與此同時，上一個迭代的用例在下一個迭代就可以迅速轉化為迴歸測試的基線。
支援BDD的工具有很多，比如：Cucumber。簡單舉個例子，如圖：
BA用BDD方式定義使用者需求，QA Review並補充AC，然後將其編寫為自動化測試指令碼。如果QA的編碼能力較弱，可以讓Dev協助完成程式碼實現的部分。這也充分說明了協作的意義。
最後，也是更重要的部分，測試應該整合在CI中。每一次Build或者每天都要去執行測試，驗證已有功能是否完好。這樣才會對沒有預期到的變化產生的問題給出快速反饋。
4.怎樣驗證產品的可靠性？
有時候，某些缺陷並不是源於程式碼的錯誤，而是一個不好的使用者體驗，或者只有當資料達到一定量時才會出現，測試人員是無法模擬這種型別的測試的，因此直接在生產環境監控變得高效又可靠。通常我們需要監控兩種特性：效能和可用性。
使用工具持續獲取使用者資料，或者使用log持續獲取效能資訊。這有助於監控產品部署到生產環境後是如何正確運作的。快速啟用一個功能，在生產環境實時監控驗證其業務價值，獲取到有效且快速的使用者反饋，加之擁有持續部署的能力，我們能夠在出現問題的時候快速做出反應，從而使得我們的產品更加可靠。
這裡實際上融入了《QA in Production》的理念。現如今，已經有很多工具和方法支援在生產環境做測試了。篇幅太長，這裡就不做詳細闡述了，請參考原文。
到這裡，再來回顧一下，我們的實踐是否真的卓有成效。
-
用BDD的方式定義使用者需求、編寫測試，有益於不同角色之間的一致理解和共同協作。
-
自動化測試解決了頻繁部署所帶來的挑戰，同時保證產品的整體功能持續得到迴歸和驗證。
-
線上監控能有效地驗證不確定需求，通過生產資料分析和預警問題的發生，並且快速獲取使用者反饋從而及時調整。除此之外，這一點也充分體現了Dev、QA和Ops的協作，像監控等原本只能Ops做的事，現在Dev或QA一樣可以做。
寫在最後
測試是一種活動，曾經我們通過它來驗證產品是否達到上線標準。現在DevOps模式下，我們需要在各個階段不斷地執行測試活動，以達到產品質量的持續改進。
而QA（Tester）僅僅是一種較多進行測試活動的角色。敏捷一直強調“團隊為質量負責”，測試不再是QA（Tester）的專屬。DevOps模式更是對測試、尤其是自動化測試提出了更高的要求，也對QA的編碼能力提出了極大的挑戰。作為團隊成員，每個人都有責任瞭解開發流程、提高測試技能，把好測試這一關。但是，測試活動作為QA（Tester）的主要職責之一，提高自動化測試技能，就是當下每個QA（Tester）最為緊急且重要的事情了。
需要軟體測試資料的小夥伴，可以來加群：747981058。群內會有不定期的發放免費的資料連結，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。