接口测试 关于接口自动化的一些疑惑 (必看)!!

江楷 · 2019年02月21日 · 最后由 ToBeBetter 回复于 2024年09月10日 · 11602 次阅读

本文就接口自动化中的一些技术难点及接口自动化的意义做一些探讨,请耐心看完,或许有不小的收获

首先,针对本人从事的项目情况做一些介绍,一套类似电商的系统

团购业务系统(类似淘宝)、CRM(客户关系管理系统)、OMS(订单管理系统)、WMS(仓库管理系统)、TMS(物流管理系统),这五个系统存在一个承接关系,数据在五个系统进行流转,如一笔订单系统,现在团购系统生成,流转到 OMS 系统进行订单分发,再到 WMS 系统进行订单入库,配货生成运单等,最后到 TMS 系统进行运单处理,团购系统的一些基础数据是在 CRM 系统进行配置,如产品管理、用户管理等等

现在针对这一整套流程,考虑实现自动化,目前遇到的难点如下:

  • 项目流程过程,造数据困难
    目前尝试过几种方式去生成测试数据:
    1.前端造数据(笑笑就好)
    2.通过 jmeter 造数据:这种方式看似有效,实际由于项目流程过长,写脚本的难度很大,造一条运单数据要调用 30 多个,存在于不同系统的接口,光是写接口关联就很头疼了,况且脚本执行的效率也不是很高,唯一的优点就在于,数据能真实可用
    3.利用存储过程直接往数据库插数据:目前仅仅是一个想法,看到几十张或者更多表的关联,我选择了放弃,开发都不一定清楚的,我怎么会知道 = - =

  • 接口文档不规范,接口场景缺失
    1.就目前来说,本人基本不看公司的接口文档,无力吐槽,全都是自己先理流程再一个个抓包去看,各个接口间的逻辑关系也靠自己去猜,效率很慢。
    2.接口本身的场景存在缺失,后端很多接口并未做校验,全靠前端限制,EXCUSE ME??那我还做啥接口测试,连传个异常类型的字符串都不限制,后端直接返回框架原生的报错给我了,这让我思考针对目前的接口开发情况,到底要不要去测试异常场景
    3.本身接口开发存在问题,enum 写的少,场景少,又存在大量的接口数据依赖,那该如何统计场景的覆盖率,又以什么指标来衡量我们自动化的成效?

  • 接口用例的维护成本过大
    1.目前我们接口用例是写在 excel,一条一条传给框架去遍历执行的,ps:谁告诉我写 excel 好用的,虽然写代码麻烦,但是写 excel 写的眼睛疼
    2.基于流程的测试,按照 excel 顺序读取下来,流程和流程间很难区分出来,测试报告里仅仅是以列表的形式展示测试的结果,一旦流程间的某个接口出现错误,后续的接口会批量报错(可能是因为本人框架设计的不好导致的,请大佬们指点),但是说实话,本人并不觉得自动化框架是个好用的东西,它只不过是一个能快速实现自动化的解决方案而已,真正能解决问题的,还是一个功能强大的测试平台。

    测试用例

用例结果展示



3.自己只能维护自己的用例,你让我去维护别人的!做梦!就算想维护,我也看不懂啊!
4.自动化的数据准备,占用用例的很大一部分,如我需要下单,首先我必须创建一个团购用户,而且团购项目里要有产品,产品又是在合作方下面的,那么好,我去 CRM 把合作方和产品加好,注册一个团购用户....等等,等做了一堆事情后发现,我是要测试啊!我的测试用例呢?花了那么多时间写在了造数据的脚本上面!(有的人可能会问为什么要准备数据,你系统数据被清了,脚本不是白写了?到时候哭都来不及啦!)

  • 接口自动化的价值没有体现

