軟體測試：UI、API、人工與自動化測試

核心基礎 — Roman Surkov 的《品質至上：軟體測試完全指南》。所有標記為 [書外補充] 的內容來自其他來源（文末清單）或業界常見實務。請將其視為補充資訊，而非作者立場。

何時使用

「測試某個功能 / 畫面 / 應用程式 / API」、「建立檢查清單 / 測試案例」、「提交 bug」。
在開發前審查規格、Figma 設計稿或 Swagger 文件 (shift-left)。
選擇自動化範圍與方式；撰寫效能測試腳本；發佈準備度報告。
針對電玩遊戲，請使用 qa-game-testing 技能，並從此處提取通用基礎（測試設計、產出物）。

步驟 0：確定工作模式

請求	應提供內容
有規格/設計稿，但無程式碼	需求審查（步驟1）+ 預先撰寫的檢查清單
「測試」但無細節	根據「BLOOGID with PC」分解（步驟2）→ 檢查清單 → 針對複雜功能的測試案例
可訪問的即時網站/應用程式	執行檢查、提交 bug 報告、最終 TRR
API / Swagger / cURL	BINMEN + POISED（步驟6）、請求集合
「應該自動化什麼？」、Flaky 測試、Playwright	根據測試金字塔與自動化規則的計劃（步驟8）
API 安全測試	OWASP API Top 10 矩陣（步驟6）
LLM 功能（聊天機器人、生成式）	驗證層與標準測試集（步驟9）
新功能的探索性測試	SBTM 會話特許狀 + SFDIPOT（步驟2）

先進行正面測試（快樂路徑），再進行負面測試。在正面測試中，測試可合併；在負面測試中，每個驗證只使用一個無效參數。

步驟 1：需求測試 (Shift-Left)

缺陷成本遵循 1–10–100 法則：在規格階段修正成本為 1，在開發階段為 3–8 倍，QA 發現時為 20–80 倍，上線後則超過 100 倍。因此，從文件開始。

良好需求的標準（針對每個違反項目，在文件上加註）：完整性（描述邊緣案例與錯誤）、一致性（文字與設計稿無矛盾）、明確性、正確性、可測試性（「我要如何驗證？」）、原子性（單一概念）。

廢話詞彙 — 「快速」、「方便」、「直覺」、「彈性」、「適當」、「必要時」。請改寫成可量化指標：「搜尋快速」→「在 1000 個並發請求下，結果返回時間 ≤ 1.5 秒」。

若無規格，預期結果的來源順序為：設計稿與原型 → 競品 → 法律法規 (GDPR, PSD2) → 最佳實踐與常識 (email 驗證、速率限制、電話格式) → 與開發者或分析師討論。

如何深入審查需求：提出邊界問題（最大長度、禁止字元、連線中斷、兩個用戶同時點擊）；繪製流程圖或心智圖（指向空白的箭頭代表未描述的場景）；在閱讀需求時直接撰寫測試案例（若無法寫出案例，即表示需求有 bug）。

FEW HICCUPPS 啟發式測試 Oracle [書外補充，M. Bolton & J. Bach] — 當規格不存在或不完整時，用來證明行為有問題的其他依據。產品應與以下項目一致：Familiar problems（不重複已知的 bug 類型）、Explainability（行為可解釋）、World（不違反現實）、History（與先前版本一致）、Image（公司形象）、Comparable products（同類產品）、Claims（文件、廣告、幫助中的聲明）、User desires（合理的用戶期望）、Product（自身一致性：相同操作在不同地方應有相同行為）、Purpose（產品目的）、Statutes and standards（法律與標準）。在 bug 報告中說明 oracle：「與先前版本矛盾」、「與幫助文件矛盾」 — 這能讓「這不是 bug」的爭論更容易解決。

遺失功能： 如果功能不存在且規格中也未提及，這不是 Bug，而是 Improvement / Feature Request。爭議可透過功能矩陣解決：Web 有、iOS 有、Android 沒有。

