作为测试人员，设计测试用例是干活的第二步（第一步当然是了解测试对象嘿嘿），这一步做的好与否，对后续工作起着决定作用，那么如何评价一个测试用例的好坏，或者说，设计的成功与否呢，本文大概讨论一下，抛砖引玉吧，记录在这里，看看是不是可以作为一次团队讨论的话题。

　　在此之前，我们需要明确测试工程师的工作原则：用小的成本找出多的问题。

　　1、用例覆盖程度

　　毫无疑问，这一点应该是重要的，无需多说，覆盖率大化是一套测试用例的重要评价标准，如果漏测杯具了。

　　2、用例是否已经达到工作量小化

　　在满足用例覆盖程度大化的前提下，应该尽量减小执行用例所需要的工作量。这些方面的方法有不少，如条件覆盖，分支覆盖，正交覆盖等方法。面对不同的测试对象，也有不同的方法来保证：对于网页背后的php逻辑，可以通过在网页上测试后，用一些工具比如xdebug来统计代码覆盖率；对于向外提供接口的server，采用的方式是分析在外面暴露的接口设计用例，大致的通过接口参数来估计一下分支判断的情况。

　　3、用例的分类以及描述是否足够清晰

　　用例的分类，在这里是指相同类型的用例是否放在一起了。例如：接口类的用例，参数的取值范围是1-3，但是现在却传入4；数据类用例，状态机现在位于状态2，却要求状态跳转到无法到达的4；逻辑类用例，正常功能的产出等。将相同类型的用例放在一起，有助于理清思路，清楚了解用例设计是否完备。

　　用例的描述，是指描述的清晰程度是否能够形成文档。例如上面参数取值范围的例子，用例这样写：“传入错误的值”或者“传入非1-3的值”，明显没有写成“传入值4”有效。这与写程序一样，总是写闭区间的范围而不是开区间。

　　4、用例是否表明了测试目的

　　写明用例的测试目的，对文档的易于理解性和工作交接的好处不言而喻，现代软件工程不可能只有一个人在做事情，项目于人员的变动也是难免的。在过程中留下足够的信息，可以在后续工作提高很多效率。

　　5、测试用例的易于维护性

　　如果被测对象有所升级，测试用例的说明或者脚本是不是容易维护呢？例如在有状态机的情况下，测试用例之间是相互依赖的（即需要一定的执行顺序），这样被依赖的用例修改后，后端不需要同步根据修改。而如果用例之间没有相互依赖关系（如用例是自己造的数据，不是依赖于前端的产出），可能一旦有变化，需要修改这两个。当然，这两种情况不能的说哪种好，是需要看实际使用时候的情况进行取舍的。不过，通过一些系统性的工具支持，也会出现一种做法性的好于另外一种的情况，情况很多，做法也有很多，在这里不多说了。

　　说了这么多，其实这个第二步，还是严重依赖于第一步的，如果对测试对象的需求，实现等都不了解，设计用例也无从谈起了。