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

如何測試無伺服器函數和應用程式

測試無伺服器函數會使用傳統的測試類型和技術，但您也必須考慮測試整個無伺服器應用程式。雲端測試提供函數和無伺服器應用程式最精確的品質測量。

無伺服器應用程式架構包括透過 API 呼叫提供關鍵應用程式功能的受管服務。因此，您的開發週期應包括自動化測試，以便在函數和服務互動時驗證功能。

如果您未建立以雲端為基礎的測試，則可能會因本機環境與部署環境之間的差異而遇到問題。您的持續整合程序應先針對雲端佈建的一組資源進行測試，然後再將程式碼升級至下一個部署環境 (例如 QA、暫存或生產環境)。

繼續閱讀這份簡短指南，了解無伺服器應用程式的測試策略，或造訪無伺服器測試範例儲存庫，深入了解所選語言和執行期的特定實際範例。

對於無伺服器測試，您仍然會寫入單元、整合和end-to-end測試。

目標業務成果

測試無伺服器解決方案可能需要更多時間來設定。您必須驗證服務之間的事件驅動型互動。閱讀本指南時，請謹記這些實際的商業原因：

應用程式的品質取決於測試許多案例。考慮您的業務案例，並自動化針對雲端服務執行的測試。這會提高應用程式的品質。

在開發週期早期發現的錯誤和組態問題成本較低。在生產之前未偵測到的問題需要更多精力和更多人進行修正。

良好的無伺服器測試策略可改善軟體品質並加速反覆運算。它會驗證您的 Lambda 函數和應用程式在雲端中是否如預期般運作。

測試項目

我們建議採用測試策略，以測試受管服務行為、雲端組態、安全政策，以及與您的程式碼整合。行為測試也稱為黑框測試，會驗證系統是否如預期運作，而不了解內部。

在傳統的伺服器型架構中， 團隊通常只會測試應用程式伺服器上執行的程式碼。他們會將其他元件、服務或相依性視為外部且超出範圍。

無伺服器應用程式由少量工作單位組成。範例包括從資料庫擷取產品的 Lambda 函數、處理佇列中的項目，或調整儲存中的映像大小。每個元件都在自己的環境中執行。團隊會在單一應用程式中管理許多這些小型單位。

某些功能可以完全由 Amazon S3 等受管服務處理，也可以在沒有自訂程式碼的情況下建置。您不需要測試這些受管服務。不過，您必須測試程式碼與程式碼的整合方式。

如何測試無伺服器

您可能知道如何測試本機部署的應用程式。您可以在桌面或容器內針對程式碼撰寫測試。例如，您可以呼叫本機 Web 服務，然後檢查回應。

無伺服器解決方案使用您的函數程式碼和雲端型受管服務，例如佇列、資料庫、事件匯流排和簡訊系統。這些元件透過事件驅動架構進行連線，其中稱為事件的訊息會從一個資源流向另一個資源。有些互動是同步的，例如會立即傳回結果的 Web 服務。

其他則是非同步的，例如在佇列中放置項目或啟動工作流程步驟。您的測試策略必須涵蓋這兩種類型，並測試服務之間的互動。對於非同步互動，您可能需要偵測下游元件中無法立即顯示的副作用。

您無法在本機完全複寫雲端環境。這包括佇列、資料庫資料表、事件匯流排和安全政策。本機環境和雲端環境之間的差異會導致問題。這些差異會增加重現和修正錯誤的時間。

在無伺服器應用程式中，元件完全存在於雲端中。需要針對雲端程式碼和服務進行測試，以開發功能並修正錯誤。

測試技術

您的測試策略可能包含技術組合。您可以使用快速互動式測試來偵錯 主控台中的 函數。您編寫自動化單元測試來檢查商業邏輯。您可以使用模擬驗證對外部服務的呼叫。您也可以針對模擬服務的模擬器進行測試。

在雲端進行測試

在雲端進行測試對於測試的所有階段都很重要：單元測試、整合測試和end-to-end測試。針對雲端程式碼和服務執行的測試可提供最精確的程式碼品質測量。

