淮北网站开发：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /68a0f7fd5017.html
📄
淮北网站开发：同一组件在不同页面表现不同时怎样构造验收样例
先给结论：不要试图找一个“能复现全部页面”的样例，而应按组件所处的上下文分组，为每组构造最小验收样例，并明确哪一组是基线、哪一组是例外。下面用一个假设情境把决策过程走一遍。
先判断差异来自组件本身还是页面上下文
假设某淮北网站开发项目里，旧系统要退出，但其中一套筛选组件仍有价值，需要迁移到新页面。迁移后发现：同一筛选组件在列表页正常，在详情页的推荐区却出现选项错位、默认值丢失。此时第一步不是改组件，而是区分两类原因。
- 组件自身原因：同一份代码、同一份数据，在任何容器里都错。证据是差异随组件版本变化，而不随页面变化。
- 页面上下文原因：只在特定页面错。证据是同一版本组件换到另一个容器就恢复正常，差异随外层布局、数据源或初始化时机变化。
可区分的动作：把组件原样放进一个空白测试页，只给最小数据。如果空白页正常，说明问题在页面上下文；如果空白页也错，才回到组件内部排查。这一步的结果直接决定后续验收样例该围绕“组件参数”还是“页面容器”来写。
按上下文分组，而不是按页面逐个枚举
页面数量多时，逐页写验收样例成本高且容易漏。更稳的做法是按会改变组件行为的上下文因素分组。常见因素有三类：容器宽度区间、数据来源、初始化时机。
- 容器宽度：窄栏、主内容区、全宽区各取一个代表页面。
- 数据来源：静态配置、接口返回、本地缓存各取一个代表页面。
- 初始化时机：首屏渲染、异步加载后渲染、用户交互后渲染各取一个代表页面。
每组只保留一个最小样例，记录该组的预期表现。这样验收样例的数量与上下文种类挂钩，而不是与页面总数挂钩。对于要退出旧系统的项目，这也能顺带确认：旧页面里哪些上下文其实已经不再出现，可以直接随旧内容一起下线。
给每组样例写明前提、动作和判定依据
验收样例要能被别人重复执行，必须写清三件事：前提、动作、判定依据。以筛选组件为例，一个假设样例可以这样写：
前提：详情页推荐区宽度约为主内容区的一半，数据来自接口，组件在页面主体渲染完成后初始化。动作：打开该页面，等待推荐区出现，点击任一筛选项，再刷新页面。判定依据：选项顺序与接口返回一致；刷新后默认值恢复为配置值，而不是上次点击值。
判定依据要写成可观察的结果，而不是“显示正常”。可观察结果包括：选项数量、顺序、默认值、空状态文案、加载中状态是否出现。若某项无法观察，就说明该样例还需要补充可观察的替代指标。
用基线样例控制例外，避免验收范围失控
构造样例时先确定一个基线组，通常选最接近组件原始设计意图的上下文。其他组作为例外，只在确有页面使用时才保留。判断某个例外是否值得保留，可以问两个问题：这个上下文在新站里还会出现吗？如果出现，是常态还是边缘情况？
如果某例外只来自即将退出的旧页面，就不必为它写验收样例，直接随旧内容下线。如果例外来自仍在使用的合作关系页面，则保留样例，并在样例中注明它依赖的外部条件。这样做的结果是：验收清单既覆盖真实使用场景，又不会因为迁就旧系统而无限膨胀。
样例执行后的结果如何影响下一步
执行完一轮样例后，通常会出现三种结果，对应三种下一步。
- 基线与例外都通过：组件可以按当前范围迁移，旧系统中不再出现的上下文可以进入下线清单。
- 只有例外失败：优先判断该例外是否必须保留。必须保留则调整页面容器或初始化方式；不必保留则删除该用例，并在下线记录中写明原因。
- 基线也失败：暂停迁移，先修组件本身。此时继续增加页面级样例没有意义，因为失败原因不在页面上下文。
需要提醒的是，某个页面抓取量下降或某类请求归零，不能单独证明组件迁移正确。它也可能是页面本身退出、入口调整或数据统计口径变化造成的。验收结论仍应以样例中可观察的组件行为为准，再结合这些现象做交叉判断。
