Warning: in_array() expects parameter 2 to be array, null given in /home/wwwroot/www.wanzhanqun.com/apps/frontend/models/Article_Data.php on line 137

手把手教你摆脱接口工具束缚

发布时间:2019-09-07   来源:体育快报   

更多精彩,请我们!

  我司是从2013年开始做接口自动化,那时候选用了测试接口工具--SoapUI。当时觉得非常好用,简单易上手,即使是代码小白,也能通过几次培训课,上手该工具。非常适用于代码基础薄弱,仅仅懂得业务的测试团队。

  随着业务的发展,一个项目的接口从几十个扩大到几百个,继续使用接口工具,无疑对后期脚本的维护产生了非常大的工作量。虽然说提供界面化管理,让做接口变的简单,但是却因为无法做接口分离,导致代码耦合性太高,大家都不愿意去维护老的接口。出现了老接口的case因为调试不通,而被无情删除的情况出现。

  事实上,只要接口仍然被软件调用的情况下,无论是老接口还是新接口。我们都是不能随意删除的。不然所谓的可持续集成,也就没有意义了。对于我来说,既然接口做了自动化,就必须是100%全覆盖。这样我才对服务器的正确性,胸有成竹。发布前以及发布后,动动手指轻点一键跑一下接口自动化,短短几分钟内就能知道发布是否宣成功。

  那么接口工具到底有哪些弊端,想让我摆脱它的束缚呢?接下来就来盘点下它的弱点。

  用过SoapUI的伙伴,可能遇到过这样的情况,比如case一多,文件一大,就出现out of memory的情况。如果接口改了,那就要到非常多的case里面去找这个接口,如果多个case调用到的话,我们还要一一做调整和修改。还有在想复用断言代码的时候,为了隔离环境,想在容器里面跑的时候.......工具的一些弊端就体现出来了。

  假如说测试团队的小伙伴有一些代码基础了,强烈建议用python去写接口自动化,当然用其他语言也ok。Python相对学起来更简单,上手更容易,代码量也少。很适合想要将接口工具切换到代码来管理和维护自动化的团队。

  当然如果想通过代码方式去实现接口自动化,就要很好的去做代码层级的规划。如果揉在一起的代码,无疑也是不可维护的,与其这样还不如用接口测试工具来管理。所以考虑接口分层必不可少。

  如何做到分层?就要从接口的构成开始分。接口组成要素1)url 2)请求体 3)响应。所以我们就可以创建3个文件。首先是创建管理接口url的文件,然后是创建管理请求参数的文件,最后就是创建管理响应的文件。

  举个例子:

  这段代码是我们把整个url,请求参数,断言都是揉在一起的一个用例。接下来我们进行拆分。

  拆分一:

  通过一个interface的文件,将url以及接口的请求method来进行封装,并返回response。

  拆分二:

  通过一个reqParam的文件来管理请求的参数

  拆分三:

  通过一个respCom的文件来管理返回的响应

  这个时候我们其实可以在interface这个文件中,进行一些改造,将return的响应结果通过resp_base再包一层,变成如下

  写case:

  这下有了接口必要的部件后,我们就可以开始写case,将这些部件整合,case看起来更加简洁。

  从代码量和文件数量上来说,由于这样的拆分貌似是多了很多,但是对于后期维护来说确实是非常的清晰,比如说接口改了一个url的地址时,大家就不再需要去看case,只需要修改interface里面该接口的url即可。请求参数如果是一个非常复杂的dict时,通过这种写法,case仍然只有了了几句。如果不拆,那么case里面将是一大段一大段的dict,无论是修改和阅读都是非常费劲的。

  当然上面的拆分还不是最细的,我们还可以将断言封装,将请求method封装,将url主域名放到一个config文件里面进行读取以及将传入的参数单独写文件等等。

  尝试一下,你会体会到自己写代码所带来的自由自在,不再受接口工具的束缚。

本文选自本文选自《51测试天地》第五十一期

更多精彩,点击下方“阅读原文”查看。