一、一個在很多公司真實上演過的情境

以下是一個組合過的典型情境——細節來自許多團隊的共同經驗，你可以把它當成「新人第一次壓測」的標準劇本。
小任剛學會效能測試，想看看公司訂單服務的極限在哪。staging 環境反正是測試用的，他直接開了 200 個 VU 往上打。十分鐘後，隔壁團隊的自動化測試整批轉紅；再過十分鐘，業務部門在客戶面前的系統展示卡成一張張載入中的圖示。沒有人知道發生了什麼——大家從「是不是誰改壞了什麼」開始查，查了半天才發現是一支沒人知道的壓測腳本。

最冤枉的是：小任壓的是訂單服務，掛掉的卻是會員服務和展示系統。因為它們共用同一顆資料庫。

圖 1：一次壓測的爆炸半徑——共用資料庫、快取與網路是隱形的連結，受害者常在你的視線之外

這個情境裡小任犯的錯，沒有一個和技術有關：他有授權嗎？算有——staging 本來就是拿來測的。他錯在沒告知、沒挑時間、不知道爆炸半徑、也沒有止血計畫。效能測試的職場風險，九成來自流程與溝通，只有一成來自技術。這就是為什麼本篇排在所有進階技術之前。

二、先認清：你手上的工具本質上是什麼

k6 這類工具的本質是「自動化的大量請求產生器」。對自己的系統、在受控條件下使用，它是測試工具；對別人的系統、未經授權使用，它的行為和阻斷服務攻擊（DoS）沒有兩樣——目標系統分不出你是在「測試」還是在「攻擊」，它只感受到大量湧入的請求。

Day 1 提過，未經授權對他人系統發送大量請求，在多數國家與台灣都可能觸犯與妨害電腦使用相關的法律。本篇不做法律分析，只給一條永遠安全的底線：授權是唯一的分界線。系統是你的、或擁有者明確允許你測——才可以按下執行。「應該沒關係吧」「只是測一下」都不是授權。

圖 2：目標系統紅綠燈——綠燈放心練、黃燈走清單、紅燈未經同意絕不可

特別說明兩個紅燈。第三方服務（例如你們串接的金流、簡訊、地圖 API）：它們是別人的系統，壓測前需要供應商同意，有些供應商提供專門的測試環境或沙盒，先問再動。正式環境：受控的生產環境測試在業界確實存在，但那需要完整的配套（限流、監控、回滾、跨團隊決策），屬於進階實務——在你能獨立完成本系列所有內容之前，請先不要單獨嘗試。

三、壓測前五問：三十秒的檢查清單

圖 3：壓測前五問——任何一題答不出「是」，就先停下來補齊

五問的細節，以公司測試環境為例：

• 問 1 授權：這個環境允許效能測試嗎？不確定就問環境的管理者。「staging 本來就是測試用的」不等於「隨時可以壓」——它是大家共用的測試環境，不是你專屬的壓測場
• 問 2 環境：把腳本裡的目標網址唸出來確認一次。最慘烈的事故都是「以為在壓 staging，其實貼成了 production 的網址」——一個字母的差距
• 問 3 告知：在團隊頻道發一則訊息（第四節會生成範本），對象包含共用這個環境的其他團隊、環境管理者，以及值班或負責告警的人**——告警系統不會知道這是演習
• 問 4 時間：避開**別人排定的測試、客戶展示、上版時段。問一句「今天下午三點到三點半我壓 staging 可以嗎」花十秒，事故檢討會要開一小時
• 問 5 止血：知道怎麼立刻停止（下一節演練）、停止後去哪確認系統恢復、恢復不了要找誰。沒有止血計畫的測試，就像沒有煞車的試駕

本系列自己也要過這個清單。對 QuickPizza 的練習：問 1，官方公開提供、明確歡迎練習，授權成立；問 2，網址就是練習站；問 3，不需要逐一告知，但要遵守它的公共規矩——小流量；問 4，任何時間皆可；問 5，Ctrl+C 隨時可停。五問全過，所以我們每天都能安心練——規矩不是拿來限制練習的，是讓練習可以一直安心進行的。

四、動手做：演練與資產

演練一：緊急停止的肌肉記憶

止血能力要真的練過才算數。啟動一個 60 秒的測試：

k6 run --vus 5 --duration 60s first-test.js

