用例篇：
看了很多资料，看了很多书，发现测试用例的基本理论基本是一致的，各种理论，但实践起来不容易。之前看过ebay的一个质量总监说过一段话：
“从理论层面来讲，设计用例的方法有很多，如果你去翻阅测试图书或网络教程，会发现一堆让人眼花缭乱的测试方法，比如等价类划分法、边界值分析法、错误推测方法、因果图方法、判定表驱动分析法、正交实验设计方法、功能图分析方法、场景设计方法、形式化方法、扩展有限状态机方法等等，但是从软件企业实际的工程实践来讲，真正具有实用价值并且常用的只有前三种方法。 当然，对于那些与人的生命安全直接或间接相关的软件，比如飞行控制、轨道交通的列车控制、医疗检测相关的软件或者系统，由于需要达到几近变态的测试覆盖率要求，会采用更多的测试设计方法。但对大多数的软件测试而言，综合使用等价类划分、边界值分析和错误推测这三大类方法就足够了。”
确实是这样，等价类划分、边界值分析和错误推测方法，可以满足绝大多数软件测试用例设计的需求。但场景法，判定表的使用还是经常要的。
最后，必须要深入理解被测软件的架构设计，深入软件内部的处理逻辑，统计需求覆盖率和代码覆盖率。还有因果图现实中基本不用了，其实最后也是变成判定表，可以使用正交表替代，使用比较简单。
简单介绍下我经常使用的几个用例设计方法的场景介绍：
一、等价类：程序的输入域能划分成若干个子集；
二、边界值：需求规定了输入域的长度、个数或者范围，可以用边界值进行补充；
三、正交表：多条件组合的查询或者筛选；这个尤其是在查询的时候管用。
四、场景法（流程分析法）：模拟用户操作软件时的各种场景，验证是否符合客户需求。
五、错误推测法：一般在业务流，数据流的测试中会使用，常用的思考就是，如果这个环节挂了会怎样。经验越丰富的，才能设计更好的错误推测用例。
最后，其实测试用例覆盖率跟个人的整体测试能力有关系，但不管是谁，用例永远会有缺漏，所以用例评审是非常重要的环节，在重要的核心功能上，用例评审是一定要的。
