一、一張單子的兩種命運

Day 21 的報告寄出去了，主管看完 30 秒，說了一句「那請 RD 處理一下」。接下來的事情你很熟：開一張單。同一個發現，兩種開法——

第一種：標題「送出評分 API 很慢」，內文「壓測的時候 p95 超過門檻，請查一下」。附上一張終端截圖。

第二種：標題「POST /api/ratings 在 30 VU 以上 p95 由 610ms 升至 920ms（門檻 800ms），改版前同條件 650ms」，內文附腳本版本、執行指令、前後兩輪的分桶數據、施壓機 CPU 峰值 38%、可信度四問結果，以及一句「此端點為評分流程主路徑，尖峰時段影響約三成使用者」。

第一種單子的命運，多半是被貼上「需要更多資訊」，或者被回一句「我們這邊跑很快」；第二種單子，RD 打開就能重現、能看到差異、知道為什麼該排進這個 sprint。兩張單的差別不在文筆，在證據——而證據，前面二十一天你已經全部準備好了，今天只是把它們裝進同一張單裡。

圖 1：效能缺陷單的四個要素——每一項都對應前面某一天的基本功

二、四個要素，各對應一天的基本功

要素一：可重現的腳本與指令。功能缺陷單寫「重現步驟」，效能缺陷單的重現步驟就是腳本加指令：哪個檔案、哪個 git 版本、幾個 VU、什麼 stages、對哪個環境、帶什麼環境變數（Day 14 整理過的那一套，這時候會感謝自己）。判斷標準只有一個：RD 在自己機器上照著貼，十分鐘內能跑出同一條曲線。做不到，這張單就是「聽說很慢」。

要素二：前後數據對比。單獨一個「p95 920ms」沒有意義，RD 第一個問題一定是「那之前呢？」。Day 17 教過環境有落差時只做相對比較，這裡就是它派上用場的地方：改版前後、同環境同腳本同資料同時段（四同），兩輪數據並排。有 Day 20 的 HTML 報告就附連結；沒有，至少把分桶後的 p50/p95/錯誤率並排成表。差異要說到端點層級——「整體慢了 40%」會被追問，「/api/ratings 慢了 40%、其他端點持平」才是可以動手查的線索。

要素三：業務影響描述。這是 QA 最常漏、卻最決定優先序的一段。RD 的待辦永遠比時間多，一張單能不能排進這個 sprint，取決於「不修會怎樣」有沒有被說清楚。Day 21 你已經做過業務影響權重的判斷，把它翻成一兩句話：這條路徑碰到什麼（下單、結帳、登入）、尖峰時段影響多少比例的使用者、是變慢還是會失敗。避免形容詞，用可以被驗證的描述。

要素四：排除施壓端的證據。這是效能缺陷單獨有的一段，功能測試沒有這個問題。Day 19 說過，RD 收到效能問題的第一反應常常是「是不是你那邊的問題」——這個懷疑是合理的，因為新手真的常常測到自己。所以先把自己排除掉：施壓機 CPU 峰值、http_req_blocked 是否肥大、連線是否重用、快取指紋、可信度四問的結果，全寫進單裡。你主動把自己排除，RD 就不用花時間懷疑你；這一段的存在本身就是專業的訊號。

四個要素整理成檢查表，開單前逐項打勾：

三、把發現變成單子：讓 Claude Code 當你的檢查員

報告的發現段已經有數據、有曲線描述、有業務排序，離一張好單子只差一次「重新裝箱」。這件事適合交給 Claude Code，而且要它順便當檢查員——哪個要素還空著，它比你更不會客氣：

Prompt 1｜報告發現轉缺陷單

請讀取 perf-report.md，把「主要發現」第 1 條轉成一張效能缺陷單，
格式依附錄的 perf-issue-template.md。
四個要素逐項填寫：重現腳本與指令、前後數據對比（到端點）、
業務影響、排除施壓端的證據。
規則：
1. 資料只能來自報告與 raw.json，不可以補造數字
2. 每個要素若報告裡證據不足，不要硬寫，改為在該欄位標示
   「⚠ 缺少：」並具體說我還需要補什麼、怎麼取得
3. 標題格式固定：{端點} 在 {負載條件} 下 {指標} 由 {前} 變為 {後}（門檻 {值}）
4. 最後給我一段「RD 可能的反問」，列三個他打開這張單最可能問的問題

