正如我們所知，DevOps最近幾年很風(fēng)靡，很多企業(yè)正在如火如荼的推行它。然而，你可曾想過，從傳統(tǒng)到敏捷、再到DevOps，開發(fā)模式的不斷革新對測試提出了怎樣的挑戰(zhàn)？

最近我們項目在實施DevOps，因此想趁熱打鐵，就DevOps模式下如何做測試，談一談自己的認知。

DevOps有什么特征

DevOps是一系列軟件開發(fā)實踐，強調(diào)開發(fā)人員（Dev）和運維人員（Ops）之間的溝通合作，通過自動化流程，使得軟件構(gòu)建、測試、發(fā)布更加快捷、頻繁和可靠。

1. DevOps強調(diào)一種文化

在很多企業(yè)中，開發(fā)和運維人員通常隸屬于不同部門，有著不同的工作環(huán)境，采用不同的溝通方式，使用不同的開發(fā)或運維工具，并且有著不同的業(yè)務(wù)目標，這使得他們之間形成一道參不透的墻。

DevOps實際是一種文化上的變遷，強調(diào)開發(fā)、運維、測試等環(huán)節(jié)之間的溝通合作。意在幫助這些人向著一個共同的目標努力：盡可能為公司提供更多價值。為了支持這種合作的發(fā)生，需要在團隊內(nèi)部文化和企業(yè)組織文化兩個層面做出努力。

2. DevOps是一種實踐

所謂DevOps，就是將敏捷方法延伸到Production!

DevOps主要是為了將敏捷開發(fā)實踐擴展到運維階段，進一步完善軟件構(gòu)建、驗證、部署、交付等流程，使得跨職能團隊能夠完成從設(shè)計到生產(chǎn)支持等各環(huán)節(jié)的工作。

3. DevOps包含一系列工具鏈

DevOps是一種融合了一系列基本原則和實踐的方法論，并從這些實踐中派生出了各種工具。這些工具體現(xiàn)在軟件開發(fā)和交付過程的不同階段：

編碼：代碼開發(fā)和審閱，版本控制工具、代碼合并工具

構(gòu)建：持續(xù)集成工具、構(gòu)建狀態(tài)統(tǒng)計工具

測試：通過測試和結(jié)果確定績效的工具

打包：成品倉庫、應(yīng)用程序部署前暫存

發(fā)布：變更管理、發(fā)布審批、發(fā)布自動化

配置：基礎(chǔ)架構(gòu)配置和部署，基礎(chǔ)架構(gòu)即代碼工具

監(jiān)視：應(yīng)用程序性能監(jiān)視、最終用戶體驗

DevOps對測試提出了哪些挑戰(zhàn)

剛參加工作時，我參與了某Audi系汽車電子的軟件研發(fā)，采用的是傳統(tǒng)瀑布開發(fā)模式。在整個項目生命周期中，前半部分設(shè)計和編碼，后半部分用來測試。然而我在東家工作了兩年，也沒能等到產(chǎn)品交付到用戶手上。直到去年，我們的軟件才得以量產(chǎn)并投入市場。在這4年中，產(chǎn)品從未交到用戶手上，因此無法驗證它所帶來的價值，也沒有任何機會得到用戶反饋從而適應(yīng)變化。

后來，我又參與一個銀行項目，我們采用敏捷的開發(fā)模式，全功能團隊，開發(fā)測試并行，每2-3周就交付一個版本。但因為沒有真正發(fā)布到生產(chǎn)環(huán)境，我們?nèi)匀粺o法及時得到有效的用戶反饋。

現(xiàn)在，我們采用DevOps的優(yōu)秀實踐，開發(fā)和運維協(xié)同工作。每個迭代完成，或者每修復(fù)一個線上缺陷就立即部署到生產(chǎn)環(huán)境。這樣，我們就能夠迅速從用戶處獲得反饋并且快速做出響應(yīng)。

通過參與傳統(tǒng)、敏捷和DevOps的項目，我深深地感受到流程的改進對團隊以及項目的產(chǎn)出和質(zhì)量所帶來的改變。

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

1. 頻繁部署

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

2. 自動化

DevOps強調(diào)將流程自動化，測試作為其中一個重要環(huán)節(jié)，勢必要大規(guī)模實現(xiàn)自動化。因此測試人員的自動化編碼能力正在面臨極大的挑戰(zhàn)。

3. 實踐和反饋

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

4. 協(xié)作

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

我們是如何做測試的

Laurent曾經(jīng)在Hiptest上發(fā)表了博客《Shift left and shift right: the testing Swing》，提出了一個有意思的測試矩陣，從四個維度進行分析，描述了當(dāng)軟件開發(fā)模式從瀑布到敏捷、再到DevOps轉(zhuǎn)型時，測試該如何響應(yīng)變化。

Laurent提出一個測試左移和右移的概念:

測試左移，就是指在開發(fā)階段之前定義測試。

測試右移，就是直接在生產(chǎn)環(huán)境中監(jiān)控，并且實時獲取用戶反饋。

在敏捷開發(fā)的生命周期中，我們通過每一次迭代來豐富和更新產(chǎn)品，以使其最大限度地符合客戶對系統(tǒng)的需求。當(dāng)時測試的關(guān)注點基本停留在開發(fā)階段，以保證產(chǎn)品達到上線標準。引入DevOps之后，我們不僅要關(guān)注產(chǎn)品的質(zhì)量是否達標，還需要使價值假設(shè)得到及時的驗證。因此，我們不僅要將測試左移，在開發(fā)環(huán)境驗證功能的可用性，還要進行測試右移，通過監(jiān)控產(chǎn)品在生產(chǎn)環(huán)境的運作情況，來驗證其價值并獲得反饋，從而持續(xù)改進?；谶@些理解，我在項目上做了初步的嘗試并取得良好的效果。我將這些嘗試和實踐總結(jié)為以下幾點：

