c. 定义经常使用的概念统一的小任务

　　openfile()函数是这种类型函数的一个典型例子。脚本编写者会编写上百个需要打开文件的脚本，但他只会有意识地关注少数脚本中的文件是怎样被打开的。至于其它的，他只是想要文件被迅速可靠地打开，这样，他就能继续测试他真正要测试的东西。添加一个库函数来做这些事情将会节省脚本编写者的时间，并且能改进脚本的可维护性。

　　这属于直接的代码重用。与其它任何软件开发一样，在测试自动化中也有同样的需求。

　　d. 定义用在若干测试用例中的更大更复杂的测试用例块

　　存在着封装更大规模的命令序列的需求。然而，这样做也存在着风险，尤其是当你过多使用时。因为一个很复杂的命令序列很可能在很多测试脚本中无法重用，所以，就不值得花力气去生成它，为它写文档，并为它加入错误检查代码以期成为编写完善的库函数。此外，序列越复杂，当用户界面改变时就越需要维护。那样一来，你的库维护成本就被一组几乎不用的复杂命令决定了。

　　e. 定义实用程序函数

　　例如，你可以创建一个以标准方法把测试结果保存到硬盘的日志函数。你也可以创建一个编码标准，即每个测试用例都以对该函数的调用作为结束。

　　每个工具都提供了它自己的一套预构建实用程序函数。这样，你可能需要也可能不需要更多额外的函数了。

　　使用框架的风险

　　你不能同时把所有这些命令都构建到你的函数库中。因为你没有足够多的人力。一些自动化项目之所以失败，正是因为测试人员试图创建一种终极的、无所不包的编程库。而在框架完成且可用之前，管理支持（一些人员的工作）就已经不存在了。因此，你必须权衡先后，随着时间逐渐地构建你的函数库。

　　不要认为每个人使用函数库仅仅是因为它已经存在。有的人的编码风格与其他人就不同。如果你没有一个编程标准来控制变量命名、函数接口的参数顺序、全局变量的使用等等，那么在一个人看来合理的东西在另一个看来将变的不可接受。此外，有的人不喜欢使用不是他们编写的代码。而另一些人由于参与项目较晚而不知道库中的内容，于是就仓促的在没有了解库的情况下开始编程。因此，你必须管理好库的使用。

　　最后，要慎重设置期望值，尤其在当你的程序员编写了他们自己定制的控件时。在发行版1.0（或你开始自动化测试的第一个发行版）中，你很可能会花费很多时间来创建一个封装了所有工作区的框架，以至你不得不编写点击按钮、选择表项、选择tab键的代码。这些工作的回报将在你最后花时间编写的发行版 2.0中体现出来。创建框架的开销很大，因此，要设置符合实际的期望值或修正你的摘要。

　　5. 按真实情况安排岗位

　　你必须让管理者注意下面几个问题。

　　首先，很多测试人员都是相对初级的程序员。他们缺乏设计系统的经验，而设计不良的框架则会扼杀项目。但是，太有能力的程序员也会使项目失败。要使自动化成功，你应该在你的测试组中多招募一些高级程序员。

　　其次，很多优秀的黑盒测试人员并没有编程经验。他们能提供紧要问题的意见，以及其它大多数程序员无法提供的与客户沟通方面的经验。他们是完成大型测试工作所不可缺少的。但是，你不能指望这些人编写自动化代码。因此，你需要一个不要求每个人都编写测试代码的岗位安排和开发策略。你还需要避免产生一种带有歧视性的想法，认为测试编程人员要高于测试非编程人员。这是一种在使用自动化工具的测试组中普遍存在的偏见，但在我看来，这是不理智的和降低生产率的。它会排挤你的高级非编程测试人员，并且会使你把大量精力投入在与实际客户需求无关的程序测试中。

　　数据驱动方法使非程序员能很好的工作，因为它使他们能通过简单地把测试规划放入电子表格中来开发测试用例。

　　第三，在把自动化外包给承包者时要特别谨慎。最好是在内部开发，把承包者视为培训者或让他们处理更多的常规事务。

　　最后，你必须让你的管理者知道，自动化是要花费时间的，而且在做初始自动化编程工作的发行版中你也无法赶回这段时间。如果你要达到你通常的测试级别，你必须增加人力。例如，如果某项目通常需要十个测试人员手工测试一年，而你想要为自动化工作投入两个人年，那你就需要保持这十个测试人员，并增加两个程序员。在下一个发行版中，你才会缩短测试时间。在这一版中，你会在某些任务上节省时间（比如配置测试），而在额外的培训和行政管理上付出更多时间。到项目结束时，你可能已经改进了面对今后困难时快速回归测试的能力，但是在进度的最后时刻，它很可能反而使你缺乏足够的测试，而并非让你有机会削减人力开支。