Framework-driven approach
框架驱动方法
For a while, the framework discussion turned into an extended discussion of the design of a procedural language, and of good implementation practices when using a procedural language. We grew tired of this, felt that other people had tackled this class of problem before, and we edited out most of this discussion from our agreements list. I’ve skipped most of the remaining points along these lines. Here are a few framework-specific suggestions:
在一段时间里，对框架的讨论变成了讨论设计过程语言以及良好实现过程语言的延伸。我们对此变得厌倦了，觉得已经有人在以前解决了这类问题，并且我们已经从我们的协议列表中删去了这个议题。我省略了沿着这条思路下去的多数要点。以下是一些针对框架的建议：
22. The degree to which you can develop a framework depends on the size / sophistication of your staff. (Consensus).
是否开发框架取决于你的员工的数量和熟练程度。(一致同意)
23. When you are creating a framework, be conscious of what level you are creating functions at. For example, you could think in terms of operating at one of three levels:
当创建一个框架时，要注意你在哪个级别上创建函数。例如，你可以考虑下面三种级别之一：
menu/command level, executing simple commands;菜单/命令级，执行简单命令
object level, performing actions on specific things;对象级，对具体事物实行操作
task level, taking care of specific, commonly-repeated tasks.任务级，负责具体的经常反复执行的任务
You might find it productive to work primarily at one level, adding test cases for other levels only when you clearly need them.
你会发现主要在一个级别上工作是高效的。所以，只有当你明确了需要在其它级别上添加测试用例后，才可以这么做。
There are plenty of other ways to define and split levels. Analyze the task in whatever way is appropriate. The issue here is that you want to avoid randomly shifting from creating very simple tests to remarkably long, complex ones. (Consensus)
还有很多定义和区分级别的其他方法。而无论用什么方法，分析任务总是合适的。这里要注意的是，需要避免随意地从创建十分简单的测试变成创建特别冗长复杂的测试。(一致同意)
24. Scripts loaded into the framework’s function library should generally contain error checking. (Consensus)
被载入框架的函数库的脚本一般应该包括错误检查功能。(一致同意)
This is good practice for any type of programming, but it is particularly important for test code because we expect the program that we’re testing to be broken, and we want to see the first symptoms of a failure in order to make reporting and troubleshooting easier.
这是任何类型编程都能得到的好经验，但是对于测试代码尤其显得重要。因为，我们希望我们测试的程序出现问题，并且，为了使报告和排除故障变得容易，我们希望看到失败的最初征兆。
25. When creating shared library commands, there are risks in dealing with people’s differing programming and documentation styles. People will not use someone else’s code if they are not comfortable with it.(Consensus)
当创建共享库命令时，就会出现处理不同编码和文档风格的问题。因为如果人们对某人的代码不满意，他们就不会使用它。(一致同意)
26. Beware of "saving time" when you create a scripts by circumventing your library. Similarly, beware of not creating a library. (Consensus)
在你打算通过包绕函数库创建脚本以“节省时间”的时候，要当心！同样，当心“不创建库”的提议。(一致同意)
The library is an organized repository for shared functions. If a function is too general, and requires the user to pass it a huge number of parameters, some programmers (testers who are doing automation) will prefer to use their own special-purpose shorter version. Some programmers in a hurry simply won’t bother checking what’s in the library. Some programmers won’t trust the code in the library because they think (perhaps correctly) that most of it is untested and buggy.
函数库是一个有组织的共享函数储藏区。如果有个函数太全面，需要用户向它传递大量的参数，那么一些程序员(正在做自动化的测试者)就可能会使用他们自己特定目的的较小版本。而有的程序员由于匆忙，不在意检查库中的代码。还有的程序员则不信任库中的代码，因为他们觉得(或许是正确的)库里的大部分东西没有被测试过，存在着bug。
27. It is desirable to include test parameters in data files such as .ini files, settings files, and configuration files rather than as constants embedded into the automation script. or into the file that contains the script. (Consensus)
非常应该把测试参数包括在数据文件中，例如.ini文件，设置文件以及配置文件，而不是把它们作为常量嵌入在自动化脚本或含有脚本的文件中。(一致同意)
28. Wrappers are a good thing. Use them as often as reasonably possible. (Consensus)包裹是一个好东西。要尽可能多的合理使用它们。
