上一篇把 AI SRE 的實際測試先收尾。接下來想換一個場景，看看 AI 能不能在壓力測試上做些什麼事。

我以前看過公司 QA 執行壓測。需求單位提出目標 TPS，QA 準備腳本、執行測試，再到 Grafana 看 CPU、Memory、JVM、GC 等圖表。最後挑出重點畫面、截圖、分析結果，整理成一份壓測報告。

整套流程每天重複發生。測試的 API 和參數會換，QA 做的事情其實都差不多。

所以我想說讓 AI 產生壓測腳本，應該可以省下不少時間吧？

QA 訪談

現在的 AI 很擅長參考既有範例產生程式碼，壓測腳本裡也有許多重複結構。只要提供 API、request body、Virtual Users（VUs，k6 用來模擬同時操作系統的虛擬使用者）、測試時間與目標 TPS，看起來很適合交給 AI 處理。

跟 QA 團隊聊過後，我才發現寫腳本沒有想像中花時間。

很多需求都有現成腳本可以修改。換掉 API、測試資料與幾個參數，再確認請求能正常執行，大致上就準備好了。多數情況是既有服務修改程式後重新壓測，只要測試需求沒有改變，原本的腳本就能繼續使用。

真正花時間的是壓測結束後的整理工作。QA 要先記錄實際測試時間，再到 Grafana 切換到相同區間，逐張查看 TPS、response time、error rate、CPU、Memory、JVM heap、GC、thread pool 與 connection pool。

看到重點要截圖，遇到異常還要來回切換不同 panel，確認這些現象是否在同一段時間發生。圖表看完後，還要把零散的觀察整理成報告，整個過程需要投入不少時間和人力。

所以我就想到，壓測跑完後，AI 能不能先把結果分析一輪，再產生報告？

壓測跑完後，如何分析

一場壓測結束後，QA 會先看 k6 的執行結果，確認實際產生多少 TPS，有沒有達到目標，以及 response time 與 error rate 是否符合需求。

接著才輪到 Grafana。CPU 有沒有持續上升？Memory 在測試結束後有沒有降回來？GC 是否突然變得頻繁？thread pool 或 connection pool 有沒有接近上限？

單看一張圖通常不夠。TPS 上不去時，CPU 可能已經很高，也可能還有餘裕。response time 突然上升時，可能剛好伴隨 GC，也可能是 connection pool 已經用滿。各項指標的時間沒有對齊，很容易把兩個無關的現象連在一起。

把每個 panel 看完，只能知道個別指標發生了什麼。要進一步分析，還得繼續追幾個問題：

• TPS 停止成長時，最早出現變化的是哪個指標？
• response time 是慢慢上升，還是在某個時間突然跳高？
• 短暫尖峰有沒有被平均值蓋掉？
• GC、thread pool、connection pool 與 error rate 是否在同一段時間惡化？
• 壓測停止後，服務花了多久才恢復？
• 目前的 metrics 足以解釋問題嗎？還缺少哪些資料？

把這些問題逐一檢查後，報告才能回答需求單位最關心的事情：目標 TPS 有沒有達標？測試期間發生了什麼？沒有達標時，瓶頸可能在哪裡？

常見的建議包括調高 Pod 的 CPU 或 Memory、增加 Pod 數量，或調整 HPA 的最大副本數。這些建議很容易寫，問題是現有證據真的有指向資源不足嗎？還是大家看到 TPS 上不去，就先增加資源再說？

壓測報告很容易流於固定格式。放上幾張 Grafana 截圖、標出最高值，再寫一段結論，表面上該有的內容都有了。老實說，如果最後只剩下「資源往上爬、測試結束有降回來、TPS 有達標」這幾句話，前面截那麼多圖好像也有點心酸。

QA 當然知道還有很多問題值得追。現實是報告還沒寫完，下一張需求單大概已經在旁邊等了。有限的人力一直花在找圖、截圖與整理數值，自然很難再往下分析。

整理資料、比對時間與產生報告，才是我希望 AI 接手的工作。

想像中 AI 加入後的流程

QA 在執行前設定測試目的、目標 TPS 與驗收門檻。壓測啟動後，系統會自動記錄實際開始與結束時間，並收集 k6 的執行結果，不需要 QA 再手動整理資料。

壓測停止後，系統會繼續收集一段預先設定的恢復期資料。等觀察時間結束，再查詢完整測試區間的 metrics，整理負載開始前、壓測期間與恢復期的吞吐量、延遲、錯誤與資源變化。哪個指標出現尖峰、什麼時間開始惡化、測試停止後有沒有恢復，都先整理成數值和圖表。

程式先根據驗收門檻計算結果，AI 再讀取這些證據並整理成報告，說明測試條件、驗收結果、觀察到的異常、可能有關聯的指標，以及下一步值得確認的方向。

報告會把相同時間區間的相關圖表放在一起，讓 QA 看得出每項判斷是根據哪些證據得來。

現有 metrics 看不出原因時，報告就要寫清楚目前確認了什麼、還有哪些事情無法判斷，以及下一步該查什麼。AI 猜得再像，也不能直接當成測試結論。

QA 拿到報告後，可以檢查圖表、數值與結論。判斷合理就採用，證據不夠就補查，測試條件有問題就重新執行。這樣 QA 的時間可以放在判讀與決策，少一點複製貼上和手動截圖。

結論

現在需求已經釐清，QA 啟動一場已經設定好驗收條件的壓測，系統接著自動記錄、分析，最後輸出一份有數值、有圖表、能回頭複查的報告。

接下來要把測試條件、驗收門檻、k6 執行結果與 metrics 串接起來，也要決定哪些資料交給 AI 解讀，以及報告該如何呈現重點。這些內容留到下一篇再討論。

今天就先寫到這，我們明天見！