接口测试

1.接口?

接口测试主要用于外部系统与系统之间以及内部各个子系统之间的交互点,定义特定的交互点,然后通过这些交互点来,通过一些特殊的规则也就是协议,来进行数据之间的交互。

接口的分类:1.webservice接口 2.http api接口

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

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

json是一种通用的数据类型,所有的语言都认识它。(json的本质是字符串,他与其他语言无关,只是可以经过稍稍加工可以转换成其他语言的数据类型,比如可以转换成Python中的字典,key-value的形式,可以转换成JavaScript中的原生对象,可以转换成java中的类对象等。)

2 什么是接口测试?

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

其实就是通过过URL向服务器或者其他模块等,传输我们想传输的数据,然后看看他们返回的是不是我们预期结果。

3 为什么要做接口测试?

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

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

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

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

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

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

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

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

4 测试点是什么?

目的:测试接口的正确性和稳定性;

原理:模拟客户端向服务器发送请求报文,服务器接收请求报文后对相应的报文做处理并向客户端返回应答,客户端接收应答的过程;

重点:检查数据的交换,传递和控制管理过程,还包括处理的次数;

核心:持续集成是接口测试的核心;

优点:为高复杂性的平台带来高效的缺陷监测和质量监督能力,平台越复杂,系统越庞大,接口测试的效果越明显(提高测试效率,提升用户体验,降低研发成本);

用例设计重点:通常情况下主要测试最外层的两类接口:数据进入系统接口(调用外部系统的参数为本系统使用)和数据流出系统接口(验证系统处理后的数据是否正常);

PS:设计用例时还需要注意外部接口提供给使用这些接口的外部用户什么功能,外部用户真正需要什么功能;


1、基本功能测试:

  由于是针对基本业务功能进行测试,所以这部分是两种测试重合度最高的一块,开发同学通常所指的也主要是这部分的内容。

2、边界分析测试:

  在基本功能测试的基础上考虑输入输出的边界条件,这部分内容也会有重复的部分(比如业务规则的边界)。但是,前端的输入输出很多时候都是提供固守的值让用户选择(如下拉框),在这种情况下测试的边界范围就非常有限,但接口测试就不存在这方面的限制,相对来说接口可以覆盖的范围更广,同样的,接口出现问题的概率也更高。

 3、性能测试:

 接口性能主要关注接口响应时间、并发、服务端资源的使用情况等。

5 接口测试流程:

1 需求讨论

2 需求评审

3 场景设计

4 用例设计

5 数据准备

6 执行

用例设计主要从以下几个方面进行: 

1 功能  

       功能是否正常

        功能是否按照接口文档进行实现

2 业务逻辑

       是否依赖业务

3 异常

     参数异常 

               关键字参数

                参数为空

                多、少参数

                错误参数

     数据异常

             关键字数据

             数据为空

              数据长度

              错误数据

4 安全

    cookie

   header    

   唯一识别码

6 测试工具

抓取工具(无接口文档):

httpwatch

fiddler

接口测试工具

fiddler

loudrunner

soapui(开源+商用)

postman(手动接口测试)

jmeter(开源)

接口测试持续集成:

      对接口测试而言,持续集成自动化是核心内容,通过持自动化的手段我们才能做到低成本高收益。目前我们已经实现了接口自动化,主要应用于回归阶段,后续还需要加强自动化的程度,包括但不限于下面的内容:

  a) 流程方面:在回归阶段加强接口异常场景的覆盖度,并逐步向系统测试,冒烟测试阶段延伸,最终达到全流程自动化。

  b) 结果展示:更加丰富的结果展示、趋势分析,质量统计和分析等

  c) 问题定位:报错信息、日志更精准,方便问题复现与定位。

  d) 结果校验:加强自动化校验能力,如数据库信息校验。

  e) 代码覆盖率:不断尝试由目前的黑盒向白盒下探,提高代码覆盖率。

  f) 性能需求:完善性能测试体系,通过自动化的手段监控接口性能指标是否正常。

 接口测试质量评估标准:

  a) 业务功能覆盖是否完整

  b) 业务规则覆盖是否完整

  c) 参数验证是否达到要求(边界、业务规则)

  d) 接口异常场景覆盖是否完整

  e) 接口覆盖率是否达到要求

  f)  代码覆盖率是否达到要求

  g) 性能指标是否满足要求

  h) 安全指标是否满足要求

 PS 1: 接口文档内容:

1、接口说明 

2、调用url

3、请求方法(get\post)

4、请求参数、参数类型、请求参数说明 

5、返回参数说明 

PS  2 :HTTP状态码:

每个发出去的http请求,都会返回一个状态码,用来标识这个请求是否成功,常见的状态码有以下几种:

1)200 2开头的表示请求成功

2)300 3开头的代表重定向

3)400 4开头的代表客户端发送的请求有语法错误

4)500 5开头的代表服务器有异常

PS 3 : webservice接口怎么测试:

它不需要你在拼报文了,会给一个webservice的地址,或者wsdl文件,直接在soapui导入,就可以看到这个webservice里面的所有接口,也有报文,直接填入参数调用,看返回结果就可以了。

天气预报wsdl地址:http://www.webservicex.net/globalweather.asmx?wsdl

 PS 4 : cookie与session的区别:

1、cookie数据存放在客户的浏览器上,session数据放在服务器上。

2、cookie不是很安全,别人可以分析存放在本地的cookie并进行cookie欺骗

考虑到安全应当使用session。

3、session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能

考虑到减轻服务器性能方面,应当使用cookie。

4、单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie。

5、所以个人建议:

将登陆信息等重要信息存放为session

其他信息如果需要保留,可以放在cookie中

工具应用参考:

https://www.cnblogs.com/shuaijie/articles/5913750.html

https://www.cnblogs.com/morning1/p/9083168.html

https://www.cnblogs.com/yoyoketang/tag/fiddler/

你可能感兴趣的:(接口测试)