1. 項目背景與用例設計思路1.1 幫助列表頁的業(yè)務價值與功能構成先交代一下背景。這是我們電商項目測試實戰(zhàn)系列的第六篇前面幾篇分別覆蓋了登錄注冊、商品搜索、購物車、訂單流程和支付回調(diào)這次輪到前臺幫助列表頁。單看這個頁面很多人覺得簡單——“不就是幾個常見問題加上分類嗎”但真正動手設計用例的時候就會發(fā)現(xiàn)越是這樣看似不起眼的頁面越容易在細節(jié)上翻車。幫助列表頁在電商系統(tǒng)里的定位我習慣把它歸為“用戶自助服務”的入口。用戶在購物過程中遇到問題——比如訂單怎么取消、發(fā)票怎么開、退換貨流程是什么——很多人的第一反應不是找客服而是先來幫助中心搜一下。所以這個頁面的KPI直接關聯(lián)兩個指標幫助文章點擊率和客服工單降低率。如果幫助列表的用例設計不到位導航分類亂了、搜索搜不到結果、文章詳情頁跳轉(zhuǎn)失效用戶就會產(chǎn)生挫敗感最終把壓力轉(zhuǎn)嫁給人工客服。這個頁面的功能構成拆開來看大概有這幾塊頂部搜索框、幫助分類Tab欄、常見問題列表、文章詳情頁、底部聯(lián)系客服入口以及一些輔助入口比如意見反饋、訂單售后鏈接。我們的系統(tǒng)里還加了一個“熱門問題TOP5”模塊和根據(jù)用戶最近行為推薦相關問題的邏輯。這些都是用例設計時需要覆蓋的對象。1.2 用例設計方法選型為什么不是“點點點”測試用例設計的方法論有很多等價類、邊界值、場景法、判定表但針對幫助列表頁我最終采用的是“場景法為主、等價類輔助、狀態(tài)遷移兜底”的組合方式。原因很簡單。幫助列表頁不像登錄模塊那樣有明確的輸入框規(guī)則它更偏重“用戶拿著一張頁面能完成哪些任務”。比如用戶的目標是“找到取消訂單的方法”他可能會直接在搜索框輸入“取消訂單”→看到搜索結果→點擊進入詳情頁→閱讀。也可能先看分類Tab→選擇“訂單相關”→瀏覽問題列表→找到目標問題→展開或點擊進入。這兩條路徑就是兩個核心業(yè)務場景用場景法能保證用戶的核心目標被完整覆蓋。等價類在這里主要用于搜索框的輸入劃分——關鍵詞命中的、部分命中的、完全不命中的、空搜索、特殊字符這屬于典型的輸入域劃分。狀態(tài)遷移則是用于“展開/收起”這類交互動效的測試——列表只有展開和收起兩個狀態(tài)但連續(xù)操作時狀態(tài)切換是否正確、數(shù)據(jù)是否殘留這些用狀態(tài)遷移的思路去查會更系統(tǒng)。我在給組內(nèi)新人培訓時常說的一句話是用例設計不是在計數(shù)器上湊條數(shù)而是把“用戶會怎么用”和“系統(tǒng)可能會怎么崩”這兩條線并行鋪開。幫助列表頁的用例也是這么設計的。2. 幫助列表頁功能拆解與測試維度劃分2.1 頁面模塊拆解與優(yōu)先級評估用例設計開始前先做模塊拆解確定優(yōu)先級。幫助列表頁按用戶可見程度和核心程度可以分成三個優(yōu)先級層級第一優(yōu)先級是對用戶完成任務至關重要的模塊包括分類導航、問題列表展示、搜索、文章詳情跳轉(zhuǎn)。這些模塊出問題會直接阻斷用戶獲取幫助優(yōu)先級P0。第二優(yōu)先級包括熱門推薦模塊、展開收起交互、面包屑導航、相關推薦它們影響體驗但通常不阻斷核心任務優(yōu)先級P1。第三優(yōu)先級是底部客服入口、意見反饋入口、頁面埋點統(tǒng)計這些功能通常穩(wěn)定運行回歸時覆蓋即可優(yōu)先級P2。這個優(yōu)先級劃分直接影響排期和用例數(shù)量分配。我見過有的測試同事把精力平均分配在“意見反饋彈窗的提示文案”上花大篇幅設計結果搜索空結果頁的兼容性缺陷在線上被用戶投訴這就是優(yōu)先級沒拉齊的典型情況。2.2 測試維度矩陣功能、交互、兼容、數(shù)據(jù)、異常幫助列表頁的測試維度我習慣用下面這個矩陣來梳理每條用例都可以歸入其中防止漏測測試維度覆蓋重點典型用例示例功能維度分類切換、列表展示、搜索邏輯、詳情跳轉(zhuǎn)切換到“售后政策”分類驗證列表刷新正確交互維度展開/收起、加載更多、返回行為、Toast反饋點擊“展開”后再次點擊“收起”驗證狀態(tài)正確兼容維度瀏覽器、移動端、分辨率、微信內(nèi)置瀏覽器Chrome與Safari下列表樣式一致數(shù)據(jù)維度分類為空、超長標題、特殊字符、富文本內(nèi)容標題含emoji時列表渲染是否正常異常維度接口超時、接口返回500、空數(shù)據(jù)、斷網(wǎng)重連列表接口超時后是否顯示兜底提示功能維度是主體交互維度最容易漏兼容維度依賴真實環(huán)境測試數(shù)據(jù)維度要提前構造數(shù)據(jù)異常維度一般配合Mock工具來做。這里要給新手一個建議測試維度矩陣最好在用例設計階段就畫出來而不是等到測試執(zhí)行時拍腦袋想。矩陣的價值在于它可以當作“查漏清單”——當你覺得用例設計得差不多了拿維度矩陣逐項對比往往能發(fā)現(xiàn)漏掉的方向。3. 核心用例設計實操分模塊逐步拆解3.1 列表展示與分類切換場景列表展示是幫助列表頁的最核心場景。我們系統(tǒng)的幫助列表頁首次進入時默認展示“全部”分類下的問題列表按后臺配置的問題排序字段排列。在此基礎上我設計了以下用例默認狀態(tài)驗證首次進入頁面斷言默認選中“全部”Tab、列表按配置順序展示、問題標題正確、每條問題前有類型圖標。這里要注意斷言不能只看標題字段還要檢查排序字段——我們之前就遇到過后臺改了排序權重前端沒有重新拉取數(shù)據(jù)導致線上頁面仍然是舊排序的缺陷。分類切換驗證分別點擊“訂單相關”“支付問題”“售后政策”等分類Tab驗證列表刷新、無數(shù)據(jù)殘留、分類選中態(tài)正確。這里補充一個細節(jié)分類切換后頁面是否回頂部、滾動位置是否重置、列表是否有加載動畫這些交互細節(jié)如果不加用例后續(xù)很容易被開發(fā)忽略。對于分類數(shù)量還要覆蓋“分類為空”的情況——比如某個新分類還沒有配置文章。正確的預期是顯示空狀態(tài)提示“暫無相關問題”而不是白屏或一直轉(zhuǎn)圈。這類空狀態(tài)用例往往是最容易被遺漏的。熱門問題模塊的驗證進入頁面時熱門問題按點擊量降序排列點擊某個熱門問題后排序可能會更新——刷新頁面后該問題排名提升。這里需要關注的是排序更新的時機是實時還是定時需要和產(chǎn)品確認否則用例預期會寫錯。3.2 搜索功能場景與關鍵詞命中規(guī)則搜索框是幫助列表頁的“第二入口”也是用例設計里最需要花心思的地方。我們的搜索邏輯走的是標題模糊匹配不匹配正文內(nèi)容所以用例設計時要圍繞這個規(guī)則來。從等價類劃分的角度搜索輸入可以這樣拆精確命中輸入“取消訂單”能搜出標題包含“取消訂單”的文章部分命中輸入“取消”能搜出標題中包含“取消”的所有相關文章無結果輸入“怎么開發(fā)票”如果沒有任何標題包含該關鍵詞預期顯示空結果頁空搜索不輸入內(nèi)容直接點擊搜索預期不發(fā)起請求或提示“請輸入關鍵詞”特殊字符輸入“%#”等符號預期無異常、無報錯這里需要特別強調(diào)的是“部分命中”的排序規(guī)則。用戶搜索“退款”返回列表里既有標題精確包含“退款”的文章也有標題包含“退款政策”“退款時效”的文章哪個排前面這是產(chǎn)品策略問題測試必須把預期弄清楚再寫用例。我們的規(guī)則是精確匹配優(yōu)先其次按標題命中位置靠前優(yōu)先最后按點擊量倒序。用例里要構造三條數(shù)據(jù)來驗證這個排序邏輯是否真正生效。搜索還有一個容易被忽略的點——搜索歷史。有些系統(tǒng)會記錄用戶搜索關鍵詞展示在下拉列表里。如果幫助列表頁有搜索歷史功能就要補充歷史記錄是否按時間倒序、刪除單條后是否消失、清空歷史后是否展示空狀態(tài)、最多展示幾條。我們的系統(tǒng)第一版沒有這個功能后來加了之后漏測了“清空歷史后再次進入搜索框下拉列表仍顯示舊數(shù)據(jù)”的緩存缺陷。3.3 展開收起與加載更多交互狀態(tài)幫助列表頁有兩種常見的信息展示方式我們系統(tǒng)兩種都用了。第一種是列表頁直接展示問題標題點擊進入詳情第二種是部分模塊比如“常見問題TOP5”在列表內(nèi)展開收起。展開收起看著簡單但坑不少。用例要覆蓋這些場景單條展開時其他條目是否自動收起。我們第一版的設計是允許同時展開多條后來產(chǎn)品改成手風琴模式即同一時間只能展開一條。這個變更如果前端沒有全局控制就會出現(xiàn)兩條同時展開、界面錯亂的缺陷?？焖龠B續(xù)點擊同一條的“展開/收起”按鈕狀態(tài)是否穩(wěn)定。這屬于狀態(tài)遷移測試的范疇連續(xù)點擊會產(chǎn)生異步請求或過渡態(tài)動畫容易導致卡死或狀態(tài)翻轉(zhuǎn)異常。展開后內(nèi)容區(qū)域的數(shù)據(jù)完整性。展開的內(nèi)容如果是異步加載的要驗證加載成功、加載失敗、加載中三種狀態(tài)如果是頁面內(nèi)靜態(tài)展示的要驗證富文本樣式正確、圖片不拉伸、超長內(nèi)容不撐破布局。加載更多的邏輯也值得單獨寫用例。列表第一屏展示10條點擊“加載更多”追加10條要驗證點擊后是否記錄上一頁的索引不能重復加載同一頁、所有數(shù)據(jù)加載完后按鈕是否隱藏或變?yōu)椤皼]有更多了”、加載更多過程中重復點擊是否導致重復請求。我們系統(tǒng)被投訴過點擊加載更多后出現(xiàn)重復數(shù)據(jù)原因是前端沒有做請求去重后端也沒有做分頁偏移校驗——這個缺陷在用例評審階段如果多想一步就能提前發(fā)現(xiàn)。3.4 接口異常與容錯處理場景異常場景是幫助列表頁用例設計里最考驗功力的一部分。正常功能開發(fā)完大家都會測但接口超時、服務端報錯這些情況往往被“功能正常”的慣性思維所掩蓋。需要覆蓋的異常場景至少包括以下幾類首屏列表接口返回500頁面應展示兜底狀態(tài)如“頁面加載失敗請重試”點擊重試后能正常恢復。這里要注意重試按鈕的點擊區(qū)域是否夠大、文案是否明確。首屏列表接口超時如超過10秒未返回頁面不能一直停留在Loading狀態(tài)應提示超時并提供重試入口。這個場景可以用Mock工具將接口響應時間拉長來模擬注意區(qū)分“超時”和“接口慢但最終返回成功”兩種表現(xiàn)。分頁加載接口失敗已加載的第一屏數(shù)據(jù)應保留頁面不能變成空白同時提示“加載失敗點擊重試”。這里有一個容易漏的斷言點——失敗后點擊重試分頁索引不能從頭開始否則會把第一屏數(shù)據(jù)重復加載一遍。搜索接口異常應保留當前列表數(shù)據(jù)同時Toast提示“搜索失敗請稍后重試”。不能把列表清空成白色頁面。我就曾遇到過搜索失敗后列表數(shù)據(jù)被清掉的情況對用戶體驗傷害很大。斷網(wǎng)狀態(tài)下進入幫助列表頁應顯示無網(wǎng)絡提示恢復網(wǎng)絡后點擊重試頁面能正常加載。這個場景在移動端尤其重要我們的H5版本在弱網(wǎng)環(huán)境下還出現(xiàn)過圖片加載不完整的缺陷。這里想強調(diào)的是接口異常用例不能只寫在用例文檔里執(zhí)行時一定用真實模擬手段去驗證而不是靠眼睛看。我一般用Charles或Mock工具改請求響應把返回碼改成500、把響應時間拉長到15秒逐項驗證頁面的真實表現(xiàn)。4. 幫助列表頁專項檢查清單與高頻缺陷4.1 高頻缺陷類型與復現(xiàn)場景幫助列表頁的功能雖然不復雜但上線后反饋的缺陷也有一定規(guī)律。我整理了這幾類高頻問題供大家設計用例和回歸時參考第一類分類切換時數(shù)據(jù)殘留。從“訂單相關”切換到“售后政策”后新列表尾部偶爾會帶出幾條舊分類的數(shù)據(jù)。復現(xiàn)路徑一般是快速連續(xù)切換多個分類前一次請求還沒返回后一次請求已經(jīng)把列表數(shù)據(jù)填充了響應后又被舊數(shù)據(jù)覆蓋——典型的競態(tài)條件問題。用例設計時要覆蓋“快速切換分類”這個操作。第二類搜索命中規(guī)則與產(chǎn)品預期不符。產(chǎn)品經(jīng)理認為搜“退”應該出現(xiàn)所有標題含“退”的文章開發(fā)實現(xiàn)的是前綴匹配導致“撤單”這類不含“退”前綴但語義相關的文章搜不出來。這種缺陷靠功能測試很難發(fā)現(xiàn)需要在用例設計前跟產(chǎn)品把規(guī)則確認清楚。第三類詳情頁返回后列表狀態(tài)丟失。用戶從幫助列表點擊進入文章詳情閱讀后返回期望回到原來的滾動位置和之前選中的分類。如果頁面刷新重載了用戶就要重新找一遍體驗很差。這類“狀態(tài)保持”的用例在移動端Webview里尤其值得重視。第四類富文本內(nèi)容樣式錯亂。幫助文章的內(nèi)容是運營在后臺用富文本編輯器維護的圖片寬度超出屏幕、代碼塊換行錯誤、表格撐破布局這些問題在列表頁用例里看起來無關但在詳情頁用例里是重災區(qū)。設計詳情頁用例時要專門構造包含圖片、表格、代碼塊、超長單詞的文章內(nèi)容來驗證樣式。4.2 兼容性與弱網(wǎng)專項檢查兼容性方面幫助列表頁作為電商系統(tǒng)的前臺頁面用戶環(huán)境非常分散需要按操作系統(tǒng)、瀏覽器、屏幕尺寸三個維度交叉覆蓋。我們項目的標準覆蓋矩陣是Chrome最新版、Firefox最新版、Safari最新版、Edge最新版、微信內(nèi)置瀏覽器、以及iOS/Android各自近三個大版本的移動端瀏覽器。實際執(zhí)行中我發(fā)現(xiàn)列表頁在桌面端瀏覽器最容易出現(xiàn)的問題是分類Tab在頁面縮小時的換行錯亂和橫向滾動。移動端最常見的問題是安全區(qū)適配——底部聯(lián)系客服入口在帶Home Indicator的iPhone機型上會被遮擋。這些都需要真機或模擬器實測不建議只在開發(fā)者工具的設備模擬模式下看完就收工。弱網(wǎng)場景我單獨拿出來說因為幫助列表頁有一個特殊點幫助文章的正文往往是圖文混排的長內(nèi)容在弱網(wǎng)環(huán)境下圖片加載會非常慢頁面可能長時間處于白屏狀態(tài)。另一個處理方案是圖片懶加載——滾動到圖片附近才加載配合骨架屏方案使用。測試時需要用工具將網(wǎng)絡限速到弱網(wǎng)環(huán)境驗證圖片懶加載是否生效、圖片是否有邊加載邊顯示的效果、快速滾動時是否會觸發(fā)大量圖片請求導致頁面卡頓。4.3 專項數(shù)據(jù)準備與后臺配置核對幫助列表頁的測試前臺頁面的操作只是一半功夫后臺數(shù)據(jù)配置的核對是另一半。很多缺陷的根因不在前端代碼而在后臺配置數(shù)據(jù)不規(guī)范。我建議在測試環(huán)境準備這樣一套基礎數(shù)據(jù)五個以上正常分類每個分類下五條以上正常文章其中至少一個分類只有一條文章至少一個分類完全沒有文章準備若干條超長標題超過50個漢字、包含特殊符號的標題、包含emoji的標題準備至少一篇文章正文包含大圖、多圖、表格和超長代碼塊。這套數(shù)據(jù)準備齊了功能、兼容、數(shù)據(jù)維度的用例基本都能跑起來。這里還涉及一個很容易被忽略的點幫助文章的發(fā)布時間在后臺配置為“未來時間”時前臺展示是否符合預期——我們的產(chǎn)品規(guī)則是未來發(fā)布的文章不展示在列表中但測試環(huán)境數(shù)據(jù)如果沒注意發(fā)布時間很容易出現(xiàn)“后臺配了文章但前臺看不到”的困惑。用例設計時把這種數(shù)據(jù)狀態(tài)當成一個明確場景來寫能節(jié)省不少排查時間。5. 用例評審與落地執(zhí)行心得5.1 用例評審時最容易出現(xiàn)的爭議點用例寫完后評審環(huán)節(jié)能暴露很多問題。幫助列表頁的用例評審我總結出幾個高頻爭議點搜索規(guī)則的預期不明確這是最經(jīng)典的爭議。產(chǎn)品說“支持模糊搜索”開發(fā)實現(xiàn)的是“標題前綴匹配”測試用例里寫的是“輸入關鍵詞能搜到相關文章”。三方對“模糊”的理解完全不同評審時必須拉著產(chǎn)品當場用真實數(shù)據(jù)跑一遍把搜什么、出來什么、排什么序當場定下來。不要試圖在用例文檔里用文字把這個規(guī)則描述清楚因為文字永遠有多義性。空狀態(tài)的文案和表現(xiàn)形式也是容易被討論的地方。列表為空時是顯示“暫無數(shù)據(jù)”還是“暫無相關問題”是給一個空插畫還是純文字要不要給“去逛逛”按鈕。這些細節(jié)看似不重要但影響開發(fā)實現(xiàn)和UI走查評審時最好連文案都確認死。分頁規(guī)則的邊界“加載更多”翻了十頁之后還要不要繼續(xù)滑動加載有沒有上限“全部”分類的文章列表數(shù)量遠超單分類時分頁參數(shù)是否一致。這些問題如果沒有產(chǎn)品確認開發(fā)就會按自己的理解實現(xiàn)測試也只能按開發(fā)實現(xiàn)去寫預期最后用戶遇到真實問題時才發(fā)現(xiàn)體驗不對。5.2 用例執(zhí)行時的數(shù)據(jù)構造與回歸策略用例執(zhí)行階段我的建議是先用接口工具直接構造數(shù)據(jù)再用頁面操作去驗證。比如要驗證“分類為空”的場景不需要真的去后臺把分類刪掉或清空文章直接用Mock工具把列表接口的響應改為返回空的分類數(shù)據(jù)即可。用接口Mock配合頁面斷言比每次手動改后臺數(shù)據(jù)要高效得多而且可重復執(zhí)行。回歸策略上幫助列表頁的用例適合在兩個時間節(jié)點重點回歸一是后臺幫助內(nèi)容管理模塊的功能改動因為內(nèi)容管理改了數(shù)據(jù)結構前臺展示頁面極可能受影響二是全站彈窗、公告、浮層等公共組件改動時幫助列表頁作為常駐頁面也需要回歸一遍重點確認彈窗是否遮擋列表操作、是否存在頁面層級錯亂。另外建議把幫助列表頁的冒煙用例控制在20條以內(nèi)選最核心的默認列表展示、分類切換、搜索、詳情跳轉(zhuǎn)、空狀態(tài)提示、接口異常兜底。這些用例每晚在CI環(huán)境跑一遍比等版本發(fā)布前大回歸要穩(wěn)得多。我們在實踐中把這幾條用例做成了自動化腳本后幫助列表頁的線上故障率有了明顯下降。5.3 補充幾個容易被忽視的細節(jié)最后再分享幾個我在項目實戰(zhàn)中踩過的細節(jié)坑這些不大不小但都真實影響過線上體驗。第一個是面包屑導航。幫助列表頁從首頁進入點擊一個三級分類后頁面頂部出現(xiàn)了面包屑“首頁 幫助中心 售后政策”但點擊“首頁”跳轉(zhuǎn)的是幫助中心首頁而不是真正的商城首頁——開發(fā)把面包屑的層級關系搞錯了。這種功能很輕但用戶一旦點出問題就會覺得系統(tǒng)“不靠譜”。第二個是頁面標題。幫助列表頁在瀏覽器標簽頁上顯示的是默認的“幫助中心”進入具體文章詳情后標簽頁標題變成了“詳情頁”瀏覽器后退時標簽頁標題又變回“幫助中心”。比較細的用戶會注意到標題的切換這也是體驗的一部分。用例里至少要有斷言頁面標題屬于預期值。第三個是數(shù)據(jù)埋點。幫助列表頁是分析用戶求助路徑的重要頁面“搜索”事件、“分類點擊”事件、“文章點擊”事件都需要精確上報。測試時如果只關注頁面表現(xiàn)很容易漏掉埋點驗證。至少要確認這幾個核心事件有上報、參數(shù)正確、連續(xù)點擊時事件不丟失。寫在最后幫助列表頁的用例設計說到底是“把用戶當普通人來對待”的過程。用戶不會按用例設計者的思路去操作他們會帶著情緒、急躁、誤操作所以你的用例要覆蓋正常路徑也要覆蓋那些“看起來不太可能發(fā)生”的操作——快速連點、弱網(wǎng)、分類一直切換、搜亂七八糟的關鍵詞。把這些場景想到了、測透了幫助列表頁才能真正常穩(wěn)。我個人在實際項目里的體會是幫助列表頁的用例設計能力某種程度上也反映了測試人員對“用戶自助體驗”的理解深度。把這類基礎頁面測精了后面再去碰訂單、支付這類復雜流程很多方法論是通用的。這篇分享如果對正在做電商項目測試的你有幫助哪怕里面某一節(jié)直接幫你堵住了一個線上漏測點我就覺得值得了。