现在很多文章都有介绍如何使用测试框架来测试，但只介绍工具如何使用，却不介绍如何从研发角度设计测试用例，写出来的单测往往很难维护，看上去就只是为了维持kpi而已。
测试用例设计的MECE原则
测试用例设计有很多经典的方法，比如等价类划分法、边界值分析法、错误推测法等。这些测试方法提供了设计的思路，但是却没有说明如何评判测试用例是否已经设计完全。评判测试用例有没有设计完全，是确保业务逻辑bug-free的关键。因此，我们在设计测试用例时，需要确保测试用例设计遵循MECE原则。测试用例设计遵循MECE原则，指的是对测试用例进行分类时，分类应该是互斥（Mutually Exclusive）且完备（Collectively Exhaustive）的。将测试用例根据MECE原则进行分类可以更好地帮助我们设计出符合需求的测试用例，从而更好的保证软件质量。下面就以排队需求作为例子，说明测试用例设计是如何满足MECE原则的。
- 有消费者、队列组、队列、任务四种角色，其关系如下：
有一批队列，在每个队列中都有一批任务，不同的队列可以组成队列组，消费者可以订阅不同的队列组。在消费者消费队列中的任务时，需要按照订阅关系和一定的规则消费队列中的任务。在消费任务时，每个任务都可能对应多个消费者，当其中一个消费者忙碌时，需要自动分配给下一个消费者。
- 另外，因为一个消费者可以同时订阅多个队列组，所以需要从多个队列组里选取一个任务出来进行消费。其消费规则如下所示：
消费规则文字详述如下：
如果专属队列有任务，则从专属队列中选择排队时间最长的任务
如果专属队列无任务，VIP队列中有任务，则选择VIP队列中的任务
- 对VIP队列中的任务按队列优先级进行排序，选择优先级最高的队列
- 如果优先级最高的队列只有一个，则从该队列中选择排队时间最长的任务
- 如果优先级最高的队列有多个，则从这多个队列中选择排队时间最长的任务
如果专属队列无任务，VIP队列中无任务，则选择非VIP队列中的任务
- 对非VIP队列中的任务按队列优先级进行排序，选择优先级最高的队列
- 如果优先级最高的队列只有一个，则从该队列中选择排队时间最长的任务
- 如果优先级最高的队列有多个，则从这多个队列中选择排队时间最长的任务
在上篇文章中引入了订阅组的概念，如图所示：
一个消费者订阅的所有队列组组成一个订阅组，不同消费者的订阅组可能是不一样的，用一张图简单表示这种关系：
要先分析清楚复杂的问题，首先要做的就是按一定的标准分解问题，将问题的规模变小，变成一个个子问题，然后逐个解决，最终就解决了整个复杂的问题。分类的方法有很多，但是无论使用哪种方法，需要确保的是，按某种标准分解问题之后，子问题之间是相互独立的，不存在任何依赖的，且分解后的n个子问题，最终也可以组合成原始的问题，不至于会漏掉某些可能的情况。这样分解问题才满足MECE原则。如果分解问题后不满足MECE原则，那必定会存在遗漏测试用例的情况，或者有重复测试用例的情况，如果在后续设计的时候发现有这样的问题，那可能就要重新回过头来确定分解的标准了。
在这个需求中，我会将这个复杂需求按这样的标准进行分解：
- 订阅了同一订阅组的消费者消费任务
- 订阅了不同订阅组的一类消费者消费任务
为什么这样分解就能满足MECE原则？因为对于整个任务消费情况来看，只有订阅了同一订阅组，和订阅了不同订阅组这两种情况，不可能存在订阅的订阅组既相同，又不同的情况。这样就是满足MECE原则的问题分解。
订阅了同一订阅组的消费者消费任务
对于这种情况，其实就是从一个订阅组内选择一个任务出来，分配给订阅了这个订阅组的消费者。所以，问题就转化成根据消费规则选择订阅组内的任务时，如何满足MECE原则。其实这里的用例的设计，已经在上面的需求描述里给出来了，此处再列出来：
这样分解为什么是满足MECE原则的呢？在这个比较规则中，比较的顺序是按 队列类型选择、优先级队列选择策略、任务选择策略 这三种策略依次比较下来的。这几种策略是根据既有的需求分类得来的，相互之间没有重叠的情况，所以在策略的分类上是满足MECE原则的。然后对于每一种选择策略，其分支的组成都是互斥且完备的，比如队列类型选择策略中，VIP队列只存在有任务和无任务两种互斥的情况，不可能存在既有任务又无任务的可能性，所以这样的用例设计就能覆盖到所有的情况。
我们可以用这样的标准去审视每一种策略，看看是否都满足MECE原则，如果都满足，那么这样的分类就能确保你不会遗漏任何一种情况。
订阅了不同订阅组的一类消费者消费任务
订阅了同一订阅组的消费者消费任务，是比较流程化的，用思维导图就可以比较方便地梳理出来。但是像订阅了不同的订阅组的消费者，用思维导图就不太好分析出来了。这个时候，我们可以稍稍运用一些基础的数学知识：集合。
试想一下，我们会如何表示一个消费者订阅了哪些队列组？比如：
- 消费者 C1 订阅了队列组 QG1, QG2，那我们会这样表示: C1: {QG1, QG2}；
- 如果是消费者 C2 订阅了队列组 QG2, QG3，那就会这样表示：C2: {QG2, QG3}。
- 这样消费者C1和C2订阅的队列组之间，就形成了交集，相交的队列组就是QG2。
从这个角度去思考，对于订阅了不同订阅组的一类消费者消费任务的情况，就变成了考察如何穷举两个集合之间的关系了。从以往学过的简单的数学知识就可以知道，两个集合之间的关系，无非就是 子集、全集、交集、无交集 这四种情况。
因此，我们可以用韦恩图来表示集合之间的关系：
从这个图里，我们以消费者C1作为考察对象，则其他消费者的订阅组和C1之间的关系是：
- C2 的订阅组是 C1 订阅组的子集
- C3的订阅组是C1订阅组的全集
- C4订阅组和C1订阅组的交集是 {QG2}
- C5订阅组和C1订阅组之间无交集。
这样，我们在写测试用例代码时，从消费者的编号和队列组的编号就知道，只需要用5个消费者和4个队列组就可以穷举所有的情况。而且这几种情况，都是相互独立又完全穷尽的。
再论先写代码还是先写测试
在前面一篇文章中讨论了究竟应该先写代码还是先写测试，在这里想结合这个需求再强调一下，其实先写哪种都没有关系，关键是要先设计测试用例。在这个需求例子中，经过这一轮分析，即使你没有写一行代码，通过对测试用例的设计，你也对最终要实现成什么效果已经了如指掌。甚至，你可以在不写一行实现代码的情况下，就可以把对应的测试用例代码写出来。当然，不是说要一下子把所有的用例都写完，而是用TDD的方式，先写一个测试用例的代码，然后再写这个测试用例对应的实现代码，测试通过后再实现下一个测试用例。其实设计测试用例的过程就像是一种直观的方式来写测试用例代码的过程，如果你之前认为先写测试再写实现这样的开发模式有点违反“常识”，不妨试试在开发之前先对着需求，按MECE原则设计出测试用例，然后再去写测试用例代码，或者去写实现代码，你就会发现，TDD方式的开发模式，是非常合理且顺畅的。
而现实中，有很多人都认为TDD并不符合实际开发过程。但其实，这篇文章介绍的测试用例设计方法和设计过程，就是在做着TDD开发模式中的一个至关重要的环节：任务拆分（tasking）。无法很好地实践TDD，本质上不是因为这种方式违反常识，而是因为开发者在开发之前无法很好地理清需求并做好任务拆分，以致于在模仿TDD的形式时遭遇到了挫败感，而忽略了TDD最核心的部分-任务拆分。所以，在之前的文章中我也说过，先写测试或先写代码，其实都不重要，重要的是要先按MECE原则设计出测试用例，其实也就是要按照MECE原则做好任务拆分，这样无论你是先写实现还是先写测试，或者是用其他的方式实现，只要最终实现的效果是符合事先设计好的测试用例的预期的，那对产品最终的质量就会有了保障。
总结
在这个需求中运用了MECE原则设计测试用例，在实际开发中的确做到了这部分业务逻辑0bug。希望这篇文章能给大家一点启示，测试用例的设计过程，本质上就是在做任务拆分。对复杂需求的测试用例，要实现对应的测试用例代码，对于前置条件的构造也很麻烦。这部分就留待下一篇文章解决了。
最后作为一位过来人也是希望大家少走一些弯路，在这里我给大家分享一些软件测试的学习资料和我花了3个月整理的软件测试自学全栈，这些资料希望能给你前进的路上带来帮助。
视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。
