接口测试

抓包作用:  网络,流量分析  数据分析  篡改数据,再次发送

工具:fiddler,wireshark,charles,浏览器网络监控

接口分类

  • 应用层<->service<->DB
  • service<->service<->service
  • 系统外部,第三方API--公共服务(如系统介入支付宝,微信的公共服务接口)

在这个过程中各层之间的交互就是通过接口:

  •  应用层与service主要通过http接口
  •  service层与DB层主要通过DAO(data access object)数据库访问接口)

网络服务接口的分类

  Restful API(简单的传输方式,传纸条)

     表现层状态转化

         资源

            URI指向它  

         HTTP协议里面,四个表示操作方向的动词, GET,POST,PUT,DELETE,改变资源的状态

  Web Service(完整的流程,可以封装各种协议,如http,socket,soap...,邮政系统)

      用xml来定义一个接口的信息(接口的方法、调用方式、参数说明)用一个文件来描述WSDL

      SOAP协议

         请求和响应的数据载体也是xml

         请求和响应要按照一定的规则进行封装--信封

        底层也要借助于各种网络协议传输(最常见绑定http协议)  

开放接口项目地址:http://www.webxml.com.cn/zh_cn/index.aspx  

Http协议基础

应用层协议,无状态。标准的客户端服务器模型,由请求和响应构成

URL结构  

  http://host[":"port][abs_path]

HTTP请求

   请求行

      请求地址,协议版本,请求方法名

   请求报文头:以明文字符串格式传送,以冒号分隔的键值对   请求头部通知服务器有关客户端请求的信息

      User-Agent、Accept、Accept-Encoding、Content-Type

   请求正文:数据内容

       四种格式:

       1.application/x-www-form-urlencoded

          对数据进行序列化处理,以键值对形式

         key1=value1&key2=value2的方式发送到服务器

            2.multipart/form-data

         将表单中数据全部上传,包括文件

            3.字符串文本格式:raw

         text/plain:纯文本,浏览器不解析

         text/html:html,浏览器自动解析

         text/xml或application/xml:后者可指定编码格式

         application/json:消息主体是序列化后的JSON字符串

            4.二进制格式:binary

HTTP响应

 响应行

     HTTP-Version表示服务器http协议的版本

     Status-Code表示服务器发回的响应状态代码

 响应报文头:以明文的字符串格式传送,以冒号分隔的键值对

     响应头部通知客户端有关服务端的应答消息

    Server、Content-Type

 响应正文:待测试的数据

    html --文本检索、样式内容浏览器检查

    xml、json -- 解析后获取关键数据

 

GET与POST请求的区别

1. GET请求没有请求体,POST请求有请求体(请求正文)

2. GET请求的参数(需要传递的数据)要放在URL中发送,大小有限制,POST请求的参数可以放在URL后传递,也可以放在请求体中(大小不受限制)

3. GET安全性相对较差

   a. 参数明文

   b. 数据会被浏览器缓存

4. 重大区别

  GET产生一个TCP数据包,POST产生2个数据包;对于GET请求,浏览器会把http header和data一并发送出去,服务器响应200;而对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200

5. 设计用途不同

    GET用来查询--不操作数据,参数量小

    POST用来插入、更新数据--安全要求高,数据量大

接口测试流程

 输入数据->发送请求->输出结果->获取响应->检查响应

特点:端到端的测试,重点通过不同的输入数据组合,检查数据的传输:

   测试业务逻辑

   测试数据库读写

   覆盖代码分支

1. 弥补传统UI测试的不足

    -很多系统没有界面,只提供接口功能,无法通过界面的方式进行测试

    -你只测了前端页面可以测试的功能,服务端的功能你又覆盖了多少?

      服务端的所有功能接口都正常吗?

      每个接口返回的每个字段是否正确   绕过前端的校验,接口是否有必要的异常处理

    -当APP的代码不更新,而服务器端代码更新时,直接通过接口自动化测试就能快速知道是否影响APP的功能

  2. 安全方面(SQL注入,1'OR'1'='1)  

  接口返回的字段是否包含多余信息(比如用户id,token等敏感字段)

  用户密码,其他用户隐私信息传输时都需要进行加密后传输

  接口是否存在防刷限制

在手工接口测试或者自动化接口测试的过程中,上下游接口有数据依赖如何处理?依赖于第三方数据的接口如何进行测试?  在工具中可以使用全局变量等方式将需要的数据进行传送,可以使用SoapUI等工具直接调用第三方数据接口的webservice,通过返回值来查看第三方数据的接口是否调用正常。 也可以利用一些MOCK的工具来模拟第三方的数据返回,最大限度的降低对第三方数据接口的依赖  

 

 

 

 

 

                         

 

posted @ 2019-03-29 16:43  lagjaflgjfl  阅读(202)  评论(0编辑  收藏  举报