1、用例覆盖程度

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

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

在满足用例覆盖程度最大化的前提下，应该尽量减小执行用例所需要的工作量。

这些方面的方法有不少，如条件覆盖，分支覆盖，正交覆盖等方法。

面对不同的测试对象，也有不同的方法来保证：对于网页背后的php逻辑，可以通过在网页上测试后，用一些工具比如xdebug来统计代码覆盖率；对于向外提供接口的server

，采用的方式就是分析在外面暴露的接口设计用例，大致的通过接口参数来估计一下分支判断的情况。

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

用例的分类，在这里是指相同类型的用例是否放在一起了。

例如：接口类的用例，参数的取值范围是1-3，但是现在却传入4；数据类用例，状态机现在位于状态2，却要求状态跳转到无法到达的4；逻辑类用例，正常功能的产出等。

将相同类型的用例放在一起，有助于理清思路，清楚了解用例设计是否完备。

用例的描述，是指描述的清晰程度是否能够形成文档。

例如上面参数取值范围的例子，用例这样写：“传入错误的值”或者“传入非1-3的值”，明显没有写成“传入值4”有效。

这与写程序一样，总是写闭区间的范围而不是开区间。

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

写明用例的测试目的，对文档的易于理解性和工作交接的好处不言而喻，现代软件工程不可能只有一个人在做事情，项目于人员的变动也是难免的。

在过程中留下足够的信息，可以在后续工作提高很多效率。

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

如果被测对象有所升级，测试用例的说明或者脚本是不是容易维护呢？例如在有状态机的情况下，测试用例之间是相互依赖的（即需要一定的执行顺序），这样被依赖的用例修改后，后端不需要同步根据修改。

而如果用例之间没有相互依赖关系（如用例是自己造的数据，不是依赖于前端的产出），可能一旦有变化，就需要修改这两个。

当然，这两种情况不能绝对的说哪种好，是需要看实际使用时候的情况进行取舍的。