娱乐淘金天地

其实大家怎么理解自动化测试框架都是有道理的，毕竟自己所看到的、别人想要表达和别人已经表达出来的很可能就都不是一码事，满足自身的需求才是最重要的，每个人都应该有自己的理解。

1、自动化测试管理框架，偏向于自动化测试的全局架构理论，把自动化测试的各个环节、要素的说明和规范文档化，测试管理结构文件实例化，在没有背离测试主旨的前提下，自动化可以在规范圈定范围内任意发挥，只要满足测试需求即可。这种框架本身也带有一些基于本公司业务特点和使用需求的其他功能，例如测试运行调度、邮件服务的使用、文件服务的使用和报表分析等等。这种框架在管理上下了较多的功夫，有了成型的架构之后就可以不依赖任何一个技术核心人物，大大降低了技术储备的难度和人员离职带来的风险。缺点是在这种理论指导下若没有相应的业工具支持，框架开发或工具和框架的二次开发比较费时费力。

2、自动化测试开发框架，典型的代表就是被很多人推崇的QTP的自动化测试框架SAFFRON。这种框架的作用就是简化自动化脚本编写，分离业务、脚本操作和数据，自定义封装一些常用的操作，使自动化脚本在业务系统发生变更时更容易维护、开发速度更快。这种框架立意于直接达到关键字驱动的效果，但是如何能与整个测试部门或公司的管理有效的整合在一起，对测试管理工作起到决策支持的作用呢？很显然，单凭这个原型化的框架本身是很难做到的，因为它很单纯的应用于自动化测试程序开发这个动作本身，笔者觉得这种框架有一个更贴切的名字：自动化测试脚本开发辅助框架。个人理解，关键字驱动和数据驱动的最大区别在于描述性语言的使用上，描述性编程的优势是大幅减少了脚本对页面对象稳定性的依赖。像SAFFRON这种框架的好处也就在于即便页面控件的属性发生了一些变化，在它下面开发的脚本也能继续运行，除非出现逻辑上的不一致。而事实上对于我们的系统来说，页面元素的变化对我们来说也是一个系统监控点：是什么样的需求让编码人员去做这样的变动呢？带着这个疑问系统测试会做得更细致，如果忽略了这些微小的变更，测试缺陷遗留的风险将有可能会提高。所以两种编程方式各自有着自己的优缺点，从自动化测试脚本维护工作量和脚本灵活性的角度笔者更愿意使用描述性语言，但是从系统测试的可信度和是否足够细致的角度上去考虑，有些人可能更愿意使用傻瓜式的对象库。

一种是理论化的概念管理型，一种是实际化的开发应用型，我们的理想自然是理论结合实际了。那么不妨把两种框架实例化地整合在一起，扬长避短，用来满足我们自身的需求。仔细考察一下上面描述的两种具有代表性的典型自动化测试框架，我们会发现他们并没有冲突，并且在本质追求上都是一致的：让自动化测试更加快捷方便。我们可以考虑把小的框架封装起来，作为大框架的一个组件来使用，这样并不影响他们各自的长处发挥，并且能够很好的消除各自的弱点。同时很明显，以大框架的包容性是不仅仅只能容纳一个小框架的，需要指出的是，不同的测试脚本开发原型框架有着不同的特点，对脚本编写人员的技能、测试工具、测试开发环境等因素的要求不一样，引进的时候我们或许会发现它本身存在与整体框架规范冲突的地方，这就需要我们在执行该领域规范的时候灵活变通，实现兼容并蓄。

如果单从概念形式上还不能明确定义什么是自动化测试框架的话，那么我们不妨从自动化测试的发展进程来看看。众所周知基于QTP的自动化测试经历了下面这四个阶段：

A、简单的录制、回放

B、录制、参数化、加检查点

C、模块复用、数据分离——数据驱动

D、对象、操作、数据分离——关键字驱动——组件分离

这是一个自动化测试由简单到复杂的过程，一个自动化技术难度越来越大的过程，一个让自动化测试更具灵活性的过程，也是一个让自动化测试越来越有趣的过程。不过，无论自动化测试如何发展，测试对自动化的需求始终没有变化：简化复杂的操作过程、保证测试的简单高效！那么我们如何把这些被拆解得支离破碎的一个个组件有机地组织在一起，来满足测试的简单高效的要求呢？自动化测试框架！所以，或许大家现在明白什么叫做自动化测试框架了：

能够有效组织和管理自动化测试中所必需的各个组件、有计划地进行自动化测试执行并且支持测试结果分析和测试过程改进的结构实例或文件实例就是自动化测试框架。