b. Define commands or features of the tool’s programming language.
b. 定義工具的程序語言的命令或特性
The automation tool comes with a scripting language. You might find it surprisingly handy to add a layer of indirection by putting a wrapper around each command. A wrapper is a routine that is created around another function. It is very simple, probably doing nothing more than calling the wrapped function. You can modify a wrapper to add or replace functionality, to avoid a bug in the test tool, or to take advantage of an update to the scripting language.
自動化工具都有一個腳本語言。你會發現，通過包裹每個命令來增加一個間接層的做法非常便捷。所謂包裹，就是一個被創建在另一個函數周圍的例程。這非常的簡單，很可能僅僅只需調用打包函數即可。而且，你可以通過修改包裹來增加或替換函數，以避免測試工具中產生bug，或利用更新的腳本語言。
Tom Arnold [9] gives the example of wMenuSelect, a Visual Test function that selects a menu. He writes a wrapper function, SelMenu() that simply calls wMenuSelect. This provides flexibility. For example, you can modify SelMenu() by adding a logging function or an error handler or a call to a memory monitor or whatever you want. When you do this, every script gains this new capability without the need for additional coding. This can be very useful for stress testing, test execution analysis, bug analysis and reporting and debugging purposes.
Tom Arnold給出了wMenuSelect的例子，它是一個選擇菜單的可視化測試函數。他編寫了一個打包函數：可簡單調用wMenuSelect的SelMenu()。這種做法具有靈活性。舉個例子，你可以修改SelMenu()，比如，添加日志功能、添加錯誤處理機制、添加調用內存監視器命令，或其他任何你想添加的東西。當這樣做時，每個腳本都能得到這個新的功能，而并不需要額外編寫代碼。這種做法在強力測試、測試執行分析、bug分析報告與調試目標方面都非常有用。
LAWST participants who had used this approach said that it had repeatedly paid for itself.
用過這種方法的LAWST成員說，該方法已經反復收到成效。
c. Define small, conceptually unified tasks that are done frequently.
c. 定義經常使用的概念統一的小任務
The openfile() function is an example of this type of function. The scriptwriter will write hundreds of scripts that require the opening of a file, but will only consciously care about how the file is being opened in a few of those scripts. For the rest, she just wants the file opened in a fast, reliable way so that she can get on with the real goal of her test. Adding a library function to do this will save the scriptwriter time, and improve the maintainability of the scripts.
openfile()函數是這種類型函數的一個典型例子。腳本編寫者會編寫上百個需要打開文件的腳本，但他只會有意識地關注少數腳本中的文件是怎樣被打開的。至于其它的，他只是想要文件被迅速可靠地打開，這樣，他就能繼續測試他真正要測試的東西。添加一個庫函數來做這些事情將會節省腳本編寫者的時間，并且能改進腳本的可維護性。
This is straightforward code re-use, which is just as desirable in test automation as in any other software development.
這屬于直接的代碼重用。與其它任何軟件開發一樣，在測試自動化中也有同樣的需求。
d. Define larger, complex chunks of test cases that are used in several test cases.
d. 定義用在若干測試用例中的更大更復雜的測試用例塊
It may be desirable to encapsulate larger sequences of commands. However, there are risks in this, especially if you overdo it. A very complex sequence probably won’t be re-used in many test scripts, so it might not be worth the labor required to generalize it, document it, and insert the error-checking code into it that you would expect of a competently written library function. Also, the more complex the sequence, the more likely it is to need maintenance when the UI changes. A group of rarely-used complex commands might dominate your library’s maintenance costs.
存在著封裝更大規模的命令序列的需求。然而，這樣做也存在著風險，尤其是當你過多使用時。因為一個很復雜的命令序列很可能在很多測試腳本中無法重用，所以，就不值得花力氣去生成它，為它寫文檔，并為它加入錯誤檢查代碼以期成為編寫完善的庫函數。此外，序列越復雜，當用戶界面改變時就越需要維護。那樣一來，你的庫維護成本就被一組幾乎不用的復雜命令決定了。
e. Define utility functions.
e. 定義實用程序函數
For example, you might create a function that logs test results to disk in a standardized way. You might create a coding standard that says that every test case ends with a call to this function.
例如，你可以創建一個以標準方法把測試結果保存到硬盤的日志函數。你也可以創建一個編碼標準，即每個測試用例都以對該函數的調用作為結束。
Each of the tools provides its own set of pre-built utility functions. You might or might not need many additional functions.
每個工具都提供了它自己的一套預構建實用程序函數。這樣，你可能需要也可能不需要更多額外的函數了。
Some framework risks
使用框架的風險
You can’t build all of these commands into your library at the same time. You don’t have a big enough staff. Several automation projects have failed miserably because the testing staff tried to create the ultimate, gotta-have-everything programming library. Management support (and some people’s jobs) ran out before the framework was completed and useful. You have to prioritize. You have to build your library over time.
你不能同時把所有這些命令都構建到你的函數庫中。因為你沒有足夠多的人力。一些自動化項目之所以失敗，正是因為測試人員試圖創建一種終極的、無所不包的編程庫。而在框架完成且可用之前，管理支持(一些人員的工作)就已經不存在了。因此，你必須權衡先后，隨著時間逐漸地構建你的函數庫。
Don’t assume that everyone will use the function library just because it’s there. Some people code in different styles from each other. If you don’t have programming standards that cover variable naming, order of parameters in function interfaces, use of global variables, etc., then what seems reasonable to one person will seem unacceptable to another. Also, some people hate to use code they didn’t write. Others come onto a project late and don’t know what’s in the library. Working in a big rush, they start programming without spending any time with the library. You have to manage the use of the library.
不要認為每個人使用函數庫僅僅是因為它已經存在。有的人的編碼風格與其他人就不同。如果你沒有一個編程標準來控制變量命名、函數接口的參數順序、全局變量的使用等等，那么在一個人看來合理的東西在另一個看來將變的不可接受。此外，有的人不喜歡使用不是他們編寫的代碼。而另一些人由于參與項目較晚而不知道庫中的內容，于是就倉促的在沒有了解庫的情況下開始編程。因此，你必須管理好庫的使用。
Finally, be careful about setting expectations, especially if your programmers write their own custom controls. In Release 1.0 (or in the first release that you start automating tests), you will probably spend most of your available time creating a framework that encapsulates all the crazy workarounds that you have to write just to press buttons, select list items, select tabs, and so on. The payoff from this work will show up in scripts that you finally have time to write in Release 2.0. Framework creation is expensive. Set realistic expectations or update your resume.
最后，要慎重設置期望值，尤其在當你的程序員編寫了他們自己定制的控件時。在發行版1.0(或你開始自動化測試的第一個發行版)中，你很可能會花費很多時間來創建一個封裝了所有工作區的框架，以至你不得不編寫點擊按鈕、選擇表項、選擇tab鍵的代碼。這些工作的回報將在你最后花時間編寫的發行版2.0中體現出來。創建框架的開銷很大，因此，要設置符合實際的期望值或修正你的摘要。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
