自动化接口测试平台搭建之路，如何搭建接口自动化测试框架？

一、背景

1.目前公司发展比较迅速，还处于不停堆业务阶段，所以迭代比较频繁，导致人工回归的成本越来越大

2.在有限的测试资源情况下，开发自测的需求占比不低，后端频繁发布容易心里没底

3.该平台主要使用用户是测试同学，编写接口用例不能有太多的代码量

4.自动化是为了提高测试的效率，需要考虑投入产出比，维护成本要低

Ps：好的自动化项目，一定是需要关注ROI的，这也是贯穿我们整个设计的核心思想

二、工具选型

java和python对比：就接口自动化而言，两者从成熟度来说差不多；和公司语言保持一致，有利于后期的白盒测试；组内成员会java的更多

TestNg和Junit对比：TestNG包含了JUnit4的核心功能外，更加灵活、方便；

Jenkins：轻量级、成熟的持续集成工具，插件多，基本上要用到的功能都已能支持

所以我们最终确定的方案是通过Java+TestNg+jenkins去实现

三、架构设计及技术实现

3.1、参数设计

首先，接口参数非常多，有些是只要环境一样，值全部都是同一个；有些参数是有时效性或者执行一次后就不能再被执行的；而大部分是每个接口甚至同一个接口都是不同的值，所以为了接口的低维护成本和编写成本，我这里把所有的接口分成了三大类，全局参数（接口协议、域名、环境、请求头参数等）和非全局参数（接口路径、接口入参、请求方式等）、动态参数

3.1.1 全局参数

这类参数我们基本都是放在配置文件里，这样只要改一个地方就可以，而不需要每个地方去改下，重点说一下环境这个参数，因为我们整个是通过jenkins去集成的，所以在jenkins上会去传不同的环境入参，其他所有的全局参数基本都依赖这个值，以下是我的实现方式

首先在在testNg.xml文件中，接收jenkins中传过来的参数

然后在BeforeTest中先去获取这个参数，如下：

@Parameters({ "env" })

@BeforeTest

public void getEnv(String environment) {

...

...

}

3.1.2 非全局参数

为了接口参数更方便的管理、编写和维护，所以我们采用数据分离的方式；另外我们在我们的持续集成方案中，需要支持多个环境，所以我们在设计上需要区分环境；每个应用部署完后，我们只希望跑对应的接口用例，而不是全部都跑一遍，所以我们需要区分应用。

3.1.3 动态参数

为了我们接口用例的可维护性，所以我们需要尽可能缩短维护的时间，那很多接口的参数是有时效性的，比如token；也有些参数是用过后就不能再继续用的，比如库存，那有两个方案，一个是每次执行前都恢复下数据，但这样可能太重了，不仅要恢复数据库，可能缓存这些也要考虑；所以我们用了第二个方案，就是动态参数化，从而保证不用频繁的修改。

主要涉及两个方法，一是从上个接口的响应值中提取指定的参数；二是在后面的接口去用这个参数

3.2、断言

断言是自动化测试的重要组成部分，也就是实际值和预期值的比较，我这边也简单给它分成了二大类，静态断言、动态断言

动态断言：期望值从数据库/redis/es中，查出来后再去和实际值比较，适用范围（经常变的重要字段，如库存等）

静态断言：把期望值设为固定值，也是最常见的，适用范围（接口返回状态、接口的json格式等）

这里说下，我们这边实现静态断言的方式，静态断言也有好几种，一是直接通过响应值中是否包含你预期值中的字符串，这种优点就是编写比较快，但是会有偏差；所以我们用的是在响应值中，通过jsonpath，把值提取出来后再去比较，但是往往我们的一次断言中，需要断言的肯定不止一个字段，所以我们会把这些都塞到数组中，最后直接拿预期值数组和实际值数组去比较，以下是我们execl中的截图

Ps：因为我们需要考虑到维护成本，所以我们在断言选择上需要做一些取舍

3.3、持续集成

我们期望是在某个应用发布后，能自动触发执行我们对应模块的测试集，并且当有执行失败用例时能实现钉钉告警、卡点，并且发送报告，以下是我们的设计流程图

Ps：之所以用jenkins就是，jenkins已经集成了非常多的成熟插件，而且可以通过get/post接口，远程去通过参数化去执行jenkins中的任务，包括发送邮件及钉钉告警，这样在我们整个框架搭建上，就节省了很多编写代码的成本，而只需要去关注接口自动化本身的脚本编写上

 3.4、测试集编写

基于以上的背景，所以要求代码量要尽可能的少，这里主要用到TestNg中的@DataProvider和@test，通过@DataProvider从execl中读取对应的参数，然后通过@test去执行对应的测试集，以下是我们一个测试集所有的代码量

四、总结

好的自动化项目，一定是为了解放更多的人力，但如果投入和产出不成正比，那注定是没有意义的，整个项目也还有很多不足的地方或待优化的地方。目前正在组内推广中，期望在质量保障上能带来更多的收益。

为什么要做（自动化）接口测试？

　　1、由于现在各个系统的复杂度不断上升，导致传统的测试方法成本上升且测试效率大幅下降，而接口测试相对于UI测试更加稳定，且相对容易实现自动化持续集成，可以减少人工回归测试的时间成本，缩短测试周期。

　　2、接口测试可以更早的介入到项目开发中，一般只要接口定义好了，就可以写代码了。而功能测试必须要等系统提供可测的界面后才能进行。

　　3、相对于UI测试（某些测试环境搞起来贼麻烦）来说，接口测试可以更简单全面地覆盖到底层的代码逻辑，从而发现一些隐藏bug。

