对于自动化测试框架，其实并没有多数人想象中的那么高深玄乎，框架的概念只是一系列的被事先定义好的标准和规范。在自动化测试中我们经常提到的对测试需求的解析、脚本设计、测试执行、测试报告、维护管理等等，通过框架将它们串联并封装起来，从而使框架的终端用户能够更方便地使用。然而，一个好的自动化测试框架，不仅仅要能让用户方便使用，还需要考虑很多其他因素，下面就来分享一下一些个人的经验。
- 选择一种类型的框架
目前比较常见的自动化测试框架主要有3种：数据驱动框架、关键字驱动框架和混合型框架。
1. 数据驱动框架(Data Driven Framework)
数据驱动最适合测试的业务逻辑固定不变的应用程序，只有测试数据会变化。通常测试数据会被配置在外部文件或数据库中。
2. 关键字驱动框架(Keyword Driven Framework)
关键字驱动顾名思义，它提供了一系列通用的关键字，用户通过调用这些关键字并输入一些参数可以实现单个操作，比如，打开浏览器、打开某个网页、点击某个链接等等，然后通过组织这些关键字形成一个完整的测试流程。
3. 混合型框架(Hybrid Framework)
混合型框架就是把数据驱动和关键字驱动整合起来，同时具备了两者的优点。与关键字框架不同的是，这种框架通常会提供一些针对于特定应用程序的关键字，比如登录、登出等。然后在完整测试流程的基础上，再应用一层数据驱动，这样就能使测试逻辑和测试数据更加灵活和可配置。
- 不必重新造轮
在设计框架的时候应该尽可能的沿用自动化测试工具已提供的功能。比如，一个基于selenium的框架，selenium本身就已经提供了打开浏览器和网页，点击按钮等功能，就不必花时间再去开发这样一些关键字，以减少开发成本。
- 可重用性
一个好的框架必须具有高度的可重用性。我们可以把一些单独的操作组合成一些最常用的测试流程，比如，把“输入用户名”、“输入密码”、“点击登录”三个操作组合成一个关键字“登录”。
- 配置管理
如同开发团队一样，自动化脚本也需要有配置管理，这样才能更有效地对脚本的提交、修改、版本控制、基线化等操作进行管理，所以在设计框架的时候需要考虑结合配置管理工具，如CVS、VSS、SVN等。
- 可配置性
1. 外部可配置性
脚本的配置项应该放在外部文件中，像URL，路径，版本信息等，从而能使脚本在不同的环境下运行。另外配置文件的路径也不能写死，应采用相对路径，以保证框架能在不同的机器上顺利运行。
2. 内部可配置性
当框架部署到不同的机器上时，会有不同的环境，要有能够自动根据不同的系统环境完成必要配置的能力。举个例子，比如一个selenium框架被部署到装有不同浏览器的机器上，框架应当能根据当前系统上装了哪些浏览器而分别运行它们。
- 对象库维护
在自动化测试中遇到的大多数问题基本上都是由于对象的属性变化导致的脚本失败，所以，对象库的维护能力对于一个框架来说十分重要。我们可以把对象库作为一个共享资源，由专人进行维护。对象库可以是一个外部的XML、Excel、数据库等。
- 执行模式
需要考虑到以下几种用例执行需求：
1. 执行一个单独的用例
2. 执行一个测试用例集
3. 重新执行失败的用例
4. 根据其他的用例或用例集的运行结果执行相应的用例或用例集
除了这些以外可能还有其他的方法，主要是根据项目的需求来的，所以只需要满足特定的项目测试需求就可以了，不必全部都实现。
- 状态监控
在脚本执行的时候，框架应当能够实时监控脚本的运行情况，如果碰到运行故障的时候应当能进行基本的容错恢复处理，这样的话不至于使脚本处在一个被block的状态，从而浪费大量时间。
- 测试报告
不同的应用程序往往会有不同的测试报告的要求，有时需要把许多用例集的运行结果结合起来（总的运行报告）看，多少个成功，多少个失败，通过率多少；有时又要看单独一个用例的执行情况，哪一步失败，失败原因是什么。
另一方面，多样化的测试报告表现形式也是需要考虑的。Excel、word、web、pdf、...等形式可以根据实际项目需要来选择，但不论做成何种形式都至少要保证测试报告的易读、易访问。
- 易调试性
一般情况下，调试(debugging)在开发测试脚本的过程中会占据大量时间，所以是否易于调试也是一个很重要的因素，直接影响到开发和维护框架的成本，不容忽视。
- 测试日志
一个好的框架应当能在测试执行过程中生产足够详细的日志信息（文字、截图等），这对于调试的帮助很大，同时也能我们快速定位到问题所在，节省时间。
- 易用性
易学易用对于自动化测试框架来说也很重要，因为毕竟是要面向最终用户的，如果框架很难上手，会失去用户群体，那框架也就没有存在的意义了。所以在保证易用性的基础上，最好有一个详细的框架说明文档，对于新手来说帮助会比较大。
- 灵活性
灵活性是指框架应当能保证在目前的基础上做二次开发的能力，这个其实跟软件开发的标准是一样的，预留足够的可扩展性以便未来的版本升级。
- 性能
框架设计不宜过于复杂，太复杂的框架会增加脚本的加载、运行时间，从而导致运行脚本的效率低下。所以在设计框架的时候，也要考虑到性能这一因素。
- 引用外部工具
有 一些外部工具本身就提供了自动化接口的，我们不妨可以把它融入到框架中，可以省去不少工作量。比如，经典的QTP+QC框架。
- 编码规范
好的编码规范能使脚本易读、易维护、易管理。下面列出了一些点：
1. 变量、常量、函数、文件、脚本的命名规范
2. 函数、函数库的注释规范
3. 对象命名规范
最后需要说一句，自动化测试框架永远没有最好的，只有最适合的！