一、把輸出當成體檢報告讀

前四天你已經跑過好幾次測試，每次結束都會湧出一整面數字。多數人的直覺是找一個「像重點的數字」看一眼就結案——這就像拿到體檢報告只看體重。效能測試輸出和體檢報告的正確讀法一樣：每個欄位回答不同的問題，有的講功能對不對、有的講速度快不快、有的講這次檢查本身做得夠不夠確實。今天把整份報告逐區讀懂，這是本系列最重要的一篇基本功——之後所有的判讀、報告、溝通，都建立在今天之上。

二、完整輸出導覽：一區一區看

以下是執行 Day 4 的 pizza-api-test.js 後的典型輸出（數字是示意，你的會不同；版面也會隨 k6 版本略有差異，區塊邏輯是一樣的）：

  █ TOTAL RESULTS
 
    checks_succeeded...: 100.00%  290 out of 290
    checks_failed......: 0.00%    0 out of 290
 
    ✓ 狀態碼是 200
    ✓ 回應內容不是空的
 
    HTTP
    http_req_duration..: avg=182ms min=155ms med=170ms max=890ms
                         p(90)=210ms p(95)=261ms
    http_req_failed....: 0.00%   0 out of 145
    http_reqs..........: 145     4.79/s
 
    EXECUTION
    iteration_duration.: avg=1.18s min=1.15s med=1.17s max=1.89s
    iterations.........: 145     4.79/s
    vus................: 5       min=5 max=5
 
    NETWORK
    data_received......: 91 kB   3.0 kB/s
    data_sent..........: 45 kB   1.5 kB/s

逐項的白話翻譯與判讀重點：

其中 http_req_duration 還能拆解成更細的分段——這對之後推測「慢在哪裡」非常有用：

圖 1：一次請求的生命週期——http_req_duration 由 sending、waiting、receiving 組成

給 RD 的補充：waiting 就是俗稱的 TTFB（Time To First Byte），是伺服器端處理時間的近似值。給 QA 的重點：當回應慢的時候，看 waiting 佔比可以初步分辨「伺服器算得慢」和「網路傳得慢」——這一個分辨，就足以讓你的問題回報比多數人專業。

三、平均值會騙人：手搖飲店的排隊課

想像一家手搖飲店，10 位客人：9 位各等 1 分鐘拿到飲料，第 10 位因為訂單被做錯，等了 15 分鐘。

圖 2：平均 2.4 分鐘聽起來不錯——但對第 10 位客人來說，這家店爛透了

平均等待時間是（9×1＋15）÷10＝2.4 分鐘。店長看著「平均 2.4 分」覺得表現不錯——但這個數字描述的客人並不存在：9 個人的實際體驗比它好，1 個人的體驗比它慘烈得多。平均值把所有人攪在一起，結果誰的故事都沒說。

百分位數（percentile）換一種問法：把所有人依等待時間排序，「p(90)」的意思是——90% 的人等得比這個數字快。上面的例子裡 med（中位數，即 p(50)）是 1 分鐘、p(90) 恰好落在邊界上，而排在後面的那位 15 分鐘客人，在 p(99) 或 max 現形。對應到 k6 的輸出：

• med（p50）：一半的請求比它快——「典型體驗」長什麼樣
• p(90)／p(95)：九成／九成五的請求比它快——「多數人的底線」在哪裡
• p(99)：最慢的那 1% 從哪裡開始——長尾的入口
• max：最慘的那一筆——單一數字，可能是離群值，要看前後文

圖 3：同一批數據，不同指標說不同的故事——avg 靠近主群，長尾要靠 p(95) 以上才現形

為什麼業界服務等級目標（SLO）幾乎都用 p95、p99 而非平均？因為每一個慢請求背後都是一位真實使用者，而且流量大的時候，「只有 1%」的絕對數量很驚人——每天一百萬個請求的服務，p(99) 之外就是一萬次糟糕的體驗。平均值是給報表看的，百分位數才是給使用者負責的。

四、動手做：三個練習

練習一：完整判讀一次自己的輸出

跑一次 Day 4 的腳本，拿著第二節的表格逐項對照，並回答三個問題（寫在筆記裡）：

k6 run pizza-api-test.js

