隨著無伺服器應用程式規模的擴大，測試策略的設計對於維持交付速度至關重要。傳統的測試方法往往難以適應無伺服器架構的特性，因此需要針對常見的錯誤模式，例如 IAM 許可權不足、API Gateway 端點請求失敗、Lambda 函式超時以及 DynamoDB 或 EventBridge 的操作錯誤，制定相應的測試方案。同時，識別應用程式中的關鍵路徑，並將測試資源集中於這些對業務至關重要的使用者經驗上，才能在有限的資源下最大化測試效益。
伺服器無伺服器應用程式的測試策略
當伺服器無伺服器應用程式規模擴大時，為新的功能和迴歸測試新增更多測試將會成為交付速度的最大瓶頸。過多的測試集將嚴重拖慢工程師和管道的速度。因此，您需要找到一個方法，在預佈署測試和生產環境中的可觀察性和還原力之間取得平衡。
測試策略的重要性
定義一個明確的測試策略以幫助工程師瞭解什麼需要測試以及何時測試它是非常重要的。沒有這種策略，測試集和預發布環境可能會迅速失控，並使開發和交付速度大大減慢。
伺服器無伺服器失敗模式和影響分析
要決定伺服器無伺服器應用程式的適當測試策略，您首先需要了解可能出錯的地方。由於伺服器無伺服器應用程式中廣泛使用管理服務，因此瞭解您和 AWS 之間的責任劃分也很重要。
常見伺服器無伺服器失敗模式
- 不足夠的 IAM 許可權：這是一個非常常見的問題，通常以「未經授權的操作」或「存取被拒絕」錯誤為表現，當資源嘗試執行未經授權的操作時。
- API Gateway 端點請求失敗：這可能由於與 Lambda 函式處理程式或超時時間（目前為 HTTP API 的 30 秒和 REST API 的 29 秒）不匹配的整合組態引起。
- Lambda 函式呼叫超時或超出記憶體組態：函式呼叫也可能因為超出帳戶範圍內的最大並發執行數而受到限制。
- DynamoDB 作業失敗：這可能由於透過 AWS SDK 的不正確語法或檔案路徑引起。讀寫作業也可能因為在流量尖峰期間超出相關容量單元而受到限制。
- EventBridge 規則呼叫失敗：如果目標組態不正確，事件匯流排可能無法攝取事件，尤其是當事件有效載荷大小超過 256 KB（目前的限制）時。
設計伺服器無伺服器測試策略
任何伺服器無伺服器測試策略都必須考慮伺服器無伺服器應用程式的獨特屬性，並最佳化以支援伺服器無伺服器工程工作流程。盡早在應用程式生命週期中制定測試策略對於開發的可擴充套件性和穩定性至關重要。
識別關鍵路徑
關鍵路徑通常是對業務營運至關重要的使用者經驗。識別應用程式中的關鍵路徑可以幫助您決定如何應用伺服器無伺服器平衡方格並集中工程資源。
關鍵路徑的特點
- 使用者通常存在於某個請求的關鍵路徑中。
- 這些請求通常是時間敏感的，需要同步回應。
- 在關鍵路徑中，從故障中還原（或容錯能力）是一種較少可行的策略，用於支援應用程式的品質。重新嘗試請求可能會增加延遲到不可接受的水平，而且當使用者不再存在或無法提供明確許可時，您重新嘗試這些操作的能力將會降低。
關鍵路徑的品質保證
關鍵路徑的營運品質應主要透過廣泛的測試涵蓋範圍和警示來支援。您必須盡量減少傳送到這些微服務的錯誤數量。
瞭解Serverless應用程式的測試策略
在Serverless應用程式中，測試策略的設計至關重要。由於Serverless應用程式的特性，傳統的測試方法可能不再適用。以下是Serverless應用程式測試策略的重點：
測試覆寫率的限制
測試覆寫率不應該過高。過高的測試覆寫率可能會導致測試時間過長，從而影響工程生產力。因此，應該限制測試覆寫率，僅測試最關鍵的使用者經驗。
測試型別
Serverless應用程式中，應該優先使用靜態測試，例如單元測試和靜態分析。這些測試不需要佈署微服務到雲端，可以更快速地執行。
Just-In-Time測試
Just-In-Time測試是指在程式碼即將佈署到生產環境時進行測試。這種方法可以確保程式碼在生產環境中能夠正常執行，並且可以快速地發現和修復錯誤。
環境數量的限制
傳統的軟體測試方法通常需要多個預生產環境，但是在Serverless應用程式中，這種方法可能不再適用。應該限制環境數量，理想情況下，只需要一個或兩個環境。
持續整合和持續交付
持續整合和持續交付是Serverless應用程式中非常重要的概念。應該盡可能地頻繁地整合程式碼變更，並且盡可能地快速地將程式碼佈署到生產環境。
完成定義
完成定義是指當一個產品待辦事項滿足品質措施時，即可視為完成。這種方法可以確保程式碼變更在佈署到生產環境之前已經滿足品質要求。
什麼是「完成」？
在軟體開發中，「完成」是一個相對的概念。軟體永遠不會完美，總會有 bug 存在。《完成宣言》（The Cult of Done Manifesto）是一個激勵人心的資源，幫助你完成任務。第 12 點特別適合於無伺服器軟體工程：「如果你有了一個想法並將其釋出在網際網路上，那就等於是一個『完成』的幽靈。」這可以被解釋為將「完成」定義為將東西呈現給使用者。它不需要是完整和完美的，最重要的是它正在收集使用資料，以便於未來的改進。
深入剖析無伺服器應用程式測試策略的核心，從底層架構到使用者經驗，可以發現有效平衡測試覆寫率、速度和成本至關重要。本文探討了常見的無伺服器失敗模式，如IAM許可權不足、API Gateway端點錯誤、Lambda函式超時以及資料函式庫操作失敗等，並強調了識別關鍵路徑的重要性。針對關鍵路徑，建議採取廣泛的測試和嚴格的監控，以確保核心業務流程的穩定性。
對於非關鍵路徑，則可採用更精簡的測試策略，例如Just-In-Time測試、單元測試和靜態分析，以提升開發效率並降低測試成本。同時，限制預發布環境的數量，並實施持續整合/持續交付流程，有助於簡化佈署流程並加快交付速度。此外，本文也探討了「完成」的定義，建議以使用者價值為導向，將產品上線並收集實際使用資料作為迭代改進的基礎，而非追求完美的測試覆寫率。
展望未來，隨著無伺服器技術的持續發展，測試策略也需不斷演進。預期將出現更多自動化測試工具和框架，以簡化測試流程並提升測試效率。同時，混沌工程等技術的應用，將有助於更全面地評估系統的韌性和容錯能力。玄貓認為，在資源有限的情況下，優先將測試資源集中於關鍵路徑，並結合自動化測試和持續交付，才能最大化無伺服器應用程式的商業價值。
