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

# 在 上測試無伺服器應用程式 AWS
<a name="introduction"></a>

*Amazon Web Services* [貢獻者](contributors.md)（貢獻者）

*2026 年 3 月* ([文件歷史記錄](doc-history.md))

本指南討論測試無伺服器應用程式的方法論，說明測試期間可能遇到的挑戰，並介紹最佳實務。這些測試技術旨在協助您更快地進行反覆運算並更自信地發佈程式碼。

本指南適用於希望為其無伺服器應用程式建立測試策略的開發人員。您可以使用本指南作為了解測試策略的起點，然後訪問[無伺服器測試範例儲存庫](https://github.com/aws-samples/serverless-test-samples)，查看遵循本指南中描述的模式和最佳實務的測試範例。本指南說明無伺服器測試方法、說明客戶在測試無伺服器應用程式時遇到的挑戰，並介紹測試無伺服器應用程式的最佳實務。這些技術旨在協助開發人員更快速地迭代，並更有信心地發佈。

## 概觀
<a name="overview"></a>

自動化測試是重要的投資，有助於確保應用程式品質和開發速度。測試也能加速開發人員的意見回饋。身為開發人員，您希望能夠在應用程式上進行快速反覆運算，並獲取程式碼品質的意見回饋。許多開發人員習慣於撰寫應用程式，這些應用程式會部署到桌上型電腦的環境中，無論是直接部署到作業系統，或是在容器型環境中。當您在桌上型電腦或容器型環境中工作時，通常會針對完全在桌上型電腦中託管的程式碼撰寫測試。不過，在無伺服器應用程式中，架構元件可能無法部署至桌面環境，而可能只存在於雲端中。雲端架構可能包括持久性層、簡訊系統、安全建構、APIs 和其他元件。當您編寫依賴於這些元件的應用程式碼時，可能很難確定設計和執行測試的最佳方法。

本指南可協助您調整測試策略，以減少摩擦和混淆，並提高程式碼品質。

## 先決條件
<a name="prerequisites"></a>

本指南假設您熟悉自動化測試的基礎知識，包括如何使用自動化軟體測試來確保軟體品質。本指南提供無伺服器應用程式測試策略的高階簡介，不需要任何實際操作的撰寫測試經驗。

## 定義
<a name="definitions"></a>

本指南使用以下術語：
+ *單元測試*是針對單個架構元件的程式碼單獨執行的測試。
+ *整合測試*** **會針對兩個或多個架構元件執行，通常是在雲端環境中。
+ *End-to-end測試*會驗證整個應用程式或工作流程的行為。
+ *模擬器*是應用程式 （通常由第三方提供），旨在模擬雲端服務，而無需佈建或調用任何雲端資源。
+ *模擬* (也稱為*仿造*) 是測試應用程式中的實作，用該相依性的模擬來取代某個相依性。

## 目標
<a name="business-outcomes"></a>

本指南中的最佳實務旨在協助您達成兩個主要目標：
+ 提高無伺服器應用程式的品質
  + 在架構界限進行測試
  + 在程式碼邊界進行測試
+ 縮短實作或變更功能的時間

### 提高軟體品質
<a name="increase-software-quality"></a>

應用程式的品質在很大程度上取決於開發人員測試各種案例以驗證功能的能力。當您未實作自動化測試時，或者更常見的是，如果您的測試無法充分涵蓋所需的案例，則無法判斷或保證應用程式的品質。

在伺服器型架構中，團隊能夠輕鬆定義測試範圍：必須測試在應用程式伺服器上執行的程式碼。呼叫伺服器的其他元件或伺服器呼叫的相依性，通常會被負責伺服器應用程式的團隊認為是外部項目或超出測試範圍。

無伺服器應用程式通常由較小的工作單位組成，例如 AWS Lambda 函數，其在自己的環境中執行。團隊可能會在單一應用程式中負責很多倍這樣的小型單位。部分應用程式功能可完全委派給受管服務 (例如 Amazon Simple Storage Service (Amazon S3) 或 Amazon Simple Queue Service (Amazon SQS))，而無需使用任何內部開發的程式碼。用於軟體測試的傳統基於伺服器的模型可能會將受管服務視為應用程式外部的服務，從而將其排除在外。這可能會導致覆蓋範圍不足，其中關鍵場景可能僅限於手動探索性測試，或是一些結果因環境而異的整合測試案例。因此，採用包含託管服務行為和雲端組態的測試策略可以提高軟體品質。

#### 在架構界限進行測試
<a name="testing-at-architecture-boundaries"></a>

隨著無伺服器應用程式的成長，它們自然會分散在多個架構元件中。雖然這使用 AWS 分散式功能，但可能會讓end-to-end行為難以理解。

##### 識別自然界限
<a name="identifying-natural-boundaries"></a>

依照無伺服器最佳實務設計架構時 （一個函數 = 一個任務，解耦），您會注意到子系統周圍的自然界限。這些界限代表應用程式中的邏輯分隔點。

##### 做為測試合約的界限
<a name="boundaries-as-testing-contracts"></a>

這些架構界限是測試邊緣的絕佳候選項目。將每個界限視為合約，並驗證其行為符合其定義的規格。將這些界限視為應用程式中的*接縫*，您可以在其中插入測試驗證。

##### 主要優點
<a name="key-benefits"></a>

以下是在架構界限測試的主要優點：
+ **聚焦測試範圍** – 獨立測試子系統，而無需了解整個應用程式。
+ **合約驗證** – 確保每個界限在系統演進時維持其預期的行為
+ **雙用途檢測** - 這些相同的界限在生產中產生了絕佳的可觀測性勾點
+ **測試繫帶 **– 可讓您測試非同步無伺服器系統。它可協助您在事件流經子系統時擷取和驗證事件，以測試事件驅動的架構。

#### 在程式碼邊界進行測試
<a name="testing-at-code-boundaries"></a>

透過將 Lambda 程式碼等基礎設施程式碼與您的核心業務邏輯分開來定義清晰的程式碼界限。此分離會建立不同的測試範圍，以簡化您的測試策略。

##### 邊界模式
<a name="the-boundary-pattern"></a>

在 Lambda 函數中建立兩個清晰的程式碼邊界：
+ **外部界限 (Lambda 處理常式）** – 一種薄型轉接器層，可處理 AWS Lambda
+ **內部界限 （商業邏輯）** – 獨立於 Lambda 執行期的純商業邏輯方法

##### 作為轉接器的處理常式 （外部範圍）
<a name="handler-as-adapter"></a>

您的 Lambda 函數處理常式應該是一個薄層：
+ 從傳入 `event`和 `context` 物件擷取資料
+ 驗證擷取的資料
+ 僅將相關詳細資訊傳遞至商業邏輯方法
+ 以 Lambda 的預期格式傳回結果

##### 商業邏輯 （內部範圍）
<a name="business-logic"></a>

您的核心商業邏輯應該：
+ 獨立於 Lambda 的特定詳細資訊操作
+ 接受簡單且經過驗證的輸入
+ 傳回可預測的輸出
+ 初始化需要最少的相依性

##### 依範圍測試優點
<a name="testing-benefits-by-scope"></a>
+ **內部界限測試 – 針對**商業邏輯進行全面的單元測試，無需 Lambda 複雜性或環境設定
+ **外部界限測試** – 驗證轉接器層事件處理和資料擷取的重點整合測試
+ **最低測試負荷** – 大多數測試不需要複雜的環境或廣泛的相依性

這種以界限為基礎的方法可讓您將大部分程式碼測試為純函數，同時保持 Lambda 測試的最小和目標性。

### 縮短實作或變更功能的時間
<a name="decrease-time-to-implement-or-change-features"></a>

您可以在反覆開發週期期間發現這些問題，將軟體錯誤和組態問題對成本和排程的影響降至最低。當開發人員無法偵測到這些問題時，更多人必須投入額外的精力來識別問題。

無伺服器架構包括透過 API 呼叫提供關鍵應用程式功能的受管服務。因此，您的開發週期應包含測試，以驗證*快樂的路徑* （與這些服務的互動如預期般運作） 和*悲傷的路徑* （呼叫失敗、傳回非預期的回應，或跨環境的行為不同）。如果沒有這些測試，您可能會因為本機環境與部署環境之間的差異而遇到問題。發生這種情況時，您必須花費額外的時間來嘗試重現和驗證修正，因為每個反覆運算現在都需要針對與您偏好設定不同的環境驗證變更。

適當的無伺服器測試策略可為包括呼叫其他服務的測試提供準確的結果，從而縮短反覆運算時間。