先固定组件本身的输入条件,再对比它所在页面的上下文,用成对样例把“组件问题”和“页面问题”分开。具体做法是:为同一组件准备两组页面,一组只改变页面级因素,另一组只改变组件输入,然后逐项记录渲染结果、交互结果和可访问性结果。只有两组样例都稳定复现同一差异,才值得把它当成组件缺陷处理;如果差异只在某一类页面出现,更可能是页面级样式、脚本加载顺序或数据来源造成的。
同一组件在不同页面表现不同,常见原因可以分成两类。第一类是组件自身状态受输入数据影响,例如列表组件在空数据、单条数据、超长文本下的高度和换行不同。第二类是页面上下文影响组件,例如父容器宽度、页面级CSS重置、同页加载的其他脚本、字体加载时机。两类原因的验收样例构造方式不同:前者要固定页面,只变输入;后者要固定输入,只变页面。
判断依据可以看差异是否随页面路径变化。如果同一输入在A页面正常、在B页面异常,而A和B用的是同一份组件代码,那么优先怀疑页面上下文。实际操作是:把A页面的组件区域连同父容器一起复制到B页面做临时对照,如果异常消失,说明问题在B页面的外层结构或全局样式;如果异常仍在,再回到组件输入层面排查。
当两个页面的模板结构、父容器宽度、全局样式和脚本加载顺序基本一致时,差异更可能来自组件接收的数据。此时验收样例应围绕输入边界展开,而不是反复截图页面。
执行时,把每个样例的预期结果写成可核对项,例如“超长文本应换行且不撑破父容器”“空数据应显示占位而不是塌陷为零高度”。如果某项不通过,先确认该输入是否在组件设计范围内;超出设计范围的输入不应直接判定为缺陷,而应记录为待确认的边界条件。
当输入数据完全相同、组件代码也相同,但表现不同,验收样例的重点应放在页面上下文。此时需要构造一组对照页面,而不是继续增加数据样例。
这里的关键动作是“逐项替换”而不是“一次性还原整个页面”。假设一个列表组件在列表页正常、在详情页错位,可以先在详情页临时移除侧边栏脚本,如果错位消失,说明同页脚本之间存在影响;如果错位仍在,再检查详情页父容器的宽度和溢出设置。每一步的结果决定下一步查什么,而不是同时修改多个因素。
构造验收样例时,证据要能区分至少两种合理解释。例如组件高度异常,可能是内容撑开,也可能是父容器设置了固定高度并裁切。区分方法是:在样例中同时记录组件自身高度和父容器高度,如果组件高度正常而父容器高度被限制,问题就不在组件。再例如交互无响应,可能是脚本未加载,也可能是事件被上层元素拦截;可以在样例中临时移除上层覆盖元素,如果交互恢复,说明是层级或事件问题。
需要说明的是,某次样例中组件表现正常,不能单独证明该因素就是原因。缓存、字体异步加载、脚本执行时机都可能让同一样例出现不同结果。因此每个结论至少要有两次独立复现,且两次之间只保留被验证的那一个变量。
这套方法适用于组件代码可控、页面结构可临时调整的情况。如果组件来自第三方且无法修改,验收样例应改为记录“在哪些页面条件下可复现”,并把页面条件作为交付说明的一部分,而不是试图在组件内部找原因。如果差异只在特定浏览器或特定网络条件下出现,还需要把浏览器版本和资源加载状态作为样例变量单独记录。
最后,验收样例的结论应落到一个明确动作上:要么修改组件输入处理,要么调整页面上下文,要么把该差异记录为已知限制并说明触发条件。只有结论能对应到下一步动作,样例才算完成。