软件测试自动化框架的基本构成

所谓自动化测试框架,可以解释为自动化测试的整体解决方案,是由一些假设、概念和为自动化测试提供支持的系统及其最佳实践等构成的集合。对不同的应用领域或不同的测试水平,自动化测试的框架具有不同的构成,但我们必须清楚如何满足自动化测试的基本要求,了解自动化测试框架的基本构成,从而在此基础上,根据自己组织的实际情况来进行扩充,从而构造适应性更强、效率更高、功能更强的自动化测试框架。

  为了能开展自动化测试的工作,首先需要基础设施(infrastructure)来支撑测试工具的运行,这包括Web 服务器、邮件服务器、FTP 服务器等。其次是执行自动化测试,要有一套机制来保证测试脚本的执行。具体地说,就是先建立测试环境,创建和执行测试套件,然后获取执行状态并给出测试结果报告。根据这个分析,可以描述一个自动化测试框架的雏形,如图2-11 所示。

图2-11 软件自动化测试框架的雏形

  图2-11 中的雏形给出了自动化测试框架的基本构成要素,包括执行器、脚本管理器、报告生成器等,也比较清楚地描述了这些要素之间的关系。但是,这个框架还没给出其他一些必要的信息,例如:

  测试脚本的层次性,如何分离业务逻辑和系统基本操作?

  如何实现自动化测试工具的接口?

  如何实现被测试系统的对象映射?

  如何事先安排测试任务?

  如何管理有效测试资源?

  如果要在测试脚本上分离业务逻辑和系统基本操作,必须将各种基本操作封装为特定的关键字,每个关键字对应一个函数,而业务逻辑可以由关键字和参数来描述,即可以通过图2-12 来描述这种脚本结构。

图2-12 关键字驱动脚本框架示意图

  事先安排测试任务,也是非常重要的。例如,测试人员在下班前将测试任务安排好,测试实际执行可以在晚上9 点钟以后或得到新的软件包后自动开始。这样,测试人员在第二天上班前就可以得到测试报告。安排完任务,还需要开发具有相应触发机制的引擎(Engine/ Cron Job)来执行测试任务。它负责完成自动部署软件包、向各台远程测试机器分发脚本并启动测试工具等工作。对于这部分,可以用图2-13 来描述,其中底层的基础设施可以由STAX 实现。

图2-13 自动化测试任务的安排和执行

====================================分割线================================

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-09-26 09:26:56

软件测试自动化框架的基本构成的相关文章

创建一个有效的GUI自动化框架

一个良好的自动化测试框架应该具备灵活的,与应用程序无关的,与技术无关和不过时的特点.本文强调的准则可以帮助开发者深层分析测试方案中的代码.这种能力已经被证明在多个自动化项目上是有效的. "自动化框架"这个术语已经为软件测试领域所熟知.尽管很多人都把它与应用在基于UI自动化的技术联系起来,但是它几乎总是被滥用于那些参与测试领域.这大部分的原因是由于大家对自动化框架的应用领域有误解.它应该不仅仅像Coded UI那样,只是一个单纯的UI技术. 现在,市场上有很多商业性的和开源的测试自动化框

云计算环境搭建综合全面的自动化框架

所以无论您是环境部署工程师还是自动化脚本开发人员,如果您想开发一套自动化环境部署的解决方案,阅读本文将会有助于您的工作.作者所在的项目是 IBM 基于企业级的 一款庞大而 复杂的云计算战略产品,通过为用户提供可视化的网络平台接口,充分和快捷地帮助客户部署高灵活度的云方案.在项目开发及上线过程中,平均每四个小时会发布一个 新的安装版本,从软件测试到生产发布需要超过四个环境的支持,尤其在 Demo(演示)环境每天需要部署一次,每个环境会涉及冗余 镜像服务.分布式架构.加密的 VPN 终端访问.而部署

选择测试自动化框架

