.NET单元测试（四）：用例设计

首先，咱们先来思考一个问题：单元测试中，哪个环节更重要？

要回答这个问题，咱们先须要了解单元测试到底有哪些环节，读到这里，请暂停一分钟，回忆一下咱们平时的单元测试实践（请最小化浏览器）。

---

对于单元测试能够划分红哪些环节，你是否是有了本身的认识呢？

按照本身的理解，无论怎样划分，都是能够的。小编根据本身的经验，将其划分红以下几个环节：

• 分析业务
• 设计用例
• 实现用例
• 重构
• 持续集成

接下来，请暂停一分钟，思考一下这五个环节中，哪个更重要（请最小化浏览器）。

---

通过一分钟的思考，相信你有了本身的认识。

针对这个问题，小编并没能肯定哪个环节更重要，彷佛，须要每一个环节的良好配合才能发挥各个环节的最大做用。

这篇文章要讲的内容就是这五个环节中的 设计用例 环节。

作一个练习

请针对下面这个业务设计用例（能够想象成有一个返回true或者false的方法，接受一个字符串，按照定义的规则作检查）

请暂停三分钟，尽可能思考更多的用例（请最小化浏览器）。

---

若是你以前没有任何测试经验，你的用例可能有这么会包含这么一些状况：

等价类划分

针对这个问题咱们能够把输入的状况按照下面的方式进行分类：

这样分类后，咱们发现，在每一个类别区间的输入都具备相同的意义，这就是等价类划分 。

经过等价类划分，能够迫使咱们分析业务的边界，明确哪些用例是真实有效的，避免了没必要要的无效用例。

等价类划分能够分为有效等价类和无效等价类

• 有效等价类：是指对于程序的规格说明来讲是合理的、有意义的输入数据构成的集合。
• 无效等价类：无效等价类指对程序的规格说明是不合理的或无心义的输入数据所构成的集合。

在这个练习中，“6-18个字母，数字或字符” 就是有效等价类，另外两个区间属于无效等价类。

在作等价类划分时，这两种等价类都是必不可少的。

边界值分析法

边界值每每有更多出错的可能，因此在设计用例时须要对边界值格外敏感。边界值分析法就是 对输入或输出的边界值进行测试。一般边界值分析法是做为对等价类划分法的补充。

针对这个练习，至少有这么些状况属于边界值：

在业务描述时抓住一些关键的点能够帮助咱们识别业务中的边界值，好比当业务中包含以下这些描述时，每每就须要留意边界值了：

• 最XX（最小/大、最快/慢、最高/底.....）
• 超过
• 在内
• 相邻
• ...

当咱们识别到了边界值，对于越界的用例设计是很是有必要的，这是对程序健壮性的验证。

• 短了再短/长了再长
• 第一个减1/最后一个加1
• 少了更少/多了更多
• 恰好超过/恰好在内

通过了等价类划分和边界值分析，咱们设计出了一些用例，可是对于业务中的 “数字、字母或符号” 还未进行考虑。对于用户的输入状况没法估计，这就致使可能存在多种组合，针对这种组合，若是凭空想是很容易漏掉的。接下来使用的 断定表分析 就是为了解决这种问题。

断定表

针对这个练习，只考虑输入的字符的状况，能够分红：字母、数字、英文字符、非英文字符、图标。咱们须要考虑这些状况的组合，若是没有断定表，是比较头痛的。

断定表的定义：断定表是分析和表达多逻辑条件下执行不一样操做的状况的工具。

这里以断定表的部分截图为例;

经过断定表，咱们能够清楚的罗列各类状况，下降漏掉的可能性。

有时候可能会遇到分类特别多的状况，这会致使断定表很是庞大。不必定要把每一个小细节做为一个项目，能够以一个维度，一个类别做为一个分类。进而减小测试用例维护的工做量。

结果

通过上面几轮方法的透析，咱们能够获得以下的用例表格。

这个表格已经包含了这个业务的绝大多数用例状况（毕竟完美的用例套件是不存在的）。

上面介绍的三种方法不是必定要按照刚才介绍的顺序来使用，只要可以在设计用例的时候想到有这些方法，并用这些方法进行分析，基本就能够覆盖绝大多数状况。

理想是美好的，现实每每比较苦涩。当咱们再分析具体业务，尝试用上面的方法去分析时，有时候并不能很快的找到合适的等价类划分方法，边界识别也可能模糊不清，被咱们漏掉。

仔细分析上面的三种方法能够发现，其中都包含了一个关键的步骤：变量识别。

变量识别

所谓变量识别，就是识别业务中的可变的关键点，经过不断的改变这些关键点来构造用例。

举个栗子

业务描述：针对当前系统用户，只在第一次调用时，执行委托的方法。

针对此描述，我们再暂停三分钟，请思考其中的变量，以及其可变化的状况（请最小化浏览器）。

---

三分钟事后，你是否是识别到了其中的变量呢？

小编识别到了这么些变量;

• 当前系统用户：若是不是当前系统用户会怎样？
• 第一次调用：若是不是第一次调用会怎样？
• 委托：这个委托是有返回值呢，仍是没返回值？若是委托中抛出了异常会怎样？

你是否是比小编识别到更多变量呢？作个练习，请针对下面的业务描述识别变量，并设计用例。

“ 执行全部事件，在执行过程不抛出异常，在所有运行以后若是有异常则抛出全部异常”

错误推测

除了上面介绍的方法，还有一种基于经验的用例设计方法：错误推测。

所谓错误推测，基于经验和直觉推测程序中全部可能存在的各类错误, 从而有针对性的设计测试用例的方法。

错误猜想大多基于经验，须要从边界值分析等其余技术得到帮助。这种技术猜想特定软件类型可能发生的错误类型，而且设计测试用例查出这些错误。 对有经验的工程师来讲，错误猜想有时是惟一最有效发现Ｂug的测试设计方法。

可是经验是须要积累的，是须要时间的，对于一个新人来说，快速得到经验是提高的法宝，对于老人来说，把经验传递给新人，帮助新人快速成长，应该是责无旁贷的责任。

因此，老人把经验都记录下来对本身和新人都会很是受益。

总结

在这边文章中，咱们介绍了以下设计用例的方法：

• 等价类划分
• 边界值识别
• 断定表分析
• 变量识别
• 错误推测

每种方法都不复杂，也都能帮咱们解决问题，若是可以在每次设计用例的时候想到这些方法，基本用例设计就比较全了。

参考资料：《单元测试的艺术》《软件测试》《软件测试的艺术》