第 2 條規則和 Day 21 的〔推論〕標註是同一個精神：讓 AI 標出缺口，而不是用文筆把缺口蓋過去。通常第一次跑會看到一兩個「⚠ 缺少」——最常見的是要素四，因為很多人跑測試時沒順手記下施壓機的資源狀態。那就回去補跑一輪，把數字記全，再開單。單子開出去之前補證據，比開出去之後被退回來補，便宜十倍。

第 4 條「RD 可能的反問」是 Day 21 練習二的延伸——先在終端被問倒，不要在會議室被問倒。下一節談那三句最常被問到的話。

四、三句最常聽到的回應，怎麼接

單子開得再好，也會遇到回應。這三句你幾乎一定會聽到，重點不是吵贏，是每一句都把對話拉回證據：

「你環境不對。」這句話往往是對的——測試環境確實只有正式環境一半，Day 17 就講過。所以不要辯護環境，直接同意，然後把焦點換掉：「對，所以我只做相對比較——同一個環境、同腳本、同資料，改版前 650ms、改版後 920ms。環境沒變，變的是程式。」相對比較的價值在這一刻兌現：環境的絕對規格不重要，前後的差異才是問題所在。如果對方進一步說「測試環境的差異放大了問題」，那正是可以一起做的事——請他協助在更接近正式的環境重跑一次，這是合作，不是對立。

「這是特例。」意思通常是：那個變慢的情境很少發生。回應方式是回到業務影響描述：「這條路徑是評分流程主路徑，尖峰時段大約三成使用者會經過；如果真的是特例，我們一起看一下流量資料。」注意最後半句——如果你在 Day 16 就拿不到流量資料，這裡反而是要求它的好時機，因為現在有人需要它來證明「特例」。特例與否是一個可以量的問題，不是一個立場問題。

「正式環境沒人抱怨。」這句最難接，因為它有一半是真的：使用者遇到慢，多數不會抱怨，會直接離開。回應的關鍵是把「沒抱怨」和「沒問題」分開：「這個版本還沒上線，改版後才會慢；而且變慢的是送出評分，使用者不會抱怨，會直接不送。」然後給一個可以驗證的方案：「上線後可以看這個端點的 p95 和送出率，如果我錯了，數據會告訴我們。」願意被數據推翻，是 QA 在這場對話裡最強的姿態。

三句的共同結構其實一樣：先同意對方裡面正確的部分，再把對話拉回四要素裡對應的那一項。整理成表，下次開會前掃一眼：

最後一列值得多說一句：RD 在自己機器上用 Postman 打一次很快，和 30 個 VU 同時打五分鐘，是兩件事——Day 1 那條曲線的意思就是「快不快取決於幾個人同時在用」。這時候要素一的重現指令就是你的全部：請他照著跑，不用爭論。

五、左移之後：你不再是守門員，是量尺

前面談的是「上線前發現問題、開單、爭取修」的情境，這是效能測試的傳統位置：守門員，站在上線的門口。但只要團隊開始固定跑效能測試（Day 23 之後進 CI 就是這樣），你的位置會慢慢改變：不是在門口攔，而是在每一次迭代裡量。

圖 2：從守門員到量尺——效能測試左移後，發現問題的時間點與成本

差別有三個。第一，時間點：守門員在功能全部做完才測，發現問題時修改成本最高、還常常被要求「先上線再說」；量尺在每個 sprint、甚至每次合併就測一次，變慢的那一次改動當場浮現，範圍小、責任清楚、修起來便宜。第二，關係：守門員與 RD 天然對立——你攔的是他的成果；量尺與 RD 是同一邊的——你給他的是「這次改動讓 /api/ratings 慢了 15%」這種即時回饋，就像單元測試紅了一樣，是資訊不是指控。第三，單子的樣子：守門員時期的單子要靠四要素撐住說服力；量尺時期，前後對比是自動產生的，腳本本來就在 repo 裡，開單這件事變得非常輕。

這也回答了一個常見的焦慮：「效能測試自動化之後，測試人員還要做什麼？」看一下四要素——腳本可以自動跑、數據可以自動比、施壓端狀態可以自動記，唯獨業務影響描述，以及面對「這是特例」時知道要去哪裡拿流量資料來回答，這兩件事不會自動發生。它們正是 Day 21 說的「必須由人來下的判斷」，左移之後不會消失，只會更頻繁地被需要。

