下面这张图我们可以看到有3个步骤，最左边是各种类型的被测软件，中间有一个业务流程图，这个我们就称之为模型，它类似于脑图。有了业务流程图之后，自动化和智能化就体现在代码自动生成和报告自动生成。
模型驱动的理念是模型即代码，这个代码本身是可以被隐藏掉的，高级用户可以针对模型去进行修改，模型驱动99%的情况下大家并不需要看到代码。
接下来我们一起看一些案例，比如说我们想测试滴滴。左边是一个业务流程图，是一个树型的业务流程图，抽取出一条线放到右上角放大，可以看到这是海外租车的一个流程：自驾租车页面→海外租车页面→去选车页面→选择一辆车页面→基础保险套餐页面。
步骤完全是按照自然语言去描述，按照人工测试用例设计的方式把excel或步骤的方式搬到流程图上面。有了这个模型以后，整个的代码就不用去生成、自动去运行，像下面案例所示的，每一个步骤都有一个截图。
在谷歌也是每个测试用例对应一个视频，或者一组测试用例对应一个大视频，点击测试用例可以跳转到视频的各个步骤，方便浏览整个测试用例的状态或者debug。
针对滴滴这个例子，我们可以看到最后一个截图是点击保险信息，保险信息弹出框本身有一个关闭的按钮但是关闭不了，就造成了整个海外租车流程完成不下去。
从模型驱动的角度我们可以看到，一个业务流程图本身去描述一个复杂的软件，是基本上不可行的。复杂的软件有上万个测试用例，我在微软的时候待过几个组，像ERP组，至少也有上万个测试用例。一万个测试用例或者一万个行为描述到一张图上面，必然是很密集，很多时候也设计不好。因此我们提出了一个像“搭积木”一样的思路，由简化繁，把测试用例的设计，通过搭积木的方式，把不同的流程图组合起来，是组合爆炸的一个方式。