本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
無伺服器應用程式的測試技巧
針對無伺服器應用程式代碼,有三種主要方法來執行測試:模擬測試、雲端測試和仿真測試。您通常會發現,在單個專案內會混合使用這些方法。例如,可能會在本機開發程式碼時使用模擬測試,但您的程式碼可能會在雲端進行測試,作為夜間持續整合和持續交付 (CI/CD) 程序的一部分。
模擬測試
模擬測試是一個策略,可透過它在程式碼中建立替代物件,來模擬雲端服務的行為。例如,您可撰寫一個使用 Amazon S3 服務模擬的測試,可以設定該模擬,以便在呼叫 CreateObject 方法時傳回特定回應物件。執行測試時,該模擬會將回應傳回,而無需呼叫 Amazon S3 或任何其他服務端點。
這些替代物件通常由模擬框架產生,以減少給定測試必需的實作量。有些模擬架構是一般的,有些則是專門針對 AWS SDKs。
模擬與虛設都屬於更廣泛的仿造類別。模擬物件與模擬器不同 (本節稍後會討論),模擬通常由開發人員建立或設定,作為測試程式碼的一部分,而模擬器是獨立的應用程式,會以與其所模擬系統的相同方式公開 API (例如 REST API)。
以下是使用模擬物件的優勢:
-
模擬物件可以模擬超出應用程式控制範圍的第三方服務,例如 API 和軟體即服務 (SaaS) 供應商,無需直接存取這類服務。
-
模擬物件在測試失敗條件非常實用,尤其當這種情況 (例如服務中斷) 很難模擬時。
-
像模擬器一樣,模擬框架可以在設定完成後提供快速的本機開發。
-
模擬物件可以為幾乎任何類型的物件提供替代行為,因此模擬策略可以為各種比模擬器更廣泛的服務建立涵蓋範圍。
-
當新功能或行為推出時,模擬測試可以使用 (或回復) 一般模擬架構,以更快的速度做出反應,一旦更新後的 AWS SDK 推出,就可以模擬新功能。
以下是模擬物件測試的缺點:
-
模擬物件通常需要進行相當複雜的設定和組態工作,尤其是在嘗試確定不同服務的傳回值以正確模擬回應的情況。
-
因為模擬由編寫測試的開發人員編寫或設定,所以這是開發人員的額外責任。
-
您可能需要存取雲端,才能了解服務的 API 和傳回值。
-
模擬也可能很難維護,因為每當被模擬的雲端 API 簽章變更時、傳回值結構描述演變時、或者測試的應用程式邏輯擴展為呼叫新 API 時,其都需要更新。這些變更會為開發人員帶來額外的測試開發工作量。
-
模擬測試可能會在桌面環境中順利通過,但在雲端中失敗。
-
模擬架構,例如模擬器,在測試或偵測 AWS Identity and Access Management (IAM) 政策或配額限制時受到限制。
-
雖然模擬物件在授權失敗或超過配額時模擬應用程式操作的效果更佳,但是當程式碼部署到生產環境時,模擬測試無法確定實際將會出現什麼結果。
在雲端進行測試
雲端中的測試是針對部署到雲端環境而非桌面環境的程式碼執行測試的程序。在雲端進行測試的價值會隨著雲端原生應用程式的開發而增加。例如:
-
可以針對最新的 API 在雲端進行測試並傳回值。
-
您的測試可以涵蓋 IAM 政策、服務配額、組態以及所有服務。
-
雲端測試環境與生產執行期環境非常相似,因此在雲端執行的測試可能會在環境中進行時獲得最一致的結果。
在雲端中進行測試的缺點包括:
-
部署至雲端環境所花費的時間通常比部署至桌面環境更長。諸如 AWS Serverless Application Model (AWS SAM) Accelerate、AWS Cloud Development Kit (AWS CDK) 監看模式以及 SST
等工具有助於降低雲端部署反覆運算相關的延遲。 -
與使用本機開發環境的本機測試不同,雲端測試可能會產生額外的服務費用。
-
如果沒有高速網際網路存取權,則在雲端中進行測試可能不太可行。
-
在雲端中進行測試通常需要彼此隔離的雲端環境。環境界限通常在開發人員環境之共用帳戶的堆疊層級繪製,有時使用命名空間類型策略 (例如使用字首來識別擁有權)。對於生產前環境和生產環境,通常會在帳戶層級設定界限,以便將工作負載隔離出來,使其不受擾鄰問題的影響,支援最低權限安全控制,並保護敏感資料。建立隔離環境的要求可能會給 DevOps 團隊帶來額外的負擔,特別是如果他們身處對帳戶和基礎設施有嚴格控制的企業中。
仿真測試
模擬測試由本機執行的應用程式啟用,稱為類似 AWS 服務的模擬器。模擬器具有類似於其雲端對應項目的 API,且會提供類似的傳回值。模擬器也可以模擬由 API 呼叫啟動的狀態變更。例如,當呼叫 PutObject 方法時,Amazon S3 模擬器可能會在本機磁碟中儲存物件。使用相同的金鑰呼叫 GetObject 時,模擬器會從磁碟讀取相同的物件並傳回它。
以下是模擬測試的優點:
-
它為習慣在本機環境中專門開發程式碼的開發人員提供最熟悉的環境。例如,如果您熟悉 N 層應用程式的開發,則可能會具有類似於在生產環境、本機電腦中執行的資料庫引擎和 Web 伺服器,以提供快速、本機且隔離的測試功能。
-
它不需要對雲端基礎設施 (例如開發人員的雲端帳戶) 進行任何變更,因此可以輕鬆透過現有的測試模式進行實作。模擬測試具有快速的本機開發反覆運算的優點。
但是,模擬器有幾個缺點:
-
通常很難對其進行設定和複寫,特別是用作 CI/CD 管道的一部分時。這可能會增加 IT 人員或管理其軟體安裝的開發人員的工作量和維護。
-
被模擬的功能和 API 通常滯後於服務變更,並且可能會阻礙採用新功能,直到新增支援為止。
-
模擬器可能需要支援、更新、錯誤修復或功能對等性增強,這些都是模擬器創作者 (通常是第三方公司) 的責任。
-
依賴模擬器的測試可以在本機提供成功的結果,但由於與 IAM 政策和配額 AWS 等其他方面的互動,它們可能會在雲端中失敗,通常不會模擬。
-
某些 AWS 服務沒有可用的模擬器,因此如果您只依賴模擬,您可能沒有應用程式部分令人滿意的測試選項。