目前，自动化测试框架已经基本成型。朋友们的一些建议，还在陆续消化中，在不久的将来或许都会加入到其中，谢谢大家的鼓励和支持。
最近，在一次技术交流会中，我的一位同事向我提起QTP(QuickTest Pro)，肯定了它的描述性编程和我们框架中的设计有类似之处，并指出QTP的可扩展性比较强，比如流程控制（IF、LOOP、SWITCH等）。特别是装载数据批量操作软件方面比较强。我深以为然。
因此，我开始和我的另一位同事小贾琢磨。我们有两种选择，一是在脚本编辑中扩展有关流程的节点（这点很像FinalBuilder），还有就是支持脚本语言。我们选择了后者，因为第一种虽然可以扩展，但最终毕竟还是不灵活。
在对编程语法方面，一开始考虑的是PascalScript，因为我们都是使用的Delphi。但是考虑到测试人员并不是熟悉Delphi的，况且，对于脚本化编程，我最先想到的是Ruby，而不是Delphi。因此我做了一个大胆的假设，如果在我们引擎中，加入对Ruby的支持，应该怎么做呢？
首先是引擎调用Ruby脚本。我查找了一下资料。发现Delphi下有现成的开源控件，而且Ruby其实已经公布了API了。因此这不是问题了。
那么下面就是最重要的问题了，Ruby脚本如何调用引擎去控制控件？我将所有针对引擎的操作，都归结于控件的操作，这简化了依赖性。但是关键的问题还是在于技术上如何实现调用。
必须承认，我对Ruby的了解很少，这方面小贾是专家。在和小贾讨论过程中，发现Delphi写Ruby的扩展没有明确的帮助，倒是有C的实现方式。我相信研究一下C的实现方式，应该可以找到Delphi的实现方式。
但在这个时候，我们忽然提到了Http。这让我想起了引擎中已经存在的一个Http的Server。因此我提出直接通过Http调用引擎。这样就跨越了语言的障碍。我们显然是抓住了RPC的精髓。这个方案一下子得到了小贾的支持。
并且我还想到另外一个理由：先实现了再说（Do it First）。这点小贾更是同意。
在这个基础上，小贾更是提出了利用Ruby定义DSL的方式，来进行编程。对于Ruby定义DSL我也是不怎么了解。在简单研究过范例之后，发现有一定的可行性，但是难度也确实不小。
下面是我和小贾讨论的一些内容，也能初步看出其中的难度。
有关DSL，还真麻烦。我考虑这样的情况：DSL可以转换成窗体实现。但是窗体实现并不完全对应DSL描述。事实上，对于客户的应用来说，一个确定按钮往往不是他的DSL描述的内容，包括所谓的Edit啊，Grid啊都不是的。这些只是实现某类DSL的方式。从反推的方式来设计DSL，确实有难度啊。控件的调用必须做到自动识别了。
比如一个简单的Input对话框，只有一个Value的Edit控件。那么对于DSL描述，我希望是这样的：在没弹出对话框之前，就应该是：设置 属性 新值。对于对话框的弹出是在DSL中不可预计的
可见，DSL的实现还是比较有挑战的。而且这里面也存在一个疑问，DSL适合测试吗？或者说我说的DSL原本是设计给需求人员或者程序员的，而不是特别给测试的。真正在自动化测试中的DSL，应该使用一种全新的方式去定义DSL。
不管怎么说，实现的方案已经基本成熟了。我们也可以展望一下如果实现了Ruby的脚本支持，会带来什么。
创新互联www.cdcxhl.cn，专业提供香港、美国云服务器，动态BGP最优骨干路由自动选择，持续稳定高效的网络助力业务部署。公司持有工信部办法的idc、isp许可证， 机房独有T级流量清洗系统配攻击溯源，准确进行流量调度，确保服务器高可用性。佳节活动现已开启，新人活动云服务器买多久送多久。