• 你寫 50 條用例，產品翻了兩頁：“風控觸發(fā)后的兜底邏輯呢？”
• 開發(fā)湊過來看了一眼：“第三步額度校驗寫的是5000，PRD 里是 50000。”
• 測試組長放下手機：“新老用戶的優(yōu)惠互斥呢？單日限額邊界值呢？預期結果就兩個字‘成功’？”

問題往往不在“用例寫得差”，而在于缺少量化的標準

——到底什么樣算合格？憑什么說這一條不行？

今天分享的這個Skill：用數(shù)據(jù)代替“我覺得”，用系統(tǒng)代替經驗。我把它用在一個金融支付轉賬優(yōu)惠活動項目中，45 條用例3分鐘審完，采納率99%以上

01、為什么你的用例總是被懟？

先看一個真實場景：某支付App要上線“轉賬手續(xù)費優(yōu)惠活動”——

PRD核心規(guī)則（簡化后）

• 單筆轉賬滿 100 元，手續(xù)費減免 2 元；
• 新用戶首筆轉賬免手續(xù)費（不與滿減疊加，取最優(yōu)）；
• 單日累計轉賬限額5,000 元（含）；
• 夜間 23:00-05:00 轉賬≥1,000 元，需觸發(fā)人臉識別
• 同一用戶同一收款方，24 小時內最多轉 3 筆；
• 優(yōu)惠券（隨機立減券）與手續(xù)費減免互斥，用戶手動二選一。

測試人員寫了45條用例，自認為覆蓋全面。結果評審會上：

• 產品：“風控拒絕后，提示文案是什么？用例里怎么沒有？”
• 開發(fā)：“夜間轉賬用例只測了 1,000 元整，1,001 元呢？99.99 分也測一下？”
• 組長：“新老用戶互相轉換的場景呢？昨天新用戶，今天變老用戶，優(yōu)惠怎么算？”

痛點本質：評審標準因人而異，用例質量靠“感覺”，問題總在最后一刻才暴露。

02、把主觀判斷變成量化數(shù)據(jù)

60 分及格。每條用例都會得到：

• 總分+各維度得分
• 扣分原因（精確到步驟編號）
• 具體的改進建議

輸入：Excel用例文件、Markdown文檔、PRD截圖（支持直接讀圖）
輸出：每條用例逐項評分 + 扣分原因 + 改進建議，一鍵導出Markdown表格

03、實戰(zhàn)場景

場景一：一條典型的不合格用例

原始用例（TC018）：

• 標題：新用戶滿100減免手續(xù)費
• 步驟：新用戶登錄，轉賬120元，使用手續(xù)費減免
• 預期結果：扣款成功，手續(xù)費0元

Skill 逐維評分后，直接亮了紅燈：

• 邏輯完整性（10/25）：PRD 規(guī)定“新用戶首筆免手續(xù)費，不與滿減疊加”，但用例步驟里同時寫了“使用手續(xù)費減免”和“新用戶免手續(xù)費”——兩者沖突，到底走哪個規(guī)則？
• 預期結果明確性（8/20）：“扣款成功”太模糊。轉賬成功返回的交易流水號？優(yōu)惠命中哪個規(guī)則？最終實際扣款金額是多少？
• 前置條件完備性（7/15）：未說明新用戶是否已完成實名認證、賬戶余額是否足夠、是否在活動有效期內、收款方是否在黑名單內。
• 邊界異常覆蓋（4/15）：沒有考慮余額不足、風控拒絕、網(wǎng)絡超時等異常場景。

綜合得分 54 分，不及格...

Skill 給出的修改建議

前置條件：

- 用戶注冊時間＜24小時，已完成實名，賬戶余額200元

- 活動有效期內，收款方為正常賬戶

步驟：

1. 發(fā)起轉賬120元

2. 系統(tǒng)自動計算優(yōu)惠：比較“新用戶免手續(xù)費”和“滿100減2元”，取最優(yōu)（免手續(xù)費）

3. 最終扣款金額=120元，手續(xù)費=0元

預期結果：

- 返回訂單號TXN2025xxx，狀態(tài)“轉賬成功”

- 賬戶余額減少120元，手續(xù)費扣減記錄為0

- 優(yōu)惠命中標識：USE_NEW_USER_FREE

異常補充：

- 余額不足時，提示“余額不足，請充值”

- 收款方被風控時，返回“對方賬戶異常，暫無法轉賬”

場景二：系統(tǒng)性遺漏

??PRD明確寫：23:00-05:00 轉賬≥1,000 元需人臉識別

??但45條用例中，凡涉及夜間轉賬的12條，步驟一律是“輸入密碼→轉賬成功”——完全跳過了人臉識別

??Skill 批量掃描后，一次性標注出所有缺失用例，并提示：“建議增加人臉識別成功、失敗、超時重試三個子場景。”

不要小看這種“系統(tǒng)性遺漏”——上線后極可能導致夜間大額轉賬繞過風控，直接資損。

場景三：邊界值漏測

??PRD中單日限額 5,000 元。用例只寫了：

• 4,999 元（成功）
• 5,000 元（成功）
• 5,001 元（失敗）

Skill 指出：

??缺少4,999.99元、5,000.01元、以及累計金額的跨日重置驗證

??同時提醒：限額是針對“單日累計”，用例里沒有覆蓋“第一筆3000，第二筆2000，

??三筆1元”——累計超限時，第三筆應該被拒絕。

這些都是評審會上最容易被“內行”追問的細節(jié)。

04、具體操作步驟

1、在WorkBuddy中找到該Skill
2、觸發(fā)關鍵詞：

審核測試用例 / 給用例打分 / review 測試用例

3、上傳文件

• 測試用例文件（.xlsx / .md）
• PRD 截圖（可直接拍照上傳，支持多張）

4、設置及格線（默認 60 分，可改為 70/80）

5、等待 1-3 分鐘，獲取完整審核報告
6、報告包含：每條用例的分值、扣分項、改進建議；整體質量評分；問題分類統(tǒng)計。

• 根據(jù)報告修改用例，再次上傳復審。

小貼士：第一次使用建議先用 10-20 條用例試跑，熟悉評分風格后再全量使用。

05、Skill能審什么？【大實話版】

?它能做

• 把主觀評審變成量化分數(shù)，結論可追溯；
• 批量發(fā)現(xiàn)“12 條用例同一個錯”的共性問題；
• 直接讀 PRD 截圖，提取規(guī)則并逐條對照；
• 支持 Excel、Markdown 和截圖，多文件同時上傳。

?它不能做

• 判斷 PRD 規(guī)則本身是否正確（例如“限額 5000”不合理，它不會質疑）；
• 驗證你執(zhí)行測試時操作是否正確；
• 處理超復雜嵌套邏輯的深層業(yè)務合理性（需要人工介入）。

結論：AI 負責“寫得對不對”，人工負責“業(yè)務對不對”——兩者互補

測試用例評審最痛苦的，不是寫用例，而是每個人都有自己的標準。
而當你拿出一份100分制的量化報告——哪條54 分、為什么扣分、怎么改——討論就不再是“我覺得”，而是“數(shù)據(jù)如此”。

??想了解更多漲薪技能提升方法

??可以到公主號【Atstudy技術社區(qū)】,即可加入領取 ??????

??轉行、入門、提升、需要的各種干貨資料

??內含AI測試、 車載測試、AI大模型開發(fā)、BI數(shù)據(jù)分析、銀行測試、游戲測試、AIGC