大家可以假设一个场景，用户登录，登录之后去借钱，去借钱本身有两个行为，去借钱的时候有没有设置好银行卡号，如果设置好了是一个流程，没设置好银行卡号是另外一个流程，登录的话可以通过用户名密码、通过手机短信、通过微信扫码的方式去登录。登录的3个行为和借钱的两个行为如果去组合一下的话，2×3是6个行为，如果去录制，这6块是非常重要的点。
模型驱动的话，本身是有模型和一些语义在里面，有一些数据算法可以直接去应用。比如说我们刚才说的，可以自动组合爆炸。上面举的这个例子一个是两个行为，一个是三个行为，我们画图的时候只需要画5个行为，2+3是加法，它会自动组合出来6个行为。这个就是一个质变，“无中生有”，因为模型的存在，计算机可以构建出一个新的测试用例，一个我们没有想到的测试用例。
比如说我们有个测试有10个模块，每个模块有2个行为，组合到一块的话 ，就会瞬间生成1000个组合出来的行为，设计出来非常复杂的，非常长的，数量也非常多的测试用例。这就是由于模型驱动的存在带来的好处，录制的话是1000个测试用例需要录1000次，通过模型驱动，即使要录制，也是只需要录制每一个小的模块的行为，各个小的模块的行为录制好以后，通过搭积木的方式就自动组件出来了。
这是我认为模型驱动做测试非常重要的一个价值所在。我们有一个案例是45分钟通过搭积木的方式，将100个流程图串起来，串成一个4500行的测试代码。一个测试用例有4500行，整个运行时间有45分钟，通过IE去运行。搭积木的方式适合于各种平台，尤其是适合于复杂的软件。如果你的软件复杂度特别低，或者不是用来赚钱的，只是用来展示静态的一些东西的话，测试用例非常少，就不需要搭模型这种额外的工作量。但是如果软件非常复杂，重复度非常高，就非常有必要通过搭模型的方式去沉淀、去做一些回归。