目標業務成果測試項目如何測試無伺服器測試技術最佳實務在本機進行測試的難題 FAQ 後續步驟和資源

如何測試無伺服器功能和應用程式

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

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

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

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

illustration showing the relationship between types of tests

對於無服務器測試，您仍然會編寫單元，集成和end-to-end測試。

單元測試：針對一組隔離的程式碼區塊進行的測試。例如，驗證商業邏輯以計算指定的特定項目與目的地的運費。
整合測試：涉及到兩個以上元件或服務進行互動的測試 (通常在雲端環境)。例如，驗證函數是否有處理佇列中的事件。
E nd-to-end 測試-測試，驗證整個應用程序的行為。例如，確保基礎設施的設定正確無誤，以及事件如預期在服務之間流動，以記錄客戶的訂單。

目標業務成果

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

提高應用程式的品質
降低建構功能和修復錯誤的時間

應用程式的品質取決於測試各種情境來驗證功能。仔細思考業務情境並自動化這些針對雲端服務進行的測試，將有助於提高應用程式的品質。

在反覆進行的開發週期中發現軟體錯誤和組態問題對成本和排程的影響最小。如果在開發過程中仍未發現問題，則在生產過程中尋找和修復問題時，將需要耗費更多人力。

經過妥善規劃的無伺服器測試策略可驗證 Lambda 函數和應用程式是否在雲端環境中如預期般運行，藉此提高軟體品質並縮短反覆運算的時間。

測試項目

建議您採用能測試受管服務行為、雲端組態、安全政策以及程式碼整合的測試策略，以提升軟體品質。行為測試 (又稱為黑箱測試) 會在不了解所有內部情況的狀況下驗證系統是否如預期般正常運作。

執行單元測試以檢查 Lambda 函數內的商業邏輯。
確認整合服務實際上是否有調用，且輸入參數是否正確無誤。
檢查事件是否通過工作流程 end-to-end 中的所有預期服務。

在傳統的伺服器型架構中，團隊通常會定義測試的範圍，且只納入在應用程式伺服器上執行的程式碼。其他元件、服務或相依項目通常會被認定屬於外部且超出測試範圍。

無伺服器應用程式通常由小型工作單位組成，例如從資料庫擷取產品、處理佇列項目或是調整儲存空間映像大小的 Lambda 函數。每個元件都會在各自的環境中執行。團隊可能會在單一應用程式中負起這類眾多小型單位的責任。

部分應用程式功能可完全委派給受管服務 (例如 Amazon S3)，也可以在不使用任何內部開發程式碼的情況下建立。您不需要測試這類受管服務，不過您確實需要測試與這些服務的整合。

如何測試無伺服器

您可能對測試在本機部署的應用程式的方式不陌生：您撰寫的測試會針對完全在桌面作業系統或容器內執行的程式碼進行測試。例如，您可以透過請求調用本機 Web 服務元件，然後對回應做出聲明。

無伺服器解決方案是根據您的函數程式碼和雲端受管服務 (例如佇列、資料庫、事件匯流排和簡訊傳送系統) 建置而成。這些元件皆透過 事件驅動的架構 連接，其中訊息 (稱為事件) 會從一項資源流向另一項資源。這些互動可以是同步的，例如當 Web 服務立即傳回結果時，或稍後完成的非同步動作，例如將項目放入佇列或啟動工作流程步驟。您的測試策略必須納入這兩種情境，並測試服務之間的互動。對於非同步交互，您可能需要檢測下游組件中可能無法立即觀察到的副作用。

複寫整個雲端環境 (包括佇列、資料庫資料表、事件匯流排、安全性政策等) 的作法並不實際。由於本機環境與雲端中部署的環境之間存在差異，因此您必定會遇到問題。環境之間的變化將增加重現和修復錯誤所需的時間。

在無伺服器應用程式中，架構元件通常完全位於雲端之中，因此您必須對雲端中的程式碼和服務進行測試，才能夠開發功能和修正錯誤。

測試技術

在實際情況下，您的測試策略可能會包括各種技術，以提升解決方案的品質。您將會採用快速互動測試來偵錯主控台中的函數、使用自動化單元測試來檢查隔離的商業邏輯、透過模擬來驗證對外部服務的呼叫，以及偶爾對模擬服務的模擬器進行測試。