步驟 2：分解「測試」任務

功能測試回答「做什麼」，非功能測試回答「做得如何」。非功能測試維度請使用助記詞 「BLOOGID with PC」：

B — 安全（XSS、SQL 注入、權限）
L — 本地化
O — 易用性 (Usability)
O — 圖形介面 (GUI)
G — 安裝（僅適用於可安裝項目：桌面、行動、遊戲主機）
I — 無障礙 (a11y)
D — 效能（客戶端與伺服器端）
P — 配置與相容性

加入 Whittaker 的探索測試旅遊進行自由探索：指南（主要功能）、後巷（罕見設定）、快遞（單一物件經歷所有狀態）、金錢（購物車與付款）、夜貓子（背景任務）、清潔工（「取消」、「重置」）、強迫症（重複同一動作 100 次）、壞街區（歷史上問題多的模組）、博物館（舊的、長期未修改的程式碼）。

產品中究竟有什麼 — SFDIPOT [書外補充，J. Bach 的 HTSM]： Structure（組成：檔案、模組、建置）、Function（功能）、Data（輸入、儲存、輸出；空的、巨大的、損壞的資料）、Interfaces（UI、API、匯入/匯出、整合）、Platform（OS、瀏覽器、硬體、外部服務）、Operations（實際使用方式：常見場景、初學者與惡意用戶）、Time（逾時、並行、事件順序、時區、長時間運行）。走過這七個詞，你將得到 BLOOGID 無法提供的覆蓋地圖。

基於會話的探索性測試 (SBTM) [書外補充，J. & J. Bach]。一個會話持續 60–90 分鐘，不受打擾，並有一個特許狀：「使用 <工具、技術、數據> 探索 <領域>，以發現 <我們想了解的內容>」。會話結束後產出會話記錄：涵蓋範圍、發現的 bug、問題、風險、測試/bug 提交/環境設定的時間分配，以及與主管的簡短回顧。這樣自由測試就變得可報告：可以清楚看到測試了什麼以及還剩下什麼。

步驟 3：測試設計技術

執行順序：先用 EP + BVA + 決策表建立骨架，再用錯誤猜測加強。

等價類別劃分 (EP)： 從每個有效和無效類別中取一個值。
邊界值分析 — 僅使用 3BVA： 在每個邊界測試 min-1, min, min+1（對最大值同樣處理）。2BVA 會漏掉運算子筆誤 X == 10 而非 X >= 10：點 9 和 10 通過，但 11 會失敗。範例：年齡限制 18–100 歲 → -1, 0, 1, 16, 17, 18, 99, 100, 101。對於金額，步長為最小單位 (0.01 元)。
組合測試： 1-wise（約 50% bug，快速檢查）、pairwise — 標準 (70–90%)、3-wise 用於金融科技（約 95%）、僅對關鍵系統進行完全組合。永遠不要在腦中組合 pairwise 矩陣：使用工具產生（PICT，如果已安裝；否則 pip install allpairspy --break-system-packages），並用腳本驗證所有配對都被覆蓋。適用場景：目錄過濾器、計算機、付款 × 運送、匯出（格式 × 編碼 × 分隔符）。跨瀏覽器測試不使用 pairwise（請見步驟5）。
決策表： 當規格中有許多「如果 / 且 / 或 / 除非」時，適用於 2–5 個二元條件。刪除不可能的組合，並將結果相同的規則合併為一個案例。典型場景：折扣與優惠碼、角色權限矩陣、表單中的依賴欄位（法人實體 → 必須填寫統一編號）、訂單狀態。
狀態與轉換： 任何具有生命週期和逾時的物件。測試非法轉換、逾時到期（未付款的預約回到「可預約」狀態）、Token 的一次性（使用舊連結重設密碼）、以及在每個步驟中斷連線。
錯誤猜測 — 常見陷阱清單：
- 髒輸入：僅空白、Email 前後空白、U+200B、表情符號、引號、漢字、從緩衝區貼上 10,000 個字元；
- 重複與競爭：三次點擊「付款」、交易後按「返回」、最後一個商品被兩人同時購買；
- 中斷：網路在 99% 時中斷、在交易進行中關閉分頁；
- 日期與數字：非閏年的 2 月 29 日、未來的出生日期、00.00.0000、數量 −1、0、999,999；
- 環境：會話在閒置 3 小時後過期、副檔名為 .jpg 的 .exe 檔案、500 MB 的檔案。

