「效能測試喔,那要會寫程式吧。」這句話擋住了多少測試人員,就擋了多少年。工具門檻、腳本門檻、環境門檻,一層一層疊上去,最後變成一種默契:效能測試是別人的事。於是每次上線前,沒有人真的回答得出那個問題——我們的系統,到底撐得住多少人?
這個系列想把那句話拆掉。AI 協作工具改變了入場條件:寫腳本這件事,現在可以交給 Claude Code;產生負載、收集數據,交給 k6。你不需要先學會 JavaScript 才能開始。
一、圖表之上,還缺一層文字 Day 20 練習二那個 30 秒的挫折,你應該還記得:report.html 打開了,曲線漂亮、數字齊全,假裝成主管的你卻答不出「...
一、一張單子的兩種命運 Day 21 的報告寄出去了,主管看完 30 秒,說了一句「那請 RD 處理一下」。接下來的事情你很熟:開一張單。同一個發現,兩種開法—...
一、第五次手動跑同一個測試的時候 Day 22 結尾留了一個伏筆:量尺要「固定地量」,才會從守門員變成量尺。但固定地量意味著重複——同一個 smoke 腳本、同...
一、撐得了多久,是第三個問題 Day 1 說效能測試回答三個問題:撐得住多少人、多快回應、撐得了多久。前面二十三天幾乎都在前兩題上;第三題一直被放在後面,因為它...
一、當 Day 19 的四問告訴你「極限是你自己」 這個場景遲早會遇到:目標是 500 個 VU 的 load test,跑到 300 VU 時,Day 19...
一、那個對不上的體感 這個場景你大概遇過,或者即將遇到:Day 21 的報告寫著全綠,/api/pizza p95 只有 180ms,門檻 800ms 綽綽有餘...
一、把 Day 26 缺的那一塊補上 Day 26 結尾留了一個問題。你量出了 QuickPizza 的 LCP——但那是安靜時的 LCP:整個網站只有你一個瀏...
一、當請求不再是「一來一回」 前面二十七天的所有測試,骨子裡都是同一個動作:發一個請求,等一個回應,量中間的時間。HTTP 的世界觀就是一來一回,http_re...
一、先把功勞算清楚 回頭看 Day 4:你用一段中文描述,拿到一支能跑的 k6 腳本。在沒有 AI 的年代,那一步是三週的 JavaScript 入門加上翻文件...
一、把 30 天摺成一張地圖 先把走過的路攤開。這 30 天不是三十個獨立的主題,是一棟四層的房子,每一層都踩在下一層上: 圖 1:30 天知識地圖——四個階段...