負載測試工具的類別
腳本優先。 你用程式碼撰寫測試情境，在本機或分散式環境執行。彈性高、可以審查，維護責任也在你身上。
計畫式。 在 UI 中建立測試情境，並存成專案檔。支援的通訊協定廣泛，但在 pull request 裡很難審查。
雲端託管。 由別人從多個區域執行流量產生器。不必維護基礎設施，按次計費。
對多數團隊來說，選哪一種工具，遠不如「這個測試量到的東西有沒有意義」來得重要。
在你開始做負載測試之前的三項檢查
每秒一個請求時，結果正確嗎？ 對一個本身就有問題的端點做負載測試，量到的只是你能多快地出錯。這是效能工作中最常見、整季白做的浪費。
這次執行會自己清理乾淨嗎？ 負載測試如果建立了資料卻留著不清，就會改變下一次執行的行為，也會影響那個環境上的其他一切。
測試環境有代表性嗎？ 在資料量只有十分之一的環境跑出來的結果，是一個數字，不是預測。
幾乎沒有人打開的那個設定
對回應內容做斷言，至少針對一部分請求。多數負載測試工具都支援，多數團隊卻都關著，因為這會吃掉流量產生器的吞吐量。結果就是：負載報告一片漂亮的綠燈，而每一個回應裡裝的都是空清單。
快而錯比慢而對更糟，因為不會有人去追查它。
真正的價值在測試情境
團隊花很多時間在挑負載測試工具，卻幾乎不花時間在測試情境上，這是本末倒置，因為情境才決定了那個數字有沒有意義。
一千個虛擬使用者猛打同一個端點，很容易建立，卻很少像真實世界的任何東西。真實流量是混合的：大部分是讀取、少量寫入、偶爾一份昂貴的報表，而且全都打在一份已經累積一年歷史的資料集上。系統可能輕鬆扛下合成版本，卻在貼近真實的版本上倒下，因為資源競爭發生在簡單情境從未碰到的地方。
花一個下午看 log，組出一組貼近你實際流量的混合情境，其價值勝過你正在比較的那些工具之間的任何功能差異。
功能正確性驗證該擺在哪裡
系統產生的 API 測試計畫涵蓋邊界與壓力型的案例，能讓那些因結構性原因而拖慢端點的輸入組合浮出水面。一個在大分頁尺寸下效能劣化的查詢，會在容量測試發現它之前很久就在這裡現形，成本也只是零頭。
那不是負載測試，也無法取代負載測試。它是底下那層便宜的驗證，而多數團隊在跑去買負載產生器的路上，跳過的正是這一層。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想安裝任何東西，儀表板也能做同樣的事。命令列能做的其他一切，都在 CLI 儲存庫。
運作細節記載於 API 測試文件。
節奏
發布前與架構變更後做負載測試。正確性則每個 pull request 都驗，因為那是修掉回歸問題最便宜的時機。
GitHub App 是你在 TestSprite 儀表板中設定的一個 webhook。它會監聽你的流程原本就會產生的部署事件，所以你的儲存庫完全不用改。
GitHub Actions 則把這個步驟放進你自己的工作流程裡，從終端機完成設定。
負載測試之前，TestSprite 負責的部分
本頁提到的三項檢查，以產品的形式落實。每秒一個請求時的正確性，透過自動產生的測試覆蓋來驗證，而且斷言的是回應內容，不只是狀態碼。清理的部分，Auto-Cleanup 移除的正是這次執行建立的東西，而不是靠名稱比對。還有那些讓結構性效能問題現形的邊界案例，它們在這裡出現的時間，遠早於容量測試碰到它們。
測試覆蓋來自 API Discovery 加上你的規格。Auto-Authentication 讓 session 保持有效，Dynamic Variables 在呼叫之間傳遞數值，Dependency Chains 則推導出安全的執行順序。
你的負載產生器原封不動留在原地。你得到的是：它產出的那個數字，描述的是一個會回傳正確內容的服務——這就是一次真正的測量，和一個對空無之事很有把握的數字之間的差別。
TestSprite 會產生負載嗎？
不會。它驗證的是正確性，包含邊界案例。持續性的高並行流量需要專門的負載產生器。
我們該選哪一個負載測試工具？
選你們團隊真的會維護的那一個。主流選項之間的差異，遠不如測試情境有沒有意義來得重要。
我們該多久做一次負載測試？
發布前與架構變更後。持續性的負載測試成本很高，而且在這兩個時機之間，通常也測不出什麼新東西。
可以在 CI 裡做負載測試嗎？
冒煙等級的檢查可以。在 CI 裡做完整的容量測試，結果不是負載量沒有意義，就是流程慢到不行。
最常見的錯誤是什麼？
在確認正確性之前就做負載測試。一個回傳空結果的端點，配上一個看起來很有把握的吞吐量數字，比沒有數字更糟。