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

# 負載測試的基礎規劃
<a name="foundation"></a>

若要確定負載測試的適當工具和設定，請明確執行測試的原因。您必須透過正確類型的測試來解決下列問題：
+ 我的應用程式可以承受多少負載？
+ 我的應用程式是否可以處理 X 負載？
+ 我的應用程式是否自動縱向擴展和縮減？
+ 我的應用程式行為是否會隨著 X 負載量的時間而降級？
+ 我的應用程式是否運作？ (這不是典型的負載測試，但您可以使用負載測試工具來確定您的應用程式是否按預期般運行。)

## 確定測試複雜性
<a name="complexity"></a>

測試複雜性取決於評估的完成程度。基本工具 (例如 [Hey](https://github.com/rakyll/hey) 或 [ab](https://httpd.apache.org/docs/2.4/programs/ab.html)) 可以針對單一應用程式 URI 執行請求。這些工具是最有效率的工具，但其僅測試應用程式的一方面。在某些情況下，這就足夠了。例如，如果您想要測試擴展，只需對端點進行呼叫以在要測試的維度中施加負載即可。例如，CPU 負載可以是巨大的承載或產生 CPU 負載的密集型計算。如果您具有分散式系統，可能想要調用一個端點來啟動一個複雜的分散式程序。

在其他情況下，您可能需要用於執行複雜行為的測試。例如，您需要在開始程序之前登入，或者您要測試包括選取商品和執行購買的訂單流程。這可以理解為一個案例。測試案例需要更複雜的負載測試工具，您可以在其中調整工作負載以符合實際情況。這將產生可用於對最終使用者將體驗到的效能做出聲明的結果。

複雜的測試會為負載生成系統帶來更多負載。對於執行中的負載測試，您不僅必須考慮工具，還必須考慮執行此工具的系統，其中 CPU 和網路頻寬是最重要的方面。設計不當的負載測試電腦系統可能會導致錯誤的結果。例如，單一機器不足以為運作良好的目標建立負載。在這種情況下，您必須設定分散式負載測試。另一方面，運作良好的工具可以為單一伺服器建立更多負載。這將在測試設定的討論中更深入地討論。

## 測量和設定
<a name="measurement"></a>

必須考慮測試環境的代表性。如果您正在執行一個擁有數千台伺服器的大型購物網站，則在不影響最終使用者的情況下測試生產或建立複寫網站大小的測試環境可能會變得困難。此外，建立足夠的流量以對此規模的系統施加壓力也需要複雜的負載測試設定。因此，負載測試通常在較小的、可比較的設定上執行，您可以使用這些設定對生產環境做出假設。建立基準或功能需求的測試可以在生產環境中執行。

最佳實務是記錄後續測試的測試環境，以便您具有一個明確定義的規格，以及針對哪種規模的目標環境所預期的結果。

考慮受負載測試影響的基礎設施的所有元素。雖然測試通常關注主機的 CPU 和記憶體，但還有其他相關的副作用需要考慮。

典型的副作用是服務之間通訊的網路頻寬可能達到其限制。對於透過網際網路連接的服務或分散式系統，通訊通常是基於網路。使用給應用程式帶來壓力的負載測試也會對基礎網路基礎設施造成壓力。

## 負載建模和逐級測試
<a name="modeling"></a>

對於不同的測試，您可以對測試過程中產生的負載進行建模。一個基本方法是建立一個逐級進度，隨著時間的推移逐漸增加負載。這將為每個步驟建立不同的資料點，可讓您在單一測試執行中得出更詳細的結論。若要找到與您的應用程式相關的限制，最佳實務是以低於您預期最高效能的典型使用情況的負載開始測試。當您逐漸增加負載時，將看到應用程式效能降級的限制。結果將顯示預期行為是否仍然有效以及您的應用程式在錯誤情況下的行為是否符合預期。例如，在測試超出限制時，您可能會預期應用程式[消減負載](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/)。

使用複雜的工具，您可以設定一個模式作為測試的組態。這將定義一段時間內將產生多少負載以及它將如何增加或減少。

大多數基本工具都是命令列工具，需要您自己編寫解決方案指令碼。在您編寫自己的指令碼時，確保您不會意外覆寫要保留的指標。每次反覆運算的輸出檔案都應具有新的後綴，這樣您就不會覆寫先前反覆運算的結果。