步驟 4：測試產出物

檢查清單（ID、檢查項目、狀態）— 預設格式。測試案例 — 用於複雜邏輯、新手引導以及移交給自動化測試。

測試案例欄位：ID、名稱、優先級、前置條件（務必填寫）、步驟、測試資料、預期結果；執行後加上實際結果與狀態（通過 / 失敗 / 受阻 / 跳過）。

規則：步驟中僅包含測試人員的操作，系統反應放在預期結果中；步驟應原子化（「輸入 email」、「輸入密碼」、「點擊登入」— 三個步驟）；一個案例 = 一個檢查點；案例不互相依賴（準備工作移到前置條件或透過 API 完成）；詳細程度適度，不需要「移動滑鼠」；優先級 High 為金流與授權，Low 為外觀，其餘（約 80%）為 Medium。

測試套件 — 依模組分類的資料夾，內含功能子套件；模組的通用檢查點放在套件根目錄。測試執行 — 針對特定建置與環境執行一組測試案例，並記錄狀態。 測試計畫（按需求）：範圍（納入/排除）、策略與環境、進入/暫停/退出條件、資源與時程、風險與應變計畫。

Bug 報告

標題：     [位置] 在什麼條件下發生什麼事
           範例：[優惠碼視窗] 輸入過期優惠券時出現 500 錯誤
環境：     正式/測試環境、瀏覽器與版本、作業系統；行動裝置需提供型號與精確 OS 版本；URL
前置條件： 使用者角色、頁面、已準備好的資料
步驟：     1. … 2. … （僅需操作，最少步驟）
預期結果： 具體，並附上規格或設計稿的參考
實際結果： 實際發生的狀況
嚴重性：   Blocker / Critical / Major（有解決方法）/ Minor / Trivial — 技術評估，由 QA 設定
優先級：   High / Medium / Low — 商業上的緊急程度（由 PO/PM 決定）
重現率：   Always (10/10) 或 Intermittent（例如 1/10）
解決方法：  替代路徑（如果有）
附件：     靜態畫面截圖、動態操作影片、後端 Console 或 HAR 日誌

規則：1 個 bug = 1 個 ticket；報名前先搜尋是否重複；立即提報；語氣中立；不要在 ticket 中猜測修復方式；撰寫描述時要確保幾個月後仍能據此驗證修復。嚴重性與優先級是獨立的（Logo 拼寫錯誤：Trivial / Immediate）。

測試總結報告 (TRR)

最少廢話，最多數據，並明確給出 Go / No-Go 建議：

建置 vX.Y 測試報告
計劃 N 個案例：通過 a (a%) · 失敗 b (b%) · 受阻 c (c%)
缺陷：BUG-… — 概述（優先級）[連結] …
受阻情況：哪個區塊因哪些 bug 受阻
QA 建議：不建議發佈 / 建議有條件發佈 …

步驟 5：UI：表單、GUI、易用性、無障礙、相容性、本地化

表單與輸入欄位