在雲端測試：您可以部署基礎設施和程式碼，透過實際的服務、安全政策、組態和基礎設施的具體參數進行測試。以雲端為基礎的測試可為您的程式碼提供最精準的品質測量方法。

您可以透過在主控台中偵錯函數，進而在雲端中迅速進行測試。您可以從範例測試事件資源庫中進行選擇，也可以建立自訂事件來單獨測試函數。您也可以透過主控台與團隊分享測試事件。

若要在開發和建置生命週期中 自動化 測試，則必須在主控台之外進行測試。如需自動化策略和資源，請參閱本指南中特定語言的測試章節。
透過模擬 (又稱為 假物件) 進行測試：模擬為程式碼中的物件，可模擬和替代外部服務。模擬物件提供預先定義的行為來驗證服務呼叫和參數。假物件 是一種模擬實作，它會透過捷徑來簡化或提升效能。例如，假物件的資料存取物件可能會從記憶體內的資料儲存傳回資料。模擬物件可以模仿和簡化複雜的相依項目，但也可能產生更多的模擬來代替巢狀的相依項目。
使用模擬器進行測試：您可以設定應用程式 (有時透過第三方) 來模擬本機環境中的雲端服務。速度是模擬器的優勢，但設定和與生產服務的一致性是它的劣勢。請謹慎使用模擬器。

在雲端進行測試

雲端測試對於測試的所有階段都很有價值，包括單元測試、整合測試和 end-to-end 測試。當您針對同時與雲端服務互動的雲端程式碼進行測試時，便可以獲得最精準的程式碼品質測量方法。

您可以透過在 AWS Management Console 加入測試事件輕鬆在雲端中執行 Lambda 函數。測試事件是您函數的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 =========================

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

您可以測試每項可用的服務。
您始終使用最新的服務APIs和返回值。
雲端測試環境與您的生產環境非常類似。
測試可以涵蓋安全策略、服務配額、組態和基礎設施的具體參數。
每位開發人員都可以在雲端中迅速建立一或多個測試環境。
雲端測試可提高程式碼在生產環境中順利執行的把握度。

在雲中進行測試確實有一些缺點。部署到雲端環境的時間通常比部署到本機桌面環境的時間更長，是在雲端進行測試時最明顯的缺點。

幸運的是，AWS 無伺服器應用程式模型 (AWS SAM) 加速、AWS Cloud Development Kit (AWS CDK) 監視模式和 SST(第三方) 等工具可減少與雲端部署反覆運算相關的延遲。這些工具可以監控您的基礎設施和程式碼，並自動將增量更新部署到您的雲端環境。

注意

請參閱無伺服器開發人員指南，了解如何建立基礎結構即程式碼，以進一步了解 AWS Serverless Application Model AWS CloudFormation、和 AWS Cloud Development Kit (AWS CDK)。

不同於本機測試，在雲端進行測試需使用額外的資源，而這可能會產生服務費用。建立隔離的測試環境可能會增加 DevOps 團隊的負擔，尤其是在對帳戶和基礎架構有嚴格控制的組織中。即便如此，在面對複雜的基礎設施情境時，開發人員設定和維護複雜本機環境的時間成本，可能會與使用基礎設施即程式碼自動化工具建立的一次性測試環境相似 (或更高)。

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

透過模擬物件進行測試

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

例如，您可以撰寫使用 Amazon S3 服務模擬的測試，該測試會在呼叫CreateObject方法時傳回特定回應。執行測試時，模擬物件會傳回該項已設計程式的回應，而不呼叫 Amazon S3 或任何其他服務端點。

模擬物件通常由模擬架構產生，以減少開發工作量。一些模擬框架是通用的，其他模擬框架是專門為的 AWS SDKs，例如 Moto，一個用於模擬 AWS 服務和資源的 Python 庫。

請注意，模擬物件與模擬器不同，模擬通常由開發人員建立或設定為測試程式碼的一部分，而模擬器是獨立的應用程式，它會以與模擬的系統相同的方式公開功能。

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

