因项目的需要，近一直在整理测试用例。大量的测试用例和业务整理起来并不容易，虽然耗费了相当长的实践，却也因此收获一些想法，希望能对以后的工作有所帮助。

　　在整理测试用例过程中，从头到尾都在思考一个问题，为什么这些用例需要整理呢？如何才能做到让后面的人再也不用整理这些用例，而是很开心的按照一定的规范做着每一个日常或项目，以期投入更多的时间把力气用在刀刃上，不遗漏bug呢？正如题所说，我们要像对待自己的孩子一样对待每一个用例，用心写好每一个用例。以下是小女的一些拙见，提出来供大家讨论。:-）

　　一个好的接口/单元测试用例应该做到：

　　1、对环境没有依赖

　　2、验证点检验完全（不能因为用例编写经常拷贝而忽略或遗漏）

　　3、用例分类合理，命名通俗易懂

　　4、对数据没有依赖，数据由所测的代码自动创建。一定需要测试数据的情况下，也要将数据准备完全

　　5、每一个用例运行完成后都要删除测试数据

　　6、能够在一个用例中覆盖到的测试点，尽量在一个用例中完成，以减少后续对测试数据和用例本身的维护成本。

　　7、各个测试用例相互独立，不相互依赖

　　8、尽量减少和开发代码的耦合，能够从上层覆盖到的情况尽量从上层覆盖

　　9、通俗易懂，注释完全，后人很容易根据用例理解业务

　　10、用例结构清晰，测试用例也可以学习开发的代码，采用一些设计模式进行优化，提高用例本身的代码质量，减少后续用例的编写成本和维护成本

　　另外，如果能根据不同业务分门别类，不同业务的根目录或入口的地方增加注释类，或者主流程测试类里。一方面可以供后人参考，另一方面也可以用作自己的备忘录。和代码放一起，同样方便浏览。开发也习惯看代码里的注释，错误的地方容易及时发现，也利于和开发的沟通。当然，这里所说的指的是注释一些比较细节的代码实现方面的业务点和总结。

　　更重要的是，如果能定义一个用例规范，我们测试也可以像开发一样进行review. 功能测试的会对手工执行的用例进行评审，开发组会对代码进行review。我们接口测试会对用例设计进行评审，那么同样也可以对用例实现进行review. 虽然不同项目的业务不同，测试用例实现方式框架也可能不同，但我相信一个好的测试用例的标准一定是相同的。

　　我相信，在那么多双眼睛的监督下，如果我们每个项目的所有测试用例都能做到上面这些点，那么能做到让用例的维护变成一件轻松的事情，让用例一旦运行不过意味着一个bug的出现， 这样的日子离我们也不再遥远了。并且当有我们离开现在的项目组时，我们曾经用心编写的用例不会因为维护成本太高，而变成一堆一文不值的垃圾。

　　但愿这样的日子离我们不再遥远，也相信它很快会到来！