ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

接口测试总结

2022-07-27 19:05:01  阅读:142  来源: 互联网

标签:总结 请求 接口 cookie 测试 参数 服务端 客户端


接口测试的技术栈

  1.协议:http、websocket、Dubbo、gRPC;

  2.接口测试工具:PostMan,JMeter;

  3接口测试的框架:(1). postman + newman(2).Jmeter +ant

  4.MockServer;

http(Hypertext transfer protocol)超文本传输协议:

  通过浏览器和服务器进行数据交互,进行超文本(文本、图片、视频等)传输的规定。

websocket协议(auth2.0):

  客户端与服务端始终保持持久连接不会断开。

grpc全称protocol buffers)

  使用RPC进行通信,调用远程函数就像调用本地函数一样,RPC底层会做好数据的序列化与传输,从而能使我们更轻松地创建分布式应用和服务。grpc是RPC的一种,免费且开源的,由谷歌出品。使用gRPC,我们只需要定义好每个API的Request和Response,剩下的gRPC这个框架会帮我们自动搞定。

 

gRPC的通信流程:

  1.gRPC通信的第一步是定义IDL,即我们的接口文档(后缀为.proto)

  2.第二步是编译proto文件,得到存根(stub)文件,即上图深绿色部分。

  3.第三步是服务端(gRPC Server)实现第一步定义的接口并启动,这些接口的定义在存根文件里面

  4.最后一步是客户端借助存根文件调用服务端的函数,虽然客户端调用的函数是由服务端实现的,但是调用起来就像是本地函数一样。

  以上就是gRPC的基本流程,从图中还可以看出,由于我们的proto文件的编译支持多种语言(Go、Java、Python等),所以gRPC也是跨语言的。

TCP协议的三次握手:

  第一次握手:client向server发送resquest请求
  第二次握手:server收到请求,后发送数据包给client确认连接
  第三次握手:client和server建立正确连接,client开始向server传输数据

http完整请求流程

  1.客户端与服务端建立完整Tcp连接

  2.客户端向服务端发送request请求

  3.服务端reponse响应回复客户端请求

  4.客户端与服务端关闭请求

客户端向服务端发送Request请求:

  A、请求方法

  B、请求头(消息体)

  C、请求地址

  D、请求参数

服务端Response响应回复客户端的请求:

  A、协议状态码

  B、响应头(响应体)

  C、响应数据

1、请求方法:

  get(获取资源)、post(添加资源)、put(修改资源)、delete(删除资源)、options(路由映射)x

2、请求头:key:value格式

  User-Agent:描述请求发送端的浏览器类型
  Content-Type:指的是客户端通过什么样的数据格式向服务端发送请求(json数据格式;form表单数据格式;xml数据格式)
  referer:表示这个请求时从那个页面发过来的
  cookie:(维持当前访问会话)反爬虫、身份认证授权

  (set-cookie:服务端把身份认证信息返回给客户端)

3、请求地址:

  URL(统一资源定位符):http协议+域名+资源路径

4、请求参数:

  post和put大部分有请求参数(在postman中有请求参数的方法需要在请求头中添加类型,在请求体中选择类型)get和delete大部分没有请求参数(在postman请求体中选择数据类型时:form格式直接选择x-www-form-urlencoded,xml和json格式需要先点raw再选)

1、协议状态码:Status Code

  200 请求成功
  201 created :添加资源成功
  204 No Content :删除资源成功
  301 Moved Permanently 永久重定向(请求A的时候,会自动跳转到B)
  302 临时重定项
  400 Bad Request 客户端请求错误(请求头/请求参数错误)
  401 Unauthorized 无权限访问该系统(postman中认证授权、鉴权(基本basic|常规digest|自定义)
  403 Forbidden 有权限但是禁⽌访问
  404 请求的资源不存在(检查请求路径)
  405 不被允许的请求⽅法
  415:只有请求头不对
  500 服务器内部错误
  504 GateWay Timeout网关超时(1、统一API访问入口 2、监控API流量)

2、响应头

  Content-Type :指的是返回的响应数据的数据格式(JSON XML HTML)
  Set-Cookie:服务端把身份认证信息返回给客户端

3、响应数据

  响应数据绝大多数不为空。请求成功:回发数据,失败:回发错误信息)