文字：有效值；空白必填欄位；剛好等於 max；max+1；特殊字元 ' " < > / ; : @ # $ % ^ & * ( ) _ +；表情符號（可能導致 utf8mb4 失敗）；僅空白、前導空白、尾端空白與中間空白（預期會 trim）；混合斯拉夫字母、拉丁字母、漢字與 RTL；F5 應保留輸入內容（密碼與驗證碼除外）；雙擊「送出」不應發送兩個請求；U+200B。
密碼：遮罩顯示；重新整理或發生錯誤時清除；檢查是否為弱密碼以及是否與使用者名稱或 Email 相同；允許從剪貼簿和密碼管理器貼上；「眼睛」圖示切換 password ↔ text。
選擇與上傳：合理的預設值（同意選項預設不勾選 — GDPR）；點擊標籤可切換核取方塊；「全選 / 取消全選」；必選的單選按鈕群組；禁止的副檔名 (.exe, .php)、0 位元組與 100 MB+ 的檔案、進度條。
UX 驗證：在 blur 時進行內聯驗證，錯誤時不清除已輸入內容，欄位高亮並在旁顯示原因與 CTA；預先提示格式（「DD.MM.YYYY」）；一個欄位一個值；成功畫面顯示編號、狀態與下一步；多步驟表單中的「返回」按鈕應保留資料或明確禁止。
加上 BLOOGID：Tab / Shift+Tab / Enter、Safari 與行動裝置、錯誤訊息翻譯、XSS、SQL、CSRF、速率限制。

GUI：與設計稿比對 (Figma + DevTools)

從通用元件開始 — 修正一個通用元件可以修復數十個畫面。尺寸 — 使用 Pixel Measurement 擴充功能（在 DevTools 打開時寬度「小於設計稿」可能是響應式設計而非 bug）。字型與顏色 — Elements → Computed (font-size, background-color → HEX)。間距 — Figma 中的 Option/Alt 對比 Box Model。動畫 — Command Palette → Show Animations，速度降低至 10–25%。疊加比對 — PerfectPixel，透明度設為 50%。1 px 的差異不是 bug（子像素捨入），除非版面因此跑掉。

易用性 (Usability)

根據 Nielsen 的 10 項啟發式進行檢查：系統狀態可見性、使用者語言、控制與復原、平台標準 (HIG / Material)、防止錯誤、辨識而非回憶、加速器、極簡設計、清晰的錯誤訊息、說明文件。針對年長使用者：字型不小於 12 pt、對比度、大點擊目標。不要破壞原生模式：雙擊、系統螢幕邊緣手勢。提供 5 秒「復原」的取消功能優於「您確定嗎？」對話框。

無障礙 (WCAG, POUR)

快速檢查：Lighthouse（僅無障礙）→ axe DevTools → IBM Equal Access → ANDI（Tab 順序與元素名稱）→ 對比度 (AA ≥ 4.5:1, AAA ≥ 7:1)。圖片或漸層上的文字 需用 DevTools 吸管再次確認：掃描工具會取用相鄰標籤的顏色。手動檢查：全程無須滑鼠操作、焦點可見且未被遮擋、資訊性圖片有 alt 文字、無閃爍頻率超過每秒 3 次的內容、尊重 prefers-reduced-motion、螢幕閱讀器 (NVDA / VoiceOver)。模擬工具 — Web Disability Simulator。

相容性

根據數據建立測試矩陣：自有分析 → 地區統計 → StatCounter（並說明覆蓋不足的風險）。根據平台營收而非僅根據流量來判斷。剔除市占率 < 0.5% 的長尾項目。根據渲染引擎分組：Windows 上的 Chrome 與 Edge 都是 Chromium；iOS 上的所有瀏覽器都是 WebKit，但 iOS 上的 Safari 仍需單獨測試（有獨特的版面 bug）。根據市佔率比例分配回歸測試（200 個案例 × 各組市佔率），而不是使用 pairwise「瀏覽器 × 案例」（這會導致 1400 次執行）。使用雲端裝置實驗室（BrowserStack / Sauce Labs）或實體實驗室來補足裝置不足。

本地化

