先给结论:不要为“这个组件没问题”写一条笼统的通过项,而要把它拆成“组件输入条件 + 页面上下文 + 可观察输出”三列,在同一份样例里同时覆盖正常页、边界页和例外页。只要有一个页面组合无法复现预期输出,就不能把该组件判为整体通过,只能判为“在已列条件下通过”,并把未覆盖的组合写成待验证项。
假设你正在验收一个怀化网站建设项目里的“产品参数表”组件,它在产品详情页显示正常,但被放进新闻详情页的侧栏后列宽错乱。此时不要先改样式,而要先把它转成样例。做法是:打开这个组件所在的模板,记录三件事——组件接收哪些数据、它被放在什么容器里、它在页面上输出什么。以参数表为例,输入是“参数条数、每行字段数、是否含长文本”,上下文是“主内容区宽度、侧栏宽度、是否嵌套在折叠面板内”,输出是“列数、是否出现横向滚动、行高是否一致”。
把这三列写成一行样例,例如:输入=6条×4字段,上下文=侧栏320px,输出=4列不换行。这一行就是最小验收单元。它比“参数表显示正常”有用,因为任何人拿到它都能复现同一个页面状态。
同一组件在不同页面表现不同,常见原因只有两类:一类是组件自身对输入敏感,另一类是页面给它的容器不同。区分方法很简单:固定输入,只改上下文;再固定上下文,只改输入。如果只改上下文就出问题,说明组件没有适配容器,属于页面上下文问题;如果只改输入就出问题,说明组件没有处理边界数据,属于组件自身问题。
举例说明,以下为假设场景:某参数表在详情页主内容区(宽960px)显示4列,在侧栏(宽320px)显示4列并溢出。固定输入为6条×4字段,只把容器从960px改为320px,结果溢出。这组对比指向“组件未按容器宽度调整列数”,而不是数据条数的问题。下一步动作应是给组件加容器宽度判断,而不是去改数据源。
反过来,若固定侧栏320px,把输入从6条改为20条,结果出现滚动条但列数不变,这说明组件对条数有处理、对宽度没有处理。两种原因的证据不同,处理顺序也不同:先解决宽度适配,再验证条数增加是否仍可接受。
只在一个页面验证通过,不能代表组件在整站可用。验收样例至少要包含三类页面,并写清每类的适用条件:
这三类不是并列可选,而是有先后:正常页通过只说明“能用”,边界页和例外页通过才说明“可复用”。如果项目时间只允许验证一类,优先验证例外页,因为复用场景最容易出现容器冲突。
验收样例的产出不应只是“通过/不通过”,而应是一张带条件的结果表。每一行写清:样例编号、输入、上下文、预期输出、实际输出、判定。判定只有三种:通过、不通过、未覆盖。未覆盖必须写明缺哪个条件,例如“未验证折叠面板内展开后的宽度”。
当某一行判为不通过时,实际动作是回到组件代码或样式,修改后再用同一行样例复测。复测通过后,还要把它加入回归样例,防止后续改动再次破坏。这个动作的结果直接影响下一步:如果修改只让当前页面通过、其他页面仍失败,说明修的是页面而不是组件,应回退并改组件本身。
如果某一行始终无法在现有组件结构下通过,可接受的处理是限定使用范围,例如“该组件仅用于主内容区宽度不小于720px的页面”,并把这条限制写进交付说明。限定范围不是失败,而是把不能直接照搬的边界写清楚。
假设某怀化网站建设项目交付前,验收人只测了产品详情页的参数表,判定通过。上线后运营把同一组件放进活动页侧栏,出现横向溢出。按本文方法,验收人应补做:固定输入6条×4字段,分别在960px、720px、320px三种容器下截图记录输出。若960px和720px正常、320px溢出,则结论是“组件在窄容器下不适用”,处理动作是加容器查询或限定最小宽度,而不是重做整个组件。这个例子的数字仅用于说明比较方法,不代表任何真实项目结果。
验收样例的价值在于把“看起来一样”变成“条件写清楚、结果可复现”。只要样例里保留了输入、上下文和输出三列,同一组件在不同页面的差异就不再是偶发现象,而是可以被逐条判定和处理的清单。