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