8. 自身可配置性 – 理想的测试框架应该是自身可配置的。一旦部署到系统中之后应当不需要再做任何手工配置，脚本应当自动配置完成一些必要的设置。
9. 任何对象改动引起的变动应该是最小的 – 自动化过程中最为常见的问题是对象识别的变更。测试框架应该支持可以很容易的来完成这些修改。这可以通过将所有的对象识别设置储存在一个共享文件来实现。 这个文件可以是XML文件、Excel文件、数据库或者自动化所特有的格式。这里有两种可能的方式来实现对象识别设置的方式：
静态方法 – 这种方法中，所有对象定义都在测试最初被加载到内存中。任何对象定义变更只能通过停止和重新运行测试来实现。
动态方法 – 对象定义是通过需求拉动的。这种方式和静态方式比较而言显得较为缓慢。但是对于非常大的脚本而言，并且对象识别需要在运行时做修正的情况下，动态方法是适用的。
10. 测试执行 – 自动化测试框架也许需要满足以下需求(基于实际需求)
执行单独的测试用例;
批量执行测试用例(一组测试用例);
只执行失败的测试用例;
可以在前一个(一组)测试用例执行结果的基础上，执行下一个(一组)测试用例;
根据实际需求还会有许多其他情况。一个框架可能无法实现所有这些需求，但它应具有足够的灵活性以适应今后此类需求。
11. 状态监测 - 一个框架应允许实时监控执行状态，一旦失败能够发出警报。这样可以在出现failure之后迅速反馈。
12. 报表 – 不同的系统对报表有不同的需求，有时候需要一组测试的整体报表，有时候只需要单个测试用例级别的测试执行报表。一个好的测试框架应该有足够的弹性来按需支持不同的报表。
13. 发生更改的时候对测试工具尽量小的依赖性 – 一些测试脚本的更改可能只能在打开测试工具后，在测试工具中进行修改，然后保存。测试脚本应该在没有测试工具的情况下也可以对脚本进行更改。这样的实现可 以减少license的购买从而为公司节省开支。这样的实现还可以让所有想去修改脚本的人无需安装测试工具也可以很方便的对脚本进行修改。
14. 方便的调试 – 调试在自动化过程中占据了大量的时间，因此在调试这个过程中需要加以特别的关注。关键字驱动的测试框架因为使用了外部的数据源(比如Excel数据表)去读取脚本中的关键字和测试过程，所以较难调试。
15. 日志 - 生成日志是执行的重要组成部分。在一个测试案例的不同点生成调试信息这是非常重要的。这些信息有助于快速地找到问题的范围，同时缩短了修改时间。
16. 易用性 - 该框架应易于学习和使用。对框架的人员培训费时且昂贵。有一个好文档的框架更容易理解和使用。
17. 灵活性 - 框架应该足够的灵活，以适应任何改进，而不会影响已有的测试案例。
18. 性能的影响 – 框架还应考虑对执行性能的影响。一个复杂的框架会增加脚本的加载或执行时间，这一定不是我们所期望的。像缓存技术，当执行时编译所有代码到单个库中等.。.只要可能都应该用于性能的改善。
19. 框架支持工具 – 开发一些外部工具来完成任务，这对框架设计会有帮助。这是一些例子：
从本地文件夹上传脚本到QC
结合库文件到当前打开的脚本
同步本地和QC上的脚本文件
20. 编码标准 - 编码标准应确保脚本的一致性，可读性和易于维护。编码标准应包含下列内容：
命名规范(变量、子程序、函数、文件名、脚本名称等)，例如i_VarName为整数变量， fn_i_FuncName为返回值是整数的函数;
库、子程序、函数的头部注释。这应包含，如版本历史，创建者，最后修订者，最后修订日期，说明，参数，示例;
对象命名规范。例如txt_FieldName为一个文本框;
总结
我们应该把自动化测试看作是一个开发项目，而不仅仅是记录和回放事件。先有一个良好的框架，再开始自动化测试，这样可以确保较低的维护成本。当你在开发一个框架，进行框架的需求分析时，可以参考本文谈到的这些准则。
文章来源于领测软件测试网 https://www.ltesting.net/
