本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

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

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

以下各節概述了實作雲端測試策略時可能遇到的挑戰。下列各節概述客戶在嘗試實作雲端測試策略時遇到的挑戰，以及我們實現有效測試涵蓋範圍的最佳實務指引。

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

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

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

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

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

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

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

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