【IT168 技术文章】

　　借鉴微软强大而又卡死人不偿命的“WorkFlow”与驱动测试的一些原理，下午成功编写出自己的第一个“TestFlow”框架雏形，希望这是自动化测试的另一道曙光，下面简称TF（自己先这个名字吧，大家也容易记）。

　　简单介绍下关于TF的一些信息，关于如何去实现关于把自动化测试定位到早期功能测试点上，并能适应多种开发模式，或者这个框架能够帮助你。

　　首先说到这个框架中的驱动，了解了QTP的对象库原理后，我们需要先自己做一个容器，在测试的过程中把需要测试的对象都添加到容器里面去，并且把对象需要被检测到的属性，通过一个简单的录入工作，保存到一个临时的XML里面，支持导入功能。因此到这里我们成功做成了第一个关键字驱动的小模型，因为后面的对象查找就是靠它了，而我们在流的控制方面，主要采用了数字驱动，并且由这个做成了一个流的模板，省力。

　　其次，什么叫做“流”呢？在这里我定义的是一个对总体对象测试的把控方法。区别于微软的WorkFlow少了权限把控，简单的就是定义步骤的触发点与流程。延续WorkFlow的特点，容器支持了对象的排列，添加，删除，复制，插入空节点等等，并且添加判断节点在各个对象中间，而某个对象自己本身对应着一个或者多个操作。

　　再次,由驱动测试理念中抽出了一个让TestFlow存在的理由，那就是如何解决早期尽早投入自动化测试难度与效率问题。撇开Flow不讲，小编我在【自动化测试的错误定位】中，强调了自动化测试能够在早期开发中投入的观点，所以在TF中，我或者更偏向把这一点发挥出来而做了这个框架的原因。

　　下面先给大家看看TF容器的前台界面的一小部分：