4、响应时间

  指的是客户端发送的时间加上服务端响应回复客户端请求的时间之和。以毫秒为单位。 响应数据的大小以kb为单位。

cookie session token必须知识

  HTTP是一个无状态的协议,所以也就导致了COOKIE技术的发展,通过COOKIE能够记下用户操作的行为状态,但是COOKIE它是存储在客户端的,所以就不安全,为了解决安全的问题,SESSION诞生,SESSION它是存储在服务端相对来说比较安全。后面移动互联网诞生,就有了TOKEN,TOKEN本质上是SESSION原理来实现的,它的流程与SESSION一样,它被称为一个令牌。

cookie:不安全 存储在客户端

session:相对安全,存储在服务端

token:session原理,随机字符串,被称为令牌。

1、以登录为例来说明COOKIE的流程:

  1、客户端输入账户密码登录成功

  2、在服务端生成cookie的信息,通过响应头中的set-cookie把生成的cookie返回给客户端

  3、客户端在下次请求的时候,通过请求头中的cookie带上 发给服务端,服务端内部进行验证

2、以登录为例来说明session的流程:

  1、客户端输入账户密码登录成功

  2、在服务端生成sessionID,同时存储在服务端本地,通过响应头中的set-cookie把生成的sessionID返回给客户端

  3、客户端接收到sessionID后再次请求服务端时(比如访问个人主页),会在请求头的cookie中带上sessionID发送给服务端

  4、服务端接受到客户端发送过来的sessionID,与存储在服务端本地的sessionID之间进行对比。(一致允许访问个人主页;不一致,重定向到登录页面。)

3、token流程

  token与session的流程一样

  1、每次登录成功后,生成的token不一样返回的token是一个随机的字符串

  2、token一般通过响应数据返回给客户端

  3、客户端发送请求给服务端是通过:请求头里面的Authorization:JWT {{token}}

怎么理解session会话对象?

所有请求之间的cookie是共享的

请求底层的tcp连接将会被重用,这样对服务端来说,不会造成不必要的性能上的损耗

通信模式:

  1、同步通信:

    客户端请求服务端必须有回应,在回应之前不能做别的操作,有缺陷,会造成排队、等待、堵塞。   

    当任务太多时,服务器压力太大,可能会造成崩溃,为了防止崩溃这时就需要线程池技术,我们现在的软件都是使用这种技术。   

    线程池技术:(所有的请求都是task,每个task都是一个线程)线程池指定同时执行最大任务数。

    (如服务器指定最大任务数为90,客户端发来100个任务数,剩下的10个采取队列机制(先进先出原则))queue:队列(先进先出的原则)

  2、异步通信:

    客户端向mq消息队列发送数据(商品名、价格),服务端从mq消息队列获取数据,向mq消息队列回应(扣款成功),mq消息队列向客户端回应(支付成功)

主流的MQ消息中间件(Kafka、RabbitMQ、ActiveMQ):

  apache是apache软件基金会的一个开放源码的网页服务器

  Kafka能够处理海量的数据(亿为单位),它的性能是非常好的,但是对数据的一致性要求不高

  RabbitMQ主要应用于一般的服务,对数据的一致性,可靠性,安全性要求高但是性能很差劲。

  RabbitMQ数据持久化使用的是那个参数?durable=true

接口自动化测试流程:

  (1)先梳理出系统当中哪些是可以做接口自动化测试的,梳理完成之后,然后找相关的领导对一下,看下梳理是否正确

  (2)梳理的这些内容我们通过哪些时间节点去完成,梳理对完之后

  (3)编写代码

  (4)编写代码完成后,叫上相关的人员评审我们编写的代码,评审的目的有3个

   第一个看下写的代码是否正确   第二看下测试场景是否考虑周全  第三 断言是否正确
  (5)评审完成后,再在大家的意见的基础之上完善代码,代码完善后,我把它整合到jenkins持续集成的平台,这样在下一个版本的时候,我直接点击立即构建,我们就可以执行了

详细描述下使用postman是怎么做API的测试的?

  首先创建一个collection,添加请求,在请求方法下拉框我们选择请求方法,request url 我们填写请求地址,headers  我们填写请求头,body 里面我们根据不同的数据格式,填写请求数据。tests填写断言
  我们以json为例:body里面  raw  下拉框选择json 然后填写json的请求数据

