接口测试基础知识介绍

一、接口测试流程

  1. 阅读分析API接口文档
  2. 场景设计编写测试用例
  3. 根据测试用例进行API的手工测试   

              3.1开发API工具,使之能测试产品

              3.2使用工具进行测试

              

二、编写测试用例

单个用例基本格式:1.前置条件 2.输入操作 3.预期输出

接口测试用例模板可以参照以下两种模板,如下:

  • 接口用例模板1

  •  接口用例模板2

 注意:实际工作场景中我们可能还会对接口之间的串联和混合场景进行测试

 举个混合场景接口测试例子如下:

、接口测试报告

接口测试报告就是在接口测试完成后梳理总结出的一份文档,是指把测试的过程和结果写成文档,对发现的问题和缺陷进行分析,为纠正软件的存在的质量问题提供依据,同时为软件验收和交付打下基础。

接口测试报告一般包含以下内容:

 <解析>

3.1系统接口概况 

简要描述与测试项目相关的一些背景资料,如被测系统简介,项目上线计划等。

对于系统接口的定义和设计做出介绍。

比如系统一共有多少个接口?采用哪种协议?都涉及到哪些发送方法?采用怎样的请求格式?使用怎样的返回标准?可用表格说明。

3.2测试目的与范围

测试目的

本次测试的目的在于确保系统接口功能和逻辑处理已验证,符合《接口定义说明书》的定义和要求,满足系统需要。

测试对象范围

说明测试的对象是哪些

  • 单场景接口功能测试
  • 混合场景接口功能测试

详见《项目接口测试用例》可考虑贴出x-mind图

测试指标范围

  • 被测接口接收请求和返回报文
  • 被测接口返回状态
  • 被测接口对应业务逻辑处理
  • 涉及数据沉淀的处理
  • 复杂场景下多接口串联交互

3.3测试工具及资源

测试工具

说明本次测试使用到的测试工具和辅助工具

测试工具:该测试将使用Postman(例)

Postman是谷歌的一款接口测试插件,它使用简单,支持用例管理,支持get、 post、文件上传、响应验证、变量管理、环境参数管理等功能,可以批量运 行,并支持用例导出、导入。

测试资源:**人

3.4测试记录及结果分析

  •  单场景接口测试

给出本次单场景接口测试的测试结果数据

可以用表格统计成功,失败个数,或图表

  • 测试问题及结果分析

结合测试中发现的问题对于整体测试结果进行分析,做出判断。

  • 接口业务功能错误类缺陷情况
  • 接口异常处理类缺陷情况
  • 接口处理数据沉淀缺陷类情况
  • 接口安全性缺陷情况 

混合场景接口测试

  • 测试结果数据
  • 给出本次混合场景接口测试的测试结果数据

结合测试中发现的问题对于整体测试结果进行分析,做出判断。

  • 混合接口业务功能错误类缺陷情况
  • 混合接口业务数据传递类缺陷情况

3.5测试结论

给出本次性能测试的测试总结论,一般以测试结果与测试目标的比较结果作为测试结论。

cookie和session的概念

  • 网站登录后--后面的操作,服务端怎么知道是前面登录的用户操作的呢?
  1. http协议被称为无状态的协议
  2. 访问前面的网页的http请求和访问后面网页的http请求是互不相干的,是独立的
  • 什么是cookie
  1. cookie就是存放信息的地方
  2. cookie是我们在访问一个网站时,通常由网站服务器返回的一种标记为cookie类型的数据
  3. 要求我们存储在浏览器所在电脑上
  4. 以后每次访问本网站,浏览器都会在http请求中将该数据发送过来
  • token的概念
  1. token包含数据信息和验证信息

 四、接口测试基础知识

1、接口定义

接口测试主要用于外部系统与系统之间以及内部各个子系统之间的交互点,

定义特定的交互点,然后通过这些交互点来,通过一些特殊的规则也就是协议,

来进行数据之间的交互。

1.1什么是接口测试

  • 接口测试是测试系统组件间接口的一种测试。
  • 接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。
  • 测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。

1.2为什么要做接口测试

①.越底层发现bug,它的修复成本是越低的。 

②.前端随便变,接口测好了,后端不用变。前后端是两拨人开发的。

③.检查系统的安全性、稳定性,前端传参不可信,比如京东购物,前端价格不可能传入-1元,但是通过接口可以传入-1元。

