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

# 用於測試無伺服器應用程式的最佳實務
<a name="best-practices"></a>

下列各節概述在測試無伺服器應用程式時實現有效涵蓋範圍的最佳實務。

## 排定雲端測試的優先順序
<a name="prioritize-cloud"></a>

對於設計良好的應用程式，您可以使用各種測試技術來滿足各種要求和條件。但是，根據目前的工具，建議您盡可能專注於在雲端中進行測試。雖然在雲端中進行測試可能會造成開發人員延遲、增加成本，有時需要投資額外的 DevOps 控制項，但此技術可提供最可靠、準確且完整的測試涵蓋範圍。

您應該可以存取在其中執行測試的隔離環境。理想情況下，每個開發人員都應擁有專用的 AWS 帳戶 ，以避免在多個使用相同程式碼的開發人員嘗試在具有相同名稱的資源上部署或調用 API 呼叫時，可能發生的任何資源命名問題。這些環境都應設定適當的警示和控制項，以避免出現不必要的支出。例如，您可以限制可建立的資源類型、層級或大小，並在預估成本超過指定閾值時設定電子郵件提醒。

如果您必須 AWS 帳戶 與其他開發人員共用單一 ，自動化測試程序應該為每個開發人員命名唯一的資源。例如，導致 AWS SAM CLI [sam 部署或 sam 同步命令的更新指令碼](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-deploy.html)或 TOML 組態檔案，可以自動指定包含本機開發人員使用者名稱的堆疊名稱。 [https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-sync.html](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-sync.html)

在雲端進行測試對所有測試階段 (包括單元測試、整合測試和端對端測試) 來說都很有價值。

## 如有必要，請使用模擬
<a name="use-mocks"></a>

模擬架構是撰寫快速單元測試的實用工具。當測試需要涵蓋複雜的內部業務邏輯 (例如數學或財務計算或模擬) 時，其尤其有價值。尋找具有大量測試案例或輸入變化的單元測試，其中輸入不會改變對其他雲端服務的模式或呼叫內容。為這些場景建立模擬測試可以改善開發人員反覆運算時間。

使用模擬測試的單元測試所涵蓋的程式碼也應被雲端中的測試所涵蓋。這是必要的，因為模擬仍在開發人員的筆記型電腦或建置機器上執行，而且環境的設定可能與雲端中的環境不同。例如，您的程式碼可能包含使用更多記憶體或花費比 Lambda 設定在特定輸入參數執行時配置更多時間的 AWS Lambda 函數。或者，您的程式碼可能包含未以相同方式 （或完全） 設定的環境變數，而差異可能會導致程式碼的行為不同或失敗。

請勿使用雲端服務的模擬來驗證這些服務整合的適當實作。雖然在測試其他功能時模擬雲端服務是可以接受的，但您應該在雲端測試雲端服務呼叫，以驗證正確的組態和功能實作。

模擬可為單元測試增加價值，尤其是當您經常測試大量案例時。整合測試的這種優勢有所減少，因為實作必要模擬的工作量會隨著連接點的數量而增加。端對端測試不應使用模擬物件，因為這些測試通常會面對無法使用模擬架構輕鬆模擬的狀態和複雜邏輯。

## 了解模擬測試的權衡
<a name="avoid-emulators"></a>

模擬器是特定使用案例的實際選擇。例如，網際網路存取有限、不一致或緩慢的開發團隊可能會發現，模擬測試是在移至雲端環境之前，最可靠的程式碼迭代方式。

對於大多數其他情況，請選擇性地使用模擬器。當您非常依賴模擬器時，在模擬廠商發佈更新以提供功能同位之前，將新的 AWS 服務功能納入您的測試可能會變得困難。模擬器還需要預先和持續投資，才能跨開發系統和建置機器進行設定和組態。此外，許多雲端服務沒有可用的模擬器；選取模擬優先策略可能會排除這些服務的使用，或產生未針對實際服務行為進行良好測試的程式碼和組態。

如果您使用模擬測試， 會盡可能搭配雲端測試來驗證適當的雲端組態，並測試與只能在模擬環境中模擬或模擬之 服務的互動。

模擬測試可以提供單位測試的快速意見回饋，並且根據模擬軟體的功能和行為同位， 可能也支援一些整合和end-to-end測試。

## 透過自然界限進行範圍測試
<a name="scope-tests"></a>

隨著無伺服器應用程式跨更多架構元件成長，子系統周圍會出現自然界限，尤其是在遵循單一用途函數和事件驅動解耦等最佳實務時。這些界限可做為有效的測試邊緣，您可以在其中驗證元件之間的合約。

### 識別架構邊界
<a name="identify-architecture-boundaries.579324d8-6a26-5c29-accb-f1cf000835af"></a>

