http接口工具有很多如:postman、jmeter、soupUI、Java+httpclient、robotframework+httplibrary等
接口就是内部模块对模块,外部系统对其他服务提供的一种可调用或者连接的能力的标准
接口的种类和分类:webservice和http api接口
1)webservice接口是走soap协议通过http传输,请求报文和返回报文都是xm格式,可以通过jme、soapui工具进行测试;
2)http api接口是走http协议通过路径来区分调用的方法,请求报文格式都是key-value形式,返回报文一般是json串,常见的请求方式有get、post请求等;
1.什么是接口测试
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等
2.接口测试流程
需求讨论,需求评审,场景设计,编写用列,准备数据,执行测试
需求评审,熟悉业务和需求
开发提供接口文档(必须提供接口说明、url、请求方法、请求参数、参数类型、请求参数说明及返回参数说明)
编写接口测试用例
进行用例评审
提测后开始测试
提交测试报告
3.http协议get和post请求方式区别
get请求:从指定的服务器中获取数据,直接在浏览器里输入就可以获取信息
post的请求:提交数据给指定的服务器处理,可以向服务器发送修改请求,从而修改服务器的,需要借助测试工具;
如果发送的数据是正确的,但是后台反馈的数据是不符合需求的,那就是后台的问题;如果前端没有请求接口,或者请求的时候发送数据与需求不符,那这个时候就是前端的问题了
cookie数据存放在客户的浏览器上,session数据放在服务器上。
cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,考虑到安全应当使用session。
session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能考虑到减轻服务器性能方面,应当使用COOKIE。
单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie。
所以个人建议:
将登陆信息等重要信息存放为SESSION
其他信息如果需要保留,可以放在COOKIE中
使用Fiddler抓取HTTPS协议主要由以下几步进行:
第一步,Fiddler截获客户端发送给服务器的HTTPS请求,Fiddler伪装成客户端向服务器发送请求进行握手 。
第二步,服务器发回相应,Fiddler获取到服务器的CA证书, 用根证书(这里的根证书是CA认证中心给自己颁发的证书)公钥进行解密, 验证服务器数据签名, 获取到服务器CA证书公钥。然后Fiddler伪造自己的CA证书(这里的CA证书,也是根证书,只不过是Fiddler伪造的根证书), 冒充服务器证书传递给客户端浏览器。
第三步,与普通过程中客户端的操作相同,客户端根据返回的数据进行证书校验、生成密码Pre_master、用Fiddler伪造的证书公钥加密,并生成HTTPS通信用的对称密钥enc_key。
第四步,客户端将重要信息传递给服务器, 又被Fiddler截获。Fiddler将截获的密文用自己伪造证书的私钥解开, 获得并计算得到HTTPS通信用的对称密钥enc_key。Fiddler将对称密钥用服务器证书公钥加密传递给服务器。
第五步,与普通过程中服务器端的操作相同,服务器用私钥解开后建立信任,然后再发送加密的握手消息给客户端。
第六步,Fiddler截获服务器发送的密文, 用对称密钥解开, 再用自己伪造证书的私钥加密传给客户端。
第七步,客户端拿到加密信息后,用公钥解开,验证HASH。握手过程正式完成,客户端与服务器端就这样建立了”信任“。
在之后的正常加密通信过程中,Fiddler如何在服务器与客户端之间充当第三者呢?
服务器—>客户端:Fiddler接收到服务器发送的密文, 用对称密钥解开, 获得服务器发送的明文。再次加密, 发送给客户端。
客户端—>服务端:客户端用对称密钥加密,被Fiddler截获后,解密获得明文。再次加密,发送给服务器端。由于Fiddler一直拥有通信用对称密钥enc_key, 所以在整个HTTPS通信过程中信息对其透明。
http是超文本传输协议,信息是明文传输;https是具有安全性的ssl加密传输协议。
http与https使用的是不同的连接方式,端口也一样,http默认端口是80;https默认端口是443;
http连接状态比较简单,是无状态的;https协议是由ssl+http协议组成的可进行加密传输、身份认证的网络协议。
根据接口请求时接口的返回状态码来判断,状态码以4或5开头就可以视为请求失败
1xx - 信息提示
2xx - 成功
3xx - 重定向
4xx - 客户端错误
5xx - 服务器错误(200.201.204.304.400.401.403.404.410.500.503)
目的:测试接口的正确性和稳定性;
原理:模拟客户端向服务器发送请求报文,服务器接收请求报文后对相应的报文做处理并向客户端返回应答,客户端接收应答的过程;
重点:检查数据的交换,传递和控制管理过程,还包括处理的次数;
核心:持续集成是接口测试的核心;
优点:为高复杂性的平台带来高效的缺陷监测和质量监督能力,平台越复杂,系统越庞大,接口测试的效果越明显(提高测试效率,提升用户体验,降低研发成本);
用例设计重点:通常情况下主要测试最外层的两类接口:数据进入系统接口(调用外部系统的参数为本系统使用)和数据流出系统接口(验证系统处理后的数据是否正常);
PS:设计用例时还需要注意外部接口提供给使用这些接口的外部用户什么功能,外部用户真正需要什么功能;
因为不同端(前段,后端)的工作进度不一样,所以我们要针对最开始出来的接口,以及需要调用其他公司的(银行,支付宝,微信,qq等)
一些接口进行接口测试及验证数据,从安全层面来说,只依赖前端进行限制已经完全不能满足系统的安全要求(绕过前面实在太容易),需要后端同样进行控制,在这种情况下就需要从接口层面进行验证。前后端传输、日志打印等信息是否加密传输也是需要验证的,特别是涉及到用户的隐私信息,如身份证,银行卡等。
作者:仅仅
链接:https://zhuanlan.zhihu.com/p/259184946