测试用例怎么选：把风险变成一张矩阵

测试数量很多，并不自动意味着关键风险得到覆盖。相反，一张清楚的风险矩阵，常常能帮助挑出更少却更有解释力的用例。

本篇目标： 为一个通用编辑动作设计回归用例，先确定不变量，再选择触发条件。

先描述不能被破坏的事情

以便签编辑为例，可以先写下几条不变量：无权限的人不能修改；失败后原内容仍可读取；旧版本不能悄悄覆盖新版本；同一命令重复提交不能产生多份结果。

这些说法比“保存按钮正常”更具体，也更容易观察。测试的输入可以变化，不变量应始终成立。

一个轴放场景：正常、边界、故障、恢复。另一个轴放状态：未开始、处理中、已提交、已结束。交叉查看时，就容易想到“处理中权限变化”“提交后响应丢失”这类正常演示里看不到的路径。

不必把所有组合机械地做成测试。优先覆盖影响大、容易发生、曾经出错，或实现中存在异步间隔的地方。

前置条件：两个窗口读取同一版本
动作：第二个窗口先保存
再动作：第一个窗口提交旧版本
断言：旧提交被拒；新内容未被覆盖；旧输入仍保留

好的断言关注外部行为和业务不变量。只检查某个内部函数被调用，可能无法证明用户最终看到的结果正确。

单元测试适合明确的计算和边界规则；集成测试检查真实组件之间的协作；端到端测试检查实际用户路径。模拟器、测试替身和真实环境各有用途，记录结果时应说明自己站在哪一层。

对修复过的问题，保留能够再次触发旧错误的最小用例。让测试先展示旧实现的缺陷，再验证修复后的行为，比增加一组只会跟着当前实现一起通过的断言更有意义。