商城网站开发：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /da8365fe8161.html
📄
商城网站开发：同一组件在不同页面表现不同时怎样构造验收样例
结论先说：当同一组件在列表页、详情页、购物车或结算页表现不一致时，验收样例不应按“组件名”组织，而应按“组件×页面上下文×数据状态”三要素组合来构造。只有把页面提供的容器宽度、数据密度、交互层级和状态来源写进样例，不同角色才可能对同一事实得出可核对的结论。若组件本身带有跨页面共享的全局状态，且该状态在页面切换时未被重置，那么按上述方法构造的样例仍会漏掉最关键的冲突，此时需要先冻结状态来源再补样例。
先确认分歧是不是同一事实
多个角色说“这个组件在详情页正常、在购物车页错位”，听起来是同一件事，实际常是三类不同事实被混在一起。第一类是渲染差异：同一份数据在不同页面被容器宽度或栅格列数改变。第二类是数据差异：列表页传入的是摘要字段，详情页传入的是完整字段，组件对空值或长文本的处理不同。第三类是状态差异：组件依赖的选中态、库存态或登录态来自不同页面各自的初始化逻辑。
把这三类分开，是构造验收样例的前提。做法是让每个提出分歧的人各写一句“我在哪个页面、用什么数据、看到什么”，而不是直接写“组件有问题”。如果三句话指向不同页面或不同数据，就不是同一个缺陷，验收样例要分别建。
把样例写成三要素组合
可核对的样例至少包含三项：页面上下文、输入数据、期望结果。页面上下文要写到容器和位置，例如“详情页主栏，宽度受侧栏挤压”；输入数据要写到边界，例如“商品名接近上限且含中英文混排”；期望结果要写成可观察的现象，例如“名称换行后按钮不被推出容器”。
- 列表页：卡片容器窄、数据为摘要、无库存交互。
- 详情页：主栏宽、数据完整、含规格选择。
- 购物车页：行内布局、数据为已选规格、含数量增减。
- 结算页：只读摘要、数据被压缩、含金额与优惠状态。
同一组件在这四类页面里的表现差异，多数来自容器和数据的组合，而不是组件代码本身随机变化。样例按组合写，执行人才能复现，评审人才能判断期望是否合理。
一个注明假设的短例子
假设某商城的价格组件在列表页显示“¥99 起”，在详情页显示“¥99”，在购物车页显示“¥99.00”。三方各执一词：运营认为详情页漏了“起”字，开发认为数据源不同，测试认为格式化规则不统一。按三要素拆开后，样例可以写成：列表页传入区间价、详情页传入单一定价、购物车页传入已选规格价；期望结果是“区间价必须带起字，单一定价不带，结算金额固定两位小数”。这样分歧就从“组件坏了”变成“哪类数据该走哪条格式化分支”，下一步动作是核对每个页面实际传入的价格类型，而不是直接改组件。
什么情况下这套方法会失效
反例是组件依赖跨页面共享的全局状态。比如规格选择状态存在全局存储中，从详情页进入购物车时未被重置，那么即使每个页面的容器和数据都写进了样例，组件在购物车页仍可能显示详情页的旧规格。此时按页面分别构造样例无法暴露问题，因为差异不在页面，而在状态生命周期。遇到这种情况，先冻结状态来源和重置时机，再把“从详情页带规格进入购物车”写成一条跨页面样例，而不是继续增加单页样例。
下一步动作与结果如何影响后续
下一步不是补更多样例，而是先做一次数据来源标注：让每个页面负责人标出该组件拿到的字段、字段类型和是否有默认值。标注完成后会出现两种结果。若各页面字段类型一致，差异就落在容器和样式，样例只需补页面上下文。若字段类型不一致，差异落在数据契约，样例必须先统一字段含义，否则样式怎么调都会在另一个页面复发。这个动作的结果直接决定后续是改样式、改数据映射，还是改状态重置逻辑，三者不能同时开工。