　　4、从安全层面来说，现在大部分系统前后端框架是分离的，只依赖前端进行限制已经不能满足系统的安全要求，需要后端同步进行控制，所以测试也需要从接口层面进行验证。

　　5.越来越多的团队开始接收DevOps所倡导的高度协同，研发、测试、运维及交付一体化的思维，对测试效能提出了更高的要求。

　　接口测试原理

　　模拟客户端向服务器发送请求，服务器接收后进行处理并向客户端返回应答，客户端再接收应答的过程。

　　测试范围

　　·业务功能（包括正常、异常场景是否实现）

　　· 业务规则（覆盖度是否全面）

　　· 参数验证（边界、业务规则是否达到要求）

　　· 异常场景（重复提交、并发提交、事务中断、多机环境、大数据量测试）

　　· 性能测试（响应时间、吞吐量、并发数、资源要求）

　　· 安全测试（权限验证、SQL注入等）

　　一、自动化测试框架规划思路

　　1.选择语言

　　· python

　　· java

　　自己擅长哪个选哪个，推荐python

　　2.编程工具选型

　　· pycharm

　　· vscode

　　自己擅长哪个选哪个？

　　3.测试框架选型

　　· unittest ---python自带的测试框架

　　· pytest ---unittest升级版，推荐

　　· httprunner

　　· rf框架 ---关键字

　　4.报告可视化方案选型

　　· htmltestrunner

　　· beautifulreport

　　· allure

　　5.持续集成方案

　　· jenkins

　　6.仓库服务器选型

　　· github ---服务器在国外

　　· gitlab

　　· gitee

　　7.测试管理工具选型

　　· 禅道

　　· jira

　　接口自动化测试框架的搭建一般有两种思路：

　　1.基于工具的

　　例如：Postman+Newman+Jenkins+Git/svn Jmeter+Ant+Jenkins+Git/svn

　　2.基于代码的

　　例如：Python+Requests+Pytest+Allure

　　个人建议：如果是学习阶段，选择基于代码的模式，通过自己一步一步的规划项目、编写代码，可以更好的理解接口自动化的实现原理，之后再学习一些工具会更得心应手。

　　我这里选择的是： Python+pycharm+pytest+allure+gitlab+jira

　　规划好方案后就可以创建我们的项目代码工程了（可以与编写测试用例并行，需要提前约定好测试用例的格式，方便后续代码设计）。

　　二、项目代码工程构建思路

　　设计框架的原则：

　　· 封装基类方法

　　对于一些较通用的方法，可以封装，比如发送请求、增、删、改、查。

　　· 高内聚低耦合

　　每个模块尽可能独立完成自己的功能，不依赖于模块外部的代码。

　　模块与模块之间接口的复杂程度尽量低，比如在类内部尽可能减少方法之间的调用，否则一个方法的变动会影响调用它的另一个方法。

　　· 脚本分离

　　业务代码、测试数据应该相互剥离、灵活调用。理念类似初识PO模式并在Selenium中简单实践中的PO设计模式。代码中应该不出现具体的数据、配置。而是调用对应的数据文件。

　　三、一个比较完善的项目代码工程结构：

　　- common #包文件，公共模块，存放一些通用方法

　　 - baseapi.py

　　 - class BaseApi()#基类

　　 - 方法1：发送请求

　　 - 方法2：增

　　 - 方法3：删

　　 - 方法4：改

　　 - 方法5：查

　　- libs #包文件，存放业务层代码

　　 - login.py #登陆模块

　　 - class Login(BaseApi) #继承基类里的BaseApi

　　 - 方法1：发送登陆请求

　　 - 方法2：发送登出请求

　　 - logout.py #登出模块

　　 - class Logout(BaseApi)

　　- configs #包文件，存放配置

　　 - config.py

　　 - HOST='xxx'#用于切换测试环境

　　 - url='xxx'

　　- datas #文件夹，存放数据/测试用例

　　 - xxx.xls

　　 - xxx.yaml

　　- testCase #包文件，存放测试用例代码,注意符合pytest命名规范

　　 - test_login.py

　　 - class Test_login

　　 - 方法1：test_login01

　　 - 方法2：test_login02

　　 - test_logout.py

　　 - - class Test_logout

　　 - 方法1：test_logout01

　　 - 方法2：test_logout02

　　- outFiles #文件夹，输出文件

　　 - logs #存放log文件

　　 - report #存放报告

　　 - screenShot #存放截图

　　- tools #包文件，工具类

　　 - handle_data.py

　　 - handle_excel.py

　　 - handle_path.py

　　 - handle_yaml.py

　　- docs #文件夹，存放说明类文档

　　 - 代码规范.doc

　　 - 需求文档.doc

　　框架搭建：

　　四、后续代码编写思路：

　　框架写好后的代码编写思路，大体上为

　　1.基类封装，把一些常用的方法比如发送请求、增、删、改、查放到我们的基类里。

　　2.编写业务层的接口代码。

　　3.编写测试用例代码，过程中发现缺什么就去写什么方法，思考这个方法应该放在具体业务内还是基类还是tools内，这个过程是对代码不断优化的过程。直到我们的用例代码写完。

　　比如，写测试用例代码过程中需要读取yaml文件，就在tools内加一个get_yml_data的方法

　　再比如，两个业务模块之间需要关联，需要A方法返回对象给B方法用，则去优化A方法，给出返回值。

　　再再比如，一些关键节点需要截图，则去补充截图的方法。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。