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中体现出来。创建框架的开销很大，因此，要设置符合实际的期望值或修正你的摘要。
文章来源于领测软件测试网 https://www.ltesting.net/