• checks 是否 100%？http_req_failed 是否 0%？——功能面先確認
• med 和 avg 誰大？差多少？——avg 明顯大於 med，代表有長尾把平均拉高了
• p(95) 和 max 差距大嗎？——差距大代表 max 可能只是單一離群值，不必恐慌

練習二：把 p(99) 叫出來

k6 預設的統計欄位沒有 p(99)，用參數指定要顯示的統計值：

k6 run --summary-trend-stats "avg,med,p(90),p(95),p(99),max" pizza-api-test.js

跑完後 http_req_duration 那行會多出 p(99)。觀察它落在 p(95) 和 max 之間的哪裡——不過先預告一個之後會正式討論的限制：這次測試只有一百多筆請求，p(99) 等於是「最慢的一兩筆」，參考價值有限。樣本數與百分位的關係，在第六節的注意事項有完整說明。

練習三：請 AI 解讀，然後驗證它

把完整輸出貼給 Claude Code，用這個 prompt——注意最後一個要求，它是今天的重點：

Prompt 1｜要求解讀，並要求標註出處

以下是我的 k6 測試輸出。請告訴我：
1. 這次測試整體健康嗎？
2. 最值得注意的一個數字是什麼？為什麼？
3. 你引用的每一個數字，請標明它出自輸出的哪一行。
（貼上完整輸出）

拿到回答後做一件事：把它引用的每個數字和你的輸出逐一核對——數字存在嗎？數值正確嗎？結論跟著數字走嗎？AI 解讀數據大多數時候是對的，但它偶爾會引用不存在的數字或算錯比例，而要求標註出處讓核對變得容易。這個「要求出處、逐一核對」的習慣，之後寫正式報告時就是你的品質保險。

Prompt 2｜反向練習：問「不能下什麼結論」

根據同一份輸出，請說出三個「不能」從這份數據得出的結論，
並說明為什麼不能。

這個反向問題比正向解讀更能練判讀力。合理的答案包括：不能說系統能撐住更多人（只測了 5 個 VU）、不能說沒有長期問題（只跑了 30 秒）、不能拿去和別的環境比較（條件不同）。知道數據「不能說什麼」，是資深測試人員和新手最明顯的差別。

五、注意事項：判讀時最常踩的坑

給 QA 的一句話：這張表其實就是你熟悉的測試專業換了場景——單一樣本不下結論、環境要受控、結果要可重現、報告要可驗證。判讀效能數據需要的不是統計學位，是你本來就有的測試紀律。

六、觀念驗證：三個問題確認你有帶走今天的重點

• 主管看報告說「平均 180ms，很好啊」——你會補上哪兩個數字讓故事完整？為什麼是這兩個？（第三節）
• 一次 30 秒、一百多筆請求的測試，p(99) 可以拿來當服務等級目標的依據嗎？（第五節）
• AI 解讀說「max 890ms 顯示系統有效能問題」——你會怎麼核對這句話？有哪些其他可能的解釋？（第四節練習三、第五節）

七、小結

今天把 k6 的輸出從頭到尾讀懂了一次：checks 講對不對、duration 講快不快、reqs 講吞吐量，而 duration 還能拆段推測慢在哪。最重要的一課是百分位數——平均值描述的使用者並不存在，med 講典型體驗、p(95) 講多數人的底線、p(99) 之後是長尾裡真實受苦的人。加上「要求 AI 標註出處、逐一核對」與「問數據不能說什麼」兩個練習，你的判讀已經有了紀律的雛形。這份能力會在整個系列反覆使用，也是效能測試裡最不會被 AI 取代的部分。

附錄：本篇指令與判讀速查

# 基本執行
k6 run pizza-api-test.js
 
# 自訂統計欄位，叫出 p(99)
k6 run --summary-trend-stats "avg,med,p(90),p(95),p(99),max" pizza-api-test.js

判讀速查（可影印貼在螢幕旁）：

• 先看 checks 與 http_req_failed：功能與錯誤率——不健康就先別談速度
• 再看 med：典型體驗；avg 明顯大於 med ＝ 有長尾
• 接著 p(95)／p(99)：多數人的底線與長尾入口——樣本要夠才可信
• max 與 p(99) 距離遠且僅零星幾筆 ＝ 可能是離群值，觀察而非恐慌
• http_reqs 每秒值＝吞吐量：容量對話用它，不是用 VU 數