📍 WDQWDWQD987AAAAA:216.73.216.145
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f63216f972e2.html
📄

CMS系统选择：同一组件在不同页面表现不同时怎样构造验收样例，先确认矛盾现象是否真实可复现

先给结论：不要继续在同一页面上反复刷新，而要把“同一组件”拆成内容、模板位置、数据来源三个变量，分别构造最小验收样例。只有当某个变量单独变化就能稳定复现差异时，才算找到可交付给开发或供应商的问题描述。下面用一个假设例子说明怎么构造，以及构造结果如何决定下一步。

先确认矛盾现象是否真实可复现

假设某篇文章详情页的推荐位组件正常显示，而分类列表页同一组件只显示标题不显示摘要。常规做法通常是检查组件配置，但如果配置项完全相同，问题就不在配置本身。此时需要先固定一个前提：两个页面使用同一套组件代码，只是被放在不同模板位置、读取不同数据源。若这个前提不成立，所谓“同一组件”其实是两份实现，验收样例要按两份组件分别写。

可复现的判断标准很具体：同一浏览器、同一登录状态、同一缓存状态下，连续三次访问两个页面，差异是否每次都出现。如果只出现一次，更可能是缓存或数据更新延迟，而不是组件逻辑问题。这一步的动作是记录复现次数，结果决定后面是继续构造样例，还是先排查缓存与数据同步。

两个解释：模板上下文差异，还是数据供给差异

当差异稳定出现时，通常剩两个解释。

• 解释一：模板上下文差异。组件在详情页能拿到文章对象里的摘要字段，在列表页拿到的是列表项对象，字段名或层级不同，组件取不到值就退回默认显示。
• 解释二：数据供给差异。两个页面调用同一字段，但列表页的数据源没有返回该字段，或返回为空，组件本身逻辑正常。

这两个解释对应完全不同的修复方向：前者要改组件取值逻辑或模板传参，后者要改数据查询或接口输出。如果只凭页面表现猜测，很容易让开发改错地方。

用能区分解释的证据构造验收样例

区分方法不是看页面，而是看组件实际收到的数据。可以构造三个最小样例，每个只改一个变量：

1. 样例A：同一数据源，换模板位置。把详情页的数据对象直接传给列表页的组件位置，观察摘要是否出现。若出现，说明组件逻辑没问题，差异来自模板上下文。
2. 样例B：同一模板位置，换数据源。在列表页位置传入详情页那类完整对象，观察摘要是否出现。若出现，说明差异来自数据供给。
3. 样例C：字段补空测试。在列表页数据中手动补上摘要字段，值用一段占位文本，观察组件是否渲染。若渲染，说明组件本身能处理该字段，只是之前没拿到值。

这三个样例的假设前提是：你能在测试环境替换数据或模板，而不是直接改线上。若没有测试环境，至少要在本地或预发布环境复现，不能把线上当试验场。

把验收样例写成可交接的条目

样例要能交接，必须包含四要素：页面路径、组件位置、输入数据、预期表现。例如：

页面：分类列表页；组件位置：列表项下方推荐位；输入数据：列表项对象含 summary 字段；预期：显示摘要前 40 字。

这样写的好处是，开发或供应商不需要猜“表现不同”指什么，可以直接对照输入与预期判断是取值问题还是数据问题。若样例C通过而样例A、B不通过，下一步就不是改组件，而是检查模板传参链路；若样例C也不通过，才需要回到组件渲染逻辑。

什么情况下不必继续构造样例

如果差异只在特定登录角色、特定设备或特定缓存状态下出现，先不要构造组件级样例，而要先固定这些条件。因为这类差异可能来自权限过滤、响应式样式或缓存版本，而不是组件本身。只有当条件固定后差异仍然稳定，构造样例才有意义。否则你会在错误层面反复验证，得到一堆无法解释的结果。

最后提醒一点：验收样例的目标不是证明谁对谁错，而是让“表现不同”变成可重复、可交接、可验证的输入输出关系。做到这一点，后续无论是改模板、改数据还是改组件，都有明确依据。