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