在你创建的库中很多函数可以在几个应用程序中用（或者你把他们设计得很灵活）。不要期望百分之百的灵活。比如openfile函数的一个版本中可能对每个用到标准文件对话框的程序都有用，但是你有些时候你要用到的是附加其他功能的自定义对话框。
框架中包含几种类型的函数，根据应用程序简单包装的函数或者使用处理一个集成任务的复杂脚本函数。下边是一些基本的类型：
a． 定义每个应用程序的功能特征
你写一个菜单选择的函数，下拉菜单，设置变量值，或者发布一个命令。如果UI的其中一个功能发生变化，你只要改动函数功能就可以了。当重新编译连接后，任何用到这个函数的脚本自动更新。
框架的本质是当处理自定义控件时，例如自画控件。自画控件就是程序员用画图命令画对话框。自动化测试工具知道那里有个窗体，但是它不会知道内部怎么样。当他不知道那里有个按钮的时候，你如何用工具点击对话框中的按钮呢？当你不知道那里有个listbox框在那里的时候，你如何用工具选择列表框中的选项呢？你可能应用一些技巧选择列表中的第三个选项，但是你如何选择一个在任何位置变长的列表中的项目呢？跟着的问题是：当你决定重新录制的时候，你怎样处理一般不显示的按钮和列表框和其他一些界面元素呢？
在lawst会议上，我们讨论了如何把想法组合在一起。一些与会者都证实大概有一半自动化开发的时间在处理自定义控件的问题。
组合这些想法是复杂的，维护量很大，对于脚本开发者来说是分心的事情。我认为他们分心的原因是自动化工具问题带来的而不是测试脚本程序的问题。他们把测试人员的焦点转移在工具的缺点上了，而不是在发现和报告程序潜在的问题。
如有你坚持用自画控件，压缩你程序的每一个功能可能是你框架中最紧迫的任务。隐藏每一个组装的函数。用哪个特性，编程人员就调用那个特性，不用考虑组装的函数。如果UI界面变化，组装函数不用影响脚本的情况下重新编写。
b．定义命令或者测试工具语言的特征
自动化工具有自己的脚本语言。你可能发现把每个命令封装到一个间接的层里面很困难。封装函数是把其他函数封装在里面。简单例子是，仅仅调用一个封装的函数。你可以修改封装函数，添加或者修改功能解决测试工具的缺陷，或者增强脚本语言的优势。
Tom Arnold提供wMenuSelect的例子，一个Visual Test选择菜单的函数。他封装了SelMenu函数，SelMenu就是简单调用了wMenuSelect函数。这很灵活。比如你可以修改SelMenu函数，添加日志函数或者错误处理或者内存监视功能，你可以想到的任何功能。添加功能后，每个脚本不用添加任何代码就可以获得新的特性。这很适合压力测试，执行结果分析，错误分析，还可以达到报告和调试的目的。
用到这个方法的与会者说这样做可以重复使用。
c．定义小的，概念性的频繁做的统一目标
openfile函数是这种类型函数的简单例子。脚本开发者写成千上万个要求大打开文件的脚本，只要关心在这些脚本中打开的文件怎么样就可以。对于测试来说，它就像文件快速打开，完成他测试的目标。写一个库函数可以节省脚本编写时间，改进脚本维护的质量。
这是代码中重用最简单方法，不管在测试自动化开发还是其他软件开发中都一样。
d．定义大而复杂应用到一些测试用例里面的大的测试用例脚本
压缩大的序列命令是合理的。特别是你过分做这个工作，是有风险的。一个复杂的序列命令可能不是用到很多测试脚本中，所以不值得推广，事实证明，应该加入错误处理代码到你期望适合写库函数中。同样，越复杂的序列，当ui变化越需要维护。一个很少用的脚本命令可能占用你的库维护成本的很大部分。
e．定义实用函数
比如，你可以创建一个用标准方法记录测试结果到硬盘的函数。你可以在开发脚本的时候把它作为标准在每个测试用例后边调用这个函数。
每个测试工具都提前提供自己写好的实用函数。你可以添加或不添加附加函数。
一些框架的风险
你不能同时把所有的命令添加到你的库中。你没有足够的支撑。一些自动化工程失败的原因在于测试提供者想创建最终的必须有的每一个编程库。管理维护在框架完成能用前无法再提供支持。你不得不分清优先级。不得不超时运行编译库。
不要期望函数库在那里每个人就都会用它。一些人的编码风格各异。如果你没有一个变量声明，函数的参数顺序，用到的全局变量等等的标准，这些对于一个程序员是合理但是对其他人就可能不合理的。同样，一些人憎恨不是他们写的代码。一些人熟悉工程代码比较慢，不知道库里有什么东西。他们总是很匆忙没有时间任何时间考虑就开始编程。你不得不设法维护这些库正常运行。
最后，小心设置执行，尤其如果你程序中有自定义控件的时候。版本1.0中（或者早期的开始自动化测试的版本），你可能花费的大部分时间去包含创建类似于点击按钮，选择列表项，选择tab页等这样模块框架。你可以节省为版本2写脚本的时间从中获益。建立框架是昂贵的。请从新考虑你的期望。
4． 认清事实
你必须给一些稳定的版本培训你的管理。
首先，很多测试人员是初级程序员。他们没有多少设计系统的经验。设计不合理的框架对工程也是有影响的。所以需要有经验的人。如果像自动化成功，你不得不需要一个有丰富编程经验的人加入测试团队。
其次，很多黑盒测试人员几乎没有编程经验。他们可以提供类似专家经验或者其他用户体验之类，这些是编程人员无法提供的。这些是有效的强壮测试不可缺少的。因此，你需要一个不用每个人都要写测试代码的稳定开发策略。你要解决创建一个测试开发人员在非测试开发人员之上的问题。很普遍，在我的观点里利用自动化测试工具的队伍中有失去理性和反对多产的偏见。这会伤害老的非测试开发人员，它会花费更多精力测试程序，而不是用户需求本身。
非开发测试人员通过往电子表格写测试计划的方式开发测试用例---也就是数据驱动方法，会做的很好。
第三，用执行人实现自动化测试要小心。他们不但要有开发经验，而且要肩负培训或者更多的日常任务。
最后，必须让管理者知道自动化是需要时间的，不要期望在最初版本中开发的自动化程序中获得效益。如果你应用层次上达到了测试目标，那么你可以添加更多的目标。如果一个项目用十个人手工测试一年正常，你可以加两名优自动化开发经验的测试人员，这时候你就有10个测试人员两个开发人员。在下个版本中，你可以减少测试人员的时间。在这个版本中，你将节省一些同样的任务时间（比如配置测试）但是你将在培训和管理费用上失去时间。在每一个项目结尾，可以提高衰退测试软件面对推迟完成测试的能力，而在计划最后一分钟确定，这样可以帮助你稍作无用的测试，胜于给你砍掉稳定版本的机会。
