接口测试 自动化落地过程记录

liuchang · 2021年03月09日 · 最后由 yindongzi 回复于 2021年03月30日 · 6492 次阅读
本帖已被设为精华帖!

1.前言


首先感谢 testerhome 这样一个平台,因为我在二线城市,相对一线互联网有些弱,让我能学习和见识到工作中没接触的很多知识,从最开始不会自动化相关的任何东西,慢慢自学 python,期间偶然进入这个论团,从此就开启了一扇大门,见识到测试工作原来也可以这样丰富多彩,有这么多优秀的同行。

学了 python 后,最开接触 AutomatorX 项目,自己写造轮子用 pyqt5+appium+python+opencv 写了一个客户端的编写 appium 的脚本工具,后面学习 docker 的系列文章,到后面使用 httprunner,模仿 fastrunner 写的 web 工具,还有很多技术之外的东西,跟着里面的大神一起学习了很多。

言归正传,因为这篇主要是记录下最近这段时间的自动化落地情况,更想向大家交流学习下。如果对你有用,我会很开心,如果觉得这个写的很呵呵,你一定比我厉害,我也想后面哪天再看这篇文章的时候,也觉得很呵呵~~😆

2.背景

公司的产品是大数据相关的中台产品,主要服务对象是企业和政务。大数据平台包括多个子平台,每个子平台负责数据加工的 ETL 过程的管理统计安全维护等工作,今年产品很多地方投入使用,公司虽然是 CICD 线上统一部署,但是 CICD 也是刚刚起步,也存在很多问题,每部署一套环境都是需要去进行冒烟测试,政务的部署一般都在现场的内网环境,部署验证都需要通过跳板机或者远程操作去完成,每次测试数据准备,测试验证都要花费很多时间和精力,尤其是多个项目同时进行时。

3.自动化过程

首先简单说下准备的数据和大致的场景,这里只展示部分的。

3.1 数据准备

T_DJ_QYXX(企业基本信息)

字段 字段类型 字段长度 注释说明
DJXH NUMBER 20 唯一 ID
QYSHXYDM VARCHAR2 20 企业社会信用代码
QYMC VARCHAR2 300 企业名称
FDDBRXM VARCHAR2 150 法人代表姓名
FDDBRSFZJHM VARCHAR2 30 法人代表身份证件号码
HY_DM VARCHAR2 4 行业代码
ZCDZ VARCHAR2 300 企业注册地址
DJRQ DATE 7 登记日期
XGRQ DATE 7 修改日期
DQ_DM VARCHAR2 12 地区代码

T_DM_HY(行业代码表)

字段 字段类型 字段长度 注释说明
HY_DM VARCHAR2 4 行业代码
HYMC VARCHAR2 68 行业名称

T_DJ_ZRRXX(自然人基本信息)

字段 字段类型 字段长度 注释说明
DJXH NUMBER 20 自然人唯一 ID
XM VARCHAR2 75 姓名
SFZJHM VARCHAR2 20 身份证件号码
CSNF VARCHAR2 8 出生年月
XB_DM CHAR 2 性别代码
DQ_DM CHAR 6 地区代码
XLQK VARCHAR2 10 学历情况
HYZK CHAR 4 行业代码
NSRE NUMBER 0 年收入额
LRRQ DATE 7 录入日期
XGRQ DATE 7 修改日期

T_DM_XB(性别代码表)

字段 字段类型 字段长度 注释说明
XB_DM VARCHAR2 255 性别代码
XBMC VARCHAR2 255 性别名称

T_NSXX(企业 (或自然人)纳税信息)

字段 字段类型 字段长度 注释说明
ZSUUID NUMBER 20 纳税流水 UUID
DJXH VARCHAR2 20 企业或自然人 ID
NSRQ VARCHAR2 300 纳税日期
NSE VARCHAR2 150 纳税额
CJSJ VARCHAR2 30 创建时间
CZLX VARCHAR2 4 创建类型

T_DM_DQ(地区代码表)

字段 字段类型 字段长度 注释说明
DQ_DM CHAR 6 地区代码
DQMC VARCHAR2 150 地区名称

3.2 大致场景:

离线加工部分

