4. 使用基于框架的架构

　　虽然框架通常与一个或一个以上的数据驱动测试策略一同使用，但它本身却提供了一种完全不同的方法。Tom Arnold（LAWST成员之一）在它的书和课程中论述了这种方法。

　　框架通过提供共享函数库中的一套函数，把应用程序从测试脚本中分离。这样，测试脚本编写者在处理这里函数时，就可以把它们视为测试工具的编程语言的基本命令。因此，他们能单独编写软件的用户界面脚本。

　　例如，一个框架编写者创建了函数openfile(p)。该函数用来打开文件p。它可以通过下拉文件菜单、选择打开命令、复制文件名到文件名域、点击OK按钮关闭对话框来完成操作。此外，这个函数也可以变得更复杂一些，比如，添加可扩展的错误处理功能。它能检查文件p是否已经被打开，或者记录打开文件的尝试以及对结果做日志。该函数还可以用一个命令快捷键，而不是菜单导航来弹出文件打开对话框。如果你的测试程序涉及到一个应用编程接口 (API)或宏语言，那么该函数或许能调用一个单独的命令，并把文件名和路径作为参数传递给它。函数的定义经常在变化。但只要openfile(x)能打开文件x，脚本编写者就不必在意。

　　很多函数库中的函数在一些应用程序中依然有用（或者当它们被设计成可移植的时，也会很有用）。不要指望100%的可移植性。例如，openfile()的某个版本可以在每个应用程序中使用标准文件打开对话框，但你可能需要为那些有定制对话框的程序设计额外的版本。

　　框架包括若干类函数，从简单应用程序或工具功能的打包到处理完整任务的复杂脚本。以下是一些基本的类型：

　　a. 定义应用程序的每种特性

　　你可以通过编写函数来选择菜单选项，弹出对话框，设定变量值或发布命令。如果用户界面改变了其中的一种工作方式，那么你也就改变了函数的工作方式。而当你重新编译或重新链接时，任何一个用该函数编写的脚本都能自动修改。

　　在处理定制控件时，框架是最重要的，比如自绘制控件。一个自绘制控件利用程序员提供的图表命令来绘制一个对话框。自动化测试工具只能辨认窗口的存在，却不能辨认里面的东西。因此，当工具并不知道按钮是否在对话框中时，如何让它点击这个按钮呢？而当工具并不知道列表框是否在那里时，又如何让它选择其中的表项呢？或许，你可以用某种小技巧来选择列表中的第三项吧，但是你如何选择一个出现在可变长度的列表中任何位置的表项呢？还有一个问题：当改变视频协议后，你如何像往常那样处理这些不可见的按钮和列表框，以及其他的用户界面元素呢？

　　在LAWST会议上，我们谈到用基于组装件的组装件来处理这类问题。有一些与会者估计，他们把自动化开发的一半时间都用来处理由定制控件所带来的问题了。

　　这些组装件对于脚本编写者来说，是一系列复杂的、难以维护且越来越严重的干扰。之所以称它们是干扰，是因为它们不是由正在测试的程序本身引起的，而是由工具引起的。因此，它们使测试人员把精力放在工具的缺点上，而不是放在找出并报告程序本身的缺点上。

　　如果你必须使用自绘制控件，那么封装应用程序的每种特性很可能是你构建框架的最紧迫且繁重的任务。这可以把每个组装件隐藏到一个函数中。如果要使用一个特性，程序员就调用该特性，而不必考虑组装件的存在。而如果用户界面发生改变，则可以在不影响单个脚本的情况下重建组装件。

　　b. 定义工具的程序语言的命令或特性

　　自动化工具都有一个脚本语言。你会发现，通过包裹每个命令来增加一个间接层的做法非常便捷。所谓包裹，就是一个被创建在另一个函数周围的例程。这非常的简单，很可能仅仅只需调用打包函数即可。而且，你可以通过修改包裹来增加或替换函数，以避免测试工具中产生bug，或利用更新的脚本语言。

　　Tom Arnold给出了wMenuSelect的例子，它是一个选择菜单的可视化测试函数。他编写了一个打包函数：可简单调用wMenuSelect的 SelMenu()。这种做法具有灵活性。举个例子，你可以修改SelMenu()，比如，添加日志功能、添加错误处理机制、添加调用内存监视器命令，或其他任何你想添加的东西。当这样做时，每个脚本都能得到这个新的功能，而并不需要额外编写代码。这种做法在强力测试、测试执行分析、bug分析报告与调试目标方面都非常有用。

　　用过这种方法的LAWST成员说，该方法已经反复收到成效。