做电商项目测试做到第七篇前面几篇我们依次聊过商城框架、搜索、商品详情、购物车和订单流程今天把目光收回到类目页里比较特殊的一块——化妆品页面用例设计。这个类目不像手机壳、纸巾那样“标品化”它有大量需要测的属性筛选、规格组合、合规字段和内容审核位如果只按普通列表页去设计用例上线后大概率会在一些意想不到的地方翻车。这篇文章我打算把自己实际做过的电商项目中化妆品类目页从列表、详情、加购到下单涉及的用例设计思路完整捋一遍覆盖筛选组合、SKU切换、合规字段、交互异常、数据埋点和回归策略拿过去就能直接用。1. 化妆品类目页的业务特殊性决定测试设计起点很多测试同学接手电商类目页时第一反应是打开页面照着功能点一条条列用例。这个做法放在化妆品页面上容易失控因为这个类目的信息架构和普通标品差别太大理解不透业务就看不到风险点。我建议先花半天时间把类目页的业务特殊性梳理清楚再动手设计用例。1.1 化妆品信息架构和普通标品最大的三个差异第一个差异是多维属性筛选。手机壳的筛选项通常只有品牌、价格、适用型号撑死了加一个颜色但化妆品类目的筛选项能铺满两屏横向滚动都翻不完品牌、价格区间、功效保湿/美白/抗皱/舒缓/修护、肤质油性/干性/混合性/敏感肌、适用人群通用/男士/孕妇、质地水/乳/霜/精华/面膜、是否特殊化妆品祛斑美白、防晒、染发等。这些筛选项不是前端写死的而是运营在后台类目树上动态配置的。这意味着用例设计不能只看接口参数还要回到类目树配置本身每加一个筛选维度列表页的请求参数、返回字段、空态文案、筛选高亮状态的组合复杂度就成倍增长。第二个差异是SKU维度的数量级。一个手机壳通常就一个SKU最多分个颜色但护肤品有容量、套装、版本滋润版/清爽版彩妆有色号洗发水有功能型组合一套下来详情页的规格可能有三到四层。测试时不仅要对SKU切换后的价格、库存、图片做校验还得考虑当前选中的规格组合在深链接、分享、购物车回显时的正确性。这个复杂度意味着SKU相关的用例不能只放在详情页模块必须跨模块设计。第三个差异是合规字段多且敏感。化妆品页面必须展示备案编号普通化妆品备案或注册编号特殊化妆品标注生产许可证号、生产企业信息进口品还要有中文标签和检验检疫信息。页面上如果漏展示、展示错误轻则被平台处罚重则影响品牌方资质审核。这类字段的校验通常没有复杂逻辑但需要专门的核对用例并且每次内容更新后要回归。我在做项目时就遇到过详情页只展示备案号但漏了生产许可证号的情况这种问题靠功能测试的正常路径根本发现不了必须有一张专门的合规字段核对清单。1.2 从用户路径梳理用例落点页面用例设计如果一上来就盯着列表页表格填充很容易漏掉上下文。我更习惯先把用户路径画出来再在每条路径上找异常分支。路径分为四条主流线被动浏览线首页/活动Banner → 化妆品类目Tab → 列表页 → 点击商品进入详情。主动检索线搜索框 → 关键词联想 → 搜索结果列表 → 筛选/排序 → 详情。直接访问线从分享链接、收藏夹、购物车回跳进入详情页。决策转化线详情 → 查看图文/评价 → 选择规格 → 加购 → 购物车 → 结算。每条路径拆出来的用例侧重点完全不同被动浏览线关注类目Tab的入口有效性、首屏数据量和曝光位主动检索线关注筛选条件组合、关键词高亮、排序稳定性直接访问线关注URL参数缺失时的兜底、非法ID、已失效商品决策转化线关注SKU选择、库存联动和加购成功状态。实际设计用例时我会把这些路径整理成矩阵每条路径至少覆盖一个正常用例和两个异常用例再把跨路径共用的业务规则单独抽出来做数据驱动。这个思路也决定了用例组织形式不要只按页面分模块而要按“路径页面”交叉分模块这样执行时更容易发现问题归属评审时也方便让产品经理快速理解覆盖范围。2. 列表页核心用例筛选、搜索、排序与分页的逻辑组合列表页是整个类目页的流量入口大部分功能用例都集中在这里。但这个区域的用例设计有一个陷阱就是很容易从“功能点”出发而不是从“逻辑组合”出发。筛选、排序、分页单独测都正常一旦组合起来就出现各种边界问题。2.1 多维度筛选的组合测试矩阵怎么搭化妆品列表页最典型的形态是顶部Tab综合/销量/新品/价格 左侧分类树或底部弹出筛选面板。筛选维度多到一定程度手动穷举所有组合很快就不现实——5个维度各3个选项全组合是243种全部测完不现实也没有必要。我的做法分两步第一步每个维度单独验证。品牌选一个、功效选一个、价格区间选一个分别断言列表返回结果中对应字段全部符合条件。比如选了“保湿”功效结果列表里所有商品的功效标签都必须包含“保湿”选了“0-100元”所有展示价格都应该在区间内。价格边界需要专门验证——刚好等于100元是否包含后端用的是闭区间还是开区间这里最容易出隐性Bug我就在一个项目里遇到过“小于等于价格上限”和“小于价格上限”的字段错位导致价格正好等于100元的商品漏展示。第二步跨维度正交组合。重点不是把所有组合跑一遍而是优先覆盖高风险组合一个是“必然为空”的组合比如价格区间0-50元 敏感肌 高端品牌这种组合结果为空必须验证空态文案和推荐位另一个是“可能冲突”的组合比如“防晒 油皮 男士”结果可能很少但系统要能正常展示。执行时可以用正交表或Pairwise工具生成一组有代表性的组合然后重点验证组合后列表是否重置、筛选条件是否保留、返回上一级时筛选状态是否存在。这里有一个经常被忽视的点筛选条件与URL参数之间的关系。很多电商列表页支持分享用户筛好了条件分享给朋友对方打开链接还要能看到同样的筛选结果。用例必须覆盖URL参数拼接、非法参数值例如功效abc、价格abc、缺失参数三种场景我见过线上因为分享链接少拼了一个筛选参数导致用户看到的是未筛选的全量列表这个问题直到埋点数据出现异常才被发现。2.2 排序和分页里容易被漏掉的场景排序不是简单的“点了按价格升序就按价格升序”。电商页面的排序往往是多个因素叠加综合排序可能包含销量、好评率、运营加权新品排序不是单纯的上架时间而是有一个“新品定义窗口”销量排序在不同筛选条件下取的口径也可能不同。测试用例至少要有以下几类切换排序维度后列表内容顺序要变化且符合规则比如价格升序时列表价格必须单调递增。筛选和排序同时存在时改筛选不改变当前选中的排序方式但排序结果要基于新的筛选结果计算。排序稳定性也叫“同序值稳定性”。两个商品价格都是59元时用户刷新后相对顺序不能乱跳否则会觉得页面闪了一下体验极差。分页边界每页数量比如20个的最后一页不满20个正好20个时下一页是否有空页快速滑到底时重复触发加载更多是否会重复请求或数据重复。位置记忆用户从列表第3页进入详情再返回应该回到第3页而不是回到第1页返回后筛选条件、搜索关键词、滚动位置尽量保留。我自己踩过的坑是分页时的“商品失效与动态排序冲突”。商品因为库存不足在列表中被标记为已失效此时用户继续往下翻因为列表数据数量发生变化后端可能返回重复商品或直接翻不动页。这类问题排查半天往往不是算法问题而是前端对列表数据的处理方式——没有根据商品ID做去重。用例设计时建议专门设计“翻页过程中商品状态变化”的场景让前端和后端提前约定好增删逻辑。2.3 搜索联想与无结果态的细节化妆品页面的搜索虽然入口在类目页外面但对类目页的测试影响很大因为用户进列表页之后大概率还是要搜一下。搜索联想需要覆盖品牌词、功效词、成分词如烟酰胺、玻尿酸这类成分名、品类词如口红、面膜。联想词高亮、点击联想词后跳转列表并携带筛选条件这些都要单独跑。尤其要注意同音词、拼音、繁体中文的处理策略——不同项目要求可能不一样但用例里必须明确一版口径否则测试、开发、产品各说各话。无结果态也值得细测。搜索“某个新锐品牌”时健康态可能没有结果这时页面应该给出“没有找到相关商品”的文案同时带一些兜底推荐比如热门搜索、同类商品。我见过有的页面无结果时只给文案没有推荐位导致用户直接流失也见过页面兜底推荐的商品和搜索词毫无相关性搜“眼霜”推“纸尿裤”这种低级问题必须用用例明确约束。测试时还建议把搜索词本身的各种特殊字符跑一遍纯空格、超长字符、表情符号、SQL注入类字符验证页面不报错且正常展示空态。下面这张表我执行回归时常用按表扫一遍能保证列表页核心逻辑不漏用例维度关键场景容易遗漏的点筛选单选、多选、清空、组合空态、价格边界、URL参数校验排序切换、稳定、与筛选叠加同价格相对顺序、刷新不乱跳分页加载更多、返回位置商品失效导致的跨页重复搜索联想、跳转、无结果拼音/繁体口径、兜底推荐相关性3. 商品详情页用例规格、成分、合规字段一个都不能少列表页把用户引进来详情页才是真正影响转化率的地方。化妆品详情页的用例量级远大于普通标品其中SKU切换、成分展示、合规字段这三块是最容易出问题的。3.1 SKU 规格切换的完整校验链化妆品SKU少的也有两三层容量30ml/50ml/100ml、版本清爽型/滋润型、套装单支/两件套/加赠小样。每一层切换都要校验以下内容标题中的规格名跟着变比如“XX面霜 50ml”和“XX面霜 30ml”不能混。主图、详情图跟着变。有些项目是同一套图有些项目是不同SKU配不同主图必须人工确认“选50ml时主图是不是50ml的”这个点自动化很难直接判断建议用视觉对比辅助。价格、划线价、促销标签跟着变。切换规格后促销标签没有更新的情况很常见比如从参与满减的50ml切到不参与满减的30ml标签还在显示“满199减30”。库存数字跟着变已售数量口径如果页面上有展示也要跟着变。加购按钮状态当前规格库存为0时置灰并提示“已售罄”而不是允许加入购物车后在购物车里再报错。默认选中态进入页面时默认选中哪个SKU通常是销量最高或运营配置的那个需要和产品经理确认口径。特别提醒一个场景SKU之间的组合可用性。假设面霜有三个容量但30ml和50ml又分别对应不同的版本后端配置SKU时不是所有组合都存在。前端切换到不存在的组合时页面必须自动把不可选规格置灰或提示“该组合暂不可售”不能让用户选中后提交不了。建议专门构造一张SKU组合合法表把后端返回的SKU矩阵和页面置灰逻辑一一对照这一步能提前发现大量规格搭配问题。第二个提醒是SKU记忆。用户选了50ml后退出详情再回来甚至从购物车回跳详情选中的规格要能正确回显。这类用例要放在跨页面回归里不能只在详情页单测。3.2 成分表和功效宣称的展示规则成分表现在是化妆品详情页的标配很多平台会直接展示完整成分列表并按含量降序排列。测试关注的点包括成分列表的顺序逻辑成分含量从高到低前端拿到的顺序是否正确有没有乱序。高风险成分提示像香精、酒精、部分防腐剂如果平台做了风险成分标注用例要验证标注口径和提示文案是否准确。成分搜索详情页是否支持成分搜索比如用户搜烟酰胺能跳到备案成分含该成分的商品。展示完整性成分表必须能拉到底长文本不截断没有乱码特殊字符括号、下标、斜杠显示正常。功效宣称和详情图文的一致性详情图说“敏感肌可用”评价区和成分表里却有高风险成分这个不完全等于功能Bug但测试人员应该在用例评审时提出核对规则。这里有一个容易被忽略的思路功效宣称的测试不能只看前端文案。很多电商后台会配置不同的功效标签详情页显示的保湿、修护、美白标签是从运营属性里透出的。测试时准备一批不同功效标签的商品逐一核对详情页是否与后台配置一致尤其是特殊化妆品祛斑美白、防晒、染发、烫发等的标签这类宣称受监管要求更严格标签配置错了直接影响审核结果。我建议在用例里专门加一条“功效标签与后台属性一致性抽检”的用例而不是把所有希望寄托在内容审核环节。提示成分表和功效标签属于“内容属性”而非“页面功能”很容易被当成纯文案漏测。请务必在用例类型里单独标记为高优先级内容校验项。3.3 合规信息字段的专项核对合规字段的核对属于“不做则已一做就要做全套”的用例。给化妆品详情页建一个合规字段模板至少包含以下字段的展示验证备案编号/注册编号普通化妆品的备案编号和特殊化妆品的注册编号格式不同需要按规则校验。生产企业名称、生产地址、生产许可证编号。进口化妆品的中文标签信息、境外生产企业信息。保质期、生产日期、限期使用日期。使用方法、注意事项、警示语如“避免接触眼睛”“使用前请测试”。具体用例要覆盖字段齐全性、字段内容与后台配置的一致性、字段展示样式换行、截断、链接跳转。同时建议做一次信息完整性抽检随机挑选若干商品人工去后台核对一遍详情页展示的所有合规字段而不是只看前端模板。我记得有一次版本迭代中详情页模板被改造开发只迁移了主图和价格字段合规字段的样式错位线上出现“备案编号字体小到看不清”的投诉就是因为测试时只校验了字段存在没有校验样式可读性。这一节很重要因为合规问题不是功能Bug是运营风险。测试人员在用例设计时主动把这块纳入范围价值会远远高于一个普通的按钮测试。4. 购物车、下单与优惠互动的集成用例详情页测试完整了接着就要验证“加购”这个动作是否把信息正确传递到下个环节。化妆品类目的购物车和订单测试有一个特点促销规则多、套装多、赠品多集成用例设计不好就会漏掉关键的联动场景。4.1 从详情页到购物车的全链路校验加购用例看着简单实际容易出错加购成功后购物车中商品名称、规格名容量/色号、图片、单价和详情页是否一致。商品加购前失效详情页刚打开时还有货等用户选好规格点加购时已经下架系统应提示“商品已下架”而不是把失效商品塞进购物车。重复加购同一商品同一SKU连续加购购物车是合并数量还是新增一条记录不同项目策略不同用例要按产品定义执行。购物车中修改规格化妆品常见升级容量、换色号的操作修改后价格、库存、优惠计算必须联动。购物车中的失效商品特价活动结束、商品售罄后购物车项应标记失效失效项不能参与全选、不能结算还要有单独清除入口。这些用例如果在功能测试阶段没覆盖到联调阶段再发现问题排查成本会高很多。尤其是“购物车中修改规格”这条前端回传的SKU ID如果出错订单里的商品规格和价格对不上客服后台看到的信息完全错误是一类线上高危问题。4.2 化妆品订单的典型价格计算场景化妆品类目是平台促销活动的主战场满减、折扣、赠品、会员价、套装优惠叠加在一起价格计算很容易出问题。设计订单价格用例时我会围绕三条主线单品折扣促销价、闪购价、会员价三者的优先级如何页面只显示一个价格但后台计算时要判断多个规则。用例要构造同一商品在不同状态下会员/非会员、活动前/活动中的价格变化。满减阶梯满199减30、满299减60是否按优惠力度取最高档是否支持跨店满减凑单临界值时指订单金额正好199.00是否参与优惠四舍五入规则如何。这类用例建议和开发确认清楚优惠计算用的精度位数。赠品逻辑买正装送小样小样数量是否随正装数量翻倍很多规则是不翻倍赠品是否占用库存赠品是否需要单独展示在订单里。赠品用例要特别设计“赠完即止”的场景赠品库存为0时是否会导致正装无法下单正确行为通常是正装可下单但不展示赠品很多前端实现会在这一步直接把整个SKU置灰。还有一类套装拆分场景一个套装商品拆成多个子商品结算子商品的优惠分摊金额是否正确。这种用例通常要结合后端结算单核对不能只看页面总价我会在用例执行时让开发提供一个查询结算详情的接口权限逐项比对分摊金额。为了控制测试成本价格用例不会每个SKU都跑一遍而是按规则引擎的维度抽取典型商品组合比如“一个参与满减的特妆品一个不参与活动的标品一个赠品SKU”把平台的典型规则都覆盖进去。4.3 库存与限购场景的边界验证化妆品大促期间容易断货库存用例的边界处理直接关系到线上体验。常规场景库存1件的商品加购后详情页库存应变为0并置灰。两个账号同时下单同一个库存1件的商品只有一人能成功。库存扣减时机是下单时预占库存还是支付时扣减用例要按项目定义执行不能想当然。超卖保护后端超卖拦截逻辑下前端是否给出友好提示。限购场景在化妆品类目很典型尤其是限量版、礼盒这类商品。限购规则一般是同一用户ID、同一设备、同一收货地址、同一手机号维度。用例要覆盖账号A和账号B使用同一收货地址下单是否被拦截不同账号用同一手机号注册是否被识别为同一人。这属于风控策略但功能测试同样要验证提示文案和拦截时机是否符合预期。我做过一次大促演练发现限购提示文案在跨设备场景下不生效用户用同一账号在不同设备轮流下单都成功了库存被一个人撸走大半这种问题必须在用例里显式覆盖。5. 移动端适配、异常容错与埋点专项功能用例设计完之后还有三类专项用例容易在评审时被跳过但对用户体感影响极大适配、容错、埋点。化妆品类目的详情页图片和视频特别多这三类问题暴露得尤其充分。5.1 不同机型、系统版本下的适配用例普通功能测试跑在主力机型上没问题不代表线上没问题。我会在版本迭代中至少安排一轮真机矩阵系统覆盖最新版和上一大版本横竖屏切换。屏幕适配不同分辨率、全面屏刘海区域、底部安全区——加购按钮是否被手势条挡住是经典问题。深色模式详情页背景、文字颜色、图片在深色模式下的可读性。字体大小系统字体放大后详情页标签和价格是否换行错乱。图片长图详情页长图滑动的性能视频自动播放/暂停逻辑是否正常。还有一类动态权限测试化妆品详情页如果集成了扫码查真伪、AR试妆等功能需要相机权限。用例必须验证拒绝授权、取消授权、授权后返回页面三种状态的跳转和提示是否正常。很多项目的AR试妆模块在拒绝权限后直接白屏就是因为只测了授权路径。5.2 弱网、接口异常和响应兜底列表页和详情页都依赖接口数据。弱网和异常场景如果只在网络条件好的情况下测试上线后会被用户教做人。我的做法是准备一份接口异常用例清单接口超时加载中状态持续多久超时后是否有重试按钮。接口返回空数据列表页显示“暂无商品”详情页显示“商品已下架”或其他兜底。接口返回错误码401、500、网络异常是否有统一错误提示且不白屏。图片加载失败默认图、品牌Logo替换图是否正确。网络切换WiFi切4G时正在加载的请求是否中止、重发是否有重复提交。在加购和下单环节异常用例更重要。加购请求重复点击是否会生成多条购物车记录下单按钮连点两次是否会产生两个订单。这类幂等性问题建议用接口工具直接模拟超时加用户重试比单纯手点更容易复现。我在项目里用这种方式发现了加购接口没有做幂等处理重复点击会产生两条记录修复后购物车数据质量明显提升。5.3 埋点数据与运营位曝光逻辑埋点测试经常被忽视但电商项目的运营决策全依赖埋点数据。化妆品页面的埋点至少包含曝光事件列表页商品曝光、详情页浏览、筛选面板打开、搜索结果页曝光。点击事件筛选条件点击、排序切换、规格选择、加购按钮、评价Tab。浏览时长用户停留时间、页面离开时机。来源渠道从首页Banner、搜索、活动位进入页面时来源参数的透传是否正确。埋点用例的核心是验证事件参数是否在正确时机上报、上报字段是否完整、是否有重复上报。具体做法是用抓包工具或埋点平台实时查看上报记录对照产品埋点文档逐字段核对。最容易出问题的是来源渠道参数前端漏传渠道编码导致运营无法区分流量来源整个活动的效果分析等于白做。还有一个容易漏掉的是运营位逻辑列表页顶部可能有品牌Tab、活动楼层、推荐位。这些位置的排序、展示条件、失效时间都要有独立用例。活动结束后推荐位如果变成空白需要验证是否有兜底内容而不是留一个刺眼的空白区。6. 测试数据构造、执行优先级与系列回归策略用例设计得再好测试数据不给力也白搭。化妆品页面的测试数据需要刻意构造不能指望现有商品数据自然覆盖所有条件。这部分的策略直接决定用例执行的效率和可信度。6.1 构建覆盖化妆品多维度的测试数据集我建议维护一张化妆品测试数据清单按维度拆好品类覆盖护肤、彩妆、香水、洗护、美容仪器等至少各有一个。功效覆盖保湿、美白、抗皱、舒缓、防晒等至少各有一个特妆商品单独标记。肤质/人群覆盖油性/干性/敏感肌/孕妇可用/男士专用。价格梯度0-50、50-100、100-300、300以上边界价格正好99、100、199元专门造数。库存场景库存0、库存1、库存大数、预售/缺货。规格覆盖单规格、多规格、套装、SKU组合缺省。构造数据时还要注意数据之间的组合关系尤其是筛选和详情之间的一致性。如果造了一款保湿敏感肌的面霜那么筛选保湿和筛选敏感肌时它都应该出现筛选美白时它不应该出现。这种一致性是设计用例时最容易出错的地方建议造完数据先做一轮数据体检把筛选条件逐个跑一遍确认预期商品都在、非预期商品都不在再开始正式用例执行。6.2 优先级划分与回归安排用例多到一定程度必须排优先级否则版本迭代根本跑不完。我的划分原则P0主链路相关覆盖浏览→详情→加购→结算→支付成功以及所有门店里合规字段展示完整性。P0用例必须全量跑不能跳。P1次级链路与关键异常包括筛选组合、SKU切换、优惠叠加、限购、弱网重试。P1用例在版本迭代时建议全量回归时间紧可以按模块抽减。P2兼容性、埋点、文案、样式类优先覆盖高风险页面比如详情页。回归策略上我习惯分三个层次发布前全量回归发布后第一轮线上冒烟主链路抽测迭代过程中做增量回归哪里改了什么相关的用例必须跟着跑。化妆品类目因为内容更新频率高活动位、品牌楼层、功效标签经常变还要额外加一条规则每次运营内容配置改动至少把合规字段、商品标签、活动入口三条用例线扫一遍避免漏测试的内容变更在线上产生问题。6.3 系列项目经验沉淀从用例评审到上线跟踪做完整一个类目的用例设计真正沉淀下来的不是几百条用例而是几个可复用的东西。第一用例评审时和产品、运营对齐筛选维度的增减。化妆品筛选维度变化特别快今天加一个孕妇可用明天加一个男士专用评审时如果不在用例里预留后面每次加维度就要重构测试矩阵成本极高。我推荐在用例设计文档里单独放一个“筛选维度扩展点”每次运营提新维度需求时先对照这个扩展点评估影响面再动手返工。第二建立线上监控的抓手。上线后我会盯三个数据类目页的曝光到点击转化率、筛选使用率、加购成功率。如果筛选使用率骤降多半是筛选交互或数据有问题如果加购成功率下降优先查SKU和库存接口。这类线上数据比测试环境用例更能反映真实问题一旦发现异常就去排查对应功能模块的日志和埋点。第三把踩过的坑沉淀成测试备忘录。比如SKU组合缺省必须置灰、价格边界用闭区间、详情页合规字段要单独做核对模板、搜索无结果要带兜底推荐。这些备忘录比任何理论都值钱新同事接手化妆品类目时直接看备忘录能少踩大部分坑。最后再分享一个实操中养成的习惯页面用例不要一次性写完就提交先把它当测试计划用两三天时间在测试环境里跑一遍把不合理的预期、遗漏的边界、缺失的数据都改掉再正式提交评审和归档。这么做前期会慢一点但评审会顺利很多执行阶段返工也会少很多。对电商这种半个月一个迭代的节奏来说这个前期投入非常划算尤其像化妆品类目这种筛选、规格、合规全占满的页面提前过一遍用例比上线后补用例要省心得多。