今天写了下CRM2.0的测试用例，刚好看到了老徐的文章，里面有一句话说得很赞同：测试的价值，不是发现多少bug，而是产品上线后，有多少漏测问题。测试用例的价值就是为了减少线上环境漏测的几率，所以，覆盖系统所有状态（正常状态 异常状态）的用例很重要。
之前我也出现过线上漏测的问题，一个是某个文案出错 一个是我的用例给另一个同事测试时漏测了，场景是这样的：b系统的密码可以在a系统中进行重置，在a系统重置了密码之后，在b系统上需要用默认密码登录。当时我写用例时只写了b系统用默认密码登录，这条用例没有同步到a系统的用例上。这个错误在于没有考虑到一个系统发生变化之后，跟这个系统有关的系统产生什么变化。这样下来，每一条用例，都会发散性地与本系统或其它系统用例关联起来
自从那次漏测之后，我写用例涉及到某个状态变化（如资料修改、删除某一项、提交订单等）时，总会停下来想想：这个状态发生变化后，其他系统或页面会发生什么变化。
我认为，写测试用例的过程，相当于做一次深度阅读理解的过程。在你读完需求文档之后，除了需求文档上涉及的点之外，你有没有发散地想到与这个点相关的其他点。比如需求上说，输入正确的手机号，你有没有发散性地想到，异常的手机号会怎样（纵向关联），外国的手机号会怎样，停机的手机号会怎样，命中黑名单的手机号会怎样等等。
联想到一个知识体系的建立，不也是这么一个过程吗？每个知识点都能发散性地与其他知识点有所联系，从而形成一张密集的知识网络。所以，当我们学习一个知识点时，也应该联想到与之相似的知识点。
