首先，我们先来思考一个问题：单元测试中，哪一个环节更重要？
要回答这个问题，我们先需要了解单元测试到底有哪些环节，读到这里，请暂停一分钟，回忆一下我们平时的单元测试实践（请最小化浏览器）。
对于单元测试可以划分成哪些环节，你是不是有了自己的认识呢？
按照自己的理解，不管怎样划分，都是可以的。小编根据自己的经验，将其划分成如下几个环节：
- 分析业务
- 设计用例
- 实现用例
- 重构
- 持续集成
接下来，请暂停一分钟，思考一下这五个环节中，哪一个更重要（请最小化浏览器）。
经过一分钟的思考，相信你有了自己的认识。
针对这个问题，小编并没能确定哪一个环节更重要，似乎，需要每个环节的良好配合才能发挥各个环节的最大作用。
这篇文章要讲的内容就是这五个环节中的 设计用例 环节。
做一个练习
请针对下面这个业务设计用例（可以想象成有一个返回true或者false的方法，接受一个字符串，按照定义的规则做检查）
请暂停三分钟，尽量思考更多的用例（请最小化浏览器）。
如果你之前没有任何测试经验，你的用例可能有这么会包含这么一些情况：
等价类划分
针对这个问题我们可以把输入的情况按照下面的方式进行分类：
这样分类后，我们发现，在每个类别区间的输入都具有相同的意义，这就是等价类划分 。
通过等价类划分，可以迫使我们分析业务的边界，明确哪些用例是真实有效的，避免了不必要的无效用例。
等价类划分可以分为有效等价类和无效等价类
- 有效等价类：是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。
- 无效等价类：无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。
在这个练习中，“6-18个字母，数字或字符” 就是有效等价类，另外两个区间属于无效等价类。
在做等价类划分时，这两种等价类都是必不可少的。
边界值分析法
边界值往往有更多出错的可能，所以在设计用例时需要对边界值格外敏感。边界值分析法就是 对输入或输出的边界值进行测试。通常边界值分析法是作为对等价类划分法的补充。
针对这个练习，至少有这么些情况属于边界值：
在业务描述时抓住一些关键的点可以帮助我们识别业务中的边界值，比如当业务中包含如下这些描述时，往往就需要留意边界值了：
- 最XX（最小/大、最快/慢、最高/底.....）
- 超过
- 在内
- 相邻
- ...
当我们识别到了边界值，对于越界的用例设计是非常有必要的，这是对程序健壮性的验证。
- 短了再短/长了再长
- 第一个减1/最后一个加1
- 少了更少/多了更多
- 刚好超过/刚好在内
经过了等价类划分和边界值分析，我们设计出了一些用例，但是对于业务中的 “数字、字母或符号” 还未进行考虑。对于用户的输入情况无法估计，这就导致可能存在多种组合，针对这种组合，如果凭空想是很容易漏掉的。接下来使用的 判定表分析 就是为了解决这种问题。
判定表
针对这个练习，只考虑输入的字符的情况，可以分成：字母、数字、英文字符、非英文字符、图标。我们需要考虑这些情况的组合，如果没有判定表，是比较头痛的。
判定表的定义：判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
这里以判定表的部分截图为例;
通过判定表，我们可以清楚的罗列各种情况，降低漏掉的可能性。
有时候可能会遇到分类特别多的情况，这会导致判定表非常庞大。不一定要把每个小细节作为一个项目，可以以一个维度，一个类别作为一个分类。进而减少测试用例维护的工作量。
结果
经过上面几轮方法的透析，我们可以得到如下的用例表格。
这个表格已经包含了这个业务的绝大多数用例情况（毕竟完美的用例套件是不存在的）。
上面介绍的三种方法不是一定要按照刚才介绍的顺序来使用，只要能够在设计用例的时候想到有这些方法，并用这些方法进行分析，基本就可以覆盖绝大多数情况。
理想是美好的，现实往往比较苦涩。当我们再分析具体业务，尝试用上面的方法去分析时，有时候并不能很快的找到合适的等价类划分方法，边界识别也可能模糊不清，被我们漏掉。
仔细分析上面的三种方法可以发现，其中都包含了一个关键的步骤：变量识别。
变量识别
所谓变量识别，就是识别业务中的可变的关键点，通过不断的改变这些关键点来构造用例。
举个栗子
业务描述：针对当前系统用户，只在第一次调用时，执行委托的方法。
针对此描述，咱们再暂停三分钟，请思考其中的变量，以及其可变化的情况（请最小化浏览器）。
三分钟过后，你是不是识别到了其中的变量呢？
小编识别到了这么些变量;
- 当前系统用户：如果不是当前系统用户会怎样？
- 第一次调用：如果不是第一次调用会怎样？
- 委托：这个委托是有返回值呢，还是没返回值？如果委托中抛出了异常会怎样？
你是不是比小编识别到更多变量呢？做个练习，请针对下面的业务描述识别变量，并设计用例。
“ 执行所有事件，在执行过程不抛出异常，在全部运行之后如果有异常则抛出所有异常”
错误推测
除了上面介绍的方法，还有一种基于经验的用例设计方法：错误推测。
所谓错误推测，基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。
错误猜测大多基于经验，需要从边界值分析等其他技术获得帮助。这种技术猜测特定软件类型可能发生的错误类型，并且设计测试用例查出这些错误。
对有经验的工程师来说，错误猜测有时是唯一最有效发现Ｂug的测试设计方法。
但是经验是需要积累的，是需要时间的，对于一个新人来讲，快速获得经验是提升的法宝，对于老人来讲，把经验传递给新人，帮助新人快速成长，应该是义不容辞的责任。
所以，老人把经验都记录下来对自己和新人都会非常受益。
总结
在这边文章中，我们介绍了如下设计用例的方法：
- 等价类划分
- 边界值识别
- 判定表分析
- 变量识别
- 错误推测
每种方法都不复杂，也都能帮我们解决问题，如果能够在每次设计用例的时候想到这些方法，基本用例设计就比较全了。
参考资料：《单元测试的艺术》《软件测试》《软件测试的艺术》
