多测师是一家拥有先进的教学理念,强大的师资团队,业内好评甚多的接口自动化测试培训机构!

17727591462

联系电话

您现在所在位置:接口自动化测试培训 > 新闻资讯

接口自动化和GUI自动化工具优劣比较

更新时间:2022-03-04 09:31:41 作者:多测师 浏览:158

  首先感谢公司,只来了一年,我接触了两种自动化工具,一种是测试接口的,一种是直接从GUI下发的。翻开目前存在的测试资料,能够被企业级应用的自动化工具类型也无非就这两种方式,深入接触了之后,觉得两种方式各有千秋,也各自能够完成自己的使命。当然了,这两种工具公司内部开发,也只能在内部平台上使用。不过没什么,学习了方法和过程,就向看惯了五岳、黄山一样。

  接口测试工具:首先这种方式测试人员自己就可以编写工具,开发人员有一套编码规范,在设计阶段就会提供北向或者南向接口,每个迭代会发布接口属性列表,告诉前端页面开发,我们的这个怎么调用。一般项目比较大一点时,前期都是需要先将后台稳定,过两个迭代才将页面集成进来。可是在没有页面的情况下,测试人员不能根据手工测试,需要自己给接口传参数来测试结果。测试人员在用例撰写完成后,就需要编写脚本了,因为在没有页面的情况下,我们的测试执行就全靠它了。

  简单的举下例子,我们的增删改查对象基本上是每个系统都会有的。那么我们如何去测试这个接口?其实我们在写自动化脚本的时候需要考虑的东西很多,不过核心的只有那么几点,一是要稳定,二是要可重用。我们的脚本和代码一样,我们在写增加对象的时候需要编写一个逻辑,逻辑中调用开发提供的接口,参数值在我们写具体用例时给予传入,例如边界值等等。整个增加功能我们只需要一个逻辑就可以搞定,节省了时间,脚本还不容易出错,后期即使接口变了,我们只需要改一下逻辑,所有的脚本还是可以正常运行了。这个和编码规范一样,通用的东西写在一个方法里,方便扩展和修改。可以想象一下把restclient做成可以连跑的工具。

  下面简单谈谈这种接口测试的适用范围和优势,接口测试更好的适应在中间件开发团队以及更页面弱相关的项目中,首先我们不需要关心页面实现是个什么样子,我们只提供接口,我们关心的接口能否正确的接纳信息并给予正确的返回,其实我们现在还没有页面来调用我们,连我们自己都不知道页面长什么样子,但是我们要保证页面集成之后我们的接口是没有问题的。对于测试人员的角度来看,这种工具有很多好处,一是逻辑抽象化容易,其基本上和写单元测试用例类型,只不过测试对象不是一个函数或者类,是一个功能点罢了,二是这种工具写好的脚本稳定性很高,不受页面变化的影响,后台接口的变更频率比前端页面小的多。

