3、描述性编程
如果对自己的对象识别容器有足够的信心，那么支持“描述性编程”是必然的，这也引发了“描述性编程”的应用热潮。描述性编程一般都是经过长时间的测试和使用最终被确定下来的，为什么Win32中这种技术未被广大用户所知(例如HP Winrunner中即存在描述性编程技术)，是因为Win32对象的非标准性(几乎各大厂商都有着自己的专属开发工具，产生了大量的控件集合)和不确定性造成的，对象根本无法被捕获(在对象识别机制无法被扩展的情况下)，大肆推广描述性编程是不明智的商业之举。进入WEB时代后，因为W3C的强力介入 Html内容格式至少有了个统一的标准，所以描述性编程终于在自动化测试中成长起来了。描述性编程的概念就是要使用者直接脱离传统的识别对象-存储对象- 再操作对象的模式，升级为你无需进行这些繁琐的操作，直接使用轻量级的附带Spy工具查到被测试对象的几个基本属性，即可快速的书写测试脚本，以节省宝贵的开发时间。一般描述性编程脚本结构为：
对象(”属性:=‘值’”,”属性:=‘值’”,”属性:=‘值’”,… …).动作 “值” //QuickTestPro中使用的描述性编程格式
对象(”属性值1|属性值2|属性值3|… …“).动作(“值“) //SilkTest中使用的描述性编程格式
在TestMice中，这种描述性编程脚本结构微调为：
对象(属性=“值“,属性=“值”,属性=“值”,… …).动作(“值“);
不管采用何种描述性编程格式，本质上是没有任何区别的，可以这样说，描述性编程是自动化测试工具一个必然发展的结果，所有的工具厂商都希望使用者更加关注测试数据和测试业务逻辑，脚本本身的表现形式则是越简单、越直白就越好。
4、测试数据驱动
数据驱动在自动化测试中至少包含了两种概念，一为对象关键字驱动，二为业务关键字驱动，采用什么样的驱动模式完全取决于使用者本身。那么对象关键字驱动是如何实现的，我们可以用下面的一张图来做个简单的解释，这是对Windows附带计算器进行对象关键字驱动：
对象关键字驱动本质上就是对可操作对象做一个显式属性标注，然后使用任意数据存储方式(文件，数据库，Excel等)将这些属性、动作存储下来，最后递交给脚本和对象识别容器统一实现。好处是简单明了，坏处是对象变更了数据就作废了，维护成本偏高，这也是众多商业自动化测试工具的通病。那么业务关键字驱动表现得目的性稍微强了一些，基本上表格中的关键字都跟业务描述测试数据挂钩，例如这样的一个业务界面，那么它的业务关键字驱动表现为：
对于业务关键字驱动来说，业务本身的数据和对应验证是最为重要的，只有通过更多的测试数据来达到一个满意的、足够安全的测试覆盖。而这些重复的、千篇一律的数据输入却是手工测试人员最不愿意面对的，那么就交给工具来实现吧。至于这些数据以何种方式存放，任何测试工具都会提供稳定的数据接口，TestMice同样也全部提供。
5、场景恢复
自动化测试执行过程中遇到中断事件是非常普遍和令人沮丧的，我们经常告诫测试人员在脚本的执行机器上不要安装过多的额外软件，就是因为某些软件可能产生一些莫名其妙的对话框或者发送一些古怪的消息来阻断正常自动化测试进程。那么作为一款强大的自动化测试工具，保存这种错误场景和继续恢复测试正常执行是非常必要的，这些统称为场景恢复。在场景中，我们需要分析哪些现象会阻断脚本的正常运行？或许是一个软件升级的对话框，或许是来自于网络的一个弹出式窗体，或许是防火墙拦截到的一段信息提示等等，这些一切皆有可能。那么如何处理这些令人讨厌的事情呢？TestMice项目中提供3种场景恢复，即：
* Windows弹出式对话框场景恢复
* 被测试软件错误场景恢复
* 对象属性变化场景恢复
第一种场景还是需要被动的预先获知弹出式对话的句柄，或者通过预设对话框Title属性，一旦该机制被触发，测试软件会自动寻找符合Title属性的窗体，然后启动由用户选择的4类后续对应处理：
* 模拟鼠标和键盘消息，进行关闭窗体或者其他可定义操作
* 关闭阻碍自动化测试过程的软件进程，可由用户设定此项较危险
* 调用预约脚本，例如发送紧急短信或者邮件通知等
* 重启Windows系统，这里建议自动化测试做在虚拟机里，可用虚拟机SDK作辅助插件开发，保存当前软件执行Cookie
第二种场景在测试过程中是最为常见的，例如已识别菜单项没找到(Winrunner中常见)，List下拉项目中数据和脚本预设数据不匹配，出现多个重复的对象(例如打开两个以上相同的IE窗口)，或者被测试对象状态为Visable等等，所以针对此场景，最好设置一个All Error处理，即不管出现了什么被测试软件错误，一概调用4类后续对应处理。更好的办法是，错误可以由使用者自定义，那么这就需要测试工具在实现机制上有更多的考虑了。
第三种场景，对象的属性变化处理最为复杂，不过这种处理机制也是对象识别容器的重要功能，可以由软件内部提供对象重新模糊匹配方式，略过该测试案例执行，直接跳转到其他待测试案例执行等。同样该场景的触发也可以调用4类后续对应处理。既然测试执行过程中产生阻碍事件是无法预料的，那么有备无患的后续处理机制就显得格外重要了。
这三种场景恢复TestMice全部支持，并且我们将场景后续处理机制做在了插件里，这样的话就把对其他场景的定义交给了实际使用者，因为我们永远相信，预设的都是不够的，是最容易招惹抱怨的。
6、插件和编译运行
目前很多测试工具有限的放开了二次开发接口，可以让使用者进行受一定限制的功能开发，但是至今还是没有一款商业测试工具放开到可以操作其对象识别容器的地步。我认为一款再优秀的软件，没有提供额外的、灵活的、可扩展的SDK包在商业上都是不够“Open”的，甚至有扼杀行业技术进步、垄断市场之嫌。 TestMice完全提供对象识别容器内核所有的接口SDK开发包，以供任何个人或者企业制作具有自己特色的自动化测试应用。另外，我在大量的自动化测试项目实施中发现了一些很有趣的事情，即目前市面上的测试工具脚本大多是以明码方式运行的，企业比较抵触这种方式，认为这种明码执行方式有泄漏企业秘密的重大风险。那么在TestMice项目中有个有趣的插件专门负责把脚本编译成二进制模式，顺便对脚本进行解释运行。插件是所有工具扩展的灵魂，既然开发商不能提供足够的想象力，那么就把这项任务交给广大插件开发者来完成吧。
7、总结
国内至今尚未有正式机构对自动化测试工具进行整体式的深入研究和商业研发，自2007年国内某人开始制作成体系的研究性自动化测试工具，直至今日发展颇为艰难。在经历了一个又一个的技术攻关后，终于让我们开始成熟起来。项目组同样希望TestMice可以成为国内每个测试人员，不，甚至是开发人员手中的测试利器，国产的商业自动化测试工具应用年代终于离我们越来越近了！