檢查字元集 (UTF-8、頁面宣告)；翻譯是否完整（無殘留的英文或 Babel 字串 key）；文字展開（德語 Zusammenhangsuntersuchung）是否破壞了未設定 word-break: break-word 的按鈕；日期格式（2024.12.31 vs 12/31/2024）、數字格式（小數點與千分位分隔符）、貨幣（售價中的 $ 符號）、地址格式，以及根據文化調整的預設值。

步驟 6：API 測試

階段 0：文件審查。 檢查 Swagger / OpenAPI：強制與可選參數、邊界 (maxLength)、授權方法和權限、回應碼和結構、文件是否有矛盾或不完整之處。

階段 1：連通性與快樂路徑 — 200 OK。階段 2：前端測試 — API 是否正確實作，所有欄位與狀態碼是否如文件所述。如果我們有前端，這就是關於 API 為何不回傳資料的 Bug 報告（例如：缺少 premise 欄位導致前端顯示空白）。

階段 3：BINMEN — 後端測試助手記憶法：

B — 邊界：maxLength、負值、零、空陣列、含空字串的陣列、浮點數作為整數傳遞、字串作為數字傳遞；
I — 遺失：缺失必填欄位、缺失可選欄位（預設值有效嗎？）、空物件 {} 或空陣列 [] 作為 body；
N — 負面：無效的 email、電話、日期、URL、格式錯誤的 JSON、未定義的型別、偶數預算等無效參數；
M — 修改資料的方法：PUT 與 PATCH 是否按預期運作（部分更新）、DELETE 是否允許重新建立（冪等）、批量操作；
E — 錯誤處理：4xx 和 5xx 回應是否包含可讀的訊息和正確的結構、標準錯誤格式；
N — 協商：Accept: text/html 是否傳回 HTML、Accept-Language 是否影響回應。

階段 4：POISED — 非功能性測試：

P — 效能：回應時間 < 閾值、負載下的行為、快取；
O — OWASP API Top 10 — 見下方矩陣；
I — 冪等性：GET, PUT, DELETE 重複請求不應改變狀態；
S — 安全性：認證、授權、列舉、Idempotency-Key、速率限制、CORS；
E — 極端情況：單一請求同時影響多個物件、長時間請求、電子郵件佇列連線遺失；
D — 資料：權限屏蔽（用戶 A 看到用戶 B 的資料）、雙重貼文、會話過期、唯讀與唯寫欄位。

OWASP API Top 10 矩陣

類別	要檢查什麼
API1:2023 — 物件層級授權失效	用戶只能存取自己的資源（user_id ≠ token.user_id → 403）；路徑遍歷攻擊；Prisma 中的 `rejectOnNotFound`；「頁面」引數中的 IDOR；使用 PUT DELETE X-HTTP-Method-Override
API2:2023 — 認證失效	暴力破解保護 (fail2ban, rate limit)；弱密碼檢查；Token 撤銷（包括已登出用戶的 Token）；重複使用密碼重設 Token；OAuth redirect_uri 驗證；JWT 驗證 (`alg: none`, 弱金鑰, 過期)
API3:2023 — 物件層級屬性層級授權失效	透過 `PATCH` 更改 Role、isAdmin；`PUT` 可選欄位更改 CreationDate；設定他人作品的 status、isActive；mass assignment
API4:2023 — 資源消耗限制失效	無 `maxLength` 的欄位；大型字串；遞迴 JSON `{"a":{"a":...}}`；無限分頁；Zip 炸彈；`?format=pdf` 對長資料的回應時間
API5:2023 — 功能層級授權失效	普通用戶呼叫管理員端點 (`GET /admin/users/export`)；角色檢查是硬編碼的還是基於實際權限；RBAC / ABAC
API6:2023 — 大量指派 (Mass Assignment)	見 API3
API7:2023 — 安全配置錯誤	啟用了除錯模式、CORS 過於寬鬆 (`*`)、未強制使用 HTTPS、舊版 API 未移除、目錄列表、HTTP 方法覆蓋、HTTP 動詞（`DELETE /payments` 如 `GET`）、錯誤訊息中的堆疊軌跡、防火牆後方的 API 金鑰洩漏
API8:2023 — 注入攻擊	反映式 XSS，儲存式 XSS（HTTP 回應中的參數？）、X-Forwarded-For、User-Agent — 任何正被記錄然後在管理 UI 中顯示的內容；SQL 注入（單引號、時間型）；NoSQL 注入；參數污染 (`?id=1&id=2`)；SSRF（`?url=`）；JSONP
API9:2023 — 資產管理不當	外部文件、測試端點 (`/api/v3/test/`)、Swagger 在正式環境中公開、管理面板 (`/admin/dashboard`)；過時的 API 版本；不只使用有效的 API 金鑰，還使用從註冊中獲得的正確金鑰（Grafana、Retool 金鑰）
API10:2023 — 不安全的使用日誌記錄與監控	API 是否記錄可疑活動？401 回應是否被處理？開發環境的日誌中是否有敏感資料 (`req.headers`)