在雲端中執行 Lambda 函數的簡單方法是在 中使用測試事件 AWS 管理主控台。一個測試事件是函數的 JSON 輸入。如果您的函數不需要輸入，則事件可以是空白的 JSON 文件 ({})。主控台為許多服務整合提供範例事件。您可以與團隊共用事件，讓測試更容易。

了解如何 在主控台中偵錯範例函數。

您可以在 無伺服器測試範例儲存庫 中取得測試自動化範例。下列命令列會執行自動化的 Python 整合測試範例：

python -m pytest -s tests/integration -v

雖然測試會在本機執行，但它會與雲端型資源交談。這些資源是使用 AWS Serverless Application Model 和 AWS SAM 命令列工具進行部署。測試程式碼會先擷取部署的堆疊輸出，例如 API 端點、函數 ARN 和安全角色。

然後，它會傳送請求到 API 端點。回應包含 Amazon S3 儲存貯體的清單。此測試會針對雲端型資源執行，以驗證這些資源是否已部署、保護和運作。

========================= test session starts =========================
      platform darwin -- Python 3.10.10, pytest-7.3.1, pluggy-1.0.0
      -- /Users/t/code/aws/serverless-test-samples/python-test-samples/apigw-lambda/venv/bin/python
      cachedir: .pytest_cache
      rootdir: /Users/t/code/aws/serverless-test-samples/python-test-samples/apigw-lambda
      plugins: mock-3.10.0
      collected 1 item                                                                                                        

      tests/integration/test_api_gateway.py::TestApiGateway::test_api_gateway 

      --> Stack outputs:

        HelloWorldApi
        = https://p7teqs3162.execute-api.us-east-2.amazonaws.com/Prod/hello/
        > API Gateway endpoint URL for Prod stage for Hello World function

        PythonTestDemo
        = arn:aws:lambda:us-east-2:123456789012:function:testing-apigw-lambda-PythonTestDemo-iSij8evaTdxl
        > Hello World Lambda Function ARN

        PythonTestDemoIamRole
        = arn:aws:iam::123456789012:role/testing-apigw-lambda-PythonTestDemoRole-IZELQQ9MG4HQ
        > Implicit IAM Role created for Hello World function

      --> Found API endpoint for "testing-apigw-lambda" stack...
      --> https://p7teqs3162.execute-api.us-east-2.amazonaws.com/Prod/hello/
      API Gateway response:
      amplify-dev-123456789-deployment|myapp-prod-p-loggingbucket-123456|s3-java-bucket-123456789
      PASSED

      ========================= 1 passed in 1.53s ========================= 
      

若是開發雲端原生應用程式，則在雲端進行測試可獲得以下優勢：

在雲端進行測試確實有一些缺點。雲端部署通常需要比本機桌面部署更長的時間。

AWS 無伺服器應用程式模型 (AWS SAM) Accelerate、AWS 雲端開發套件 (AWS CDK) 監看模式和 SST （第三方） 等工具可降低此延遲。這些工具會監控您的基礎設施和程式碼，然後自動將更新部署到您的雲端環境。

與本機測試不同，雲端測試使用可能會產生成本的資源。隔離的測試環境可能會為您的 DevOps 團隊新增工作，尤其是在具有嚴格帳戶控制的組織。即使如此，開發人員設定複雜本機環境的時間，可能比使用以基礎設施做為程式碼工具建置的一次性雲端環境還要昂貴。

即使有這些考量，在雲端進行測試仍然是保證無伺服器解決方案品質的 最佳作法。

透過模擬物件進行測試

使用模擬物件進行測試是一種技術，您可以在程式碼中建立替代物件，來模擬雲端服務的行為。

例如，您可以撰寫使用 Amazon S3 服務模擬的測試。每當呼叫 CreateObject 方法時，模擬會傳回集合回應。它不會呼叫 Amazon S3 或任何其他服務端點。

模擬架構通常會為您產生模擬物件。有些架構是通用的。其他 AWS SDKs，例如 Moto，用於模擬 AWS 服務的 Python 程式庫。

模擬物件與模擬器不同。開發人員會在測試程式碼中建立模擬。模擬器是獨立應用程式，公開與其模擬系統相同的功能。

以下是使用模擬物件的優勢：

以下是模擬物件測試的缺點：

使用 AWS SAM CLI 進行本機測試