接口自动化和GUI自动化工具优劣比较

  话又说回来这种工具也是有局限性的,它不关注页面,目前我们市面上能够只提供接口或者API来赚钱的公司毕竟少数,大家还都是做产品的出身,毕竟东西是要拿出去卖钱的,没有页面你让客户看什么?而且这种工具引进项目之后,测试人员没有端到端的打通过产品,还是需要手工在页面上操作,这个工具也不能发现UI和接口未对齐的地方的缺陷。

  那么下面的一种工具就能够满足要求了,那就是GUI的自动化工具,它能直接模拟测试人员触发功能按钮,端到端的测试交付的功能,我们常见的QTP也是属于这一类的。不过这种自动化工具也是有其长处和短处的,具体如何取舍呢?

  下面我们来谈谈时下应用最多的自动化类型工具--GUI类型的自动化工具。

  图形用户接口类型的工具,顾名思义,是从页面直接触发命令,完成测试人员手动执行的步骤。相当与一个不需要休息不需要拿薪水的测试人员,每天孜孜不倦的干着重复的事情,却没有任何抱怨一样。不管是我们的QTP还是公司内部自己开发的自动化工具,无非就是先寻找页面上的ID信息或者脚本定位信息或者XPath信息,定位到某一个按钮或者输入框,点击或者输入测试内容,提交后校验页面能够给予的返回信息,不同的脚本传递不同的参数或者点击不同的按钮,校验最后的输出也好,校验页面的错误提示信息也罢,都是以工具替代人工来执行,例如我们可以编写某个系统的门槛用例、冒烟用例的自动化脚本,在开发人员使用自动编译工具生成最新版本的时候,我们自动获取最新版本执行安装,之后执行自动化脚本,在夜里、第一时间掌握版本的实际信息,是否能够转测试成功,是否存在主干流程上不通的情况,如果附带录像回放工具,那这个工具还能帮助开发人员还原当时错误的情况让开发人员“穿越”到之前的情况查看页面出现的BUG,一举多得。

  既然这种工具这么好,那我们赶紧开展哦~~~

  熟练的测试人员都知道这种工具有个很不好的弱点。这种工具过分依赖页面,可以说页面一旦有个风吹草动这个工具生成的脚本就需要更改;一般情况下展开测试自动化都是在项目的后期,基本功能已经无大碍,连续测试过几轮都没有问题,页面也渐渐趋于稳定。所以,采用这种形式的自动化时,测试人员需要做的首件事情就是和开发的SE确定页面和页面控件的ID。其实这些东西我就在这里说说,这个东西实现起来,推动起来是多么难最后还是要修改,被这个脚本折腾吃过苦头的事还历历在目。其实项目开始的时候,领导一声令下要使用GUI工具自动化时就想到这一点,结果就是迭代一推动到迭代二,在推到迭代四,一直到最后要自动化了,下了最后通牒时才给出一个结果。不是开发的SE故意敷衍你,就算迭代一他费好大的劲搞好了又能怎么样呢?众所周知页面这个东西,都是仁者见仁智者见智,更不用资料和UCD的那一帮子整天觉得这个不爽那个不顺眼的,我不是诋毁他们哈,只是觉得页面这个东西,定的太死后面吃亏的是我们自己,包括测试和开发。即便如此,我们实现了自动化,还是给修改带来了很大的工作量。很难保证开发在某一个迭代页面没有动一点东西,只能祈求不要动主干或者不要添加什么ID或者打乱原来的XPath(有些东西开发是没办法给出ID的)。

  再者这个工具有一个弱点,分析不了逻辑,如果一个页面需要逻辑展示或者时下最流行的图形操作,这个自动化真是鞭长莫及,这个分析能够根本不能胜任的,测试人员你还是老老实实的自己构造条件手工测试吧!

  看到了吧,过分依赖页面的自动化工具的下场了吧。

  但是我们不能因噎废食,自动化工具如果不能提高我们的测试效率,那我们凭什么花那么大力气去定规范和写脚本?自动化工具,不管是接口的还是GUI的,其能够存在都是有其道理的。一般情况下接口是不会随便动的开发人员也害怕领导找他的麻烦,改动接口还得联调,又是一个大工作量,所有接口自动化工具生成的脚本稳定,可执行程度高,基本不会出错,如果里面存在缺陷可以很大程度上能够校验出来,缺点是不能结合页面不知道最后集成后会有什么问题;GUI类型的工具强大的地方在端到端的验证,能够像人一样操作被测系统,给测试人员最好的结论,缺点就是维护成本高,易变更(这一点高手测试人员可以尽量减少)。此处比较罗列,想让使用自动化的项目组有个参考,看哪一点舍弃损失最少或者采用哪种收益和成本最大。其实说了这么多,其实自动化工具再好也替代不了人,自动化脚本跑动的脚本依赖用例,用例设计依赖测试人员,用例才是测试根本!

  以上内容为大家介绍了接口自动化和GUI自动化工具优劣比较,希望对大家有所帮助,如果想要了解更多接口自动化测试相关知识,请关注多测师。https://www.aichudan.com/xwzx/


联系电话

17727591462

返回顶部