先给结论:不要为每个页面各写一份验收样例,而是把组件拆成“输入条件—渲染结果—可观察输出”三层,用一份基准样例加若干差异样例覆盖例外。当同一组件在A页正常、B页异常时,先假设差异来自页面传入的数据形状、所在容器的样式作用域、以及渲染时机三类条件,再针对这三类分别构造可复现的最小样例。下面用一个假设情境说明完整决策过程。
假设某站点用同一套建站平台搭建,文章列表页和文章详情页都调用同一个“相关推荐卡片”组件。列表页显示正常,详情页卡片宽度溢出、图片比例失真。此时如果只截详情页的图交给开发,往往得到“在我这里正常”的回复,因为缺少能区分原因的对照条件。
正确的动作是先固定变量:同一浏览器、同一视口宽度、同一登录状态,只切换页面类型。若异常只在详情页出现,说明问题不在组件本身,而在页面给组件喂的数据或包裹它的容器。这一步的结果决定后续样例是围绕数据构造,还是围绕布局容器构造。
构造样例前先定义每层“看什么”,否则样例会退化成截图比对。
三层分开后,同一组件在不同页面的差异就能被定位到具体一层,而不是笼统地说“样式不对”。
基准样例只保留组件运行所需的最小输入:一条完整数据、一个固定宽度的容器、无外部覆盖样式。它回答“组件在理想条件下是否正确”。
差异样例在基准上每次只改一个条件,形成可对照的版本:
每个样例都要写明“预期结果”和“判定依据”。例如图片缺省时预期显示占位块且容器高度不塌陷,判定依据是容器高度与有图时一致。这样样例才能被不同人重复执行,而不是依赖某个人的经验。
个别样本成立不等于可以全量复制。以下边界需要在样例说明里写清:
这些边界不是免责说明,而是决定样例能否被批量复用的前提。忽略它们,规模化后出现的例外会重新回到“无法复现”的状态。
具体动作:在测试环境建一个仅用于验收的样例页,用查询参数切换数据形态与容器宽度,例如 <div data-case="no-image" data-width="narrow">,让同一组件在同一页面上并排渲染多个差异样例。
这个动作的结果是:异常能被并排对照,定位从“详情页有问题”缩小到“缺图时容器高度未锁定”。下一步就不再是反复截图沟通,而是直接修改组件的缺省状态规则,并在同一验收页回归验证。若修改后该样例通过、其他样例不受影响,才把规则同步到全站组件库;若其他样例被带崩,说明修改引入了新的耦合,需要回到分层定义重新判断。
验收样例的价值不在于覆盖所有页面,而在于用最小对照把“哪一层出错”变成可判定的事实,让后续修改有明确的回归范围。