項目實施DevOps時，我們是如何做測試的
正如我們所知，DevOps最近幾年很風靡，很多企業(yè)正在如火如荼的推行它。然而，你可曾想過，從傳統(tǒng)到敏捷、再到DevOps，開發(fā)模式的不斷革新對測試提出了怎樣的挑戰(zhàn)?
最近我們項目在實施DevOps，因此想趁熱打鐵，就DevOps模式下如何做測試，談一談自己的認知。
一、DevOps有什么特征
DevOps是一系列軟件開發(fā)實踐，強調開發(fā)人員(Dev)和運維人員(Ops)之間的溝通合作，通過自動化流程，使得軟件構建、測試、發(fā)布更加快捷、頻繁和可靠。
1. DevOps強調一種文化
在很多企業(yè)中，開發(fā)和運維人員通常隸屬于不同部門，有著不同的工作環(huán)境，采用不同的溝通方式，使用不同的開發(fā)或運維工具，并且有著不同的業(yè)務目標，這使得他們之間形成一道參不透的墻。
DevOps實際是一種文化上的變遷，強調開發(fā)、運維、測試等環(huán)節(jié)之間的溝通合作。意在幫助這些人向著一個共同的目標努力：盡可能為公司提供更多價值。為了支持這種合作的發(fā)生，需要在團隊內部文化和企業(yè)組織文化兩個層面做出努力。
2. DevOps是一種實踐
所謂DevOps，就是將敏捷方法延伸到Production!
DevOps主要是為了將敏捷開發(fā)實踐擴展到運維階段，進一步完善軟件構建、驗證、部署、交付等流程，使得跨職能團隊能夠完成從設計到生產支持等各環(huán)節(jié)的工作。
3. DevOps包含一系列工具鏈
DevOps是一種融合了一系列基本原則和實踐的方法論，并從這些實踐中派生出了各種工具。這些工具體現(xiàn)在軟件開發(fā)和交付過程的不同階段：
- 編碼：代碼開發(fā)和審閱，版本控制工具、代碼合并工具
- 構建：持續(xù)集成工具、構建狀態(tài)統(tǒng)計工具
- 測試：通過測試和結果確定績效的工具
- 打包：成品倉庫、應用程序部署前暫存
- 發(fā)布：變更管理、發(fā)布審批、發(fā)布自動化
- 配置：基礎架構配置和部署，基礎架構即代碼工具
- 監(jiān)視：應用程序性能監(jiān)視、最終用戶體驗
二、DevOps對測試提出了哪些挑戰(zhàn)
剛參加工作時，我參與了某Audi系汽車電子的軟件研發(fā)，采用的是傳統(tǒng)瀑布開發(fā)模式。在整個項目生命周期中，前半部分設計和編碼，后半部分用來測試。然而我在東家工作了兩年，也沒能等到產品交付到用戶手上。直到去年，我們的軟件才得以量產并投入市場。在這4年中，產品從未交到用戶手上，因此無法驗證它所帶來的價值，也沒有任何機會得到用戶反饋從而適應變化。
后來，我又參與一個銀行項目，我們采用敏捷的開發(fā)模式，全功能團隊，開發(fā)測試并行，每2-3周就交付一個版本。但因為沒有真正發(fā)布到生產環(huán)境，我們仍然無法及時得到有效的用戶反饋。
現(xiàn)在，我們采用DevOps的優(yōu)秀實踐，開發(fā)和運維協(xié)同工作。每個迭代完成，或者每修復一個線上缺陷就立即部署到生產環(huán)境。這樣，我們就能夠迅速從用戶處獲得反饋并且快速做出響應。
通過參與傳統(tǒng)、敏捷和DevOps的項目，我深深地感受到流程的改進對團隊以及項目的產出和質量所帶來的改變。
那么，這些改變究竟是對測試提出了什么樣的挑戰(zhàn)? 我認為有以下幾點:
1. 頻繁部署
在采用DevOps之后，我們能夠根據(jù)項目具體情況做到每天甚至一天多次部署。在生產環(huán)境頻繁部署軟件，最大的挑戰(zhàn)就是測試。以前，測試基本上都在開發(fā)階段之后和產品上線之前完成。但現(xiàn)在，不再有充足的時間留給QA團隊去發(fā)現(xiàn)問題再拋給開發(fā)團隊來修復。那么，速度成了測試面臨的一大挑戰(zhàn)。
2. 自動化
DevOps強調將流程自動化，測試作為其中一個重要環(huán)節(jié)，勢必要大規(guī)模實現(xiàn)自動化。因此測試人員的自動化編碼能力正在面臨極大的挑戰(zhàn)。
3. 實踐和反饋
敏捷提倡我們要擁抱變化，更多的是要適應需求的不斷變化。雖然一部分功能性需求是明確又具體的，我們清楚的知道用戶想要什么，也因此易于測試。然而，也有一些非功能性需求的驗收標準沒那么明確，比如：提高應用性能達到良好的用戶體驗。我們如何才能驗證用戶體驗是否真的良好呢?僅僅通過性能指標嗎?當然不是，滿足指標只能說明一部分問題，唯有真實的用戶數(shù)據(jù)和反饋才是可最靠的。
4. 協(xié)作
敏捷強調全功能開發(fā)團隊的共同協(xié)作，但這僅僅止于開發(fā)階段。而DevOps注重Dev、Ops和QA三個群體之間的密切協(xié)作。因此，良好的角色定位能夠幫助測試人員將價值最大化。
三、我們是如何做測試的
Laurent曾經在Hiptest上發(fā)表了博客《Shift left and shift right: the testing Swing》，提出了一個有意思的測試矩陣，從四個維度進行分析，描述了當軟件開發(fā)模式從瀑布到敏捷、再到DevOps轉型時，測試該如何響應變化。
Laurent提出一個測試左移和右移的概念:
- 測試左移，就是指在開發(fā)階段之前定義測試。
- 測試右移，就是直接在生產環(huán)境中監(jiān)控，并且實時獲取用戶反饋。
在敏捷開發(fā)的生命周期中，我們通過每一次迭代來豐富和更新產品，以使其最大限度地符合客戶對系統(tǒng)的需求。當時測試的關注點基本停留在開發(fā)階段，以保證產品達到上線標準。引入DevOps之后，我們不僅要關注產品的質量是否達標，還需要使價值假設得到及時的驗證。因此，我們不僅要將測試左移，在開發(fā)環(huán)境驗證功能的可用性，還要進行測試右移，通過監(jiān)控產品在生產環(huán)境的運作情況，來驗證其價值并獲得反饋，從而持續(xù)改進?；谶@些理解，我在項目上做了初步的嘗試并取得良好的效果。我將這些嘗試和實踐總結為以下幾點：
1. 如何保證新功能得以實現(xiàn)?
在開發(fā)環(huán)境，我們開發(fā)新功能，并且通過測試保證其達到產品驗收標準。
首先，使用BDD(Behavior Driven Development，BDD)的方式定義用戶需求，這樣用特定的語言來描述用戶行為，能夠使各個角色(測試、開發(fā)、產品負責人、市場等)對業(yè)務價值達成一致的理解，從而使其從需求到最后的測試驗證，進行高度的協(xié)作和溝通，最后交付最有價值的功能。同時，QA能夠提前Review故事卡，補充驗收標準。除此之外，BDD方式的用戶需求可以直接指導測試，后續(xù)我會寫到。
其次，采用單元測試來驗證最基本的代碼邏輯。在編寫單元測試時，建議Dev和QA Pair工作。單元測試可以認為是編碼的一部分，要對系統(tǒng)的代碼邏輯有深入的了解，因此，Dev是最合適的人選，而QA可以幫助測試覆蓋的更全面。
最后，每一個功能都要嚴格按照故事卡的AC(Acceptance Criteria)進行驗收，并采用探索性測試方法來對新功能進行無死角測試。
2. 怎樣驗證新功能的價值?
我們將新功能部署到生產環(huán)境以后，接下來就應該衡量業(yè)務價值是否達到預期。
驗證預期的一個好方法是衡量用戶的行為變化。比如：在上傳圖片的功能后面添加了一個預覽按鈕，但用戶卻極少用它，很可能是因為用戶根本不需要這個按鈕，或者按鈕放在了不恰當?shù)奈恢脤е掠脩舨环奖闶褂?，亦或是按鈕樣式不夠友好，導致用戶沒有欲望使用它。這時候，該按鈕的業(yè)務價值就沒有真正達到，是時候調整一下了。
3. 如何確保已有功能不被破壞?
在軟件開發(fā)中，任何代碼都不可能完全獨立存在，一行代碼的變更也有可能導致系統(tǒng)的全面崩潰。那么，如何保證在開發(fā)新功能的同時，已有功能不被破壞?換句話說，如何做到全面的回歸測試?人力是最高成本，也有現(xiàn)實的局限性，比如，人手不夠，重復做同樣的事情人會變得煩躁，手不夠快導致效率低下等。因此，自動化測試才是不二選擇。
將BDD需求直接轉化為自動化測試用例。每個測試用例都應該講一個關于應用程序的故事。當一個測試用例使用一致的業(yè)務術語定義時，它的可讀性會比較高，且容易自動化。與此同時，上一個迭代的用例在下一個迭代就可以迅速轉化為回歸測試的基線。
支持BDD的工具有很多，比如：Cucumber。簡單舉個例子，如圖：
BA用BDD方式定義用戶需求，QA Review并補充AC，然后將其編寫為自動化測試腳本。如果QA的編碼能力較弱，可以讓Dev協(xié)助完成代碼實現(xiàn)的部分。這也充分說明了協(xié)作的意義。
最后，也是更重要的部分，測試應該集成在CI中。每一次Build或者每天都要去執(zhí)行測試，驗證已有功能是否完好。這樣才會對沒有預期到的變化產生的問題給出快速反饋。
另外，做一些性能測試、兼容性測試、和安全性測試等等。
4. 怎樣驗證產品的可靠性?
有時候，某些缺陷并不是源于代碼的錯誤，而是一個不好的用戶體驗，或者只有當數(shù)據(jù)達到一定量時才會出現(xiàn)，測試人員是無法模擬這種類型的測試的，因此直接在生產環(huán)境監(jiān)控變得高效又可靠。通常我們需要監(jiān)控兩種特性：性能和可用性。
使用工具持續(xù)獲取用戶數(shù)據(jù)，或者使用log持續(xù)獲取性能信息。這有助于監(jiān)控產品部署到生產環(huán)境后是如何正確運作的?？焖賳⒂靡粋€功能，在生產環(huán)境實時監(jiān)控驗證其業(yè)務價值，獲取到有效且快速的用戶反饋，加之擁有持續(xù)部署的能力，我們能夠在出現(xiàn)問題的時候快速做出反應，從而使得我們的產品更加可靠。
這里實際上融入了《QA in Production》的理念。現(xiàn)如今，已經有很多工具和方法支持在生產環(huán)境做測試了。篇幅太長，這里就不做詳細闡述了，請參考原文。
到這里，再來回顧一下，我們的實踐是否真的卓有成效。
- 用BDD的方式定義用戶需求、編寫測試，有益于不同角色之間的一致理解和共同協(xié)作。
- 自動化測試解決了頻繁部署所帶來的挑戰(zhàn)，同時保證產品的整體功能持續(xù)得到回歸和驗證。
- 在線監(jiān)控能有效地驗證不確定需求，通過生產數(shù)據(jù)分析和預警問題的發(fā)生，并且快速獲取用戶反饋從而及時調整。除此之外，這一點也充分體現(xiàn)了Dev、QA和Ops的協(xié)作，像監(jiān)控等原本只能Ops做的事，現(xiàn)在Dev或QA一樣可以做。
四、寫在最后
測試是一種活動，曾經我們通過它來驗證產品是否達到上線標準?，F(xiàn)在DevOps模式下，我們需要在各個階段不斷地執(zhí)行測試活動，以達到產品質量的持續(xù)改進。
而QA(Tester)僅僅是一種較多進行測試活動的角色。敏捷一直強調“團隊為質量負責”，測試不再是QA(Tester)的專屬。DevOps模式更是對測試、尤其是自動化測試提出了更高的要求，也對QA的編碼能力提出了極大的挑戰(zhàn)。作為團隊成員，每個人都有責任了解開發(fā)流程、提高測試技能，把好測試這一關。但是，測試活動作為QA(Tester)的主要職責之一，提高自動化測試技能，就是當下每個QA(Tester)最為緊急且重要的事情了。
【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉載請聯(lián)系原作者】
