正如我們所知，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的項目，我深深地感受到流程的改進對團隊以及項目的產出和質量所帶來的改變。

那么，這些改變究竟是對測試提出了什么樣的挑戰? 我認為有以下幾點:

1. 頻繁部署

在采用DevOps之后，我們能夠根據項目具體情況做到每天甚至一天多次部署。在生產環境頻繁部署軟件，最大的挑戰就是測試。以前，測試基本上都在開發階段之后和產品上線之前完成。但現在，不再有充足的時間留給QA團隊去發現問題再拋給開發團隊來修復。那么，速度成了測試面臨的一大挑戰。

2. 自動化

DevOps強調將流程自動化，測試作為其中一個重要環節，勢必要大規模實現自動化。因此測試人員的自動化編碼能力正在面臨極大的挑戰。

3. 實踐和反饋

敏捷提倡我們要擁抱變化，更多的是要適應需求的不斷變化。雖然一部分功能性需求是明確又具體的，我們清楚的知道用戶想要什么，也因此易于測試。然而，也有一些非功能性需求的驗收標準沒那么明確，比如：提高應用性能達到良好的用戶體驗。我們如何才能驗證用戶體驗是否真的良好呢？僅僅通過性能指標嗎？當然不是，滿足指標只能說明一部分問題，唯有真實的用戶數據和反饋才是可最靠的。

4. 協作

敏捷強調全功能開發團隊的共同協作，但這僅僅止于開發階段。而DevOps注重Dev、Ops和QA三個群體之間的密切協作。因此，良好的角色定位能夠幫助測試人員將價值最大化。

我們是如何做測試的

Laurent曾經在Hiptest上發表了博客《Shift left and shift right: the testing Swing》，提出了一個有意思的測試矩陣，從四個維度進行分析，描述了當軟件開發模式從瀑布到敏捷、再到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》的理念?，F如今，已經有很多工具和方法支持在生產環境做測試了。篇幅太長，這里就不做詳細闡述了，請參考原文。

到這里，再來回顧一下，我們的實踐是否真的卓有成效。

用BDD的方式定義用戶需求、編寫測試，有益于不同角色之間的一致理解和共同協作。

自動化測試解決了頻繁部署所帶來的挑戰，同時保證產品的整體功能持續得到回歸和驗證。

在線監控能有效地驗證不確定需求，通過生產數據分析和預警問題的發生，并且快速獲取用戶反饋從而及時調整。除此之外，這一點也充分體現了Dev、QA和Ops的協作，像監控等原本只能Ops做的事，現在Dev或QA一樣可以做。

寫在最后

測試是一種活動，曾經我們通過它來驗證產品是否達到上線標準。現在DevOps模式下，我們需要在各個階段不斷地執行測試活動，以達到產品質量的持續改進。

而QA（Tester）僅僅是一種較多進行測試活動的角色。敏捷一直強調“團隊為質量負責”，測試不再是QA（Tester）的專屬。DevOps模式更是對測試、尤其是自動化測試提出了更高的要求，也對QA的編碼能力提出了極大的挑戰。作為團隊成員，每個人都有責任了解開發流程、提高測試技能，把好測試這一關。但是，測試活動作為QA（Tester）的主要職責之一，提高自動化測試技能，就是當下每個QA（Tester）最為緊急且重要的事情了。

審核編輯：ymf