Ⅰ 自动化测试框架有哪几种
冒昧的说一句，您这个问题问的可能比较大。
因为从自动化测试角度讲的测试框架有很多种；而且并没有什么固定的条条框框。全部是根据测试需要及公司产品开发现状进行搭建的。从通俗的 整体的角度讲只要满足：测试输入（脚本编写）-》测试执行-》结果输出 这种模式的都可称之为自动化测试框架。
而从不同的角度分析框架又可根据不同筛选条件分为多类：
如：1.脚本语言方面分析，很多种语言提供了多种自动化测试的基础框架：
1)ruby的Watir开源自动化测试框架、Test::Unit单元测试框架、开源测试框架Ruby on Rails 等等
2)java的junit回归测试框架、Mockito、TestNG、easyb等等等等
3)Perl的perl Mechanize、Test::Base数据驱动测试等等等等
4)Python的PyUnit、PAMIE等等等等
5)基于Tcl/Tk的swift 自动化测试框架,ATF/VTP自动化测试框架
以上仅列举自动化测试常用的几种脚本语言的测试框架，当然不仅仅是这些
2.从测试体系角度分又分为：
1)单元测试框架.
2)系统测试框架
3)集成测试框架
。。。。。
3.基于测试目的的划分
1)GUI自动化测试框架
2)网络协议自动化测试框架
3)基于web的自动化测试框架
。。。。。
4.从实现深度和角度分类：
1)简单的录制回放测试框架（或工具）
2)关键字驱动的测试框架
3)关键字驱动及结果输出分析的自动化测试框架
4)智能匹配功能及具备快速脚本生成功能的自动化测试框架
。。。。。。
5.从测试工具角度分：
有些测试工具是许多大型公司结合了很多测试经验及数据后进行开发的自动化测试软件或者称之为测试管理软件的自动化管理部分及自动化测试部分；也有人称之为自动化测试框架或自动化测试工具。比如QTP;LoadRunner;Quality Center、selenium等等。都具有一定的自动化测试及管理功能。
所以总的来看，测试框架分为很多种；不知提问者问的是哪个具体方面的。
笔者水平有限，仅能做个基本介绍，希望能有所帮助。也祝愿所有从事自动化测试相关工作的同志事业顺利。欢迎沟通交流
Ⅱ 自动化测试框架的发展及开发
自动化测试框架是自动化测试的核心，在开展自动化测试工作前，需要相应的自动化测试框架。一个好的自动化测试框架不但影响自动化测试的进程，也决定自动化测试的成败。
基于界面的软件自动化测试框架经历了四个发展阶段： 无框架→数据驱动→关键字驱动→混合模型，如图 17-2 所示。
（1）无框架阶段（即简单的录制/回放）。
■ 在早期，自动化测试并没有框架这一概念，只是简单的录制/回放，由工具录制并记录操作的过程和数据，并形成脚本，通过对脚本的回放重复人工操作的过程。这种模式脚本与数据混合在一起，导致一个测试用例对应着一个脚本，维护成本很高，并且当界面发生变化时，就得重新录制脚本，导致脚本的使用率很低。
（2）数据驱动（Data Driven）框架阶段。
■ 无框架阶段最大的缺点就是脚本与数据混合在一起，为了解决这一问题，自动化测试框架发展到数据驱动框架阶段，该框架从数据文件中读取数据，通过参数化的方式将数据文件中的数据写入脚本中，由于不同的数据对应着不同的测试用例，将脚本与数据彻底地分离，因此提高了脚本的使用率，大大降低了脚本的维护成本。虽然数据驱动框架解决了脚本与数据的问题，但并没有将被测试对象与操作分离。
（3）关键字驱动（Keyword Driven）框架阶段。
■ 关键字驱动测试是在数据驱动框架的基础上改进的一种框架模型。它将测试逻辑按照关键字进行分解，形成数据文件与关键字对应封装的业务逻辑。主要关键字包括三类：被测试对象（Item）、操作（Operation）和值（Value）。用面向对象形式将其表现为 Item.Operation（Value）。关键字驱动的主要思想是：脚本与数据分离、界面元素名与测试内部对象名分离、测试描述与具体实现细节分离。
（4）混合框架（Hybrid Framework）阶段。
■ 关键字驱动框架将自动化测试框架带入了一个新的阶段，自动化测试工具 QuickTest 也很好地使用了这个理念。但在实际开展自动化测试的时候，发现测试工具所带的关键字驱动方式还是无法很好地完成测试任务。该框架虽然将数据与脚本进行了分离，但是如果要更灵活地调用测试用例中的数据或输出测试结果，该框架无法做到；并且需要读取其他文件存储格式中的数据时也是无法很好地解决，这样在自动化测试开始的前期，工程师会开发一个符合实际测试的框架来支持后期的测试工作，这就是通常所说的混合模型自动化测试框架。
随着自动化测试框架的不断发展，自动化测试脚本类型也在不断地发生变化。 自动化测试脚本类型的发展经历了以下几个阶段：
（1）线性脚本。
▲ 通过录制直接产生线性执行脚本。线性脚本无法对其逻辑或顺序进行任何的调整，产生的线性脚本只能按顺序一行一行地执行。该脚本类型对应着自动化测试框架发展中的无框架阶段。
（2）结构化脚本。
▲ 很显然线性脚本无法处理逻辑和业务关系。为了解决该问题，在原来的线性脚本中添加了顺序、循环和分支等结构的脚本，形成结构化脚本。
（3）共享脚本。
▲ 在实际测试过程中，需要将调试的脚本进行共享，供其他工程师调用，这样脚本类型就发展到了可共享的阶段。
（4）数据驱动脚本。
▲ 数据驱动脚本将数据与流程控制进行分离，通过读入数据文件来驱动流程。
（5）关键字脚本。
▲ 脚本、数据、业务分离，数据和关键字在不同的数据表中，通过关键字来驱动测试业务逻辑。
自动化测试框架是由假设、约束以及为自动化测试提供支持的工具的集合。自动化测试框架最大的优点是可以减少测试脚本实现和维护的成本，测试用例只需要修改测试用例文件，而不需要更新脚本驱动程序和引擎驱动程序。自动化测试框架的优劣直接影响到自动化测试的成功与否。
假设自动化测试框架是形成自动化测试策略的基础，下面是常用的假设条件：
约束条件影响着自动化测试是否成功，如果不注意以下约束条件，自动化测试工作将很难成功：
一般自动化测试框架应该包括四部分内容：测试管理、数据驱动、结果分析和测试报告。
如图 17-3 所示是一个混合测试框架模型样例。
Ⅲ 自动化测试：为什么需要框架
因为软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及到的知识，内容，问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，你只需要集中精力完成系统的业务逻辑设计。而且框架一般是成熟，稳健的，他可以处理系统很多细节问题，比如，事物处理，安全性，数据流控制等问题。还有框架一般都经过很多人使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，你可以直接享受别人升级代码带来的好处。
Ⅳ 自动化框架工具有哪些
1．模块化测试框架
在五种框架中，模块化框架是最容易掌握和使用的。在一个组件上方建立一个抽象层使其在余下的应用中隐藏起来，这是众所周知的编程技巧。这样应用同组件中的修改隔离开来，提供了程序设计的模块化特性。模块化测试脚本框架使用这一抽象或者封装的原理来提高自动测试组合的可维护性和可升级性。
2．测试库框架
测试库框架（Test Library Architecture）与模块化测试脚本框架很类似，并且具有同样的优点。不同的是测试库框架把待测应用程序分解为过程和函数而不是脚本。这个框架需要创建描述模块、片断以及待测应用程序的功能库文件。
3．关键字驱动或表驱动的测试框架
对于一个独立于应用的自动化框架，关键字驱动（KEYWORD Driven）I9LJJ试和表驱动（TABLE DRIVEN）测试是可以互换的术语。这个框架需要开发数据表和关键字。这些数据表和关键字独立于执行它们的测试自动化工具，并可以用来“驱动＂待测应用程序和数据的测试脚本代码，关键宇驱动测试看上去与手工测试用例很类似。在一个关键字驱动测试中，把待测应用程序的功能和每个测试的执行步骤一起写到一个表中。
这个测试框架可以通过很少的代码来产生大量的测试用例。同样的代码在用数据表来产生各个测试用例的同时被复用。
4．数据驱动测试框架
数据驱动（DATA Driven），LJ试是一个框架。在这里测试的输入和输出数据是从数据文件中读取（数据池，ODBC源，CSV文件，EXCEL文件，ado对象等）并且通过捕获工具生成或者手工生成的代码脚本被载入到变量中。在这个框架中，变量不仅被用来存放输入值还被用来存放输出的验证值。整个程序中，测试脚本来读取数值文件，记载测试状态和信息。这类似于表驱动测试，在表驱动测 试中，它的测试用例是包含在数据文件而不是在脚本中，对于数据而言，脚本仅仅是一个“驱动器”，或者是一个传送机构。然而，数据驱动测试不同于表驱动测试，尽管导航数据并不包含在表结构中。
5．混合测试自动化（hybrid Test Automation）框架
最普遍的执行框架是上面介绍的所有技术的一个结合，取其长处，弥补其不足。这个混合测试框架是由大部分框架随着时间并经过若干项目演化而来的。
Ⅳ 如何搭建自己的自动化测试框架
这段时间一直在为公司内部开发
自动化测试框架
，简称GTF，因为这个框架现在还属于开发阶段，很多事都是言之过早。我会持续将我在架构过程中的想法写下来。供自己和大家一起分享。
这些想法，并不属于我一个人，我工作中的同事们给了我很大的帮助。
今天这一篇主要说明架构方面的考虑。
在现有的提供自动化测试解决方案的产品很多，包括:Robot，TestComplete，WinRunner等等。我只接触过这些，公司里也进行过很大的尝试，但是结果往往总是不竟如人意。
这中间，排除那些人员方面的原因，也总结这些自动化工具
，在使用过程中的不方便的地方:
1. 定位控件不方便。标准控件还好，非标准控件就只能靠很多非正常方法去获取。而且，控件的识别往往和界面布局相关。
3. 代码维护不方便。由于在编写过程中，大量的和界面相关的代码，导致最后在需求变更的时候，代码的维护，成为软件测试人员的负担。
针对这些情况，我们经过讨论，何不自己做一个软件测试框架。当然了，这是基于我们的丰富的知识积累的决策。大家不需要关心这个决策的情况。不过，可以多关注一些我们在做的过程中的分析结果。
通过分析流行的软件测试框架，有多种方式:
第一、最典型的就是消息驱动，自动化工具通过脚本录制和编写，保存为测试脚本。在回放的过程中，将这些脚本转换成为Windows消息，发送给我们应用程序的窗体和各种控件。
这种方式的好处在于，自动化工具和应用程序之间能够做到完全的隔离。但是，由于使用了Windows消息，它也拥有了一个非常致命的缺点。那就是消息队列的异步性与程序的顺序性之间的矛盾。很多消息发送给了应用程序，但是应用程序的处理可能已经和消息队列错位了。有一些关于代码的时间片等待，就是因为这个问题。
另外，就是由于完全的隔离，对于操纵控件数据的能力大大降低。毕竟，拥有大量数据的控件都不是标准控件。
第二、嵌入式
。TestComplete就是这类工具。它有支持不同语言的版本。大概思路，就是在程序编译的时候，注入自己的控件代理。脚本的回放，直接可以通过代理，操纵到应用程序。
可惜的是，这类软件开发的时候，更多的是考虑平台的兼容性。对于特有平台上的支持不是十分完美。特别是对自定义控件(比如Delphi中，除了VCL的标准控件)支持也没有做到最好。不过，我这里必须承认，TC的内部实现机制可能十分强大，我不能窥探所有。如果有人清晰，可以指点一二。
针对上面的两种，我们想到的第三种方式:一体式。这种方式中，通过给程序在打包的过程中，添加额外的框架代码，使得程序自动提供控件的访问方式。自动化的模块也会作为软件测试程序的一部分运行。
应用程序在执行脚本的时候，自动通过脚本
，控制各控件界面的显示和关闭。它应该是第二种方式的变种。但是由于是自己实现的，所以在对各类自定义控件支持的都非常好。
针对一开始提出的几个自动化测试的难题，我们提出了，自动封装窗体上所有控件的概念(这些概念后面会详细介绍)，对于软件测试人员，只要关心真正的业务操作流程。而业务流程中涉及到的控件，已经为他们自动提供好。这样，脚本也自然只成了业务流程的脚本。其复杂度也就大大降下来了。
如果要推荐2个工具的话，我就推荐泽众软件公司的
自动化测试工具AutoRunner和测试管理工具Testcenter
，用这2个软件合作可以很好的进行自动化测试与对测试用例进行管理。
Ⅵ web自动化测试框架有哪些
Web自动化测试在测试领域里面用得比较多的工具或者框架有Selenium, robotframework, Cucumber等。
Selenium是一个开源的Web自动化测试框架，ujiuye主要用于做HTML页面的UI自动化测试。
RobotFramework是一个基于Python语言的，可扩展的关键字驱动的自动化测试框架，使自动化测试脚本编写变得更简单
Cucumber是BDD(Behavior-driven development，行为驱动开发)的一个自动化测试的副产品。它使用自然语言来描述测试，使得非程序员可以理解他们。
Ⅶ web ui自动化测试框架有哪些
冒昧的说一句，您这个问题问的可能比较大。
因为从自动化测试角度讲的测试框架有很多种；而且并没有什么固定的条条框框。全部是根据测试需要及公司产品开发现状进行搭建的。从通俗的
整体的角度讲只要满足：测试输入（脚本编写）-》测试执行-》...