1.功能测试不信自动化:虽然说现在都是敏捷流程,靠人工去点肯定是来不及的,回归得靠自动化,但是有了自动化就不用点了吗?测了接口,就算正确了,还不是要前端去回归一下,毕竟接口是看不见莫不着的,不懂技术的功能测试肯定不信这一套
2.自动化投入少,无人支持:单单靠我们(自动化团队 2 人)写用例肯定是不全的,又得熟悉多个系统,又要花时间理清接口间的逻辑关系,靠我们俩效率肯定是很低的。那好吧,我们把这一部分交接出去,让功能测试也开始写接口用例。好了又出现一堆问题:功能测试人员水平有限(http 协议、接口是啥都不懂)、功能测试不相信自动化,并且会觉得增加了他们的工作量(编写用例,维护用例)...这让我思考自动化的意义何在,我们自动化不是为了减少手工吗?为什么反而给功能测试增加了工作量?这就违背了自动化测试的初衷
3.自动化测试出 Bug 少:由于自动化场景覆盖率低下,用例数少(仅靠两人编写),确实难以测试出 Bug,就算能测出来基本也只是环境崩了之类的。。全是通过的自动化是不存在任何意义和价值的!!说到这里就越发怀疑自己的价值,懂那么多技术,为何还无法提升自动化的质量和效率?问题到底出在哪里??或许当所有测试都拥有自动化测试的能力了,才能做好自动化吧...

说到这里,都是一把辛酸泪啊!
到底自动化如何才能做好?如何才能让自动化真正的产出成果?如何真正的为苦逼的功能测试们减负?
这可能是目前做自动化测试的各位大佬们一个共同的疑问吧
这个问题的答案或许会在不久的未来,有人为我们解答!

共收到 38 条回复 时间 点赞

脚本读取 excel 用户批量造数据,先把新建用户这一过程自动化

个人想法,说错勿怪,自动化框架还是有用的,只是看框架的设计本身。框架设计包含了设计者对自动化测试认知,如何使框架在技术上符合大多数测试场景,设计上规避掉自动化测试的主要风险,使用上降低使用者的入门难易度、增强团队协作和易用性,是否有设计者对框架使用规范上做出建议等等。出发点都是提升自动化的优势,降低自动化的劣势,平台化能好用,是因为它本身集各个数据于一身,在做数据关联和数据统计时,会更加有优势,但底层运行依然是以自动化框架为基础。不是框架不好,而是要考虑是否框架已足够好。

共鸣啊,和我当前的状况一样,自动化团队也就 2 人,还时不时被抽走去测功能。😂
之前测试经理要我们先搞 UI 自动化,好了,框架脚本啥啥啥写好了,3 个月后才意识到版本迭代太快界面经常改变,维护成本太大,就放弃了😓
后来转战弄接口自动化,也同样的接口文档完完全全不能入目,只能靠自己抓包分析和开发交流解决,心酸啊。
好了,现在连测试经理也跑了,剩下我们在这苦苦挣扎。😂

顶一下//同样的困境/希望大佬提提建议

testlover 回复

你说的都对,但是……但是……但是你说的还是都对😂
完美自动化测试三观~高度赞同!

testlover 回复

第一条有些不赞同/功能测试用例不可能全部变现成自动化测试用例/自动化测试用例要求简单,目的明确/覆盖增删改查/
一味的贪多/导致后面维护更加困难

独缺 回复

说明我的自动化框架还是不够完善导致的这些问题,受教了

江楷 #10 · 2019年02月22日 Author
陈恒捷 回复

多谢大神指点,我们部分观点是一致的,我觉得公司领导本身不了解自动化也是一个重要的原因,我曾多次跟领导提出 “” 后端未做校验,做场景的覆盖测试是毫无意义的!!“,目前应该做的应该是规范后端的一个接口开发和相关文档后,再考虑异常的一些场景覆盖,从而实现自动化!!

江楷 #11 · 2019年02月22日 Author
膨化先生 回复

我们现在有部分数据是通过 jmeter 去并发造出来的,但是某些数据,如订单、运单的数据就很难造,因为流程过长导致脚本执行的效率低,这是现在的一个问题

江楷 #12 · 2019年02月22日 Author
柠檬 回复

估计好多人都是一样的困境吧!!😭 😭 😭

江楷 #13 · 2019年02月22日 Author
testlover 回复

