MBT，基于模型的测试设计方法，这种方法不是一个新东西了，但是还是想拿出来说说，给没用过的同学，开阔一下思路。
通常MBT的方法是需要搭配工具使用的，这样在模型画好的同时，可以自动生成对应的测试用例以及自动化脚本。这样，我们就可以聚焦于测试设计上面，然后生成用例与自动化脚本的这类繁琐的工作由工具完成，这样避免了人为的覆盖不全（只要模型对，工具就会覆盖到所有的分支）
但是每个行业的产品不同，自动化框架不同，自动化脚本语言不同，这就导致了，除非花精力去定制或者适配工具，否则上述的工作都无法达成。 我想这也是为什么MBT不是很火的缘故，但是即使是这样，我们也不能忽视了该方法的好处，即使少了便利的输出，但是方法的理念，还是在设计用例的过程中，给我们提供很大的启发的。 那么我就在抛开工具的前提下，来分享一下。
基于模型的测试，首先是模型，那么这个模型是什么呢？是开发的设计流程么？
当然不是，在这里，我们要明确，MBT的模型是经过分析后的需求工作模型。为什么这么说呢？如果你的模型是开发设计流程，那么实际上你参考这个设计出来的模型，只是再测试开发设计流程，如果流程错了，你的模型也就是个错的，那么就一错再错，无法回头。
而MBT的测试理念，是基于需求的功能流程，然后进行建模，基于这个模型，才称得上是测试需求。鉴于此，就要求对于需求要有深刻的认知，所以熟悉业务是很必要的，若是业务不熟悉，那建模过程将会充满艰难险阻。
拿到需求后，不建议立即去建立模型，而是要有个初步的分析，这个需求，都有哪些功能，会有哪些分支，最后的终点在哪里。在经过这么一个初步分析后，再去建立模型。
举一个例子，测试一台抓娃娃机。 那么首先，我们要分析，抓娃娃机都涉及哪些功能。 我们先看一下主要的，投币，计时，转动摇杆爪子随即改变位置，按动按钮爪子像下捕获娃娃，爪子松开等等。这些都是一个抓娃娃机在抓娃娃的过程中会遇到的操作。
那么除了这些，还有哪些呢？再深层次的还包括识别硬币，计时器超时等等。
至此，基本的一个功能流程我们基本理清楚了，那么就可以开始我们愉快的建模过程了。
首先确定一下功能的起始，投币，投币以后系统需要判断是不是一元硬币，此时会存在一个功能判断，那么模型起始如下
可以从上图看出，当识别到不是一元硬币的时候，机器会吐出，此时针对整个功能来说，已经不会产生后续操作了，所以该部分流程已经finish。
机器正确识别到硬币后，那么机器就会进行下一步操作，启动定时器，然后解锁摇杆，使摇杆可以控制爪子，那么针对此部分的建模如下
好了，摇杆移动到娃娃上方后，此时有两种方式可以抓取娃娃，一个是按动按钮，另一个就是等待定时器超时，所以接下来的模型如下
至此，整个流程结束，所以最终的模型图如下
至此MBT的建模过程可以说完成了，由于没有工具，我们没有办法自动生成用例和脚本，但是对于一个需求的功能部分的用例，我们可以通过这种建模分析的方法，使我们的测试对象变得具象化，这样我们只需要根据模型的流程，提取到我们的用例即可。
MBT的方法在使用时，可以根据业务需求进行多样化的建模来梳理我们的测试对象，使抽象的需求具象化，为我们下一步输出用例，提供基础。
针对一套完整的用例，MBT只是沧海一粟，不同的测试类型，适用性不同。MBT只是一种方法，熟悉MBT只是给你的测试设计阶段，多提供了一个选择，灵活选用该方法，可以使你的测试设计，更加有理有据，覆盖全面。
