测试基础 金融复杂场景自动化最佳实践!

花菜 · 2024年05月09日 · 最后由 回复于 2024年06月13日 · 10347 次阅读

背景

目前公司使用开源 MeterSphere(下面简称 ms) 做接口自动化平台

在使用 ms 的过程中存在以下致命问题:

  • 缺少变量追踪!导致用例调试,问题排查非常麻烦,压根不知道变量从哪里来,在哪里被赋值,实在令人抓狂!简直就是变量引用地狱!
  • 卡顿严重!金融产品用例很复杂,一个用例中引用 20 个场景用例,总步骤数量超过 100 步,编辑用例时,浏览器的标签页内存使用高达 1GB!!!简直是吃内存狂魔。另外,点击保存用例,哪怕什么都不改,响应时间也会超过 10s,我不禁问,这真是 21 世纪产品的吗?
  • image-20240508000223300

当然,ms 还有其他很各种问题,但不是致命的,我就不一一列举。

问题分析

首先,场景是不是真的那么复杂,是真的。

能重新造一个平台来替换 ms 吗?能,但成本太大,新开发的也不一定就比 ms 好用,并且 ms 上面现存的场景用例已经上千个,迁移也是很大的成本。

又或者说,用纯代码来编写自动化,这样就不需要在页面上调试那么蛋疼,也不存在保存响应慢的问题。

这个在团队小,并且人员都有 coding 能力时可以采用。目前我们团队人员能力参差不齐,有 coding 能力的并不是很多,并且大家技术栈也不一样,Java 和 Python 都有,

经过深入分析以及和部分同学沟通后,采用了一种比较折中的方案:接口聚合。

方案设计

什么是接口聚合,顾名思义,就是把多个接口聚合起来。

举例子来说,在贷款的过程中,有用户授信合同签约的节点,需要经过以下步骤:

  • 1、获取用户唯一编码,手机号
  • 2、获取合同唯一编码
  • 3、调用获取短信验证码
  • 4、执行 sql,把验证码从数据库中捞出来
  • 5、提交签约合同接口(入参包含:用户唯一编码,手机号,合同唯一编码,短信验证码)

在 ms 上,要完成这个节点,就需要写 5 个步骤

这 5 步中,涉及到以下变量:

  • 第一步,抽取用户唯一编号和手机号
  • 第二步,抽取合同唯一编码
  • 第三步,引用第一步的手机号
  • 第四步,引用第一步的手机号
  • 第五步,引用第一步的合同编号,手机号,第二部的合同唯一编码,第四步的验证码

如果单纯这 5 个步骤来看,也没多复杂,完全不需要什么变量追踪之类的。

但如果有 20 个这样的节点,或者说一个节点步骤可能会高达 10 步,甚至更多时,情况就会变得很不一样。

既然业务本身就是这么复杂,无法改变。

那么我们能做的就是化繁为简,把这 5 个步骤合并到一个接口来实现。

我们自己开发一个接口,把这个节点需要的步骤全部操作完,那么在页面上,就只需要调用一个步骤即可!

这样做带来以下好处:

  • 大幅度减少在 ms 上的步骤数量,避免找不到变量在哪里来,在哪里赋值的问题
  • ms 在前端的步骤数量少了,接口保存时,就不会有那么大的数据量,速度也就会更快;浏览器便签内存也不会暴涨
  • 接口聚合这种方式,是直接 IDE 上调试代码,变量跳转这种基础操作,太轻松了。

总结

接口聚合这个方案目前能很好的解决了现阶段的问题,但这就是最好的方案吗? 我认为是的。

优点:

  • 大幅度缩短用例步骤,使 ms 页面不在卡顿,变量引用地狱也可以大幅减轻
  • 直接在 IDE debug,实际效率更高

当然任何方案都会存在缺点,接口聚合也不例外。

  • 接口聚合需要一定的代码能力,对代码能力薄弱的同学不友好
  • 编写接口聚合前期耗时,表面上可能会比直接在 ms 上拖拉拽时间更长
  • 修改没有直接在 ms 上来得快

公众号原文

