cms建站教程：同一组件在不同页面表现不同时怎样构造验收样例

📍 WDQWDWQD987AAAAA:216.73.217.85
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /de6195def59f.html
📄

cms建站教程：同一组件在不同页面表现不同时怎样构造验收样例

先给结论：不要试图用一份“全站统一”的组件验收样例去覆盖所有页面，而应先按“组件是否带页面级上下文”分成两类。带上下文的组件（如面包屑、相关推荐、表单回填）必须按页面类型分别造样例；不带上下文的纯展示组件（如按钮、标签、分隔线）可以共用一组基线样例。验收样例的目标不是证明组件好看，而是让同一组件在不同页面上的差异变成可复现、可判断的条目。

先判断差异来自组件本身还是来自页面上下文

同一组件表现不同，常见原因有三类：一是组件读取了页面级数据（分类、语言、登录态、父级栏目）；二是组件被不同模板或不同容器包裹，继承到的宽度、字体、间距不同；三是数据源本身不同，比如同一推荐位在不同栏目取的是不同内容集合。构造验收样例前，先做一次归因，否则样例只会把现象抄一遍。

可区分证据可以这样收集：把同一组件在两个页面上的渲染结果并排看，若差异只在文案和数据，通常归因于数据源；若差异在字号、行高、折行、溢出，通常归因于容器与样式继承；若差异在是否出现、出现几项，通常归因于页面级条件判断。归因不同，验收样例的写法也不同。

条件一：组件带页面级上下文，按页面类型分别造样例

当组件依赖页面上下文时，一份样例不足以验收。正确做法是按“页面类型 × 关键变量”建最小样例集。假设一个面包屑组件，在文章页显示“首页 > 栏目 > 文章”，在栏目页显示“首页 > 栏目”，在搜索结果页不显示。那么验收样例至少要有三条，分别对应三种页面类型，并写明预期结果。

实施动作可以固定为：为每个页面类型准备一个可长期访问的测试页面，记录该页面上组件的预期结构（层级数量、是否显示、链接指向规则）。验收时逐条比对，而不是全站随机点。这样做的结果是把“某页面看起来不对”转成“某页面类型缺少第二级”，下一步就能直接定位到模板条件或数据映射，而不是反复刷新猜测。

例外情况：如果页面类型过多，不必穷举所有组合。优先覆盖会改变组件结构或可见性的变量，例如登录态、语言、是否首屏。仅改变文案的变量可以合并到同一类样例中，用其中一条代表。

条件二：组件不带页面级上下文，用基线样例加容器差异样例

纯展示组件可以共用一组基线样例，但仍需补一组“容器差异样例”，因为同一按钮放在主栏和侧栏、放在卡片内和卡片外，表现可能不同。基线样例固定组件自身的预期：默认态、悬停态、禁用态、长文案折行。容器差异样例固定它被放进窄容器、宽容器、带内边距容器时的预期。

验收时先跑基线，再跑容器差异。若基线通过而容器差异失败，问题在页面布局或样式作用域，不在组件逻辑；若基线就失败，先修组件本身，不要急着改页面。这个顺序能避免把布局问题误判成组件缺陷，也能避免为了迁就某个页面而改坏其他页面。

把差异写成可判定的验收条目

好的验收样例应当写成“在什么页面条件下，组件应呈现什么可观察结果”。可观察结果包括：是否出现、出现数量、文本内容、链接目标、是否折行、是否溢出容器、点击后的跳转目标。避免写“显示正常”“样式统一”这类无法判定的描述。

假设一个表单组件在联系页和注册页表现不同：联系页不显示验证码，注册页显示。若只写“表单显示正常”，验收时无法判断哪个页面该有验证码。改成两条样例后，失败信息会直接指出是注册页缺少验证码，还是联系页错误显示验证码，下一步动作随之明确。

旧内容或旧合作关系退出时，样例如何取舍

当旧页面、旧模板或旧数据源准备退出，验收样例不应全部保留。先标记哪些样例验证的是即将下线的页面类型，哪些验证的是仍然保留的公共组件。对即将下线的页面类型，样例可以归档但不再执行；对仍然保留的公共组件，样例必须继续跑，并补一条“旧页面移除后组件仍正常”的回归样例。

动作上，可以先冻结新样例的添加，集中确认保留组件的基线是否仍然通过。若旧页面移除后某个组件不再被任何保留页面引用，可以连同其样例一起停用；若仍被引用，则样例保留，并检查它是否还依赖已下线的数据源。这样处理的结果是验收范围随退出动作收缩，而不是留下一堆永远失败的旧样例干扰判断。

需要说明的是，页面访问量下降或某个入口不再出现，并不能单独证明旧内容已经安全退出，也可能是缓存、跳转或统计口径造成的。判断退出是否完成，仍要以保留页面的组件验收结果为准。

图1 图2
nginx