工作方式
成员列表在名字较短时可能显示正常，但邮箱地址一长，操作菜单就被挤出屏幕。Break UI 会把每个显示的值追溯到 props、测试数据或 API 数据，检查其限制，并从相同的数据入口替换测试数据。它不会为了制造故障而改动布局。
测试结果应便于直接对比：在演示数据与最坏情况数据之间切换，并按需分别提供空列表、单项列表和大量条目状态。报告会区分内容不可读或操作不可达、视觉异常，以及容易出问题的设计假设，也会记录哪些情况已经能正常处理。
预期交付物
- 包含来源、限制和可选值的字段清单
- 最坏情况测试数据和仅限开发环境的数据集切换器
- 按优先级排序的故障、建议的修复方案以及需要负责人决定的事项
从输入到发现
- 01映射每个显示的值
阅读组件、验证规则和 API 结构。记录限制和字段缺失时的行为,包括数量、徽章、图片和列表长度,而不仅是文本输入。
- 02构造可信的边界情况
在与现有数据结构相同的测试数据中，组合长名称、短名称、缺失字段和本地化标签。已知限制时遵循数据结构约束（schema）；未找到上限的字段应如实记录，而不是自行编造限制。
- 03在真实尺寸下对比
将切换器保留在开发环境或原型路由中。检查组件的实际容器、320px 宽度及其最宽布局,以及放大后的文字;如果产品支持深色模式和 RTL,也要包含。
- 04先报告,再修复
为每个故障给出严重程度、触发值、建议的修复方案和文件位置。遇到换行还是截断这类决定时请暂停;仅在被要求时才应用修复,然后重新测试演示状态和极端状态。