关注公众号,加入千人纯技术交流群,拒绝闲聊😀

共收到 26 条回复 时间 点赞
花菜 #23 · 2024年05月10日 Author

天下苦 ms 久已,希望这篇文章能给遭受痛苦的朋友们一点点启发~~

如果是接口聚合里面的某个步骤出错了,那排查岂不是还要到 ide 工具打开代码查看?

毕竟是开源免费,要求不能太高

花菜 回复

也可能是我吃不来细糠,ms 用起来很僵硬😂

我觉得可以使用 AI 来编写聚合的接口,这样就能解决测试人员能力不足的问题。再就是我在使用 apifox 的时候,有全局变量。环境区分的也很清楚 还能同步 缺点就是要收费,免费的团队 人员数量有限

“我们自己开发一个接口,把这个节点需要的步骤全部操作完”

我理解就是搭一个接口服务把上面的步骤都在一个脚本里做完,然后 ms 再去请求这个接口................. 听起来就像是接口自动化一样,用 ms 主要是为了无码操作,这是很多人追求的平台化,现在是走复古路线了吗

[有 coding 能力的并不是很多] 这个问题解决了就没这些乱七八糟平台的事了,感觉这些平台总是默认测试不会写代码。。。

jackye 回复

不止这个问题,一个接口聚合了多个步骤,如果其中某个步骤的执行时间较长,导致整个接口的响应时间增加,在 ms 上无法看到是哪一步出问题,得去看脚本日志判断哪个时间是比较长的。还有执行测试用例时,由于一个接口都是封装了多个步骤可能会导致某些接口被频繁调用😁

jackye 回复

不用,聚合接口会返回所有执行过程的 log,直接在 log 中看

花菜 #10 · 2024年05月10日 Author

这个问题好解决,在聚合接口,能统计到每个接口的执行时间,以及执行日志,统一返回

花菜 #11 · 2024年05月10日 Author

跟纯代码自动化不一样,这里只是对复杂场景统一封装,类似于 UI 的 PO 模式

花菜 #12 · 2024年05月10日 Author
悲伤蛙 回复

正是考虑到这点,才会这么做。有 coding 能力的封装好聚合的接口,其他没有 coding 能力的同学直接用即可。

花菜 #13 · 2024年05月10日 Author
Bzzb 回复

有在用 GPT 辅助,把接口录制下面,通过自定义提示词,能生成对应格式的单个接口。
但还是需要人工合并一下,没时间调试提示词

还是 ms 架构设计的问题

花菜 回复

Codes 有调用链 没这问题

且支持 拖拉编排 场景

codes 回复

接口有 beanshell,python 代码设置环境变量能推断出来吗

花菜 回复

beanShell 目前不支持 ,后续要支持,Py 只要接口的形式存式 就能推断

codes 回复

不是接口形式,都是脚本形式设置变量

你这样的话,就是按场景进行了步骤封装?聚合接口里还包含项目本身的接口,那项目接口和聚合接口一旦要更改,进行维护,不麻烦吗,而且这样还多了个写聚合接口的工作量

一日之纪 回复

难道直接在 ms 上写用例,接口改动了不需要维护?不麻烦吗?

而且?在 ms 上面调试用例是什么体验?你知道吗?

花菜 回复

这不叫苦,直接不用不就好了,又不是独一份。我司也在用,这个东西诞生的时候就已经落后了,不明白存在的意义是啥。

悲伤蛙 回复

对,低代码,里边写几行脚本还贼难用。

为了平台而平台,不如直接提升测试人员的代码水平性价比高。

藕片 回复

团队中,已经用起来了,作为一个后来的人。大概率还是要在 shi 上雕花。

推倒重新来,短时间内,自研是不现实的,领导也不会给这个成本去做😭

这个东西倒也不是说完全没有用处,对于业务不复杂,代码能力差的团队,还是不错的。

花菜 回复

赞同楼主的说法,面对短时间不能改动的屎山,的确这种做法是比较合适的

公司自动化非要用 MS,我真的痛苦至极,我觉得 RF+python 挺好的

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