改進自動化測試套件的可維護性（三）

　　4.使用基于框架的架構

　　The framework provides an entirely different approach, although it is often used in conjunction with one or more data-driven testing strategies. Tom Arnold (one of the LAWST participants) discusses this approach in his book [8] and courses.

　　雖然框架通常與一個或一個以上的數據驅動測試策略一同使用，但它本身卻提供了一種完全不同的方法。Tom Arnold(LAWST成員之一)在它的書和課程中論述了這種方法。

　　The framework isolates the application under test from the test scripts by providing a set of functions in a shared function library. The test script writers treat these functions as if they were basic commands of the test tool’s programming language. They can thus program the scripts independently of the user interface of the software.

　　框架通過提供共享函數庫中的一套函數，把應用程序從測試腳本中分離。這樣，測試腳本編寫者在處理這里函數時，就可以把它們視為測試工具的編程語言的基本命令。因此，他們能單獨編寫軟件的用戶界面腳本。

　　For example, a framework writer might create the function, openfile(p). This function opens file p. It might operate by pulling down the file menu, selecting the Open command, copying the file name to the file name field, and selecting the OK button to close the dialog and do the operation. Or the function might be richer than this, adding extensive error handling. The function might check whether file p was actually opened or it might log the attempt to open the file, and log the result. The function might pull up the File Open dialog by using a command shortcut instead of navigating through the menu. If the program that you’re testing comes with an application programmer interface (API) or a macro language, perhaps the function can call a single command and send it the file name and path as parameters. The function’s definition might change from week to week. The scriptwriter doesn’t care, as long as openfile(x) opens file x.

　　例如，一個框架編寫者創建了函數openfile(p)。該函數用來打開文件p。它可以通過下拉文件菜單、選擇打開命令、復制文件名到文件名域、點擊OK按鈕關閉對話框來完成操作。此外，這個函數也可以變得更復雜一些，比如，添加可擴展的錯誤處理功能。它能檢查文件p是否已經被打開，或者記錄打開文件的嘗試以及對結果做日志。該函數還可以用一個命令快捷鍵，而不是菜單導航來彈出文件打開對話框。如果你的測試程序涉及到一個應用編程接口(API)或宏語言，那么該函數或許能調用一個單獨的命令，并把文件名和路徑作為參數傳遞給它。函數的定義經常在變化。但只要openfile(x)能打開文件x，腳本編寫者就不必在意。

　　Many functions in your library will be useful in several applications (or they will be if you design them to be portable). Don’t expect 100% portability. For example, one version of openfile() might work for every application that uses the standard File Open dialog but you may need additional versions for programs that customize the dialog.

　　很多函數庫中的函數在一些應用程序中依然有用(或者當它們被設計成可移植的時，也會很有用)。不要指望100%的可移植性。例如，openfile()的某個版本可以在每個應用程序中使用標準文件打開對話框，但你可能需要為那些有定制對話框的程序設計額外的版本。

　　Frameworks include several types of functions, from very simple wrappers around simple application or tool functions to very complex scripts that handle an integrated task. Here are some of the basic types:

　　框架包括若干類函數，從簡單應用程序或工具功能的打包到處理完整任務的復雜腳本。以下是一些基本的類型：

　　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