蚌埠网站制作：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2b19134fea38.html
📄
蚌埠网站制作：同一组件在不同页面表现不同时怎样构造验收样例
先给结论：不要为这个组件写一份“通用验收单”，而要按它出现的页面角色分别构造样例。判断依据是组件是否依赖所在页面的数据上下文、容器宽度或权限状态。若依赖，就为每种上下文各留一条最小样例；若不依赖，一条基准样例加一条反向样例即可。下面把这两种情况拆开说，并给出可以直接照着做的动作。
先判断：组件表现不同，是上下文差异还是真实缺陷
同一个组件在列表页正常、在详情页错位，常见原因有三类：一是它读取了页面级数据，比如详情页传入的字段比列表页多一个空值；二是容器宽度不同，列表页是固定栅格，详情页是流式布局；三是权限或登录态不同，同一组件在未登录时渲染的是另一套分支。这三类都属于上下文差异，不是组件本身坏了。
与之相对，如果两个页面的容器宽度、传入数据和登录态完全一致，组件仍然表现不同，那就要按缺陷处理，而不是继续加验收样例。判断方法是：先固定其中一个变量，只改另一个，看差异是否复现。复现了，说明该变量是原因；不复现，说明还有未识别的变量，先别急着写样例。
情况一：组件依赖页面上下文时，按“上下文矩阵”构造样例
当组件确实依赖传入数据或容器，验收样例就不能只写“组件显示正常”，而要写清楚在哪种上下文下显示成什么样。建议按下面的动作做：
- 列出该组件出现过的所有页面角色，例如列表项、详情主体、侧栏推荐、弹窗内嵌。
- 为每个角色记录两个关键变量：传入数据的完整度（字段齐全还是可能缺省）、容器宽度区间（固定还是流式）。
- 每个角色至少写一条样例，样例里包含“给定什么输入、期望看到什么、不期望看到什么”。
- 把两条角色样例放在同一张验收表里，标注它们共享组件但上下文不同。
这样做的结果是：验收时不会再出现“列表页过了、详情页没过”却说不清谁对谁错的情况。下一步就可以把差异归到具体角色上，而不是反复重测整个组件。
一个注明假设的短例子
假设某蚌埠网站制作项目里，一个“文章卡片”组件同时出现在首页推荐位和搜索结果页。首页传入的封面图字段必定有值，搜索结果页可能为空。若只按首页写样例，搜索页出现占位空白时就会被当成缺陷；若按上下文矩阵写两条样例，就能明确：搜索页无封面时应显示文字占位，而不是报错。这只是说明比较方法的假设例子，不代表任何实际项目结果。
情况二：组件不依赖上下文时，用“基准加反向”两条样例就够
如果组件只接收固定属性、容器宽度也由外部统一约束，那么为每个页面各写一条样例就是重复劳动。此时更合适的做法是：
- 一条基准样例：给定标准输入，期望标准输出。
- 一条反向样例：给定边界输入，例如空数组、超长文本、缺失可选字段，期望降级而不是崩溃。
选择这种做法的条件是：组件内部没有读取页面级全局状态，也没有依赖父容器的动态宽度。代价是，一旦后续有人给组件加了页面相关逻辑，这两条样例就不再够用，需要补回上下文矩阵。因此建议在验收表里留一句备注：若组件新增页面依赖，样例数量随之增加。
实施动作：把差异写成可检查的验收项
无论走哪条路径，最终都要落到可检查的验收项上。一个可用的写法是：在什么页面角色下，给定什么输入，组件应呈现什么，不应呈现什么。 例如：
详情页 / 传入字段完整 / 卡片显示封面、标题、摘要 / 不显示占位符
搜索页 / 传入封面为空 / 卡片显示文字占位 / 不出现破图或空白块
写完之后做一次交叉检查：把每条样例交给另一个人，看他是否能不看代码就判断通过与否。如果判断不了，说明样例还缺少可观察的判定点，需要继续细化。这个动作的结果直接影响下一步——判定点清晰，回归测试才能稳定复现；判定点模糊，后续每次改版都会重新争论同一件事。
例外：什么时候不该继续加样例
有两种情况要停下来。第一，差异来自第三方组件自身在不同浏览器下的渲染差异，且无法通过传入参数控制，这时加再多页面样例也解决不了，应改为记录已知差异并评估是否替换。第二，差异只在某个已废弃页面出现，而该页面即将下线，此时为它补样例的代价高于收益，更合理的动作是确认下线计划，而不是扩充验收表。
把这两条例外写进验收说明，可以避免团队把时间花在无法通过验收样例解决的问题上，也能让后续判断有据可依。
