测试用例的模版其实没有太多的差异，而在我刚开始接触测试时总想找一个好的测试用例模版。通常来说，测试用例模版包括最主要的三项：操作说明，预期结果和否通过。有了这三项，其它的就根据你的需要来添枝加叶了，我blog上面有一个我现在用的测试需求及用例模版，可参考一下。
　　问题是如何填满这个模版，即如何编写测试需求和用例。有的人把测试需求和测试用例分开来编写的。测试需求作为一个文档，测试用例作为另一个文档，在我开始写测试用例之初，一直有这样一个疑问：测试需求和测试用例只写一个不就可以了吗?的确，测试需求和测试用例本身没有太明显的界限，测试需求写得细的话和测试用例就没有太多的差别了。根据详细的测试需求是可以执行测试的，这一点我不怀疑。其实我一直持有一种观点，如果时间不够的话，可以只写测试需求，因为毕竟现在测试基本上都是由测试员本人执行自己的测试需求和测试用例，如果测试需求将功能点都列出来了，操作过程自己都知道。不过，我现在还是将测试需求和测试用例写在一起的，时间也好像还比较充足。
　　下面举一个简单的测试需求和测试用例的例子：
　　测试需求： 在编辑框中只能输入1～4中的任意一个数字
　　测试用例： 1.考虑输入非数字的情况
　　(不是完整 2.考虑不输入的情况
　　的测试用例格式) 3.考虑输入的不是1～4中的情况
　　4..................
　　以上是一个测试需求和测试用例的对比，可以看出上面的测试用例比测试需求描述的要详细的多，一般来说我是按上面的方式来写的，测试需求只说明一个整体要求，测试用例则考虑多种情况。
　　至于测试需求和测试用例的编写，还一个容易疑惑的问题：粒度。简单的说就是细化到何种程度。 写的粒度太大，不利于写清楚测试对象及操作过程。如果是自己执行测试自己写的测试用例还好一点，知道你自己写的是什么，在什么前置条件下可以执行这个测试用例，如果是别人执行你写的测试用例，特别是对系统还不熟的人，就难说不碰到麻烦了，可能是找不到操作说明中的第一步在什么地方操作，也有可能是对测试结果产生疑惑，这个结果是和测试用例上面写的测试结果是一样的吗?我想这样的测试用例不能算好的测试用例。 写的粒度太小，自己都会受不了，你会埋怨要写的东西实在是太多了，更重要的是，写测试用例的时间用的越多，你可以用来执行测试用例的时间就越少，这点我有过类似的经历。 粒度的权衡，是个麻烦的事情，不过对于刚开始写测试用例的人来说，建议开始还是写细一点，写的多了，也会慢慢的体会到哪些地方可以偷偷懒了，呵呵。
　　测试用例的覆盖，这是个比较大的问题，我在这里只是初略的提一下，很多书中都有介绍，我才学了点皮毛。最简单的，测试用例，第一必须保证包含了你所要测试对象的所有功能点;第二，必须有至少有正反两个测试项。另外还一个等价划分，这个方法我想，这是最基本的要求了，但是也是用的最多的，最重要的。其它的某某方法，也可以学习学习，必要的时候说不定用的上，比如要测试的对象关系特复杂的时候，因果图的方法就可以试试了。老实说，那些方法我一个也没用过，因为基本上用不上，用它们简直是浪费脑力，呵呵。
　　测试用例的跌代，一个不可避免的过程。我到现在也写了一两篇测试用例文档了，没有一次是一次就搞定的。一个是因为刚开始对需求及详细设计文档理解的不深，疏忽了一些比较隐蔽但重要的测试点，第二则是在编写测试用例期间软件需求有可能出现一些小的变化。记得有一次我写完一遍测试用例的时候，自认为快写完了，很高兴，发现才二十几页，然而到最终我真的觉得可以完工的时候，文档页数翻了一倍，五十几页，我还真是头一次写这么多的字。
　　最后一个，持怀疑态度。理论上说，测试应该从需求开始抓起，参与需求的评审，对详细设计也要测试，但目前我们并没有做这么多，或者说做得不完全。根据现状，有时候我只能依靠详细设计来写测试用例，所以先必须假设详细设计上面写的是对的。然后我们开始理解详细设计，持怀疑态度的看，在我们对详细设计有了一定的理解之后(刚开始最好不要怀疑)。这时候会有几种情况，一种，看的不是很明白;第二种，好像有遗漏的地方;第三种，好像错了(仅仅指写错了字，因为我们还没有需求规格可以参考)。要继续写测试用例必须处理这三个问题，对第一种，没办法，请教写这个文档的程序员;对第二种，还是请教写这个文档的程序员;对第三种，告诉他这里错了。当然你也可以选择另一种途径，暂时跳过，不过迟早还是要解决的。在没有需求文档的条件下，有一定的风险，不知道详细设计是否和需求是否一致，在需求文档没有出来之前，对自己怀疑的地方问一下需求人员，在需求文档出来之后，和详细设计文档对照一下，一般详细设计文档都不会错到哪去，呵呵。