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

最近我們項(xiàng)目在實(shí)施DevOps，因此想趁熱打鐵，就DevOps模式下如何做測(cè)試，談一談自己的認(rèn)知。

DevOps有什么特征

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

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

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

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

2. DevOps是一種實(shí)踐

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

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

3. DevOps包含一系列工具鏈

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

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

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

測(cè)試：通過(guò)測(cè)試和結(jié)果確定績(jī)效的工具

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

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

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

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

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

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

后來(lái)，我又參與一個(gè)銀行項(xiàng)目，我們采用敏捷的開(kāi)發(fā)模式，全功能團(tuán)隊(duì)，開(kāi)發(fā)測(cè)試并行，每2-3周就交付一個(gè)版本。但因?yàn)闆](méi)有真正發(fā)布到生產(chǎn)環(huán)境，我們?nèi)匀粺o(wú)法及時(shí)得到有效的用戶反饋。

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

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

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

1. 頻繁部署

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

2. 自動(dòng)化

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

3. 實(shí)踐和反饋

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

4. 協(xié)作

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

我們是如何做測(cè)試的

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

Laurent提出一個(gè)測(cè)試左移和右移的概念:

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

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

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

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

在開(kāi)發(fā)環(huán)境，我們開(kāi)發(fā)新功能，并且通過(guò)測(cè)試保證其達(dá)到產(chǎn)品驗(yàn)收標(biāo)準(zhǔn)。

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

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

最后，每一個(gè)功能都要嚴(yán)格按照故事卡的AC（Acceptance Criteria）進(jìn)行驗(yàn)收，并采用探索性測(cè)試方法來(lái)對(duì)新功能進(jìn)行無(wú)死角測(cè)試。

2.怎樣驗(yàn)證新功能的價(jià)值？

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

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

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

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

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

支持BDD的工具有很多，比如：Cucumber。簡(jiǎn)單舉個(gè)例子，如圖：

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

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

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

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

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

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

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

到這里，再來(lái)回顧一下，我們的實(shí)踐是否真的卓有成效。

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

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

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

寫在最后

測(cè)試是一種活動(dòng)，曾經(jīng)我們通過(guò)它來(lái)驗(yàn)證產(chǎn)品是否達(dá)到上線標(biāo)準(zhǔn)。現(xiàn)在DevOps模式下，我們需要在各個(gè)階段不斷地執(zhí)行測(cè)試活動(dòng)，以達(dá)到產(chǎn)品質(zhì)量的持續(xù)改進(jìn)。

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

審核編輯：ymf