把 API 效能測試工具對應到這三個問題
容量 → 負載產生器
執行緒群組、逐步加壓、分散式工作節點。
在發布前與架構變更後執行。持續執行的成本很高。
回歸 → 時間比對
需要的是基準線與差異比對，而不是高並行。
三者之中成本最低的一項，也是最常缺席的一項。
正確性 → 功能驗證
針對回應主體做斷言，包括刁鑽輸入的情況。
另外兩者的底層基礎。
多數團隊缺少的那一類
幾乎每個說自己有做效能測試的團隊都有負載產生器，但很少有團隊會針對每一次變更監看效能回歸。就成本與收穫而言，這個順序反了。
容量在版本之間很少改變，所以持續測它得不到什麼資訊。效能回歸則是一個 pull request、一個 pull request 累積出來的；等到每季一次的容量測試抓到它，你面對的是半年份的 commit，完全不知道是哪一次加進了那個沒有索引的查詢。
每一類該看什麼
負載產生器： 能不能對回應主體做斷言，至少抽樣檢查。多數工具做得到，但很少團隊會開啟，這就是為什麼負載測試報告一片乾淨，而每一個回應其實都是空的。
回歸工具： 它比對的是你自己的歷史數據，還是一個絕對門檻。別人的目標值說明不了你自己的產品。
功能驗證： 有沒有涵蓋邊界案例。一個在大分頁尺寸下就開始變慢的查詢是結構性問題，在這裡會比容量測試早很多就被抓出來。
誠實地解讀百分位數
效能工具會給你百分位數，而這些數字經常被誤讀，誤讀的方式剛好會蓋掉你正在找的那個問題。
看起來漂亮的 p50 只說明了中位數的那一筆請求，對於運氣不好的人經歷了什麼完全沒有交代。一個每小時被呼叫一千次的端點，就算 p99 看起來沒問題，也代表每小時有十筆慢請求，也就是十個不耐煩的使用者。而把所有端點平均起來的數字幾乎沒有意義，因為它把健康檢查和報表產生混在一起算。
兩個習慣就能解決大部分問題：按端點分別看百分位數，而不是看整體加總；看 p95 和 p99，而不是看平均值。真正重要的端點通常就那幾個，長期追蹤那四個數字，比任何一次把所有東西攤開來的儀表板都更有用。
能省錢的順序
先正確性，再回歸，最後容量。對一個回傳錯誤內容的端點做負載測試，只會得到一個很有自信卻毫無意義的數字，而這正是效能專案浪費掉第一季最常見的方式。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想在本機安裝任何東西，TestSprite 儀表板也提供同樣的設定方式。CLI 其餘的功能都整理在 CLI 儲存庫。
工作階段、擷取的變數值、執行順序與清理，都記錄在 API 測試文件。
有兩條路徑，而選哪一條其實取決於誰擁有這條 pipeline。從儀表板連接 GitHub App 完全不需要更動你的儲存庫，因為它是對你的建置流程本來就會發出的部署事件做出反應。加上一個 GitHub Actions 步驟，則是把這項檢查放進儲存庫裡，讓它像建置流程的其他部分一樣接受審查。
TestSprite 補上的是什麼
正確性這一欄，也就是另外兩者的底層基礎。它斷言的是回應主體而不是狀態碼，涵蓋會讓結構性變慢浮現的邊界案例，並且在每一次 pull request 都會執行。
測試覆蓋是由一次探索掃描加上你的規格文件產生的。Auto-Authentication 讓工作階段在整輪執行中保持有效，Dynamic Variables 在呼叫之間傳遞變數值，Dependency Chains 推導出執行順序，Auto-Cleanup 則精準移除這輪執行所建立的東西。
它的價值在於，你的容量數字開始描述的是一個真的能運作的服務。一個在大分頁尺寸下變慢的查詢，在這裡被找出來的成本只是負載測試的零頭；而一個默默回傳空結果的端點，也不會再在吞吐量上拿到漂亮成績。
TestSprite 屬於這個類別嗎？
屬於正確性那一欄。它驗證的是行為，包括邊界案例，並不會產生持續的負載。
有沒有一個工具可以涵蓋這三件事？
有些工具宣稱可以。但實務上，產生負載和深入斷言回應主體是互相拉扯的，因為斷言會吃掉產生器的吞吐量。
合理的回歸門檻該設多少？
用你自己的數據波動來設。如果在沒有其他負載的環境下，每次執行的數字都會差上百分之十，那百分之五的門檻只是雜訊。
我們需要分散式的負載產生嗎？
只有在單一產生器成為瓶頸的時候才需要。很多團隊買了分散式的產能，卻從來沒有把它用滿過。
各自應該在哪裡執行？
正確性與回歸在每一次 pull request 執行。容量則在發布前與架構變更後執行。