合約測試：不應將合約測試與 API 測試混淆。API 測試針對的是實作（給定資料庫狀態和請求 → 檢查回應），而合約測試針對的是介面文件。Pact 能產生「pact」檔案，用來驗證消費者端的模擬請求是否符合提供者端的測試。它不能取代功能或端到端測試。

步驟 7：非功能性測試

安裝

（僅限可安裝產品）安裝路徑、權限、非管理員使用者、已安裝舊版本的情況下進行更新、損壞的安裝程式、安靜安裝與 GUI 安裝、安裝後捷徑、卸載（是否完全移除，包括登錄檔中的設定？）、檢查是否安裝了 VC++ 執行階段等必要元件。

效能

固定負載（例如 1,000 個同時用戶持續 1 小時）→ 穩定狀態附近不應出現下降。尖峰負載（5 分鐘內從 100 到 5,000）→ 檢查自動擴展與節流。耐久性測試（2–3 小時）→ 檢查記憶體流失。用戶體驗：LCP < 2.5 秒、INP < 200 毫秒、CLS < 0.1（用於網站）；TTFB < 1 秒（用於 API）。

安全 — OWASP Top 10 (Web) / OWASP API Top 10 (API)

對照步驟 6 中的 OWASP API Top 10 矩陣執行。手動檢查：XSS（儲存型）、SQL 注入、路徑遍歷、存取控制（管理員權限等），以及基於角色和權限的授權。

步驟 8：測試自動化

自動化計劃

規劃： 對於端到端 (E2E)：撰寫 4–6 個快樂路徑來覆蓋主要功能。在每個版本中執行。如果它失敗了，QA 在開始測試前就知道並且開發人員也得到通知。API 自動化：覆蓋核心 CRUD、邊界、錯誤、資料庫中的資料完整性、安全檢查。

何時不使用自動化： 沒時間或預算、不穩定的環境導致頻繁失敗、蜜月期（功能即將重寫）、極難以自動化驗證的檢查（音訊/視訊品質、設計與設計稿的比對）。願望：將 E2E 視為「您可以手動測試某些東西」，但讓機器人反覆執行相同的操作。

測試金字塔與分配比例：

單元測試 - 70%：隔離的類別/方法，快速，由開發人員在 CI 中執行。QA 針對邊界案例、錯誤路徑和資料庫邏輯（資料庫測試）進行程式碼審查。
API 測試 - 20%：請求-回應檢查，在沒有 UI 的情況下在後端層級驗證邏輯。由 QA 在 CI 中執行。
E2E 測試 - 10%：關鍵業務路徑（付款、註冊）。僅對高風險功能進行測試。由 QA 在 CI 中執行。

