营销网站建设：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ed5f1876ae46.html
📄
营销网站建设：同一组件在不同页面表现不同时怎样构造验收样例
先给结论：不要为“组件本身”写一份通用验收样例，而要为“组件所处的页面上下文”分别写样例。同一个表单、卡片或导航组件，在首页、栏目页和详情页里承载的任务不同，验收判定也应不同。可行的做法是保留组件的核心契约，改写与页面任务绑定的表现项，退出那些把组件孤立起来测的旧样例。
先判断差异来自组件本身还是页面上下文
同一组件表现不同，通常有三类可区分的原因。第一类是数据差异：首页只展示三条摘要，详情页要展示全量字段，组件在长内容下的折行、截断和空态就会暴露问题。第二类是容器差异：侧栏宽度、栅格列数和页面留白不同，组件的换行点和点击区域随之变化。第三类是交互路径差异：同一个筛选组件在列表页承担主操作，在详情页只是辅助入口，用户对它的期待不同。
判断方法很简单：把组件放到一个最小空白页里，喂入与目标页面相同的数据和容器宽度。如果最小页里表现正常，回到原页面就异常，问题多半在页面上下文，验收样例就该按页面写。如果最小页里同样异常，问题在组件契约，应该回到组件层修正，而不是给每个页面各写一份补丁样例。
保留：组件级契约仍然值得单独验收
保留组件级样例的前提是，这些样例只验证与页面无关的稳定契约。适合保留的项目包括：必填与选填字段的提交行为、键盘可聚焦顺序、错误提示是否与输入项关联、空数据与超长文本下的兜底显示。这些项目在任何页面都应一致，一旦不一致就是缺陷，而不是“页面特色”。
保留的代价是维护成本。组件每改一次，组件级样例都要回归。因此只保留那些一旦破坏就会影响多页面的项目，不要把颜色、间距、圆角这类随页面主题变化的视觉项写进组件级样例。判断标准可以设为：如果这个项目在某个页面合理地不同，它就不属于组件级契约。
改写：把表现项绑定到页面任务上
改写适用于组件核心行为不变、但表现要求随页面变化的项目。例如同一个商品卡片，在首页承担引流，需要突出主图和标题；在搜索结果页承担比较，需要露出价格和关键属性；在详情页的相关推荐里只承担补充，信息密度可以更低。这时不该问“卡片应该显示几行”，而该问“这个页面上的卡片要帮用户完成什么判断”。
改写后的验收样例应写成“在什么页面、什么数据、什么视口下，观察到什么结果”。可执行的动作是：为每个页面各取一条真实长度的数据，在目标视口下检查截断位置、点击区域和溢出情况，记录结果。如果某页出现内容被裁切但无法展开，就回到该页的样例补充展开或跳转要求，而不是修改组件全局样式。这样做的结果是，后续同类页面可以直接复用该页样例，减少重复判断。
一个注明假设的短例子
假设某营销站点有一个咨询表单组件，首页放在首屏右侧窄栏，联系页放在主内容区全宽。可以这样构造两条样例：首页样例使用窄栏宽度和三条简短字段，验收重点是首屏内是否完整可见、按钮是否无需滚动即可点击；联系页样例使用全宽和带说明文字的长字段，验收重点是标签与输入框的对应、错误提示是否把页面撑开。两条样例共享同一份提交与校验契约，只在布局和可见性上分开判定。这只是说明比较方法的假设例子，不代表任何具体项目的实测结果。
退出：删除那些无法指导决定的旧样例
需要退出的样例有两类。一类是只记录“看起来正常”的截图式样例，没有说明数据长度、视口和页面任务，换一个页面就无法判断对错。另一类是重复覆盖同一契约的样例，比如每个页面都重测一遍必填校验，除了增加回归时间，不会带来新的判断依据。
退出的前提是先确认该契约已被组件级样例覆盖，且该页面的特殊表现已有对应页面样例。如果某个页面确实存在独特风险，比如表单嵌在弹层里、卡片处于横向滚动容器中，就不能退出，而应把它升级为独立的页面样例。动作上可以先标记待退出样例，观察一个迭代周期内是否出现过相关缺陷；若没有新的判断需求，再删除。注意，某段时间内没有报错，并不能单独证明样例多余，也可能只是该路径访问量低或未被覆盖，因此要结合路径重要程度决定。
落到验收清单时的取舍顺序
- 先列组件在所有页面都必须一致的项目，写成组件级样例。
- 再按页面任务列出会合理不同的表现项，每页各写一条带数据和视口的样例。
- 对每个差异点追问一次：是数据、容器还是交互路径造成的，据此决定改组件还是改样例。
- 删除无法复现判断条件的旧样例，保留能指向下一步动作的样例。
按这个顺序执行后，验收样例的数量不会随页面数量线性膨胀，同时每个页面的关键差异仍被覆盖。下一步可以把这些样例并入上线前的检查流程，并在组件变更时只回归受影响的页面样例，而不是全量重跑。
