1. 拿到需求別急著開寫用例設(shè)計的第一步其實是讀懂系統(tǒng)功能測試用例到底該怎么設(shè)計我發(fā)現(xiàn)很多剛?cè)胄械臏y試新人最喜歡干的一件事就是打開Excel照著需求文檔的字段列表一個輸入框一個輸入框地寫用例。輸入用戶名一條輸入密碼一條點擊登錄按鈕一條……寫了幾十條下來看著挺充實一評審就被老測試幾句話問住登錄失敗之后有提示嗎連續(xù)輸錯五次會鎖賬號嗎鎖了之后什么時候解鎖這些用例你寫在哪了這其實就是典型的用例設(shè)計思路沒建立起來的表現(xiàn)。測試用例不是需求文檔的字段翻譯器它是你對整個系統(tǒng)的一次模擬推演——你得在腦子里先把功能跑一遍再把跑法具象化成一條條用例。所以我不太喜歡直接用設(shè)計思路這個詞來講這件事我更愿意把它拆成四個環(huán)節(jié)讀懂需求、拆解場景、組織表達、持續(xù)維護。這篇文章就沿著這條線把我這些年實際走下來的思路完整過一遍希望能給正在為用例寫不好、評審總挨批發(fā)愁的朋友一點實在的參考。1.1 需求澄清階段用例設(shè)計者應(yīng)該坐的位置先說一個我自己的親身體會用例設(shè)計真正開始的時間不是需求文檔交到你手上那一刻而是產(chǎn)品經(jīng)理開始講需求的那一刻。我見過太多測試同事需求宣講會上從頭到尾不吭聲等文檔發(fā)下來才逐字逐句讀。結(jié)果讀到一半發(fā)現(xiàn)一堆模糊地帶這里的列表排序規(guī)則是什么這個字段必填嗎超時時間設(shè)多少——這些問題如果在會上問一分鐘就能得到答案拖到寫用例的時候再回頭找產(chǎn)品往往就得等半天而且很容易出現(xiàn)需求變更了但你還在按舊邏輯寫的情況。所以在需求澄清階段我會強迫自己干三件事第一帶著問題去聽。需求文檔沒到手之前先跟產(chǎn)品經(jīng)理要一頁紙的功能概述哪怕是口頭說的都行。我要搞清楚三個最基本的問題這個功能給誰用解決什么問題操作路徑是什么這三個問題搞不清楚后面所有用例都是空中樓閣。第二現(xiàn)場把業(yè)務(wù)規(guī)則頂清楚。產(chǎn)品經(jīng)理講到任何一條規(guī)則時我都會追問它的邊界情況。比如訂單超過30分鐘未支付自動取消我會立刻問那第29分59秒支付成功了呢第30分鐘整呢自動取消的同時用戶正在支付怎么辦取消之后庫存還恢復(fù)嗎這些問題不是抬杠而是把規(guī)則從文字描述變成可執(zhí)行的邏輯。第三把需求當(dāng)代碼一樣做靜態(tài)走查。我會在拿到需求文檔之后對照歷史功能列一張變更影響清單——這次改了什么、新增了什么、刪除了什么、有沒有動到之前的老邏輯。很多重大故障都出在我只是加了一個字段沒想到牽動了舊邏輯這種地方。說個真實案例。我們之前做過一個后臺的批量導(dǎo)入功能需求文檔里寫得很清楚支持Excel批量導(dǎo)入單次不超過1000條。我看完之后問了一句如果導(dǎo)入的文件里有50條數(shù)據(jù)格式正確、30條格式錯誤、20條重復(fù)系統(tǒng)會怎么處理產(chǎn)品說逐條校驗錯誤的跳過正確的導(dǎo)入。我又問那錯誤和重復(fù)的記錄要不要給用戶反饋反饋在哪看要不要生成一個失敗清單產(chǎn)品當(dāng)場愣了一下說這個細節(jié)他還沒想好。結(jié)果這個沒想好的細節(jié)后來成了整個功能最復(fù)雜的模塊——因為失敗清單要展示具體行號、錯誤原因、并且允許用戶下載修正。測試人員如果在需求階段不問這一句等用例寫完、開發(fā)做完了才發(fā)現(xiàn)返工成本就是十倍百倍。所以別覺得自己只是寫用例的你要把自己當(dāng)成第一個運行這套系統(tǒng)的人——你在紙上跑不通的邏輯開發(fā)寫完大概率也跑不通。1.2 業(yè)務(wù)規(guī)則拆解從需求描述翻譯成邏輯清單需求澄清做完接下來這一步非常關(guān)鍵也是很多測試同學(xué)跳過去的把需求文檔里的自然語言逐條翻譯成如果-那么的邏輯清單。為什么要干這件事因為自然語言是有歧義的。用戶點擊提交后系統(tǒng)將訂單狀態(tài)更新為待審核——這句話看起來沒毛病但點擊提交之前發(fā)生了什么表單校驗不通過怎么辦網(wǎng)絡(luò)異常超時怎么辦服務(wù)器返回500怎么辦這些在自然語言里全是隱含邏輯你要做的就是把它們?nèi)匡@式化。我常用的做法是畫一張業(yè)務(wù)規(guī)則清單表每一行就是一條獨立業(yè)務(wù)規(guī)則列包括編號、觸發(fā)條件、系統(tǒng)動作、異常分支、備注。比如拿一個最簡單的登錄功能來說編號觸發(fā)條件系統(tǒng)動作異常分支R01用戶名和密碼均正確登錄成功跳轉(zhuǎn)首頁無R02用戶名正確密碼錯誤提示密碼錯誤記錄失敗次數(shù)R03用戶名不存在提示用戶名不存在無R04連續(xù)失敗5次鎖定賬號30分鐘鎖定期間即使密碼正確也不放行R05鎖定期滿后首次登錄解鎖并允許登錄重置失敗計數(shù)這套規(guī)則清單整理完你會發(fā)現(xiàn)兩件重要的事第一用例還沒開始寫你已經(jīng)能看出產(chǎn)品邏輯的漏洞了比如R04和R05之間的競態(tài)條件第29分59秒用戶試了一次錯的算不算鎖定期內(nèi)第二后面寫用例的時候完全可以一條規(guī)則對應(yīng)至少兩條用例——一條走正常分支、一條走異常分支覆蓋率和邏輯完備性一下子就上去了。這塊我還有個心得規(guī)則清單要盡量落到可判定的程度。什么叫可判定比如密碼錯誤這四個字你得搞清楚是前端先校驗格式還是發(fā)到后端校驗錯誤提示的文案是什么輸入框要不要標紅光標要不要定位回密碼框這些雖然不是每條都要寫進用例但它們是你的測試觀察點——沒有觀察點的用例執(zhí)行完你也分不清到底算通過還是算失敗。2. 用例設(shè)計的工具箱不是每種方法都要硬套得知道在什么場景用哪把功能測試用例設(shè)計方法論市面上講得很多等價類劃分、邊界值分析、場景法、判定表、因果圖、正交實驗、錯誤推測……書上都寫過但我在實際項目里發(fā)現(xiàn)一個普遍問題很多測試同學(xué)把方法當(dāng)成了模板拿到任何功能都從等價類開始套結(jié)果把最簡單的東西做復(fù)雜了把最復(fù)雜的東西又做簡單了。所以這一節(jié)我不打算按教科書的方式把每個方法講一遍而是想聊聊我實際使用這些方法時的選型邏輯——什么場景下用什么方法最劃算什么情況下可以大膽地把方法組合起來用。2.1 輸入類功能等價類和邊界值誰在先其實有講究等價類劃分和邊界值分析是測試用例設(shè)計的基礎(chǔ)中的基礎(chǔ)幾乎所有跟輸入框、下拉框、日期控件有關(guān)的功能都能用上。但這兩者誰先誰后很多人沒想過。我的習(xí)慣是先做等價類劃分再做邊界值補充最后用錯誤推測來加菜。為什么這個順序因為等價類解決的是覆蓋面問題邊界值解決的是精準度問題錯誤推測解決的是真實感問題。你不可能一上來就精確定位某個邊界你得先把大區(qū)域分出來把有效數(shù)據(jù)和無效數(shù)據(jù)劃清楚再去看邊界上的那兩三個值。舉個例子一個庫存管理系統(tǒng)的入庫數(shù)量輸入框要求是大于0小于等于10000的正整數(shù)。等價類怎么劃有效等價類有三個1到10000之間的整數(shù)、大于0的任意整數(shù)這只是理論上說實際上還是要落到具體值無效等價類有一堆0、負數(shù)、小數(shù)、非數(shù)字字符、超過10000的整數(shù)、空值。邊界值分析怎么做就是取邊界旁邊的值0和1下邊界兩側(cè)、10000和10001上邊界兩側(cè)。注意這里有一個新手常犯的錯誤——邊界值不是只取邊界本身而是要把邊界兩側(cè)的值都取到而且要結(jié)合有效類取一個、無效類取一個。比如1是有效下邊界0是無效下邊界兩個都要測。但是光這樣還不夠。我還會問一句這個輸入框有沒有輸入法限制能不能粘貼復(fù)制粘貼一個1000有沒有可能輸入 1 帶空格算不算通過這些用等價類和邊界值劃分不出來因為它們屬于真實用戶在操作時可能出現(xiàn)的輸入方式——這就是錯誤推測法發(fā)揮作用的地方了。錯誤推測法聽起來很玄學(xué)好像全靠個人經(jīng)驗其實也有套路基于你過去犯過的錯和見過的bug去推測當(dāng)前系統(tǒng)可能存在的問題。我有個習(xí)慣新項目開始前會專門去翻一下過往同類模塊的缺陷報告把高頻bug列成一張失效模式清單——比如日期格式在不同瀏覽器解析差異、金額計算浮點精度丟失、大量數(shù)據(jù)下分頁按鈕失效、快速雙擊提交按鈕產(chǎn)生重復(fù)訂單……這些清單每到一個新功能就拿出來過一遍能命中不少問題。2.2 流程類功能場景法才是主線別再用功能點羅列代替用戶旅程輸入類功能好處理真正讓很多測試頭疼的是流程類功能——用戶從開始操作到結(jié)束中間可能跨頁面、跨狀態(tài)、跨數(shù)據(jù)變更。比如電商下單、審批流、訂單退貨流程這類功能光靠等價類和邊界值是遠遠不夠的你需要的是場景法。場景法的核心思想是用基本流和備選流把用戶的操作路徑走一遍。但我在工作中看到的普遍現(xiàn)象是大家用場景法用得特別粗糙基本流就是需求文檔里的happy path備選流就是隨便挑幾個報錯場景——這樣下來整個流程的完整性還是覆蓋不到。我自己的做法是把場景法和狀態(tài)轉(zhuǎn)換法結(jié)合著用。第一步先把系統(tǒng)的核心狀態(tài)畫出來比如一個訂單的狀態(tài)可能有新建、待支付、已支付、待發(fā)貨、已發(fā)貨、已完成、已取消。第二步畫狀態(tài)之間的合法轉(zhuǎn)換邊新建可以到待支付發(fā)起支付待支付可以到已支付支付成功待支付可以到已取消用戶取消已支付可以到待發(fā)貨支付完成進入備貨……第三步把導(dǎo)致狀態(tài)轉(zhuǎn)換的動作逐條列出來。第四步用這些合法轉(zhuǎn)換邊推導(dǎo)基本流用非法轉(zhuǎn)換邊和異常情況推導(dǎo)備選流。這么做的好處是你會發(fā)現(xiàn)有些雖然流程上合法但產(chǎn)品經(jīng)理沒寫清楚的狀態(tài)組合。比如已發(fā)貨之后還能不能申請取消如果訂單已經(jīng)出庫了用戶取消申請系統(tǒng)是攔截還是走逆向流程已支付但是支付回調(diào)沒收到訂單卡在中間態(tài)系統(tǒng)有沒有對賬機制這些問題如果等到執(zhí)行階段暴露出來要么是需求漏洞要么是開發(fā)實現(xiàn)沒考慮——而你現(xiàn)在在用例設(shè)計階段就發(fā)現(xiàn)了等于提前幫項目排了雷。場景法寫出來的用例還有個好處就是可讀性強。我評審別人的用例時最怕看到那種點擊A按鈕驗證跳轉(zhuǎn)到B頁面點擊C按鈕驗證D字段顯示的碎片化用例——你根本不知道用戶在干什么也說不清這條用例驗證的是哪個業(yè)務(wù)目標。場景法用例就不一樣它們的名字本身就帶著業(yè)務(wù)含義用戶支付超時后重新發(fā)起支付訂單狀態(tài)最終應(yīng)為已支付并恢復(fù)庫存扣減——評審人一眼就能看出這條用例的業(yè)務(wù)價值和驗證點。2.3 多條件組合判定表、因果圖、正交試驗到底用哪個流程類功能處理完還有一個場景經(jīng)常讓人頭大當(dāng)一個動作的結(jié)果同時受多個條件影響時用例數(shù)量會失控。比如優(yōu)惠券計算用戶是否登錄、是否會員、訂單金額是否滿足門檻、優(yōu)惠券是否在有效期內(nèi)、是否可疊加使用——五個條件兩兩組合就是32種情況全寫出來用例數(shù)爆炸不寫吧又怕漏掉關(guān)鍵組合。這種場景下不同的方法各有適用場景。判定表適合條件個數(shù)不多一般不超過4~6個且條件和動作都是離散取值的情況。因果圖是判定表的圖形化表達適合你在跟別人溝通邏輯時用實際寫用例時還是轉(zhuǎn)化為判定表更直接。正交試驗法我個人覺得是最適合條件多、組合多、但全測不現(xiàn)實的場景——它用正交表取有代表性的組合用最少的用例覆蓋兩兩組合的完整度很適合參數(shù)組合測試。不過我得給一句忠告正交試驗法在真實項目中的應(yīng)用沒有教科書里那么樂觀。因為正交試驗假設(shè)所有條件之間是相互獨立的而真實業(yè)務(wù)邏輯里條件之間往往有強關(guān)聯(lián)——用戶是會員和用戶未登錄這兩個條件不可能同時為真。所以正交試驗算出來的用例組合里經(jīng)常會有一些邏輯上不可能的搭配你需要人工把這些排除掉。我的建議是先用判定表把業(yè)務(wù)規(guī)則的核心邏輯理清楚再用正交試驗的思路處理那些理論上可以組合、但沒必要窮舉的次級參數(shù)兩者結(jié)合才能既保證核心邏輯覆蓋又控制用例規(guī)模。3. 如何判斷用例夠了從覆蓋維度到優(yōu)先級排序的完整框架用例寫完了評審的時候最怕被問一個問題用例全了嗎——全這個字是沒法量化的。你不能拍著胸脯說全覆蓋了你得有一套判斷框架。3.1 功能點之外的隱形維度數(shù)據(jù)、狀態(tài)、權(quán)限、環(huán)境、異常很多測試同學(xué)判斷覆蓋率的時候只看功能點——需求文檔里寫了幾個功能點我就寫幾條用例。這是遠遠不夠的。我在工作里總結(jié)了一套多功能維度檢查法每次用例評審之前用這套維度清單做一次自查第一個維度是數(shù)據(jù)維度同樣的操作不同數(shù)據(jù)狀態(tài)下結(jié)果是否一致比如列表頁有0條數(shù)據(jù)、1條數(shù)據(jù)、1000條數(shù)據(jù)時的分頁展示比如搜索功能關(guān)鍵詞為空、單字、長文本、帶特殊符號時的表現(xiàn)。這些不寫用例你心里就沒底。第二個維度是狀態(tài)維度上文已經(jīng)說過流程類功能一定要畫出所有狀態(tài)和狀態(tài)轉(zhuǎn)換。很多bug其實就藏在狀態(tài)動作的矩陣里——比如已取消訂單重新支付這種操作需求文檔根本沒寫但用戶真的能到達這個頁面歷史訂單里點了一個舊鏈接。這種從不該出現(xiàn)的入口進入的用例恰恰最能發(fā)現(xiàn)問題。第三個維度是權(quán)限維度同一功能對不同角色、不同數(shù)據(jù)范圍應(yīng)該有不同的可見性和操作性。前臺用戶能不能看到后臺的刪除按鈕普通員工能不能看到所有人的薪資A部門經(jīng)理能不能修改B部門的數(shù)據(jù)權(quán)限維度最容易出的是越權(quán)漏洞這類用例在安全測試里也是重點。第四個維度是環(huán)境維度不同瀏覽器、不同操作系統(tǒng)、不同網(wǎng)絡(luò)環(huán)境下功能表現(xiàn)是否一致這不僅僅是兼容性測試的事——有些隱藏的js報錯、樣式錯亂、接口超時只在特定環(huán)境下才會觸發(fā)。我見過一個項目開發(fā)在自己Chrome上測得好好的用戶用Safari打開直接白屏就是因為有個API在Safari下不被支持。第五個維度是異常維度這是我最看重的維度。包括外部接口異常、依賴服務(wù)超時、數(shù)據(jù)庫連接失敗、消息隊列積壓等。很多團隊把異常測試扔給聯(lián)調(diào)階段去碰運氣但真正的異常場景需要提前設(shè)計——比如支付回調(diào)延遲2分鐘到達系統(tǒng)怎么處理第三方短信服務(wù)掛了注冊流程是繼續(xù)還是報錯這些不是聯(lián)調(diào)能碰出來的得專門寫用例去驗證。用這套維度自查完你會發(fā)現(xiàn)功能點全覆蓋只是一個及格線。真正的好用例是能讓這些隱形維度里的深層問題浮到水面上來的。3.2 優(yōu)先級排序高風(fēng)險、高頻次、高影響三者合一的先測用例數(shù)量永遠不可能無限膨脹所以在用例設(shè)計階段就得學(xué)會做減法。我的排序邏輯就一句話風(fēng)險高低、使用頻次、影響范圍三者綜合打分分數(shù)高的優(yōu)先級就高。這不是什么高深理論但真正落地的團隊不多。具體怎么操作我給每條用例標三個維度分每個維度1到5分風(fēng)險維度是這個功能出錯的可能性——邏輯越復(fù)雜、耦合越深、越容易出問題分越高頻次維度是用戶實際使用這個功能的頻率——高頻功能出錯影響面最大影響維度是出錯后的后果嚴重程度——數(shù)據(jù)不可恢復(fù)、資金損失、權(quán)限泄露都是5分級別的。然后計算綜合分風(fēng)險乘以頻次乘以影響或者簡單相加看你團隊習(xí)慣。分高的用例放在冒煙測試和回歸測試的核心集里分低的放在擴展回歸里。這里有個容易被忽視的tip冒煙測試用例集一定要從高優(yōu)先級用例里選而不是從功能點里平均選。因為冒煙測試的目的是用最少的時間確認系統(tǒng)沒崩只有把高風(fēng)險高頻的功能覆蓋到了這個目標才成立。4. 用例表達與文檔化字段怎么設(shè)計、步驟怎么寫才算一份能直接用的用例設(shè)計好用例思路之后表達層面的問題就來了。很多團隊用例寫了不少一執(zhí)行才發(fā)現(xiàn)前置條件沒寫清楚、測試數(shù)據(jù)沒準備好、預(yù)期結(jié)果模糊不清——執(zhí)行人員拿到用例根本沒法跑。這一節(jié)我專門聊聊怎么把腦子里想好的用例落成一份別人能直接照著執(zhí)行的文檔。4.1 用例字段設(shè)計從最小集到完整集哪些字段必不可少功能測試用例模板不同公司差別很大。有些公司一個Excel里就五六個字段用例編號、模塊、標題、步驟、預(yù)期結(jié)果。有些公司特別講究從測試環(huán)境、測試階段、前置條件、測試數(shù)據(jù)、步驟描述、預(yù)期結(jié)果、實際結(jié)果、缺陷編號、執(zhí)行人、執(zhí)行時間、備注十幾個字段一個不少。我的觀點是字段不是越多越好但有幾個字段絕對不能省。省掉那些字段用例的可執(zhí)行性和可追溯性都會大打折扣。首先是前置條件這個字段重要性極高但也是被省略得最多的。前置條件寫清楚執(zhí)行人員才知道這條用例的起點是什么——需要哪些數(shù)據(jù)已存在、哪個環(huán)境已準備好、登錄的是哪個賬號。我見過很多用例步驟第一條就寫點擊個人中心但個人中心入口在哪需要登錄嗎數(shù)據(jù)是空還是有歷史記錄全沒寫執(zhí)行人員只能靠猜。第二步測試數(shù)據(jù)字段也很關(guān)鍵。比如測試搜索功能你得寫明搜索關(guān)鍵詞是什么期望返回哪些結(jié)果測試轉(zhuǎn)賬功能你得寫明轉(zhuǎn)賬金額、賬戶余額、手續(xù)費規(guī)則。沒有明確測試數(shù)據(jù)的用例不同人執(zhí)行可能得出不同結(jié)論——你說驗證通過我說數(shù)據(jù)不對吵半天最后發(fā)現(xiàn)是各自拿的數(shù)據(jù)不一樣。第三步預(yù)期結(jié)果字段一定要寫到可觀察可判定。不要寫系統(tǒng)正常運行這種廢話要寫頁面右上角提示保存成功列表第一行顯示新記錄記錄狀態(tài)為草稿。預(yù)期結(jié)果越具體用例執(zhí)行的判定就越容易即使換一個新人來執(zhí)行也不會因為理解偏差而出錯。第四步用例編號要有規(guī)則。很多項目的用例編號就是流水號用例多了之后完全沒法追溯。我習(xí)慣的編號規(guī)則是模塊縮寫-階段-序號比如LOGIN-SM-001代表登錄模塊冒煙測試第1條、ORDER-EXT-023代表訂單模塊擴展測試第23條。這樣做的好處是從缺陷編號里直接能反查到用例編號用例編號又能定位到模塊和階段——需求變更的時候改起來也有索引可循。4.2 步驟描述操作、輸入、預(yù)期逐行對應(yīng)一段白話勝過十行術(shù)語用例步驟怎么寫我非?？粗乜蓤?zhí)行性。我見過最差的寫法是輸入正確賬號密碼點擊登錄驗證頁面跳轉(zhuǎn)?！_賬號密碼是哪個賬號哪個密碼跳轉(zhuǎn)到哪個頁面驗證什么什么都不明確。我自己的寫法偏好是每個步驟都包含三要素操作位置、操作動作、輸入數(shù)據(jù)如有。每個步驟的預(yù)期結(jié)果單獨成行緊跟其后。比如登錄用例可以這樣寫打開登錄頁訪問地址https://xxx.com/login測試環(huán)境輸入用戶名test_user01該賬號在測試庫中已存在輸入密碼Test123456點擊登錄按鈕預(yù)期結(jié)果頁面跳轉(zhuǎn)至首頁右上角顯示test_user01首頁接口請求均返回200這么寫看起來很啰嗦但一個從沒接觸過這個項目的執(zhí)行人員照著這個步驟就能完成測試。這才是用例該有的樣子——用例是給人看的執(zhí)行手冊不是給自己看的思維導(dǎo)圖。另外還有一個細節(jié)用例步驟里應(yīng)該寫數(shù)據(jù)而不是寫任意有效數(shù)據(jù)。因為任意有效不知道怎么構(gòu)造你說隨便填一個執(zhí)行的人隨手填了個123456然后發(fā)現(xiàn)報錯說密碼格式不對白白浪費時間排查是不是環(huán)境問題。4.3 從功能用例到自動化前置設(shè)計階段就要留的自動化接口隨著測試團隊逐步引入自動化比如用Playwright這套工具鏈做Web端端到端測試功能用例的設(shè)計思路也要跟著升級——最核心的變化是用例設(shè)計階段就要考慮這條用例將來能不能被自動化復(fù)用。我在日常工作中有一個習(xí)慣每寫一條手工用例都會在腦子里過一遍如果自動化來做這條用例的步驟是否可腳本化。有些用例天生適合自動化固定的操作路徑、明確的輸入輸出、確定的頁面跳轉(zhuǎn)——這些可以按Playwright的Page Object模式來拆解把頁面元素定位和業(yè)務(wù)操作封裝成Page對象用例腳本只做點擊和斷言兩層。有些用例不適合自動化需要人工視覺判斷的樣式問題、需要連第三方硬件的場景、大量隨機數(shù)據(jù)驅(qū)動的探索性測試——這些留在手工用例里更理智。所以在用例模板里我會額外加一列自動化適配性高/中/低/不適用并在步驟描述中盡量把元素的穩(wěn)定標識id、name、data-testid等記錄下來。這樣做有一個實際好處等真正開始搭自動化框架的時候你手頭已經(jīng)有一批按自動化標準組織過的用例了不用再回頭重新梳理需求。我見過太多團隊功能測試用例是一套Excel自動化腳本是另一套Script兩邊各寫各的維護成本翻倍。從一開始就在用例設(shè)計階段對齊后面能省很多事。5. 用例評審和維護好的用例是改出來的不是寫出來的用例寫完了評審做完了是不是就結(jié)束了不是。用例的生命周期是從評審會之后才開始的。我見過太多項目的用例庫版本還停留在半年之前新需求加了一堆舊用例沒刪改動的邏輯也沒同步——這樣的用例庫執(zhí)行價值接近于零。5.1 評審會看什么業(yè)務(wù)正確性、邏輯完備性、表達可執(zhí)行性用例評審這個環(huán)節(jié)不同團隊做法差別很大。有的團隊評審就是測試組自己人過一遍有的團隊會叫產(chǎn)品、開發(fā)、測試三方一起過——后者才是我覺得靠譜的做法因為三方看用例的角度完全不同三個角度合起來才能把問題暴露全。產(chǎn)品經(jīng)理看什么看用例是否真實反映了業(yè)務(wù)需求——有沒有遺漏商業(yè)規(guī)則有沒有把某種邊界情況處理得跟業(yè)務(wù)預(yù)期不符。開發(fā)人員看什么看用例是否符合系統(tǒng)實現(xiàn)——某個功能其實是調(diào)了第三方接口的你的預(yù)期結(jié)果里得體現(xiàn)異步等待某個狀態(tài)其實是定時任務(wù)刷新的你的用例步驟里得留出觸發(fā)時機。測試人員自己看什么看表達可執(zhí)行性——前置條件清不清楚測試數(shù)據(jù)有沒有給全預(yù)期結(jié)果可不可判定評審會上我最常問的三個問題是第一個這條用例的失敗怎么定義如果預(yù)期結(jié)果是頁面提示保存成功那如果頁面沒有提示但數(shù)據(jù)確實存進去了算通過還是失敗這類判定標準必須在評審時定清楚否則執(zhí)行時一定打架。第二個這個場景的數(shù)據(jù)從哪里來很多用例需要特定數(shù)據(jù)支持比如測試用戶已購買過該課程。執(zhí)行人員要去哪找這個用戶是自己注冊一個新賬號買一遍還是測試環(huán)境里已經(jīng)有預(yù)置數(shù)據(jù)評審的時候不把這個鏈路走通執(zhí)行階段就開始到處求人。第三個這條用例和那條用例之間有無依賴關(guān)系用例的執(zhí)行順序有沒有講究比如新增用戶這條必須在查詢用戶列表之前執(zhí)行。如果有依賴關(guān)系要么在用例里寫明前置用例編號要么在Excel里把用例排好序。移動端的用例尤其依賴執(zhí)行順序——你不可能在沒有安裝App的情況下測試啟動App后的閃屏頁。評審會的產(chǎn)出不只是通過不通過的結(jié)論而是一份修改意見清單。我把每個意見標記為阻塞性必須改和建議性可以不改阻塞性的比如業(yè)務(wù)規(guī)則理解錯誤、遺漏關(guān)鍵場景、測試數(shù)據(jù)不可用必須當(dāng)場改完建議性的比如步驟描述可以更精簡、字段順序調(diào)整會后統(tǒng)一處理。5.2 變更驅(qū)動的用例維護新增、修改、刪除三條線并行系統(tǒng)上線之后需求變更不可避免。每一次需求變更都是用例庫的一次手術(shù)。我建議團隊里指定一個用例庫Owner維護者每次變更走一條標準流程第一步需求變更分析。拿到變更需求后先評估影響范圍——涉及哪些模塊、哪些狀態(tài)、哪些數(shù)據(jù)規(guī)則。影響分析做得越細用例改動范圍就越準。第二步用例新增。新增的特性寫成新用例這部分邏輯跟從0到1設(shè)計用例一樣不再贅述。但要注意新增用例的編號不要插到舊編號中間去用新模塊前綴加新序號保持編號體系穩(wěn)定。第三步用例修改。這個最容易被偷懶——很多測試同學(xué)在舊用例上直接把預(yù)期結(jié)果改了也不管步驟描述、前置條件、測試數(shù)據(jù)是否需要同步調(diào)整。我見過一個經(jīng)典事故需求把注冊時手機號必填改成了注冊時手機號可選填測試同學(xué)只改了預(yù)期結(jié)果另一條卻不知道手機號必填這條用例在另外兩個模塊如忘記密碼模塊、安全設(shè)置模塊里也有同樣的斷言三個地方全要同步改——漏改的直接后果就是后面回歸測試誤報了一堆bug開發(fā)查了半天發(fā)現(xiàn)根本不存在。第四步用例刪除。刪除舊用例也是學(xué)問不要直接用物理刪除建議在用例狀態(tài)列標記為廢棄——保留可追溯性。因為出了問題要回溯時你可能需要知道當(dāng)年這個地方為什么不再測試了——可能是功能下線了也可能是策略調(diào)整了。5.3 覆蓋率評估從點數(shù)人頭到需求-用例映射最后聊聊覆蓋率這個指標。很多人一提覆蓋率第一反應(yīng)是代碼覆蓋率——行覆蓋率、分支覆蓋率多少多少。但這個對功能測試用例來說并不直接適用。功能測試用例設(shè)計更關(guān)心的是需求-用例映射覆蓋率。我的做法是每個功能需求點建立一張需求項-用例編號映射表。比如需求項用戶注冊-手機號校驗對應(yīng)用例REG-001、REG-002、REG-003需求項用戶注冊-密碼強度校驗對應(yīng)REG-004、REG-005。評審時把映射表打開從上往下逐條打勾看看哪些需求項還沒有對應(yīng)用例或者有了用例但沒覆蓋關(guān)鍵分支。這張表的維護成本不高但它的價值在于讓你的用例庫從一堆Excel變成了一張可審計的網(wǎng)絡(luò)——每一個需求點都有據(jù)可查每一條用例都有責(zé)任歸屬。這套需求-用例映射的另一個價值是在需求變更時快速定位影響面?；仡^再看5.2節(jié)說的同步修改問題如果你有映射表一條需求變更過來直接查表就知道哪些模塊下的哪些用例需要看不用靠記憶去翻Excel。到這里我把功能測試用例設(shè)計從讀懂需求到表達落地到持續(xù)維護的完整思路都過了一遍。這一套東西看著挺多但落到日常工作中核心就是一句話用例設(shè)計不是寫出來的是拆出來的——把需求拆成規(guī)則、把規(guī)則拆成路徑、把路徑拆成步驟、把步驟拆成斷言。你把這個拆字吃透了用例自然就有血有肉了。