关于基于模型的测试的那些事
现在大家对探索性测试讨论得很热门，在自动化测试大行其道的今天，探索性测试似乎是唯一一块测试人员更能体现自己专业性的领域。甚至我还看到有人在讨论如何通过探索性测试来达到较高的代码覆盖率。
个人以为，如果你真的对覆盖到代码的每个分支更感兴趣，或者说希望测到哪怕是一些比较细节的用户行为，通过探索性测试的方法来做也许并不是一个很推荐的做法。
我这里想介绍一种基于模型的测试，通过它，我们可以对软件的功能达到更强的覆盖，达到更有效的测试，同时还能发现一些隐藏更深的问题。
同时，它也被某些业内人士誉为继关键字驱动之后的下一代自动化测试技术。
该方面的专家 Harry Robinson，来自微软的测试架构师，有一个很有意思的说法：“MBT is not your parents' test automation”， 也说明了这个意思。
首先来看它的定义：
Model based testing, 基于模型的测试
基于模型的测试属于软件测试领域的一种测试方法。按照此方法，测试用例可以完全或部分的利用模型自动产生。以上所说的模型通常是指对被测系统（SUT, system under test）某些（通常是功能性的）方面的描述。
什么是模型：
模型是系统的抽象描述，同时模型比真实的系统简单。
状态机是一种常见的表示用户操作的模型，比如以下的操作就可以模型化。
所有的测试都是基于模型的，但是不是每个模型都被保留：
我们在做测试的时候，脑子里面都预先会有软件的行为应该是怎么样的概念，它会指导我们去做相关的测试。
如何来建立测试领域的模型：
通常来讲，建模是应用MBT的一个难点，原因可能在于，大部分的测试人员都是在已经实现的系统上工作，在他们的日常工作中，比较少的受到如何来构建一个产品的训练。
而建模所需要的技能更多是一个软件工程师所需要的那一些技能，比如
1. 抽象和归纳
有时候，为了认清事物的本质，我们必需抛弃掉事物的细节，透过事物的表象。我总结了一下，就是抽象抽象再抽象，归纳归纳再归纳
2. 分而治之
一个大的系统通常是复杂的，我们工作的领域的软件也类似。为了能从它们中有效地抽象出模型，建议可以采取分而治之的策略。
3. 从概念本质到实现细节
那我们有哪些建模的方法呢：
从我有所实践的经验看，应该可以归纳成数据模型的建模和状态机的建模
以下分别选取了两个例子，介绍如何对其进行数据模型或者状态机模型的建模，并最后生成可执行的自动化测试用例。
有关数据模型的建立：
Linux的发明者 Torvalds, Linus 曾经有过一句话：
Bad programmers worry about the code.
Good programmers worry about data structures and their relationships.
在Agile Testing领域比较知名的一位专家 Elisabeth Hendrickson 也从测试的角度对数据的重要性做过一些阐述，她列举了常见的测试设计技术：
Test Design Technique
等价类
边界值
Data Type Attacks
CRUD
Different configurations
Count (user count, resource count)
…
然后做出了归纳，
It’s all about the variables.
所以我们可以看到，如果能建立系统的数据模型，无论对于开发和测试都是很有帮助的。
以计算机行业常见的和磁盘相关的测试，来说明如何用数据模型对测试需求建模：
然后我们把它翻译成框架可以识别的格式，用了一些非常简单的python语法来描述。
然后可以通过框架生成自动化用例：
另外一种常见的模型是状态机模型，主要是针对用户的行为建模：
比如Bug管理系统的工作流模型
或者SIP 协议的呼叫模型：
SIP协议呼叫相关的测试：
首先我们还是把它描述成框架可以识别的格式：
我们看到，可能的测试路径是很多的，那怎么才可以以最小的测试代价达到我们的覆盖率的目标呢？
假设我们的覆盖率目标定义成以最小的成本覆盖所有状态之间的迁移，那我们面临的其实是一个数学问题，那就是在一个有向图上，如何找到最短的路径覆盖。
这其实是一个著名图论问题。邮递员从邮局出发送信，要求对辖区内每条街，都至少通过一次，再回邮局。在此条件下，怎样选择一条最短路线?此问题由中国数学家管梅谷于1960年首先研究并给出算法，故名。
通过邮递员算法，我们看到我们一共需要28个步骤才能覆盖所有图中的变化：
然后我们也可以把它变成可执行的Robot Case
