• 0
  • 0
分享
  • 从三个阶段讲讲,网关类接口都要测什么——软件测试圈
  • 恬恬圈 2023-03-13 16:15:40 字数 989 阅读 767 收藏 0

  网关是指内部服务和第三方外部服务交互的接口,常见的网关有通过渠道引入外部用户的通用网关、和支付商户对接的支付网关、获取第三方数据的数据网关等(一种是我们提供给第三方调用,一种是去调用第三方,这里重点讨论第二种)。

  因为网关接口需要依赖第三方响应的结果,而不管我们请求参数如何,第三方测试环境响应结果基本固定,不一定会出现我们想要的情况。

  还有一种情况是测试账号的原因,比如缺少有效的信用卡号、有流水记录的淘宝卖家账号等,导致我们使用的测试账号只能覆盖单一的情况。

  虽然对网关来说大部分时候只要能和第三方调通就可以,但是线上情况不可控,只验证正常情况当然不够严谨,需要确保各种可能出现的异常情况都能处理。很多同学在测试网关接口时,只是联调一次成功的情况,再多也是测试各种请求参数缺失和组合的情况,这样的覆盖率是很低的。

  那么我们怎么样才能提高测试覆盖率,以及做到不依赖第三方服务呢?

  设计阶段

  一般第三方会给出详细的接口文档,里面有给出各种情况的返回码和返回参数,包括成功的、失败的、参数缺失、参数错误、签名错误、请求超时、解密错误、解析消息体错误等。

  结合我方的业务,分析对方返回数据是否满足我方要求,以及是否还有其它可能出现的情况,并且需要和开发同学强调要处理第三方的这些返回结果。

  开发阶段

  针对那些测试时比较难覆盖的情况,我们可以让开发在单元测试中补充覆盖这些场景。

  单元测试是很好的补充覆盖异常情况的方式,很多被catch的异常情况我们无法在测试中执行,那么这部分代码通过单元测试覆盖即可。

  测试阶段

  测试阶段需要关注的几个点,一是网关的功能和性能,二是要监控网关的情况以及针对异常要有预警,三是需要通过mock第三方服务补充覆盖异常情况。

  很多情况第三方无法返回,需要我们创建mock接口来模拟(将测试环境请求第三方的地址修改为mock接口的地址),即可测试在不同场景下的处理情况。

  比如,请求第三方超时时我们这边的业务会不会阻塞,第三方返回了成功但是没有带上我们想要的数据怎么处理,第三方返回的订单id和我们请求时带的不是同一个我们会校验码,这些都是我们需要考虑的,通过mock可以很好地帮我们实现。



作者:circle_hyy    

来源:http://www.51testing.com/html/42/n-7792742.html

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 最近在阅读《高性能之道》这本书,其中有一个小标题让我突然想到一个旧话题:拓展自己的边界。弱化边界感。在我之前读过的技术类书籍中,往往更多偏重于不同团队之间的协作配合。而在这本书中我读到了更多关于个人成长方面的。如果你在在一个岗位工作时间变长之后,在经过稳定期之后就会遇到工作瓶颈。如何能突破这种瓶颈限制呢,作者提出一个方向:突破边界。# 拓展边界的重要性在IT工作中,拓展自己的边界绝对是非常重要的。作为一名互联网工作者,我们常常面对着快速发展的技术和变化的行业趋势。如果我们只停留在自己熟悉的领域,不积极主动地学习和尝试新的知识和技能,很可能会被时代抛在身后,错失许多机会。拓展自己的边界可以带来许...
            0 0 580
            分享
          •   前言  性能测试大致分以下几个步骤:  1.需求分析  2.脚本准备  3.测试执行  4.结果整理  5.问题分析  今天要说的是最后一个步骤——“问题分析”。  需求描述  有一个服务,启动时会加载一个1G的词表文件到内存,请求来了之后,会把请求词去词表里做模糊匹配,如果匹配到了就向一个后端服务发送一条http请求,拿回数据之后,返回给客户端的同时,向mysql记录请求的唯一标识和一个请求次数的标记;   其中有几个关键函数 :  ·模糊匹配(fuzzyMatching)   · 后端请求函数(sendingRequest)   · 拼...
            0 0 245
            分享
          •   最近项目发补丁,笔者所负责的模块进行回归测试。提供的补丁版本在回归测试前已经进行过一些时日的测试,并且发现的故障也已经修复完成。但是情理之中意料之外的是,已经测试完成的功能陆陆续续又发现了几个故障,让笔者不得不检讨和怀疑自己。那么,这些故障为什么会测试遗漏呢?  经过笔者对比和总结,复测发现的故障主要出现在以下情况:  ·交互模块测试不充足,导致其他模块引用笔者测试模块时发现故障;  ·测试样本数据量小,无法触发大数据量场景下的故障;  ·非正常途径获取测试版本,导致故障未能及时发现;  ·版本升级,兼容性测试不足;  ·忽略一般类打印错误,导致数据残留;  那么,所述的这几种测试遗漏场景...
            0 0 750
            分享
          • 1.BUG等级划分建议:目前project上的BUG严重程度分为五个等级,按照CMM5中定义的规范,BUG严重等级可分为3-5个等级,由于我们公司的CMM水平还处于初级阶段,将BUG等级划分过细不符合我们当前的CMM水平,同时也不利于测试人员对BUG等级的精确划分。根据我们公司的情况,同时参照其它中小公司的等级划分标准,建议将BUG等级划分四个等级,分别为致命、严重、一般、提示。致命(可对应目前BUG体系中的“非常严重”):致命性问题主要为:系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。具体基本上可分为:严重花屏内存泄漏用户数据丢失或破坏系统崩溃/死机...
            0 0 3046
            分享
          • 前言HTTP接口测试很简单,不管工具、框架、还是平台,只要很的好的几个点就是好工具。测试数据问题:比如删除接口,重复执行还能保持结果一致,必定要做数据初始化。接口依赖问题:B接口依赖A的返回值,C接口依赖B接口的返回值。加密问题:不同的接口加密规则不一样。有些用到时间戳、md5、base64、AES,如何提供种能力。断言问题:有些接口返回的结构体很复杂,如何灵活的做到断言。对于以上问题,工具和平台要么不支持,要么很麻烦,然而框架是最灵活的。unittest/pytest + requests/https 直接上手写代码就好了,既简单又灵活。那么同样是写代码,A框架...
            9 9 1004
            分享
      • 51testing软件测试圈微信