自动化测试框架UFT BASED
自动化测试，一个现在被炒的火热的词；各大公司都在嚷嚷着要上自动化测试的项目，都在招聘各种自动化测试人员。。。
本材料对于编程基础较低初学者，在编写和学习过程中可以接触到很多旁枝侧节的知识，这些都是做好自动化所有需要的知识；对于有一定技术储备。
本框架不能帮你成为高大上的编程大牛，或者自动化测试的行家。但是，它可以引领你迈入自动化测试的领域。
师傅领进门，修行靠个人；一切的一切都还是要靠你自己去多多实践，不是有一句名言么？实践是检验真理的唯一标准！
一、自动化测试基础
手工测试VS自动化测试
手工测试：
手工测试就是由人去一个一个的去执行测试用例，通过键盘鼠标等输入一些参数，查看返回结果是否符合预期结果。
自动化测试:
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自概念。
自动化测试又可分为：功能自动化测试与性能自动化测试，在本文中我们着重探讨功能自动化测试。
什么样的项目适合自动化测试
1、任务测试明确，不会频繁变动
2、比较频繁的回归测试
3、软件系统界面稳定，变动少
4、需要在多平台上运行的相同测试案例、组合遍历型的测试、大量的重复任务
5、软件维护周期长
6、被测软件系统开发比较规范，能够保证系统的可测试性
7、具备大量的自动化测试平台
8、测试人员具备较强的编程能力
UFT简介
UFT是Unified Functional Testing的简称，是一种自动测试工具。
以VBS为内嵌语言。
UFT自动化测试的基本功能包括：
创建测试
检验数据
增强测试
运行测试脚本
分析测试结果
维护测试
UFT工具特点
特点：易于上手，开发简单，功能强大
注：主流配置都能带起了（选择UFT11.5和UFT12.0）
二、自动化测试模型介绍
一个自动化测试框架就是一个集成体系，在这一体系中包含测试功能的函数库、测试数据源、测试对象识别标准，以及种可重用的模块。自动化测试框架在发展的过程中经历了几个阶段，模块驱动测试、数据驱动测试、对象驱动测试。
线性测试
通过录制或编写脚本，一个脚本完成一个场景（一组完整功能操作），通过对脚本的回放来进行自动化测试。这是早期进行自动化测试的一种形式。
参见下图test1和test2实例：
通过上例，我们可以看出：
每一个脚本都是独立的，任何一个脚本文件拿出来就能单独运行；当然，缺点也很明显，用例的开发与维护成本很高。
一个用例对应一个脚本，假如登陆发生变化，用户名的属性发生改变，不得不需要对每一个脚本进行修改，测试用例形成一种规模，我们可能将大量的工作用于脚本的维护，从而失去自动化的意义。
这种模式下数据和脚本是混在一起的，如果数据发生变也需要对脚本进行修改。这种模式下脚本的没有可重复使用的概念。
模块化与类库
我们会清晰的发现在上面的脚本中，其实有不少内容是重复的；于是我们就考虑能不能把重复的部分写成一个公共的模块，需要的时候进行调用，这样就大大提高了我们编写脚本的效率。
参见下图：
通过阅读上面的代码发现，我们可以把脚本中相同的部分代码（登录）独立出来，形成模块或库。
这样做有两方面的优点：
一方面提高了开发效率，不用重复的编写相同的脚本；假如，我已经写好一个登录模块，我后续需要做的就是在需要的地方调用，不同重复造*。
另一方面方便了代码的维护，假如登录模块发生了变化，我只用修改文件中登录模块的代码即可，那么所有调用登录模块的脚本不用做任何修改。
数据驱动
数据驱动应该是自动化的一个进步；从它的本意来讲，数据的改变（更新）驱动自动化的执行，从而引起测试结果的改变。这显然是一个非常高级的概念和想法。其实，我们可直白的理解成参数化，输入数据的不同从而引起输出结果的变化。
参见下面例：
不管我们读取的是数组，还是字典、函数，又或者是csv、txt文件。我们实现了数据与脚本的分离，换句话说，我们实现了参数化。我们传一千条数据，通过脚本的执行，可以返回一千条结果出来。
同样的脚本执行不同的数据从而得到了不同的结果，是不是增强的脚本的复用性呢！
关键字驱动
理解了数据驱动，无非是把“数据”换成“关键字”，通过关键字的改变引起测试结果的改变。
关键字驱动用编程方式就不太容易表现了。UFT、robotframework等都是以关键字驱动为主的自动化工具，因为这类工具主打的易用性，“填表格”式的关键字驱动帮我们封装了很多底层的东西，我们只要考虑三个问题就可以了：我要做什么？ 对谁做？怎么做？。
三、自动化框架设计
环境要求
体系结构与驱动逻辑
文件组织结构
文件组织结构说明
1. Autotest文件夹,整个工程的最高一级目录，名称可以修改。
2. driver文件夹,这个是整个框架的入口，内有Driver.vbs驱动程序、wyz.vbs辅助程序和UFT测试项目文件夹
3. testpro文件夹,用于记录有哪些项目，是否执行
4. testdata文件夹，用于设计测试用例，给testscript提供数据、期望值等信息
5. testscript文件夹，存放测试脚本，全部存储为vbs文件。类名对应项目名，对应文件名，一个函数对应一个用例（需和testdata中信息对应），也可添加其他公共函数
6. library文件夹，按项目名称分文件夹放置的对象库文件
注：testdata和testscript目录下的内容，是真正需要开发的。
数据组织结构说明
数据组织总结
1、基于把测试设计和脚本开发分开的思路，设计了testpro和testdata Excel表格。测试设计时，主要是设计testdata中的测试用例数据表格；
2、开发testscript中的测试用例脚本；
因此，希望尽可能把这些Excel表格做得更易用。所谓的框架，就是把这几个Excel 表格串起来的东西。
driver 脚本驱动逻辑
优势：
脚本文件少，并且占用的空间也少了；
可以使用版本控制工具对单个的数据文件或者vbs 文件进行版本控制；
测试设计和脚本开发解耦；
测试用例和数据的展现更加人性化。
缺点：
异常的捕获考虑得很少；
日志只是打印到output或输出到文件，不利于查看。如果把日志输出到数据库，就可以生成相应的测试执行报告；
测试用例的管理太过于简陋。
注：该框架编写和学习对于想要学习自动化框架编写的同学，可以起到一个入门，可以帮助同学理清楚自动化框架设计的思路
以上内容皆为wyz私有版权，转载请注明出处，如果有同学或者同事进行共同深入的研究，需要相关自动化材料和自动化框架的代码，请加QQ:2604947115，我们共同进行探讨。