学习笔记——自动化测试框架的构成

不管是测试框架，还是开发框架，都是为了高效、便捷的完成工作。

一般自动化测试框架四部分组成：基础模块、管理模块、运行模块、统计模块。

一、基础模块

基础模块就是底层公共的部分。就好比汽车，没有四个轮胎也就不能飞驰。

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.混合模型

其实测试框架的存在并不是为了分类型，没有人规定我们的测试框架要属于那一种。我们为了能够更好的完成测试工作，往往根据实际需要糅合不同框架模型，也就是第四种模型，混合模型。