先给结论:不要为每个页面单独写一份验收单,也不要只测一个“标准页面”。正确做法是把组件拆成“结构、数据、上下文”三层,为每层各构造一个最小样例,再按差异出现的页面类型补一个组合样例。这样验收的是组件在真实条件下的行为,而不是某一次渲染的截图。
同一组件在不同页面表现不同,常见原因只有三类。第一类是结构差异,比如列表页和详情页给组件套了不同的父容器,宽度、层叠上下文或外边距折叠规则因此不同。第二类是数据差异,比如首页传入的是摘要字段,栏目页传入的是完整字段,字段为空或超长时组件内部走的分支不同。第三类是上下文差异,比如同一组件在弹层内、在侧栏内、在无图状态下分别触发不同的样式或脚本路径。
判断方法很直接:把出问题的页面和正常页面并排,逐项替换变量。先只换数据、不改结构,如果表现恢复正常,问题在数据层;再把组件原样搬进正常页面的父容器,如果恢复正常,问题在结构层;如果两者都换过仍不同,才去查上下文和加载顺序。这个判断结果直接决定你要构造几组样例——只在一层出问题,就只补这一层的样例,不必把三层都铺开。
假设你手上有一个蚌埠网站开发项目里的“资料卡片”组件,它在栏目列表页显示正常,在搜索结果页出现文字溢出。可以按下面的顺序把它转成样例,而不是靠反复刷新页面碰运气。
做完这五步,你会得到一组数量可控、每个都有明确触发条件的样例。下一步的取舍就清楚了:如果差异只在超长数据下出现,优先修组件的截断或换行规则;如果只在窄容器下出现,优先修布局约束。两类都出现,才需要同时处理。
实际工作里通常有两种做法。做法一是“逐页验收”,把每个用到该组件的页面都打开看一遍,看到不对就记下来。做法二是“按条件验收”,只构造能区分原因的最小样例,通过后再抽查真实页面。
逐页验收成立的条件是:页面数量少、组件用法高度一致、且你已经有稳定的检查清单。它的代价是重复劳动多,而且页面一多就容易漏掉只在特定数据下才出现的分支。按条件验收成立的条件是:你能说清差异属于结构、数据还是上下文中的哪一层。它的代价是前期需要花时间拆解,如果拆错了层,样例再全也覆盖不到真正原因。
对多数中小型项目,建议以按条件验收为主、逐页抽查为辅。具体动作是:先用最小样例定位并修好问题,再回到真实页面抽查三类代表——数据最长的、容器最窄的、结构最特殊的。抽查结果如果与样例结论一致,说明样例有效,可以停止扩大范围;如果不一致,说明还有未识别的变量,需要回到第一步重新判断层级,而不是继续加样例数量。
假设某项目里“资料卡片”组件在首页、栏目页、搜索结果页三处使用,只有搜索结果页出现文字溢出。按上面的方法,先固定栏目页为基线,只把标题字段替换为搜索结果页的长标题,结果复现,说明触发条件是数据长度而非页面结构。此时只需补空值、单字符、阈值附近、明显超长四个数据样例,不必为首页和栏目页各写一份验收单。修复后回到这三个页面抽查,如果长标题在搜索结果页正常、在另外两页也正常,样例可以收敛;如果首页反而出现新问题,说明首页传入了不同的字段组合,需要把首页也纳入数据层样例,而不是判定修复失败。
需要说明的是,这套方法的适用前提是你能够修改或至少观察组件接收的数据和所处的容器。如果组件来自无法调整的第三方嵌入,你能控制的只有外层容器和传入参数,样例范围应相应缩小到这两项,并把无法覆盖的部分明确写进验收记录的遗留项,而不是用“看起来正常”代替判断。