建站教程：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /11f0d5ed611e.html
📄
建站教程：同一组件在不同页面表现不同时怎样构造验收样例
先给有条件的结论：如果同一组件在不同页面的差异来自数据形态、容器宽度或交互状态，而不是组件代码本身，那么验收样例应当按“页面条件组合”来构造，而不是只截一张正常页面的图。反例是：如果差异只在某一个浏览器出现，且换数据、换容器都复现，那么问题更可能在渲染或兼容层，此时按条件组合做样例会掩盖真正原因，应该先做最小复现页。
先确认差异是内容条件还是环境条件
把同一组件的差异分成两类来记录。内容条件包括字段长度、是否为空、图片比例、列表条数、富文本里有没有表格或代码块。环境条件包括容器宽度、页面是否带侧栏、是否处于弹窗或折叠区域、用户是否已登录、是否处于加载或错误状态。
一个实际动作是：在出现差异的两个页面上，分别用浏览器开发者工具临时把容器宽度改成相同值，再刷新。如果差异消失，说明问题主要来自容器宽度；如果差异仍在，继续检查数据。这个动作的结果决定下一步：前者要把宽度断点写进验收样例，后者要把具体数据样本固定下来。
需要注意，刷新后差异消失不能单独证明组件本身没有问题。缓存、异步加载顺序、字体加载时机都可能造成类似现象。因此至少要重复两次，并记录是否在无缓存模式下仍能复现。
用条件组合表代替零散截图
验收样例的目标是让不同角色对同一事实有可核对的依据。可以按下面的结构整理，不必追求覆盖所有组合，但每个组合都要能回答“在什么条件下，期望看到什么”。
- 条件一：数据最短与最长。用真实字段的最小值和最大值各一条，注明假设来源。
- 条件二：容器最窄与最宽。取页面实际会出现的最小宽度和最大宽度，而不是设计稿的固定宽度。
- 条件三：交互初始态与展开态。例如折叠面板收起和展开后，组件高度变化是否影响相邻元素。
- 条件四：异常态。字段为空、图片加载失败、接口返回错误时，组件是否仍保持可读和可操作。
每个组合写一条可观察的期望，例如“在窄容器且字段最长时，标题最多换两行，不遮挡操作按钮”。期望要能被另一个人独立核对，而不是写“显示正常”。
把分歧转成可核对的项目
当设计、开发和内容角色对同一组件表现有不同理解时，不要继续争论“应该是什么样”，而是把分歧拆成三个可核对项：触发条件、观察位置、判定标准。
假设一个场景：列表页的卡片组件在首页显示为三列，在详情页相关推荐里显示为两列，开发认为这是正常响应式行为，设计认为间距不一致。此时可以构造一个验收样例：固定浏览器宽度为 1280 像素，分别打开首页和详情页，测量卡片之间的水平间距，并记录容器实际宽度。如果两个页面的容器宽度不同，那么间距差异可能来自容器；如果容器宽度相同而间距仍不同，才需要检查组件样式是否被页面级规则覆盖。
这个例子的数字只用于说明比较方法，不代表任何真实项目结论。关键动作是测量并记录，而不是凭截图印象判断。测量结果会影响下一步：若确认是页面级样式覆盖，修复范围应限定在该页面，而不是改动组件默认样式。
验收样例要能暴露反例
好的验收样例不仅覆盖正常情况，还要能暴露使结论失效的反例。至少加入一条“如果出现以下现象，则当前结论不成立”的记录。
- 如果同一组件在相同数据、相同容器宽度下，仅因浏览器不同而表现不同，则不能只按页面条件验收，需要补充浏览器兼容项。
- 如果差异只在首次加载出现，刷新后消失，则要记录加载顺序和缓存状态，不能直接判定为布局问题。
- 如果差异只在登录后出现，则要检查权限或个性化数据是否改变了传入组件的字段。
这些反例的作用是防止团队把“某一次看起来正常”当成“所有条件都正常”。它们不是额外免责声明，而是验收样例的一部分。
下一步动作：先做最小复现页，再回填样例
如果差异原因仍不明确，下一步不是继续增加截图，而是做一个最小复现页：只保留该组件、一组固定数据和可控的容器宽度。把最小复现页交给开发和设计分别核对，确认差异是否仍存在。
若最小复现页中差异消失，说明原页面的其他元素或脚本参与了影响，应回到原页面逐项排除；若差异仍在，则可以把最小复现页作为验收样例的基准，再把真实页面的数据条件补充进去。这样得到的样例既能被不同角色核对，也能在后续修改后快速判断是否引入了新的表现差异。
