建站推广方案，同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /852bd1e30158.html
📄
建站推广方案，同一组件在不同页面表现不同时怎样构造验收样例
验收样例要先把“组件本身”和“组件所处页面条件”分开。同一组件在A页正常、B页异常，通常不是组件坏了，而是B页缺少某个前置条件。构造样例时，应针对两种页面条件各写一组可复现的输入与预期输出，而不是只截一张异常图当作验收依据。
先判断差异来自组件还是页面条件
把差异归因前，先做一次最小对照：同一个组件在A页和B页分别加载，保持浏览器、账号、时间窗一致，只改变页面。若A页正常、B页异常，优先怀疑页面级条件，包括：
- 容器宽度或父级样式覆盖了组件的默认布局；
- B页先加载了另一个同名脚本或样式，造成覆盖；
- B页在组件初始化前就触发了交互，导致状态错位；
- B页的数据源字段缺失，组件拿到空值后走了不同分支。
若两页条件一致但表现仍不同，才把组件自身作为主要怀疑对象。这一步的判断结果直接决定验收样例写在哪一层：页面级条件成立时，样例必须包含“页面环境”这一输入项；组件级问题成立时，样例才聚焦组件参数。
两种条件下的验收样例写法
条件一：差异可稳定复现，且能定位到某个页面条件。此时样例写成“环境 + 输入 + 预期输出”三段式。假设某筛选组件在列表页正常、在详情页不响应，样例可以这样写：
- 环境：详情页，父容器宽度小于组件最小宽度，页面已加载两个版本的选择器脚本；
- 输入：点击筛选按钮，选择第二项；
- 预期输出：按钮进入选中态，列表区域按第二项过滤，控制台无脚本报错。
执行这条样例后，如果结果与预期不符，下一步不是改组件，而是先移除B页多加载的那个脚本再跑一次。若移除后恢复正常，验收样例就应补一条“禁止重复引入”的检查项，而不是把修复动作写进组件代码。
条件二：差异只在特定数据或特定操作顺序下出现。此时样例要写成“操作序列 + 中间状态 + 最终预期”。假设组件在直接进入B页时正常，但从A页跳转进入B页时异常，样例应记录跳转来源、跳转时携带的参数、B页首次渲染时的组件状态。执行后若异常只在带参数跳转时出现，下一步应检查参数解析逻辑，而不是调整组件样式。
样例里必须写清的三个字段
很多验收样例失败，是因为只写了“点击后应正常”，没有写清前置状态。可复用的样例至少包含：
- 初始状态：页面URL特征、已加载资源、组件初始值；
- 触发动作：点击、滚动、输入或跳转，写清顺序；
- 可观察结果：DOM变化、可见文本、请求是否发出、是否报错。
可观察结果要选一个能区分对错的信号。例如“列表刷新”太模糊，“列表首项文本由X变为Y”才能判定通过。若某个信号在两种条件下都会出现，它就不能作为区分依据。
什么情况下样例需要例外分支
不是所有差异都要修。若B页的异常表现属于已知的降级路径，例如组件在窄容器下改为折叠展示，这属于设计允许的例外，不应写成缺陷。此时验收样例应写成两条：一条验证正常条件下的完整交互，一条验证窄容器下的降级展示，并注明降级是预期行为。
判断例外是否成立，看它是否有明确触发条件和可接受的输出。若触发条件写不出来，或输出无法用文字描述，它更可能是缺陷而非例外。把例外写进样例后，后续修改若改变了触发条件，样例必须同步更新，否则验收会失效。
从样例结果决定下一步动作
跑完样例后，按结果分三种走向：
- 两种条件都通过：记录当前环境与数据版本，作为回归基线；
- 仅一种条件失败：把失败条件补进样例，修复后重跑该条件，不改动已通过条件的样例；
- 两种条件都失败：说明问题在组件或公共依赖，先回退到最近一次通过的环境再定位。
关键动作是：每次修复只改一个变量，并保留修复前的样例记录。这样当下一次同一组件在第三个页面出现差异时，可以直接比对已有样例，判断是新条件还是旧问题复发，而不是从头再猜一遍。
