持續測試效能的方法

持續測試是指在軟體開發生命週期中的不同階段納入自動反饋的過程，其中包括探索性測試等自動化測試外的活動。持續測試是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、執行和監控

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

三、寫在最後

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

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