1. 化妆品页面测试的整体思路拆解做电商项目测试这么久我越来越觉得化妆品类目是一个“看着简单、测起来全是细节”的典型场景。标题里说的“测试实战七化妆品页面用例设计”本质上是把一个看似普通的商品详情页拆成功能、交互、数据、兼容性等多个维度去验证。而且这个类目有它特有的敏感性价格波动、规格组合、效期展示、图片文案合规每一样拎出来都能写一页用例。这一期我重点围绕化妆品页面的用例设计来聊。先亮个观点页面用例设计不是把UI上的按钮点一遍就算完而是要结合电商业务的真实链路去倒推。比如用户从搜索进入列表再点进详情页看到主图、标题、价格、规格、卖点、评论、推荐位这个过程里任何一环的数据错乱都会直接影响转化。所以我在设计用例时基本遵循一个“三段式”的逻辑页面呈现层元素是否展示完整、文案是否正确、图片是否清晰不破图。交互逻辑层规格切换、数量增减、加购、收藏、分享这些操作是否顺畅状态是否联动。数据一致性层页面展示的价格、库存、SKU信息是否与接口返回一致是否与购物车、订单、库存系统同步。这个思路同样适用于其他电商类页面但化妆品页面有几个特殊点需要注意规格通常比较多色号、容量、套装价格营销玩法复杂券、满减、会员价叠加详情页里图文模块远远多于普通商品而图片和文案正是化妆品信任感的来源测试时不能只检查样式还要关注图片加载策略。我先把整篇用例设计的框架列出来后面逐个展开。测试维度关注重点说明页面元素完整性标题、主图、价格、规格、参数基础展示正确营销信息准确性优惠券、满减、会员价、活动标签计算口径不出错SKU切换联动规格选择、库存、价格、图片变化交互核心链路数据一致性详情页/列表页/购物车/订单状态统一跨页面数据贯通兼容与异常弱网、多端、缓存、接口异常边界情况兜底为什么把“数据一致性”单独拎成一个维度因为我在实际项目里踩过坑——列表页显示“仅剩3件”点进详情页却还能正常下单后来一查是详情页库存接口没有实时刷新。这类问题只靠UI用例根本发现不了必须从用户完整路径去设计验证场景。这也是我反复强调的用例设计的第一原则不是覆盖多少条而是覆盖了哪些真实用户路径。2. 测试准备阶段需要做哪些功课别急着写用例先花半天时间把底子打好。我每次接到化妆品页面的测试任务第一件事不是打开电脑而是先做三样准备工作。2.1 吃透PRD和视觉稿打开PRD不要只看文字描述重点看两个东西商品规格的枚举值、营销活动的叠加规则。化妆品页面经常出现“买一送一”“第二件半价”“满199减30”这类活动而PRD里往往只有一个笼统描述具体到某个SKU能不能参加活动需要测试人员自己去核对后台配置。视觉稿同样不能只看“好不好看”要关注异常态设计——比如数量减到0时按钮置灰还是允许输入0图片加载失败时有没有占位图这些视觉稿大概率不会画但你必须提前想清楚。我的习惯是读PRD时手边放一张A4纸把每个模块的边界条件随手记下来。比如“价格区展示逻辑”这一条我就记过有促销价时展示促销价促销结束后展示原价会员价又该怎么展示这一个个问题都是后续用例的核心素材。2.2 盘点测试数据和后台配置化妆品页面的测试数据比普通商品更讲究。我建议准备几个典型商品多规格商品比如一款口红有10个色号每个色号又有2种容量。单规格商品比如某款精华只有一个规格验证简化版展示。活动商品参加满减、秒杀、优惠券叠加的商品。下架/售罄商品验证特殊状态下的页面表现。后台配置也要提前核对包括SKU编码、库存值、价格、活动ID、优惠券模板。这些数据最好是构造出来的干净数据不要直接用线上在售商品否则测试过程中改了库存或者价格影响面不可控。我以前就遇到过测试时把某个SKU价格改成0.01元忘改回来差点被运营同步到线上的事故。2.3 提前梳理接口文档页面展示的数据大概率来自好几个接口商品基础信息接口、价格库存接口、营销活动接口、评论接口。每个接口的字段含义、返回值类型、异常情况都需要提前看一遍。我见过很多测试同事在用例设计阶段完全不看接口文档结果执行时发现某个字段多了一个“单位”属性页面展示单位对不上临时返工。提前梳理接口还能帮你判断哪些用例应该在前端层面验证哪些需要构造接口数据来模拟。接口这块还有个小技巧化妆品页面的图片通常走CDNURL里有规格参数比如?w750h750这种如果CDN缩放参数配置错了会出现图片被拉伸变形的问题。这类问题用例设计时就要考虑到别等执行阶段才发现。3. 页面元素的梳理与分类方法写用例之前我习惯先把页面拆成一个个模块再给每个模块标一个“风险等级”。页面元素看着多其实按功能归类后结构非常清晰。我一般把化妆品详情页拆成商品信息区、多媒体展示区、价格营销区、SKU选择区、服务承诺区、内容评价区、推荐位。每个区域单独梳理后续写用例时就不用满屏找要素了。商品信息区通常包括商品标题、品牌名、卖点标签、参数表。其中商品标题是最容易出问题的标题里的规格信息和SKU不一致、标题文案超长导致截断、标题里包含违禁词被合规拦截——这些都是常见缺陷。参数表要关注的点是“参数项是否完整”“单位是否正确”化妆品的参数往往包含“保质期”“净含量”“适用肤质”等字段少一项用户都可能发起咨询。多媒体展示区是我比较关注的一个区域。化妆品主图通常有“首图视频轮播图详情长图”三部分组成。用例设计时要分别覆盖视频能否自动播放、是否静音、播放中切换图片是否中断轮播图滑动时是否卡顿、有无白屏详情长图的加载方式是分段加载还是整图加载弱网下是否出现大面积空白。这些体验细节直接影响用户对商品品质的判断。价格营销区涉及的元素最多原价、促销价、券后价、满减提示、会员价、活动倒计时。我建议用例设计时把这个区域单独列一个表格把所有价格形态和展示优先级写清楚。比如原价99元、促销价79元、叠加满减券后再减10元最终展示是69元还是79元加“券后69元”的提示各家电商的展示规则不同但务必以PRD和UI标注为准。价格营销区的用例我一般还会加一条“数据埋点验证”。电商页面几乎都会埋曝光点击事件价格区域是关键埋点位。用例执行时顺手验证一下埋点上报是否正常能省去后面数据验证阶段的很多麻烦。信息架构梳理完之后我习惯画一张“页面模块-接口映射表”把前端模块、后端接口、关键字段列在一个表里。这个表对后续写用例非常有帮助——每一类用例都能迅速定位到对应的接口与字段也能帮我判断某个异常场景应该在前端mock还是通过接口模拟。4. 功能类用例的设计方法与要点功能用例是整个用例集的核心也是最考验经验积累的地方。我不打算罗列几百条用例而是挑那些“写错概率大、返工成本高”的模块逐个讲设计思路。4.1 商品标题与品牌信息的展示校验标题用例看起来简单无非是“标题是否正确展示”但真正执行起来要考虑的细节远不止于此。我通常会设计这些场景标题在30字、50字、80字等不同长度下的展示效果是否换行、是否截断、是否遮挡价格。标题含特殊符号如™、®、表情符号时在Android与iOS上的渲染是否一致。品牌名单独一行展示品牌名与标题之间是否有分隔点击品牌名能否跳转品牌主页。已下架商品的标题是否显示“失效商品”之类的标识。你可能会觉得这些都是很小的问题但我实际项目里确实遇到过某款口红的标题里有个“™”符号在部分安卓机型上显示成了乱码用户还以为买到假货客诉直接爆了。所以标题展示相关的用例宁可写得细一些也别嫌琐碎。4.2 主图与详情图的校验图片用例我建议从“内容正确性”和“加载表现”两个维度去写。内容正确性包括首图是否和商品对应尤其是多个规格不同图片的商品、轮播图顺序是否与后台配置一致、详情图是否覆盖完整卖点信息。加载表现包括弱网下是否出现破图、快速滑动时是否加载占位图、图片尺寸是否适配不同屏幕。化妆品详情页经常是长图图特别长走的是分段加载机制。这里有一个高频缺陷页面滚动到某个位置时下一段图片加载不出来用户看着一大片空白。我习惯把这类用例写成“滚动到第1屏/第3屏/第5屏/末尾等待图片加载确认无空白区域”并把网络环境分别设为Wi-Fi和4G。图片加载这种事测的时候不觉得上线后用户一旦遇到感知会特别明显。4.3 价格展示与计算逻辑的用例设计价格这块我见过最多的缺陷集中在“叠加逻辑”上。化妆品SKU多每个SKU可能对应不同的活动价同一款商品可能同时参与店铺满减和平台券算下来用户实际支付的价格五花八门。用例设计时一定要覆盖“多活动叠加”的场景并且每一档都独立验证。我举例说明一款面霜有三个SKU30ml/50ml/100ml活动规则是“满199减30可叠加店铺券减10”30ml价格是89元50ml是139元100ml是189元。用户如果把30ml和50ml一起加入购物车总价是228元按规则应当减30再减10最终是188元。用例就要覆盖这个组合同时还要覆盖“只买一个SKU不满足满减条件”时的价格展示。价格用例里还有一个容易被忽略的点价格展示的时间与活动状态的关系。比如秒杀活动结束的瞬间页面价格是否从“秒杀价”自动恢复为“原价”活动倒计时归零时页面有无残留“已抢光”之类的状态这些场景需要结合活动配置在用例里明确写出来。4.4 SKU切换联动逻辑用例设计重心SKU联动是化妆品页面用例里最有代表性的模块。简单说就是用户选择不同规格时页面上的主图、价格、库存、SKU选中态、加购按钮状态要同步变化。我把这类用例设计成一张矩阵表逐项核对。操作步骤预期主图预期价格预期库存预期加购按钮选中色号#01切换为#01主图显示#01价格显示#01库存可加购选中色号#01容量30ml切换为30ml主图显示30ml价格显示30ml库存可加购选中已售罄的SKU切换为该SKU主图显示售罄SKU价格显示“已售罄”置灰不可点取消全部规格选择恢复默认主图显示默认价格区间显示默认库存可加购这个矩阵表看起来不复杂但执行时容易翻车的是“售罄SKU”的联动。有的页面在切换到售罄SKU后加购按钮确实置灰了但价格还停留在上一个SKU的价格上用户会误以为“能下单但买不了”体验非常差。用例设计时要把“按钮状态”和“价格/图片是否同步切换”绑定在一起验证不要拆开写。另外多规格切换时还有一个细节——图文的“规格记忆”功能。用户选了#05色号之后退出页面再次进入时页面是恢复默认还是自动定位到上次选的色号有的电商为了实现这个记忆引入了本地缓存。用例里要有“退出重进”“终止进程重开”两类场景来验证否则上线后用户会碰到“我明明选了色号加购时又变成了另一个色号”的情况。4.5 加购与购物车交互的用例化妆品加购的用例除了常规的“加购成功/失败”之外我特别建议补上这些场景同一SPU下不同SKU加购后购物车里是否按SKU维度拆分条目。售罄SKU在购物车里能否被正常结算是否提示“已失效”。已加购的商品如果后台改了价格购物车是否跟随更新并给出价格变化提示。加购后点击购物车角标跳转能否正确落位到对应商品。这些用例的价值在于它们跨了两个页面验证的不只是详情页自身而是整条购物链路的连通性。化妆品活动中用户往往一次加购多个规格购物车里的分组展示一旦混乱后面下单流程直接受影响。4.6 收藏/关注/分享功能的用例收藏、分享这些功能看起来很“轻”但用户粘性往往就靠这些轻交互支撑。化妆品页面上收藏按钮通常同时承担“关注上新”的作用分享则要拉起多个第三方平台。用例设计时我要验证收藏按钮的状态切换点击前是空心图标点击后变实心再次点击取消收藏图标恢复。关键点在于“登录态”与“未登录态”的处理未登录点击收藏是跳转登录页还是弹窗提示收藏成功后退出再登录收藏状态是否保持分享用例则要覆盖分享到不同平台后的页面文案是否正常、分享图是否露出。这里有一个容易被忽略的坑分享出去的卡片标题和图片往往是服务端生成的而不是客户端实时截屏。这意味着分享文案需要后端接口配合用例里要验证分享内容与当前商品是否一致。我在一个美妆项目里就遇到过分享卡片标题一直是上一件商品的问题原因就是缓存没清理。4.7 评论与问大家区域的用例化妆品页面的评论区域至少包含“综合/最新/图片/视频”几个Tab有时还有“问大家”。用例设计的重点有两块一是列表加载与分页表现二是内容维度的正确性。列表加载用例覆盖首屏加载、下拉刷新、上拉加载更多、切Tab后列表是否重置。内容维度的用例要验证评论里的商品规格标签是否与当前SKU对应图片评论的缩略图能否点击查看大图视频评论是否可以播放。化妆品商品的评论里用户经常晒“使用前后对比图”这些图片往往比较大弱网下加载明显变慢。用例里最好专门设计“弱网下评论图片加载失败时是否有重试机制”的场景。问大家区域的用例重点是“提问后多久有回复文案提示”因为很多项目的问大家功能是异步的不能即时返回。用例要验证前端对“等待回复”状态的展示是否合理不能直接出现空页面。5. 兼容性测试与异常场景容易被忽视但必须覆盖兼容性和异常场景我把它放在功能用例之后是因为这部分用例的“含金量”更多体现在测试思维的严谨性上而不是用例数量。化妆品页面在这两块有自己的一些特性。5.1 多端与多机型的适配用例设计化妆品页面是图片密集型页面对机型适配的敏感度极高。iPhone SE这类小屏机型上详情图是否被压缩变形刘海屏、水滴屏机型上页面顶部是否被状态栏遮挡不同分辨率Android机型上价格文字是否折行。这些适配问题单靠开发自测很难覆盖完全测试用例需要在真机矩阵上执行。我建议用例设计时至少覆盖三类机型iOS小屏比如iPhone SE系列、iOS全面屏比如Pro系列、高性能/低性能Android各一台。低性能Android主要验证的是滑动流畅度和图片加载会不会卡顿因为化妆品详情页长图多低端机上白屏和闪退的概率明显更高。另外深色模式也需要关注。默认情况下电商App多以浅色设计为主但部分机型系统开了深色模式后页面背景和文字颜色如果没做适配会出现黑色背景上显示黑色文字的情况。这个用例在化妆品页面尤其重要因为详情长图多为白底深浅色切换后观感差异大。5.2 特殊网络环境的处理验证弱网测试在上线前必须执行尤其是页面依赖大量图片和视频的化妆品详情页。我用过两个办法一是通过客户端工具模拟弱网iOS自带网络调节、Android端用抓包工具限速二是直接在真机上切换为3G/4G网络进入页面观察加载表现。弱网用例至少覆盖这几个场景进入页面时处于弱网环境页面加载超时是否有重试按钮。图片加载一半时断网是否出现破图恢复网络后能否点击重新加载。视频播放中网络中断是否有“网络不稳定”提示恢复后能否续播。弱网下加购操作超时是否出现loading转圈卡死能否自动重试。这些场景用户在实际使用中遇到得不少但用例阶段容易遗漏。我建议在用例设计模板里把“网络异常”作为一个固定模块写进每个功能点的测试前置条件中这样能有效避免遗漏。5.3 接口异常与返回异常的兜底设计化妆品页面的接口返回复杂字段多服务端出问题时前端如果没有兜底页面会直接白屏或显示“网络错误”。用例设计时要想清楚接口挂了页面是显示缓存数据还是纯空白接口某些字段为空页面是隐藏对应模块还是展示占位文案我举一个具体场景商品详情接口返回的price字段为空此时如果前端直接把这个空值渲染到页面上价格区域会变成“¥”加空白用户体验很差。好的兜底应该是在数据校验层发现异常后隐藏整个价格模块并弹出一条轻提示“数据加载异常请重试”。用例里就要覆盖这类字段缺失的场景。接口超时同样要测。购物车加购接口超时页面不能一直转圈要有明确的结果反馈。我在做美妆App测试时设计过一个用例断网后点击加购等待10秒观察页面是提示“网络不给力”还是假死。上线前通过这个用例发现过至少两个模块的假死问题。接口异常验证需要用抓包工具配合常用的方案有很多我用得比较多的是客户端本地mock工具。工具选型这个事团队内统一就好关键是执行用例时能精确模拟“接口超时”“返回空数据”“返回错误码”这三类场景。5.4 后台配置变更引发的回归场景化妆品页面前端展示高度依赖后台配置配置一旦变更页面可能立刻受影响。这类回归场景我在用例里专门放了一节建议测试执行时仔细核对。后台修改商品标题后前端详情页是否实时生效。后台修改SKU库存为0后前端是否变为“已售罄”状态。后台结束促销活动后前端价格是否自动恢复为原价。后台新增一个规格SKU后前端在不发版的情况下能否正常展示。化妆品活动频繁运营几乎每周都在调整价格和活动配置如果配置变更后页面没有及时刷新线上很容易出现“活动已结束但页面还在倒计时”的尴尬情况。这类用例设计得越细线上事故越少。6. 化妆品页面测试用例设计中的经验总结与避坑指南到这我把化妆品页面用例设计的核心模块都过了一遍。最后说几个从实战中沉淀下来的心得可能比前面的用例更有直接参考价值。第一用例设计别贪多求全。我见过有人把同一个“标题展示正确”写成20条相似用例其实是浪费。更高效的做法是每条用例对应一个独立的业务规则或边界条件。比如“标题展示”只写5条分别对应不同长度、特殊字符、售罄态、品牌跳转、数据异常完全覆盖必要场景就够了。第二用例设计完一定要拉一个“遗漏自查会”。我会把PRD、视觉稿、历史缺陷记录放在一起逐项过一遍。化妆品页面最容易遗漏的点基本集中在这几块图片弱网加载、SKU售罄联动、活动倒计时归零、分享卡片数据来源、收藏状态记忆。每次遗漏自查把这些点单独拎出来再过一遍基本能把最危险的坑都堵住。第三执行用例时记录要比对后台数据。页面展示的数据最终要跟后台配置去核对不能只看前端长什么样。比如价格区域显示“券后99元”你必须确认这个“99”确实是后台优惠券计算出来的而不是前端写死的。第四用例版本要跟着需求走。化妆品项目迭代快促销活动频繁本周的用例下周可能就失效了。我保持的习惯是每次活动配置有变化就同步更新价格区和营销区的用例SKU配置有调整就同步更新SKU切换联动用例。用例和现状脱节比没有用例更危险因为执行者会盲目信任过时用例。第五多留一些“坏数据”用例。很多测试同学习惯用正常商品数据去测页面但线上最容易出问题的恰恰是数据异常时页面的表现。SKU名称超长、价格字段为null、库存为负数、图片URL失效——这些“脏数据”在数据库中并不罕见。造一批坏数据专门验证页面的容错能力我认为这比覆盖100条正常流程更有价值。化妆品页面用例设计这件事说到底是对业务理解、交互细节和数据敏感度的综合考验。按照我上面说的思路先梳理信息架构再锁定核心交互链路最后补上兼容和异常场景一套用例集基本就能覆盖上线前的关键风险点。你在实际项目里如果碰到某个模块测起来特别费劲不妨回头看看是不是用例设计阶段对这个模块的边界条件拆得还不够细。
