浅谈浅谈MBT基于模型的测试技术基于模型的测试技术
基于模型的测试是一个轻量级的，形式化的验证软件系统的方法。为什么这么说呢，因为首先，基于模型的测试对待测软件系
统（通常被称为System Under Test，简称SUT）进行形式化的建模，
很多朋友可能已经听说了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），修改模型使其能反映系统的预期行为，然后重新生成测试用例。
资源评论
