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

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

背景

目前公司使用开源 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 条回复 时间 点赞

天下苦 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 有调用链 没这问题

且支持 拖拉编排 场景

花菜 #16 · 2024年05月11日 Author
codes 回复

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

花菜 回复

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

花菜 #18 · 2024年05月13日 Author
codes 回复

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

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

花菜 #20 · 2024年05月15日 Author
一日之纪 回复

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

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

花菜 回复

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

悲伤蛙 回复

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

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

藕片 回复

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

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

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

花菜 回复

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

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

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