• 6
  • 14
分享

互联网时代的到来,互联共享成为主旋律。多个互联网公司之间的合作越来越深入,越来越紧密,接口测试的重要性显得越来越突出。今天就把我接口测试的思路分享出来,希望可以给大家指明测试的方向,开拓大家的测试思维。

从一个模型说起,进行接口测试两年多了,不断的测试,不断的摸索,将接口测试抽象成如下模型:

967767-20170906154717116-592134760.png

模型很简单,就是四个模块,为了更好的说明这一点,我接下来展开来说。

第一:接口文档测试

对于接口接口文档是双方约定的最基础的约定,数据能否正常传输依赖于接口文档,接口文档定义的标准、规范。对于这个接口来说已经完成了大部分的工作。

从接口文档中我们要剖析出以下的点展开测试:

【1】首先明确请求的数据类型是什么,主流的有Json、http等请求。

【2】对接口文档中定义的必录项一一进行测试,看某必录项缺失时,作为接收的一方是否有合理提示。

【3】对于文档中定义的非必录项一一进行测试,看某非必录项缺失时,作为接收的一方是否可以正常接入信息。

【4】对于日期格式进行测试。支持的是yyyy-MM-dd还是yyyyMMdd还是yyyy/MM/dd这种格式进行验证。

【5】对于有效数字保留进行测试。一般接口文档要求保留最多两位小数,此时要验证整数、保留一位小数、保留三位小数时接收方的响应。(等价类划分)

【6】对于常见的身份证号、手机号要进行长度、容错性测试。

【7】对于枚举值,要一一进行测试。(运用等价类划分的方法)

【8】对于请求方的数据还要对照接口文档确认是否完全按照接口文档定义的数据类型进行传输的。看一个小小的接口文档对于测试来说有这麽多的门道。肯定需要引起大家的足够重视。

第二:进行完接口文档的测试。

那么最起码接口是满足基本功能要求的,此时我们就要基于各种业务场景,测试其接口的内部逻辑。因为针对业务不同,具体逻辑也五花八门,我只概括的进行总结,希望大家能根据自己测试的接口展开扩展。

【1】遇到时间,要确认各种业务场景下是否有因为时间而影响的场景。举个例子来说:一个借款人要来银行借款,银行的审批时间为7天,但是借款人在第8天才进行审批请求,此时已经超过银行的规定了,接口必然需要进行差异处理。

【2】遇到金额想到是否存在等式和不等式的关系。还拿借款人来银行借款这个例子来说:借款人借款之后,需要进行还款,还款请求中有还款总金额、还款本金还款利息金额。此时我们肯定要分析出:

还款总金额=还款本金+还款利息(等式成立)

还款总金额、还款本金必须>0(不等式成立),才是正确的请求。

【3】遇到运维阶段的需求改动,一定要想到历史数据的处理。这个也很好理解。还拿借款来说,银行答应借款人的借款期限是三个月,后来业务收缩,决定缩小期限变为2个月。那么已经按照3个月借款的借款人怎么办呢?肯定还是按照3个月期限进行还款。此时就需要我们的程序一定要兼容历史数据也要适用于新数据。我们测试的时候也必须考虑这一点。

【4】独立存在的逻辑场景,这个需要切实根据自己测试的功能进行总结,不在多说。建议可以将这部分建立自己的质量地图,后期维护的时候肯定会叫自己事半功倍。

第三:下面我们要进行数据库的测试。

针对接口数据库部分的测试其实占有很大的比重,我们应该着重注意测试以下方面:

【1】业务流转如何映射在数据库。一般都是靠状态、流程节点进行区分。

【2】各个表的更新如何映射业务流程。即一个接口的接入哪些表只是单纯的存储数据,哪些表是更新数据,更新的数据有哪些。一定要清晰。

【3】各个表的流转之间是不是有异常处理。举个例子来说:接口A成功接收后,需要存储表tab1和tab2,且存储完tab1才去存储tab2,此时数据库发生异常,存储完tab1但是存储tab2失败,此时需要验证功能是否回滚,是否有这部分的异常处理。

第四:其他异常流测试。

这个其实有点探索性测试的意味,到生产上遇到的异常会五花八门。这里我只说下自己的情况。

【1】dubbo重试机制引起的雪崩,测试过微服务的人都知道,运用阿里的dubbo服务搭建的接口,当消费者调用服务者的时候,如果由于网络异常原因,第一次调用失败,dubbo重试机制会自己在发送几次。此时大概率会发生数据重复存储的问题。

【2】重复申请处理,一般程序第一次接收正常,要确认第二次再次申请是不是有重复校验,不会有高并发的风险。

