持續測試是指在軟件開發生命週期中的不同階段納入自動反饋的過程，其中包括探索性測試等自動化測試外的活動。持續測試是CI/CD流程取得成效的關鍵因素，通過提高代碼質量來避免付出多餘的人力、物力和財力，從而加快DevOps流程。在Dan Ashby創建的DevOps持續測試模型圖（如圖1）中，他表明我們可以在任何一個階段進行測試。

對於持續測試存在一個誤區：持續測試就是測試左移。這是兩種不同的方法，測試左移是指將測試活動在軟件開發生命週期中的介入時機向前推動，以便儘早發現問題。持續測試與測試左移是兩種不同的方法，因此測試左移不能作為不執行持續測試的藉口。

本篇文章將重點説明：

• 什麼是持續測試。
• 如何實施持續性能測試 。

一、 什麼是持續測試

“持續測試是指每次代碼更改時定期執行的自動化測試，這些測試作為軟件交付的一部分進行，以推動對推送到代碼存儲庫的最新更改進行更快的反饋。”這是BrowserStack對持續測試的定義，也是大多數組織通常所採用的定義。

雖然自動化測試在實現持續測試方面發揮着重要作用，但持續測試並不只是包括自動化測試這麼簡單。

根據圖1中的持續測試模型圖的左側，通過提前開始討論和質疑需求來檢驗計劃，這個過程就能夠進行測試。通過在本地拉取代碼並探索功能來測試分支，也能夠進行測試。此外，當進行代碼審查並確保自動化測試的有效性時，同樣會就會發生測試，甚至測試還發生在合併和構建過程中。

另一方面，圖1中持續測試模型的右側顯示，一旦更改發佈並部署，測試也會持續進行。如果使用金絲雀發佈或藍綠部署等部署技術，這些技術也會經過測試以確保部署成功。當更改部署到生產環境中後，真實用户會不斷測試這些更改。但測試並不止於此，還發生在監控階段，通過收集指標和數據來持續推動改進。

持續測試不只是自動測試，還可以在其他測試模式中實現，例如軟件開發生命週期之前進行測試的想法。持續測試需要建立在開放學習、協作的團隊文化中，必須鼓勵團隊成員嘗試不同的方法，並確定哪種方法適合團隊的測試需求。

二、 如何實施持續性能測試

傳統方法的性能測試是如何進行的，為什麼這種方法的測試不能很好地擴展？

傳統的性能測試被視為發佈到生產之前的最後一項活動。它在驗證系統的主要功能之後進行，並需要一組專門的性能測試人員。然而，由於性能測試位於最後階段，一旦性能測試期間發現任何Bug，修復這些Bug就需要付出多餘的人力、物力和財力。此外，隨着功能的快速開發和發佈需求，傳統的性能測試方法難以融入到敏捷模式中。

那麼，如何實施持續性能測試方法呢？通過引入自動化性能測試，在添加新更改時自動觸發是不夠的。我們要記住持續測試不僅是指自動化測試，參考Dan Ashby的持續測試模型，我們可以將性能測試納入軟件開發生命週期的各個階段。

1、規劃

在討論中將性能要求作為每個功能的一部分，並根據現有服務級別協議（SLA）創建驗收標準和已制定的服務級別目標（SLO）是很重要的。如果沒有SLA或SLO，團隊可以一起合作制定這些SLA和SLO。

同時，考慮將性能要求納入到完成定義（DoD）中，這可以提高團隊對性能的認識，確保性能需求在開發的每個功能中得到充分考慮。

2、分支及編碼

團隊成員可以審查代碼並檢查可能出現的任何性能瓶頸。同時，在開發代碼的同時編寫自動化性能測試也是非常有用的。在此階段，性能測試主要是針對較低級別的組件進行的，而不是全面的端到端性能測試。團隊成員可以從性能角度對的組件進行，例如：

• 專注於協議級別的測試，不涉及UI。
• 針對特定的API端點進行測試，並觀察隨着負載逐漸增加，響應時間的變化。
• 通過提前執行壓力或峯值測試來查找API端點的痛點。

除了自動化測試之外，還可以嘗試配對測試，並在本地探索應用程序，以發現自動化測試無法發現的性能問題，例如檢查應用程序的感知性能。

3、合併

當開發人員將代碼推動到構建步驟並在某些情況下引入功能環境時，利用快速可靠的自動化測試來實現快速反饋循環非常重要。

從性能角度來看，作為CI/CD的一部分，可以運行前一階段確定的組件性能測試。開發人員還可以這些測試到冒煙性能測試中，以驗證應用程序在承受最小負載時的運行情況。

從後端性能的角度來看，這些測試應該以更少的虛擬用户或更短的持續時間運行。如果專注於前端或客户端性能，還可以使用專門針對客户端性能的工具，在幾個頁面上運行基本檢查以獲取數據。

4、構建

當功能合併到主分支時，可以進行更多接近用户體驗的性能測試。測試或開發人員應該專注於端到端性能測試，而不只是組件級的性能測試，因為需要驗證典型用户在使用過程中可能進行的主要流程。以下是一些從性能角度進行的端到端測試示例：

• 每次將代碼部署到臨時環境時，自動運行平均負載測試，以評估系統在典型負載下的性能。
• 運行端到端性能測試來模擬用户的完整使用流程，並在後端服務面臨高負載時找到瀏覽器級別的瓶頸。在這個階段，性能測試更加現實，並嘗試模擬典型用户的行為。
• 可以選擇手動觸發壓力、峯值或持續性能測試，將其集成到CI上。
• 如果將結果集成到可視化儀表板中，團隊可以持續觀察性能趨勢，並使用數據通知是否可以安全地將代碼部署到生產環境中。

5、發佈和部署

當功能在生產中發佈時，可以通過運行狀況測試來驗證部署是否成功。在某些公司中，可能沒有適合進行性能測試的預生產環境，因此可以選擇在生產環境中進行測試。

為了避免對用户造成的干擾，可以在商定的窗口期間（如非高峯時段）進行負載測試，這可以確保在測試期間不會對用户的正常使用產生負面影響。

6、運行和監控

一旦代碼上線，用户會不斷地對其進行測試。為了瞭解與性能相關的用户痛點，建立一個渠道來獲取用户反饋，將其納入下一個迭代中。同時，擁有監控解決方案也是持續測試的一種方法。這可以實時獲得用户遇到的性能問題，例如頁面響應時間過慢、在不同數據服務上出現的請求失敗等。

三、寫在最後

這並不是一成不變的，而是作為參考指南提供。持續測試並不意味着自動化的性能測試，而是在軟件開發的整個生命週期中嵌入和不斷改進性能，以便我們在各個階段都能瞭解產品的性能。

通過持續測試，我們可以及時發現和解決性能問題，確保產品在不同階段都能滿足性能需求。這有助於提高用户體驗、減少用户痛點，併為產品的穩定性和可靠性打下堅實基礎。