先给结论:不要为每个页面各写一份验收样例,也不要只测组件库里的独立演示页。正确做法是把组件放回至少两个真实页面的上下文,用同一组输入分别渲染,再对比差异。验收样例要记录的是“输入相同、输出不同”的那部分上下文变量,而不是组件本身的视觉参数。只有把页面级上下文当作样例的一部分,才能复现并定位问题。
“同一组件在不同页面表现不同”这句话本身可能包含误判。在动手构造样例前,先用一个可重复的动作验证:在同一浏览器、同一视口宽度、同一登录状态下,依次打开两个页面,把组件所在区域的截图并排保存。如果截图显示差异,再检查两页是否引用了同一版本的组件资源。若一页加载的是构建产物,另一页仍引用旧缓存或不同入口文件,那这不是组件行为差异,而是资源版本差异。
假设一个场景:某营销站的联系表单组件在首页显示为两列,在活动落地页显示为单列。截图确认差异后,先查看两页的网络请求列表,比较表单样式文件的哈希或版本标识。如果哈希不同,问题在发布流程;如果哈希相同,才进入下一步的页面上下文分析。
差异确认后,通常只剩两类解释。
这两类解释的修复方向完全不同:前者要改页面传参或样式作用域,后者要改布局约束或加载顺序。如果验收样例不区分它们,测试就会反复在“组件没问题”和“页面没问题”之间打转。
能区分上述两种解释的证据,是“把组件从页面上下文中抽离后,差异是否消失”。具体动作分三步:
这个动作的结果直接决定下一步:上下文问题改容器和层叠顺序,属性问题改页面调用方式,全局状态问题则要收敛组件的副作用。
验收样例不是“打开首页看看”,而是一份可交给他人复现的最小组合。每个样例至少包含:页面路径、视口宽度、组件所在容器的约束条件、传入的属性值、预期输出。两个页面各写一份,并标注哪些字段相同、哪些不同。
假设一个短例子:首页容器宽度为 1200px,落地页容器宽度为 720px,组件属性均为默认值。如果差异只在窄容器中出现,那么样例应固定“容器宽度”为变量,其他字段保持一致。运行后若窄容器下组件换行,而宽容器下不换行,就能确认是容器约束导致的布局分支,而不是组件缺陷。此时下一步不是改组件,而是决定窄容器下是否需要单独的布局属性。
上述方法成立的前提是:两个页面确实引用了同一版本的组件资源,且测试环境一致。如果资源版本不同,先统一发布产物再谈验收样例。另外,验收样例只覆盖你已识别的上下文变量;若页面还存在异步注入的样式或脚本,需要把加载完成作为样例的前置条件,否则对比结果不可靠。把这些条件写进样例说明,比在结论里补一句“环境不同”更有用。