自动化测试框架的构成
不管是测试框架,还是开发框架,都是为了高效、便捷的完成工作。
一般自动化测试框架四部分组成:基础模块、管理模块、运行模块、统计模块。
一、基础模块
基础模块就是底层公共的部分。就好比汽车,没有四个轮胎也就不能飞驰。
1.底层核心驱动
我们比较常见的,像selenium/webdriver。一般都是驱动测试程序的第三方库。
2.可复用组件
一个组件的复用性高,就可以降低自动化测试的成本,比如登录、时间处理等等。
3.对象库
存储测试对象的库,我们可以把页面进行分组,把一个页面上的所有对象放到一个类,也就是PO模式(Page Object)。
4.配置文件
配置文件包含测试环境的配置,和应用程序的配置。我们测试的时候一般会在测试环境测试,上线之前,我们可能会经过好几个测试环境(测试环境,联调环境,沙箱环境,投产验证环境等等)。
测试环境配置就可以减少,我们手动切换环境,改代码的成本。应用配置,我们可以利用配置文件,在不更改代码的情况下覆盖程序不同的配置
二、管理模块
管理模块就好比汽车的外观、内饰,对测试框架的使用操作体验有直接的影响,一般分为测试数据管理和测试文件管理
1.测试数据管理
测试数据,就是我们的测试用例用到的各种测试数据,一般都是为了验证业务而构造的,一条用例对应一条数据或者多条数据,分为事先创建和实时创建。
实时创建,就是我们在测试过程中生成的数据,这是测试数据和测试代码是耦合的,也比较符合业务运作场景,通常用在测试公用功能。例如,用户绑定银行卡以方便后续支付,但是如果调用链比较长,耗时就会比较久。
事先创建,测试前就已经构造好的数据,在测试的时候可以直接拿来用,但是数据本身没有经过业务调用,也可以称作假数据,不能很好的验证数据产生的逻辑,必须保证数据本身的可用性和正确性,也会存在业务在生产数据时失败的风险。
测试数据在测试中是非常重要的,关系到测试用例的有效性,测试框架要做到对测试数据有效管理。
2.测试文件管理
测试框架的文件结构应该清晰有序、一目了然。
比如,一个测试用例应建立三个对应的文件,page类文件(xxxPage,根据PO模型)、测试类文件(testxxPage)和对象库文件(xxxPageYml)。
这三个文件共同描述了一个完整的用例,当看page类型时,就应该做到它还有一个对应的测试类。
测试文件的结构清晰,有助于他人理解测试框架的设计思想,便于测试框架维护和推广。
三、运行模块
运行模块就好比汽车的动力系统了,主要用于测试用例的组织和运行,包括:测试用例调度,驱动机制、错误恢复机制、持续集成支持。
测试用例调度,驱动机制 可以理解为框架驱动测试用例的生成、和执行。可以根据需要,通过指定Tag,动态选择执行需要的测试用例,可以按顺序执行,也可以并发,还可以远程执行。
错误恢复机制 容错机制,由于测试环境、程序、代码的各种不确定因素,测试框架应具备一定的错误恢复机制。当执行用例过程中,出现错误,测试框架应该能够识别错误并给予相应的处理。一般分为代码/运行导致的错误和环境/依赖导致的错误。
持续集成支持 测试框架能够和CI系统低成本集成,用户可以通过设定参数,部署测试代码、运行指定的测试环境、生成测试报告等。
四、统计模块
一般分为测试报告和日志模块。
测试报告 包括测试用例条数统计、用例成功/失败百分比、总的执行时间等。对于单条用例,还应包括测试用例ID、运行结果、运行时间、所属模块、执行失败截图、测试的日志等信息。
日志 测试框架应该包括完善的日志文件,方便出错时进行排查和定位。
对于框架,我们可以通过一个例子,课程当中用了一个蚂蚁吃甜点的例子。我自己想用盖房的例子:
1.当用一些材料建房子时,没有图纸,没有计划,也没有细分工种。这时盖房子就会乱作一锅粥!不知道房子的外观、几层、平房还是楼房、每个人应该先做什么,该怎么做。——就好比没有测试框架,一切都要从0开始。
2.当我们拿到一个草图时,我们要建几层,要建平房还是楼房,可以先把地基建好。——测试框架的一个核心雏形。
3.细化图纸,细化分工,要建一个三层的小别墅,某些工人砌墙,某些工人安门窗等。——测试框架安装,配置等。
4.按照工期和分工开始建造。——测试框架 里Test Runner的作用。
5.美化别墅外观,装修内部。——各个开源测试框架,底层协议大都是webdriver的json wire protocol
当下测试框架有很多类型,比较常见的有四种。
常用的测试框架
1.模块化测试框架
模块化测试框架是利用OOP思想和PO模式改造而来的框架。
模块化测试框架把整个测试分了多个模块。特征:
- 将一个业务或一个页面当作一个page对象;
- 用一个page类来表示这个page对象;
- 这个page类里存放所有这个page所属的页面对象、元素操作;
- 页面对象和元素操作组成一个个测试类方法,供测试用例层调用。
使用了PO模型的框架都可以叫做模块化测试框架。
好处:方便维护,测试用例可以由不同模块的不同对象组成;
坏处:需要非常了解系统及这些模块是如何划分的,才能在测试脚本里自如运用,不然就陷入了重复定义模块对象的循环里。
2.数据驱动框架
提到数据驱动最先想到的就是DDT。个人觉得在测试服务层之间的接口时,会用到的比较多。
数据驱动框架主要解决了测试数据的问题。当我们需要为同一个逻辑,构造大量不同的数据,以满足不同业务场景,这些数据可以保存在测试代码里,也可以保存在外部文件里(包括excel、file、DB)。
数据驱动的精髓在于,输入N组数据,框架就会自动构造N个测试用例,并把每一个测试用例的测试结果独立展示出来。
3.关键字驱动
关键字驱动,出现的比较早了,比如做UI自动化测试的时候,我们经常把登录的操作,封装成一个关键字(其实就是函数名),比如点击账户输入框,输入账号,点击密码框,输入密码,点击登录,就可以封装成login的关键字。我们可以把各种关键的组合起来,生成测试用例。
在后续操作中,凡是有关登录的操作,都可以直接调用login关键字。
BDD行为驱动,被当成了一种独立敏捷软件开发技术来使用。
4.混合模型
其实测试框架的存在并不是为了分类型,没有人规定我们的测试框架要属于那一种。我们为了能够更好的完成测试工作,往往根据实际需要糅合不同框架模型,也就是第四种模型,混合模型。