在前面的网站自动化系统里面，大概聊了下如何结合Selenium生成的代码和VSTT创建一个简单的自动化系统。虽然在文章网站测试自动化系统—基于Selenium和VSTT、数据驱动测试、在测试代码中硬编码测试数据里，我讲了一些封装代码以及测试数据的技巧，规避后续开发过程中，程序员修改代码时，对测试程序带来的影响。但是每次程序员做出大的改动的时候，测试人员还是要修改大量的测试代码，更糟糕的是，每次大的改动，又涉及到测试覆盖是否足够的问题。为了规避类似的风险，以及帮助测试人员创建尽量多的测试用例，有些人提出了模型驱动测试的概念。
模型驱动测试的想法和飞机的风洞测试差不多，即根据功能需求说明书，对要测试的程序先建立一个模型，然后有另外一个程序分析这个模型，产生测试用例。就好比为了验证新飞机的气动布局，不可能建一个全比例的飞机，去测试它的布局是否合理;而是建立一个小的飞机模型，模型的气动布局和整机的布局是一致的。飞机模型建好以后，才放到风洞里面测试一下。
市面上已经有几个做模型驱动测试的工具了，这里我用的是NModel，本来想拿SpecExplorer尝一下鲜的，但最后发现这个想法太贵了—需要安装了Visual Studio 2010才能使用“免费”的SpecExplorer。你可以在这个网页里下载 NModel：
http://nmodel.codeplex.com/
在NModel中，测试人员使用C#创建程序的模型，模型创建的原理是：
1.程序是用来处理数据的，数据也可以称作状态(State);
2.用户通过程序提供的操作界面来处理数据，操作界面也可以称作动作(Action);
3.数据的更动 又反过来影响一些动作是否可以执行。
比如说，使用Word的时候，刚启动程序时是没有任何数据的，这个时候有些动作，例如“保存”是禁用的。当用户通过“新建”这个动作创建了一个新文件(数据)，这个新文件反过来激活“保存”动作。
因此当测试人员建模时，他要做的工作就是将程序的动作和状态抽象出来，并且描述动作和状态相互影响的过程。
来看一个例子，假如现在要测试一个用户登录程序，登录界面就是一个输入用户名和密码的文本框，而程序支持的用户有两种：管理员和授权用户。
先来做第一步，将动作和状态抽象出来，程序的状态应该包括：
1.程序状态：运行状态和未运行状态。
2.用户类型：管理员和授权用户。
3.密码：正确的密码和错误的密码。
4.登录状态：成功登录和登录失败。
动作应该包括：
1.登录：即用户在界面上输入用户名和密码。
2.注销。
第二步，编写C#?程序建模。
状态已经抽象出来了，在NModel里面，抽象出来的状态一般是用枚举值表示的。
文章来源于领测软件测试网 https://www.ltesting.net/
