07 缺口分析：地图上空白的地方最危险

第三章最后一件事是区分两种空白：是"知道但没测"和"连该测什么都不清楚"，两件事不一样。

你手里有一张空白格子的 ACC 地图——\ 空白格子分两种，它们的危险程度完全不同。

开篇除恐

"缺口"听起来像审计报告，像会计在说"这笔账对不上"。测试里的缺口就是这么一回事，但你需要搞清楚的是这份地图诚不诚实。

你在空白格子面前有两种反应：\ 1. 这没什么——反正目前没人提问题；\ 2. 这里是盲区，下一步该填。

第二种反应才是 ACC 想给你的。

白话化

缺口

缺口的字面意思：格子里应该有东西，但没有。

缺口的实质：你不知道该测什么，而这个位置恰好是用户会碰到的地方。

"未知"和"还没测"的区别

"还没测"=我清楚这里是什么风险，只是人手不足，暂时排后面。\ "未知"=我根本不确定这里该关注什么，可能连风险是什么都不知道。

后者是一种认知结构的盲区，不是资源问题。认知盲区用"等资源够了再测"解决不了——需要先理解问题。

怎么找到最大的那个未知

看你的矩阵，挑出所有"未知"标签，然后问：

1. 这个格子的用户在什么场景下会碰到它？
2. 如果它坏了，最坏的结果是什么？
3. 我现在有没有办法描述"它坏了"是什么样子的？

如果三条一条都答不上，"未知"就是你需要优先处理的——先理解、再定义、最后才是测试。

直觉先行

想象你住在一栋老楼的五层。每层楼有四个房间。\ 你住了三年，但你从来没去过三层东边的储物间。\ 最近，储物间的锁坏了，你推开门——

里面已经堆了好几年没有处理的东西，你根本叫不上它们的名字。\ 一个瓶子上的标签纸上写着"2018"，你起开闻——不能闻。\ 另一箱上只写了一个"？"。你再也不知道这是谁放进去的。

这就是"未知"。\ 你知道它在那里，但你不知道它是什么。

现在，如果储物间的地基在震动——你不跑，你得先弄清楚里面有没有易燃物。

ACC 矩阵里的"未知"格子就是这样。

从互联网产品看：登录功能的缺口

（经典，来自业界公开讨论）

以登录功能为例，市面上如此常见，开发者常觉得"登录？就那回事。输入手机号+验证码，完了。"

但如果你画 ACC 矩阵——从 C₁ 组件角度拆解：

• 验证码输入框
• 验证码生成后端
• 网络请求
• 错误回显 UX
• 密码找回链路
• 第三方登录对接
• Token 有效期管理
• 多端登录状态同步
• 验证码过期 UX
• 验证码重发节流

每个组件对应的能力填进去，你会发现： - 验证码重发节流：极少产品有明确的"60 秒内不能重发"的测试覆盖 - 多端登录状态同步：手机端退了，平板端退不退？这个窗口期里出现的 bug 不在 Matrix 里 - 错误回显 UX：后端返回 500，界面上显示什么？能不能把内部错误号透给用户？

这三个格子的典型共同点——开发者知道这些逻辑存在，但朴素地认为"不会有 bug"——\ 于是它们成了空白，而且多半是"未知"而不是"还没测"。

例子贴身

☼☼☼ 硬骨头：RedPen 的高风险缺口（自编）

我们抽五个"未知"格子的样，用之前的 RedPen 矩阵。

1. PDF 导出 × 轻量（行×列空白两侧，风险空气）

• 问题：大 PDF 导出速度没有上限（在定义上根本不存在文件大小的测试上限）。
• 最坏的场景：用户导出 200MB 的 Markdown 文件，编辑器崩溃，未经保存的内容丢失。
• 先定义再测：需要先定义一个"最大支持导出"，超出这个上限的 UX 是什么——拒绝？分片导？先压缩？

2. 主编辑 × 协作友好 ×（多光标冲突处理）

• 问题：两个用户同时改同一行，怎么解决？
• 你们已经有"差异高亮"机制，但冲突规则没有定义——"谁最后改谁赢了"？还是采纳合并？
• 需要先定义合并规则，然后测试"实际发生的情况和定义是否一致"。

3. 侧边栏 × 轻量（实际是 C₂ 的时序配合问题）

• 问题：侧边栏第一次加载时做了哪些磁盘 IO？
• 最坏的场景：大项目（10k 文件的仓库），侧边栏加载时间超过可接受范围。
• 需要先定义"可接受的冷加载时间"，再配测试环境（10k 模拟文件）。

4. 命令面板 × 协作友好

• 问题：一个用户执行"全局替换"指令，另一个用户在编辑被替换的那一段。
• 两个用户的指令是不是都在互相执行？如果是，替换结果预测不到。
• 需要定义"指令作用域的即时性协议"。

5. PDF 导出 × 协作友好

• 问题：导出版本怎么体现协作的冲突？
• 最坏的场景：导出时两人在不同段落各改了一个公式，导出自动选了其中一个人的版本，没提示。

这四个缺口，共同的 pattern

这几个格子的共同点是：能力定义不明确。 不是说"这些功能做不出来"，是说"这些功能在边界下应该怎么表现，没人说过"。

ACC 缺口分析的一个重要产出是：帮你发现不是"要测的东西太多"，而是"需要定义的规范"——后者才是真正应该先完成的。

☼ 热身：给你的手机矩阵三处缺口

拿出你的 ACC 矩阵（第一章的练习），挑一个空白格子，用三步问它：\ 1. 这个格子在什么场景下会被使用？\ 2. 如果它坏了，最坏的结果是什么？\ 3. 我能用一句话描述"坏了"长什么样子吗？

如果能答上三个，它就不是高危缺口；如果答不上，把它标为⛔——这是接下来要先了解，再上升才有的智。

这一章要带走的东西

• 缺口分两种："已定缺"（知道风险，在计划的后续）和"未知"（不知道风险在哪）
• 后者的危险是十倍，因为危险不在于它坏，在于你以为它没事
• 找到缺口的办法是问三个问题：场景？最坏结果？能描述失效的样子吗？
• 太多"未知"的底层原因，往往不是"没测"，而是规范根本没有定义过

就这样。