做電商項目測試做到第七篇前面幾篇我們依次聊過商城框架、搜索、商品詳情、購物車和訂單流程今天把目光收回到類目頁里比較特殊的一塊——化妝品頁面用例設計。這個類目不像手機殼、紙巾那樣“標品化”它有大量需要測的屬性篩選、規(guī)格組合、合規(guī)字段和內(nèi)容審核位如果只按普通列表頁去設計用例上線后大概率會在一些意想不到的地方翻車。這篇文章我打算把自己實際做過的電商項目中化妝品類目頁從列表、詳情、加購到下單涉及的用例設計思路完整捋一遍覆蓋篩選組合、SKU切換、合規(guī)字段、交互異常、數(shù)據(jù)埋點和回歸策略拿過去就能直接用。1. 化妝品類目頁的業(yè)務特殊性決定測試設計起點很多測試同學接手電商類目頁時第一反應是打開頁面照著功能點一條條列用例。這個做法放在化妝品頁面上容易失控因為這個類目的信息架構(gòu)和普通標品差別太大理解不透業(yè)務就看不到風險點。我建議先花半天時間把類目頁的業(yè)務特殊性梳理清楚再動手設計用例。1.1 化妝品信息架構(gòu)和普通標品最大的三個差異第一個差異是多維屬性篩選。手機殼的篩選項通常只有品牌、價格、適用型號撐死了加一個顏色但化妝品類目的篩選項能鋪滿兩屏橫向滾動都翻不完品牌、價格區(qū)間、功效保濕/美白/抗皺/舒緩/修護、膚質(zhì)油性/干性/混合性/敏感肌、適用人群通用/男士/孕婦、質(zhì)地水/乳/霜/精華/面膜、是否特殊化妝品祛斑美白、防曬、染發(fā)等。這些篩選項不是前端寫死的而是運營在后臺類目樹上動態(tài)配置的。這意味著用例設計不能只看接口參數(shù)還要回到類目樹配置本身每加一個篩選維度列表頁的請求參數(shù)、返回字段、空態(tài)文案、篩選高亮狀態(tài)的組合復雜度就成倍增長。第二個差異是SKU維度的數(shù)量級。一個手機殼通常就一個SKU最多分個顏色但護膚品有容量、套裝、版本滋潤版/清爽版彩妝有色號洗發(fā)水有功能型組合一套下來詳情頁的規(guī)格可能有三到四層。測試時不僅要對SKU切換后的價格、庫存、圖片做校驗還得考慮當前選中的規(guī)格組合在深鏈接、分享、購物車回顯時的正確性。這個復雜度意味著SKU相關(guān)的用例不能只放在詳情頁模塊必須跨模塊設計。第三個差異是合規(guī)字段多且敏感?；瘖y品頁面必須展示備案編號普通化妝品備案或注冊編號特殊化妝品標注生產(chǎn)許可證號、生產(chǎn)企業(yè)信息進口品還要有中文標簽和檢驗檢疫信息。頁面上如果漏展示、展示錯誤輕則被平臺處罰重則影響品牌方資質(zhì)審核。這類字段的校驗通常沒有復雜邏輯但需要專門的核對用例并且每次內(nèi)容更新后要回歸。我在做項目時就遇到過詳情頁只展示備案號但漏了生產(chǎn)許可證號的情況這種問題靠功能測試的正常路徑根本發(fā)現(xiàn)不了必須有一張專門的合規(guī)字段核對清單。1.2 從用戶路徑梳理用例落點頁面用例設計如果一上來就盯著列表頁表格填充很容易漏掉上下文。我更習慣先把用戶路徑畫出來再在每條路徑上找異常分支。路徑分為四條主流線被動瀏覽線首頁/活動Banner → 化妝品類目Tab → 列表頁 → 點擊商品進入詳情。主動檢索線搜索框 → 關(guān)鍵詞聯(lián)想 → 搜索結(jié)果列表 → 篩選/排序 → 詳情。直接訪問線從分享鏈接、收藏夾、購物車回跳進入詳情頁。決策轉(zhuǎn)化線詳情 → 查看圖文/評價 → 選擇規(guī)格 → 加購 → 購物車 → 結(jié)算。每條路徑拆出來的用例側(cè)重點完全不同被動瀏覽線關(guān)注類目Tab的入口有效性、首屏數(shù)據(jù)量和曝光位主動檢索線關(guān)注篩選條件組合、關(guān)鍵詞高亮、排序穩(wěn)定性直接訪問線關(guān)注URL參數(shù)缺失時的兜底、非法ID、已失效商品決策轉(zhuǎn)化線關(guān)注SKU選擇、庫存聯(lián)動和加購成功狀態(tài)。實際設計用例時我會把這些路徑整理成矩陣每條路徑至少覆蓋一個正常用例和兩個異常用例再把跨路徑共用的業(yè)務規(guī)則單獨抽出來做數(shù)據(jù)驅(qū)動。這個思路也決定了用例組織形式不要只按頁面分模塊而要按“路徑頁面”交叉分模塊這樣執(zhí)行時更容易發(fā)現(xiàn)問題歸屬評審時也方便讓產(chǎn)品經(jīng)理快速理解覆蓋范圍。2. 列表頁核心用例篩選、搜索、排序與分頁的邏輯組合列表頁是整個類目頁的流量入口大部分功能用例都集中在這里。但這個區(qū)域的用例設計有一個陷阱就是很容易從“功能點”出發(fā)而不是從“邏輯組合”出發(fā)。篩選、排序、分頁單獨測都正常一旦組合起來就出現(xiàn)各種邊界問題。2.1 多維度篩選的組合測試矩陣怎么搭化妝品列表頁最典型的形態(tài)是頂部Tab綜合/銷量/新品/價格 左側(cè)分類樹或底部彈出篩選面板。篩選維度多到一定程度手動窮舉所有組合很快就不現(xiàn)實——5個維度各3個選項全組合是243種全部測完不現(xiàn)實也沒有必要。我的做法分兩步第一步每個維度單獨驗證。品牌選一個、功效選一個、價格區(qū)間選一個分別斷言列表返回結(jié)果中對應字段全部符合條件。比如選了“保濕”功效結(jié)果列表里所有商品的功效標簽都必須包含“保濕”選了“0-100元”所有展示價格都應該在區(qū)間內(nèi)。價格邊界需要專門驗證——剛好等于100元是否包含后端用的是閉區(qū)間還是開區(qū)間這里最容易出隱性Bug我就在一個項目里遇到過“小于等于價格上限”和“小于價格上限”的字段錯位導致價格正好等于100元的商品漏展示。第二步跨維度正交組合。重點不是把所有組合跑一遍而是優(yōu)先覆蓋高風險組合一個是“必然為空”的組合比如價格區(qū)間0-50元 敏感肌 高端品牌這種組合結(jié)果為空必須驗證空態(tài)文案和推薦位另一個是“可能沖突”的組合比如“防曬 油皮 男士”結(jié)果可能很少但系統(tǒng)要能正常展示。執(zhí)行時可以用正交表或Pairwise工具生成一組有代表性的組合然后重點驗證組合后列表是否重置、篩選條件是否保留、返回上一級時篩選狀態(tài)是否存在。這里有一個經(jīng)常被忽視的點篩選條件與URL參數(shù)之間的關(guān)系。很多電商列表頁支持分享用戶篩好了條件分享給朋友對方打開鏈接還要能看到同樣的篩選結(jié)果。用例必須覆蓋URL參數(shù)拼接、非法參數(shù)值例如功效abc、價格abc、缺失參數(shù)三種場景我見過線上因為分享鏈接少拼了一個篩選參數(shù)導致用戶看到的是未篩選的全量列表這個問題直到埋點數(shù)據(jù)出現(xiàn)異常才被發(fā)現(xiàn)。2.2 排序和分頁里容易被漏掉的場景排序不是簡單的“點了按價格升序就按價格升序”。電商頁面的排序往往是多個因素疊加綜合排序可能包含銷量、好評率、運營加權(quán)新品排序不是單純的上架時間而是有一個“新品定義窗口”銷量排序在不同篩選條件下取的口徑也可能不同。測試用例至少要有以下幾類切換排序維度后列表內(nèi)容順序要變化且符合規(guī)則比如價格升序時列表價格必須單調(diào)遞增。篩選和排序同時存在時改篩選不改變當前選中的排序方式但排序結(jié)果要基于新的篩選結(jié)果計算。排序穩(wěn)定性也叫“同序值穩(wěn)定性”。兩個商品價格都是59元時用戶刷新后相對順序不能亂跳否則會覺得頁面閃了一下體驗極差。分頁邊界每頁數(shù)量比如20個的最后一頁不滿20個正好20個時下一頁是否有空頁快速滑到底時重復觸發(fā)加載更多是否會重復請求或數(shù)據(jù)重復。位置記憶用戶從列表第3頁進入詳情再返回應該回到第3頁而不是回到第1頁返回后篩選條件、搜索關(guān)鍵詞、滾動位置盡量保留。我自己踩過的坑是分頁時的“商品失效與動態(tài)排序沖突”。商品因為庫存不足在列表中被標記為已失效此時用戶繼續(xù)往下翻因為列表數(shù)據(jù)數(shù)量發(fā)生變化后端可能返回重復商品或直接翻不動頁。這類問題排查半天往往不是算法問題而是前端對列表數(shù)據(jù)的處理方式——沒有根據(jù)商品ID做去重。用例設計時建議專門設計“翻頁過程中商品狀態(tài)變化”的場景讓前端和后端提前約定好增刪邏輯。2.3 搜索聯(lián)想與無結(jié)果態(tài)的細節(jié)化妝品頁面的搜索雖然入口在類目頁外面但對類目頁的測試影響很大因為用戶進列表頁之后大概率還是要搜一下。搜索聯(lián)想需要覆蓋品牌詞、功效詞、成分詞如煙酰胺、玻尿酸這類成分名、品類詞如口紅、面膜。聯(lián)想詞高亮、點擊聯(lián)想詞后跳轉(zhuǎn)列表并攜帶篩選條件這些都要單獨跑。尤其要注意同音詞、拼音、繁體中文的處理策略——不同項目要求可能不一樣但用例里必須明確一版口徑否則測試、開發(fā)、產(chǎn)品各說各話。無結(jié)果態(tài)也值得細測。搜索“某個新銳品牌”時健康態(tài)可能沒有結(jié)果這時頁面應該給出“沒有找到相關(guān)商品”的文案同時帶一些兜底推薦比如熱門搜索、同類商品。我見過有的頁面無結(jié)果時只給文案沒有推薦位導致用戶直接流失也見過頁面兜底推薦的商品和搜索詞毫無相關(guān)性搜“眼霜”推“紙尿褲”這種低級問題必須用用例明確約束。測試時還建議把搜索詞本身的各種特殊字符跑一遍純空格、超長字符、表情符號、SQL注入類字符驗證頁面不報錯且正常展示空態(tài)。下面這張表我執(zhí)行回歸時常用按表掃一遍能保證列表頁核心邏輯不漏用例維度關(guān)鍵場景容易遺漏的點篩選單選、多選、清空、組合空態(tài)、價格邊界、URL參數(shù)校驗排序切換、穩(wěn)定、與篩選疊加同價格相對順序、刷新不亂跳分頁加載更多、返回位置商品失效導致的跨頁重復搜索聯(lián)想、跳轉(zhuǎn)、無結(jié)果拼音/繁體口徑、兜底推薦相關(guān)性3. 商品詳情頁用例規(guī)格、成分、合規(guī)字段一個都不能少列表頁把用戶引進來詳情頁才是真正影響轉(zhuǎn)化率的地方?；瘖y品詳情頁的用例量級遠大于普通標品其中SKU切換、成分展示、合規(guī)字段這三塊是最容易出問題的。3.1 SKU 規(guī)格切換的完整校驗鏈化妝品SKU少的也有兩三層容量30ml/50ml/100ml、版本清爽型/滋潤型、套裝單支/兩件套/加贈小樣。每一層切換都要校驗以下內(nèi)容標題中的規(guī)格名跟著變比如“XX面霜 50ml”和“XX面霜 30ml”不能混。主圖、詳情圖跟著變。有些項目是同一套圖有些項目是不同SKU配不同主圖必須人工確認“選50ml時主圖是不是50ml的”這個點自動化很難直接判斷建議用視覺對比輔助。價格、劃線價、促銷標簽跟著變。切換規(guī)格后促銷標簽沒有更新的情況很常見比如從參與滿減的50ml切到不參與滿減的30ml標簽還在顯示“滿199減30”。庫存數(shù)字跟著變已售數(shù)量口徑如果頁面上有展示也要跟著變。加購按鈕狀態(tài)當前規(guī)格庫存為0時置灰并提示“已售罄”而不是允許加入購物車后在購物車里再報錯。默認選中態(tài)進入頁面時默認選中哪個SKU通常是銷量最高或運營配置的那個需要和產(chǎn)品經(jīng)理確認口徑。特別提醒一個場景SKU之間的組合可用性。假設面霜有三個容量但30ml和50ml又分別對應不同的版本后端配置SKU時不是所有組合都存在。前端切換到不存在的組合時頁面必須自動把不可選規(guī)格置灰或提示“該組合暫不可售”不能讓用戶選中后提交不了。建議專門構(gòu)造一張SKU組合合法表把后端返回的SKU矩陣和頁面置灰邏輯一一對照這一步能提前發(fā)現(xiàn)大量規(guī)格搭配問題。第二個提醒是SKU記憶。用戶選了50ml后退出詳情再回來甚至從購物車回跳詳情選中的規(guī)格要能正確回顯。這類用例要放在跨頁面回歸里不能只在詳情頁單測。3.2 成分表和功效宣稱的展示規(guī)則成分表現(xiàn)在是化妝品詳情頁的標配很多平臺會直接展示完整成分列表并按含量降序排列。測試關(guān)注的點包括成分列表的順序邏輯成分含量從高到低前端拿到的順序是否正確有沒有亂序。高風險成分提示像香精、酒精、部分防腐劑如果平臺做了風險成分標注用例要驗證標注口徑和提示文案是否準確。成分搜索詳情頁是否支持成分搜索比如用戶搜煙酰胺能跳到備案成分含該成分的商品。展示完整性成分表必須能拉到底長文本不截斷沒有亂碼特殊字符括號、下標、斜杠顯示正常。功效宣稱和詳情圖文的一致性詳情圖說“敏感肌可用”評價區(qū)和成分表里卻有高風險成分這個不完全等于功能Bug但測試人員應該在用例評審時提出核對規(guī)則。這里有一個容易被忽略的思路功效宣稱的測試不能只看前端文案。很多電商后臺會配置不同的功效標簽詳情頁顯示的保濕、修護、美白標簽是從運營屬性里透出的。測試時準備一批不同功效標簽的商品逐一核對詳情頁是否與后臺配置一致尤其是特殊化妝品祛斑美白、防曬、染發(fā)、燙發(fā)等的標簽這類宣稱受監(jiān)管要求更嚴格標簽配置錯了直接影響審核結(jié)果。我建議在用例里專門加一條“功效標簽與后臺屬性一致性抽檢”的用例而不是把所有希望寄托在內(nèi)容審核環(huán)節(jié)。提示成分表和功效標簽屬于“內(nèi)容屬性”而非“頁面功能”很容易被當成純文案漏測。請務必在用例類型里單獨標記為高優(yōu)先級內(nèi)容校驗項。3.3 合規(guī)信息字段的專項核對合規(guī)字段的核對屬于“不做則已一做就要做全套”的用例。給化妝品詳情頁建一個合規(guī)字段模板至少包含以下字段的展示驗證備案編號/注冊編號普通化妝品的備案編號和特殊化妝品的注冊編號格式不同需要按規(guī)則校驗。生產(chǎn)企業(yè)名稱、生產(chǎn)地址、生產(chǎn)許可證編號。進口化妝品的中文標簽信息、境外生產(chǎn)企業(yè)信息。保質(zhì)期、生產(chǎn)日期、限期使用日期。使用方法、注意事項、警示語如“避免接觸眼睛”“使用前請測試”。具體用例要覆蓋字段齊全性、字段內(nèi)容與后臺配置的一致性、字段展示樣式換行、截斷、鏈接跳轉(zhuǎn)。同時建議做一次信息完整性抽檢隨機挑選若干商品人工去后臺核對一遍詳情頁展示的所有合規(guī)字段而不是只看前端模板。我記得有一次版本迭代中詳情頁模板被改造開發(fā)只遷移了主圖和價格字段合規(guī)字段的樣式錯位線上出現(xiàn)“備案編號字體小到看不清”的投訴就是因為測試時只校驗了字段存在沒有校驗樣式可讀性。這一節(jié)很重要因為合規(guī)問題不是功能Bug是運營風險。測試人員在用例設計時主動把這塊納入范圍價值會遠遠高于一個普通的按鈕測試。4. 購物車、下單與優(yōu)惠互動的集成用例詳情頁測試完整了接著就要驗證“加購”這個動作是否把信息正確傳遞到下個環(huán)節(jié)。化妝品類目的購物車和訂單測試有一個特點促銷規(guī)則多、套裝多、贈品多集成用例設計不好就會漏掉關(guān)鍵的聯(lián)動場景。4.1 從詳情頁到購物車的全鏈路校驗加購用例看著簡單實際容易出錯加購成功后購物車中商品名稱、規(guī)格名容量/色號、圖片、單價和詳情頁是否一致。商品加購前失效詳情頁剛打開時還有貨等用戶選好規(guī)格點加購時已經(jīng)下架系統(tǒng)應提示“商品已下架”而不是把失效商品塞進購物車。重復加購同一商品同一SKU連續(xù)加購購物車是合并數(shù)量還是新增一條記錄不同項目策略不同用例要按產(chǎn)品定義執(zhí)行。購物車中修改規(guī)格化妝品常見升級容量、換色號的操作修改后價格、庫存、優(yōu)惠計算必須聯(lián)動。購物車中的失效商品特價活動結(jié)束、商品售罄后購物車項應標記失效失效項不能參與全選、不能結(jié)算還要有單獨清除入口。這些用例如果在功能測試階段沒覆蓋到聯(lián)調(diào)階段再發(fā)現(xiàn)問題排查成本會高很多。尤其是“購物車中修改規(guī)格”這條前端回傳的SKU ID如果出錯訂單里的商品規(guī)格和價格對不上客服后臺看到的信息完全錯誤是一類線上高危問題。4.2 化妝品訂單的典型價格計算場景化妝品類目是平臺促銷活動的主戰(zhàn)場滿減、折扣、贈品、會員價、套裝優(yōu)惠疊加在一起價格計算很容易出問題。設計訂單價格用例時我會圍繞三條主線單品折扣促銷價、閃購價、會員價三者的優(yōu)先級如何頁面只顯示一個價格但后臺計算時要判斷多個規(guī)則。用例要構(gòu)造同一商品在不同狀態(tài)下會員/非會員、活動前/活動中的價格變化。滿減階梯滿199減30、滿299減60是否按優(yōu)惠力度取最高檔是否支持跨店滿減湊單臨界值時指訂單金額正好199.00是否參與優(yōu)惠四舍五入規(guī)則如何。這類用例建議和開發(fā)確認清楚優(yōu)惠計算用的精度位數(shù)。贈品邏輯買正裝送小樣小樣數(shù)量是否隨正裝數(shù)量翻倍很多規(guī)則是不翻倍贈品是否占用庫存贈品是否需要單獨展示在訂單里。贈品用例要特別設計“贈完即止”的場景贈品庫存為0時是否會導致正裝無法下單正確行為通常是正裝可下單但不展示贈品很多前端實現(xiàn)會在這一步直接把整個SKU置灰。還有一類套裝拆分場景一個套裝商品拆成多個子商品結(jié)算子商品的優(yōu)惠分攤金額是否正確。這種用例通常要結(jié)合后端結(jié)算單核對不能只看頁面總價我會在用例執(zhí)行時讓開發(fā)提供一個查詢結(jié)算詳情的接口權(quán)限逐項比對分攤金額。為了控制測試成本價格用例不會每個SKU都跑一遍而是按規(guī)則引擎的維度抽取典型商品組合比如“一個參與滿減的特妝品一個不參與活動的標品一個贈品SKU”把平臺的典型規(guī)則都覆蓋進去。4.3 庫存與限購場景的邊界驗證化妝品大促期間容易斷貨庫存用例的邊界處理直接關(guān)系到線上體驗。常規(guī)場景庫存1件的商品加購后詳情頁庫存應變?yōu)?并置灰。兩個賬號同時下單同一個庫存1件的商品只有一人能成功。庫存扣減時機是下單時預占庫存還是支付時扣減用例要按項目定義執(zhí)行不能想當然。超賣保護后端超賣攔截邏輯下前端是否給出友好提示。限購場景在化妝品類目很典型尤其是限量版、禮盒這類商品。限購規(guī)則一般是同一用戶ID、同一設備、同一收貨地址、同一手機號維度。用例要覆蓋賬號A和賬號B使用同一收貨地址下單是否被攔截不同賬號用同一手機號注冊是否被識別為同一人。這屬于風控策略但功能測試同樣要驗證提示文案和攔截時機是否符合預期。我做過一次大促演練發(fā)現(xiàn)限購提示文案在跨設備場景下不生效用戶用同一賬號在不同設備輪流下單都成功了庫存被一個人擼走大半這種問題必須在用例里顯式覆蓋。5. 移動端適配、異常容錯與埋點專項功能用例設計完之后還有三類專項用例容易在評審時被跳過但對用戶體感影響極大適配、容錯、埋點。化妝品類目的詳情頁圖片和視頻特別多這三類問題暴露得尤其充分。5.1 不同機型、系統(tǒng)版本下的適配用例普通功能測試跑在主力機型上沒問題不代表線上沒問題。我會在版本迭代中至少安排一輪真機矩陣系統(tǒng)覆蓋最新版和上一大版本橫豎屏切換。屏幕適配不同分辨率、全面屏劉海區(qū)域、底部安全區(qū)——加購按鈕是否被手勢條擋住是經(jīng)典問題。深色模式詳情頁背景、文字顏色、圖片在深色模式下的可讀性。字體大小系統(tǒng)字體放大后詳情頁標簽和價格是否換行錯亂。圖片長圖詳情頁長圖滑動的性能視頻自動播放/暫停邏輯是否正常。還有一類動態(tài)權(quán)限測試化妝品詳情頁如果集成了掃碼查真?zhèn)?、AR試妝等功能需要相機權(quán)限。用例必須驗證拒絕授權(quán)、取消授權(quán)、授權(quán)后返回頁面三種狀態(tài)的跳轉(zhuǎn)和提示是否正常。很多項目的AR試妝模塊在拒絕權(quán)限后直接白屏就是因為只測了授權(quán)路徑。5.2 弱網(wǎng)、接口異常和響應兜底列表頁和詳情頁都依賴接口數(shù)據(jù)。弱網(wǎng)和異常場景如果只在網(wǎng)絡條件好的情況下測試上線后會被用戶教做人。我的做法是準備一份接口異常用例清單接口超時加載中狀態(tài)持續(xù)多久超時后是否有重試按鈕。接口返回空數(shù)據(jù)列表頁顯示“暫無商品”詳情頁顯示“商品已下架”或其他兜底。接口返回錯誤碼401、500、網(wǎng)絡異常是否有統(tǒng)一錯誤提示且不白屏。圖片加載失敗默認圖、品牌Logo替換圖是否正確。網(wǎng)絡切換WiFi切4G時正在加載的請求是否中止、重發(fā)是否有重復提交。在加購和下單環(huán)節(jié)異常用例更重要。加購請求重復點擊是否會生成多條購物車記錄下單按鈕連點兩次是否會產(chǎn)生兩個訂單。這類冪等性問題建議用接口工具直接模擬超時加用戶重試比單純手點更容易復現(xiàn)。我在項目里用這種方式發(fā)現(xiàn)了加購接口沒有做冪等處理重復點擊會產(chǎn)生兩條記錄修復后購物車數(shù)據(jù)質(zhì)量明顯提升。5.3 埋點數(shù)據(jù)與運營位曝光邏輯埋點測試經(jīng)常被忽視但電商項目的運營決策全依賴埋點數(shù)據(jù)?；瘖y品頁面的埋點至少包含曝光事件列表頁商品曝光、詳情頁瀏覽、篩選面板打開、搜索結(jié)果頁曝光。點擊事件篩選條件點擊、排序切換、規(guī)格選擇、加購按鈕、評價Tab。瀏覽時長用戶停留時間、頁面離開時機。來源渠道從首頁Banner、搜索、活動位進入頁面時來源參數(shù)的透傳是否正確。埋點用例的核心是驗證事件參數(shù)是否在正確時機上報、上報字段是否完整、是否有重復上報。具體做法是用抓包工具或埋點平臺實時查看上報記錄對照產(chǎn)品埋點文檔逐字段核對。最容易出問題的是來源渠道參數(shù)前端漏傳渠道編碼導致運營無法區(qū)分流量來源整個活動的效果分析等于白做。還有一個容易漏掉的是運營位邏輯列表頁頂部可能有品牌Tab、活動樓層、推薦位。這些位置的排序、展示條件、失效時間都要有獨立用例。活動結(jié)束后推薦位如果變成空白需要驗證是否有兜底內(nèi)容而不是留一個刺眼的空白區(qū)。6. 測試數(shù)據(jù)構(gòu)造、執(zhí)行優(yōu)先級與系列回歸策略用例設計得再好測試數(shù)據(jù)不給力也白搭?；瘖y品頁面的測試數(shù)據(jù)需要刻意構(gòu)造不能指望現(xiàn)有商品數(shù)據(jù)自然覆蓋所有條件。這部分的策略直接決定用例執(zhí)行的效率和可信度。6.1 構(gòu)建覆蓋化妝品多維度的測試數(shù)據(jù)集我建議維護一張化妝品測試數(shù)據(jù)清單按維度拆好品類覆蓋護膚、彩妝、香水、洗護、美容儀器等至少各有一個。功效覆蓋保濕、美白、抗皺、舒緩、防曬等至少各有一個特妝商品單獨標記。膚質(zhì)/人群覆蓋油性/干性/敏感肌/孕婦可用/男士專用。價格梯度0-50、50-100、100-300、300以上邊界價格正好99、100、199元專門造數(shù)。庫存場景庫存0、庫存1、庫存大數(shù)、預售/缺貨。規(guī)格覆蓋單規(guī)格、多規(guī)格、套裝、SKU組合缺省。構(gòu)造數(shù)據(jù)時還要注意數(shù)據(jù)之間的組合關(guān)系尤其是篩選和詳情之間的一致性。如果造了一款保濕敏感肌的面霜那么篩選保濕和篩選敏感肌時它都應該出現(xiàn)篩選美白時它不應該出現(xiàn)。這種一致性是設計用例時最容易出錯的地方建議造完數(shù)據(jù)先做一輪數(shù)據(jù)體檢把篩選條件逐個跑一遍確認預期商品都在、非預期商品都不在再開始正式用例執(zhí)行。6.2 優(yōu)先級劃分與回歸安排用例多到一定程度必須排優(yōu)先級否則版本迭代根本跑不完。我的劃分原則P0主鏈路相關(guān)覆蓋瀏覽→詳情→加購→結(jié)算→支付成功以及所有門店里合規(guī)字段展示完整性。P0用例必須全量跑不能跳。P1次級鏈路與關(guān)鍵異常包括篩選組合、SKU切換、優(yōu)惠疊加、限購、弱網(wǎng)重試。P1用例在版本迭代時建議全量回歸時間緊可以按模塊抽減。P2兼容性、埋點、文案、樣式類優(yōu)先覆蓋高風險頁面比如詳情頁。回歸策略上我習慣分三個層次發(fā)布前全量回歸發(fā)布后第一輪線上冒煙主鏈路抽測迭代過程中做增量回歸哪里改了什么相關(guān)的用例必須跟著跑?；瘖y品類目因為內(nèi)容更新頻率高活動位、品牌樓層、功效標簽經(jīng)常變還要額外加一條規(guī)則每次運營內(nèi)容配置改動至少把合規(guī)字段、商品標簽、活動入口三條用例線掃一遍避免漏測試的內(nèi)容變更在線上產(chǎn)生問題。6.3 系列項目經(jīng)驗沉淀從用例評審到上線跟蹤做完整一個類目的用例設計真正沉淀下來的不是幾百條用例而是幾個可復用的東西。第一用例評審時和產(chǎn)品、運營對齊篩選維度的增減?；瘖y品篩選維度變化特別快今天加一個孕婦可用明天加一個男士專用評審時如果不在用例里預留后面每次加維度就要重構(gòu)測試矩陣成本極高。我推薦在用例設計文檔里單獨放一個“篩選維度擴展點”每次運營提新維度需求時先對照這個擴展點評估影響面再動手返工。第二建立線上監(jiān)控的抓手。上線后我會盯三個數(shù)據(jù)類目頁的曝光到點擊轉(zhuǎn)化率、篩選使用率、加購成功率。如果篩選使用率驟降多半是篩選交互或數(shù)據(jù)有問題如果加購成功率下降優(yōu)先查SKU和庫存接口。這類線上數(shù)據(jù)比測試環(huán)境用例更能反映真實問題一旦發(fā)現(xiàn)異常就去排查對應功能模塊的日志和埋點。第三把踩過的坑沉淀成測試備忘錄。比如SKU組合缺省必須置灰、價格邊界用閉區(qū)間、詳情頁合規(guī)字段要單獨做核對模板、搜索無結(jié)果要帶兜底推薦。這些備忘錄比任何理論都值錢新同事接手化妝品類目時直接看備忘錄能少踩大部分坑。最后再分享一個實操中養(yǎng)成的習慣頁面用例不要一次性寫完就提交先把它當測試計劃用兩三天時間在測試環(huán)境里跑一遍把不合理的預期、遺漏的邊界、缺失的數(shù)據(jù)都改掉再正式提交評審和歸檔。這么做前期會慢一點但評審會順利很多執(zhí)行階段返工也會少很多。對電商這種半個月一個迭代的節(jié)奏來說這個前期投入非常劃算尤其像化妝品類目這種篩選、規(guī)格、合規(guī)全占滿的頁面提前過一遍用例比上線后補用例要省心得多。