感谢大佬指点迷津,观点很赞!

testerYZ 回复

我并没有说 要全部实现自动化 自动化的目标应该是测试场景的自动化 而不是针对接口或者某个功能的自动化 只能说借助某个接口(接口自动化)或者某个功能(UI 自动化)达到场景覆盖的目的 自动化实现有成本 但是因为接口相对更稳定些 所以实现起来效果更好 性价比更高 UI 变动更频繁 执行效果差 性价比低 要不要把某些场景自动化 得综合考虑 业务重要程度 测试资源 执行频率 和实现难度

testlover 回复

非常赞同。

管理好自动化的投入和产出的预期。

testlover 回复

理解//主要还是场景

江楷 回复

难造的数据,使用自动化来做,我认为正合适。调用接口 30 多个,订单、运单,应该还会有不同身份用户的操作,页面上操作简直就是灾难
脚本的执行效率低?可以看看在哪些接口上出现了问题,找一下原因

个人观点:自动化测试开发应该独立于业务之外来设计工具。让业务测试人员可以与代码剥离,他们来设计接口用例的参数。参数化,非空遍历,sql 注入等这些通用功能可以封装成功能开关,而工具设计者本身应当着眼于可以提升设计效率,降低难度。

建议写业务接口测试,不要使用这种数据固定的用例,维护成本很高;
业务接口测试,所有的数据都从接口或数据库里面拿,拿已经有的数据;

在上家公司,被招进来搞自动化,进来之后发现版本迭代速度太快,每周至少俩版本,就决定暂时先只做接口的,然后也是各种文档不规范,说错了,是各种文档缺失,然后就自己去找人挨个的了解业务,抓包……终于框架搭好了,重点场景的用例写好了,然后领导觉得自动化这玩意好像没啥用,也就批量产生数据这块有点价值,让我以后先全职去搞功能,自动化先放放。部门自动化就我一人,自动化这东西本来就不是那么好推广起来的,也需要领导有魄力才行,好吧,我走,走人还不行嘛……

柠檬 回复

同感,部门中只有我一个搞自动化,各种文档缺失,自己搭框架,抓包写用例。东西搞差不多了,领导觉得这玩意没啥用,让我去做功能,唉……郁闷啊

江楷 #17 · 2019年03月06日 Author
袁俊磊 回复

兄弟我们差不多啊,苦逼

柠檬 回复

哈哈,惨

柠檬 回复

大佬,握手,感同身受啊

我不会服输的,我要搞好接口自动化啊!

同款 report

槽神 回复

哈哈哈哈哈哈

Bensir 回复

ExtentReport 😆

陈恒捷 回复

谢谢大佬指点!
从造数据开始,然后加断言复用,直接变成接口自动化。

我觉得自动化 没有必要做全流程吧 做关键的部分 要不然不得累死

柠檬 回复

你们测试经理,平时做些什么工作

testerYZ 回复

testlover 的功能测试用例和自动化测试用例不分开的观点(第一条)我认同,你说的功能测试用例不可能全部自动化实现的观点我也认同,你俩本身就是不同的观点,都对!
质量管理系统里只有测试用例一说,通常测试用例默认的执行方式是手工,可以在 “是否自动化执行” 一项里改为 “是”。
自动化不可能实现所有的测试用例,这是基于多方面的考虑,有的用例本身就不适合自动化比如需要物理动作参与完成,有的用例自动化实现成本过高也需要做出取舍。

花落去 回复

拿已经有的数据?如果没有数据是不是这个用例就没得跑?自动化测试的覆盖度怎么保证呢?

造数据没必要通过业务接口去造,可以通过调用较底层的 service 造数据,一般都是可以将流程简化的。

较底层的 service 造数据能单独抽离出来做成服务吗?兄弟

NotBBB 回复

当然是可以啊,你按自己的需求包一层,暴露个接口出来就行了。

兔子🐰 自动化测试合辑 中提及了此贴 02月18日 12:30
花落去 回复

有利有弊,已有数据被人修改,数据状态不对可能导致用例不稳定。根据情况来吧。

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