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

# 無伺服器應用程式的測試技巧
<a name="techniques"></a>

針對無伺服器應用程式程式碼執行測試有三種主要方法：模擬測試、模擬測試和雲端測試。您通常會發現，在單個專案內會混合使用這些方法。例如，您可以在本機開發程式碼時使用模擬測試、在部署之前更緊密地複寫服務行為的模擬測試，以及作為夜間持續整合和持續交付 (CI/CD) 程序一部分的雲端測試。

## 模擬測試
<a name="mock-testing"></a>

模擬測試是一個策略，可透過它在程式碼中建立替代物件，來模擬雲端服務的行為。例如，您可以撰寫使用 Amazon S3 服務模擬的測試，也可以將該模擬設定為在呼叫`PutObject`方法時傳回特定回應物件。執行測試時，該模擬會將回應傳回，而無需呼叫 Amazon S3 或任何其他服務端點。

這些替代物件通常由模擬框架產生，以減少給定測試必需的實作量。有些模擬架構是通用的，有些則是專門針對 AWS SDKs。

模擬與虛設都屬於更廣泛的*仿造*類別。模擬物件與模擬器不同 (本節稍後會討論)，模擬通常由開發人員建立或設定，作為測試程式碼的一部分，而模擬器是獨立的應用程式，會以與其所模擬系統的相同方式公開 API (例如 REST API)。

以下是使用模擬物件的優勢：
+ 模擬物件可以模擬超出應用程式控制範圍的第三方服務，例如 API 和軟體即服務 (SaaS) 供應商，無需直接存取這類服務。
+ 模擬物件在測試失敗條件非常實用，尤其當這種情況 (例如服務中斷) 很難模擬時。
+ 如同模擬器，模擬架構可以在設定後提供快速的本機開發。
+ 模擬物件可以為幾乎任何類型的物件提供替代行為，因此模擬策略可以為各種比模擬器更廣泛的服務建立涵蓋範圍。
+ 當新功能或行為可用時，模擬測試可以使用 （或回復） 通用模擬架構來更快地做出反應，該架構可在更新後的 AWS SDK 可用時立即模擬新功能。

以下是模擬物件測試的缺點：
+ 模擬物件通常需要進行相當複雜的設定和組態工作，尤其是在嘗試確定不同服務的傳回值以正確模擬回應的情況。
+ 因為模擬由編寫測試的開發人員編寫或設定，所以這是開發人員的額外責任。
+ 您可能需要存取雲端，才能了解服務的 API 和傳回值。
+ 模擬也可能很難維護，因為每當被模擬的雲端 API 簽章變更時、傳回值結構描述演變時、或者測試的應用程式邏輯擴展為呼叫新 API 時，其都需要更新。這些變更會為開發人員帶來額外的測試開發工作量。
+ 模擬測試可能會在本機通過，但在雲端中失敗，因為模擬 - 而不是複寫 - 實際服務的行為，使得未偵測到環境特定的問題。
+ 模擬架構，例如模擬器，無法偵測 AWS Identity and Access Management (IAM) 政策違規、服務配額限制或承載大小限制，也不會觸發可能影響部署環境中應用程式行為的輔助服務 AWS CloudTrail，例如 Amazon CloudWatch 或 Amazon GuardDuty。
+ 雖然模擬比較適合模擬應用程式在授權失敗或超過配額時將執行的動作，但模擬測試無法判斷程式碼部署到生產環境時實際發生的結果。

## 仿真測試
<a name="emulation-testing"></a>

模擬測試由本機執行的應用程式啟用，稱為類似 的*模擬器* AWS 服務。模擬器具有類似於其雲端對應項目的 API，且會提供類似的傳回值。模擬器也可以模擬由 API 呼叫啟動的狀態變更。例如，呼叫 `PutObject`方法時，Amazon S3 模擬器可能會在本機磁碟上存放物件。當 使用相同的金鑰`GetObject`呼叫 時，模擬器會從磁碟讀取相同的物件並傳回它。

以下是模擬測試的優點：
+ 它為習慣在本機環境中專門開發程式碼的開發人員提供最熟悉的環境。例如，如果您熟悉 *n* 層應用程式的開發，您可能有一個資料庫引擎和 Web 伺服器，類似於在生產環境中執行的，在本機電腦上執行以提供快速、本機、隔離的測試功能。
+ 它不需要對雲端基礎設施 （例如開發人員雲端帳戶） 進行任何變更，因此使用現有的測試模式輕鬆實作。模擬測試具有快速的本機開發反覆運算的優點。

但是，模擬器有幾個缺點：
+ 它們通常難以設定和複寫，尤其是當它們用作 CI/CD 管道的一部分時。這可能會增加 IT 人員或管理其軟體安裝的開發人員的工作量和維護。
+ 被模擬的功能和 API 通常滯後於服務變更，並且可能會阻礙採用新功能，直到新增支援為止。
+ 模擬器可能需要支援、更新、錯誤修復或功能對等性增強，這些都是模擬器創作者 (通常是第三方公司) 的責任。
+ 依賴模擬器的測試可以在本機提供成功的結果，但由於與 IAM 政策和配額 AWS 等其他方面的互動，通常不會模擬這些測試可能會在雲端中失敗。
+ 有些 AWS 服務 沒有可用的模擬器，因此如果您只依賴模擬，您可能沒有應用程式部分令人滿意的測試選項。

## 在雲端進行測試
<a name="cloud-testing"></a>

雲端中的測試是針對部署到雲端環境而非桌面環境的程式碼執行測試的程序。在雲端進行測試的價值會隨著雲端原生應用程式的開發而增加。例如：
+ 您可以針對最新的 APIs 和服務功能在雲端中執行測試，確保您的測試反映最新的傳回值和行為，因為 會 AWS 繼續啟動新的服務和功能。
+ 您的測試可以涵蓋 IAM 政策、服務配額、組態以及所有服務。
+ 雲端測試環境與生產執行期環境非常相似，因此在雲端執行的測試可能會在環境中進行時獲得最一致的結果。

在雲端中進行測試的缺點包括：
+ 部署至雲端環境所花費的時間通常比部署至桌面環境更長。諸如 [AWS Serverless Application Model (AWS SAM) Accelerate](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/accelerate.html)、[AWS Cloud Development Kit (AWS CDK) 監看模式](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-deploy-watch)以及 [SST](https://sst.dev/) 等工具有助於降低雲端部署反覆運算相關的延遲。
+ 與使用本機開發環境的本機測試不同，雲端測試可能會產生額外的服務費用。
+ 如果您沒有高速網際網路存取，在雲端進行測試可能較不可行。 
+ 在受管制的產業中，企業安全政策可能會限制開發人員對雲端環境的存取，使得在本機開發工作流程中執行雲端測試變得困難或無法執行。
+ 環境界限通常在開發人員環境之共用帳戶的堆疊層級繪製，有時使用命名空間類型策略 (例如使用字首來識別擁有權)。對於生產前環境和生產環境，通常會在帳戶層級設定界限，以便將工作負載隔離出來，使其不受擾鄰問題的影響，支援最低權限安全控制，並保護敏感資料。建立隔離環境的需求可能會對 DevOps 團隊造成額外的負擔，特別是如果他們位於對帳戶和基礎設施具有嚴格控制的企業中。