● 执行模式

　　需要考虑到以下几种用例执行需求：

　　1、执行一个单独的用例

　　2、执行一个测试用例集

　　3、重新执行失败的用例

　　4、根据其他的用例或用例集的运行结果执行相应的用例或用例集

　　除了这些以外可能还有其他的方法，主要是根据项目的需求来的，所以只需要满足特定的项目测试需求就可以了，不必全部都实现。

　　● 状态监控

　　在脚本执行的时候，框架应当能够实时监控脚本的运行情况，如果碰到运行故障的时候应当能进行基本的容错恢复处理，这样的话不至于使脚本处在一个被block的状态，从而浪费大量时间。

　　● 测试报告

　　不同的应用程序往往会有不同的测试报告的要求，有时需要把许多用例集的运行结果结合起来（总的运行报告）看，多少个成功，多少个失败，通过率多少；有时又要看单独一个用例的执行情况，哪一步失败，失败原因是什么。

　　另一方面，多样化的测试报告表现形式也是需要考虑的。Excel、word、web、pdf、...等形式可以根据实际项目需要来选择，但不论做成何种形式都至少要保证测试报告的易读、易访问。

　　● 易调试性

　　一般情况下，调试（debugging）在开发测试脚本的过程中会占据大量时间，所以是否易于调试也是一个很重要的因素，直接影响到开发和维护框架的成本，不容忽视。

　　● 测试日志

　　一个好的框架应当能在测试执行过程中生产足够详细的日志信息（文字、截图等），这对于调试的帮助很大，同时也能我们快速定位到问题所在，节省时间。

　　● 易用性

　　易学易用对于自动化测试框架来说也很重要，因为毕竟是要面向最终用户的，如果框架很难上手，会失去用户群体，那框架也就没有存在的意义了。所以在保证易用性的基础上，最好有一个详细的框架说明文档，对于新手来说帮助会比较大。

　　● 灵活性

　　灵活性是指框架应当能保证在目前的基础上做二次开发的能力，这个其实跟软件开发的标准是一样的，预留足够的可扩展性以便未来的版本升级。

　　● 性能

　　框架设计不宜过于复杂，太复杂的框架会增加脚本的加载、运行时间，从而导致运行脚本的效率低下。所以在设计框架的时候，也要考虑到性能这一因素。

　　● 引用外部工具

　　有一些外部工具本身就提供了自动化接口的，我们不妨可以把它融入到框架中，可以省去不少工作量。比如，经典的QTP+QC框架。

　　● 编码规范

　　好的编码规范能使脚本易读、易维护、易管理。下面列出了一些点：

　　1、变量、常量、函数、文件、脚本的命名规范

　　2、函数、函数库的注释规范

　　3、对象命名规范

　　最后需要说一句，自动化测试框架永远没有最好的，只有最适合的！