极端长度或异常格式的数据需要在原型阶段就纳入测试
别名: 极端长度数据 · 异常格式测试 · hostile data in prototypes
概念解释
平均长度的“正常”样本测不到截断、折行、溢出和解析失败。极端长度（超短、超长、空）和异常格式（emoji、从右到左脚本、科学计数、带空格的标识、错误编码）必须在原型阶段就作为一等测试数据，而不是留给上线后的缺陷。它们不是吹毛求疵：姓名、地址、金额、日志编号在真实系统里本来就长成这样。等工程做完再测极端，返工落在已经锁死的组件上。与占位掩盖边界不同，这里要求主动放入敌意样本，即使手头暂时没有生产库。
机制
排版与校验是对字符串的假设：有最大宽度、是某国电话、不含零宽字符。极端值专门打碎这些假设。超长标题覆盖动作、超短标题让列表失去可扫性、异常格式让搜索和复制失败。人在极端值上的策略也会变：放弃阅读、改用猜测、把失败归咎于自己。若原型从未给过这些字符串，这些策略与相应的界面补偿（展开、复制、警告）都不会被设计出来。越早上极端，补偿可以还很便宜；越晚，只能加省略号了事。
怎么研究
为每个输入和展示字段建敌意表：空、单字符、语言上限、混合脚本、注入式特殊字符、错误分隔符。任务脚本强制至少一次使用敌意记录，而不是让参与者碰巧抽到。编码溢出、截断是否可恢复、错误信息是否把责任推给用户。国际化走查和模糊测试的思路可以缩小到原型：不需要攻击系统，只需要攻击布局与校验。不要把“设计师手工排过的那一条长标题”当成已覆盖——那一条往往被偷偷改短了。
边界
无意义的随机噪声（几千个 Z）对某些字段没有生态意义，会浪费场次；敌意值应来自该字段的真实分布尾部。安全测试（注入）有单独的方法与伦理，原型阶段的异常格式是体验与校验，不是渗透。有些极端只在特定语言或设备上出现，样本要按目标市场构造。无障碍用户对截断的代价更高，敌意测试应包含读屏下的超长文本。
怎么落地
- 每个关键字段准备最短、最长、空、一种异常格式四条记录，写进测试脚本。
- 禁止为了截图好看而改短演示数据。
- 溢出必须有可验证的补偿（展开、换行、提示），不能只有设计者“应该会省略”。
- 把敌意表交给工程，作为验收而不是作为“有空再看的 polish”。