# 持續整合和持續交付的測試階段
三個 CI/CD 團隊應將測試整合到 CI/CD 管道中不同階段的軟體開發生命週期內。整體而言，測試應盡早開始。以下的測試金字塔，是由 Mike Cohn 在《*敏捷帶來成功*》中提供的概念。其顯示了各種軟體測試與其成本和執行速度的關係。
*CI/CD 測試金字塔*
單元測試位於金字塔的底部。其不僅執行速度最快，也是最便宜的。因此，單元測試應在您的測試策略中佔絶大部分。根據良好的經驗法則大約為 70%。由於此階段發現的錯誤可以快速且修正成本低，所以應為幾近整個程式碼都進行單元測試。
服務、元件和整合測試，在金字塔中位於單元測試之上。由於這些測試需要詳盡的環境，因此在基礎設施需求部分成本較高，且執行速度較慢。效能和合規測試則為下一個層級。由於其需要具備生產品質的環境，因此較為昂貴。UI 和使用者接受度測試則位於金字塔的頂端，也需要生產品質的環境。
所有這些測試都是確保軟體高品質的完整策略之一部分。但針對開發速度而言，應強調位於金字塔下半部的測試數量及涵蓋範圍。
下列各章節會討論 CI/CD 階段。
## 設定原始檔
在專案開始時，設定可存放原始程式碼及組態和結構描述變更的原始檔，相當重要。請在原始檔階段選擇原始檔儲存庫，例如託管在 GitHub 或 AWS CodeCommit 的儲存庫。
## 設定及執行建置
建置自動化對 CI 程序而言相當重要。在設定建置自動化時，首要任務就是選擇正確的建置工具。有許多建置工具可供選擇，例如：
+ 適用於 Java 的 Ant、Maven 及 Gradle
+ 適用於 C/C\+\+ 的 Make
+ 適用於 JavaScript 的 Grunt
+ 適用於 Ruby 的 Rake
最適合您的建置工具取決於您專案的程式設計語言，以及您團隊的技能程度。選擇建置工具後，需要在建置指令碼中清楚定義所有相依性及建置步驟。對最終的建置成品進行版本控制，以易於部署及追蹤問題，也是一項最佳實務。
## 建置
在建置階段，建置工具會將所有對原始程式碼儲存庫進行的變更當作輸入、建置軟體，並執行下列類型的測試：
**單元測試 ‒** 測試特定程式碼區段，確保該程式碼能如預期般運作。單元測試由軟體開發人員在開發階段執行。在此階段可運用靜態程式碼分析、資料流程分析、程式碼涵蓋範圍，以及其他軟體驗證程序。
**靜態程式碼分析 ‒** 在建置及進行單元測試後，會在不實際執行應用程式的情況下執行這項測試。這項分析有助於找出編碼錯誤及安全漏洞，也能確保符合編碼準則的規定。
## 預備
在預備階段，會建立完整且和最終生產環境完全一樣的環境。此階段會執行下列測試：
**整合測試** ‒ 驗證元件與軟體設計之間的界面。整合測試是一項反覆的程序，有助於建置健全的界面及系統完整性。
**元件測試** ‒ 測試在不同元件之間傳遞訊息，以及結果如何。這項測試的關鍵目標可能是元件測試中的冪等。測試可包含極為龐大的資料量，或是極端情況及異常輸入。
**系統測試** ‒ 測試系統的端對端，並驗證軟體是否滿足業務需求。這可能包含測試使用者界面 (UI)、API、後端邏輯及結束狀態。
**效能測試 ‒** 判斷系統在執行特定工作負載時的回應能力及穩定性。效能測試也可用於調查、評量、驗證或確定其他系統的品質屬性，例如可擴展性、可靠性及資源使用量。效能測試的類型也可能包含負載測試、壓力測試和尖峰測試。效能測試可用於針對預先定義的條件進行基準化比對。
**合規測試 ‒** 檢查程式碼變更是否符合非功能規格及 (或) 法規的需求。這項測試會判斷您的實作符合定義的標準。
**使用者接受度測試 ‒** 驗證端對端業務流程。這項測試由最終使用者在預備環境中執行，並確認系統是否符合需求規格的需求。通常，客戶會在此階段採用 Alpha 和 Beta 測試方法。
## 生產
最後，在通過先前各項測試後，會在生產環境內重複預備階段。在此階段可先透過只在少部分的伺服器或甚至只在一部伺服器或一個 AWS 區域上，部署新的程式碼來進行 *Canary 測試*，然後再將程式碼部署到整個生產環境。[部署方法](deployment-methods.md)一節涵蓋了有關如何安全地部署至生產環境的特定資訊。
下一節會討論建置管道以整合這些階段和測試。