遇到这3种接口测试问题,其实,你可以这么办~

遇到这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调用后台接口看看。假如后台接口返回的数据是正常确的,那接下来怎么处理呢?这就需要我们回头去服务器查日志了。当我们发现只有一个总公司,没有分公司时,分公司对应的参数都是空的,程序就直接跳过没再执行后面的查询了。根据这种情况,只需我们找开发人员加一个接口:判断分公司是否有值。没有值时,直接跳过,计算总公司的数据即可。

当然,接口测试常见的问题还有:内存溢出、性能问题、查询接口还会涉及到安全问题,等等。这些问题都要根据接口的实际功能,进行分析和有针对性的测试,这里就不一一列举了。

加助教老师VX:xiaoxianchen89,回复:软件测试马上加入IT学习交流群,领更多软件测试学习资料

  • 0
    点赞
  • 4
    收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:1024 设计师:我叫白小胖 返回首页
评论

打赏作者

ITstudy001

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值