反模式： 在沒有自動化 API 測試的情況下執行 E2E 測試（沒有 squashing bugs — 你怎麼知道它是否正常運作？）；測試用例在 E2E 中包含無限的斷言（測試維護、PowerShell 接收器）；每次建置都執行所有回歸測試（只在合併前執行受影響的 API 測試，而不是整個套件）。

Playwright 測試規則

選擇器：優先使用 data-testid / data-cy → getByRole → getByText → getByPlaceholder。page.locator('button') 會中斷。
登入：透過 API 進行認證（設定 Cookie / LocalStorage），以便測試可以獨立登入。
測試隔離：每個測試必須設定自己的資料（API 呼叫 + DB 清理）或使用專用帳戶。不要使用 test.describe.serial。
等待：優先使用 waitForResponse / waitForURL 而非 waitForTimeout。不要睡 1 秒鐘。
使用 linters：eslint-plugin-playwright（檢查 'no-wait-for-timeout', 'no-page-pause', 'no-force-option'）
不穩定性：註解掉不穩定的測試不是解決方案。修正它們或使用 test.fixme。

Flaky 測試

原因與解決方案：

計時問題 → 使用 waitForResponse 或 toPass，而不是固定的 waitForTimeout。
順序依賴（測試共用 Cookie）→ 每個測試使用獨立的狀態。
浮動元素（動畫）→ 在互動前等待動畫結束。使用 waitFor({ state: 'stable' })。
非確定性（隨機資料）→ 在 CI 執行期間記錄種子值。
並行（同一個使用者的兩個請求）→ 使用可唯一識別的測試資料。
外部 API → 使用攔截 (mock/route)。

措施： 設定閾值 — 非合併，例如，如果 > 5% 的執行失敗。如果測試經常不穩定，請建立一個票證。對每次 CI 執行進行分類。

步驟 9：LLM 測試

LLM 架構層級

架構層：RAG、提示、快取、協調器 — 我們能控制什麼？搜尋相關性、提示注入、快取命中率、協調器邏輯（工具選擇）。
模型層：LLM 模型 — 我們無法直接控制。輸出驗證、毒性、幻覺、遵循指示。
展示層：UI/UX — 即時串流、載入指示器、標記反饋（「讚」/「倒讚」）、定價、延遲。我們測試用戶所看到的。

通用 LLM 測試

角色設定遵守（系統提示）：模型是否扮演指定的角色（顧問、翻譯）？
邊界案例：超出上下文長度的長文字、空輸入、特殊字元。
安全性：提示注入、越獄（請參閱 PromptFoo、Garak）、資料外洩（在回應中洩漏系統提示）。
幻覺：模型是否欺騙使用者（虛構的引文、數字、事實）？檢查事實，將其與 RAG 來源進行比較。
令牌計數：超長的提示是否會導致截斷、錯誤或降級？
語言一致性：提示為英文 → 回應為英文。混合語言時如何處理？
回應格式：JSON、Markdown、XML。如果提示要求「僅 JSON」，但模型回傳了 Markdown 呢？
重現性且溫度=0：相同提示 → 相同回應。如果不是，這就是一個 bug。
載入狀態：使用者是否看到 Loading... 或骨架螢幕？
即時性：回覆產生時是否串流？還是等到完成後才一次顯示？
反饋：使用者能否對回覆評分？評分是否已記錄？
狀態：檢查後續操作（重新產生、繼續、停止）的行為。

附錄：來源與參考文獻

Roman Surkov，《品質至上：軟體測試完全指南》
Michael Bolton, James Bach：FEW HICCUPPS, SBTM, HTSM
James Whittaker，《探索性軟體測試》
Nielsen Norman Group：10 項可用性啟發式
OWASP API Security Top 10 (2023)
Playwright 文件
Pact 文件（合約測試）
PromptFoo（LLM 安全測試）
Garak（LLM 漏洞掃描器）

在你喜歡的 AI 中提問

說明文件