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

　　测试用例的覆盖，这是个比较大的问题，我在这里只是初略的提一下，很多书中都有介绍，我才学了点皮毛。简单的，测试用例，第一必须保证包含了你所要测试对象的所有功能点；第二，必须有至少有正反两个测试项。另外还一个等价划分，这个方法我想，这是基本的要求了，但是也是用的多的，重要的。其它的某某方法，也可以学习学习，必要的时候说不定用的上，比如要测试的对象关系特复杂的时候，因果图的方法可以试试了。老实说，那些方法我一个也没用过，因为基本上用不上，用它们简直是浪费脑力，呵呵。

　　测试用例的跌代，一个不可避免的过程。我到现在也写了一两篇测试用例文档了，没有一次是一次搞定的。一个是因为刚开始对需求及详细设计文档理解的不深，疏忽了一些比较隐蔽但重要的测试点，第二则是在编写测试用例期间软件需求有可能出现一些小的变化。记得有一次我写完一遍测试用例的时候，自认为快写完了，很高兴，发现才二十几页，然而到终我真的觉得可以完工的时候，文档页数翻了一倍，五十几页，我还真是头一次写这么多的字。

　　后一个，持怀疑态度。理论上说，测试应该从需求开始抓起，参与需求的评审，对详细设计也要测试，但目前我们并没有做这么多，或者说做得不完全。根据现状，有时候我只能依靠详细设计来写测试用例，所以先必须假设详细设计上面写的是对的。然后我们开始理解详细设计，持怀疑态度的看，在我们对详细设计有了一定的理解之后（刚开始好不要怀疑）。这时候会有几种情况，一种，看的不是很明白；第二种，好像有遗漏的地方；第三种，好像错了（仅仅指写错了字，因为我们还没有需求规格可以参考）。要继续写测试用例必须处理这三个问题，对第一种，没办法，请教写这个文档的程序员；对第二种，还是请教写这个文档的程序员；对第三种，告诉他这里错了。当然你也可以选择另一种途径，暂时跳过，不过迟早还是要解决的。在没有需求文档的条件下，有一定的风险，不知道详细设计是否和需求是否一致，在需求文档没有出来之前，对自己怀疑的地方问一下需求人员，在需求文档出来之后，和详细设计文档对照一下，一般详细设计文档都不会错到哪去，呵呵。

　　好像这些吧，自己慢慢体会也出来了，但是一定要先硬着头皮写用例，写着写着好了。