持續測試是 DevOps 開發流程中的重要一環。在很多已經在嘗試進行 DevOps 開發的團隊中，開發人員往往會將測試自動化等同于實施了持續測試，這種觀念其實是錯的。

　　事實上，測試自動化只是持續測試眾多要素中的一部分。實施完整的持續測試，需要一個多維度的測試策略，這些策略涵蓋開發過程中所有需要的測試類型 —— 包括單元、集成、功能、探索性和自動化。持續測試還必須有一個完整的戰略，將測試納入整個 CI/CD (持續集成/持續交付)的流程。

　　DevOps 本質上來說是一系列軟件開發實踐的模型，強調開發人員(Dev)和運維人員(Ops)之間的溝通合作，通過自動化流程，使得軟件構建、測試、交付更加快捷、頻繁和可靠。這種開發模式的特點是可以把產品的每個迭代，或者每修復一個線上缺陷就立即部署到生產環境，這樣一來，開發者就能夠迅速從用戶處獲得反饋并快速做出響應。企業開發團隊轉向 DevOps，必須在不犧牲軟件產品質量的情況下，最大限度地提高交付速度來增加價值和改善用戶體驗，這些都需要在 DevOps 流程中通過實施 CI/CD 流程來實現，而持續測試在這其中發揮著重要的作用。

　　總而言之，持續測試不僅僅是在整個軟件交付流程中執行自動化測試，還需要持續的業務和技術風險分析，以及整個持續集成過程的流程改進和自動化。從本質上來說，持續測試還是伴隨 DevOps 發展出來的一種文化，它要求開發團隊中的每個成員都把產品質量當作是共同的責任。此外，持續測試也是一種管理風險的方法，它可以通過提高測試流程的有效性和效率來消除測試瓶頸。

　　下面是由業內專家總結的持續測試策略四大關鍵步驟：

　　1. 簡化測試流程

　　簡化測試流程包含三部分內容：關注業務風險、解決測試瓶頸以及優化測試。

　　業務風險

　　DevOps 以及持續測試的最終目標都是降低業務風險，而所謂的業務風險實際上是來自于客戶和組織兩方面的風險組成。

　　客戶風險涉及了解應用程序工作流程中哪個環節對客戶來說最為重要，并相應地規劃基于這些環節可能出現風險的測試覆蓋率。

　　組織風險涉及了解商業環境以及產品本身的復雜性。例如，是為了搶占市場而讓產品率先上市重要，還是產品本身的健康度或安全性更重要?

　　一旦準確評估了整體業務風險，開發團隊應該將需求、應用程序組件和測試映射到這些風險中。

　　解決瓶頸

　　在開發測試流程中，識別和緩解可能出現的瓶頸至關重要，這些瓶頸通常是阻礙最終交付產品質量和交付速度最重要的因素。這一過程通常貫穿產品需求到生產上線后的整個軟件開發生命周期。

　　舉幾個例子，比如在某項待辦事項中缺乏測試人員，沒有在這一環節建立驗收標準，沒有及時解決缺陷，導致項目上線延期;比如某自動化測試套件運行時間過長，以及手動完成后期生產檢查，導致效率低下。

　　這一步通常需要開發團隊使用一些自動化工具來解決。自動化測試工具是測試人員用來提高測試效率的輔助工具。

　　就比如在業界家喻戶曉的Selenium ，它被認為是 Web 應用程序用戶界面自動化測試的行業標準。根據"測試自動化挑戰調查"顯示，十分之九的測試人員在其項目中使用或曾經使用過 Selenium。但為了有效地使用 Selenium，用戶必須具備高級編程技能，并且需要花費大量時間來構建自動化所需的自動化框架和庫，這是 Selenium 的主要缺點，雖然可以通過 Katalon Studio 等集成工具解決，但其依然對測試人員的能力提出了較高的要求。

　　對于測試人員并不充足的團隊，也可以使用一些自動化測試平臺來解決測試瓶頸。例如由飛算獨立研發的飛算 SoFlu 全自動軟件工程平臺，其全自動測試平臺提供了測試生命周期管理、測試數據管理和精準回歸測試等一站式自動化測試功能。依托平臺的測試用例自動生成等特性，可以讓測試人員無需編寫腳本，即可快速完成自動化測試工作，提升項目上線效率。

　　優化測試

　　如果說依靠自動化測試工具可以解決團隊在 DevOps 流程中遇到的效率瓶頸，那么測試優化則是在持續測試流程中實施自動化策略的基礎，它要求測試團隊選擇正確的測試方法，這些測試以最少的測試用例提供團隊所需的測試覆蓋率，即從策略層面提升測試的效率。