模擬可以模擬超出應用程序控制的第三方服務，例如APIs軟件即服務（SaaS）提供商，而無需直接訪問這些服務。
模擬物件在測試失敗條件非常實用 (尤其當這種情況很難模擬時，例如服務中斷)。
模擬物件可以在設定後讓您迅速進行本機測試。
模擬物件可以為幾乎任何類型的物件提供替代行為，因此模擬策略可以為各種比模擬器更廣泛的服務建立涵蓋範圍。
當新功能或行為開放使用時，模擬物件測試便可以更迅速地做出回應。通過使用通用的模擬框架，您可以在更 AWS SDK新後立即模擬新功能。

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

模擬物件通常需要進行相當複雜的設定和組態工作，尤其是在嘗試確定不同服務的傳回值以正確模擬回應的情況。
模擬物件是由開發人員撰寫、設定以及進行必要維護，而這會加重他們的責任。
您可能需要存取雲端，才能瞭解服務的APIs和傳回值。
模擬物件維護起來可能並不容易。當模擬的雲API簽名發生變化或返回值模式發展時，您需要更新模擬。如果您擴展應用程序邏輯以對 new 進行調用，嘲笑還需要更新APIs。
使用模擬物件的測試可能會在桌面環境中順利通過，但在雲端中卡住。結果可能與目前的不相符API。您無法對服務組態和配額進行測試。
模擬框架在測試或檢測 AWS Identity and Access Management（IAM）策略或配額限制方面受到限制。雖然模擬物件在授權失敗或超過配額時的模擬效果更佳，但您無法透過測試確定生產環境中實際將會發生的結果。

透過模擬進行測試

仿真器通常是模仿生 AWS 產服務的本地運行應用程序。

仿真器具有類似於他們的雲同行APIs，並提供類似的返回值。它們也可以模擬由API呼叫啟動的狀態變更。例如，您可以使 AWS SAM 用 AWS SAM 本機執行函數來模擬 Lambda 服務，以便快速叫用函數。如需詳細資訊，請參閱 《AWS Serverless Application Model 開發人員指南》 中的 AWS SAM 本機。

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

模擬器可讓您快速進行本機開發迭代和測試。
模擬器為習慣在本機環境中開發程式碼的開發人員提供了一個熟悉的環境。例如，如果您熟悉 N 層應用程式的開發，則可能會具有類似於在生產環境、本機電腦中執行的資料庫引擎和 Web 伺服器，以提供快速、本機且隔離的測試功能。
模擬器不需要對雲端基礎設施 (例如開發人員的雲端帳戶) 進行任何變更，因此可以輕鬆透過現有的測試模式進行實作。

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

模擬器可能不易進行設定和複製，尤其是用於 CI/CD 管道時。這可能會導致管理個人軟體的 IT 人員或開發人員的工作量有所提升。
模擬功能，APIs通常落後於服務更新。這可能會導致錯誤，因為測試的代碼與實際不匹配API，並且阻礙了新功能的採用。
模擬器需要在支援、更新、錯誤修復和功能平等方面有所提升。這些工作是模擬器開發者 (可能為第三方公司) 的責任。
使用模擬器的測試可能會在本機產生成功的結果，但可能會因為生產安全政策、服務間組態或超過 Lambda 配額而在雲端中產生失敗。
許多 AWS 服務沒有可用的仿真器。如果您仰賴模擬，則可能會無法對應用程式的某些部分以令人滿意方式進行測試。

最佳實務

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

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

排定雲端測試的優先順序

在雲端進行測試可提供最可靠、精準且完整的測試涵蓋範圍。在雲端環境中執行測試，不僅會全面測試商務邏輯，還會測試安全性原則、服務設定、配額，以及最新的API簽名和傳回值。

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

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

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

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

加快回饋迴圈的開發速度

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

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

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

全力進行整合測試

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

針對兩個 (或以上) 架構元件進行的測試稱為 整合測試。整合測試的目標不僅是了解程式碼將如何在各個元件中執行，還要了解託管程式碼的環境將會如何運作。E nd-to-end 測試是特殊類型的集成測試，用於驗證整個應用程序的行為。

