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

  • 时间:
  • 浏览:0

  话又说回来这人工具也是有局限性的,它不关注页面,目前大伙儿儿市面都也有益于只提供接口不可能 API来赚钱的公司毕竟少数,大伙儿儿还时候做产品的出身,毕竟东西是要搞定去卖钱的,那末页面你让客户看那此?你否则什么工具引进项目时候,测试人员那末端到端的打通过产品,还是需用手工在页面上操作,这人工具可是能发现UI和接口未对齐的地方的缺乏。

====================================分割线================================

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

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

最新内容请见作者的GitHub页:http://qaseven.github.io/

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

首先感谢公司,只来了一年,我接触了一种生活 自动化工具,一种生活 是测试接口的,一种生活 是直接从GUI分派的。翻开目前发生的测试资料,也能被企业级应用的自动化工具类型也无非就这人种生活 最好的土土办法,深入接触了时候,其实一种生活 最好的土土办法各有千秋,也各自 也能完成各自 的使命。当然了,这人种生活 工具公司内部开发,也都也能了在内部平台上使用。不过没那此,学习了最好的土土办法和过程,就向看惯了五岳、黄山一样。

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

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

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

  既然这人工具那末好,从前们赶紧开展哦~~~

  测试,你做好设计准备多会儿?

  再者这人工具有有2个多弱点,分析不了逻辑,不可能 有2个多页面需用逻辑展示不可能 时下最流行的图形操作,这人自动化甜得鞭长莫及,这人分析也能根本都也能了胜任的,测试人员你还是老老实实的各自 构造条件手工测试吧!

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

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

  接口测试工具:首先这人最好的土土办法测试人员各自 就都也能编写工具,开发人员有一套编码规范,在设计阶段就会提供北向不可能 南向接口,每个迭代会发布接口属性列表,告诉前端页面开发,大伙儿儿的这人为什么我么我调用。一般项目比较大其他时,前期时候需用先将后台稳定,过有2个多迭代才将页面集成进来。从前在那末页面的情况表下,测试人员都也能了根据手工测试,需用各自 给接口传参数来测试结果。测试人员在用例撰写完成后,就需用编写脚本了,不可能 在那末页面的情况表下,大伙儿儿的测试执行就全靠它了。