JMeter 真正出色的地方
產生並行負載。 執行緒群組、逐步加壓、分散式產生器。這正是它當初被設計出來的目的，至今仍是最好的免費選擇之一。
協定涵蓋面廣。 遠遠不只 HTTP，這對於含有訊息傳遞與資料庫層的企業系統很重要。
它早就裝好了。 這不是技術優點，卻是團隊選它的真實原因。
JMeter API 測試開始彆扭的地方
測試計畫是 XML
想在 pull request 裡審查一項變更，幾乎是不可能的任務。
.jmx 檔的合併衝突，則是另一種等級的痛苦。
預設的斷言很淺
回應碼與子字串比對能涵蓋常見情況，除此之外就沒什麼了。
只要牽涉到結構性的檢查，就得動用腳本元件。
狀態全靠手動
擷取器、變數與控制器，全都得一個一個手動接起來。
相依關係圖藏在測試計畫的結構裡，而不是被明確宣告出來。
行得通的分工
把 JMeter 留給容量問題：服務在持續並行之下表現如何、延遲會從哪裡開始惡化、什麼會最先壞掉。這正是它的用途，本文沒有任何一處在建議換掉它。
把功能正確性搬到另一個地方——一個把工作階段、擷取到的值、執行順序與清理當成產品本身的一部分，而不是當成要你自己拼裝的元件的地方。這四項的說明，請見 API 測試文件。
無論如何，有一件事值得在 JMeter 裡做
在你的負載計畫裡加上回應內容的斷言，哪怕只抽樣一部分請求也好。只檢查狀態碼的負載測試，就算服務回傳的是空結果，也照樣會回報一切正常；而「又快又錯」是最糟的結果，因為沒有人會去追查它。
把功能測試這一層建起來
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
不想在本機安裝的人，用儀表板也能做到同樣的事；完整的指令清單則收錄在 CLI 儲存庫。
把 .jmx 的問題說白
在 JMeter 裡做功能覆蓋之所以愈久愈難維護，問題不在斷言，而在檔案格式，值得具體說明原因。
測試計畫是 GUI 產生的 XML。只改一條斷言就開一個 pull request，得到的 diff 會是一堆被重新排序的元素和自動產生的識別碼，於是審查變成一種信任遊戲。同一週裡兩個人改同一份計畫，會產生一種合併衝突：與其讀懂它，不如直接捨棄其中一邊來得省事。而正因為審查不切實際，這份計畫就會不斷累積沒人看過的變更。
這是實實在在的成本，而當計畫只由一個人維護時，這筆成本完全看不見——偏偏大多數 JMeter 測試套件，正是在這種情況下建起來的。
不同的執行節奏
負載測試在發布前與架構變更後跑。正確性則每個 pull request 都跑，因為那是修掉回歸問題成本最低的時機。
GitHub App 是你在 TestSprite 儀表板裡設定的一個 webhook。它會監聽你的管線本來就會產生的部署事件，因此你的儲存庫完全不必改動。
GitHub Actions 則是把這個步驟放進你自己的工作流程裡，從終端機完成設定。
TestSprite 能從負載計畫裡接走什麼
那些只因為 JMeter 本來就在、才被塞進 JMeter 的功能覆蓋。測試計畫由一次探索掃描加上你的規格產生，以自然語言描述，而不是靠元件拼裝出來；而且可以在 pull request 裡審查，而不是埋在自動產生的 XML 裡。
Auto-Authentication 讓工作階段在整輪執行中保持有效，Dynamic Variables 在呼叫之間傳遞值，Dependency Chains 依據每個案例需要什麼、產出什麼來推導執行順序，Auto-Cleanup 則精準清除這一輪執行所建立的東西。這些正是你現在要靠擷取器、變數、控制器和 teardown 執行緒群組自己組出來的部分。
你的負載計畫原封不動，繼續做 JMeter 真正出色的那件事。改變的是：正確性測試變成每個 pull request 都跑，而不是等到發布前才跑；而且斷言的變更，第二個人也讀得懂。
JMeter 能做功能性的 API 測試嗎？
可以，只是整個使用體驗處處跟你作對。XML 計畫、淺薄的預設斷言，以及全手動的狀態處理，就是你要付的代價。
我們該換掉 JMeter 嗎？
負載測試不必換。該換掉的是當初誤打誤撞跑到上面的功能覆蓋，負載計畫留著。
那 Taurus 或 JMeter DSL 呢？
兩者都大幅改善了撰寫體驗，但都改變不了這個工具原本被最佳化的方向。
兩者可以同時放在 CI 裡跑嗎？
可以。它們以不同的節奏回答不同的問題，而且彼此都不需要知道對方的存在。
TestSprite 會產生負載嗎？
不會。它驗證的是正確性，包含邊界情況。持續並行是 JMeter 的地盤。