遇到这3种接口测试问题，其实，你可以这么办~
作为整个软件项目的必经环节，软件测试是不可缺少的“查漏补缺”环节。而作为软件测试中的重要一环——接口测试，几乎串联了整个项目所有的输入和输出环节。
前几年，我在做后端测试时，接触最多的正是接口测试。基于此，我想给大家分享一些我曾经碰到过的接口测试难题，希望抛砖引玉，给正在做测试的小伙伴们提供一些避雷方案。
1、未释放请求服务，导致APP执行任务失败
这个接口功能大概是这样的：
这是一个算法转换服务的接口。也就是说，我们需要把下单系统中的订单的产品信息，转换成生产系统的生产产品信息。然后根据转换后的订单，进行生产。
基于我们要做不同系统间的调用，所以我们可选择webserivce服务来做调用接口。在这个过程中，接口B将处理这些信息：
l 接收系统A传的参数
l 调用转换服务进行转换
l 转换成功把转换结果写入数据库
l 转换失败返回错误信息
测试这样的接口一般是先本地构造数据，用接口工具进行测试。在这里我们用的是soapui工具，然后就是用真实数据不同系统间进行联测。
当然如果前端功能已经实现，我们也可以直接用前端系统构造数据直接调用接口，这样构造出来的数据更直接。特别是参数比较多，比较复杂的时候，这样测试比直接用接口工具更快更省事。当然，即使我们直接这样测试，也不能取代联测。为什么呢？
因为你去别人的系统自己构造数据，构造的数据只是根据参数来的，不一定能把别个系统所有产品的特性覆盖全。
接下来，我们说说这个接口测试过程中，可能出现的问题。如果这个接口开发交付验收基本功能是正常的，但是一把代码部署到测试环境里，没运行多久，这个接口的APP任务就出现执行失败，这就有问题了。
即便我们认为一条失败了，问题是出在数据构造上。但如果多条连续失败，甚至之前执行成功的数据再次执行转换任务也失败了，那我们应该怎么办呢？
其实很简单，这个时候我们应该去服务器取日志，进行校验。如果发现是服务请求数超限，无法请求到服务，导致APP执行超时导致失败。那么，我们就应该请开发人员协助处理了。
假如此时，我们喊来开发小哥一起分析，发现是接口请求服务链接后，用完未进行释放（这个链接服务器是有一个数量限制的，达到一定量后就无法再进行新的链接）导致的，我们接下来又应该怎么处理呢？
当然就是请开发小哥调整一下代码处理方式，使每次请求用完后，都可以自动释放掉链接。这样处理以后，我们只需再重新测试，直到不存在此问题即可。
2、前后端就扣参数对不上，导致接口问题
假如前后端接口参数code对不上，导致数据读取、接收不到或转换，运算结果失败，我们应该怎么处理呢？
这个是接口测试中常见的一个问题，特别是涉及到不同系统间调用接口传参数时，很容易出现这样的问题。
日常工作中，当测试页面功能时涉及到一个接口，功能大概是这样的：查询产品的目录价，成交展示出来。当时前台入参可能是这样的：
l Productname:
l Productversion:
l Productcode:
l Listprice:
l Netprice:
后台返回参数是这样的：
l Productname:
l Productversion:
l Productcode:
l Listprice:
l Net_price:
如果单独用接口工具测试这两边的参数，数据展示是没有问题的。但只要前后台联测，就出现所有产品成交价都是0。遇到这样的情况，我们应该怎么办？
只要我们对比两边消息体的参数，就不难发现，两边参数成交价的名称code写的不一致的。这也就是导致前台读取不到后台传过来的值，默认展示为0的原因了。
类似这样的问题还有很多。
比如：前端系统想要参数1的值，而后台传过来的，却是参数2的值，导致前端在拿过这个值进行逻辑判断或运算的时候，怎么都不对。
再比如：两边取值都是一样的，但是在业务上，这个值就是取的不对，这样即使测试没问题，在实际应用中，结果也是不对的。这个时候，就要求我们需要加深对业务知识的理解了。
为了避免我们在做测试时，遇到这样的问题，我给大家做了一下总结：
1）接到这种传参数的测试时，一定要先做静态测试，核对两边的参数code；
2）对于接到参数取值相关的任务时，在做测试前，两边一定要沟通核对数值及其代表的含义；
3）要提前熟悉业务，看清楚每一个存储的参数表示的含义，确保业务传值正确。
3、参数判断少了特殊情况，导致查询结果不对
这个问题也是接口测试中常见的问题之一。多数情况下，这个问题是由于开发人员对当前产品业务了解不够造成的。
我印象比较深的一次，是一个关于权限优化的需求。记得当时有一个紧急版本要上线，我们的任务是：优化权限的判断逻辑，提高查询性能。
这个功能大概是这样的，当前登录人所在公司有分公司，那么，他同时可以查看分公司的订单。逻辑如下：
分析一下这个功能，主要有以下几种场景：
情况1：登录人所在公司，只有一个总公司，没有分公司。且总公司有订单，当前登录人可以查看所在公司的订单；
情况2：登录人所在公司是总公司。且该公司有多个分公司，每个分公司都有订单，总公司没有订单，当前登录人可以查看到所有分公司的订单；
情况3：登录人所在总公司有多个分公司，总公司和分公司都有订单，当前登录人可以查看总公司和分公司的所有订单；
情况4：登录人所在公司是总公司且其下有多个分公司，分公司没有订单，只有总公司有订单。当前登录人可以查看到总公司订单。
场景分析完后，接下来，我们就是需要据场景，构造数据进行测试了。
这里，我主要就【情况1】的场景给大家做一个分析。假设在【情况1】里：一进行场景测试，就出现：因为明明有订单的，页面上却展示空白。
这是怎么回事呢？
此时，我们需要先用postman调用后台接口看看。假如后台接口返回的数据是正常确的，那接下来怎么处理呢？这就需要我们回头去服务器查日志了。当我们发现只有一个总公司，没有分公司时，分公司对应的参数都是空的，程序就直接跳过没再执行后面的查询了。根据这种情况，只需我们找开发人员加一个接口：判断分公司是否有值。没有值时，直接跳过，计算总公司的数据即可。
当然，接口测试常见的问题还有：内存溢出、性能问题、查询接口还会涉及到安全问题，等等。这些问题都要根据接口的实际功能，进行分析和有针对性的测试，这里就不一一列举了。感兴趣的小伙伴也可以在留言区留言，提出问题，我们共同探讨，共同进步。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
