当下有很多软件公司已经开始做接口自动化，也有很多还没有开始。准备开始做的测试Leader可能会有些困惑，怎么着手去做？下面就从我接触接口测试到部门内多个项目使用并持续集成的一些经验做个简单的介绍。
三年前，我们部门一直是手工测试，也没觉得不好，但是有一件事情触动了我。软件不断更新迭代后，我们要花很多力气去维护不同的版本。有时候在一个新迭代中修改了一个接口，后端程序就会要求我们去把各个老版本和这个接口相关的功能都去测试一遍，工作量相当大，有的时候数据库版本升级了，或者tomcat版本升级了，后端程序又来句："你们把每个和服务器相关的功能都点一遍，我们也不知道哪里会有问题。"这着实让我崩溃。
我就琢磨着，这样搞下去，正儿八经的新功能反而没时间测试了。就想着如果能做接口持续集成的话，不就可以解决这个痛苦了吗？于是就去网上搜索，找到一篇介绍SoapUI工具的文章，豁然开朗，就暗下决心要把这个事情搞成。现在想想正是因为这个痛点，让我学习SoapUI干劲十足。其实学习过程还是有点难度(对于我这样没有代码基础的人来说)，本来以为只是学习下工具，后来才发现除了工具本身的功能外，Groovy，xpath等都要去额外补充知识。
学习SoapUI最好的方式就是看官网，其实学其他的也是一样，看官网比你在一个qq群里面抛出一个问题等待人家解决要强很多，不过官网是英文的，所以也是考验你英文水平的时候。或者找些视频来学习，进度会快很多。当然在选SoapUI工具的时候，也有人建议我直接用Python做，不过对于团队整体自动化水平不高的情况下，无疑SoapUI更好上手。
我先在一个接口相对来说不太多的项目做了试点（整个项目30多个接口），把所有的接口都做成和业务场景相关的Case，过程还是比较顺利的，除了SoapUI经常会出现out of memory的问题，导致脚本经常忘记保存就白做了。基于已实现的接口做SoapUI还是比较容易，开着客户端，通过抓包工具，比如fiddler或者httpdebugger，把接口的wsdl/wadl得到，然后照着写请求就行，这个也是熟悉工具的一个很好的过程。
项目持续开发，新增的接口也越来越多，单接口测试用SoapUI，我们还可以做到分层测试。大多数前端开发和后端开发的研发节点往往是不同步的，我们这儿就出现了一个问题，就是往往后端开发的接口先完成，等前端来调用的时候，前端开发就开始发飙、骂人，对接总是不顺利，要不就是压根调不通，要不就是少返回参数，一来二去对接时间完成节点都会往后调整，整个项目进度就延迟了。如果我能提前把接口先测试通，这样客户端再来调用，就很顺利了。于是我就要求程序提供接口文档，文档有哪些要求，还专门写了一个标准和程序一起讨论完成。然后每次还介入接口方案评审，接口这块的问题就变的越来越少。前端程序对测试做这块工作大加赞赏。而测试提前介入接口测试，后期还可以把单接口做回归和接口Case，一举多得，这感觉倍儿爽。
由于积累了接口测试经验后，就在部门里面开班培训SoapUI，有的人把这个学工具当作任务，有的人还有些抵触心理，但是我坚信一点，当大家感受到做接口测试的好处时，热情就会来，事实证明是这样的，现在我们每个项目组都在做接口，而且大家都很乐意去做。因为做这个事是给大家节约时间，而不是耗费时间。
当接口测试渐入佳境时，问题又来了，如果是一个人做接口测试，那还容易，如果是多个人一起做同一个项目的不同接口测试，那么参数的规范化，以及用例的合理划分以及多人协作提交脚本就会有问题。我会把经常要变的参数放到Global，好处就是我不用打开脚本去改参数，比如服务区的访问的地址，由于我们是通过docker部署服务器环境，所以访问的ip都会是动态变的，所以我会把IP提取出来放到Global里面参数化，这个本身没有问题，但是对于同一个参数的Global命名每个人都不一样，有的人命名ip，有的人命名URL，这就导致维护Global的成本很高。于是我又出了一份接口测试设计规范，大家就按照这个规范做，就避免这些问题。最开始一个人做接口时，脚本就放在本地，多人时脚本就保存到SVN,脚本越来越多，可以不同人去执行时，就通过Teamcity来运行这些脚本，这样一个接口测试化测试框架就出来了。期间，脚本做了很多次重构，这个我感觉是在做自动化中不可避免的，必须面对，坑跳一跳就明白是怎么回事了。对于我现在写的这些东西，如果没有做过的人，可能就不知所云，做过的人应该跟我会有共鸣。
总的来说，接口测试非常有必要，能实实在在提升测试效率。
.......
本文出自《51测试天地》原创测试文章系列（四十四）
喜欢我们的会点赞，爱我们的会分享！