使用 AWS SAM CLI 在 Docker 容器中測試函式，這些容器使用與 AWS Lambda相同的執行時期環境。您可以在本機測試函式邏輯與事件處理，無需部署至雲端。如果您的函數對其他 發出 API 呼叫 AWS 服務，則這些呼叫會到達實際 AWS 的資源。

使用本機容器進行測試的優勢包括：

使用本機容器進行測試存在以下限制：

透過模擬進行測試

模擬器是在本機執行的應用程式，透過提供類似的 APIs 和傳回值來模擬 AWS 服務。LocalStack 是一種熱門的模擬工具，可提供完整的本機開發環境來測試服務間的整合運作。

LocalStack 是一種 AWS 雲端模擬器，可用於在本機測試無伺服器應用程式。您可以測試與 DynamoDB、Amazon S3 和 Amazon SQS 等服務整合的 Lambda 函數，而無需連線到實際 AWS 服務。您可以在 AWS Toolkit for VS Code 中使用 LocalStack。

以下是使用模擬器進行測試的優點：

以下是使用模擬器進行測試的缺點：

最佳實務

下列各節提供成功測試無伺服器應用程式的建議。

您可以在 無伺服器測試範例儲存庫 中找到測試和測試自動化的實際範例。

排定雲端測試的優先順序

在雲端進行測試可提供最可靠、精準且完整的測試涵蓋範圍。在雲端環境中執行測試不僅全面測試商業邏輯，還全面測試安全政策、服務組態、配額，以及最新的 API 簽章和傳回值。

構建程式碼以實現可測試性

將 Lambda 專屬程式碼與核心商業邏輯分隔開來，以簡化您的測試和 Lambda 函數。

您的 Lambda 函數 處理常式 應為一個小型的轉接器，它會接收事件資料，且只將重要的詳細資料傳遞給您的商業邏輯方法。您可以透過這項策略以商業邏輯為核心進行全面測試，無需擔心特定 Lambda 詳細資訊。您的 AWS Lambda 函數不需要設定複雜的環境或大量相依性，即可建立和初始化待測元件。

一般而言，您應撰寫一個處理常式，從傳入的 事件 和 內容 物件擷取和驗證資料，然後將該輸入傳送至執行商業邏輯的方法。

加快回饋迴圈的開發速度

您可以透過一些工具和技術加快回饋迴圈的開發速度。例如，AWS  SAM Accelerate 和 AWS  CDK 監看模式都可以縮短更新雲端環境所需的時間。

GitHub 無伺服器測試範例儲存庫 中的範例會探究其中一些技術。

我們也建議您在開發期間儘早建立和測試雲端資源，而不只是在登記至原始碼控制後才進行。這種作法可在制定解決方案時加快探索和實驗的速度。此外，從開發電腦自動化部署作業可協助您更快發現雲端組態問題，並減少更新和程式碼審查程序所浪費的人力。

全力進行整合測試

使用 Lambda 建置應用程式時，最佳作法是一起測試元件。

針對兩個 (或以上) 架構元件進行的測試稱為 整合測試。整合測試的目標是不僅了解程式碼在元件之間的執行方式，還了解託管程式碼的環境行為。端對端測試 屬於特殊類型的整合測試，它會驗證整個應用程式中的行為。

若要建置整合測試，請將應用程式部署至雲端環境。您可以透過本機環境或 CI/CD 管道完成這項動作。接著，請撰寫測試以訓練待測試的系統 (SUT)，並驗證預期的行為。

例如，待測試的系統可能是使用 API Gateway、Lambda 和 DynamoDB 的應用程式。測試可以對 API Gateway 端點進行合成 HTTP 呼叫，並驗證回應是否包含預期的有效負載。此測試會驗證 AWS Lambda 程式碼是否正確，而且每個服務都已正確設定為處理請求，包括它們之間的 IAM 許可。此外，您可以將測試設計為寫入各種大小的紀錄，以驗證服務配額 (例如 DynamoDB 中的最大紀錄大小) 是否設定正確。

建立獨立的測試環境

在雲端中進行測試通常需要獨立的開發人員環境，好讓測試、資料和事件不會出現重疊的狀況。

