[作者提醒：从Visual Studio 2015 RC 版本开始，“Smart Unit Tests”已经更名为“IntelliTest”]
在这篇文章中，我们介绍了IntelliTest，如果你还没有阅读过，强烈建议先阅读它。
我们接着讨论IntelliTest的相关内容。IntelliTest是怎么自动生成高覆盖率的测试用例的？它运行的原理是什么？如果可以将其运行原理抽象成模型，对我们理解并使用它都大有帮助。
运行时的检测和监控是IntelliTest得以发挥威力的核心：
- 首先，测试引擎检测被测代码，并注入回调以监控其执行。接着，测试引擎会为被测代码创建一些最简单的测试用例，这些测试用例主要由输入的参数类型决定。这些简单的测试用例便是测试引擎生成其他用例的基础。
- 有了这组最基础的测试用例，测试引擎便监控其执行，并计算每一个用例执行后的代码覆盖率，同时会跟踪用例在代码中的执行流程。如果所有的分支都已被覆盖，则停止这个过程。所有异常行为都会被看作一个分支，就像代码中的分支一样。如果最终有分支未被覆盖，测试引擎会记录未被覆盖的分支的分界点，并计算要达到这些分支的输入值。
- 测试引擎内部有一个约束求解器，会记录哪些输入会到达未覆盖分支的程序分割点，然后基于这些输入，引擎会尝试从约束求解器中重新生成新的输入以覆盖更多分支。
- 如果约束求解器能够生成一个新的输入，则继续运行被测代码。
- 运行后，如果覆盖率有提升，那么这个输入将被作为一个新的测试用例。
引擎会重复2~5步，直到所有分支被覆盖，或者达到我们配置的探索终止条件。
下面这张图表，描述了上述五个步骤：
我们把这整个过程叫做“探测”，在“探测”过程中，被测代码可能被运行很多次 - 但不是每一次运行都能提高覆盖率，只有哪些提高了覆盖率的用例才会被记录。
下面的图表展示了探测的生命周期，从中我们可以看出，代码可能被运行很多次，但只有那些提高了覆盖率的用例会被记录。
有了以上理论知识的了解，接下来我们看一个实际的例子：
详细的探测过程如下：
- 引擎使用最简单的输入作为初始用例（一般情况下都是基于类型得到初始用例），在这个例子中，参数是数组，那么作为初始用例的输入是：a=null
- 有了初始用例，引擎开始执行代码，在这期间，引擎会监控所有的条件判断
- 在这个例子中，传入null作为参数，函数将直接返回
- 接下来，引擎会根据失败的条件判断去询问约束求解器是否有一组新的输入可以使得失败的条件通过
- 如果确实存在，那么这组新的输入将作为一组新的用例进行执行
引擎重复着上面的步骤直到代码被完全覆盖或达到配置的终止探测条件。在引擎内部，它会把所有被检测到的条件判断构成一棵树，每次运行一个用例，这棵树就增长一点，同时引擎用例也覆盖更多代码。经过多次迭代后，探测结束，并得到了图表中表格部分的结果。我们可以看出，只要4个用例就可以完全覆盖代码，这就是一个高覆盖率的测试套件了！
但是，单元测试的正确性验证呢？引擎又怎会知道代码运行是否符合逻辑呢？
这时候，断言就登场了。断言可以以Debug.Assert的形式工作，因为引擎生成了覆盖所有分支的用例，所以这是一个高效的bug发现工具。
ok，我们总结一下这篇博客的内容。一开始，我们提出了一个问题，我们想要知道IntelliTest是如何工作的，为此，我们从抽象模型入手，分析了关于“探测”、“代码覆盖率”、“运行次数”以及“断言”的概念。这些名词，在运行IntelliTest时都会看到。除此之外，我们还有一些问题需要弄明白，比如：报告出来的“issues”时啥意思？“exploration boundaries”呢？如果你对这些感兴趣，让我们知道，我们会在接下来的博客中一一讨论。
2017-10-20 09:43:52
