网站建设需要什么人：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /16f058444c48.html
📄
网站建设需要什么人：同一组件在不同页面表现不同时怎样构造验收样例
先给结论：不要为“组件本身”写一条通用验收样例，而要为“组件在具体页面中的上下文”分别写样例。同一组件在列表页和详情页表现不同，通常不是组件坏了，而是它依赖的数据形状、容器宽度或交互前提不同。构造验收样例的第一步，是把这个前提显式写进样例里，而不是让测试者凭感觉判断。
先判断差异来自组件还是来自页面上下文
同一组件在两处表现不同，只有两种可能：组件在两种上下文下都该正常工作却失败了，或者组件本来就只适配其中一种上下文。区分它们，靠的是把“页面给组件的输入”和“组件输出的结果”分开记录。
- 如果两处传入的数据结构一致、容器约束一致，输出却不同，问题在组件实现或样式作用域。
- 如果数据结构不同（例如列表页传数组、详情页传单个对象），表现不同是预期内的，需要的是两套样例。
- 如果容器宽度、字体继承、父级定位不同，属于上下文差异，样例要固定这些变量。
这一步的实际动作是：在写样例前，先列出该组件接收的输入项和所处容器的约束项。结果会直接决定下一步——输入项相同就查组件，输入项不同就拆成两条样例。跳过这一步，样例会写成“组件显示正常”，无法定位任何问题。
两种条件下的不同选择
条件一：组件是共享实现，页面只是容器不同
这时应构造“同一输入、不同容器”的对照样例。样例里要写明容器宽度区间、父级是否设置了溢出隐藏、字体是否被页面级样式覆盖。验收时只允许容器变量变化，其余输入保持一致。如果结果仍然不同，说明组件对上下文有隐藏依赖，需要把它暴露成显式参数。
条件二：组件在两处接收的数据形状本就不同
这时不应强求一条样例覆盖两处，而应各写一条，并在样例中标注数据前提。列表页样例使用集合数据，详情页样例使用单条数据，两条样例分别声明各自的必填字段和缺省行为。强行合并成一条，只会让验收标准变得模糊，测试者无法判断失败到底该归咎于哪一侧。
取舍的代价很明确：合并样例省了文档量，但排查成本高；拆分样例增加了维护条目，但每条都能独立复现。当组件被三个以上页面复用时，拆分的收益通常超过维护成本。
验收样例里必须写清的三类信息
- 前提：页面路径类型、容器约束、传入数据的形状，以及是否依赖某个交互前置状态。
- 动作：测试者具体做什么，例如滚动到组件可见、切换到某个标签、在窄容器中观察。
- 可观察结果：不是“显示正常”，而是“在容器宽度小于某阈值时，内部文字不溢出容器边界”。
假设一个筛选组件在列表页正常、在详情页侧栏错位。若样例只写“筛选组件显示正常”，验收者无法判断侧栏算不算正常。若样例写明“在侧栏窄容器中，选项换行而非横向溢出”，失败就能被稳定复现，下一步也就能直接指向容器的宽度约束，而不是盲目改组件。
例外：什么时候不值得为差异单独建样例
如果某页面只是临时活动页，且该组件在此页面的使用方式不会复用到其他页面，为它单独建长期验收样例的维护成本可能高于收益。此时可以只记录一次性检查项，但要在文档中注明它不纳入回归范围。反过来，只要该组合预计会被再次使用，就应升级为正式样例。判断依据是复用预期，而不是当前页面数量。
把样例落到可执行的检查清单
构造完成后，每条样例应能被不同的人独立执行并得到一致结论。一个可用的检查方式是：让另一位不熟悉该组件的成员仅凭样例描述操作，若他无法判断通过与否，说明样例还缺少前提或可观察结果。这个动作的结果会反馈到样例本身——补全缺失信息后，再决定是否需要拆成两条。验收样例的质量，最终体现在它能否把“表现不同”转化为“可定位的差异”。
