[如需转载，请在转载时注明出处，并保证本文的完整性]
先佩服一下自己的破记性吧，测试用例设计，作为测试人员最基础的基本功，已经开始淡忘了，逼着自己总结一下。。。
——如何划分测试用例粒度？
关注有效功能点；用例的粒度可以界定到有效功能点的层级，而不必细化到其特性。有效功能：就是指在被测应用所涉及的实际业务中，当用户在手工状态下进行工作时，整个业务流程中对用户来说，具有实际意义那些功能。
——测试用例要写到多详细？
测试用例的详细程度和测试用例的可维护性，这似乎是鱼和熊掌不能兼顾的事情。
测试用例是否要详细到每一个不懂业务的新人都能看懂？这可能得溯源到：测试用例的作用是什么？是指导测试执行，还是为了让新人熟悉业务？答案是不言而喻的。
再回到我们编写和执行TC的实际场景，一组功能点的测试用例集往往都有相似的操作步骤、校验方法，所不同的是测试数据和预期结果，包括执行的时候，也不会过多依赖每个TC书写的操作步骤，而是针对不同的测试数据检验其结果，所以重要的是从庞杂的用例细节书写中释放出来，关注测试数据、测试场景的设计。
——测试用例设计方法
接触到的方法大致有：功能分解、等价类、边界值、判定表、正交、因果图、流程分析法、状态迁移法。
1、功能分解先一带而过，但是越来越发现这是一种非常有帮助的方法，通过功能分解整理出功能列表，能够比较清晰地看到功能覆盖的范围，对界定测试范围、制定测试计划、启发测试思路都有帮助；
2、“等价划分是把程序中的所有可能的输入划分为若干等价类，然后从每一类中选取具有代表性的数据进行测试”，它是避免穷举测试的一种方法，往往用于检查各个条件单独输入的情况，不适用于检查输入间存在组合关系的情况。
3、边界值往往是等价类的一种补充（相近的还有一个临界值的概念，有点生疏，暂略不表）
4、判定表和正交都适合输入条件间存在组合关系，依赖多个逻辑条件的取值的操作。设计TC时我们往往倾向于使用正交，因为相对于判定表，正交出来的组合数量会少很多很多，但其中会隐藏风险（曾经就遇到过啊。。。），对于输入条件间精度要求高的情况，宁可选择判定表。另外，判定表和正交都是用来检验正常的情况，异常情况的用例还需要用错误推测等方法来补充。
5、因果图用于描述系统的输入和输出之间的因果关系和制约关系，往往是和判定表结合使用。
6、流程分析法其实是从白盒测试中的路径覆盖法借鉴过来的黑盒测试方法。其基本步骤就是：画出业务流程图、定义状态节点和条件分支、确定测试路径（基本流和备选流）、最后选择测试数据构造测试用例。
他山之石：
测试用例设计白皮书－－等价类划分方法:http://www.uml.org.cn/Test/200902128.asp
用正交实验法设计测试用例:http://www.uml.org.cn/Test/200907238.asp
组合测试法中的全对偶测试法:http://www.uml.org.cn/Test/201108294.asp
测试用例设计白皮书－－判定表驱动分析方法:http://www.uml.org.cn/Test/200902128.asp
测试用例设计方法之状态迁徙图法:http://www.uml.org.cn/Test/200902128.asp
