软件测试中自动化测试框架: 设计的重构

软件测试中自动化测试框架: 设计的重构

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序list 中去，然后确认该值出现在list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。
　　单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
　　工厂在组装一台电视机之前，会对每个元件都进行测试，这，就是单元测试。 　
　其实我们每天都在做单元测试。你写了一个函数，除了极简单的外，总是要执行一下，看看功能是否正常，有时还要想办法输出些数据，如弹出信息窗口什么的，这，也是单元测试，把这种单元测试称为临时单元测试。只进行了临时单元测试的软件，针对代码的测试很不完整，代码覆盖率要超过70%都很困难，未覆盖的代码可能遗留大量的细小的错误，这些错误还会互相影响，当BUG暴露出来的时候难于调试，大幅度提高后期测试和维护成本，也降低了开发商的竞争力。可以说，进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。
　　对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。
　　要进行充分的单元测试，应专门编写测试代码，并与产品代码隔离。老纳认为，比较简单的办法是为产品工程建立对应的测试工程，为每个类建立对应的测试类，为每个函数（很简单的除外）建立测试函数。首先就几个概念谈谈老纳的看法。 　
　一般认为，在结构化程序时代，单元测试所说的单元是指函数，在当今的面向对象时代，单元测试所说的单元是指类。以老纳的实践来看，以类作为测试单位，复杂度高，可操作性较差，因此仍然主张以函数作为单元测试的测试单位，但可以用一个测试类来组织某个类的所有测试函数。单元测试不应过分强调面向对象，因为局部代码依然是结构化的。单元测试的工作量较大，简单实用高效才是硬道理。
　　有一种看法是，只测试类的接口(公有函数)，不测试其他函数，从面向对象角度来看，确实有其道理，但是，测试的目的是找错并最终排错，因此，只要是包含错误的可能性较大的函数都要测试，跟函数是否私有没有关系。对于C++来说，可以用一种简单的方法区隔需测试的函数：简单的函数如数据读写函数的实现在头文件中编写(inline函数)，所有在源文件编写实现的函数都要进行测试(构造函数和析构函数除外)。

最近对测试框架进行了重构，也对其中原有的一些设计进行了反思。其中不免有一些自我感觉得意之处，因此写出来和大家分享。这是一个重构的过程，所以将以重构的思路来讲述。

先来说说为什么会重构。原先的框架系统，思路是将自动化代码，通过调用控件的适配接口，最终完成对界面的操作。而这些代码，也被编译到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。

好了，这次重构基本都完成了。整个过程的中心在于脚本的结构迁移。而重构的前因和结果也都进行了对比。虽然说很多方面的细节也许并没有考虑清除。但是这次框架设计的重构，其实更是框架本身的完善过程。

希望自动化测试框架越来越好！

原文转自：http://www.ltesting.net