API 效能測試裡的三個問題
| 容量 | 多少並行流量會開始讓延遲惡化。需要負載產生器。在發布前以及架構變更後執行。 |
| 效能回歸 | 這個 pull request 有沒有讓某個呼叫變得比以前慢。需要的是基準值與比較，而不是高並行。 |
| 正確性 | 回應內容是否正確，包括在輸入很刁鑽的情況下。需要對回應主體做斷言。三者中成本最低，也是最常被略過的一個。 |
為什麼回歸是最值得優先自動化的一項
容量測試執行成本高，而且在不同版本之間很少出現變化。效能回歸剛好相反：它是逐步發生的，一次一個 pull request，等到容量測試抓到時，你面對的是累積了六個月的變更，卻完全不知道是哪一個造成的。
在每次變更時，針對每個呼叫做一次簡單的計時比較、對照基準值，就能在那個慢了十倍的查詢進來的當天抓到它。這比一季一次的容量報告有價值得多。
正確性這道底線
如果回應本身就是錯的，任何計時數字都沒有意義。一個回傳空陣列的端點快得不得了。這聽起來理所當然，但服務就是這樣帶著壞掉的篩選條件和漂亮的延遲圖表上線的。
所以順序是：先正確性，再回歸，最後才是容量。多數團隊的順序剛好相反，因為容量測試才是看起來最像效能工作的那一個。
自動產生的測試涵蓋範圍能補上什麼
API 測試計畫會包含邊界與帶有壓力性質的案例，這些案例會讓那些因為結構性原因、而非負載原因而拖慢端點的輸入組合浮現出來。一個在每頁筆數放大時就會劣化的查詢，會在容量測試發現它之前很久就在這裡現形。
這不是負載測試，也不能取代負載測試。它是位在底下、成本低廉的那一層。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想安裝任何東西，儀表板也能做到同樣的事。命令列能做的其他所有事情，都在 CLI 儲存庫。
工作階段、狀態、執行順序與清理的說明，都收錄在 API 測試文件。
回歸通常藏在哪裡
當一個端點在兩次發布之間變慢，原因幾乎都是這三件事之一，知道這三件事能大幅縮短排查的時間。
查詢失去了索引，或是多了一個索引涵蓋不到的條件。這是遙遙領先的第一名，而且它造成的變化在 diff 裡看不出來，因為 SQL 看起來一切正常。
原本一次來回就能完成的呼叫，現在變成好幾次，通常是因為某個輔助函式開始在迴圈裡一筆一筆撈取關聯資料。程式碼讀起來比以前更清楚，所以它才通得過審查。
某個東西變大了。回應裡包含的一個集合，以前只有五筆資料，現在有五百筆，因為產品做起來了。什麼都沒有壞掉，而這個端點現在對所有人來說都很慢。
執行頻率
有兩條路，而怎麼選其實取決於 pipeline 由誰負責。從儀表板串接 GitHub App 完全不需要改動你的儲存庫，因為它是對你的建置本來就會發出的部署做出反應。加上一個 GitHub Actions 步驟，則是把這項檢查放進儲存庫裡，讓它跟建置流程的其他部分一樣接受審查。
三者之中，TestSprite 涵蓋的是哪一塊
第三個，也就是正確性，以及那些會讓結構性效能問題浮現的邊界案例。一個在每頁筆數放大時就會劣化的查詢，會以失敗或緩慢的邊界案例形式出現，遠早於容量測試觸及它的時間點，而且成本只是零頭。
涵蓋範圍來自 API Discovery 加上你的規格，測試計畫橫跨功能、結構描述、授權、錯誤處理與邊界等類別。Auto-Authentication 讓工作階段在整輪執行期間保持有效，Dynamic Variables 在呼叫之間傳遞數值，Dependency Chains 依據每個案例需要什麼、產出什麼來推導執行順序，Auto-Cleanup 則只清除這輪執行所建立的東西。
你得到的，是多數效能計畫缺少的那一層：在每個 pull request 上執行、會注意到某個端點回傳空結果的東西，而這正是吞吐量圖表會呈現為表現優異的那種失敗。
TestSprite 會測量延遲嗎？
它驗證的是正確性，而不是容量。要量測持續並行下的耗時與吞吐量，需要專門的效能工具。
什麼樣的基準值才合理？
你自己在相同環境下先前量到的數字。從其他產品借來的絕對數值目標，能告訴你的其實非常有限。
效能測試應該擋下合併嗎？
關鍵路徑上出現大幅回歸，應該擋。小幅波動則不該，否則你的時間會花在調整門檻值，而不是把東西交付出去。
為什麼我們量到的數字起伏這麼大？
通常是因為共用環境、冷快取，或是資料量不同。先把這些控制好，再去相信任何比較結果。
有沒有一個工具能同時做到這三件事？
有些工具宣稱可以。但實務上，容量的問題需要負載產生器，正確性的問題需要對回應主體做斷言，能在同一輪執行裡把兩者都做好的，比行銷說法暗示的還要罕見。