1.如何保證新功能得以實現(xiàn)？

在開發(fā)環(huán)境，我們開發(fā)新功能，并且通過測試保證其達到產(chǎn)品驗收標準。

首先，使用BDD（Behavior Driven Development，BDD）的方式定義用戶需求，這樣用特定的語言來描述用戶行為，能夠使各個角色（測試、開發(fā)、產(chǎn)品負責(zé)人、市場等）對業(yè)務(wù)價值達成一致的理解，從而使其從需求到最后的測試驗證，進行高度的協(xié)作和溝通，最后交付最有價值的功能。同時，QA能夠提前Review故事卡，補充驗收標準。除此之外，BDD方式的用戶需求可以直接指導(dǎo)測試，后續(xù)我會寫到。

其次，采用單元測試來驗證最基本的代碼邏輯。在編寫單元測試時，建議Dev和QA Pair工作。單元測試可以認為是編碼的一部分，要對系統(tǒng)的代碼邏輯有深入的了解，因此，Dev是最合適的人選，而QA可以幫助測試覆蓋的更全面。

最后，每一個功能都要嚴格按照故事卡的AC（Acceptance Criteria）進行驗收，并采用探索性測試方法來對新功能進行無死角測試。

2.怎樣驗證新功能的價值？

我們將新功能部署到生產(chǎn)環(huán)境以后，接下來就應(yīng)該衡量業(yè)務(wù)價值是否達到預(yù)期。

驗證預(yù)期的一個好方法是衡量用戶的行為變化。比如：在上傳圖片的功能后面添加了一個預(yù)覽按鈕，但用戶卻極少用它，很可能是因為用戶根本不需要這個按鈕，或者按鈕放在了不恰當(dāng)?shù)奈恢脤?dǎo)致用戶不方便使用，亦或是按鈕樣式不夠友好，導(dǎo)致用戶沒有欲望使用它。這時候，該按鈕的業(yè)務(wù)價值就沒有真正達到，是時候調(diào)整一下了。

3.如何確保已有功能不被破壞？

在軟件開發(fā)中，任何代碼都不可能完全獨立存在，一行代碼的變更也有可能導(dǎo)致系統(tǒng)的全面崩潰。那么，如何保證在開發(fā)新功能的同時，已有功能不被破壞？換句話說，如何做到全面的回歸測試？人力是最高成本，也有現(xiàn)實的局限性，比如，人手不夠，重復(fù)做同樣的事情人會變得煩躁，手不夠快導(dǎo)致效率低下等。因此，自動化測試才是不二選擇。

將BDD需求直接轉(zhuǎn)化為自動化測試用例。每個測試用例都應(yīng)該講一個關(guān)于應(yīng)用程序的故事。當(dāng)一個測試用例使用一致的業(yè)務(wù)術(shù)語定義時，它的可讀性會比較高，且容易自動化。與此同時，上一個迭代的用例在下一個迭代就可以迅速轉(zhuǎn)化為回歸測試的基線。

支持BDD的工具有很多，比如：Cucumber。簡單舉個例子，如圖：

BA用BDD方式定義用戶需求，QA Review并補充AC，然后將其編寫為自動化測試腳本。如果QA的編碼能力較弱，可以讓Dev協(xié)助完成代碼實現(xiàn)的部分。這也充分說明了協(xié)作的意義。

最后，也是更重要的部分，測試應(yīng)該集成在CI中。每一次Build或者每天都要去執(zhí)行測試，驗證已有功能是否完好。這樣才會對沒有預(yù)期到的變化產(chǎn)生的問題給出快速反饋。

另外，做一些性能測試、兼容性測試、和安全性測試等等。

4.怎樣驗證產(chǎn)品的可靠性？

有時候，某些缺陷并不是源于代碼的錯誤，而是一個不好的用戶體驗，或者只有當(dāng)數(shù)據(jù)達到一定量時才會出現(xiàn)，測試人員是無法模擬這種類型的測試的，因此直接在生產(chǎn)環(huán)境監(jiān)控變得高效又可靠。通常我們需要監(jiān)控兩種特性：性能和可用性。

使用工具持續(xù)獲取用戶數(shù)據(jù)，或者使用log持續(xù)獲取性能信息。這有助于監(jiān)控產(chǎn)品部署到生產(chǎn)環(huán)境后是如何正確運作的?？焖賳⒂靡粋€功能，在生產(chǎn)環(huán)境實時監(jiān)控驗證其業(yè)務(wù)價值，獲取到有效且快速的用戶反饋，加之擁有持續(xù)部署的能力，我們能夠在出現(xiàn)問題的時候快速做出反應(yīng)，從而使得我們的產(chǎn)品更加可靠。

這里實際上融入了《QA in Production》的理念。現(xiàn)如今，已經(jīng)有很多工具和方法支持在生產(chǎn)環(huán)境做測試了。篇幅太長，這里就不做詳細闡述了，請參考原文。

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

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

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

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

寫在最后

測試是一種活動，曾經(jīng)我們通過它來驗證產(chǎn)品是否達到上線標準?，F(xiàn)在DevOps模式下，我們需要在各個階段不斷地執(zhí)行測試活動，以達到產(chǎn)品質(zhì)量的持續(xù)改進。

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

審核編輯：ymf