最近对测试框架进行了重构，也对其中原有的一些设计进行了反思。其中不免有一些自我感觉得意之处，因此写出来和大家分享。这是一个重构的过程，所以将以重构的思路来讲述。
重构对于一个系统来说，往往是必要的。他的必要性往往不在于重构的好处，而在于系统的成长的趋势。一个好的系统在初步阶段，在很多方面都会存在成长的空间，就如人在小时候长身体一样，如果补充的营养跟不上，一生都可能会受到影响。
对于我们这个系统来讲，目前也正是初步使用验证阶段，所以重构的可能性非常大。当然了，如果从成本角度来看，在系统重构的时候，必须对系统的使用做严格的管理。幸好我们在早期对这方面比较谨慎，使用范围没有盲目扩展。因此重构所带来的影响会被缩小到最小范围。
那么先来说说这次重构的目的。在原先的框架系统中，设计思路是在Delphi中编写自动化测试，代码通过调用控件的适配接口，最终完成对界面的操作。而这些代码，也被编译到DLL中。这里面就有一些问题：
-
每一次修改，都必须重新编译。
-
由于DLL被程序Load，不可直接覆盖（替换），所以必须重新启动目标测试系统。
-
基本上不可以部分执行脚本。
-
自动化代码和自动化框架代码同时暴露给用户
再一次说明一下原先的设计。原先的设计中，自动化代码将作为DLL的一部分被编译进去，而这个DLL会作为程序系统的一部分被装载。本来我想用图形来表示，突然感觉其实可以多多用表达式来表示，我想做一个尝试，这样可以免去图片的麻烦。下面是系统的表示：
被测试系统（自动化框架（自动化代码））
其中括号表示包含关系。可以看到，最终只有一个系统在运行。
在这里关注一下列出的问题重点，这在重构过程中非常重要。因为重构并不是盲目的。需要做到目标准确不偏移。简单点说就是将好刀用在刀刃上。并且要保障重构的结果能呼应最初的目的。并且这次重构属于系统级别的重构，重点不是一些类的调整，而是整天解决方案的革新。
为了解决这些问题，我们思考从脚本入手，进行自动化测试框架的重构。但在做之前，必须考虑好重构系统的稳定性如何保障。系统级别的重构和单元级别的重构的保障机制应该是不一样的。这不得不提到单元测试，但仅仅是单元测试是无法保障的。
第一、系统中大部分类可能都有所改变。针对原先的单元测试必须重新编写。
第二、系统级别的测试不能被单元测试替代。因此非常有必要持续进行。
这里，我并没有做方法上深入探究，但是测试这件事必须做。电脑暂时做不了的事，人来做。我们在单元测试的基础上，持续迭代地对重构后的系统进行系统测试，这样能尽量快速地发现重构中失误所在。
后来发现，在重构过程中，对新的方法编写测试用例更加有效。因为重构往往是在时间紧急的情况下进行的，所犯错误可能比初期编码阶段更容易。这个阶段，旧的单元测试代码和新的单元测试代码能够很好提升系统的稳定性。
现在讲一下重构的过程。重构的目标是，将自动化代码的编写改变为XML的配置。自动化框架通过读取配置，并解析每一段脚本，自动执行。我们先不谈其中的实现技术细节，而是先来谈谈这样的好处。
- 脚本是解释性的，因此框架DLL不需要重新编译。
- 脚本由于成为配置，那么其管理也就变得更加容易和简单。
- 可以让测试人员，完全只是关心业务上的脚本。
- 从配置中，可以方便地记录每一步的执行内容。原先的编译方式，失去了很多信息。
- 配置可以动态组织，这样有可能实现部分脚本的执行。
重构，就是发现问题到解决问题的过程。相对于设计的不同，在于重构是在现有设计的基础上发现问题。
下面说说实现过程中的细节。在这个过程中，最关键的是脚本的解析。由于之前，针对所有控件，都已经有了封装的接口，因此在这个基础上，我们考虑到采用SOAP的实现思想，通过对接口方法的Invoke，来实现最终的脚本执行。
要实现这个Invoke的过程，就必须深入了解一下Delphi是如何实现SOAP的。这当然是另外一个话题了。有兴趣的可以看一下Invoker.pas中的代码。要实现Invoke的过程，可以有两个选择：
- 完全参考SOAP的调用约束
- 自己定义结构，自己解析转换参数，实现Invoke
我实际是选择了后者，虽然说对于我理解Invoke原理有了很大帮助，但后来还是证实我的选择不是最好的。先不管这个了。
完成了Invoke的过程，下面就是脚本的设计了。我为脚本的设计，增加了几方面的内容：
- 定义TestWindow的概念，表示每一个被测试和编码的窗体。
- 定义TestStep的概念，表示对用户界面发出的每一次命令。
- 定义TestPackage概念，表示多个TestStep的组合。
- 定义TestWindow和TestStep之间的关系。TestWindow包含多个TestStep。每一个TestStep包含多个TestWindow，表示这个命令可能触发的新的测试窗体。
定义这些概念是非常有意义的。可以帮助我们清晰地理解系统，也非常便于以后的技术交流。这也说明了自动化测试框架本身设计的完善和进步。
在定义完成这些概念后，就是完成一个脚本的配置工具。并在这个编辑器上实现脚本的调试和日志功能。调试方面，我们选择了HTTP的调用方式。其实可以选择很多其他方式。一来HTTP的方式，实现起来很简单。二来支持HTTP后，调用自动化测试，只需要通过HTTP就可以了。FinalBuilder和一些Shell都支持这种方式。这对于以后的自动化调用是非常有意义的。
现在系统的架构变了。不再是原先的一个系统了，因为这里引入了一个辅助系统，可以称之为自动化的IDE。再使用上面的方式，我们描述以下系统：
被测试系统（自动化框架）＝ IDE（自动化脚本）
等号表示系统交互是双方向的。IDE向系统发送脚本，系统向IDE发送LOG。
好了，这次重构基本都完成了。整个过程的中心在于脚本的结构迁移。而重构的前因和结果也都进行了对比。虽然说很多方面的细节也许并没有考虑清楚。但是这次框架设计的重构，还是非常有价值的！而且整个重构的过程，更是框架本身的完善过程。
希望自动化测试框架越来越好！
发表于 @ 2007年08月20日 00:12:00|评论(loading...)|编辑