test-report-docxlisted

# 測試報告 DOCX 輸出模式 > 交付物本身是「一份給 PM／客戶的測試報告檔案（DOCX）」時走這裡。 > **哲學與 deliver-report skill 一致：不套固定格式，先做決定、再從構件庫按需組裝，形狀自己長出來。** > 定位：修復／功能上線前，把「改了什麼、怎麼證明它對、上線要注意什麼」寫成 PM 能直接轉發簽核的文件。 > **前提：測試已做完、證據在手**——本模式只文件化既有結果；證據還沒產生就先去做測試，不要憑描述寫報告。 > **證據以實際畫面為主（2026-08-19 使用者裁定）**：功能有畫面入口時，一切文件產出的證據必須經由**實際畫面操作**產生，不得以 API 直打等方式繞過畫面取證——繞過畫面產生的證據可能測到使用者根本走不到的���徑（實例：證書提醒信曾以 API 對「未填日期」料號直寄取證，但畫面按鈕的顯示條件根本擋掉這種料號，該證據呈現了一條 UI 上不存在的流程）。唯一例外＝本來就無畫面的機制（排程寄信、webhook 等背景作業）。**證據合法性逐張判、不按產生批次連坐**：同批取得的證據中，「呈現了 UI 不存在流程」的才排除；內容與觸發路徑無關的成品（如信件實寄畫面——範本相同）仍可用，圖說如實註記來源即可（2026-08-19 實例：誤將整批信箱截圖連坐撤除，使用者糾正後逐張回收合法者）。 ## 鐵則（不分形狀全適用） 1. **禁字清單（出現即重寫）**：自動化測試、固化、迴歸測試清單、codify、紅藍對抗、紅隊、QA、code review、reviewer、pipeline、agent、AI、skill、plugin、session、commit（雜湊）、e2e／pytest 等 runner 名。 替代寫法：「自動化測試」→「測試案例」或直接刪；「已固化為可重複執行的自動化測試」→ 整句刪。 2. **meta 句不寫**：「以上情境均已納入測試案例清單，後續版本可重複執行驗證」這類「我們流程做得很好」的自述句一律刪——報告只講交付物與證據，不講我方怎麼管理測試。 3. **預設讀者是 PM／客戶**（不懂技術）：正文全白話；技術詞只出現在「必須精確」的地方（欄位名、參數名）且緊跟白話解釋。 4. **實機截圖是主證據，流程圖不放**（使用者明確裁決過：「重點不是流程���，我要實際系統的操作截圖」）。 5. **誠實邊界與缺陷不進報告本體，改走交付揭露**（2026-08-18 使用者裁定，取代舊制「誠實邊界必寫進報告」）：報告只呈現已驗證通過的最終狀態。測試發現的缺陷應**修復並重驗後再交付**，不寫「已知問題」章；未能驗證的情境、驗證層級缺口（如以模擬服務代真實端）、環境限制、後續建議，一律在交付時**於報告之外對使用者逐條揭露**（見「交付前的揭露」），由使用者決定要不要處理、或點名破例寫進報告。**省略可以，造假不行**——不得因此把未驗證的東西寫成已驗證。 6. **只寫最終狀態，不寫我方作業時序**（鐵則 2 的時間軸版本）：報告呈現「現在的事實」，不呈現「我方跑了幾輪、什麼時候跑的、哪一輪失敗後來又修好」。 **禁字**：複驗、重跑、補行、補跑、第 N 輪、報告產出前、當時、稍早、後來、原先跑的、再次執行。 替代寫法：「調整前 334 項通過；調整後複驗 192 項亦通過」→「既有 334 項全數通過；受本次調整影響之 192 項另行驗證亦全數通過」。「報告產出前之複驗因外部服務無法連線未能重現」→ 移到〔測試限制〕寫成常態性邊界（「