移动端建站同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /91bc7e33e519.html
📄
移动端建站同一组件在不同页面表现不同时怎样构造验收样例
先给结论：不要为“组件本身”写一份通用验收样例，而要为“组件在具体页面里的上下文组合”各写一份。同一组件在列表页与详情页表现不同，通常不是组件坏了，而是容器宽度、内容长度、数据来源或交互层级不同。验收样例要能复现这种差异，而不是只测一个理想页面。
先判断分歧属于“组件缺陷”还是“页面上下文差异”
当设计、前端和测试对同一组件给出不同结论时，先别争论谁看错了，而是把分歧拆成两类可核对的事实。
- 组件自身缺陷：在相同容器宽度、相同内容长度、相同数据状态下，不同页面仍表现不一致。这指向组件实现或样式作用域问题。
- 页面上下文差异：组件本身稳定，但列表页给的容器更窄、详情页给的内容更长、首页数据来自缓存，导致换行、截断、间距或点击区域不同。
区分依据是：把组件放进一个固定宽度的测试容器，再分别注入各页面真实的内容长度和数据状态。如果固定容器下表现一致，就应把验收重点放在页面上下文，而不是组件源码。
两种条件下选择不同的验收样例构造方式
条件一：组件被多个页面复用，但各页面容器宽度不同
此时验收样例应以“容器宽度 + 内容长度”为组合维度，而不是以页面名称为维度。例如假设一个卡片组件在列表页宽度约 160px、详情页宽度约 320px，那么至少构造四组样例：窄容器短标题、窄容器长标题、宽容器短标题、宽容器长标题。每组记录换行位置、是否截断、点击区域是否仍可点。
实施动作：在验收文档里为每组样例写明容器宽度、注入的标题字数、预期换行行数。结果如何影响下一步——如果只有窄容器长标题出问题，就优先改列表页的截断策略或容器最小宽度，而不是改组件全局样式，避免影响详情页。
条件二：组件相同，但各页面数据来源和状态不同
此时验收样例应以“数据状态”为维度：加载中、空数据、正常数据、超长数据、错误状态。假设首页数据来自缓存、详情页数据来自实时请求，那么同一组件在首页可能先显示旧内容再刷新，在详情页则直接显示最新内容。验收样例要分别记录首次渲染和刷新后的表现。
实施动作：为每个页面标注数据来源和状态切换时机，构造对应的状态样例。结果如何影响下一步——如果差异只出现在缓存刷新阶段，就应把验收重点放在状态过渡，而不是静态布局。
把角色分歧转成可核对项目的具体做法
设计说“间距不对”，前端说“代码没改”，测试说“我这边正常”，这类分歧往往因为三方看的页面不同。可以按下面顺序转成可核对项目：
- 让每个角色写出自己观察到的页面、容器宽度、内容长度和数据状态，而不是只写结论。
- 把相同描述合并成一组验收样例，给每组编号。
- 每组样例只保留一个变量，例如只改内容长度，不改宽度和状态。
- 记录实际结果与预期结果的差异点，差异点要具体到换行、截断、间距或点击区域。
这样做的结果是，分歧从“谁对谁错”变成“哪组样例在哪个变量下不一致”，下一步就能直接定位到页面配置或组件实现。
哪些情况不应套用这套样例构造方式
如果组件只在一个页面出现，且没有复用计划，就不必为多页面上下文构造样例，直接按该页面的真实内容长度和状态验收即可。如果差异来自浏览器或系统版本，而不是页面上下文，那么验收样例应改为“浏览器版本 + 页面”的组合，而不是容器宽度或数据状态。例外还在于：当页面本身仍在频繁改版、容器宽度尚未确定时，过早固定样例可能很快失效，此时应先稳定页面布局，再补验收样例。
一个注明假设的短例子
假设某移动端建站项目的按钮组件在活动页显示为通栏，在个人中心显示为半宽。设计认为按钮高度不一致，前端认为代码相同。此时构造两组样例：活动页通栏宽度、个人中心半宽宽度，分别注入相同文案。若两组高度不同，再检查容器是否设置了不同的行高或内边距。若高度相同，则差异可能来自文案长度或图标有无。这个例子只用于说明比较方法，不代表真实项目结果。
验收样例的价值不在于覆盖所有页面，而在于让每个差异都有可复现的条件。先固定变量，再记录结果，最后决定改组件还是改页面上下文，这样同一组件在不同页面的表现差异才能被稳定核对。
