昭通网站开发：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /35d7094f5cb2.html
📄
昭通网站开发：同一组件在不同页面表现不同时怎样构造验收样例
结论是：不要为组件单独写一份验收样例，而要按“页面角色 + 数据条件 + 可见结果”三个维度各取一个代表页面，组成一组最小对照样例。只有当同一组件在相同数据条件下、相同页面角色中表现不同，才应作为缺陷处理；如果页面角色或数据条件不同，表现不同通常是预期内的，需要先修正验收口径。
先分清“组件差异”和“页面差异”
同一组件在不同页面表现不同，常见的真实原因有三类，需要先用证据区分：
- 容器差异：父级宽度、栅格列数、内边距或溢出规则不同，组件被压缩或撑开。
- 数据差异：字段缺失、文本超长、图片比例不同、列表条数为零或极多。
- 上下文差异：同一组件在详情页承担主内容，在列表页只是摘要，交互和层级要求本就不同。
能区分这三类的证据不是截图本身，而是同一份测试数据在两组容器条件下的对照截图。如果只交一张“列表页正常、详情页异常”的图，开发、设计、测试三方会各自解读，分歧无法收敛。
把分歧转成可核对的项目
可执行的做法是把每个争议点写成一条带前提的样例条目，而不是一句“这里显示不对”。一条合格的样例至少包含：页面标识、页面角色、数据前提、容器前提、预期可见结果、判定方式。其中“判定方式”要能回答是看位置、看是否截断、看是否可点击，还是看是否出现滚动条。
假设一个场景：某卡片组件在列表页显示正常，在详情页侧栏出现文字截断。此时不应直接判定组件有缺陷，而应补一条样例：在侧栏容器宽度下、标题为最长允许字符数时，标题应完整显示或按约定折行，不得出现省略号截断。这条样例一旦成立，下一步动作就明确了——要么调整侧栏宽度，要么修改组件的折行规则，而不是反复争论“到底算不算问题”。
构造最小对照样例的具体步骤
- 列出该组件实际出现的所有页面角色，通常不超过四种，取其中差异最大的两种作为对照。
- 为每种角色固定一组数据：最短、常规、最长各一条，零条和极多条各一条。
- 固定容器条件：记录父级宽度区间和栅格位置，而不是只写“桌面端”。
- 对每个组合只记录一个可判定的结果，避免一条样例里塞入多个结论。
- 把无法判定为通过或失败的条目单独列出，标记为待确认，不混入缺陷清单。
这样做的直接结果是缺陷数量可能先上升后下降：原先被笼统归为“显示异常”的条目，会被拆成若干条有前提的样例，其中一部分经核对属于预期行为，可以从缺陷清单中移除。这一步会影响下一步的排期判断，因为真正需要修改的条目变少了，但每条的责任归属更清楚。
一个会让上述结论失效的反例
如果同一组件在不同页面加载的是不同版本或不同配置，那么按页面角色构造对照样例就不再有效。例如列表页引用的是本地打包版本，详情页引用的是另一处引入的版本，两者行为差异来自版本而非页面。此时继续用容器和数据条件做对照，只会得到互相矛盾的结论。识别信号是：在相同容器、相同数据下，两个页面的组件行为仍不一致，且控制台或构建产物显示来源不同。遇到这种情况，应先统一引用来源，再回到对照样例。
下一步动作
先选一个争议最多的组件，按上述方法写出三到五条最小对照样例，交给开发和测试各核对一遍。如果双方对同一条样例的判定仍不一致，说明该条的前提描述还不够具体，需要继续拆细；如果核对后争议消失，就把这组样例固化为该组件的验收基线，后续同类页面直接复用，不再逐页重新争论。对于昭通网站开发中多角色协作的项目，这组基线比任何口头约定都更容易交接。
