小王的故事
周围慢慢静了下来，起初还能听到有讨论问题的声音，但是随着时间的流失，这些声音都慢慢消失了，整个楼层都变得非常安静。但是对于小王而言，他却丝毫没有意识到这一点。
他还在紧张的测试着一个非常紧急的项目，连续几天的通宵加班，已经让他看起来有些疲惫了，疲惫到已经忘记了现在已是深夜。
“oh, yeah. 搞定”，他自言自语道。接下来就是非常清脆的敲击键盘的声音。他用力的敲下了Enter键，也意味着这个项目测试完毕了，明天就可以上线了。
然而，几个星期之后，这个项目出现了非常严重的问题……
在我的工作中，我经常会见到类似的例子，测试工程师无论怎样努力，最终还会有很多的问题遗留到了线上。我经常听到的原因有：
- 不知道这个模块还调用了其他模块，所以没考虑到影响
- 我对这块功能也不是很了解，所以没想到这里可能会异常
- RD说这里没有改动，所以就没有关注
- ……
此时，为了避免这些问题，普遍的做法是：
- 全员学习相关模块的业务逻辑
- 补充相关的test case，完善测试校验点
- ……
然而，这些方法短期看会有一定的收益，但是随着时间的积累，这些方法的弊端也会慢慢凸显：
- 不断膨胀的校验点，以及对这些校验点的维护成本不断增加，每个测试工程师不得不在每次项目中面对一份长长的校验清单。
总之，每次当有一种新的类型的未知的问题存在时，这个问题有遗留到了线上……
那么，问题的本质究竟是什么呢？如何解决类似的问题呢？
最终，我发现，问题的本质在于：预见风险——发现未知的风险。