　　這是一個動態的、持續的過程，尤其是作為連續測試框架的一部分應用時。測試優化應該在自動化之前進行，并且必須在整個連續測試過程中持續進行。第一步通常是通過了解關鍵用戶工作流程中涉及的所有集成來優化測試范圍——包括這些應用程序中采用的技術(網絡、移動、消息/API 層等)。

　　一旦團隊對測試范圍有了清晰的了解，下一步就是優化測試用例。這不僅包括分析測試用例的質量和詳細程度，還包括選擇提供最高測試覆蓋率的測試。團隊的測試套件應設計為以最少的測試用例提供最大的覆蓋量，以提高質量和速度。前文提到的飛算 SoFlu 全自動測試平臺就可以通過錄制工具把測試人員的操作過程記錄下來，并能夠自動識別相關的接口并創建相應的測試用例場景，實現自動優化測試用例。

　　一些團隊默認「每次運行所有的測試」來保證代碼覆蓋率。這不但浪費資源還延長了測試周期，而且沒有真正保證代碼覆蓋率。測試那些需要測試的部分，以節省時間和資源。可視化模型可以讓各種路徑被探索優化，以便只用少量的測試用例就能提供最大化的覆蓋率。

　　2. 在整個 CI 流程中實現自動化測試

　　持續測試需要在整個交付流程中實現測試自動化。測試自動化提高了部署速度并降低了持續交付中固有的風險。

　　但持續測試框架內的自動化不僅僅是開發和維護自動化回歸測試組件。事實上，很多不間斷運行自動化回歸測試組件會在持續部署過程中造成瓶頸。持續測試需要一個測試自動化策略來增強而不是阻礙持續交付過程。

　　例如飛算 SoFlu 全自動測試平臺提供的精準回歸測試功能，該功能在項目測試時能夠自動識別所有變動的接口，自動查找接口關聯的所有測試用例進行精準回歸測試。

　　自動化測試策略必須在構建過程的每一步都包含自動檢查點。首先是驗證單個代碼片段的單元測試和驗證關鍵特性的組件測試。基于風險的回歸測試套件應根據開發者當前正在實施的功能進行定制。

　　在項目上線到生產環境中時，持續測試要求團隊通過部署健康檢查系統來確保應用正常運行，生產監控應在客戶發現之前發現產品的功能和性能問題。

　　總而言之，在持續測試策略中，測試自動化必須設計為高效運行(可利用自動化工具)，同時提供可靠、一致、可重復的結果。

　　3. 左移原則

　　傳統測試主要集中在軟件開發周期的最后，即產品發布之前的集中測試。為了迎合不斷加快的交付頻率，越來越多團隊的測試活動開始向左右兩側移動。一般問題修復成本較高和面向企業收費的軟件，一旦生產環境中出現了問題會造成比較大的損失，通常采取測試左移的方式;對于具有展示功能的軟件產品，更容易在生產環境中發現問題，通常采取測試右移的方式。

　　測試左移是 DevOps 流程中常見的模式，指的是測試人員更早地參與到軟件項目前期的各項活動中，在功能開發之前定義好相關的測試用例，提前發現質量問題。早期引入測試過程有助于防止缺陷，并為開發人員提供在整個開發階段應用動態變更的靈活性。

　　4. 對質量負責

　　這一步是持續測試策略的基礎，它要求團隊中的所有成員(包括開發、測試和運維)都需要為項目的質量負責。

　　業內專家認為，DevOps 中質量保證不再是測試人員的專屬責任，而是全體人員都要為之努力的方向。持續測試的成功實施離不開團隊內部及跨團隊的協作。測試人員需提前介入到開發工作中，與開發人員一起制定測試計劃;開發人員可以參與配置部署;運維人員可以向自動化測試用例庫填寫測試用例;測試人員隨時將自動化測試用例配置到持續交付鏈中，所有成員的共同目的都是交付高效、高質量的產品。

　　這種趨勢也催生了很多自動化開發、測試和運維工具以降低這些領域的技術門檻。同樣以飛算 SoFlu 全自動軟件工程平臺為例，該平臺提供了全自動開發、全自動測試和全自動運維工具，可以管理從需求、研發、測試、部署、上線到運維的整個軟件生命周期，真正實現了軟件工程開發、測試、運維全流程自動化。這種新興的全自動工具降低了開發、測試和運維門檻，能夠幫助任何一家企業快速構建一支 DevOps 開發團隊。

　　DevOps 打破了開發和運維之間的障礙，縮短了開發周期。其中，持續集成、持續測試、持續交付都是提高質量的關鍵催化劑，而持續測試則更具挑戰性。掌握 DevOps 生命周期的持續測試，對于我們充分理解 DevOps 起著至關重要的作用。