一說起 DevOps，闖入腦海的就是CI/CD（Continuous Integration/Continuous Delivery，即持續(xù)集成和持續(xù)交付）。
但是，要想構(gòu)建能夠支撐起數(shù)字化轉(zhuǎn)型要求的軟件研發(fā)能力，與之適配的軟件測(cè)試能力必不可少。
隨著敏捷宣言的發(fā)布，業(yè)界開始提倡測(cè)試驅(qū)動(dòng)開發(fā)、驗(yàn)收測(cè)試驅(qū)動(dòng)開發(fā)，開始關(guān)注自動(dòng)化測(cè)試，加強(qiáng)測(cè)試工具和測(cè)試框架的開發(fā)，盡可能做到回歸測(cè)試自動(dòng)化、測(cè)試管理自動(dòng)化。
而DevOps 的興起之后，人們更是要求測(cè)試要有“左移”和“右移”的能力，還要求在線測(cè)試（Test in Production，TIP）等。
于是，Continuous Testing（持續(xù)測(cè)試）走進(jìn)我們視線中。
01 測(cè)試已死？“持續(xù)測(cè)試”才是未來
在 GTAC 2011的一場(chǎng)名為《測(cè)試已死》的演講中，Alberto Savoia 描述了幾個(gè)測(cè)試人員必須要面對(duì)的開發(fā)趨勢(shì)：
首先，所有的checking工作（包括validation和verification）都可以自動(dòng)化；其次，隨著云計(jì)算出現(xiàn)，部分用戶可以在云上對(duì)開發(fā)版本做出測(cè)試；最后，開發(fā)者自己做測(cè)試幾乎是不可避免的趨勢(shì)。
在演講中，Alberto Savoia 認(rèn)為傳統(tǒng)的QA方式隔離了開發(fā)和測(cè)試并不合理
在傳統(tǒng)測(cè)試方法中，測(cè)試團(tuán)隊(duì)通常采用的實(shí)踐是：測(cè)試管理- 規(guī)劃測(cè)試工作-識(shí)別需要的測(cè)試-創(chuàng)建手動(dòng)測(cè)試-收集現(xiàn)有測(cè)試-執(zhí)行測(cè)試-跟蹤和報(bào)告測(cè)試進(jìn)度。
因此，傳統(tǒng)測(cè)試需要關(guān)注的是：測(cè)試工作是否按計(jì)劃完成？
其中的缺點(diǎn)也是顯而易見的。首先，手動(dòng)運(yùn)行所有測(cè)試是低效或無效的，在許多情況下不可行；其次，這個(gè)方法并沒有服務(wù)于軟件開發(fā)項(xiàng)目，無法創(chuàng)建穩(wěn)健且可維護(hù)的測(cè)試自動(dòng)化框架，沒法實(shí)現(xiàn)最終的項(xiàng)目目標(biāo)。
而這些問題在敏捷和DevOps時(shí)代，得到了足夠重視。
敏捷的出現(xiàn)，大大引入了自動(dòng)化測(cè)試的比例。因此，敏捷時(shí)期的測(cè)試呈現(xiàn)出以底層運(yùn)行速度快、消耗小的單元測(cè)試為主的正三角模式；強(qiáng)調(diào)測(cè)試持續(xù)進(jìn)行，通過各部門的協(xié)同工作，持續(xù)發(fā)現(xiàn)缺陷并迅速修復(fù)。
到了DevOps時(shí)代，“持續(xù)測(cè)試”的概念涌現(xiàn)，在這個(gè)概念中，測(cè)試應(yīng)該是開發(fā)過程的一部分，而不是在開發(fā)完成后的“保健”任務(wù)。
持續(xù)測(cè)試是持續(xù)交付流水線中的一環(huán)，讓開發(fā)過程可隨時(shí)且具有連續(xù)性的自動(dòng)化測(cè)試流程。但是，持續(xù)測(cè)試并不等同于自動(dòng)化測(cè)試，而是大于自動(dòng)化測(cè)試。IBM認(rèn)為，測(cè)試自動(dòng)化與服務(wù)虛擬化的組合稱為 “持續(xù)測(cè)試”。
在整個(gè)持續(xù)交付流程中，包括了計(jì)劃、編碼、構(gòu)建、測(cè)試、發(fā)布、部署、運(yùn)維和監(jiān)控8個(gè)環(huán)節(jié)，既要求“速度”也要求“質(zhì)量”。其中，持續(xù)測(cè)試保障的就是整個(gè)開發(fā)流程的質(zhì)量問題。
總的來說，持續(xù)測(cè)試需要在正確的時(shí)機(jī)將可行的反饋意見提供給正確的利益相關(guān)，側(cè)重于業(yè)務(wù)風(fēng)險(xiǎn)，并提供有關(guān)軟件是否可以發(fā)布的見解。
因此，持續(xù)測(cè)試關(guān)注的是：提供的有關(guān)軟件是否可以發(fā)布？
02 “持續(xù)測(cè)試” 的7個(gè)方法論
“持續(xù)測(cè)試”雖好，但建立持續(xù)測(cè)試文化需要投入人員、實(shí)踐、工具和時(shí)間。
1.持續(xù)測(cè)試的完整時(shí)間，需要取得公司高層的支持，制定清晰的轉(zhuǎn)型戰(zhàn)略、建立指導(dǎo)團(tuán)隊(duì)。
2.建設(shè)內(nèi)容包括：研發(fā)團(tuán)隊(duì)測(cè)試能力建設(shè)、工具與框架建設(shè)以及最佳實(shí)踐落地。
3.整個(gè)過程需要通過合理量化跟蹤體系，去量化持續(xù)測(cè)試建設(shè)的進(jìn)展和影響。
以下七個(gè)方面，是構(gòu)建持續(xù)測(cè)試的關(guān)鍵：
1、You can’t continuously if you don’t start testing early.
發(fā)現(xiàn)bug的時(shí)間越早越好。在測(cè)試中，盡早發(fā)現(xiàn)了風(fēng)險(xiǎn)元素，就可以不斷重用這些測(cè)試、盡早地直接向開發(fā)團(tuán)隊(duì)提供代碼質(zhì)量的迭代式反饋。
在生命周期中，更早和更頻繁地執(zhí)行測(cè)試（“提前測(cè)試”），使團(tuán)隊(duì)能夠持續(xù)地編譯、部署、測(cè)試和收集反饋。
而在生產(chǎn)中發(fā)現(xiàn)問題時(shí)，不僅解決成本非常高，而且可能嚴(yán)重?fù)p害公司的聲譽(yù)，甚至對(duì)客戶忠誠度產(chǎn)生持久的影響。如果沒有及時(shí)的測(cè)試和反饋，公司就無法真正地快速提高質(zhì)量。
2、開發(fā)級(jí)測(cè)試至關(guān)重要
在一定程度上，開發(fā)與測(cè)試的確日漸融合，這樣可以確保開發(fā)得到快速的反饋，而且保障了結(jié)果符合預(yù)期。
在持續(xù)集成中，們測(cè)試反饋越及時(shí)，越來越多的測(cè)試操作，例如靜態(tài)或者動(dòng)態(tài)分析、security checks、API validation……越可能被納入其中，被集中的信息越豐富，項(xiàng)目的結(jié)果就越有保障。
3、自動(dòng)化是提速降本的利器
執(zhí)行過程要達(dá)到“足夠快”，以滿足整體迭代的效率。這要求每個(gè)階段都引入盡可能多的自動(dòng)化工具和能力。比如，云平臺(tái)提倡基礎(chǔ)設(shè)施即代碼（IaC）和容器領(lǐng)域的編排技術(shù)（以K8s為代表）都在一定程度上實(shí)現(xiàn)了環(huán)境的自動(dòng)化部署。
近來，國內(nèi)外也涌現(xiàn)了不少針對(duì)測(cè)試的自動(dòng)化工具及平臺(tái)。以國內(nèi)的飛算SoFlu全自動(dòng)軟件工程平臺(tái)為例，近期上線的全自動(dòng)測(cè)試平臺(tái)主要通過創(chuàng)建項(xiàng)目—創(chuàng)建測(cè)試用例—編輯測(cè)試場(chǎng)景—創(chuàng)建測(cè)試計(jì)劃—接口測(cè)試—性能測(cè)試這6步流程來實(shí)現(xiàn)。
據(jù)了解，該平臺(tái)具備三大特性：一是測(cè)試生命周期管理。它提供測(cè)試用例管理、測(cè)試用例評(píng)審、測(cè)試計(jì)劃跟蹤和測(cè)試報(bào)告生成等測(cè)試生命周期管理相關(guān)功能。二是測(cè)試數(shù)據(jù)管理。全自動(dòng)測(cè)試平臺(tái)基于測(cè)試腳本與測(cè)試數(shù)據(jù)分離的思路，方便研發(fā)測(cè)試協(xié)同、方便自動(dòng)化測(cè)試中的測(cè)試數(shù)據(jù)使用，支持 UI、接口等自動(dòng)化工具中快速可重復(fù)地使用。三是精準(zhǔn)回歸測(cè)試。它在項(xiàng)目測(cè)試時(shí)，可以自動(dòng)識(shí)別所有變動(dòng)接口，自動(dòng)查找接口關(guān)聯(lián)的所有測(cè)試用例，進(jìn)行精準(zhǔn)回歸測(cè)試。
值得注意的是，全自動(dòng)測(cè)試平臺(tái)隨其全自動(dòng)開發(fā)平臺(tái)聯(lián)動(dòng)，開發(fā)測(cè)試一鍵關(guān)聯(lián)，自動(dòng)生成測(cè)試用例完成軟件測(cè)試，1 人就即可完成開發(fā)、測(cè)試整套流程。
4、服務(wù)虛擬化是穩(wěn)定性的重點(diǎn)
用戶被測(cè)系統(tǒng)通常并不孤立存在，它依賴各種外部系統(tǒng)才能正常運(yùn)行。但是在測(cè)試環(huán)節(jié)中，這些外部系統(tǒng)依賴可能會(huì)因?yàn)楦鞣N原因而不具備支持持續(xù)測(cè)試正常運(yùn)行。
服務(wù)虛擬化是解決自動(dòng)化測(cè)試中外部依賴不穩(wěn)定或者不可得的關(guān)鍵手段。
服務(wù)虛擬化需要能夠快速、準(zhǔn)確地模擬外部依賴系統(tǒng)。從而，只需明確測(cè)試需求，而不需要太多關(guān)注真實(shí)的業(yè)務(wù)邏輯。此外，服務(wù)虛擬化尤其注重自身的穩(wěn)定性。它的初衷是解決外部系統(tǒng)依賴的穩(wěn)定性和可獲得性，如果其自身不夠穩(wěn)定，就無法支撐持續(xù)測(cè)試的高效、高頻運(yùn)行。
5、快使用虛擬機(jī)和容器技術(shù)
虛擬機(jī)通過機(jī)器鏡像解決整個(gè)運(yùn)行機(jī)器的環(huán)境管理，而容器技術(shù)則采用更為輕量的運(yùn)行時(shí)封裝模式構(gòu)建。
這樣就可以屏蔽業(yè)務(wù)系統(tǒng)依賴的底層基礎(chǔ)設(shè)施差異，研發(fā)團(tuán)隊(duì)只需要管理好虛擬機(jī)和容器的鏡像版本，基本就能保障多個(gè)測(cè)試環(huán)境的一致性。
目前，好用的容器包括Docker、 Mesos或者 LXC等等，他們大多都擁有很高的適配性。
6、從產(chǎn)品的角度開展測(cè)試
正如前文所述，充分考慮到產(chǎn)品最終形態(tài)，也就是產(chǎn)品偏向，是“持續(xù)測(cè)試”的特點(diǎn)之一。因此，在測(cè)試設(shè)計(jì)階段，就應(yīng)該開始向生產(chǎn)思維的配置靠近，去模擬產(chǎn)品類似的測(cè)試氛圍。
7、逐步進(jìn)化測(cè)試數(shù)據(jù)管理
如何處理好測(cè)試數(shù)據(jù)，往往是一個(gè)重大的挑戰(zhàn)。很多情況下，人們不知道什么樣的數(shù)據(jù)是測(cè)試所需要的、什么樣的數(shù)字管理是好的。
簡單來說，測(cè)試數(shù)據(jù)管理隨著DevOps實(shí)踐的深入程度，呈現(xiàn)出4個(gè)階段：
第一階段：測(cè)試數(shù)據(jù)以個(gè)人管理為主，生成機(jī)制隨機(jī)，質(zhì)量無法保障。
第二階段：通過文件或者數(shù)據(jù)庫形成初步的測(cè)試數(shù)據(jù)集中管理，但是無合理的版本管理機(jī)制，無數(shù)據(jù)生成和質(zhì)量保障機(jī)制。
第三階段：有集中的測(cè)試數(shù)據(jù)管理平臺(tái)，平臺(tái)數(shù)據(jù)進(jìn)行合理的版本管理，有較為豐富的數(shù)據(jù)生成和生產(chǎn)數(shù)據(jù)脫敏機(jī)制，數(shù)據(jù)質(zhì)量穩(wěn)定。
第四階段：測(cè)試數(shù)據(jù)集中管理，數(shù)據(jù)版本和質(zhì)量可靠，測(cè)試數(shù)據(jù)與測(cè)試用例和自動(dòng)化測(cè)試場(chǎng)景形成良好關(guān)聯(lián)和互動(dòng)。
當(dāng)然，隨著持續(xù)測(cè)試實(shí)踐的程度越高，我們所要求的測(cè)試數(shù)據(jù)管理能力自然也就越高。