【3】极端情况,要知道我们测试的程序,任何固化的东西都不可信任,都可能产生风险,需要我们一一确认。具体来说依然拿借款的例子来说:借款人向银行借款,必须经过申请->银行审批->放款这个流程进行,但是借款人直接出发程序的放款机制,此时还没有经过银行审批,那程序是不是有正常处理策略,需要我们一一测试。

掌握了以上的测试流程,不管遇到什么样的接口都会手到擒来,测试其实就是一个重在分析、贵在思路的过程!希望用我的经验给大家启发,接口测试并不难,征服它的道路上我们一路同行!


本文出自51讲堂讲师海宝的博客园。原文链接:https://www.cnblogs.com/haibaowang/articles/7485880.html

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

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   美国汽车制造商特斯拉公司上周日宣布,将在上海新建一家超级工厂,专门生产该公司的超大型储能商用电池Megapack。特斯拉CEO埃隆·马斯克在推特转发官宣推文,表示新工厂将作为加州工厂Megapack产能的扩充。  据悉,该工厂初期规划年产商用储能电池可达1万台,储能规模近40GWh,产品提供范围覆盖全球市场。该项目计划于2023年第三季度开工,2024年第二季度投产。作者:佚名原文链接:新浪科技_新浪网(sina.com.cn)
            0 0 623
            分享
          •   软件缺陷管理是一个关于发现,记录,追踪,处理和报告软件缺陷的过程。这是软件开发过程中的一个重要环节,它可以帮助开发团队保持代码的质量并及时修复问题。  一、早期小团队使用的免费缺陷管理工具  在项目早期或者团队规模较小的情况下,人们经常使用的缺陷管理工具有电子表格,如Microsoft Excel或Google Sheets;代码托管平台,比如如GitHub,GitLab等;项目管理工具,通过创建卡片来代表每个缺陷,并将它们按照状态(如待处理,正在处理,已解决)分类。  当团队规模扩展到几十人,项目规模扩大,使用电子表格等非专业工具的缺陷就开始展露,比如缺乏自动化,你需要手动输入...
            0 0 939
            分享
          •   质量监控的范围和概念  1.用户体验是否舒服:  以用户的角度对产品进行使用,以找到不合理,体验差的功能点。  2.产品设计是否符合:  以产品的角度对产品设计的完整性进行检验。  3.性能状况是否稳定:  以系统运维的角度找到产品性能的瓶颈。  4.逻辑设计是否存在漏洞:  以开发人员的角度检测产品的逻辑合理性。  5.系统安全,数据安全是否有保障:  以不法分子,黑客的角度对产品进行攻击,以检测产品的安全性。  测试用例设计方法:  软测行内共识的设计方法不再赘述,转帖一篇文章小白们可以自己去看:  测试用例的几种常见设计方法:  已有的常规方法我们可以照搬照用,但是从质量管理的整体性...
            11 10 1418
            分享
          • 一、前言在当前主流的前端后端分离模式开发下,拥有一个接口文档并且是好用的接口文档是很有必要的一个东西。PS:?以下观点是真实开发场景下碰到并且悟出来的痛点。1、在项目的开发过程中,有一个接口文档的存在能让前端后端工程师保持的数据信息概念是统一的。例如:”项目需求的接口字段,参数字段。所有只要请求的返回参数记录到文档中的情况后,前后端工程师编写代码的同时就能统一对照接口文档去编写各自的逻辑,那么在各个信息的命名都是统一的情况下,在各自的代码中就不会发生前端在一个需求功能的请求接口命名是与后端返回接口的命名信息不一致的情况。这样可以大大避免了导致排查问题的时候不能很快速的定位问题。2、好的接口文档...
            2 2 653
            分享
          •   关于“好的” 的定义  “好的”测试用例一定是一个完备的集合,可以覆盖所有等价类以及各种边界值,而跟它最终是否可以发现缺陷无关。  “好的”用例具备的特征  1.等价类集合的完备性  需要保证所有可能的边界值和边界条件都已经正确识别。  2.等价类划分的准确性  指的是对于每个等价类都能保证只要其中一个输入测试通过,其他输入也一定测试通过。  3.整体完备性  往往一个功能点需要涉及到多个用例去覆盖方方面面,所以测试用例是一个完备的整体,是有效测试用例的集合,能完全覆盖测试需求。  最常用三种用例设计方法  1. 等价类划分方法  2. 边界值分析方法  3. 错误推测方法  如何才能设计...
            0 0 676
            分享
      • 51testing软件测试圈微信