SoapUI测试接口工具有哪些弊端？盘点它的优缺点

我司是从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文件里面进行读取以及将传入的参数单独写文件等等。尝试一下，你会体会到自己写代码所带来的自由自在，不再受接口工具的束缚。