测试用例的模版其实没有太多的差异，而在我刚开始接触测试时总想找一个好的测试用例模版。通常来说，测试用例模版包括主要的三项：操作说明，预期结果和否通过。有了这三项，其它的根据你的需要来添枝加叶了。

    问题是如何填满这个模版，即如何编写测试需求和用例。有的人把测试需求和测试用例分开来编写的。测试需求作为一个文档，测试用例作为另一个文档，在我开始写测试用例之初，一直有这样一个疑问：测试需求和测试用例只写一个不可以了吗？的确，测试需求和测试用例本身没有太明显的界限，测试需求写得细的话和测试用例没有太多的差别了。根据详细的测试需求是可以执行测试的，这一点我不怀疑。其实我一直持有一种观点，如果时间不够的话，可以只写测试需求，因为毕竟现在测试基本上都是由测试员本人执行自己的测试需求和测试用例，如果测试需求将功能点都列出来了，操作过程自己都知道。不过，我现在还是将测试需求和测试用例写在一起的，时间也好像还比较充足。

    下面举一个简单的测试需求和测试用例的例子：

 


 

    以上是一个测试需求和测试用例的对比，可以看出上面的测试用例比测试需求描述的要详细的多，一般来说我是按上面的方式来写的，测试需求只说明一个整体要求，测试用例则考虑多种情况。

    至于测试需求和测试用例的编写，还一个容易疑惑的问题：粒度。简单的说是细化到何种程度。 写的粒度太大，不利于写清楚测试对象及操作过程。如果是自己执行测试自己写的测试用例还好一点，知道你自己写的是什么，在什么前置条件下可以执行这个测试用例，如果是别人执行你写的测试用例，特别是对系统还不熟的人，难说不碰到麻烦了，可能是找不到操作说明中的第一步在什么地方操作，也有可能是对测试结果产生疑惑，这个结果是和测试用例上面写的测试结果是一样的吗？我想这样的测试用例不能算好的测试用例。 写的粒度太小，自己都会受不了，你会埋怨要写的东西实在是太多了，更重要的是，写测试用例的时间用的越多，你可以用来执行测试用例的时间越少，这点我有过类似的经历。 粒度的权衡，是个麻烦的事情，不过对于刚开始写测试用例的人来说，建议开始还是写细一点，写的多了，也会慢慢的体会到哪些地方可以偷偷懒了，呵呵。