先给结论:不要为每个页面单独写一份验收样例,也不要只拿表现正常的页面当基准。正确做法是把组件拆成“组件自身状态”和“页面环境”两组变量,构造一组最小对照样例,让每个样例只改变一个变量。如果改变页面环境后组件行为跟着变,问题在环境;如果环境相同、组件自身状态不同才出问题,问题在组件实现或数据契约。这样构造出的验收样例,既能覆盖当前已知的正常页面,也能在规模化后定位例外来自哪里。
常见情形是:组件在商品详情页显示正常,在活动落地页出现错位或样式丢失;或者在列表页点击有效,在搜索结果页点击无响应。此时最容易做的动作是“把出问题的页面单独修一遍”,但这类修法在页面数量增长后会反复失效,因为修的是页面,不是组件与环境的边界。
验收样例要解决的正是这个边界:它要能回答“到底是组件本身在特定输入下坏了,还是宿主页面给了它不同的容器、样式作用域或数据”。如果样例只覆盖正常页面,验收结论就只是“这一个页面当时没问题”,不能支撑规模化交付。
同一组件表现不同,通常落在两类解释里:
这两类解释对应的修复责任不同:前者要改组件或补契约,后者要约束页面接入方式或补适配层。验收样例必须先能区分它们,否则修完一个页面,下一个页面还会复现。
关键证据是“控制变量后的对照结果”。可以按下面的顺序构造:
这里有一个可操作的判断动作:在最小宿主页里把容器宽度从正常值逐步调到异常页面的值,记录第一次出现异常的临界点。这个临界点就是后续验收样例里必须覆盖的边界值之一。它直接影响下一步——如果临界点来自容器,验收样例应把它写成环境约束;如果临界点来自组件内部计算,验收样例应把它写成组件输入约束。
假设一个卡片组件在文章列表页正常,在侧边栏推荐位出现文字截断。先不要直接改侧边栏样式。构造两个最小宿主页:A 页给卡片容器 640px,B 页给 280px,其他条件相同。结果只有 B 页截断,那么可以初步判断是容器宽度触发的布局问题。再把 B 页容器宽度从 280px 调到 300px,如果截断消失,说明临界点在两者之间。
接下来固定 280px 容器,只改变卡片标题长度。如果短标题正常、长标题截断,说明组件对标题长度没有兜底策略。此时验收样例应包含“280px 容器 + 长标题”这一组,而不是只写“侧边栏页面正常”。这个例子的数字只为说明对照方法,不代表任何真实项目的阈值。
把样例写成“环境 + 输入 + 预期可观察结果”三列结构(这里用文字描述,不要求表格):
当出现新的例外页面时,先判断它属于哪一类变量,再决定是补一条验收样例,还是把它归入已有样例的边界内。这个动作的结果会直接决定下一轮是改组件、改接入约束,还是只记录为已知限制。
这套方法成立的前提是:你能拿到或复刻出异常页面的关键环境变量,并且组件可以被单独挂载。如果异常只出现在完整业务流程中、依赖登录态或第三方脚本时序,最小宿主页可能无法复刻,此时应退回到“记录真实页面路径和操作序列”的样例,而不是强行拆组件。另外,如果组件本身由外部服务动态下发,环境和输入都可能随时变化,验收样例只能覆盖你观察到的条件,不能宣称覆盖全部情况。规模化的例外往往来自这些边界,而不是来自样例数量不够。