接口测试知识点

最近在面试,都会问接口测试相关的问题,做个整理,希望帮到求职的小伙伴。

部分内容源于:https://www.cnblogs.com/linyu51/p/14277533.html(侵删)

还有部分内容从抖音、哔哩哔哩整理所得,侵删。

一、你们公司是如何做接口测试的?

答案1:

  1.获取接口文档,熟悉单接口 以及链路接口(接口业务流程)的业务,包括:接口地址、鉴权方式、入参、出参、错误码等。

  2.编写接口测试用例并评审?

    正例:1-2个,单接口返回成功场景,链路接口业务流程实现(功能业务流程)

    反例:

      鉴权异常:空、错误、过期

      参数异常:空、类型异常、长度异常

      错误码异常:接口文档中会给出错误码

      其他异常:接口黑名单、接口调用次数现在(分页,少于0, =0, 中间页,最大页,超过最大页)

   3.使用接口测试工具或代码的方式执行接口测试,重要考虑的情况:接口关联、接口加密、接口参数是否签名、是否需要带请求头等

     4.实现持续集成并输出接口测试的电子邮件,有bug 提bug。

 

如下是是一个标准的接口文档示例,有详细的错误码说明:https://pay.weixin.qq.com/wiki/doc/apiv3/apis/chapter3_2_1.shtml

答案2:

  接口测试实际跟一般测试不同就是测试用例的设计部分。
  ①获取接口规范。
  ②设计接口测试功能用例(主要从用户角度出发看接口能否实现业务需求,用例设计就是黑盒用例那一套)。
  ③各种入参验证(正常情况,异常情况包括输入参数个数不对,类型不对,可选/必选,还有考虑参数有互斥或关联的情况)。
  ④接口返回值各种验证(符合接口文档需求)
  ⑤了解接口实现逻辑,实现逻辑覆盖(语句/条件/分支/判定/…)
  ⑥接口能并发执行吗、安全吗,性能满足要求吗?
  ⑦采用工具或者自写代码来验证。
  ⑧发现问题跟功能测试一样,该报bug报bug,该跟踪状态的跟踪状态。

答案1 是之前在bili上 刷的面试题,给出的答案,答案2 是博客园的这个小伙伴分享的.我觉得都OK。

  

二、设计接口测试用例的思路?

通常,设计接口测试用例需要考虑以下几个方面:
  ①是否满足前提条件
    有些接口需要满足前提,才可成功获取数据。常见的,需要登录Token
    逆向用例:针对是否满足前置条件(假设为n个条件),设计0~n条用例
  ②是否携带默认值参数
    正向用例:带默认值的参数都不填写、不传参,必填参数都填写正确且存在的“常规”值,其他不填写,设计1条用例
  ③业务规则、功能需求
    这里根据时间情况,结合接口参数说明,可能需要设计N条正向用例和逆向用例
  ④参数是否必填
    逆向用例:针对每个必填参数,都设计1条参数值为空的逆向用例
  ⑤参数之间是否存在关联
    有些参数彼此之间存在相互制约的关系
  ⑥参数数据类型限制
    逆向用例:针对每个参数都设计1条参数值类型不符的逆向用例
  ⑦参数数据类型自身的数据范围值限制
    正向用例:针对所有参数,设计1条每个参数的参数值在数据范围内为最大值的正向用例

此题来源:https://www.cnblogs.com/linyu51/p/14277533.html

我的回答:

    1.通过会议确定接口测试用例的颗粒度

    2.根据颗粒度的大小设计用例,颗粒度大的话,一个接口可设计7-8个,正例 2-3条 反例 5条左右,主要是对入参的一些校验,如默认值、必填、选填、字段类型等等,一般还根据开发文档上的异常码,去造相关的数据。

三、你平常做接口测试的过程中发现过哪些bug?

答案1:

  面试官出这个题,主要是想知道你是不是真的做过接口测试,毕竟现在很多小伙伴简历经过包装(不包装连面试机会都没有,没办法,为了生存,能理解)
答:
  常规错误,接口没实现,没按约定返回结果,边界值处理出错等。
  输入异常值(空值、特殊字符、超过约定长度等),接口抛错,没做封装处理;
  输入错误的参数、多输入、少输入参数,接口可能出现的错误;
  安全性问题,如明文传输、返回结果含有敏感信息,没对用户身份信息做校验,没做恶意请求拦截等;
  性能问题,如接口并发插入多条相同操作,响应时间过长,接口压测出现瓶颈等;

答案2: 

  常规bug:接口没有安装文档说明返回结果,输入异常类(空值、特殊字符),接口报错,没有返回合理的提示

      如 商品价格 修改为-3

  权限bug:

      测试修改服务包商品信息接口,接口文档要求只有超级管理员才有权限修改,我传入一个普通人员的人员ID 和角色编码,都能修改成功。

  接口测试就是为了避免绕过前端测试,直接访问后端接口的BUG。

