接口自动化测试简介与搭建整体思路

最新推荐文章于 2024-05-23 16:35:00 发布

renxingzhadan

最新推荐文章于 2024-05-23 16:35:00 发布

阅读量426

点赞数

分类专栏： 2021测试 testNG

原文链接：https://blog.csdn.net/qq_39364584/article/details/109387511

版权

2021测试同时被 2 个专栏收录

42 篇文章 5 订阅

订阅专栏

testNG

21 篇文章 7 订阅

订阅专栏

前言：

由于产品功能的不断迭代，产品的核心功能保持相对的稳定状态，因此对核心功能的验证大部分都是重复性工作，通过计算机程序来完成这类工作即高效又可靠。因此自动化测试能极大的发挥作用，提高测试效率，改进测试质量。自动化测试的目的就是将测试人员从重复繁琐的手工操作中解放出来，把精力和时间可以投入到测试需求分析，测试用例设计和测试结果分析上，从而提高测试效率和质量。在《Google软件测试之道》一书中有介绍到：在Google，70%的自动化测试工作集中于单元测试，20%集中于接口测试，剩下10%才是UI测试。因此本文主要讲解来接口自动化测试的思想与落地实施的过程。

一、接口自动化测试实施作用：

1、低成本：

根据数据模型推算，底层的一个程序BUG可能引发上层的8个左右BUG，而且底层的BUG更容易引起全网的死机。接口测试能够提供系统复杂度上升情况下的低成本高效率的解决方案。

2、高质量：

当服务端代码有改动，避免新开发功能导致其他关联功能存在问题，通过持续集成，服务端发布代码时触发接口测试代码运行，尽早发现问题，提高产品质量。

3、高稳定：

提取重要接口测试用例，定时运行程序，对线上常用的业务操作进行监控，及时发现修复。

4、高效益：

当系统复杂度和体积越大，接口测试的成本就越低，相对应的，效益产出就越高。

二、接口自动化测试核心技术：

三：接口自动化测试的四个阶段：

四：立项：

根据三所提到的，当我们拿到一个项目时，我们首先要进行的是立项，即需求的梳理与Case的设计。首先要思考的是我们要做什么，需要设计哪些case才能达到我们的目的。以下以一个项目为例做相关介绍：

项目设计与框架搭建（这里我们使用到的技术是二）：

1、表结构设计

我们首先要进行表结构的设计，看需求X是多系统，因此表接口设计时一定要考虑此因素。所以这里就诞生了第一张表，渠道表，渠道表需要哪些字段呢，最基本的id，和渠道的名称，如下图：

CREATE TABLE `channel` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(512) DEFAULT '' COMMENT '渠道名称',
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `updated_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `is_delete` int(11) DEFAULT '0' COMMENT '是否删除 0.未删除 1.删除',
  `note` varchar(255) DEFAULT '' COMMENT '备注',
  PRIMARY KEY (`id`),
  KEY `name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='渠道表';

渠道有了，我们做接口自动化测试还需要什么，最重要的是接口的url，每个系统的服务器名称或ip是相同的，因此这里我们可以提炼出第二张表，服务器主机表，字段：id, 渠道id，环境，协议，服务器主机或名称，如下图：

CREATE TABLE `server_host` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `channel_id` int(11) DEFAULT '0' COMMENT '渠道id ',
  `env` int(11) DEFAULT '0' COMMENT '环境 0.通用 1.dev 2.beta 3.线上',
  `protocol` varchar(255) DEFAULT '' COMMENT '协议',
  `server_name` varchar(255) DEFAULT '' COMMENT '服务器名称或ip',
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `updated_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `is_delete` int(11) DEFAULT '0' COMMENT '是否删除 0.未删除 1.删除',
  `note` varchar(255) DEFAULT '' COMMENT '备注',
  PRIMARY KEY (`id`),
  KEY `host` (`server_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='服务器主机表';

接下来还缺少最重要的接口路径，因此这里我们建了第三张表，接口路径表。字段：id，渠道id，接口名称，接口路径等

