先给结论:不要试图构造一个“放之四海而皆准”的验收样例,而是按组件所处的位置分成两类分别验收。当组件出现在模板直接控制的区域(如归档页循环、单篇正文区)时,验收样例应固定模板上下文,只变数据源;当组件出现在编辑者自由插入的区域(如区块编辑器中的可复用区块、短代码、小工具)时,验收样例应固定数据,只变宿主页面。两类样例不能混用,否则你测的其实是页面环境,而不是组件本身。
表现差异通常来自渲染上下文,而不只是数据。判断依据是:这个组件的输出位置由主题模板决定,还是由编辑者在某篇内容里手动放置决定。
两者的差异来源不同:模板托管更容易受查询对象、分页状态、条件判断影响;内容托管更容易受宿主页面宽度、已有区块顺序、是否处于嵌套容器影响。混淆这两类,就会出现“在归档页正常、在单篇页错位”却找不到原因的反复返工。
如果组件由模板输出,验收样例应当锁定模板文件与查询参数,只替换数据。具体动作如下。
这样做的结果:如果只有“无缩略图”那条出错,问题就落在组件的空值分支,而不是模板或查询。下一步只需修组件的兜底逻辑,不必动模板。假设某归档页每页显示 10 条,其中 3 条无缩略图,若这 3 条造成卡片高度塌陷,那么验收样例就应把“无缩略图”作为必测项,而不是等到上线后才发现。
如果组件由编辑者插入内容,模板不确定,验收样例应当锁定同一份组件数据,把它放进不同的宿主页面。具体动作如下。
这样做的结果:如果最小页面正常、分栏容器中溢出,问题就落在组件的响应式假设或容器的宽度约束上。下一步是给组件加容器无关的宽度策略,而不是改宿主页面。假设同一价格表组件在整宽页面表现正常,在二分之一栏中横向溢出,那么验收样例就应把“二分之一栏”作为必测宿主,而不是只测整宽。
构造样例时,至少要有一组能区分原因的证据,否则容易把页面环境问题误判为组件缺陷。
注意:请求量、抓取量或某项统计归零不能单独证明组件处理正确。页面未被访问、缓存未命中、统计脚本未加载,都可能导致同样的归零现象。验收样例应基于可复现的页面输出,而不是单一指标。
如果组件本身依赖页面级状态,例如只在特定分类下显示、只在登录状态下渲染、只在特定语言版本出现,那么上面的拆分不成立。此时验收样例应把“状态”作为第三个变量,先固定状态再变数据或宿主,否则你无法判断差异来自状态还是来自页面。
另一个例外是组件已经被大量页面复用且无法逐页回退。这种情况下,先构造一个隔离的验收环境,把组件单独渲染,确认基线表现,再回到真实页面观察差异。隔离环境确认的是组件下限,真实页面确认的是集成结果,两者都需要,但不能互相替代。
实际动作上,建议先写一张验收样例表,列出每个样例的模板、数据、宿主和预期输出,再逐条执行。这样做的结果是:当同一组件在不同页面表现不同时,你能明确知道是数据分支、宿主环境还是页面状态在起作用,从而决定是修组件、修容器,还是修状态判断,而不是反复猜测并改动模板。