在日常测试时，我们在执行用例的过程中经常会遇见这样的问题：当一条用例执行后，我们会发现后续的一些用例是冗余的，并不需要执行。例如对于“用户只准中奖一次”的规则，我们设计用例“今天中奖后当日再次抽奖不中奖”以及“今天抽奖后明天允许抽奖但不中奖”，很明显，我们的校验点很简单，就是验证“用户只准中奖一次”这个功能点。但是为什么我们在后期用例执行的过程中才会发现我们设计的用例存在冗余呢？

　　我想，造成这样的原因之一是因为对于功能点的理解过于表面。也许遇到这个校验点时，从用例完善的角度出发，我们很容易想到上述两条用例，但是到测试阶段的后期，我们会发现就开发的实现方式而言，后述的用例成为了冗余，因为开发根本就没有关注过时间这样的字段，程序的实现过程关心的只是是否有插入过一条中奖数据而已。

　　在日常过程中我们应该多关心功能点的背后的真谛，而不是盲目的根据需求文档和UC去编写功能测试用例，这一点就我自身的感受而言觉得相当重要。

　　其次，我认为思维定势也会对我们的用例编写产生一定的影响。从自身所在的会员产品线出发，目前会员的等级分为普通会员、荣誉会员、VIP1、VIP2、VIP3五个等级，在会员信息表中存在一个标志位通过依次连续的数值来分别予以标记。我们的惯性思维是当涉及到等级的相关业务时，我们会验证每一个等级的情况，例如某项功能暂时开放给VIP3用户使用，由于情况本身是可以列举的，这种功能性测试我们可能习惯性的去验证对于每一类型的会员否会打开这个功能的入口。而事实上根据边界值分析法，在这个功能点上我们只需要执行两条用例即可。

　　当然这里只是给大家一种用例编写的思路，而不是说一定要大家不把用例写得冗余，冗余的用例也是测试人员的一颗定心丸。在我们不了解程序内部实现的情况下，把用例设计的越发完备也是有必要的。毕竟，发现测试用例冗余的过程往往伴随在我们执行测试的过程中，基于测试过程对应用更加了解的情形下才会意识到的。能够把用例设计的恰如其分也需要一定经验的积累。

　　还记得在一开始写测试用例的时候，自己设想测试的粒度要越细越好，而时间久了就很容易导致一个极端—用例的过度设计，这也是自己为什么会写这篇文章的原因，主要是启发自己在以后测试用例的设计中多一些思考。当我们更深入的探究这个话题的时候，这就成了一个测试策略的问题，而这又会引发更多的思考，诸如用例是否容易转换为自动化脚本等。

　　总而言之，一个优秀的测试策略需要我们在平时的工作中多一些积极的思考，如何做好取舍，如何量体裁衣，如何发挥测试工程师的最大价值，都要求我们从经验中去潜心汲取、慢慢累积。