关于测试框架的好处，比如快速回归提高测试效率，提高测试覆盖率等这里就不讨论了。这里主要讨论自动化框架包含哪些内容，以及如何去设计一个测试框架。

什么是自动化测试框架？

它是由一个或多个自动化测试基础模块、自动化测试管理模块、自动化测试统计模块等组成的工具集合。以常见的前端UI测试为例，一个测试框架大概包括测试对象，测试组件，基础类和函数，工具类，测试数据，异常处理，测试日志，断言和测试报告等这些模块。在设计测试框架的时候，我们要尽可能的将这些模块有机的结合起来，将脚本能够有效的组织、连贯应用起来，提高测试脚本的可维护性和可读性。

好框架的定义

由于应用系统技术五花八门，几乎没有测试框架能应用在多个项目上并体现出应有的价值，所以一般情况都需要根据项目自身情况来定制化我们的测试框架，常用的有数据驱动，关键字驱动和两种方式的混合。

a. 数据驱动 （DDT）：如果被测系统业务逻辑固定不变或变动较小，我们可以使用数据驱动，通过不同数据来保证测试覆盖率，通常数据都是保存在外面文件或数据库中，运行时自动获取。特点是数据与测试脚本分离，基于模块化的测试库，一个驱动脚本可以执行多个相似测试，这样非常容易建立新测试。

b.关键字驱动 ：将数据与关键字结合来描述如何使用数据执行测试。这种方法具备数据驱动的优势，同时非编程人员也能建立新类型测试。

设计框架的思路

1

高内聚低耦合：

高内聚就是每个模块尽可能独立完成自己的功能，不依赖于模块外部的代码；低耦合就是模块与模块之间接口的复杂程度，比如在类内部尽可能减少方法之间的调用，否则一个方法的变动会影响调用它的另一个方法。

比如，你要做两个功能：对文本文件的读写，对 word 读写，同是IO你可以放在一个类里的不同方法，高内聚。

比如，写了一个类，“人”类，“人”有自己的名字年龄等属性，每个“人”又有一条狗做为自己的属性，你可以把“人”类的属性和“人”的狗的属性都写在“人”类里，这就成了高耦合。

而把狗的属性剥离出来，写成“狗”类，在“人”类里只放一个对“狗”的对象做引用，这个“狗”类，即可做为“人”的属性，也可以做它用，即 低耦合。

2

脚本分离

对象、测试数据、业务逻辑相互剥离、灵活调用,在前端UI测试上可以得到明显的效果，我们可以使用PageObject设计模式来实现对象和业务逻辑的剥离，使用DataProvider来实现数据业务逻辑分离。

安装相应的环境依赖：

• 安装python3.7(要保证pip能用，一般安装python3.7会自动安装pip)
• 安装pytest框架---- pip install pytest
• 安装request库---- pip install request
• 安装openpyxl库（测试数据保存在excel中，需要依赖读取excel的库）---- pip install openpyxl
• 安装pycharm(编写python脚本工具)

3

模块化设计用例

如果时间充裕且项目提供支持，可以遵循以下顺序进行测试：页面对象 - 功能点 - 业务逻辑 - 业务流程。

从实现来说就是：先测试底层的页面操作对象，通过调用操作对象、及业务逻辑实现对功能点的验证，再通过调用业务逻辑组合功能点实现对业务流程的验证。不同的业务流程，对于底层的操作组件、中间层的功能点函数是完全可以复用的，只是调用的业务逻辑的差异，或者是测试数据的差异性。这样的好处是脚本相互独立性，代码复用，易维护，如有新的业务流程可以调用已有代码来组合。

• common:存放公共方法；
• config:存放环境配置信息；
• lib:存放第三方库；
• main:框架主入口；
• report:存放allure测试报告；
• test_case:存放测试用例；
• test_data:存放测试数据；

4

封装基础方法

对于一些较通用的方法，可以封装，比如log，assert，异常处理，文件读写操作，数据库读写操作，保存页面截图等等，在需要的时候直接在测试用例里调用即可。

如何开展自动化测试

自动化测试实施思路：

1.项目准备：安装相应的环境依赖；

2.设计基于pytest的测试框架结构：

3.实现接口公共文件：封装http请求；

4.抽离测试环境配置信息：获取不同环境的URL，放到config目录；

5.创建conftest.py放置一些公共的fixture；

6.将测试数据放到excel中；

7.编写自动化测试业务代码；

8.集成allure；

9.自动化执行生成结果；

10.Jenkins环境搭建；

自动化开展建议：

抓住业务测试工作中的痛点和领导的痛点，多沟通多交流，优先解决基层的工作痛点，相信一个好的领导会看到你的责任心和付出；

技术选型和方案可行性调研，多投入时间和精力，有的人性子急，前期做的很快，如果一开始的方向错了，最终会得不偿失；

如果是比较复杂的解决方案，尽量前后端分离、保证各模块的独立性、可融合性、解耦不解体，做到灵活可扩展，要有下一盘大棋的准备。

end