详细描述下使用jmeter是怎么做API的测试的?

  首先我们创建一个测试计划,测试计划里面我们添加一个线程组,线程组里面我们可以添加具体的测试用例,添加完成后 我们执行,然后我们结合ant构建工具,以及ant构建工具当中的build.xml 文件,build.xml 文件当中我们定义了测试脚本,以及生成测试报告,还有就是自动发送邮件的信息,那么这样我们最后把它整合到jenkins持续集成平台上,jenkins持续集成平台整合完成后,在下一个迭代应用的时候,我们直接点击立即构建

  1、首先在JMeter里面创建测试计划,在测试计划里面创建线程组
  2、在线程组里面添加HTTP的请求,以及添加API的测试用例
  3、编写测试用例结束后,结合Ant构建工具,编写build.xml文件(执行脚本,测试报告目录,自动发送邮件)
  4、在build.xml文件的目录下执行ant,就会自动执行
  5、最后整合到Jenkins持续集成的平台,那么在下个版本中,只需要点击构建就能够自动化的执行

postman和jmeter的区别

  Jmeter和postman 相比 我们用的jmeter比较的多 因为  postman 中断言写100个  它的测试报告给我们的错觉是写了100个测试用例  所以 jmeter相对而言 比较的好些 不会给人这种错觉   。

谈谈你对postman中collection的理解?

  (1)测试套件:是测试用例的集合,在一个测试套件里面,有很多个测试用例。每一个独立的请求在测试里面,都叫测试用例 testcase。
  (2)Collection的目的:把所有的测试用例组织起来,并且一次性的执行,得到测试报告;解决API测试中参数关联这部分。

Postman动态参数处理逻辑是什么?Postman参数之间的关联在代码里面怎么解决?

  我们可以通过函数的返回值把这个动态参数写入一个文件,然后需要的时候我们读取这个文件 向下传递

JMeter动态参数处理逻辑是什么?

以登录为案例,登录成功后返回的TOKEN每次都是不一样的,这个值就是动态参数,那么在登录成功后的接口中(如首页)需要调用到这个TOKEN:
  1、在登录的接口中添加后置处理器中的JSON提取器,定义一个变量获取登录成功后返回的token的值
  2、在下个接口(如首页)中通过${}来调用这个变量
  3、执行线程组中的任务,就能够实现参数的上下关联

什么是mockserver?

  Mock本意就是模拟或者效仿,我们可以把Mock理解为一个替身,在软件开发领域,通常就是指模拟对象,故mockserver就可以理解为测试替身的服务。Mock是为了解决不同的单元之间由于耦合而难于开发、测试的问题。所以Mock既能出现在单元测试中,也会出现在集成测试、系统测试过程中。在官网选择下载  Standalone Moco Runner ,下载之后,你将会得到一个 moco-runner-1.3.0-standalone.jar 文件。

场景:测试过程中,没有数据怎么办?解决办法,自己造数据(手动造数据或者代码造数据),自己moco数据。

(1)自己造数据,编写HTTP请求的json文件,将其和moco放在同一位置;

(2)打开控制台,进入到存放moco和json文件的目录,运行如下命令: java -jar moco-runner-1.3.0(moco版本)-standalone.jar http -p 12306(指定的端口) -c product.json(文件名);

(3)打开postman运行HTTP请求。

怎么判断前端问题还是后端问题?

  1、没有发送网络请求,错误提示信息不正确,是前端问题
  2、如果有网络请求,并且错误提示信息不正确,那么是后端的问题
  3、假设正确展示是456,页面展示信息是123,但是是错误的,查看后端返回的是不是123,如果后端返回的是456,那么是前端问题,如果后端返回的是123,那么是后端问题

针对一个服务,你怎么测试?

  1、正常功能
  2、异常功能
    A、请求参数是必须填写,但是没有带,后台有没有做判断
    B、请求参数的数据类型是否做了判断
    C、特定参数需要特定的值
    D、请求参数超过长度的限制
  3、安全测试,主要指的是服务是否做了认证授权
  4、性能测试(这个服务同时多少个人可以访问)
  5、稳定性测试(指的是验证一个服务的稳定性)

 

标签:总结,请求,接口,cookie,测试,参数,服务端,客户端
来源: https://www.cnblogs.com/wrwangrong/p/16525930.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有