基于只使用一种捕获工具例如IBM Rational Robot来录制并且回放测试用例而得出自动化测试工作量是有缺陷的.只使用一种捕获工具来运行复杂且巨大的测试是非常耗费时间和昂贵的.因为这些测试是随机创建的,他们的功能性是很难追踪和重现,而且维护成本也是非常昂贵的. 对于一个刚刚起步的自动化测试小组,更好的选择是使用一种测试自动化框架,它已经定义好了由一些假设,概念和制定工作平台或为自动化测试提供支持的实践组成的集合.在这篇文章中我试着将一些我熟悉的测试自动化框架-特别是测试脚本模块化,测试库构

Api自动化框架分享

前言 今天把我最近的一点小小的收获分享给到大家,希望能给大家一点帮助和启发-当然最需要的还是大家的意见!  今天给大家分享的是最近开发的一个API自动化框架: 框架定位 1,数据驱动  2,简单流程覆盖,快速迭代  3,组合Case不需要Coding 总而言之只要是代码能够实现的,能方便API测试的都是框架定位的方向~! 框架介绍 边画的很不专业,随便画的应该是还有一个 数据层,所有的都是以数据配置的方式来驱动整个运转的!~ 所需环境 Jenkins + Svn + Maven+TestNG+R

APP 自动化框架设计思路分享

APP自动化框架设计分享 框架需要解决的问题: • 渠道包->多渠道包核心用例自动化 • 多设备覆盖安装,安装卸载更新等测试 • 多设备核心用例适配测试 • 验证主要页面(包括webview)检查是否加载成功 • 离线主流程覆盖 • 一些重复性操作可以通过框架简单实现 框架目标定位: • 让Tester无需编写代码 通过简单数据驱动方式实现通用简单的自动化 • 跟开发约定一些UI上的元素标准和规范建立自动化规范流程化 • 结合实时抓包组件和性能监控插件方便分节点定位问题 • 自动异常捕获,Cra

Appium移动自动化框架

Appium 框架的功能 (1)支持iOS.Android,可在多台机器上并行App 自动化,测试机型适配.  (2)代码实现关键字驱动: 测试集:关联Excel 测试用例和脚本配置. 测试数据:Excel 存储输入数据.控件元素.测试结果. 测试脚本:由Java 和TestNG 编写,分层结构有case.log.config.report 以及data 等. (3)自动测试用例执行: 从功能测试用例中抽取需重复执行的.主要的功能进行用例覆盖. 支持用例failed(失败)时自动截屏. fail

UI自动化框架调研-番外篇

导语 前面写了两篇文章介绍了个人基于Macaca在UI自动化上的实践心得,那我们为什么会选择了Macaca呢,这篇文章将简单介绍一下我们选择Macaca的原因. 有哪些可用的UI自动化框架? 他们的区别在哪里? 我们是如何选择的? 条件1:支持移动端app自动化 从以上对比其实已经可以比较明确的帮助大家做出自己的选择,从我所在的团队来讲,我们主要做的是移动端的UI自动化,相信现在大多数同学所做的也都是这一类的自动化,因此,仅限于PC端webApplication的几个框架就不可避免的要排除掉了,

CYQ.Data 从入门到放弃ORM系列:开篇:自动化框架编程思维

前言: 随着CYQ.Data 开始回归免费使用之后,发现用户的情绪越来越激动,为了保持这持续的激动性,让我有了开源的念头. 同时,由于框架经过这5-6年来的不断演进,以前发的早期教程已经太落后了,包括使用方式,及相关介绍,都容易引人误解. 为此,我打算重新写个系列来介绍最新的版本,让大伙从传统的ORM编程过渡到自动化框架型思维编程(自已造的词). 于是:这个新系列的名称就叫:CYQ.Data 从入门到放弃ORM系列 什么是:CYQ.Data 1:它是一个ORM框架. 2:它是一个数据层组件. 3

ShutIt:一个基于Python的shell自动化框架

译者注:本文通过实例简单介绍了ShutIt这个基于Python的自动化框架的使用方法.除了pexpect,我们又多了这个选择.以下是译文. ShutIt是一个易于使用的基于shell的自动化框架.它对基于python的expect库(pexpect)进行了包装.你可以把它看作是"没有痛点的expect".它可以通过pip进行安装. Hello World 让我们从最简单的例子开始吧.创建一个名为example.py的文件: import shutit      session = sh