一、數字沒錯，但沒人看得懂

Day 19 之後，你的證據乾淨了，推理也有模有樣。你把終端輸出截圖貼進郵件寄給主管，十分鐘後收到回信：「所以……是好還是不好？」

別怪主管。那滿螢幕的等寬字體、縮寫指標和百分位數，對非技術人就是天書——而溝通的責任在說的人身上。下半場的主軸從「會做」走到「會說」，第一步就是把數字變成圖。好消息是 k6 把這件事做到了零安裝：不用架 Grafana、不用裝資料庫，內建的 Web Dashboard 一個環境變數就打開。先把全貌看清楚——同一輪測試，其實可以同時產出三份輸出，各自服務不同的讀者：

圖 1：同一輪測試、三份輸出——終端給自己、圖表給人、JSON 給 AI

終端 summary 你從 Day 3 就在讀，它是給自己的 30 秒紅綠燈；今天打開的是後兩份：給人看的圖表，和給機器讀的原始數據。

二、一個環境變數，圖表就出來

k6 的 Web Dashboard 是內建功能，開關是環境變數 K6_WEB_DASHBOARD；再加一個 K6_WEB_DASHBOARD_EXPORT，測試結束時自動把整個儀表板存成單一 HTML 檔：

# macOS / Linux
K6_WEB_DASHBOARD=true K6_WEB_DASHBOARD_EXPORT=report.html k6 run journey.js

# Windows PowerShell
$env:K6_WEB_DASHBOARD="true"; $env:K6_WEB_DASHBOARD_EXPORT="report.html"
k6 run journey.js

# 測試一啟動, 終端會多印一行:
# web dashboard: http://127.0.0.1:5665
# 用瀏覽器打開它, 圖表跟著測試即時更新

照系列的老規矩，指令不用背——跟 Claude Code 說「幫我用開啟 web dashboard 並輸出 HTML 報告的方式跑 journey.js」，它會依你的作業系統給出正確寫法。值得體會的是兩件事：第一，邊跑邊看——瀏覽器裡 VU 數、rps、回應時間、錯誤率的曲線即時前進，異常發生在第幾分鐘當場看到，不用等跑完再回頭猜；第二，那個 report.html 是單一檔案——寄給主管、丟進群組，對方雙擊就開，不需要安裝任何東西。它就是 Day 21 那份「給主管的報告」的圖表底稿。

第三份輸出留給機器：--out json=raw.json 會把每一個數據點寫進檔案——每個請求的每個分段、每個時刻的 VU 數，鉅細靡遺。它和 Day 17 用過的 --summary-export 是兩回事：後者只存「整場的總結」（十幾行），前者存「整場的過程」（時間序列）。過程數據就是 Day 21 讓 Claude Code 施展分析的原料，今天先學會把它留下來。

三、看圖說話：時間軸會說 summary 不會說的故事

為什麼有了 summary 還需要曲線？因為summary 是一個數字，時間軸是一條線——把整場測試壓縮成一個數字的過程，必然有故事被壓掉。看一組會讓人出冷汗的例子：兩輪測試的 summary 一模一樣，p95 都是 800ms、都壓線通過 Day 16 的門檻——

圖 2：summary 一模一樣的兩輪測試——時間軸還原出完全不同的兩個故事

測試 A 全程平穩，是真的撐得住；測試 B 從 400ms 一路爬到 1600ms，它不是「表現普通」，是「正在惡化」——多跑半小時大概就破千五了，只是測試先結束、平均把它救了回來。持續爬升是資源洩漏的經典嫌疑（記憶體、連線、檔案握把慢慢漏），Day 24 的 soak 測試就是專門讓這種問題無所遁形的。summary 看不出 A 和 B 的差別，時間軸一眼。

看趨勢圖不需要藝術天分，常見的形狀就這幾種，各自對應一個故事：

注意其中兩個老朋友：飽和點，Day 18 你是用數字推出來的，現在 rps 曲線走平的位置圖上直接可見；週期性尖刺則是全新的收穫——它只存在於時間軸上，任何統計數字都抓不到它，因為幾個尖刺攤進整場平均連水花都沒有。這正是圖表無可取代的地方。

四、動手做：跑一輪，看三份輸出

練習一：開著儀表板跑一輪。用 Day 13 的 journey 腳本（或任何有 stages 的腳本）跑一輪五分鐘的測試，全程開著瀏覽器看：

Prompt 1｜開儀表板跑測試