1.初始化上面公安局和税务局样例表数据到测试 mysql 数据库。
2.在平台创建组织角色用户账号以及 mysql 外部数据源。
3.将公安局和税务局 mysql 数据通过集成平台接入 hive 贴源。
4.通过标准平台将 T_TY_DJ_ZRRXX(自然人基本信息)中性别代码进行码表标准化处理。
5.通过资产数据模型创建 T_ZT_FDQQYHSTJ(分地区企业户数统计表)。
6.通过离线平台加工数据获取分地区企业户数统计数据写入 T_ZT_FDQQYHSTJ,并通过同步任务将 T_ZT_FDQQYHSTJ 数据下云到 mysql。
7.通过数据质量平台对 T_TY_DJ_QYXX,T_DM_HY,T_TY_DJ_ZRRXX,T_TY_NSXX 全表数据质量检核。
8.通过 API 平台对 T_ZT_FDQQYHSTJ 的数据进行 API 创建。
9.标签平台通过字段映射,mysql 语句,拖拽形式进行标签加工。

实时计算部分

1.实时计算人员数据量变化:准备一个 mysql 存储过程往一个表不停写入数据,然后从 mysql 实时采集到 kafka,运用 flink 实时计算。(实时计算平台完成)

4.自动化实施

4.1 从 0 开始

xx 的一句话:我们需要开始实施自动化了。

1.人力投入

1 人,好吧就我自己,那就干吧!

2.主要目标

首先整理要实现自动化的场景,第一版数据和场景都很随意,自己随便造的测试数据,场景也是之前组织组内同事按照每个人的平台去定一个数据处理的要求,然后每个人各自编写测试步骤,组成的测试场景。定的目标就是就是把每个平台串起来,验证数据流转加工正常,每个平台只验证一个核心流程,确保每个平台间的依 赖,配置正确。

3.工具

工具使用 Httprunner,为啥,因为是同行写的,牛逼!

4.过程

一顿操作,因为还有每个版本的测试任务,前前后后花了将近一个月的时间,把主要流程自动化用例写好了,勉强能跑。为啥勉强能呢?这脚本只有我自己能跑,给别人跑,跑不了。因为脚本,里面的限制太多,比如 env 里面的参数太多了,每次切换环境要改很多参数(要配置外部 mysql,kafka 以及其他的数据源连接信息,要更换平台访问地址,要更改角色配置,要配置很多 hadoop 组件的连接信息,类似很多。。。。。。)。

5.问题

除了运行起来麻烦,还有很多其他问题,比较突出的:

  1. 期间不断重复操作页面点击,charles 抓包,转成脚本,参数化。。。很多重复劳动耗时耗力。
  2. 用例只能一次从头执行到结束,几百个接口,有一个报错,就得从头开始。
  3. 用例执行多轮完后,很多测试数据遗留在上面没有清理。
  4. 用例颗粒度需要细化。

这个过程我觉得最重要的是把自动化场景确定,要求对业务比较熟悉,场景能覆盖到核心流程,明确自动化脚本要干啥,有一个目标;工具适合自己或者团队就行,不必过于纠结;先把核心的流程实现,脚本能跑出东西来才可能有价值,少说多做,这个过程技术上可能坑多些,多百度,多思考,更多的是驱动自己去完成。

#### 4.2 从 0 到 0.5

很多 xx 的话:我们需要好用的自动化。

1.人力投入

3 人,主干的流程实现了,现在多投入 3 个人来维护丰富用例!那就改吧!

2.主要目标:
  1. 减少脚本配置,增加场景业务含义
  2. 编写工具减少重复劳动,提升效率
  3. 优化脚本逻辑
2.工具

开发:主要 drf+vue+httprunner+tornado
管理:主要 git+jenkins+docker

3.过程

因为有同事参与进来,冒烟脚本跟随版本迭代在 git 进行版本控制,集成到 jenkins,构建 docker 镜像,和应用一起进行交付。一部分工作可以安排同事去完成,很大程度减少了工作压力,同事也积极配合,分配的任务都能按计划实施,还是很开心的。

首先增加场景业务含义,之前线上部署,都是开发冒烟,测试验证,产品上去创建给客户演示的场景。那既然自动化也是去跑场景,那就去跑产品创建的那套场景,一举两得。就和产品确定了场景和测试数据,然后拆分转为自动化脚本任务。

减少脚本配置,应用部署都是注册在 nacos 上,用 python 去解析 nacos 获取参数,一些外部组件的参数,也通过 cicd 他们部署后,写入 nacos 去获取,脚本的参数最终只需要配置 nacos 的连接就行。

提升编写效率,最小的开发成本编写了一个在线的 httprunner 编辑器,主要解决 :

  • 提供一个公共脚本运行环境,免去安装脚本运行环境,减少使用成本

  • charles 抓包导出的 har 包转化脚本的时候自动参数化变量

  • 不敲命令,在线调试和查看报告

  • 能上传和导出脚本

  • 多人维护的时候在线合并脚本等

