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