若要建置整合測試，請將應用程式部署至雲端環境。您可以透過本機環境或 CI/CD 管道完成這項動作。然後，編寫測試以執行下測試的系統（SUT）並驗證預期的行為。

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

建立獨立的測試環境

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

一種方法是為每個開發人員提供專用 AWS 帳戶。這將避免與資源命名衝突，當多個開發人員在共享代碼庫中工作，嘗試部署資源或調用API.

自動化測試程序應為每個堆疊建立名稱獨一無二的資源。例如，您可以設置腳本或TOML配置文件，以便 AWS SAM CLI sam deploy 或 sam sync 命令將自動指定具有唯一前綴的堆棧。

在某些情況下，開發人員共享一個 AWS 帳戶。這可能是因為堆疊中有運作、佈建及設定時成本非常高的資源。例如，您可以共用資料庫，以便更容易正確設定和植入資料

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

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

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

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

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

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

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

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

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

請謹慎使用模擬器

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

通過避免使用仿真器，您將能夠使用最新的服務功能和最新的進行構建和創新APIs。您無需等待供應商發布新版本，即可實現功能平等。您將可以減少購買和設定多個開發系統和建置機器的前期和持續支出。此外，您也可以避開許多雲端服務根本就不提供模擬器的問題。仰賴模擬的測試策略將使您無法使用這些服務 (進而衍生出成本可能更高的解決方法)，或產生未經過良好測試的程式碼和組態。

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

在本機進行測試的難題

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

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

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

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

在模擬物件測試設定中，您可能會模擬成功回應，並可能加入測試案例來應對回應失敗的狀況。
在模擬測試案例中，CreateBucketAPI可能會呼叫，但您需要注意進行本機呼叫的身分不會來自 Lambda 服務。呼叫身分不會像在雲端中一樣擔任安全角色，因此會改用預留位置驗證 (可能會有更寬鬆的角色或使用者身分，在雲端中執行時會有所不同)。

模擬物件和模擬設定將測試 Lambda 函數在呼叫 Amazon S3 時會執行的動作；不過，這些測試將不會驗證設定的 Lambda 函數是否能成功建立 Amazon S3 儲存貯體。您必須確定指派給函數的角色具有允許函數執行 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 將永遠無法發送該大小的消息。

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

FAQ

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

是。Lambda 函數具有可能改變測試結果的組態參數。所有 Lambda 函數程式碼都依賴於逾時和記憶體設定，如果未正確設定這些設定，可能會導致函數失敗。Lambda 政策也啟用 Amazon 的標準輸出記錄功能 CloudWatch。即使您的代碼沒有 CloudWatch 直接調用，也需要許可才能啟用日誌記錄。此必要許可無法精確模擬。

雲端中的測試如何協助進行單元測試？如果測試在雲中進行且連接到其他資源，那這樣不就是整合測試嗎？

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

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

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

準備：分配資源 (用於接收訊息的佇列和待測函數)。
執行：呼叫待測函數。
驗證：擷取函數發送的訊息，並驗證輸出。

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

以雲端為基礎的方法，測試會為測試目的建立 Amazon SQS 佇列，並將使用環境變數部署 Lambda 函數，這些變數設定為使用隔離 Amazon SQS 佇列做為輸出目的地。運行 Lambda 函數後，測試將從 Amazon SQS 隊列中檢索消息。

雲端測試會執行相同的程式碼、驗證相同的行為，並驗證應用程式功能是否正確。但是，它具有能夠驗證 Lambda 函數設定的額外優勢：IAM角色、IAM政策以及函數的逾時和記憶體設定。

後續步驟和資源

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

實作範例

的無伺服器測試範例儲存庫 GitHub 包含遵循本指南中描述的模式和最佳作法的具體測試範例。儲存庫包含前幾節所述之模擬物件、模擬和雲端測試程序的範例程式碼和引導式逐步解說。使用此儲存庫可以快速獲得最新的無伺服器測試指南。 AWS

深入閱讀

造訪無伺服器領域網站，存取最新的部落格、影片和 AWS 無伺服器技術訓練。

還建議閱讀以下 AWS 博客文章：

工具

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

最佳實務

整合其他服務