细化用例颗粒度,将脚本按照每个子平台去维护用例,然后每个子平台的用例可以独立执行。

优化脚本逻辑,持久化 extract 参数(重点),如果想每个子平台独立执行,这里面涉及到参数化的传递,extract 传递的变量只能在执行的那个 session 里面使用,但是每个子平台的数据是关联的,比如资产平台新加一个数据源,集成平台就需要这个数据源的 id 和连接的信息。每个平台独立执行的话,单独执行资产创建数据源,然后再执行集成平台无法用 extract 获取变量。解决的办法就是把数据源的 id 和信息持久化到 env 文件里面,数据源的信息就能共享给其他的脚本。就是再 teardown_hooks 将 $respons 里面需要的参数写入到 env 文件里面。后面接口使用变量都从用 ${ENV(xx)}去参数化。

有什么好处呢?你可以调试单个的参数化的 api 接口,接口出错不用重头开始,前面平台接口完成后,后面的平台用例可以从 env 里面读取需要的参数单独重复跑。还能解决每个子平台用例参数的依赖。

解决执行后的遗留数据问题,因为新环境很难保证脚本能一次成功执行,脚本里面新增的接口中涉及命名的都加上一个批次号的变量,避免重复执行的 ‘重复命名’ 报错。多次执行后,就有很多遗留数据。

有 2 种方案:

  • 脚本里面增加删除的接口,之前的接口为正向接口脚本加上 skipif 关键字判断 env 文件里面的变量 skip,teardown_hooks 都加上判断逻辑,判断 $respoen 里面的业务代码是否 200,如果不是 200,就将 env 文件里面的 skip 变量设置成 True,删除接口的脚本加上 unskif 关键字判断 env 文件里面的变量 skip。这样只要正向接口报错,就会跳过剩下正向接口,执行删除接口。保证执行多次只有一个批次的遗留数据,用于演示。

  • 铲库,重置数据库,然后再执行一遍脚本,用于演示(只能适用于新环境部署)。

这个过程技术上的也基本没啥阻碍了,更多的在于沟通,组内组外的推广,这个是落地非常重要的一环,脸皮厚点,只要别人在用了,就算说的再烂,只要有需求反馈,我就很开心,不断完善,可能做的多错的多,但是使每次犯错都有它的价值,都是提升自己的一次机会,自动化可能更多的是去契合外部的需求。

4.2 努力到 1

经过和同事的努力,虽然自己还是觉得很多地方不太好,但是线上确实能产生价值了,自动化也上了迭代流程。最后交由交付的同事去使用,从开发,产品,交付的得到了很多很好的反馈,他们不用再去糟心验证的事了。

当然还有很多东西需要去做,比如使用 mitmproxy 去结合现有工具开发一个在线抓包的工具,能直接勾选接口转化用例。省去使用 charles 工具;继续优化 web 编辑工具,修复 bug;增加 nacos 里面配置项的验证,如 xx 平台需要使用 es 的某个 index,但是部署的时候 es 的 index 没有初始类似的;丰富更多的用例,不单单是冒烟用例。。。

这个过程也发现,工作中的沟通很重要,从自动化场景的确立,脚本的编写方案,组内维护脚本的工作,脚本的推广使用等,技术和能力是很少的一部分,工作中的良好沟通和配合才是一件事情干成的关键。

管理经验需要提升,现在组内每个人都参与自动化的维护了。组里面每个人技术,兴趣可能不一致,目前还是培训全流程业务和技术,增加绩效考核的手段,虽然组内同事都很支持,配合,但是很多工作都是要安排到具体的事情,缺少主动去发现问题的积极性,后面更多的重心放在这上面吧。

后话

上面说的都很粗,想到哪写到哪,这里做个记录,和大家一同进步~

放一些截图
wiki 归档

git 代码

jenkins 构建

新建/导入项目

运行当前 tab 页用例

快捷键:保存所有:Ctrl+S 跳转到 API:鼠标选中 testcases 中 api 关键字中的 api 完整路径,按 Ctrl+Q 跳转跳转到函数方法:鼠标选中脚本中的 python 方法,按 Ctrl+Q 跳转运行:执行当前选中的 tab 页脚本,运行完后,右上角会出现查看报告的按钮关闭全部:关闭所有 tab 页,按 Ctrl+F 搜索替换

运行完出现报告查看按钮,点击进入报告查看

上传 har 包,自动解析生成 yml 用例,自动参数化。

编写 yml 用例能自动提示 debugtalk 和 env 文件里面的函数变量

