框架包括若干类函数，从简单应用程序或工具功能的打包到处理完整任务的复杂脚本。以下是一些基本的类型：
a. Define every feature of the application.
a. 定义应用程序的每种特性
You can write functions to select a menu choice, pull up a dialog, set a value for a variable, or issue a command. If the UI changes how one of these works, you change how the function works. Any script that was written using this function changes automatically when you recompile or relink.
你可以通过编写函数来选择菜单选项，弹出对话框，设定变量值或发布命令。如果用户界面改变了其中的一种工作方式，那么你也就改变了函数的工作方式。而当你重新编译或重新链接时，任何一个用该函数编写的脚本都能自动修改。
Frameworks are essential when dealing with custom controls, such as owner-draw controls. An owner-draw control uses programmer-supplied graphics commands to draw a dialog. The test-automation tool will know that there is a window here, but it won’t know what’s inside. How do you use the tool to press a button in a dialog when it doesn’t know that the button is there? How do you use the tool to select an item from a listbox, when it doesn’t know the listbox is there? Maybe you can use some trick to select the third item in a list, but how do you select an item that might appear in any position in a variable-length list? Next problem: how do you deal consistently with these invisible buttons and listboxes and other UI elements when you change video resolution?
在处理定制控件时，框架是最重要的，比如自绘制控件。一个自绘制控件利用程序员提供的图表命令来绘制一个对话框。自动化测试工具只能辨认窗口的存在，却不能辨认里面的东西。因此，当工具并不知道按钮是否在对话框中时，如何让它点击这个按钮呢?而当工具并不知道列表框是否在那里时，又如何让它选择其中的表项呢?或许，你可以用某种小技巧来选择列表中的第三项吧，但是你如何选择一个出现在可变长度的列表中任何位置的表项呢?还有一个问题：当改变视频协议后，你如何像往常那样处理这些不可见的按钮和列表框，以及其他的用户界面元素呢?
At the LAWST meeting, we talked of kludges upon kludges to deal with issues like these. Some participants estimated that they spent half of their automation development time working around the problems created by custom controls.
在LAWST会议上，我们谈到用基于组装件的组装件来处理这类问题。有一些与会者估计，他们把自动化开发的一半时间都用来处理由定制控件所带来的问题了。
These kludges are a complex, high-maintenance, aggravating set of distractions for the script writer. I call them distractions because they are problems with the tool, not with the underlying program that you are testing. They focus the tester on the weaknesses of the tool, rather than on finding and reporting the weaknesses of the underlying program.
这些组装件对于脚本编写者来说，是一系列复杂的、难以维护且越来越严重的干扰。之所以称它们是干扰，是因为它们不是由正在测试的程序本身引起的，而是由工具引起的。因此，它们使测试人员把精力放在工具的缺点上，而不是放在找出并报告程序本身的缺点上。
If you must contend with owner-draw controls, encapsulating every feature of the application is probably your most urgent large task in building a framework. This hides each kludge inside a function. To use a feature, the programmer calls the feature, without thinking about the kludge. If the UI changes, the kludge can be redone without affecting a single script.
文章来源于领测软件测试网 https://www.ltesting.net/
