測試無伺服器應用程式時的挑戰

當您使用模擬器和模擬呼叫在本機電腦上測試無伺服器應用程式時，隨著程式碼在 CI/CD 管道中從一個環境進入到另一個環境，您可能會遇到測試不一致的情況。在電腦上建立的用於驗證應用程式業務邏輯的單元測試可能不包括或無法準確表示雲端服務的關鍵方面。完整的測試不能單獨在本機執行。它們需要驗證多個服務之間的許可和組態。

以下各節概述了實作雲端測試策略時可能遇到的挑戰。

範例：建立 S3 儲存貯體的 Lambda 函數

如果 Lambda 函數的邏輯仰賴於建立 S3 儲存貯體，則完整測試應確認已成功呼叫 Amazon S3，且儲存貯體已成功建立。在模擬物件測試設定中，您可能會模擬成功回應，並可能加入測試案例來應對回應失敗的狀況。在模擬測試案例中，可能會呼叫 CreateBucket API，但進行呼叫的身分並不是來自擔任角色的 Lambda 服務，將改用預留位置驗證 – 這通常是更寬鬆的角色或使用者身分。

如果成功地 (或失敗) 呼叫 Amazon S3，先前討論的模擬和仿真設定很可能會測試 Lambda 函數會做什麼。但是，在給定函數組態的情況下，這些測試將無法捕獲 Lambda 函數是否能夠成功建立儲存貯體。此組態可能由基礎設施表示為產品和服務的程式碼 (IaC) AWS CloudFormation AWS SAM，例如，或 HashiCorp Terraform。一個可能的問題是，指派給函數的角色沒有允許 s3:CreateBucket 動作的附接政策，因此該函數在部署到雲端環境時永遠會失敗。

範例：Lambda 函數會處理來自 Amazon SQS 佇列的訊息

如果 Amazon SQS 佇列是 Lambda 函數的來源，則完整測試應驗證訊息放入佇列時是否已成功調用 Lambda 函數。模擬測試和模擬物件測試通常設定為直接執行 Lambda 函數程式碼，並透過傳遞 JSON 事件承載 (或還原序列化物件) 作為函數處理常式的輸入來模擬 Amazon SQS 整合。

模擬 Amazon SQS 整合的本機測試將測試 Amazon SQS 使用指定承載呼叫 Lambda 函數時會執行的動作，但它不能確保 Amazon SQS 在 Lambda 函數部署到雲端環境後能夠成功調用它。

以下是您在使用 Amazon SQS 和 Lambda 時可能會遇到的一些組態問題範例：

• Amazon SQS 可見性逾時過低，導致原本只要調用一次，變成調用多次。

• Lambda 函數的執行角色不允許從佇列讀取訊息 (透過 sqs:ReceiveMessage、sqs:DeleteMessage 或 sqs:GetQueueAttributes)。

• 傳遞至 Lambda 函數的範例事件超出 Amazon SQS 訊息大小配額。因此測試無效，因為 Amazon SQS 永遠無法傳送那麼大的訊息。

如上述範例所示，涵蓋商業邏輯但不涵蓋雲端服務之間組態的測試可能會產生不可靠的結果。