个人网站搭建，同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3d438c5f7981.html
📄
个人网站搭建，同一组件在不同页面表现不同时怎样构造验收样例
先给结论：不要试图用一份“全站通用”的验收样例解决这个问题，而是把组件拆成“固定输入”和“页面上下文”两部分，为每个出问题的页面各写一份最小样例。做法是：先记录该组件在哪些页面正常、哪些页面异常，找出这些页面之间真正不同的那个变量，再围绕这个变量构造两组对照样例。验收时两组样例必须都能复现预期结果，只测一组没有意义。
先判断分歧属于哪一类，再决定样例数量
同一组件表现不同，通常落在两种原因上，验收样例的构造方式完全不同。
- 上下文差异：组件本身没变，是所在页面的容器宽度、父级样式、数据来源或加载顺序不同。这类问题的证据是“把组件搬到另一个页面，表现跟着页面走”。
- 数据差异：组件代码相同，但传入的内容长度、字段是否为空、条目数量不同。这类问题的证据是“同一页面换一条数据，表现就变”。
判断方法很直接：把正常页面的组件原样复制到异常页面，观察表现是否跟着复制过去。如果表现跟着组件走，偏数据；如果表现留在原页面，偏上下文。这个动作的结果决定下一步——偏数据就构造不同数据量的样例，偏上下文就构造不同容器条件的样例，不要混在一起测。
上下文差异：用容器和相邻元素构造两组样例
假设一个卡片组件在文章列表页显示正常，在首页推荐位出现文字截断。先不要改样式，而是构造两组对照样例：
- 样例A：把该卡片放进与文章列表页相同的容器宽度和相邻元素结构中，预期表现与列表页一致。
- 样例B：把该卡片放进与首页推荐位相同的容器宽度和相邻元素结构中，预期复现截断。
如果样例B没有复现问题，说明你找的变量不对，需要继续缩小范围，比如检查父级是否有overflow、flex或grid相关设置。如果样例B复现了，就可以在这个样例上做单变量修改，每次只改一个属性，确认哪个条件触发了差异。验收样例到这里才算构造完成：它必须能稳定复现问题，也能在修正后稳定通过。
数据差异：用边界值而不是典型值构造样例
如果判断偏数据，典型值往往测不出问题。更有效的做法是围绕边界构造样例，例如：
- 最短输入：字段为空、条目数为零。
- 最长输入：接近该字段允许的最大长度，或条目数达到页面设计上限。
- 混合输入：部分字段有值、部分为空，模拟真实录入不完整的情况。
每组样例都要写明预期结果，而不是只写“显示正常”。比如“标题超过两行时截断并保留完整提示”，这样验收时才有可核对的依据。如果某组样例的预期结果无法确定，说明需求本身还没对齐，应先回到需求确认，而不是继续写样例。
把分歧转成可核对项目的三个动作
多个角色对同一事实理解不同时，验收样例的作用是把争论变成可复现的对照。
- 记录现象而非结论：写“首页推荐位卡片标题第三行被裁掉”，不写“样式有bug”。现象可以复现，结论容易各说各话。
- 标注观察条件：写明浏览器窗口宽度、数据条目数、是否登录等前提。缺少前提的样例无法被他人复现。
- 约定通过标准：明确“两组样例都符合预期才算通过”，避免只测正常页面就宣布完成。
执行顺序上，先构造能复现问题的最小样例，再在修正后重跑同一组样例。重跑结果决定下一步：如果异常样例通过、正常样例仍通过，可以进入下一项验收；如果正常样例反而被改坏，说明修正引入了回归，需要回到样例重新定位。
例外与适用条件
这套方法并不适合所有情况。如果组件表现差异只在极少数用户环境下出现，且无法稳定复现，强行构造样例可能成本过高，此时更实际的做法是先记录环境信息，等待更多复现线索。另外，如果差异来自第三方组件自身行为，且你无法修改其内部逻辑，验收样例的重点应放在“该组件在当前条件下是否满足你的使用要求”，而不是追究其内部原因。样例数量也不必追求覆盖所有页面，优先覆盖已出现分歧的页面和最容易出问题的边界条件即可。
简单说，验收样例的价值不在于数量，而在于它能否把“我觉得不对”变成“按这个条件操作，结果是这样”。只要样例能稳定复现、条件写清、通过标准明确，同一组件在不同页面的差异就不再是争论，而是一个可以逐项核对的项目。
