框架包括若干類函數，從簡單應用程序或工具功能的打包到處理完整任務的復雜腳本。以下是一些基本的類型：
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.
文章來源于領測軟件測試網 http://www.kjueaiud.com/