其中一種方法是為每個開發人員提供專用 AWS 帳戶。這可避免當多個開發人員在共用程式碼庫中工作、嘗試部署資源或叫用 API 時，可能發生的資源命名衝突。

自動化測試程序應為每個堆疊建立名稱獨一無二的資源。例如，您可以設定指令碼或 TOML 組態檔案，讓 AWS SAM CLI sam 部署或 sam 同步命令自動指定具有唯一字首的堆疊。

在某些情況下，開發人員會共用 AWS 帳戶。這可能是因為堆疊中的資源操作成本高昂，或是佈建和設定成本高昂。例如，可能會共用資料庫，以便更輕鬆地正確設定和植入資料

如果開發人員共用帳戶，則應設定界限，以識別擁有權並排除重疊的狀況。其中一種作法是在堆疊名稱前面加上開發人員的使用者 ID。另一種流行的作法是根據 程式碼分支 設定堆疊。使用分支界限時，環境會獨立出來，但開發人員仍可以共用資源 (例如關聯式資料庫)。當開發人員一次處理多個分支時，這種作法便是最佳實務。

在雲端進行測試對所有測試階段 (包括單元測試、整合測試和端對端測試) 來說都很有價值。保持適當的隔離是必要的作法，但您仍會希望 QA 環境能盡可能與您的生產環境相似。因此，團隊會為 QA 環境加入變更控制程序。

生產前環境和生產環境方面，您通常會在帳戶層級設定界限，以便將工作負載隔離出來，使其不受擾鄰問題的影響，並實作最低權限安全控制以保護敏感資料的安全。工作負載具有配額。您不會希望測試消耗分配給生產環境 (擾鄰) 的配額，或可以存取客戶的資料。負載測試是應從生產堆疊中隔離出來的另一項活動。

在所有情況下，環境都應設定警示和控制項，以避免出現不必要的支出。例如，您可以限制可建立的資源類型、層級或大小，並在預估成本超過指定閾值時設定電子郵件提醒。

將模擬物件用於隔離的商業邏輯

模擬架構是撰寫快速單元測試的實用工具。當測試涵蓋複雜的內部商業邏輯 (例如數學或財務計算或模擬) 時，它們的優勢就會特別明顯。尋找具有大量測試案例或輸入變化的單元測試，其中這些輸入不會改變對其他雲端服務的模式或呼叫內容。

模擬物件單元測試所涵蓋的程式碼也應涵蓋在雲端的測試之中。此為建議作法，因為開發人員的筆記型電腦或建置機器環境的設定方式可能會不同於雲端中的生產環境。例如，使用特定輸入參數執行時，Lambda 函數使用的記憶體或時間可能比分配到的還多。或者，您的程式碼可能會含有未以相同方式 (或完全不同的方式) 設定的環境變數，且這些差異可能會導致程式碼出現不同的行為，或執行失敗。

模擬物件在整合測試中較不具優勢，因為實作必要模擬物件的人力需求會隨著連接點的數量而上升。端對端測試不應使用模擬物件，因為這些測試通常會面對無法使用模擬架構輕鬆模擬的狀態和複雜邏輯。

最後，請避免使用模擬雲端服務來驗證服務呼叫是否有正確實作。請改為在雲端中進行雲端服務呼叫，以驗證行為、組態和功能實作。

請謹慎使用模擬器

模擬器對於部分使用案例而言可能會很方便 (例如網際網路存取受限、不可靠或緩慢的開發團隊)。不過，在大多數情況下，請謹慎使用模擬器。

透過避免模擬器，您可以使用最新的服務功能和最新的 APIs來建置和創新。您不會卡在等待廠商版本以達成功能同位。您可以減少在多個開發系統和建置機器上購買和組態的預付和持續費用。此外，您可以避免許多雲端服務根本沒有可用的模擬器的問題。依賴模擬的測試策略使得無法使用這些服務 （導致可能更昂貴的解決方法） 或產生未經良好測試的程式碼和組態。

當您使用模擬進行測試時，您仍然必須在雲端中進行測試，以驗證組態，並測試與雲端服務的互動 (只能在模擬環境中進行模擬)。

在本機進行測試的難題