项目合并,比对查看两个项目间的文件差异,选择文件进行合并

文件的编辑复制删除

共收到 30 条回复 时间 点赞

强。可以请教一下吗?

IEhao 回复

谢谢称赞,您说

请问,请求参数中的数据是自动生成的吗,如何保证生成的数据,是有效的,可以直接作用于流程性接口嘛

liuchang 回复

接口的参数都是上个接口通过 teardown_hooks 中从 $respons 里面需要的参数写入到 env 文件里面。后面接口使用变量都从用 ${ENV(xx)}去参数化。就是直接作用流程性的接口

liuchang 回复

接口的参数都是上个接口通过 teardown_hooks 中从 $respons 里面需要的参数写入到 env 文件里面。后面接口使用变量都从用 ${ENV(xx)}去参数化。就是直接作用流程性的接口

柒意 回复

接口的参数都是上个接口通过 teardown_hooks 中从 $respons 里面需要的参数写入到 env 文件里面。后面接口使用变量都从用 ${ENV(xx)}去参数化。就是直接作用流程性的接口

自动生成的请求参数数据,如何保证用例成功,然后下个接口来用呢

柒意 回复

上个接口成功,才能获取参数,如果上个接口失败,后面的接口就不会跑

liuchang 回复

好吧,谢谢

“比如使用 mitmproxy 去结合现有工具开发一个在线抓包的工具,能直接勾选接口转化用例。”
请问下这方案能详细讲解下么?我目前的接口平台也有此项需求。

JKzhishui 回复


mitmproxy 的 git 上有 har 包抓取的脚本,mitmdump 模式下去解析 flows 用这个脚本,然后通过 httprunner har2case 去转化,页面展示的话 可以参考 mitmweb 模式的 ui 界面。

liuchang 回复

感谢大佬

很强的技术整合和执行力,🐂

liuchang 回复

mitmdump 模式下 flows 的流式数据,里面有请求的所有信息,熟悉下 flows 的结构,可以结合自己的需求获取相应的参数

JKzhishui 回复

这个回复我老回复自己了😂
mitmdump 模式下 flows 的流式数据,里面有请求的所有信息,熟悉下 flows 的结构,可以结合自己的需求获取相应的参数

zailushang 回复

😄 谢谢,还是菜鸟,代码还是流水账的模式 我也是在社区里面向大家学习,看的多了,遇到问题解决得思路就多点。

能落地的方案就是好方案👍

细化用例颗粒度,将脚本按照每个子平台去维护用例,然后每个子平台的用例可以独立执行。

用例颗粒度是什么意思,请教下

zkx 回复

简单来说就是之前所有接口写在一个 case 里面,按照业务和功能拆分细化,让每个用例能独立执行,完成某个小的场景。

厉害的执行力,后面抓包生成用例哪里很用共鸣,不过我是直接 mitmdump 抓包后提取需要的参数去组合成 yaml 文件😂

恒温 将本帖设为了精华贴 03月11日 07:59

业务有点类似,也想自己动手落地接口自动化,可以分享你在这个过程中的一些学习资料吗?谢谢!

moku 回复

这样更好,我是能用现成的就用现成的😂

J.w-XIAO 回复

大部分都是在这个社区看到的,很多没见过的技术知识,自己都会去百度学习下,然后就会发现很多东西是相通的,单就自动化这块,首先自己要多用产品,不非常熟悉业务我感觉是写不出好用的自动化的,技术上用框架不是很难,提升的话就找个项目写轮子,在结合自己业务用到自动化里面。多看多做,多思考准没错,共勉!

已经被社区公众号收录

很多人问我:你写了那么多服务的脚本,你就没想过把它们工具化,做成一个平台吗?我想说的是:依项目性质而定。如果是迭代维护型项目,落地成测试平台是一个必然的结果。如果是定制交付型项目,那么大可不必。但往往领导要看到的是表面化的工作,有个可视化的成果来体现你的量化工作,这就是测试的无奈。真正决定能不能做好一个测试平台的条件= 项目的前景 + 人力的投入 + 时间的允许 + 技术的迭代 + 核心的规划 + 成果的体现。

想问下楼主,我看你这平台有执行步骤的 log 输出到前台,是怎么跟 httprunner 集成的?是用 websocket 后端实时推送吗?

这个干货多,优秀。

Jason Cheng 回复

是的,我是直接调用 httprunner 执行脚本,把 httprunner 的日志通过 websocket 发送给前端。

很有参考价值,最近公司也要搭一个系统,还在思考怎么优化原来的框架。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册