测试用例写的太细化了，则适应不了系统的变更需求; 写的太粗糙，则可操作性不强，太随意。那么如何设计测试用例呢？
笔者建议：关注“测试思想”而不是关注“操作步骤”；
作为测试用例设计人员：我们需要思考的是，如何理解基本流和备选流？如何深入分析并找到所有需要覆盖的路径和需要检查的特性？然后用容易理解的自然语言清晰的来描述我们将要如何进行测试。
传统的用例文档编写方式有两种：
1)填写操作步骤列表：对基本流和备选流进行分析后，他可以清晰描述你的测试思路；
2)填写测试矩阵：适合用来存放测试数据，特别是那些需要人工赋予一个正确的值的特性；
注：网络上对于这两种方式孰优孰劣的争论，将大家错误的引导向了两个极端：要么采用A，要么采用B。
纠正一个误区：对于工作方法的争论，本质上同工具的争论并不是一回事。如果不同的方法各有优势，我们完全可以通过变通的方法，把优势的部分组合在一起使用。
那么对于测试用例文档，已经被分成两个部分：
1)一部分是描述了测试用例执行者所应遵循的操作过程；
2)一部分是在操作中需要使用的测试数据；
这样做的原因是在我们的实际工作中，尤其是在进行功能测试时，很多时候都是使用雷同的操作过程和不同的测试数据来进行的。而使用上面的方法，可以不用再对原本在多个用例中重复出现的操作过程再次描述，而可以把更多的精力放到测试数据的设计和准备上。
用例管理成本考虑：测试需求同测试用例之间并非是一一对应的关系因为一条测试需求未必是明确的对应到一个有效功能的(其实测试需求本身同软件需求和用例之间也未必是一一对应的)。而我们的测试用例所关注的，应该是一个有效功能。不过不用担心，这种情况并不会增加管理测试需求和测试用例的成本，现在市面上提供的测试工具中已经有些是专门用来维护软件需求、测试需求同测试用例之间的关系的，并且它们提供的强大的视图功能还可以让您很容易的查看到测试用例对测试需求的覆盖情况。
原文地址：http://www.cnblogs.com/ziyaboke/p/4043510.html
