如果你是一位「手動測試」出身的測試人員,過去十年聽過效能測試很多次,但每次想學就被「要寫程式」這四個字擋下來——這篇就是寫給你的。
以前學效能測試的痛點很實際:JMeter 介面複雜、變數設定眼花繚亂,GUI 拖拉之後出來的東西看不懂;k6 看起來輕巧,但要寫 JavaScript,腳本貼上去報錯卻不知道怎麼修。結果就是「想學但永遠沒入門」。
AI 工具改變了這個遊戲規則。
現在你只要會「描述你想要測什麼」,Claude Code 就能幫你產出可執行的 k6 腳本、解讀錯誤、調整參數、解釋結果。你不需要先學會 JavaScript,你只要學會「怎麼跟 AI 講清楚你要的測試是什麼」——而這個能力,本來就是測試人員最核心的能力。
這篇教學的目標,是讓你在大約兩個小時內,從零跑出第一個 k6 效能測試,而且看得懂結果。
重點不是讓你變成 k6 工程師。重點是讓你成為「會用 AI 設計效能測試」的測試人員——這在 2026 年比前者值錢得多。
開始之前你要懂的三件事
第一件事:效能測試在測什麼
簡單講,效能測試是模擬「很多使用者同時用系統」的情境,看系統會不會慢、會不會壞。
舉個例子。你的公司網站平常一秒鐘有 10 個人在用,沒什麼問題。但雙 11 活動開跑的瞬間,一秒鐘變成 5000 個人同時點進來——這時候系統會不會撐住?頁面會不會打不開?訂單會不會掉?這些就是效能測試要回答的問題。
效能測試會給你三類數字:
- 回應時間(Response Time):使用者點一下,要等多久才看到結果。通常以毫秒(ms)為單位。
- 吞吐量(Throughput / RPS):系統每秒能處理多少個請求。RPS = Requests Per Second。
- 錯誤率(Error Rate):有多少個請求是失敗的(回 500、timeout 等)。
第二件事:k6 是什麼
k6 是一個開源的效能測試工具,由 Grafana Labs 維護(就是做那個有名的監控面板 Grafana 的公司)。它的特色是:
- 輕量:不用 Java、不用 GUI,單一執行檔就能跑
- 用 JavaScript 寫測試腳本:程式碼結構簡單,AI 特別擅長產出
- 適合自動化:可以直接接進 CI/CD pipeline
- 社群活躍、文件齊全
這篇我們會選 k6,因為它對 AI 最友善——這對「不會寫程式」的你,是最重要的優勢。
第三件事:Claude Code 在這裡扮演什麼角色
Claude Code 是 Anthropic 的命令列 AI 助手,可以在你的終端機(Terminal)裡跟它對話,它能讀檔、寫檔、跑指令。
在這篇教學裡,Claude Code 會幫你做這些事:
- 根據你的自然語言描述,寫出 k6 測試腳本
- 解釋每一行腳本在做什麼
- 幫你跑測試、看結果
- 看到報錯時,告訴你怎麼修
- 分析測試結果、解讀數字背後的意義
你的工作只有一個:用中文描述你想要的測試是什麼。
環境準備清單
我們假設你已經裝好以下兩樣東西(如果還沒,可以請任何工程師朋友幫你裝,5 分鐘的事):
| 工具 | 用途 | 檢查指令 |
| k6 | 效能測試工具本身 | k6 version |
| Claude Code | AI 助手,幫你寫腳本 | claude –version |
打開終端機(Mac 是 Terminal,Windows 是 PowerShell 或 Windows Terminal),輸入上面的檢查指令。如果跑出版本號就代表裝好了。
第一次跟 Claude Code 對話
先建立一個資料夾來放我們的測試,然後啟動 Claude Code。打開終端機,依序輸入以下指令(每打完一行按 Enter):
mkdir k6-learning
cd k6-learning
claude
看到 Claude Code 的提示符號(通常是一個閃爍的游標等你輸入)出現,就可以開始對話了。
我們的第一個任務:測試一個公開的 API
為了不打擾任何真實系統,我們用 k6 官方提供的測試網站:
這個網站專門設計給大家學 k6 用的,你可以放心打它。
直接把這段話貼給 Claude Code
打開 Claude Code 之後,把下面這段話完整複製貼進去,按 Enter:
我要學 k6 效能測試,完全不會寫程式。
請幫我做這件事:
1. 建立一個 k6 測試腳本,檔名叫 first-test.js
2. 測試的目標是 https://test.k6.io
3. 設定 10 個虛擬使用者(VU),測試 30 秒
4. 每個使用者每次請求之間等 1 秒
5. 加上一個檢查:HTTP 狀態碼必須是 200
寫完之後,逐行用中文解釋這個檔案在做什麼,
最後告訴我要怎麼執行它。
Claude Code 會幫你建立檔案、解釋內容、給你執行指令。這時候你不需要看懂每一行 JavaScript,但要看懂 Claude 的「中文解釋」——這就是學習真正發生的地方。
這是一個很重要的習慣:每次叫 AI 寫東西,都要求它「用中文解釋」。久了你自然會懂這些程式碼在說什麼,不需要刻意背語法。
Claude Code 大概會產出這樣的腳本
(你看一下就好,不用記)
import http from ‘k6/http’;
import { check, sleep } from ‘k6’;
export const options = {
vus: 10,
duration: ’30s’,
};
export default function () {
const res = http.get(‘https://test.k6.io’);
check(res, {
‘status is 200’: (r) => r.status === 200,
});
sleep(1);
}
這就是一個完整的 k6 測試腳本。看起來像天書沒關係,我們先讓它跑起來。
跑出你的第一次測試
Claude Code 會告訴你執行指令,大概是這樣:
k6 run first-test.js
輸入這行、按 Enter。如果一切正常,你會看到終端機開始跑出一大堆數字和進度條。30 秒後,測試結束,會出現一份報表。
把報表貼回去給 Claude Code
這是這篇教學最關鍵的一招——別自己硬看報表。
把整份報表複製貼回 Claude Code,加上這句話:
這是剛剛跑完的結果,請用中文逐項解釋:
1. 哪些數字代表什麼意義
2. 這次測試的結果算好還是不好
3. 如果是上線前的最後檢查,我應該關注哪些數字
4. 哪些紅字代表有問題
Claude 會把整份報表翻譯成中文、告訴你重點在哪。你會發現你在跟 Claude 對話的過程中,自然而然學會看 k6 報表——這比任何教學影片都有效。
報表裡你會看到的主要數字
| 數字名稱 | 代表什麼意思 |
| http_req_duration | 每個請求花了多久(回應時間)。看 avg、p(95) 這兩個就好。 |
| http_reqs | 總共送出多少請求,以及每秒幾個請求(RPS)。 |
| http_req_failed | 失敗率。0% 是完美,超過 1% 就要注意。 |
| vus | 虛擬使用者數量(你設定的 10 個)。 |
| checks | 檢查項目的通過率(我們設定狀態碼要是 200)。 |
特別注意 p(95) 這個指標
p(95) 唸做「P95」,意思是「95% 的請求都比這個數字快」。它比 avg(平均值)更值得看,因為平均值會被少數慢的請求拉低,而 P95 反映的是「大部分使用者的真實體驗」。
舉個例子:100 次請求裡,99 次都是 100ms,1 次是 5000ms。平均值大概是 149ms 看起來還可以,但其實有人等了 5 秒。P95 = 100ms 告訴你「95% 的人體驗良好」,而 P99 = 5000ms 才會把那個慘案抓出來。
業界常用的標準是 p(95) < 500ms 算可接受、p(95) < 200ms 算優秀。但這個標準依產業而定——金融交易系統可能要求 50ms 內,內部報表系統 2 秒都可以。
四種你一定會用到的測試類型
跑完第一個測試,接下來你要學會「為什麼要跑這個測試」。效能測試不是只有一種,目的不同,設定就不同。
1. Smoke Test(冒煙測試)
目的:確認系統還活著。VU 設定 1~2 個,跑 1 分鐘。
什麼時候用:每次部署完成後立刻跑,30 秒內知道有沒有破。
叫 Claude Code 幫你寫的時候,你可以這樣講:
幫我寫一個 smoke test 腳本,
目標是 https://test.k6.io,
1 個 VU、跑 1 分鐘、每次間隔 2 秒。
檔名叫 smoke-test.js
2. Load Test(負載測試)
目的:模擬「正常使用情境」,確認系統在預期流量下表現正常。
什麼時候用:上線前的標準關卡。例如系統預期最高 100 人同時在線,就用 100 個 VU 跑 10 分鐘。
這個測試會用到「ramp-up(漸進加壓)」,意思是不要一開始就把 100 個 VU 全部塞進去,而是慢慢爬上來。叫 Claude Code 寫的時候:
幫我寫一個 load test 腳本,
目標是 https://test.k6.io,
使用 ramp-up 模式:
– 前 2 分鐘從 0 慢慢加到 100 個 VU
– 維持 100 個 VU 跑 5 分鐘
– 最後 2 分鐘從 100 降回 0
加上門檻設定:p(95) 必須小於 500ms,失敗率必須小於 1%
檔名叫 load-test.js
3. Stress Test(壓力測試)
目的:找出系統的「極限」——加壓到什麼程度會撐不住。
什麼時候用:你想知道「我們的系統最多能扛多少人」的時候。
幫我寫一個 stress test 腳本,
目標是 https://test.k6.io,
分階段加壓:
– 0 → 100 VU(2 分鐘)
– 100 → 500 VU(5 分鐘)
– 500 → 1000 VU(5 分鐘)
– 1000 → 0(2 分鐘)
檔名叫 stress-test.js
4. Spike Test(尖峰測試)
目的:模擬「流量瞬間暴衝」的情境,例如雙 11 開賣的那一秒。
什麼時候用:你的系統會遇到突發流量的時候——電商秒殺、新聞熱點、活動開跑。
幫我寫一個 spike test 腳本,
目標是 https://test.k6.io,
模擬流量瞬間暴衝:
– 前 30 秒維持 10 VU(平常流量)
– 接下來 10 秒瞬間衝到 1000 VU
– 維持 1000 VU 跑 1 分鐘
– 再降回 10 VU 跑 30 秒(看系統會不會恢復)
檔名叫 spike-test.js
這四種測試,你不用記語法,只要記得「目的」就好。需要的時候用上面的描述方式叫 Claude Code 寫就好——你的工作是「決定要測什麼」,寫腳本是 AI 的工作。
關鍵技巧:設定 Thresholds(門檻)
Thresholds 是 k6 最有價值的功能之一,中文叫「門檻」或「合格標準」。
它的作用是:你預先設定「什麼條件算過、什麼條件算不過」,測試跑完 k6 會自動判斷。例如:
- p(95) 必須小於 500ms
- 失敗率必須小於 1%
- 總請求數至少 1000 個
為什麼這很重要?因為它讓效能測試可以「自動化」。設定好門檻,測試直接接到 CI/CD pipeline,每次部署自動跑,沒過就擋下不准上線——這就是現代效能測試該長的樣子。
叫 Claude Code 加門檻的方法
如果你已經有一個測試腳本,可以跟 Claude Code 說:
幫我在 load-test.js 裡加上這些 threshold:
1. p(95) 回應時間必須小於 500ms
2. p(99) 回應時間必須小於 1000ms
3. 失敗率必須小於 1%
4. checks 通過率必須超過 95%
加完之後解釋 thresholds 區塊在做什麼。
Threshold 怎麼設才合理?
這沒有標準答案,但有幾個原則:
- 從業務需求出發:先問「使用者能忍受多慢」、「我們承諾過多快」(SLA)。
- 從現況出發:先測一次目前的數字,在這個數字上加一點壓力當門檻。
- 別設太鬆:如果 p(95) 已經 800ms,你設門檻 1000ms,等於沒設。
- 別設太緊:每次跑都 fail,大家就會關掉門檻——這比沒門檻更糟。
Threshold 不是工程師決定的,是「業務、產品、測試」三方一起決定的。這是測試管理層級的決定,不是工具操作的細節。
看不懂的時候,怎麼跟 Claude Code 求助
這節是這篇教學最實用的部分,把它印下來貼在電腦旁邊。
情境 1:看不懂腳本裡的某一行
複製那一行,問:
這行是什麼意思?用中文解釋,假設我完全不會程式:
[貼上你看不懂的那一行]
情境 2:跑測試出現紅字錯誤
複製整段錯誤訊息,問:
我跑 k6 test.js 出現這個錯誤,請告訴我:
1. 這個錯誤是什麼意思
2. 怎麼修正
3. 為什麼會發生
錯誤訊息如下:
[貼上錯誤訊息]
情境 3:結果看起來不對勁
貼上結果,問:
這次測試結果,p(95) 是 2500ms,我覺得太慢了。
請幫我:
1. 確認 2500ms 是不是真的算慢
2. 列出可能的原因(從測試本身、網路、伺服器、資料庫四個方向)
3. 我下一步應該怎麼做才能找出真正的瓶頸
情境 4:想加新功能但不知道怎麼說
用「我想要……,例如……」的句型:
我想要測試的時候模擬「登入後再查詢資料」的流程,
例如使用者先 POST /login 拿到 token,
再帶著 token 去 GET /profile。
請幫我改 first-test.js 來做這件事,
登入用 username=admin, password=test123,
查詢的 endpoint 是 https://test.k6.io/profile
跟 AI 對話的關鍵不是「會用什麼提示詞」,而是「把情境講清楚」。把你心裡那個畫面描述出來,AI 自然就會寫對。
給「不會寫程式」的你三個進階建議
建議一:不要去背 JavaScript 語法
很多人學工具學一半就跑去學語言,結果語言沒學成、工具也沒學會。你的目標是「跑出有用的效能測試」,不是「成為 JavaScript 工程師」。
看得懂 Claude Code 給你的解釋、會描述你要的測試、會看報表——這三件事做到,你的價值就在了。語法的事,讓 AI 處理。
建議二:把每次的學習存下來
建立一個資料夾,把每次跑成功的腳本、每次問 Claude Code 的好問題、每次解讀結果的對話,通通存下來。三個月後你回頭看,會發現你已經累積了一本「自己的 k6 手冊」。
具體做法:每完成一個測試,叫 Claude Code 做這件事——
幫我整理今天學的東西成一個 .md 檔案:
1. 我今天做了什麼測試
2. 用了哪些技巧
3. 遇到什麼問題、怎麼解決
4. 下次要記得什麼
存成 learning-log-YYYYMMDD.md
建議三:把效能測試當成「測試管理」的事,不是「工具操作」的事
這是這篇教學最重要的一個觀念。
業界很多人學完工具就停下來,以為效能測試就是「會跑 k6」。但真正困難、真正有價值的部分,不是工具,而是——
- 決定要測哪些情境(從業務出發,不是隨便找 API 來打)
- 設計貼近真實的負載模型(尖峰時段、使用者行為比例)
- 訂出合理的 threshold(跟業務、SLA 對齊)
- 解讀結果、找出瓶頸(這需要懂系統架構)
- 把測試嵌進開發流程(讓效能持續被檢查,不只是上線前)
這些事情,工具不會幫你做,AI 也不會替你決定——但你身為測試人員,本來就應該會的。
會 k6 的人很多,會「設計效能測試策略」的人很少。AI 工具讓前者的門檻消失了,後者的價值就會被放大。這就是「不會寫程式的測試人員」在 AI 時代的機會。
結語
十年前學效能測試,要先會寫程式、再學工具、再讀文件、再上手——這條路把很多手動測試出身的人擋在門外。
AI 時代,這條路被打通了。你不需要先變成工程師才能做效能測試,你只需要會「描述測試情境」、會「解讀測試結果」、會「跟 AI 對話」——這三件事,測試人員本來就比工程師強。
k6 是入場券,Claude Code 是你的副駕駛。你坐的還是駕駛座——決定要去哪裡、什麼時候出發、什麼時候要轉彎,這些是你的工作。
不會寫程式從來不是測試人員的弱點。在 AI 時代,只是一個「不再重要」的限制而已。
祝你跑出第一個 k6 測試的時候,有種久違的「我也做得到」的興奮感。
發表迴響