API 負載測試真正量到的是什麼
容量： 在延遲開始惡化之前，每秒能處理多少請求。答案來自產生並行流量，並觀察回應時間與錯誤率。
正確性： 回應裡裝的是不是對的東西。答案來自拿回應內容對照預期值做斷言。
只檢查狀態碼的負載測試，就算每一筆回應都是空清單，也會回報一次漂亮的執行結果。服務又快又錯，而又快又錯比又慢又對更糟，因為沒有人會去查它。
功能測試套件能告訴你哪些負載相關的事，又有哪些不能
自動產生的 API 測試計畫會包含邊界與壓力形態的案例：過大的 payload、超出範圍的數值、不尋常的參數組合。這些確實能抓到一類真實的失敗，但它們不是負載測試。它們一次只測一個邊界，而不是衡量服務在持續並行流量下的行為。
所以誠實的分工是這樣：容量交給專門的負載測試工具，正確性交給功能驗證，包括那些只有在丟進刁鑽輸入時才會現形的邊界情況。兩者都無法取代對方，而兩件事都做，比在正式環境才發現這道落差便宜得多。
在做負載測試之前，值得先確認的三件事
每秒一個請求時，它是對的嗎
對一個壞掉的端點做負載測試，只是在量你能錯得多快。
它會清理自己嗎
一次負載測試建立了資料卻沒清掉，就會改變下一次執行的行為。
這個環境有代表性嗎
在只有十分之一資料量的環境跑出來的負載結果，不是預測，只是一個數字。
真實條件下的正確性
真正值得補起來的落差，不在負載測試與功能測試之間。而是大多數功能測試都跑在乾淨、閒置的環境上，所以永遠看不到資料量一大、狀態一亂才會冒出來的失敗。把功能檢查放到一個被用過的環境上跑，是找出這些問題的便宜做法。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想在本機安裝任何東西，同樣的設定在 TestSprite 儀表板裡也做得到。CLI 其餘的功能說明都在 CLI 儲存庫。
決定一套 API 測試能不能長久維持的四件事——工作階段、擷取到的值、執行順序與清理——請見 API 測試文件。
誠實地解讀負載測試結果
負載測試的結果大概比任何其他測試輸出都更容易被過度解讀，而且通常往兩個方向偏。
從一個和正式環境不一致的環境量到的數字，充其量只是下一次執行的比較基準。資料庫只有一半、資料只有十分之一、沒有其他流量、執行個體規格也不同。把那個數字當成容量報出去，團隊就會在上線當天，被一個自以為已經量過的數字嚇到。
另一個方向是把「通過」當成健康的證據。如果這次執行只對狀態碼做斷言，那你量到的只是服務在負載下回得很快——而當查詢回傳的是空集合時，它會回得非常有效率。對一部分請求打開回應內容的斷言，同一次執行才真的告訴你一些事。
每一次變更都跑正確性驗證
負載測試適合排程執行，或在發布前跑一次。正確性驗證則屬於每一個 pull request，因為那是修掉迴歸問題成本最低的時機。
GitHub App 是你在 TestSprite 儀表板裡設定的一個 webhook。它會監聽你現有管線本來就會發出的部署事件，所以你的儲存庫完全不用改。
GitHub Actions 則是把這個步驟放進你自己的工作流程裡，從終端機完成設定。
TestSprite 在負載測試周邊的位置
TestSprite 負責的是正確性這一層，也就是讓容量數字真正有意義的那一層。它會依照你預期的行為去操作 API，包含邊界與授權的案例，並回報實際拿回來的內容，而不只是回得多快。
測試涵蓋範圍來自對執行中服務的一輪探索，再加上你手上既有的規格，所以那些刁鑽的輸入不必任何人動手寫就已經包含在內。Auto-Authentication 讓工作階段在整次執行中保持有效，Dynamic Variables 在呼叫之間傳遞值，Dependency Chains 依照每個案例需要什麼、產出什麼推導出執行順序，Auto-Cleanup 則只清掉這次執行建立的東西。
好處是替效能工作墊了一層底：在你花一整天量吞吐量之前，你已經知道這個端點回傳的是對的東西。持續並行的壓力仍然交給你的負載產生器，兩者以不同的節奏執行，互不干擾。
TestSprite 做負載測試嗎？
不做。它驗證的是正確性，包含邊界案例。持續並行流量下的容量，需要專門的負載測試工具。
負載測試裡可以對回應內容做斷言嗎？
大多數負載測試工具都支援，但很少團隊會打開，因為這會吃掉產生器的吞吐量。值得對一部分請求做，而不是全部。
哪一個該先做？
正確性。對一個回傳錯誤內容的端點做負載測試，只會得到一個很有自信、卻什麼都沒說明的數字。
負載測試該多久做一次？
發布前，以及架構變動之後。持續不斷地做負載測試成本很高，而且在這兩個時機點之間，通常也問不出什麼新東西。
那在 CI 裡做負載測試呢？
冒煙測試規模的負載檢查是可行的。但把完整的容量測試放進 CI，結果通常不是負載等級低到沒有意義，就是管線慢得受不了。