持續(xù)測試是DevOps開發(fā)流程中的重要一環(huán)。在很多已經在嘗試進行DevOps開發(fā)的團隊中，開發(fā)人員往往會將測試自動化等同于實施了持續(xù)測試，這種觀念其實是錯的。
事實上，測試自動化只是持續(xù)測試眾多要素中的一部分。實施完整的持續(xù)測試，需要一個多維度的測試策略，這些策略涵蓋開發(fā)過程中所有需要的測試類型——包括單元、集成、功能、探索性和自動化。持續(xù)測試還必須有一個完整的戰(zhàn)略，將測試納入整個CI/CD（持續(xù)集成/持續(xù)交付）的流程。
DevOps本質上來說是一系列軟件開發(fā)實踐的模型，強調開發(fā)人員（Dev）和運維人員（Ops）之間的溝通合作，通過自動化流程，使得軟件構建、測試、交付更加快捷、頻繁和可靠。這種開發(fā)模式的特點是可以把產品的每個迭代，或者每修復一個線上缺陷就立即部署到生產環(huán)境，這樣一來，開發(fā)者就能夠迅速從用戶處獲得反饋并快速做出響應。企業(yè)開發(fā)團隊轉向DevOps，必須在不犧牲軟件產品質量的情況下，最大限度地提高交付速度來增加價值和改善用戶體驗，這些都需要在DevOps流程中通過實施CI/CD流程來實現(xiàn)，而持續(xù)測試在這其中發(fā)揮著重要的作用。
總而言之，持續(xù)測試不僅僅是在整個軟件交付流程中執(zhí)行自動化測試，還需要持續(xù)的業(yè)務和技術風險分析，以及整個持續(xù)集成過程的流程改進和自動化。從本質上來說，持續(xù)測試還是伴隨DevOps發(fā)展出來的一種文化，它要求開發(fā)團隊中的每個成員都把產品質量當作是共同的責任。此外，持續(xù)測試也是一種管理風險的方法，它可以通過提高測試流程的有效性和效率來消除測試瓶頸。
下面是由業(yè)內專家總結的持續(xù)測試策略四大關鍵步驟：
1、簡化測試流程
簡化測試流程包含三部分內容：關注業(yè)務風險、解決測試瓶頸，以及優(yōu)化測試。
業(yè)務風險：
DevOps以及持續(xù)測試的最終目標都是降低業(yè)務風險，而所謂的業(yè)務風險實際上是來自于客戶和組織兩方面的風險組成。
客戶風險涉及了解應用程序工作流程中哪個環(huán)節(jié)對客戶來說最為重要，并相應地規(guī)劃基于這些環(huán)節(jié)可能出現(xiàn)風險的測試覆蓋率。
組織風險涉及了解商業(yè)環(huán)境以及產品本身的復雜性。例如，是為了搶占市場而讓產品率先上市重要，還是產品本身的健康度或安全性更重要？
一旦準確評估了整體業(yè)務風險，開發(fā)團隊應該將需求、應用程序組件和測試映射到這些風險中。
解決瓶頸：
在開發(fā)測試流程中，識別和緩解可能出現(xiàn)的瓶頸至關重要，這些瓶頸通常是阻礙最終交付產品質量和交付速度最重要的因素。這一過程通常貫穿產品需求到生產上線后的整個軟件開發(fā)生命周期。
舉幾個例子，比如在某項待辦事項中缺乏測試人員，沒有在這一環(huán)節(jié)建立驗收標準，沒有及時解決缺陷，導致項目上線延期；比如某自動化測試套件運行時間過長，以及手動完成后期生產檢查，導致效率低下。
這一步通常需要開發(fā)團隊使用一些自動化工具來解決。自動化測試工具是測試人員用來提高測試效率的輔助工具。
就比如在業(yè)界家喻戶曉的Selenium，它被認為是Web應用程序用戶界面自動化測試的行業(yè)標準。根據“測試自動化挑戰(zhàn)調查”顯示，十分之九的測試人員在其項目中使用或曾經使用過Selenium。但為了有效地使用Selenium，用戶必須具備高級編程技能，并且需要花費大量時間來構建自動化所需的自動化框架和庫，這是Selenium的主要缺點，雖然可以通過Katalon Studio等集成工具解決，但其依然對測試人員的能力提出了較高的要求。
對于測試人員并不充足的團隊，也可以使用一些自動化測試平臺來解決測試瓶頸。例如由飛算獨立研發(fā)的飛算SoFlu全自動軟件工程平臺，其全自動測試平臺提供了測試生命周期管理、測試數(shù)據管理和精準回歸測試等一站式自動化測試功能。依托平臺的測試用例自動生成等特性，可以讓測試人員無需編寫腳本，即可快速完成自動化測試工作，提升項目上線效率。
優(yōu)化測試：
如果說依靠自動化測試工具可以解決團隊在DevOps流程中遇到的效率瓶頸，那么測試優(yōu)化則是在持續(xù)測試流程中實施自動化策略的基礎，它要求測試團隊選擇正確的測試方法，這些測試以最少的測試用例提供團隊所需的測試覆蓋率，即從策略層面提升測試的效率。
這是一個動態(tài)的、持續(xù)的過程，尤其是作為連續(xù)測試框架的一部分應用時。測試優(yōu)化應該在自動化之前進行，并且必須在整個連續(xù)測試過程中持續(xù)進行。第一步通常是通過了解關鍵用戶工作流程中涉及的所有集成來優(yōu)化測試范圍——包括這些應用程序中采用的技術（網絡、移動、消息/API層等）。
一旦團隊對測試范圍有了清晰的了解，下一步就是優(yōu)化測試用例。這不僅包括分析測試用例的質量和詳細程度，還包括選擇提供最高測試覆蓋率的測試。團隊的測試套件應設計為以最少的測試用例提供最大的覆蓋量，以提高質量和速度。前文提到的飛算SoFlu全自動測試平臺就可以通過錄制工具把測試人員的操作過程記錄下來，并能夠自動識別相關的接口并創(chuàng)建相應的測試用例場景，實現(xiàn)自動優(yōu)化測試用例。
一些團隊默認「每次運行所有的測試」來保證代碼覆蓋率。這不但浪費資源還延長了測試周期，而且沒有真正保證代碼覆蓋率。測試那些需要測試的部分，以節(jié)省時間和資源?？梢暬Ｐ涂梢宰尭鞣N路徑被探索優(yōu)化，以便只用少量的測試用例就能提供最大化的覆蓋率。
2、在整個CI流程中實現(xiàn)自動化測試
持續(xù)測試需要在整個交付流程中實現(xiàn)測試自動化。測試自動化提高了部署速度并降低了持續(xù)交付中固有的風險。
但持續(xù)測試框架內的自動化不僅僅是開發(fā)和維護自動化回歸測試組件。事實上，很多不間斷運行自動化回歸測試組件會在持續(xù)部署過程中造成瓶頸。持續(xù)測試需要一個測試自動化策略來增強而不是阻礙持續(xù)交付過程。
例如飛算SoFlu全自動測試平臺提供的精準回歸測試功能，該功能在項目測試時能夠自動識別所有變動的接口，自動查找接口關聯(lián)的所有測試用例進行精準回歸測試。
自動化測試策略必須在構建過程的每一步都包含自動檢查點。首先是驗證單個代碼片段的單元測試和驗證關鍵特性的組件測試?；陲L險的回歸測試套件應根據開發(fā)者當前正在實施的功能進行定制。
在項目上線到生產環(huán)境中時，持續(xù)測試要求團隊通過部署健康檢查系統(tǒng)來確保應用正常運行，生產監(jiān)控應在客戶發(fā)現(xiàn)之前發(fā)現(xiàn)產品的功能和性能問題。
總而言之，在持續(xù)測試策略中，測試自動化必須設計為高效運行（可利用自動化工具），同時提供可靠、一致、可重復的結果。
3、左移原則
傳統(tǒng)測試主要集中在軟件開發(fā)周期的最后，即產品發(fā)布之前的集中測試。為了迎合不斷加快的交付頻率，越來越多團隊的測試活動開始向左右兩側移動。一般問題修復成本較高和面向企業(yè)收費的軟件，一旦生產環(huán)境中出現(xiàn)了問題會造成比較大的損失，通常采取測試左移的方式；對于具有展示功能的軟件產品，更容易在生產環(huán)境中發(fā)現(xiàn)問題，通常采取測試右移的方式。
測試左移是DevOps流程中常見的模式，指的是測試人員更早地參與到軟件項目前期的各項活動中，在功能開發(fā)之前定義好相關的測試用例，提前發(fā)現(xiàn)質量問題。早期引入測試過程有助于防止缺陷，并為開發(fā)人員提供在整個開發(fā)階段應用動態(tài)變更的靈活性。
4、對質量負責
這一步是持續(xù)測試策略的基礎，它要求團隊中的所有成員（包括開發(fā)、測試和運維）都需要為項目的質量負責。
業(yè)內專家認為，DevOps中質量保證不再是測試人員的專屬責任，而是全體人員都要為之努力的方向。持續(xù)測試的成功實施離不開團隊內部及跨團隊的協(xié)作。測試人員需提前介入到開發(fā)工作中，與開發(fā)人員一起制定測試計劃；開發(fā)人員可以參與配置部署；運維人員可以向自動化測試用例庫填寫測試用例；測試人員隨時將自動化測試用例配置到持續(xù)交付鏈中，所有成員的共同目的都是交付高效、高質量的產品。
這種趨勢也催生了很多自動化開發(fā)、測試和運維工具以降低這些領域的技術門檻。同樣以飛算SoFlu全自動軟件工程平臺為例，該平臺提供了全自動開發(fā)、全自動測試和全自動運維工具，可以管理從需求、研發(fā)、測試、部署、上線到運維的整個軟件生命周期，真正實現(xiàn)了軟件工程開發(fā)、測試、運維全流程自動化。這種新興的全自動工具降低了開發(fā)、測試和運維門檻，能夠幫助任何一家企業(yè)快速構建一支DevOps開發(fā)團隊。
DevOps打破了開發(fā)和運維之間的障礙，縮短了開發(fā)周期。其中，持續(xù)集成、持續(xù)測試、持續(xù)交付都是提高質量的關鍵催化劑，而持續(xù)測試則更具挑戰(zhàn)性。掌握DevOps生命周期的持續(xù)測試，對于我們充分理解DevOps起著至關重要的作用。
下載文檔
