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