跑到一半時按下 Ctrl+C。注意 k6 的兩段式行為：按第一次是「溫和停止」——不再開始新的一輪，等正在進行中的請求收尾，然後照樣印出到目前為止的統計；如果情況緊急，再按一次 Ctrl+C 會立刻強制中斷。兩種都試一次，然後做完整的止血流程：打開瀏覽器確認 QuickPizza 仍然正常。「停止之後確認系統恢復」這半步，是多數人漏掉的——中斷測試不等於解除影響，親眼確認才算結案。

演練二：生成你的「壓測告知」範本

告知訊息每次手寫既花時間又容易漏項目，把它變成可重複使用的範本。啟動 claude，用這個 prompt：
Prompt 1｜生成告知訊息範本

請幫我建立一個檔案 announce-template.md，內容是「效能測試告知訊息」範本，
用於發到團隊頻道。範本要包含以下欄位，每個欄位附一行範例：
執行者與聯絡方式、目標系統與環境網址、時間窗口、
預計流量（VU 數與大約每秒請求數）、可能的影響範圍、
是否已知會告警值班人員、緊急停止方式與預計恢復時間、
資料影響（唯讀，或會建立測試資料與測後清理方式）。
請用繁體中文，格式簡潔，適合直接貼到聊天頻道。

生成後打開看一遍，依你們公司的習慣調整措辭。這是今天第一個可以直接帶去公司的資產——下次要壓測，開檔案、填空、貼出去，三分鐘完成專業的告知。

演練三：讓 AI 當你的禮儀檢查員

五問裡有幾題可以讓 Claude Code 幫你把關。試試對任何一支腳本做「起飛前檢查」：
Prompt 2｜腳本的禮儀檢查

請檢查 pizza-api-test.js，回答以下問題，不要修改檔案：
1. 目標網址是什麼？看起來像正式環境還是測試環境？
2. 有沒有 sleep？拿掉它會發生什麼事？
3. VU 數與時長是多少？對一個公開練習站來說合理嗎？
4. 有沒有任何寫死在腳本裡、看起來像機密的資訊？

它會給出一份檢查回報。但請記住定位：AI 可以幫你檢查腳本，回答問 2 的一部分；授權、告知、時間窗口這些人與人之間的事，工具幫不了——五問裡有四問的答案在對話裡，不在程式碼裡。

五、常見情境速查

六、注意事項：容易被忽略的邊角

給 RD 的一句話：五問裡 QA 最難自己回答的是「這個服務跟誰共用資料庫」——這張架構的地圖在你腦中。主動畫出來、貼在團隊看得到的地方，是工程端對壓測安全最實質的貢獻；順便也保護了你自己的服務不被別人的測試誤傷。

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

• 小任的故事裡，他其實「有授權」——那他錯在哪？五問裡他漏了哪幾問？（第一、三節）
• 同事說「我壓的是訂單服務，會員服務變慢關我什麼事」——你會用哪張圖、哪個概念回應他？（第一節、第六節）
• 為什麼「按 Ctrl+C 停止測試」不算完成止血？完整的止血還差哪半步？（第四節演練一）

八、小結

今天沒有新的技術，卻可能是整個系列最保值的一篇：效能測試的職場風險九成來自流程與溝通。帶走四樣東西——授權是唯一的分界線；壓測前五問（授權、環境、告知、時間、止血），三十秒走完；緊急停止的兩段式肌肉記憶，以及「停止後確認恢復」那半步；還有兩個直接可用的資產：告知訊息範本與腳本禮儀檢查 prompt。從明天起，每一次按下執行之前，五問先走一遍——讓它變成呼吸一樣自然的動作。

附錄：壓測前五問（影印版）與告知訊息欄位

壓測前五問：

• 授權——這個系統是我的，或擁有者明確允許我測試？
• 環境——目標網址唸過一遍，確認是測試環境？
• 告知——共用環境的團隊、環境管理者、告警值班的人都知道了？
• 時間——避開了別人的測試、展示與上版時段？
• 止血——知道怎麼立刻停止、去哪確認恢復、恢復不了找誰？

告知訊息應包含的欄位（完整範本請用第四節的 prompt 生成）：

【效能測試告知】
執行者與聯絡方式:
目標系統與環境網址:
時間窗口:
預計流量(VU 數/約每秒請求數):
可能的影響範圍:
已知會告警值班:是/否
緊急停止方式與預計恢復時間:
資料影響(唯讀/會寫入,清理方式):