CREATE TABLE `interface_path` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `channel_id` int(11) DEFAULT '0' COMMENT '渠道id',
  `name` varchar(255) DEFAULT '' COMMENT '接口名称',
  `path` varchar(255) DEFAULT '' COMMENT '接口路径',
  `method` int(11) DEFAULT '0' COMMENT '接口类型：0：未设置 1:GET 2.POST 3.DELETE',
  `asserts` int(11) DEFAULT '0' COMMENT '通用断言',
  `general` int(11) DEFAULT '0' COMMENT '是否是通用接口  0.否  1.是',
  `limit_time` int(11) DEFAULT '1000' COMMENT '接口限制超时时间',
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `updated_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `is_delete` int(11) DEFAULT '0' COMMENT '是否删除 0.未删除 1.删除',
  `note` varchar(255) DEFAULT '' COMMENT '备注',
  PRIMARY KEY (`id`),
  KEY `path` (`path`),
  KEY `name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='接口路径表';

有了接口的url后，接下来就是参数了，因此这里需要第四张表参数表。字段：id，渠道id，参数名，参数值等

CREATE TABLE `mid_param` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `channel_id` int(11) DEFAULT '0' COMMENT '渠道id',
  `path_id` int(11) DEFAULT '0' COMMENT '接口路径id 0.全局参数',
  `env` int(11) DEFAULT '0' COMMENT '环境类型 0.通用 1.dev 2.beta 3.线上',
  `name` varchar(512) DEFAULT '' COMMENT '参数名称',
  `value` varchar(512) DEFAULT '' COMMENT '参数值',
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `updated_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `is_delete` int(11) DEFAULT '0' COMMENT '是否删除 0.未删除 1.删除',
  `note` varchar(255) DEFAULT '' COMMENT '备注',
  PRIMARY KEY (`id`),
  KEY `channel_id` (`channel_id`),
  KEY `name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='参数表';

有了这些数据后我们就可以进行接口测试了，但是一次完整的case跑完我们怎么知道接口的运行状态呢，这时候需要一张表进行记录。字段：id，渠道id，环境，状态等

CREATE TABLE `mid_build` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `channel_id` int(11) DEFAULT '0' COMMENT '渠道id',
  `env` int(11) DEFAULT '0' COMMENT '环境类型 1.dev 2.beta 3.线上',
  `enabled` int(11) DEFAULT '1' COMMENT '构建状态 0.构建失败 1.构建成功',
  `message_status` int(11) DEFAULT '0' COMMENT '是否发送短信 0.未发送 1.发送',
  `voice_status` int(11) DEFAULT '0' COMMENT '是否拨打电话 0.未拨打 1.拨打',
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `updated_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `is_delete` int(11) DEFAULT '0' COMMENT '是否删除 0.未删除 1.删除',
  `note` varchar(255) DEFAULT '' COMMENT '备注',
  PRIMARY KEY (`id`),
  KEY `enabled` (`enabled`),
  KEY `message_status` (`message_status`),
  KEY `channel_id` (`channel_id`),
  KEY `voice_status` (`voice_status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='构建状态表';

构建状态记录下来后我们当然也可以记录报错结果（只有错误的数据对我们才有价值）。字段：id，渠道id，环境，接口路径id，构建状态id，参数，返回数据等

CREATE TABLE `mid_errno_result` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `channel_id` int(11) DEFAULT '0' COMMENT '渠道id',
  `env` int(11) DEFAULT '0' COMMENT '环境 1.dev 2.beta 3.线上',
  `path_id` int(11) DEFAULT '999999' COMMENT '接口路径id',
  `build_id` varchar(512) DEFAULT '0' COMMENT '构建状态id',
  `params` longtext COMMENT '参数',
  `status` int(11) DEFAULT '0' COMMENT '报错类型  0.响应超时，1.返回的code不是200，2.返回的结果为空，3.返回的errno不为0，4.返回的data为空，5.返回的list为空，6.json解析错误，7.其他',
  `result` longtext COMMENT '返回的具体报错信息',
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `updated_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `is_delete` int(11) DEFAULT '0' COMMENT '是否删除 0.未删除 1.删除',
  `note` varchar(255) DEFAULT '' COMMENT '备注',
  PRIMARY KEY (`id`),
  KEY `path_id` (`path_id`),
  KEY `build_id` (`build_id`),
  KEY `status` (`status`),
  KEY `channel_id` (`channel_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='报错信息表';

