專注 API 管理、DevOps 整合、自動化測試與軟體品質工程的顧問服務
說到「API 壓力測試 (Load Testing)」,所有工程師的第一反應幾乎都是 Apache JMeter。 沒錯,JMeter 是免費的、強大的、開源的業界標準。但與此同時,它也是出了名的介面複雜、學習曲線陡峭、且維護痛苦。 如果你曾經打開 JMeter,看著那堆 “Thread Group”、”BeanShell Sampler” 發呆;或者為了要在測試中傳遞一個簡單的 JSON 參數,還得去查 Java 語法怎麼寫… 這篇文章就是為你寫的。 另一些人可能會說:「那我用 Postman 的 Collection Runner 跑多個次數不就好了?」 大錯特錯。 Postman Runner 是「序列執行 (Sequential)」(做完一次做下一次),而不是「平行併發 (Concurrent)」(同時擠進來)。用 Postman 測出來的效能數據,充其量只能滿足「大量的資料」而非「高流量」,因此在真實的高流量情境下「完全沒有參考價值」。 其實,做壓力測試不需要在「難用的 JMeter」與「不是用來做壓測的 Postman」之間做選擇。 ReadyAPI 的設計哲學只有一個:「不要為了測效能而重新寫一次腳本」。 痛點一:拒絕「重複造輪子」 (The Double Work Trap) 這是測試團隊最常見的低效能流程: QA 甲 用 Postman 寫好了功能測試,確認 API 邏輯正確。 要上線前,QA 乙 打開 JMeter,把 QA […]
你是否也經歷過這樣的場景? 早會剛結束,後端工程師丟給你一句:「API 改好了,你再跑 Postman 測一下。」 你打開 Postman,發現上次存的 Collection 已經過期了。你只好請同事把他的 json 檔匯出傳給你,結果匯入後發現環境變數 (Environment Variables) 全部跑掉。 為了測一個登入功能,你手動改了 10 次參數,點了 10 次 Send。 你以為你在省公司的錢(因為 Postman 是免費的),但其實,你正在浪費公司最貴的資源——你的時間。 在台灣,90% 以上的團隊都依賴 Postman 進行 API 測試。但在這篇文章中,我要告訴你一個反直覺的真相:當你的「團隊超過 3 個人」,或者「API 超過 50 支」時,堅持使用「免費版 Postman」可能是你做過成本最高的決策。 隱形成本一:協作的「檔案地獄」 (The File Hell) Postman 免費版最致命的傷,就是它的協作模式。 在沒有購買昂貴的 Enterprise 版之前,團隊分享測試腳本的方式通常是:Export JSON -> 丟 Slack/Line -> Import JSON。 這聽起來很簡單,但災難往往發生在細節裡: 版本衝突: A 同事改了腳本,B […]