答案1(博客园)和答案2(bilibili)结合起来更好。

四、你做接口测试,测什么?

  • 可用性测试  根据约定的协议、方法、格式内容,传输数据到接口经处理后返回期望的结果:

    接口功能是否正确实现;
    返回值测试 - 返回值除了内容要正确,类型也要正确,保证调用方能够正确地解析;
    参数值边界值、等价类测试;

  • 错误和异常处理测试

    输入异常值(空值、特殊字符、超过约定长度等),接口能正确处理,且按预期响应;
    输入错误的参数,接口能正确处理,并按预期响应;
    多输入、少输入参数,接口能正确处理,且按预期响应;
    错误传输数据格式(如json格式写成form格式)测试;

  • 安全性测试,主要指传输数据的安全性:

    敏感数据(如密码、秘钥)等是否加密传输;
    返回数据是否含有敏感数据,如用户密码、完整的用户银行账号信息等;
    接口是否对传入的数据做安全校验,如身份ID加token类似校验;
    接口是否防止恶意请求(如大量伪造请求接口致使服务器崩溃);

  • 性能测试,如接口的响应时间、并发处理能力、压测处理情况:

    并发请求相同的接口(特别为POST请求),接口的处理情况(如插入了相同的记录导致数据出错,引发系统故障);
    接口响应时长在用户可忍受的范围内;
    对于请求量大的接口做压测,确定最大的瓶颈点是否满足当前业务需要;

此题来源:https://www.cnblogs.com/linyu51/p/14277533.html

 

五、浏览器地址栏输入了一个URL,直到请求结束数据加载出来,这中间经历了什么?

  第一进行DNS域名解析

  第二它会建立TCP链接(3次握手4次挥手)

  第三发送一个http的请求

  第四服务器处理相关的请求

  第五是返回响应的结果

  第六关闭TCP连接

  第七浏览器解析HTML

  第八浏览器进行布局渲染

来源:抖音

  

六、cookie、session、token的区别

相同点:都是用于鉴权并且都是服务器生成的。

不同点:

  cookie 保存在客户端的浏览器上,cookie不安全,可以去分析存在在本地的cookie进行cookie欺骗

  session保存在服务器的内存,默认保存30分钟,比cookie安全,缺点是当登录的用户过多,比较占用服务器的资源。session一边会生成一个sessionid(名称自定义),sessionid可以通过cookis传输。

  token存储在服务器的数据库里面,通过一个接口或者通过登录获取,然后后续所有的接口都必须传token才可以请求成功。

来源:bilibili

七、接口关联是如何处理的?

  接口关联:一个接口依赖于多个接口,或多个接口依赖于一个接口(登录)。很多的接口测试都是登录之后获取鉴权码,然后其他所以的接口都需要这个鉴权码。

  以实际做过的案例为主:登录接口-登录成功后,会返回token信息,其他需要登录才能查看的接口都需要这个token,并且是在请求头header里边,处理办法:将登录成功后的token取出来保存为全局变量,哪里需要直接引用就可以。

  jmeter 里边使用json提取器(正则也能实现),将token提取出来,别处直接引用:${token},可借助chrome的插件:JSON-handle_0.6.1.crx  之前写过文章,

       传送门: https://www.cnblogs.com/eosclover/p/15325499.html

  postman :用脚本的方式去实现,提取之后都要保存在全局变量。 

八、常用的接口测试工具?

  postman  jmeter

  我的回答:单接口的话  使用postman比较多,多接口 关联的话,使用jmeter比较多,jmeter处理接口关联比较方便。

九、对于依赖第三方数据的接口如何进行测试?

  我的回答:通过postman 搭建Mock服务器。

  之前写过搭建步骤,传送门:https://www.cnblogs.com/eosclover/p/15695581.html

十、接口测试如何校验结果是否正确?

    1.HTTP状态码校验

         验证返回的状态码为200(常见的HTTP 状态码有:200,404,501)

    2.业务状态码

        (1)根据接口文档,看看业务状态码成功是什么,之前遇到的是用10个0  代表成功。

          (2)当接口响应的内容比较少,比较固定的情况下,校验完全一致。

        (3)当接口响应的内容比较多,校验最核心的业务信息。

        (4)当接口响应的内容为层级较多的xml格式或JSON格式时,可通过xpath、JSONPath、正则的方式匹配获取到最关键字的业务字段,然后再校验。

        (5)查询数据库校验或是通过其他接口校验。

原文地址:https://www.cnblogs.com/eosclover/p/15752810.html