验证隐喻是否成立，需要检验边界情形而不只是核心典型场景
别名: metaphor validation · edge case testing · 隐喻测试
概念解释
一个隐喻在核心典型场景下表现良好，并不能说明它整体成立——隐喻的失效点，无论是被脑补的空白属性、混用产生的规则冲突，还是被推广到的边界情形，几乎全部集中在用户很少走到、但确实会走到的那些非典型操作上。因此，判断一个隐喻是否站得住脚，测试范围必须专门覆盖边界情形，只测核心路径得到的"通过"结论，说明不了隐喻在其余地方是否也成立。
机制
标准的可用性测试天然偏向核心场景：测试任务通常按最常见的使用流程设计，招募来的用户也大多被引导去完成典型目标。这套流程能高效验证"多数人在做多数事情时体验如何"，却系统性地绕开了隐喻真正容易破裂的地方——因为边界情形本来就不在典型使用路径上，一次只测典型路径的研究，永远不会主动撞见它们。
这不是抽样运气不好，而是测试设计本身的结构性盲区：只要任务脚本是从"用户通常想做什么"反推出来的，边界情形就不会被自然纳入，除非专门为它们设计任务。而边界情形恰恰是隐喻的推论规则被自动、无意识地推广到的地方——不主动测，就等于让这部分推论完全不受检验地留到上线之后才第一次被真实用户撞见。
怎么研究
要让测试真正覆盖边界情形，任务设计不能从"用户平时会做什么"出发，而要从隐喻源域本身的属性空间出发，系统性地枚举：源域里除了核心用途之外还有哪些性质、状态、组合方式（文件夹能不能装文件夹、购物车能不能在下单后继续加东西、对话能不能被多人同时编辑），再逐一确认系统在这些点上是否有定义的行为，把每一条都变成一个具体的测试任务。
常见自变量：任务是否落在核心路径还是源域推导出的边界情形、被试对源域的熟悉程度。 常见因变量：用户对边界操作结果的预测准确率、预测与实际行为不符时的困惑程度或后续纠错行为。
方法论注意点：源域属性空间的枚举本身依赖研究者对源域的熟悉程度，容易漏掉设计者自己也没意识到的边界属性——比较可靠的补充做法是先做一轮不预设边界清单的自由探索，观察用户自发触碰到哪些非典型操作，再把这些操作补进系统枚举的任务清单，两种来源互相校验，比单靠其中一种更全面。
边界
- 边界情形的枚举不可能穷尽——源域的属性空间可以无限细分，测试资源总是有限的，这条讲的是"要专门分配测试资源覆盖边界"，不是"要覆盖所有可能的边界"。
- 只有当隐喻确实借用了一个用户有丰富直觉的源域时，这种系统性枚举才有意义；如果源域本身对用户很陌生，用户几乎不会自发产生边界推广，覆盖边界情形的收益也相应降低。
- 用核心场景测试得到的"可用性良好"结论，不能被这条结论推翻或替代——两者回答的不是同一个问题，一个测的是多数人多数时候的体验，一个测的是隐喻规则的完整性，产品上线前通常两者都需要。
怎么落地
- 在测试计划阶段就单列一份"边界情形清单"，来源包括系统枚举源域属性和前一阶段自由探索观察到的操作，与核心任务清单分开管理，避免边界任务因为看起来"不常用"而被优先级排到测试周期之外。
- 对已识别但确认不支持的边界操作，检查系统是否给出了明确反馈（禁用状态、提示文案），而不是留下未定义行为，这是把测试发现转化为具体修复动作的关键一步。
- 验证办法：测试报告中单独统计边界情形任务的通过率，与核心任务通过率并列呈现；如果边界任务通过率明显偏低但因为占比小被平均数掩盖，说明当前的测试口径正在系统性低估这个隐喻的实际风险。