进阶

在接口测试过程中很多事时候我们需要提取一些数据供下个接口使用，这个时候就需要用到，正则和使用正则了

CREATE TABLE `json_regex` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `channel_id` int(11) DEFAULT '0' COMMENT '渠道id',
  `env` int(11) DEFAULT '0' COMMENT '环境 1.dev 2.beta 3.线上',
  `ext_path_id` int(11) DEFAULT '0' COMMENT '提取接口路径id',
  `ext_name` varchar(512) DEFAULT '' COMMENT '提取参数名称',
  `regex` varchar(512) DEFAULT '' COMMENT '正则表达式',
  `ext_value` varchar(512) DEFAULT '' COMMENT '提取参数值',
  `weight` int(11) DEFAULT '99999' COMMENT '权重 权重值小权重大',
  `general` int(11) DEFAULT '0' COMMENT '是否通用  0.否  1.是',
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `updated_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `is_delete` int(11) DEFAULT '0' COMMENT '是否删除 0.未删除 1.删除',
  `note` varchar(255) DEFAULT '' COMMENT '备注',
  PRIMARY KEY (`id`),
  KEY `path_id` (`ext_path_id`),
  KEY `env` (`env`),
  KEY `name` (`ext_name`),
  KEY `weight` (`weight`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='正则表';

CREATE TABLE `json_regex_used` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `json_regex_id` int(11) DEFAULT '0' COMMENT '正则id',
  `used_path_id` int(11) DEFAULT '0' COMMENT '使用接口id，0：全局通用',
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `updated_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `is_delete` int(11) DEFAULT '0' COMMENT '是否删除 0.未删除 1.删除',
  `note` varchar(255) DEFAULT '' COMMENT '备注',
  PRIMARY KEY (`id`),
  KEY `json_regex_id` (`json_regex_id`),
  KEY `used_path_id` (`used_path_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='使用正则表';

在我们需要判断接口的具体返回数据是否符合预期也可通过json_schema来判断

CREATE TABLE `json_schema` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `path_id` int(11) DEFAULT '0' COMMENT '接口路径id',
  `env` int(11) DEFAULT '0' COMMENT '环境 1.dev 2.beta 3.线上',
  `schema_json` longtext COMMENT 'jsonSchema',
  `enabled` int(11) DEFAULT '0' COMMENT '是否可用 0.不可用 1.可用',
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `updated_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `is_delete` int(11) DEFAULT '0' COMMENT '是否删除 0.未删除 1.删除',
  `note` varchar(255) DEFAULT '' COMMENT '备注',
  PRIMARY KEY (`id`),
  KEY `path_id` (`path_id`),
  KEY `env` (`env`),
  KEY `enabled` (`enabled`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='验证接口,json_schema表';

2、框架搭建

什么是框架？你可以理解为一个完整的环，也可以理解为让接口测试脚本运行的一整套环境，平台，随便什么都可以。

接口自动化测试最基本的是调接口和加断言。

因此我们可以根据此思想，封装好相关的底层框架，case完成后自动生成测试报告。这样之后加case就会十分便捷。

五、开发阶段：

此阶段是开发人员开发接口的阶段，当然接口没有完全开发出来我们也可以用mock生成假数据，可以根据假数据先建好相应的model，完成接口测试用例的设计

六、测试阶段：

此阶段是测试的重要环节，需要进行测试的执行与测试报告的生成

七：上线回归

在此阶段我们的case已经全部完成了，需要部署到jenkins上去，从而进行一键回归。

上面说了这么多，实际上它的意义就是：数据与脚本分离，测试结果自动提交通知，提高测试脚本和测试数据的维护便利等等。。。
————————————————
版权声明：本文为CSDN博主「美滋滋的小测试」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_39364584/article/details/109387511