渭南建网站：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /61ee568a0b0f.html
📄
渭南建网站：同一组件在不同页面表现不同时怎样构造验收样例
先确认差异是否可复现，再决定验收样例是补一组对照条件，还是把组件本身退回修改。同一个组件在A页正常、B页异常，最常见的原因不是组件代码坏了，而是B页给它提供了不同的上下文。验收样例要做的，是把这些上下文差异固定成可重复的输入，让每次判断都有同一把尺子。
先分清两种解释：组件缺陷还是环境差异
第一种解释是组件自身有缺陷，只是A页恰好没触发。第二种解释是组件本身没问题，但B页的容器宽度、数据形态、权限状态或加载顺序与A页不同。两者在现象上可能完全一样，但处理方向相反：前者要改组件，后者要改调用方式或页面条件。
区分的关键不是看哪个页面“更正常”，而是看差异是否随条件移动。如果把B页的某个条件搬到A页，异常跟着搬过去，说明问题在条件；如果条件不变、只换组件版本就复现或消失，说明问题在组件。验收样例必须能承载这两种对照。
把差异拆成可复制的输入条件
不要只记录“B页显示错位”这类结论，要记录能重建现场的输入。对多数网站组件，以下四类条件足以覆盖大部分差异来源：
- 容器条件：父级宽度、内边距、是否处于栅格或弹性布局中。
- 数据条件：字段是否为空、超长、含特殊字符、条数是否超过一屏。
- 状态条件：登录与否、角色权限、是否首次访问、是否已提交过表单。
- 时序条件：组件是在首屏同步渲染，还是等接口返回后再插入。
每一项都要写成可切换的开关，而不是描述性文字。例如“数据超长”要给出具体字符数区间，“容器偏窄”要给出具体像素范围。这样验收样例才具备可重复性。
构造最小对照样例的具体动作
假设一个列表组件在“产品列表页”正常，在“案例详情页”的侧栏里出现高度塌陷。先不要改代码，按下面顺序做一次对照：
- 把侧栏容器的宽度临时改成与产品列表页主栏一致，刷新观察。若恢复正常，记录“容器宽度”为可疑条件。
- 把案例详情页传给组件的数据替换为产品列表页的同结构数据。若仍异常，排除数据形态；若恢复正常，记录“数据条数或字段长度”为可疑条件。
- 把组件从异步插入改为首屏同步渲染。若异常消失，记录“加载时序”为可疑条件。
每一步只改一个条件，改完立即记录结果。这个动作的价值在于：它能告诉你下一步该验证哪个条件，而不是同时改三处然后猜是哪一处起了作用。如果三步都未能复现或消除异常，才把组件本身作为主要怀疑对象，进入代码层排查。
验收样例要写成可执行的三段式
一个能用于验收的样例，至少包含前提、操作、判定三部分。前提写清页面、容器、数据和状态；操作写清做什么、按什么顺序；判定写清什么算通过、什么算失败。例如：
前提：案例详情页侧栏，容器宽度小于某个阈值，数据条数为零。操作：直接打开页面，不滚动。判定：组件区域高度不为零且不遮挡相邻内容为通过；出现重叠或高度为零为失败。
判定标准要能被不同人重复执行。如果只能靠“看起来不对”来判断，这个样例还不合格。把主观描述换成可观察的现象，比如高度、是否重叠、是否可点击、是否出现滚动条。
什么情况下应该改组件，什么情况下应该改页面
当同一条件在多个页面都触发同一异常，且该条件属于组件的合理使用范围时，优先改组件。当异常只在特定页面、特定容器或特定数据下出现，且该页面属于少数用法时，可以改页面调用方式，但要在验收样例里保留这个页面作为回归项。
判断依据是使用范围，不是修改成本。如果某个条件在未来会被更多页面用到，即使当前只有一个页面触发，也应该在组件层解决，否则每新增一个页面就要重新处理一次。反之，如果该条件只属于某个页面的特殊布局，改页面更直接，但要防止后续改版时把这个特殊条件丢掉。
把结论固化成回归清单
每次定位到一个差异条件，就把它追加到该组件的回归样例里。清单不需要很长，但要覆盖已经出现过问题的条件组合。下次改组件或改页面布局时，先跑这份清单，再决定是否需要新增样例。
这样做的结果是：同一组件在不同页面的表现差异，从“每次都要重新排查”变成“按已有样例逐项确认”。验收样例的作用不是证明组件没问题，而是让问题在固定条件下暴露，从而让修改有明确目标。