請依我的作業系統，給我開啟 k6 Web Dashboard 並同時輸出
HTML 報告（report.html）與原始數據（--out json=raw.json）的完整指令，
腳本用 journey.js，負載改成 5 分鐘的三段 stages（爬升-平穩-下降）。
執行期間我會在瀏覽器觀察，請提醒我 dashboard 的網址，
並告訴我五分鐘裡值得盯著看的三件事。

邊跑邊回答三個問題：rps 在第幾分鐘穩定下來？p95 曲線是水平、爬升還是有尖刺？錯誤率有沒有在某個時間點起跳？——這三個問題的答案，就是你這輪測試判讀的骨架。

練習二：用主管的眼睛審 HTML 報告。測試結束後打開 report.html，先自己看一遍，然後做一個殘酷的練習：假裝你是完全不懂技術的主管，限時 30 秒，你能回答「這次測試是好是壞」嗎？大概率不能——圖表呈現了事實，但沒有人告訴你結論。這個 30 秒的挫折感请記住，它就是 Day 21 存在的理由：圖表之上還缺一層文字解讀。接著請 Claude Code 幫你選材：「打開 report.html，如果只能截三張圖給主管，你選哪三張？各配一句話說明。」

練習三：掀開 raw.json 的蓋子。最後看看給機器的那份輸出裡到底有什麼：
Prompt 2｜原始數據初體驗

請讀取 raw.json，先告訴我：檔案多大？總共幾個數據點？
然後把 http_req_duration 依每 30 秒分桶，各桶算出 p95，
輸出一張文字趨勢表，並和我在 dashboard 看到的曲線互相印證。
最後回答：這份檔案裡有哪些資訊是終端 summary 完全沒有的？

先有心理準備：五分鐘的測試，raw.json 可能就有幾十 MB——它記的是每一個請求的完整履歷。所以兩個提醒：長時間測試注意磁碟空間；這種檔案不要 commit 進版控（Day 14 的 .gitignore 名單再添一員），要留就留 summary 與 HTML 報告。

五、注意事項：把圖表用對的六個習慣

給 RD 的一句話：當 QA 寄來的不再是終端截圖，而是一份 HTML 報告，請花三十秒看兩條線：p95 有沒有爬、錯誤率何時起跳。然後你一句「第 6 分鐘那個尖刺是我們的排程在跑」，能省他一下午的猜測——時間軸的最大價值，是你們兩個第一次能指著同一個東西說話。

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

• 三份輸出——終端 summary、HTML 報告、raw.json——各自的讀者是誰？各回答什麼問題？（第一、二節）
• 兩輪測試 p95 都是 800ms，一輪全程平穩、一輪從 400 爬到 1600——哪一輪更危險？為什麼 summary 看不出差別？（第三節）
• 週期性尖刺為什麼「只存在於時間軸上」？發現它之後，你該帶著什麼資訊去問 RD？（第三節）

七、小結

零安裝的視覺化到手了：一個環境變數開儀表板、再一個變數出 HTML 報告、--out json 留下原始數據——同一輪測試，三份輸出，各自服務終端前的你、會議室裡的人、和 Day 21 登場的 AI 分析師。看圖說話的心法只有一句：summary 是一個數字，時間軸是一條線，被平均壓掉的故事要靠曲線還原——爬升的線、週期的刺、走平的 rps，每個形狀都是一句話。但練習二那個 30 秒的挫折也很誠實：圖表自己不會下結論。把曲線變成主管看得懂的「結論、原因、建議」，讓 Claude Code 當你的分析師——Day 21 見。

附錄：那條叫 Grafana 的路（本系列不走，但你該知道它在哪）

搜尋 k6 視覺化，你很快會撞到 k6 + Grafana（搭配 InfluxDB 或 Prometheus）的組合：把 --out 指向一個時序資料庫，再用 Grafana 畫儀表板。它適合的場景很明確——測試已經固定週期在跑（例如 Day 23 之後進了 CI）、團隊要一面長期的歷史趨勢牆、或要和既有的監控系統擺在同一個螢幕上。代價同樣明確：多架多管兩三個服務，對「不會寫程式」的起點來說是一座不必先爬的山。本系列的立場：單次測試的判讀與交付，內建 Dashboard 完全夠用；等你真的需要那面歷史趨勢牆的那一天，再回來走這條路——到時候，一樣可以請 Claude Code 幫你把它架起來。