很多朋友可能已经听说了Spec Explorer 是一款强大的测试工具，但却不是很了解所谓的基于模型的测试到底是什么，这篇文章可以让你对模型测试有一个大致的认识。

如果你在互联网上搜索“Model-Based Testing”（即基于模型的测试，简称MBT），你将发现大量的信息。基于模型的测试并不是一个新生事物，也不局限于Spec Explorer这一工具，而是一个在学术界和工业界都已存在多年的概念。只是诸如Spec Explorer的工具将这一概念变得更易于学习和使用，并使得更广大的用户群能够广泛接受。

基于模型的测试是一个轻量级的，形式化的验证软件系统的方法。为什么这么说呢，因为首先，基于模型的测试对待测软件系统（通常被称为System Under Test，简称SUT）进行形式化的建模，设计出机器可读的模型；其次，和其他形式化方法比，基于模型的测试并不致力于让待测软件系统与规格说明在所有可能情况下都保持一致，而是系统化的从模型生成一组测试用例，使用这组测试用例测试待测软件系统，得到充分的证据说明待测系统的行为与模型期望是一致的。轻量级和重量级的方法的根本区别在于一个是充分证明，一个是完全证明。

目前完全验证一致性的代价非常高，重量级的形式化方法往往难以被应用到实际工程中，而基于模型的测试在这方面体现了优势，并已被运用到很多大型项目中。

下面是一个基于模型测试的简单图解：

基于模型的测试从一组需求开始，这组需求可以是文字，草图或者仅仅是团队成员的一些想法。

首先，我们需要创建一个机器可读的模型（#1），该模型表述了需求所表述的所有可能行为。这一步是由人工完成，并且是整个流程中工作量最大的一步。模型设计工作的关键点在于正确的抽象，一个建模者应该专注于系统的待测试的某一方面，而不需要关心系统的其余部分。不同部分可以被不同模型覆盖，但是每一个模型都确保自己在清晰的抽象层面上。

具体到Spec Explorer，模型被表述为一组规则，这些规则可以使用主流程序开发语言C#开发，不需要再学习其他特定的形式化建模语言，降低了学习难度。同时，Spec Explorer是一个Visual Studio集成开发环境的插件，所以提供了诸如语法颜色标记，自动补全和代码重构等功能。Spec Explorer还提供了一种小型的配置语言Cord（Coordination Language的简称）用于结合不同模型，生成代码以及选择特定的测试场景。

虽然创建模型的工作量很大，但是回报也是巨大的。通过把非形式化的需求转化为形式化的模型，你将很容易发现需求中遗漏的部分（譬如：如果我连按两次ESC键，系统到底应该怎么样？）。上图中的#2表明仅仅通过分析模型，就可以得到关于需求的反馈。

当模型成型以后，就到了Spec Explorer这种工具发挥作用的时候了。它能够通过分析模型自动生成测试用例（#3），包括提供给待测试系统的输入以及期望的输出，我们称之为测试预期。自动生成的测试用例一旦生成，就可以在一个标准的单元测试框架中（例如Visual Studio的测试框架或者NUnit）独立于模型运行。

这些测试用例提供了测试序列（#4）去控制待测试系统，同时观察（#5）待测试系统的返回值，并与生成预期值进行比较，然后做出判定（#6）测试是通过还是失败。测试用例可以被反复执行以重现bug，最后找到问题所在。

对测试结果的判定是对待测试系统的一个重要反馈（#7），但是找到待测试系统的bug并不是我们的唯一目标。一个失败的测试用例也有可能表明待测试系统的行为是正确的，但是模型的预期行为是错的！或者更进一步，模型本身是正确的反映了需求，但是需求本身从一开始就错了！

如果真的如此，你也不用特别悲观，基于模型的测试与传统人工测试相比的最大优势就在于维护方便，你需要的仅仅是让失败的结果作为有效的反馈给模型或者需求（#8），修改模型使其能反映系统的预期行为，然后重新生成测试用例。

【编辑推荐】

1. 嵌入式软件测试浅谈
2. “脚踩二枝”做软件测试复合型人才
3. 软件测试中排错的基本方法
4. 通过软件测试防止IT浪费 降低成本和风险