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

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

    1.用例覆盖程度

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

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

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

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

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

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

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

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

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

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

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

建议继续学习：

1. Xvfb+YSlow+ShowSlow搭建前端性能测试框架    (阅读：54216)
2. 安全测试与渗透测试区别    (阅读：23701)
3. 使用Fiddler对手机应用进行抓包测试    (阅读：6931)
4. 服务器性能测试工具推荐    (阅读：6479)
5. 给Apache做压力测试时遇到的问题    (阅读：5922)
6. WEB性能测试工具推荐    (阅读：5652)
7. 可用性测试好助手——Morae软件的应用    (阅读：5502)
8. 12款很棒的浏览器兼容性测试工具推荐    (阅读：4865)
9. 可用性测试的权衡之道（二）    (阅读：4806)
10. 性能测试工具sysbench简介    (阅读：4757)