本文深入探讨了自动化测试框架的定义、作用及不足，强调框架的扩展性和支撑性。介绍了自动化测试的重要性，如提高效率、稳定性和覆盖率。同时，文章阐述了常见的接口和UI自动化测试框架，并提出自动化测试框架应结合模块化、库、数据驱动和关键字驱动等思想。构建策略强调以简化操作和流程为主，结合具体需求和测试流程。未来，自动化测试框架将更加注重与流程的结合，以适应不断增长的测试需求。
目录
3、框架里面可以为后续扩展的组件提供很多辅助性、支撑性的方便易用的工具，也就是说框架是配套了一些帮助解决某类问题的库（libraries）或工具（tools）。
序言：也许到现在大家对所谓的“自动化测试框架”仍然觉得是一种神秘的东西，仍然觉得其与各位很远；其实不然，“自动化测试框架”从理念来说，并不复杂，但其之所以神秘，是因为其运用起来很是复杂，每个公司，每个部门其产品线，其运作流程都是不同的，所以就导致了在想运用“自动化测试框架”去完成自动化测试时产生了很多不定因素，导致了很多自动化测试项目的失败，让人对“自动化测试框架”开始敬而远之。
而自动化测试发展也有一段时间了，为什么到现在虽见其火热，但难见其规模，关键是大家对其的定位，很多公司以及很多人都知道做好自动化测试不简简单单的靠一个工具，而更需要一个框架，但其总是对“自动化测试框架”缺乏清晰的定位，很容易将其定位成了一个固定的框架，其实个人理解不然，自动化测试框架不是一个模式，而是一系列思想的集合，是将各种自动化测试框架思想集合应用去搭建成的一个分层组织。
一、简述自动化测试框架
无论是在自动化测试实践，还是日常交流中，经常听到一个词：框架。之前学习自动化测试的过程中，一直对“框架”这个词知其然不知其所以然。
什么是框架
框架（framework）是一个框子——指其约束性，也是一个架子——指其支撑性。是一个基本概念上的结构，用于去解决或者处理复杂的问题。
在软件工程中，框架（Framework）是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法；
另一种定义认为，框架是可被应用开发者定制的应用骨架，前者是从应用方面而后者是从目的方面给出的定义。
上面的概念比较抽象，换另一个角度解释：
1、框架本身一般不完整到可以解决特定问题；
2、框架天生就是为扩展而设计的；
3、框架里面可以为后续扩展的组件提供很多辅助性、支撑性的方便易用的工具，也就是说框架是配套了一些帮助解决某类问题的库（libraries）或工具（tools）。
约束性：针对解决特定问题的软件框架会首先定义问题的边界，进而将相关的软件组件约束在这个边界内，保持框架在解决问题方面上的内聚性。
支撑性：框架本身不解决什么问题，但给了解决问题的相关组件一个组合底子，这个底子的科学性和易用性直接影响在此之上进一步开发的科学性和方便性。
上面的2个对框架的解释和定义，看起来也并没有很简单直白的说清楚什么是框架，下面是我的一些理解：
定义：为解决某些特定问题而约束边界，支撑整个问题解决方案，配套了一些解决问题的组件而构成的工具。
特定问题：什么问题？——自动化测试
约束边界：为什么约束？——明确测试范围和目的
解决方案：用什么方案解决问题？——编程语言+工具+其他
构成工具的组件：哪些组件？—— 用例、脚本、数据、日志、报告、通知
工具：特点是什么？—— 灵活性、可扩展性、高内聚低耦合
自动化测试
1、为什么要进行自动化测试？
①、黑盒测试回归效率低
②、手动测试的偶然性和不确定性
③、回归的覆盖率不足
④、交付的产品质量无法保证，全靠评估
⑤、系统越复杂，问题越多
⑥、上线时间长、构件失败率高导致的蝴蝶效应（迭代快，加班多）
2、自动化测试能解决什么问题？
①、提高出现问题后的响应速率
②、降低回归成本
③、提高回归覆盖率
④、提高回归效率
⑤、提高回归的稳定性
3、自动化测试的不足有哪些？
①、无法减少成本投入，而是为了加快测试结果反馈，提升测试质量
②、自动化适用于回归和冒烟，而不是发现BUG
③、录制回放功能是鸡肋，可视化并不是一个很好的做法
④、不是所有所有系统所有功能都适合做自动化测试
自动化测试框架
构成框架的组件，最起码应该具备以下的功能：
Log：日志记录和管理功能，针对不同的情况，设置不同的日志级别，方便定位问题；
Report：测试报告生成和管理以及即时通知，测试结果快速响应；
Source：配置文件、静态资源的管理，遵循高内聚低耦合原则；
Common：公共函数、方法以及通用操作的管理，遵循高内聚低耦合原则；
TestCase：测试用例管理功能，一个功能点对应一个或者多个case，尽可能的提高覆盖率；
TestData：测试数据管理功能，数据与脚本分离，降低维护成本，提高可移植性；
TestSuite：测试组件管理功能，针对不同场景不同需求，组装构建不同的测试框架，遵循框架的灵活性和扩展性；
Statistics：测试结果统计管理功能，每次执行测试的结果统计、分析、对比以及反馈，数据驱动，为软件优化和流程改进，提供参考；
Continuous：持续集成环境，即CI环境，包括测试文件提交、扫描编译、执行测试、生成报告及时通知等功能，持续集成是自动化测试的核心！
常见的自动化测试框架
1、接口自动化框架：
①、java+testNG/Junit+Maven/Ant/Gradle+Jenkins+MySQL+testlink/redmine
②、python+unittest/pytest+Git+Jenkins+MySQL+testlink/redmine
③、python+rebot framework+unittest/pytest+Git+Jenkins+MySQL+testlink/redmine
④、jmeter+Maven/Ant+Jenkins+MySQL+testlink/redmine
2、UI自动化测试框架
①、java+selenium/appium+testNG/Junit+Maven/Ant/Gradle+Jenkins+MySQL+testlink/redmine
②、python+selenium/appium+unittest/pytest+Git+Jenkins+MySQL+testlink/redmine
③、python+rebot framework+unittest/pytest+Git+Jenkins+MySQL+testlink/redmine
通过上面的一些常见框架，你发现了什么？
它们都拥有共同特性：编程语言+单元测试框架+扫描编译工具+持续集成工具+数据库+项目管理工具。
编程语言：编写测试脚本、日志记录和输出；
单元测试框架：提供测试脚本运行、异常校验等一些列的配置；
扫描编译工具：测试文件扫描编译，一般配合持续集成工具使用效果更佳；
持续集成工具：Jenkins，经典的持续集成工具；
数据库：测试数据管理；
项目管理工具：测试结果统计管理；
自动化测试工具太多，上面只是列举了使用率较高以及我个人还算了解的一些开源工具，具体的框架选型，需要根据具体项目特点和团队、个人技术特点来决定！
也许很多人印象里的自动化测试框架就是一个能够进行自动化测试的程序似的。其实这不全面，真正的自动化测试框架可以不是一个程序，它仅仅是一种思想和方法的集合，说白了，就是一个架构，大家应该都知道操作系统其实也是一个架构吧，你可以把其理解成一个基础的自动化测试框架为一个简单的操作系统，它定义了几层架构，定义了各层互相通信的方式。通过这个架构我们才能在上面进行拓展我们的测试对象（核心体）、测试库（链接库）、测试用例集（各个windows进程）、测试用例（线程），而其之间的通过参数的传递进行通信（即相当于系统中的消息传递）。
二、自动化测试框架思想
接触过自动化测试的，一定不会对以下几种“自动化测试框架思想”陌生吧。
- 模块化思想
- 库思想
- 数据驱动思想
- 关键字驱动思想
很多人都将以上定义为“框架”，而我却觉得它们都只是代表了一种自动化测试的思想，不能以纯粹的框架定义。
首先，我们来看看自动化测试的一个发展，就能更加明白这些思想的真谛了。
a）第一代自动化测试，即自动化测试思想刚开始诞生时，依靠的是传统的“录制-回放”技术，这种技术与现在的工具的“录制-回放”思想不一样，其其实就是一个“模拟”的过程，即模拟你对PC的操作而形成的，其基于你对键盘的输入与对鼠标的操作，原理与按键精灵等类似，这种机制对环境的依赖性太强，对变化性太过于敏感，因此不可能发展成一种规模。
b）第二代自动化测试，即脚本化的自动化测试，利用脚本进行结构化的自动化测试，此可以应用于CLI与API的自动化测试，在其就开始集成了模块化与库思想。
c）第三代自动化测试，开始产生了各种自动化测试思想，包括数据驱动与关键字驱动思想，其伴随着对象化思想的产生，而且也造就了现在一系列的自动化测试软件，其实其中都集成了这些思想，从这时候开始，自动化就开始实现了一定的规模，开始运用在各个行业，并且发展趋势越来越快。
现在将一一根据自己的个人理解来介绍这些“自动化测试框架思想”：
1、所谓模块化思想，就是将一个测试用例中的几个不同的测试点拆分并且将其单个点的测试步骤进行了封装，形成了一个模块。
例如：一个测试用例要对一个登录程序进行测试，其中包括：用户名输入、密码输入、以及确定登录；
那么就可以将用户名输入、密码输入、确定登录、取消登录四个操作分别封装在四个不同的模块中。测试时，只需调用其模块即可。这样的话，当一个模块有变化，你只需单独维护那个模块即可，也可以根据模块的不同组合成不同的测试用例。
2、所谓测试库思想，就是模块化思想的升华，其为应用程序的测试创造了库文件（可以是APIs、DLLs等），这些库文件为一系列函数的集合。其与模块化思想不同的是，其拓展了接口思想，即可以通过接口去传递参数，而不是一个封死的模块，可以说是一个多了一个“门”的交互型模块。
例如：还是以上那个测试用例，只是将用户名输入、密码输入、确定登录、取消登录封装成一个库，这个库含有一个函数Login，这个函数Login接收两个参数“用户名、密码”，对输入不同的用户名和密码可以进行不同的测试用例。也可以另外一个函数Cancle。
3、所谓数据驱动思想，众说纷纭，很多人都觉仅仅依靠用EXCLE表进行不同数据的读取仅是一个高级的参数化，其实怎么理解并不重要，关键是其思想能够好的应用到你的框架中。而我的理解就是变量不变，数据驱动结果，不同的数据导致了不同的结果的产生。而对于数据的导入，可以通过很多方式，例如：EXCLE表、XML（用在WEB中）、数据库（DB）、CSV文件、TXT等都可以。
4、所谓关键字思想，这个思想，我曾经一直思考，它与面向对象的关系，与交互模块化思想的区别。后来个人理解，其实关键字驱动就是一种面向对象的思想，例如：QTP、RFT中，对象可以为一个数据或者一个关键字，对对象的抓取，可以将其测试对象封装为一个关键字（即可以将gui元素封装成了一个个关键字），这样可以对其关键对象进行各种操作了，不同的对象可以驱动不同的测试流向与结果。
简单的应用的方式可以用一个EXCEL表，里面包括“对象类型”“对象名称”“对象操作名称”“判断方式”“预期结果”。这样的话，可以通过导入不同的对象类型和名称、不同的对象操作来构建成了一个测试用例表了。
以上只是对这些思想的个人理解，做好自动化测试，不是说你掌握了一个框架，而是要掌握其自动化的思想，然后根据这些思想，结合你不同的测试环境和流程来构建你自己的自动化测试框架。
三、构建自动化测试框架的策略
1、永远记住，你的“自动化测试框架”是给测试人员用的，如果你真的想把自动化测试做成一个规模，那么你需要将测试工程师当做你的用户，你不能指望他们有耐心的去编写测试脚本或者指望他们能够像你一样对这些思想有良好的掌握。你要将他们当成什么都不懂的用户，因此你的框架必须是“一切简单化”的化身，简单的操作、简单的维护、简单的拓展。
2、做一个自动化测试框架主要是从分层上去考虑，而不是简简单单的应用一种思想，它是各种思想的集合体。
例如，做GUI自动化测试，简单的一般就将其分为三层，其框架如下图所示：
而其中，可以贯穿着自动化测试的各种思想，例如：对象层中有关键字的思想、可以将对象库标示在Excel表中进行管理，或者应用动态搜索的方式传递对象识别参数。tasks层中可以封装各种方法，形成一个大型的方法库，而每个方法中可以应用上数据驱动的思想。
3、真正的自动化测试框架是与流程上结合的，而不简简单单的靠技术实现，技术其实不是很复杂，关键就在于对其架构和流程的深刻把握，而这需要很长的一段时间，所以不要指望一口气能吃成胖子，只能一步一步按需求来，需求指导思想的应用。
四、自动化测试框架的发展趋势
个人认为，自动化测试从初始诞生到至今，已经经过了一段漫长的日子，而其仍处于上升期，特别是现在软件大爆炸、敏捷模式、云端的开始热门，测试难度和质量保证的难度开始越来越大，自动化测试的比重也会越来越大，而单存的自动化测试是无法实现规模化的，因此，自动化测试框架热门化的趋势化的必然的，那是，在各种框架思想的集合中，各种框架将散发出各自的璀璨，来帮助我们快速的完成各种测试。
以上仅仅是至今，个人对“自动化测试框架”的理解，也许在以后的日子，因为认识的加深而会有不同的火花蹦出，但至少觉得现在的框架对自己的项目能够进行应用，也许某一天，需求饱和时，那么，新一轮的远征探索就又要开始……
希望，我们大家在自动化测试的征程上能越走越远，也希望自动化测试能真正成为测试流程中“不可缺少”的一部分。共勉之。
五、最后:【可能给你带来帮助的教程】
这一些资料，对做【软件测试】的朋友而言应该是较为完整了，这类学习资料也陪伴我走过了最艰难的路程，希望也可以帮助到你！万事要尽早，尤其是技术行业，一定要提升技术功底。
以上软件测试资料需要的可以点下面小卡片领取
扫一扫
477
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
