先来说说为什么会重构。原先的框架系统，思路是将自动化代码，通过调用控件的适配接口，最终完成对界面的操作。而这些代码，也被编译到DLL中。这里面就有一些问题：
１.每一次修改，都必须重新编译。
２.由于DLL被程序Load，不可直接覆盖，所以必须重新启动被测试系统。
３.基本上不可以部分执行脚本。
４.自动化代码和自动化框架代码同时暴露给用户。
再一次说明一下原先的设计。原先的设计中，自动化代码将作为DLL的一部分被编译进去，而这个DLL会作为程序系统的一部分被装载。本来我想用图形来表示，突然感觉其实可以多多用表达式来表示，我想做一个尝试，这样可以免去图片的麻烦。
被测试系统（自动化框架（自动化代码））
其中括号表示包含关系。最终只有一个系统在运行。为了解决这些问题，我们思考从脚本入手，进行自动化测试框架的重构。
首先重构的对象是，将自动化代码的编写改变为XML的配置。自动化框架通过读取配置，并解析每一段脚本，自动执行。我们先不谈其中的实现技术细节，而是先来谈谈这样的好处。
１.脚本是解释性的，因此框架DLL不需要重新编译。
２.脚本由于成为配置，那么其管理也就变得更加容易和简单。
３.可以让测试人员，完全只是关心业务上的脚本。
４.从配置中，可以方便地记录每一步的执行内容。原先的编译方式，失去了很多信息。
５.配置可以动态组织，这样有可能实现部分脚本的执行。
重构，就是发现问题到解决问题的过程。相对于设计的不同，在于重构是在现有设计的基础上发现问题。
下面说说实现过程中的细节。在这个过程中，最关键的是脚本的解析。由于之前，针对所有控件，都已经有了封装的接口，因此在这个基础上，我们考虑到采用SOAP的实现思想，通过对接口方法的Invoke，来实现最终的脚本执行。
要实现这个Invoke的过程，就必须深入了解一下Delphi是如何实现SOAP的。这当然是另外一个话题了。有兴趣的可以看一下Invoker.pas中的代码。要实现Invoke的过程，可以有两个选择：
１.完全参考SOAP的调用约束
２.自己定义结构，自己解析转换参数，实现Invoke
我实际是选择了后者，虽然说对于我理解Invoke原理有了很大帮助，但后来还是证实我的选择不是最好的。先不管这个了。
文章来源于领测软件测试网 https://www.ltesting.net/