④.如今的系统复杂度不断上升,传统的测试方法成本急剧增加且测试效率大幅下降,接口测试可以提供这种情况下的解决方案。

⑤. 接口测试相对容易实现自动化持续集成,且相对UI自动化也比较稳定,可以减少人工回归测试人力成本与时间,缩短测试周期,支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。

⑥.   现在很多系统前后端架构是分离的,从安全层面来说:

(1)、只依赖前端进行限制已经完全不能满足系统的安全要求(绕过前面实在太容易), 需要后端同样进行控制,在这种情况下就需要从接口层面进行验证。

(2)、前后端传输、日志打印等信息是否加密传输也是需要验证的,特别是涉及到用户的隐私信息,如身份证,银行卡等。

拓展:

可以发现很多在页面上操作发现不了的bug;检查系统的异常处理能力

1.3接口测试怎么进行

    • 通过性验证:首先肯定要保证这个接口功能是好使的,也就是正常的通过性测试,按照接口文档上的参数,正常传入,是否可以返回正确的结果。
    • 参数组合:现在有一个操作商品的接口,有个字段type,传1的时候代表修改商品,商品id、商品名称、价格有一个是必传的,type传2的时候是删除商品,
      商品id是必传的,这样的,就要测参数组合了,type传1的时候,只传商品名称能不能修改成功,id、名称、价格都传的时候能不能修改成功。

    • 接口安全:
      1、绕过验证,比如说购买了一个商品,它的价格是300元,那我在提交订单时候,我把这个商品的价格改成3元,后端有没有做验证,更狠点,我把钱改成-3,是不是我的余额还要增加?
      2、绕过身份授权,比如说修改商品信息接口,那必须得是卖家才能修改,那我传一个普通用户,能不能修改成功,我传一个其他的卖家能不能修改成功
      3、参数是否加密,比如说我登陆的接口,用户名和密码是不是加密,如果不加密的话,别人拦截到你的请求,就能获取到你的信息了,加密规则是否容易破解。
      4、密码安全规则,密码的复杂程度校验

    • 异常验证
        所谓异常验证,也就是我不按照你接口文档上的要求输入参数,来验证接口对异常情况的校验。比如说必填的参数不填,输入整数类型的,传入字符串类型,长度是10的,传11,总之就是你说怎么来,我就不怎么来,其实也就这三种,必传非必传、参数类型、入参长度。

    • 性能测试
      接口并发情况,如上面提到的:一个账号,同时(大于2个请求)对最后一个商品下单,或不同账号,对最后一个商品下单
      接口响应时间,响应时间太长了,肯定需要优化,一般都是毫秒级别

1.4上下游接口有数据依赖如何处理

用一个全局变量来处理依赖的数据,比如登录后返回token,其它接口都需要这个token,那就用全局变量来传token参数

1.5接口异常,如何分析异常

1.抓包,用fiddler工具抓包,或者浏览器上f12,app上的话,那就用fiddler设置代理,去看请求报文和返回报文了
2.查看后端日志,xhell连上服务器,查看日志

1.6如何分析bug是前端还是后端的

先抓包看请求报文,对着接口文档,看请求报文有没问题,有问题就是前端发的数据不对
请求报文没问题,那就看返回报文,返回的数据不对,那就是后端开发的问题

2、接口类型

a.程序内部的接口

系统对外的接口:比如你要从别的网站或服务器上获取资源或信息,别人肯定不会把数据库共享给你,他只能给你提供一个他们写好的方法来获取数据,你引用他提供的接口就能使用他写好的方法,从而达到数据共享的目的。

b.系统对外的接口

程序内部的接口:方法与方法之间,模块与模块之间的交互,程序内部抛出的接口,比如bbs系统,有登录模块、发帖模块等等,那你要发帖就必须先登录,那么这两个模块就得有交互,它就会抛出一个接口,供内部系统进行调用。

3、接口分类

a.webservice接口 

webService接口是走soap协议通过http传输,请求报文和返回报文都是xml格式的,我们在测试的时候都用通过工具才能进行调用,测试。

b.http api接口

http api接口是走http协议,通过路径来区分调用的方法,请求报文都是key-value形式的,返回报文一般都是json串,有get和post等方法,这也是最常用的两种请求方式。

原文地址:https://www.cnblogs.com/lixuefang69/p/10864133.html