正如我們所知，DevOps最近幾年很風(fēng)靡枝缔，很多企業(yè)正在如火如荼的推行它布疙。然而，你可曾想過(guò)，從傳統(tǒng)到敏捷灵临、再到DevOps拣挪，開發(fā)模式的不斷革新對(duì)測(cè)試提出了怎樣的挑戰(zhàn)？
最近我們項(xiàng)目在實(shí)施DevOps俱诸，因此想趁熱打鐵菠劝，就DevOps模式下如何做測(cè)試，談一談自己的認(rèn)知睁搭。
DevOps有什么特征
DevOps是一系列軟件開發(fā)實(shí)踐赶诊，強(qiáng)調(diào)開發(fā)人員（Dev）和運(yùn)維人員（Ops）之間的溝通合作，通過(guò)自動(dòng)化流程园骆，使得軟件構(gòu)建舔痪、測(cè)試、發(fā)布更加快捷锌唾、頻繁和可靠锄码。
1. DevOps強(qiáng)調(diào)一種文化
在很多企業(yè)中，開發(fā)和運(yùn)維人員通常隸屬于不同部門晌涕，有著不同的工作環(huán)境滋捶，采用不同的溝通方式，使用不同的開發(fā)或運(yùn)維工具余黎，并且有著不同的業(yè)務(wù)目標(biāo)重窟，這使得他們之間形成一道參不透的墻。
DevOps實(shí)際是一種文化上的變遷惧财，強(qiáng)調(diào)開發(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主要是為了將敏捷開發(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)在軟件開發(fā)和交付過(guò)程的不同階段：
- 編碼：代碼開發(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)瀑布開發(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)目尸疆，我們采用敏捷的開發(fā)模式椿猎，全功能團(tuán)隊(duì)，開發(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í)踐，開發(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è)試基本上都在開發(fā)階段之后和產(chǎn)品上線之前完成鞭达。但現(xiàn)在，不再有充足的時(shí)間留給QA團(tuán)隊(duì)去發(fā)現(xiàn)問(wèn)題再拋給開發(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)全功能開發(fā)團(tuán)隊(duì)的共同協(xié)作，但這僅僅止于開發(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)軟件開發(fā)模式從瀑布到敏捷、再到DevOps轉(zhuǎn)型時(shí)喘批，測(cè)試該如何響應(yīng)變化撩荣。
Laurent提出一個(gè)測(cè)試左移和右移的概念:
- 測(cè)試左移铣揉，就是指在開發(fā)階段之前定義測(cè)試饶深。
- 測(cè)試右移餐曹，就是直接在生產(chǎn)環(huán)境中監(jiān)控，并且實(shí)時(shí)獲取用戶反饋敌厘。
在敏捷開發(fā)的生命周期中台猴，我們通過(guò)每一次迭代來(lái)豐富和更新產(chǎn)品，以使其最大限度地符合客戶對(duì)系統(tǒng)的需求俱两。當(dāng)時(shí)測(cè)試的關(guān)注點(diǎn)基本停留在開發(fā)階段饱狂，以保證產(chǎn)品達(dá)到上線標(biāo)準(zhǔn)。引入DevOps之后宪彩，我們不僅要關(guān)注產(chǎn)品的質(zhì)量是否達(dá)標(biāo)休讳，還需要使價(jià)值假設(shè)得到及時(shí)的驗(yàn)證。因此尿孔，我們不僅要將測(cè)試左移俊柔，在開發(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)错维？
在開發(fā)環(huán)境，我們開發(fā)新功能橄唬，并且通過(guò)測(cè)試保證其達(dá)到產(chǎn)品驗(yàn)收標(biāo)準(zhǔn)需五。
首先，使用BDD（Behavior Driven Development轧坎，BDD）的方式定義用戶需求宏邮，這樣用特定的語(yǔ)言來(lái)描述用戶行為，能夠使各個(gè)角色（測(cè)試缸血、開發(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.如何確保已有功能不被破壞边篮？
在軟件開發(fā)中，任何代碼都不可能完全獨(dú)立存在奏甫，一行代碼的變更也有可能導(dǎo)致系統(tǒng)的全面崩潰戈轿。那么，如何保證在開發(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é)任了解開發(fā)流程寸认、提高測(cè)試技能，把好測(cè)試這一關(guān)串慰。但是偏塞，測(cè)試活動(dòng)作為QA（Tester）的主要職責(zé)之一，提高自動(dòng)化測(cè)試技能模庐，就是當(dāng)下每個(gè)QA（Tester）最為緊急且重要的事情了烛愧。
作者：ThoughtWorks史湘陽(yáng)