當您使用模擬器和模擬呼叫在本機電腦上進行測試時，當程式碼在 CI/CD 管道中從一個環境進入到另一個環境時，您可能會遇到測試不一致的情況。在桌面上驗證應用程式商業邏輯的單元測試可能無法準確測試雲端服務的關鍵層面。

以下範例提供了使用模擬物件和模擬器進行本機測試時應留意的情況：

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

如果 Lambda 函數的邏輯取決於建立 S3 儲存貯體，則完整測試應確認已呼叫 Amazon S3 且儲存貯體已成功建立。

模擬和模擬設定會測試 Lambda 函數在呼叫 Amazon S3 時的處理方式；不過，這些測試不會驗證 Lambda 函數是否能夠成功建立 Amazon S3 儲存貯體。您必須確定指派給函數的角色具有允許函數執行 s3:CreateBucket 動作的附加安全政策。如果沒有，函數在部署到雲端環境時可能會失敗。

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

如果 Amazon SQS 佇列是 Lambda 函數的來源，則完整測試應驗證訊息放入佇列時是否已成功調用 Lambda 函數。

模擬測試和模擬測試通常設定為直接執行 Lambda 函數程式碼，並透過傳遞 JSON 事件承載 （或還原序列化物件） 做為函數處理常式的輸入來模擬 Amazon SQS 整合。

模擬 Amazon SQS 整合的本機測試會測試 Amazon SQS 使用指定的承載呼叫 Lambda 函數時，Lambda 函數的動作，但測試不會驗證 Amazon SQS 在部署到雲端環境時是否成功叫用 Lambda 函數。

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

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

常見問答集

我有一個 Lambda 函數，它可以執行計算並傳回結果，無需呼叫任何其他服務。我真的需要在雲端進行測試嗎？

是。Lambda 函數具有可能改變測試結果的組態參數。所有的 Lambda 函數程式碼都有逾時和記憶體設定的相依項，如果未正確進行設定，可能會導致函數失敗。

Lambda 政策也會向 Amazon CloudWatch 啟用標準輸出記錄。即使您的程式碼未直接呼叫 CloudWatch，也需要許可才能啟用記錄功能。此必要許可無法精確模擬。

雲端中的測試如何協助進行單元測試？ 如果它位於雲端並連接到其他資源， 不是整合測試嗎？

我們將單元測試定義為在架構元件上獨立運作的測試，但這不會阻止測試包含可能呼叫其他服務或使用某些網路通訊的元件。

許多無伺服器應用程式都具有可隔離進行測試的架構元件 (即使在雲端也是如此)。其中一個例子是接受輸入、處理資料並將訊息傳送至 Amazon SQS 佇列的 Lambda 函數。此函數的單元測試可能會測試輸入值是否會導致某些值出現在佇列訊息之中。

考慮使用「準備、執行、驗證」模式撰寫的測試：

模擬物件測試方法包括使用正在進行的模擬物件來模擬佇列，以及建立含有 Lambda 函數程式碼的類別或模組的進行中執行個體。驗證階段期間，佇列的訊息會從模擬物件進行擷取。

在雲端方法中，測試會針對測試目的建立 Amazon SQS 佇列，並透過設定為將隔離的 Amazon SQS佇列作為輸出目的地使用的環境變數來部署 Lambda 函數。執行 Lambda 函數後，測試會從 Amazon SQS 佇列擷取訊息。

雲端測試會執行相同的程式碼、宣告相同的行為，並驗證應用程式的功能正確性。不過，它還可以驗證 Lambda 函數的設定：IAM 角色、IAM 政策和函數的逾時和記憶體設定。

後續步驟和資源

使用以下資源以進一步了解並探索測試的實際範例。

實作範例

GitHub 上的 無伺服器測試範例儲存庫 包含遵循本指南所述模式和最佳實務的具體測試範例。儲存庫包含前幾節所述之模擬物件、模擬和雲端測試程序的範例程式碼和引導式逐步解說。使用此儲存庫來取得來自 的最新無伺服器測試指引 AWS。

深入閱讀

請造訪 Serverless Land 以存取最新的部落格、影片和無 AWS 伺服器技術訓練。

也建議閱讀下列 AWS 部落格文章：

工具