建站流程指南：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3ed8153f63ff.html
📄
建站流程指南：同一组件在不同页面表现不同时怎样构造验收样例
先给结论：不要为“组件本身”写一份通用验收样例，而要按它出现的页面类型分别写。同一组件在列表页、详情页、表单页里，输入数据、容器宽度、相邻元素和交互时序都不同，只有把“页面条件”写进样例，验收才能复现。做法是：先选一个最稳定的页面作为基准样例，再为每个差异页面补一条边界样例，最后用同一条判定标准比对结果。
先判断差异来自组件还是来自页面条件
构造样例前，先分清两种原因，否则会把页面问题误记成组件缺陷。
- 组件自身原因：同一份输入数据、同一容器宽度下，组件在多个页面都出错，且出错位置一致。此时样例只需锁定输入和版本。
- 页面条件原因：同一份输入数据下，只在某个页面出错，而该页面的容器宽度、父级样式、相邻元素或加载顺序与基准页不同。此时样例必须记录页面条件。
可操作的区分动作：把基准页的组件容器宽度、父级类名、相邻元素类型抄下来，逐项在异常页对齐。如果对齐某一项后差异消失，这一项就是样例必须固定的条件；如果全部对齐后仍存在差异，才把问题归到组件本身，并进入下一轮隔离。
两种条件下，样例的写法不同
条件一：页面条件可控，比如容器宽度、栅格列数、父级内边距都由团队自己决定。这时样例写成“输入数据 + 容器条件 + 期望结果”三行即可，重点是容器条件必须写成具体数值或具体类名，而不是“正常宽度”。
条件二：页面条件不可控，比如组件被嵌进第三方内容区、用户可编辑区域或动态插入的模块。这时样例不能只写期望结果，还要写“允许的偏差范围”和“判定失败的下限”。例如文字换行位置可以不同，但按钮不可被裁切、不可遮挡相邻链接，这两条作为硬判定。
选择依据很简单：你能改的条件就固定它，你不能改的条件就给它划边界。把不可控条件当成可控条件来写，样例一定会在规模化后失效。
一条可复用的样例结构
假设有一个卡片组件，在列表页显示正常，在详情页侧栏里文字溢出。下面是一个假设例子，数字仅用于说明比较方法，不代表任何真实项目结果。
- 基准样例：容器宽度 320px，输入标题 18 个汉字，期望标题最多两行、按钮完整可见。
- 差异样例：容器宽度 240px，同一份输入，期望标题截断且出现可展开入口，按钮仍完整可见。
- 判定动作：先在基准宽度跑一遍，记录标题行数与按钮位置；再切到 240px 跑同一份输入，只比较这两项是否满足各自期望。
- 结果如何影响下一步：如果基准通过、差异失败，说明验收样例缺了宽度条件，需要把宽度写进样例而不是改组件；如果两者都失败，才回到组件内部排查。
关键点是：每个样例只改变一个页面条件。一次改宽度又改输入数据，失败后无法判断是哪一项造成的。规模化验收时，样例数量会增加，但每条样例的变量必须保持单一。
哪些情况不能直接照搬基准样例
以下边界要在写样例时就标出来，否则个别样本成立、批量执行时必然出现例外：
- 容器由外部决定：组件被放进用户可编辑区域或第三方模块时，宽度和高度不受控，基准样例的固定数值不适用，应改为范围判定。
- 相邻元素会变：同一组件旁边可能是图片、长文本或另一个组件，间距和换行会受影响，样例需注明相邻元素类型。
- 加载顺序不同：组件依赖的数据晚于页面其他部分到达时，首次渲染结果可能不同，样例要区分“数据到达前”和“数据到达后”两种状态。
- 内容语言或长度差异：同一组件承载不同长度文本时表现不同，样例输入应覆盖最短和最长两类，而不是只用一个中间值。
遇到这些边界，正确动作不是删掉样例，而是把它降级为“参考样例”，并另写一条带范围判定的边界样例。这样既保留可比对的基准，又不会把不可控条件伪装成可控条件。
把样例写进验收清单时的检查顺序
建议按这个顺序执行：先跑基准样例确认组件在当前版本可用；再逐条跑差异样例，每条只改一个页面条件；最后跑边界样例，检查硬判定是否被突破。任何一条差异样例失败时，先回看该样例是否只改了一个条件，再决定是修组件还是补样例。这个顺序能让“个别页面异常”变成可定位的验收项，而不是靠主观描述反复争论。
