本文共 4329 字,大约阅读时间需要 14 分钟。
什么是接口测试
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等
接口测试流程
需求讨论,需求评审,场景设计,编写用列,准备数据,执行测试
a)需求评审,熟悉业务和需求 b)开发提供接口文档(必须提供接口说明、url、请求方法、请求参数、参数类型、请求参数说明及返回参数说明) c)编写接口测试用例 d)进行用例评审 e)提测后开始测试 f)提交测试报告http协议get和post请求方式区别
get请求:从指定的服务器中获取数据,直接在浏览器里输入就可以获取信息
post的请求:提交数据给指定的服务器处理,可以向服务器发送修改请求,从而修改服务器的,需要借助测试工具;做接口测试如何分析是前段还是后端的问题?
如果发送的数据是正确的,但是后台反馈的数据是不符合需求的,那就是后台的问题;如果前端没有请求接口,或者请求的时候发送数据与需求不符,那这个时候就是前端的问题了
session和cookies区别?
1、cookie数据存放在客户的浏览器上,session数据放在服务器上。
2、cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗 考虑到安全应当使用session。 3、session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能 考虑到减轻服务器性能方面,应当使用COOKIE。 4、单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie。 5、所以个人建议: 将登陆信息等重要信息存放为SESSION 其他信息如果需要保留,可以放在COOKIE中怎么抓取HTTPS协议?
使用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协议区别?实现机有什么不同?
1.http是超文本传输协议,信息是明文传输;https是具有安全性的ssl传输协议。 2. http与https使用的是不同的连接方式,端口也一样,http默认端口是80;https默认端口是443; 3. http连接状态比较简单,是无状态的;https协议是由ssl+http协议组成的可进行传输、身份认证的网络协议。在测试接口中怎么知道请求成功还是失败?
根据接口请求时接口的返回状态码来判断,状态码以4或5开头就可以视为请求失败
说出请求接口中常见的返回状态码?
1xx - 信息提示
2xx - 成功 3xx - 重定向 4xx - 客户端错误 5xx - 服务器错误(200.201.204.304.400.401.403.404.410.500.503)怎么设计接口测试用例?
目的:测试接口的正确性和稳定性;
原理:模拟客户端向服务器发送请求报文,服务器接收请求报文后对相应的报文做处理并向客户端返回应答,客户端接收应答的过程; 重点:检查数据的交换,传递和控制管理过程,还包括处理的次数; 核心:持续集成是接口测试的核心; 优点:为高复杂性的平台带来高效的缺陷监测和质量监督能力,平台越复杂,系统越庞大,接口测试的效果越明显(提高测试效率,提升用户体验,降低研发成本); 用例设计重点:通常情况下主要测试最外层的两类接口:数据进入系统接口(调用外部系统的参数为本系统使用)和数据流出系统接口(验证系统处理后的数据是否正常); PS:设计用例时还需要注意外部接口提供给使用这些接口的外部用户什么功能,外部用户真正需要什么功能;因为不同端(前段,后端)的工作进度不一样,所以我们要针对最开始出来的接口,以及需要调用其他公司的(银行,支付宝,微信,qq等)一些接口进行接口测试及验证数据,从安全层面来说,只依赖前端进行限制已经完全不能满足系统的安全要求(绕过前面实在太容易),需要后端同样进行控制,在这种情况下就需要从接口层面进行验证。前后端传输、日志打印等信息是否**传输也是需要验证的,特别是涉及到用户的隐私信息,如身份证,银行卡等
tps就是每秒事务数,transaction per second。吞吐量下降是可能因为频繁访问redis,而频繁访问redis的原因是参数过多,解决的思路很容易想到: 减少参数。我们可以把多组参数变成json字符串之类的一个参数,从而达到信息量不减少而参数个数变少的效果。
对称加密: 信息交换的双方使用同一个密钥加密解密,就像是用同一把钥匙开一把锁非对称加密公开密钥加密(英语:Public-key cryptography),也称为非对称加密(英语:asymmetric cryptography),是密码学的一种算法,它需要两个密钥,一个是公开密钥,另一个是私有密钥;一个用作加密的时候,另一个则用作解密。使用其中 一个密钥把明文加密后所得的密文,只能用相对应的另一个密钥才能解密得到原本的明文;甚至连最初用来加密的密钥也不能用作解密。由于加密和解密需要两个不 同的密钥,故被称为非对称加密;不同于加密和解密都使用同一个密钥的对称加密。虽然两个密钥在数学上相关,但如果知道了其中一个,并不能凭此计算出另外一 个;因此其中一个可以公开,称为公钥,任意向外发布;不公开的密钥为私钥,必须由用户自行严格秘密保管,绝不通过任何途径向任何人提供,也不会透露给要通 信的另一方,即使他被信任。基于公开密钥加密的特性,它还提供数字签名的功能,使电子文件可以得到如同在纸本文件上亲笔签署的效果
UI与接口测试的协同可以从下面的方向考虑UI的操作实际上就是用另一种方式调用接口,那么接口有多少种参数组合就要求UI用例要构造多少种操作进行调用UI操作所需要的数据可以用接口来生成接口测试可以保证数据和逻辑的准确性,UI测试需要考虑交互和界面展示的逻辑正确性UI测试需要重视接口调用不成功或者接口异常情况下UI的呈现方式和用户体验UI中可能会有一些状态的缓存信息(这样就不需要每次频繁调用接口去获取了),比如鉴权信息等,需要重点关注这些缓存的更新策略
上下游接口的数据依赖无非就是准备测试数据。假如一个事务需要顺序调用3个接口,A B C, C依赖于AB, 而AB有数据依赖,这时候就需要准备好A和B的数据。数据一般有两种方式生成动态方式:假如B依赖A创造的数据,那么每次执行B之前必须执行A去做数据创建静态方式:独立统一的测试数据库, ABC需要的数据都可以从库里拿到
依赖第三方就mock掉,可以自己写mock server
---待补充
依赖登录态,那么每次测试该接口之前都需要调用登录的接口如果是jwt之类的token based auth的话,每次在调用接口时提供token就可以了
修改的接口,也就是update的接口一般只需要传:被更新了的字段 以及 被更新实体的 主键 比如id。这是开发常识,如果大家研究过jsonapi规格的话,可以直接套用jsonapi的设计进行阐述。
swagger文档可以解决这个问题。()swagger是我用过最好用的,只是编写相关的json比较麻烦,又不想集成在代码中。不过可以在网站(www.sosoapi.com)上在线表单方式编写swagger-ui对应的json哈,编辑简单而且可以在线预览和导入导出,挺方便的。
转载地址:http://awiwi.baihongyu.com/