结论先给:如果同一组件在不同页面的差异来自页面传入的数据或容器宽度不同,验收样例应当按“页面角色×数据形态”组合构造,而不是只挑一个页面反复看;如果差异来自组件本身在某个页面被二次覆盖了样式或脚本,那么继续加样例没有意义,应先定位覆盖来源。判断走哪条路,取决于你能否在改动组件之前复现出差异。
同一组件在列表页、详情页、活动页表现不同,常见原因有两类。第一类是输入不同:详情页给组件的标题更长、图片比例更特殊、字段可能为空;列表页给的是短标题和固定缩略图。这类差异是组件对真实数据的响应,验收样例要覆盖数据边界。第二类是环境不同:某个页面额外加载了一段样式,或把组件包在更窄的容器里,甚至重复引入了同一份脚本。这类差异是页面污染,样例再多也只能证明“这个页面有问题”,不能证明组件本身合格。
区分方法很直接:把出问题的页面结构复制到一个空白模板,只保留组件和它的数据,看差异是否还在。如果消失,说明是页面环境造成的;如果仍在,说明是组件对数据或容器宽度的处理问题。这一步的产出会直接决定下一步动作——前者去查覆盖,后者去补样例。
当确认是输入差异后,样例不应按“每个页面各截一张图”来组织,而应按两个维度交叉:
假设一个产品卡片组件,详情页标题可能长达三十个汉字,列表页只有八个字。那么至少要构造四组样例:短标题加方图、长标题加方图、长标题加竖图、字段缺失。每组在列表容器和详情容器各看一次。这样得到的不是“哪个页面好看”,而是“组件在哪些输入组合下会溢出、错位或塌陷”。
如果资源有限,优先覆盖最长的文本和最窄的容器这两个极端,因为大多数表现差异都出现在边界处,而不是平均值处。
如果差异只在某个页面的特定浏览器或特定登录状态下出现,那么按页面角色和数据形态构造样例就不成立。此时问题不在组件对数据的响应,而在该页面的加载顺序、条件渲染或缓存。继续扩充数据样例只会浪费时间,正确动作是固定浏览器和登录状态,逐项排除脚本加载顺序,再回到组件本身。
另一个反例是:差异出现在组件被复用多次的同一页面内。这时页面角色维度失效,因为同一页面里就有多个容器,验收样例应以容器宽度和相邻元素为维度重新组织。
样例要能被执行,而不只是被描述。建议每条样例写成“容器宽度 + 数据输入 + 预期表现”的形式,例如:
执行时记录实际表现与预期的偏差,偏差项就是下一步要修的位置。修完后只重跑受影响的样例,而不是全部重来。这样一轮验收的产出是“哪些输入组合需要改组件”,而不是“哪个页面看起来不对”。
先做一次空白模板复现:把出问题的页面剥到只剩组件和数据。如果差异消失,去查该页面的样式覆盖和脚本重复引入,修完后在原始页面复验一次;如果差异仍在,按容器宽度和数据形态补齐样例,把偏差清单交给改组件的人。这个顺序能避免在错误的方向上反复截图比对。