在應用程式設計中尋找自然接縫：
+ 服務之間，例如將發佈者連線至消費者的 Amazon EventBridge 規則
+ 在 API 邊緣，例如前端 Lambda 函數的 Amazon API Gateway 端點
+ 圍繞工作流程，例如 AWS Step Functions 協調多個服務
+ 在儲存層，例如觸發下游處理的 Amazon DynamoDB 串流

### 將 Lambda 程式碼與商業邏輯分開
<a name="separate-9999999999999999lam--code-from-business-logic.400b5c80-0b44-5f98-9bcd-7bee9baa921d"></a>

將 Lambda 程式碼與核心商業邏輯隔離，簡化您的測試。您的 Lambda 處理常式應該做為 AWS 執行時間與應用程式邏輯之間的精簡轉接器。它應該擷取並驗證事件資料，然後委派給沒有 Lambda 相依性的可測試函數。這可讓您的商業邏輯更方便攜帶、更易於推理，且無需模擬 Lambda 物件或設定複雜環境即可直接進行測試。

### 將界限視為合約
<a name="treat-boundaries-as-contracts.2f48075c-8e72-5953-9115-1c3ff51459b0"></a>

在邊界測試，而不是透過邊界測試。驗證哪些項目跨邊緣，而不需要整個下游系統。這些相同的界限也在生產環境中做為可觀測性勾點。您可以使用 Amazon CloudWatch Logs、 AWS X-Ray traces 和 EventBridge 事件來檢測您測試的架構接縫以進行監控。

## 使用非同步工作流程的測試機制
<a name="test-harnesses"></a>

無伺服器應用程式通常依賴非同步模式，其中事件觸發處理、訊息流經佇列，以及工作流程跨越多項服務，而無需立即回應。您無法直接叫用函數並檢查傳回值。結果稍後可能會出現在資料庫、日誌串流或其他 服務中。

*測試工具*正在測試您隨應用程式一起部署的基礎設施，以觀察和驗證此非同步行為。測試機制通常包括：
+ 訂閱應用程式產生的相同事件的事件接聽程式
+ 可擷取測試結果的儲存機制 （例如 DynamoDB 資料表或 Amazon S3 儲存貯體）
+ 測試程式碼中等待預期結果出現的輪詢邏輯

您的測試程式碼會啟動事件、等待工作流程完成，然後查詢測試機制以確認預期的結果發生。

最佳實務如下：
+ **為非同步操作定義明確的 SLAs ** – 建立工作流程應花費的時間，並在測試中將這些工作流程用作輪詢逾時
+ **使用唯一識別符進行測試隔離** – 產生每個測試執行的唯一檔案名稱、訊息 IDs 或關聯字符，以防止測試之間的干擾
+ **將測試基礎設施與您的應用程式一起部署** – 在您的infrastructure-as-code範本中包含測試設備資源，以便它們在您的應用程式演進時保持同步
+ **測試執行後清除測試資料** – 這可防止在雲端環境中累積測試成品

測試機制對於驗證跨多個服務之工作流程的整合測試、驗證完整使用者旅程的end-to-end測試，以及服務透過 EventBridge、Amazon SNS、Amazon SQS 或 Amazon Kinesis 通訊的事件驅動架構來說，是最有價值的。

## 組織雲端環境以進行開發人員隔離
<a name="organize-cloud-environments"></a>

在雲端進行測試需要彼此隔離的環境。當開發人員共用單一 AWS 帳戶，例如團隊開發帳戶時，請考慮為每個開發人員或功能分支建立個別的應用程式堆疊。這可隔離資源、防止命名衝突，並在測試期間避免配額爭用或雜訊鄰近問題。

使用 AWS Systems Manager 參數存放區或類似工具來管理堆疊特定的組態，例如 API 端點和佇列名稱。為了提高成本效益，在開發人員堆疊之間共用 Amazon Relational Database Service (Amazon RDS) 叢集等昂貴的資源，同時保持每個堆疊隔離輕量型無伺服器資源 （例如 Lambda 函數、API Gateway 階段和 DynamoDB 資料表）。

在受管制的產業中，企業安全政策可能會限制開發人員對雲端環境的存取，使得在本機開發工作流程中難以執行雲端測試。在這些情況下，模擬測試可以填補本機模擬測試和完整雲端驗證之間的差距，但應該在存取允許時補充雲端測試。

## 加速回饋迴圈
<a name="feedback-loops"></a>

在雲端進行測試時，請使用工具和技術來加速開發回饋迴圈。例如，使用[AWS SAM 加速](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/accelerate.html)和 AWS CDK 監看模式可縮短將程式碼修改推送至雲端環境所需的時間。GitHub [無伺服器測試範例儲存庫](https://github.com/aws-samples/serverless-test-samples) 中的範例會探究其中一些技術。

我們也建議您在開發期間儘早從本機機器建立和測試雲端資源，而不只是在簽入來源控制之後。這種作法可在制定解決方案時加快探索和實驗的速度。此外，從開發電腦中自動化部署可協助您更快發現雲端組態問題，並減少更新和核准來源控製修改所浪費的人力。