六、動手做：開一張站得住的單

練習一：把 Day 21 的第一條發現開成單。用 Prompt 1 產出缺陷單，看看有幾個「⚠ 缺少」。若要素四是空的（多半是），回頭用 Day 19 的做法補跑一輪：施壓中記下自己機器的 CPU、跑完看 http_req_blocked 的 p95、檢查回應 header 的快取指紋。把數字填回單裡。

練習二：角色互換。把單子貼給 Claude Code，請它扮演一位手上有二十張單、下週要交功能的 RD，用「你環境不對」「這是特例」「我這邊跑很快」三句話依序回應，你逐句用第四節的方式接。接不下去的地方，就是單子還缺證據的地方。

練習三：改成量尺版本。假設這條測試下週開始每次合併都跑（Day 23 會真的做到），把同一張單改寫成「自動化回饋」的口吻：拿掉說服的部分，只留下改動前後的數字與端點。比較兩個版本的長度——你會看到左移省掉的是什麼。

七、注意事項：開單與協作的六個習慣

給 RD 的一句話：收到一張帶四要素的效能單，請先照要素一的指令跑一次，再回話。它已經替你排除了施壓端、給了前後對比、說明了業務影響——這是一張花了心思、也願意被推翻的單。「你環境不對」在它面前不是反駁，是邀請：一起換個環境再跑一次。

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

• 效能缺陷單比功能缺陷單多出的那個要素是什麼？為什麼它的存在本身就是專業的訊號？（第二節）
• 面對「你環境不對」，為什麼正確的做法是先同意？你接下來要把對話拉回哪個要素？（第四節）
• 效能測試左移後，四要素裡哪些會自動化、哪些不會？這對測試人員的角色意味著什麼？（第五節）

九、小結

從報告到單子，差的是一次重新裝箱：可重現的腳本、前後對比、業務影響、排除施壓端——四個要素各對應前面某一天的功課，今天只是把它們裝進同一張單。那三句最常聽到的回應，每一句都有正確的部分，先同意它，再把對話拉回對應的要素；願意被數據推翻，是這場對話裡最強的姿態。而當效能測試開始固定地跑，你的位置會從門口的守門員變成迭代裡的量尺——單子變輕、關係變近，但業務影響的判斷永遠在你手上。讓測試「固定地跑」這件事本身，明天就來做：用 GitHub Actions 讓 smoke test 在部署後自動把關，本機不用裝任何東西——Day 23 見。

附錄：效能缺陷單範本（perf-issue-template.md）

# {端點} 在 {負載條件} 下 {指標} 由 {前} 變為 {後}（門檻 {值}）
## 影響（給排優先序的人看）
- 路徑：{此端點屬於哪個使用者流程；碰到下單／結帳／登入？}
- 範圍：{尖峰時段約 N% 使用者經過此路徑}
- 表現：{變慢 / 逾時 / 錯誤率上升}，使用者端的感受：{...}
## 前後對比（同環境、同腳本、同資料、同時段）
| 版本 | p50 | p95 | 錯誤率 | rps |
| 改版前 {版本/日期} | ... | ... | ... | ... |
| 改版後 {版本/日期} | ... | ... | ... | ... |
- 其他端點：{持平 / 一併變慢}（附 HTML 報告連結）
- 曲線描述：第 {N} 分鐘 {M} VU 起 {爬升 / 尖刺 / 走平}
## 重現方式
- 腳本：{檔名} @ {git commit}
- 指令：{完整指令，含環境變數，機密以 ${...} 表示}
- 資料：{參數化 CSV / 測試帳號前綴 / 清理方式}
- 環境：{名稱與規格；與正式環境差距}
## 已排除施壓端問題
- 施壓機 CPU 峰值 {N}%、open files 未觸頂
- http_req_blocked p95 {N}ms（連線重用正常）
- 快取指紋：{回應 header 摘要；含 / 不含快取}
- 可信度四問：{全過 / 例外說明}（Day 19）
## 關閉條件
- {修正後同條件重測 p95 < 門檻} 或 {上線後觀察 p95 與送出率 N 天無異常}
## 附件
- report.html、summary.json、raw.json 位置