商业网站建设：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9309181f6ef7.html
📄
商业网站建设：同一组件在不同页面表现不同时怎样构造验收样例
先给结论：不要为“组件本身”写一份通用验收样例，而要为“组件在页面中的上下文”各写一份。同一组件在A页正常、B页异常，通常不是组件坏了，而是页面给了它不同的输入：容器宽度、继承样式、数据条数、加载顺序、权限状态。验收样例要能区分这些解释，否则你改的是组件，坏的是页面。
先判断该保留、改写还是退出这个组件方案
三种取舍的适用前提不同，不要同时做。
- 保留：组件在多数页面表现一致，只有个别页面异常，且差异能追到页面级输入。此时保留组件，补页面级验收样例即可。
- 改写：多个页面都出现同类偏差，且每次都要在页面里写覆盖样式或补丁逻辑。说明组件缺少必要的可配置项，应把差异收进组件参数。
- 退出：该组件依赖的上下文在目标页面无法稳定提供，例如容器宽度不可控、数据结构差异过大。继续保留只会让每个页面都变成特例。
判断依据不是“改起来麻烦不麻烦”，而是异常是否可被页面级输入解释。能被解释，就保留并补样例；不能被解释，才考虑改写或退出。
把“表现不同”拆成可核对的证据
先固定一个组件，再收集三类证据，避免把猜测写成结论。
- 输入证据：传入的数据条数、字段是否为空、图片比例、文本长度上限。
- 环境证据：所在容器的可用宽度、父级字号与行高、是否处于弹层或折叠区域。
- 时序证据：组件渲染时数据是否已就绪、异步内容是否改变高度、字体加载是否影响换行。
实际操作：在异常页面和正常页面各记录一次上述三项，做成两列对照。如果只有一项不同，下一步就只针对该项构造样例；如果多项同时不同，先固定其余项，只留一项变化，否则无法归因。
假设一个例子：某卡片组件在列表页显示正常，在详情页侧栏被压成两行。对照后发现侧栏可用宽度更小、标题字段更长，其余相同。此时把宽度和文本长度分别作为单一变量各测一次，就能判断是宽度不足还是文本过长触发。这个例子只说明比较方法，不代表任何真实项目结论。
验收样例的最小结构
每份样例应包含四段，缺一段就会留下争议空间。
- 前置条件：页面、容器、数据状态、登录或权限状态。
- 操作：加载、滚动、切换标签、改变视口宽度等具体动作。
- 可观察结果：写清看什么，例如换行位置、是否出现截断、按钮是否仍可点击。
- 判定边界：允许的偏差范围，以及超出后算失败。
注意“可观察结果”不要写成“显示正常”。正常不是证据。写成“标题在两行内完整显示，无省略号，右侧操作区不重叠”，才能被不同的人重复核对。
按页面上下文分组，而不是按组件分组
组件级样例只能证明组件单独可用，不能证明它在页面里可用。更稳的做法是按上下文分组：
- 宽容器 + 短文本
- 宽容器 + 长文本
- 窄容器 + 短文本
- 窄容器 + 长文本
- 空数据或单条数据
- 异步内容延迟到达
不必每组都测，但至少要覆盖你实际会遇到的极端组合。哪一组失败，就说明该组合缺少约束，而不是组件整体不可用。这个分组的价值在于：失败时你能直接说出是哪一类页面需要补规则。
用结果决定下一步动作
执行样例后，结果只指向三种动作之一。
- 只有窄容器失败：在组件层设定最小可用宽度，或要求页面保证容器下限，并把该下限写进样例。
- 只有长文本失败：给标题设定行数上限与截断规则，样例中固定文本长度区间。
- 多组同时失败且原因分散：停止逐页修补，回到组件接口，把宽度、行数、数据条数变成显式参数。
关键动作是：每次只改一个变量，然后重跑同一组样例。如果改完后失败组没有减少，说明你的解释不成立，应回到证据收集而不是继续加样式。若失败组减少但出现新的失败组，说明约束生效但引入了新边界，需要把新边界补进样例，再决定是否继续保留该组件。
最后提醒一点：请求量、抓取量或某项统计归零，不能单独证明组件处理正确，它也可能是页面未被访问、数据未上报或缓存命中造成的。验收样例要盯住页面上的可观察结果，而不是把某个指标当作唯一裁判。
