51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 4082|回复: 0
打印 上一主题 下一主题

[原创] 这些年接口测试遇到的那些事

[复制链接]
  • TA的每日心情
    擦汗
    昨天 09:02
  • 签到天数: 1046 天

    连续签到: 4 天

    [LV.10]测试总司令

    跳转到指定楼层
    1#
    发表于 2021-4-27 14:58:17 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    说起测试,不得不说一下接口测试,这是在整个测试过程中不可缺少的一部分的测试,只要有输入输出,几乎都涉及到接口这块,在前几年做后端测试时接触最多的就是接口测试这块,在这其中大大小小的问题也遇到不少。
      今天给大家讲讲这其中的故事吧
      一、未释放请求服务,导致APP执行任务失败:
    这个接口功能大概是这样的:
      

    这是一个算法转换服务接口,就是把下单系统订单中的销售产品信息转换成生产系统的生产产品信息,然后根据转换后的订单进行生产。不同系统间调用接口用的是webserivce服务。
    在这个过程中接口B做了这样几件事:
    1. 接收系统A传的参数
    2. 调用转换服务进行转换
    3. 转换成功把转换结果写入数据库
    4. 转换失败返回错误信息。
      测试这样的接口一般是先本地构造数据,用接口工具进行测试,在这里我们用的是soapui工具,然后就是用真实数据不同系统间进行联测,当然如果前端功能已经实现,我们也可以直接用前端系统构造数据直接调用接口,这样构造出来的数据更直接,特别是参数比较多,比较复杂的时候,这样测试比直接用接口工具更快更省事,当然即使我们直接这样测试,也不能取代联测。
      为什么呢,因为你去别人的系统自己构造数据,构造的数据只是根据参数来的,不一定能把别个系统所有产品的特性覆盖全。
      好了说了这么说,现在说说这个接口测试中出现的问题吧,这个接口开发交付验收基本功能是正常的,可是一把代码部署到测试环境,运行没多久,这个接口的APP任务就会执行失败,一条失败了可以说是数据构造的问题,多条连续失败甚至之前执行成功的数据再次执行转换任务也是失败的,那就接口有点问题了。
      什么问题呢?去服务器取日志查看,发现是服务请求数超限,无法请求到服务导致APP执行超时导致的失败。
      请求为什么会超时,喊来开发小哥一起分析了一把,发现是接口请求服务链接后用完未进行释放,这个链接服务器是有一个数量限制的,达到一定量后就无法再进行新的链接。
       怎么办?开发小哥把代友码修改一下处理方式,每次请求用完以后,释放掉链接,之后再重新测试,未再复现此问题
    到此,我们可以正常的按需求和业务逻辑进行数据场景测试覆盖了。
    二、前后端接口参数code对不上,导致数据读取、接收不到或转换,运算结果失败
    这个是接口测试中常见的一个问题,特别是涉及到不同系统间调用接口传参数时,很容易出现这样的问题。
    当时测试页面功能时涉及到一个接口,功能大概是这样的的,查询产品的目录价,成交展示出来。
    当时前台入参是这样的:
      Productname:
      Productversion:
      Productcode:
      Listprice:
      Netprice:
    后台返回参数是这样的:
      Productname:
      Productversion:
      Productcode:
      Listprice:
      Net_price:
    两边这样的参数,单独用接口工具测试,数据展示没有问题的,前后台联测,就会发现所有产品成交价都是0.
    怎么回事?对比两边消息体的参数,我们就发现两边参数成价的名称code写的不一致,导致前台读取不到后台传过来的值,就默认展示为0
    这样类似的问题还有很多,比如说前端系统想要的参数1的值,而后台传过来的却是参数2的值,导致前端在拿过这个值进行逻辑判断或运算的时候,怎么都不对。
    再比如说两边取值都是一样的,但是在业务上这个值就是取的不对,这样即使测试没问题,在实际应用中结果也是不对,这个时候就要求我们理解业务了。
    那么遇到这样的问题我们要如何避免,我总结了一下:
    1. 接到这种传参数测试时,一定要先做静态测试,核对两边的参数code
    2. 对于参数取值相关的需求时,测试时两边一定要沟通核对数值及其代表的含义。
    3. 要提前熟悉业务,开清楚每一个存储的参数表示的含义,确保业务传值正确。
    三、参数判断少了特殊情况,导致查询结果不对
        这种问题也是接口测试中常见的,多数是由于开发对当前产品的业务了解不够引出来的,记忆比较深的就是一个权限优化的需求。
        记得当时有一个紧急版本要上线,修复内容是优化权限的判断逻辑,提高查询性能。
       这个功能大概是这样的当前登录人所在公司有分公司,那么他同时可以查看分公司的订单,大概逻辑如下:

    这个功能分析一下主要是有以下几种场景:
    1. 登录人所在公司,只有一个总公司,没有分公司且总公司有订单,当前登录人可以查看所在公司的订单。
    2. 登录人所在公司是总公司且其下有多个分公司,每个分公司都有订单,总公司没有订单,当前登录人可以查看到所有分公司的订单。
    3. 登录人所在总公司有多个分公司,总公司和分公司都有订单,当前登录人可以查看总公司和分公司的所有订单。
    4. 登录人所在公司是总公司且其下有多个分公司,分公司没有订单,只有总公司有订单。当前登录人可以查看到总公司订单。
    场景分析完了,然后就是根据场景构造数据进行测试了,首先构造就是只有一个总公司没有分公司且总公司有订单的场景,结果这一场景测试就出问题了,明明有订单的,页面上却展示空白。
      怎么回事,用postman调用后台接口看看,后台接口返回的数据是正常确的,那是怎么回来呢?
       回头去服务器查日志看看,发现是只有一个总公司,没有分公司时,分公司对应的参数都是空的,程序就直接跳过没再执行后面的查询。
       知道问题了,就找开发小哥发析是哪里的问题导致程序没有执行后面的查询,开发小哥分析了一下代码,发现接口少做一个判断:分公司没有值,只有总公司有值的时候跳过去了,加了一个这种特殊场景的判断再执行测试,查询结果就正确了。
    接口测试常见的问题还有内存溢出,性能问题,查询接口还会涉及到安全问题,等等这些问题都要根据接口的实际功能进行分析和有针对性的测试,这里就不一一列举了。



    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

    x
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-15 00:37 , Processed in 0.066483 second(s), 24 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表