一、幂等性测试
接口的幂等性测试就是多次调用该接口看它的结果是否和单次调用的结果一致:
如前端表单的多次提交;支付按钮的多次点击;弱网时接口调用超时多次点击提交等是否只生成唯一数据/只支付一次。
顺便了解一下开发是怎么实现接口的幂等的:
1、redis+token验证:验证客户端请求的token在Redis中是否存在;利用Redis命令操作的单线程的特点:可以实现高并发下的幂等
2、利用数据库主键的唯一性,插入时不能插入重复数据
3、执行插入前查询是否已存在该数据
二、断点
通常接口测试中的断点可以借助工具来说实现:
如我比较习惯用fiddler
断点可以设置在请求前和响应前
这时候可以对请求的值做一些修改来达到我们测试的目的
中断响应则可以对返回的参数进行修改
三、高并发测试
一般高并发多线程的测试我会使用Jmeter来做:
设置多长时间启用多少个线程数(示例是1s5000个线程)
填入接口信息和传入参数
设置请求头信息和结果树;开始运行。这样也可以验证高并发下接口的幂等性:看是不是只有第一次请求时返回的状态是成功。
http请求的头信息参数:
Accept: 允许哪些媒体类型。
Accept-Charset: 允许哪些字符集。
Accept-Encoding: 允许哪些编码。
Accept-Language: 允许哪些语言。
Cache-Control: 缓存策略,如no-cache,详见官方文档。
Connection: 连接选项,例如是否允许代理。
Host: 请求的主机。
If-None-Match: 判断请求实体的Etag是否包含在If-None-Match中,如果包含,则返回304,使用缓存,见Etag。
If-Modified-Since: 判断修改时间是否一致,如果一致,则使用缓存,。 、
If-Match: 与If-None-Match相反。
If-Unmodified-Since: 与If-Modified-Since相反。
Referer: 表明这个请求发起的源头。
User-Agent: 这个大家相信应该很熟悉了,就是经常用来做浏览器检测的userAgent。
Cache-Control: 缓存策略,如max-age:100,详见官方文档。
Connection: 连接选项,例如是否允许代理。
Content-Encoding: 返回内容的编码,如gzip。
Content-Language: 返回内容的语言。
Content-Length: 返回内容的字节长度。
Content-Type: 返回内容的媒体类型,如text/html。
Data: 返回时间。
Etag: entity tag,实体标签,给每个实体生成一个单独的值,用于客户端缓存,与If-None-Match配合使用。
Expires: 设置缓存过期时间,Cache-Control也会相应变化。
Last-Modified: 最近修改时间,用于客户端缓存,与If-Modified-Since配合使用。
Pragma: 似乎和Cache-Control差不多,用于旧的浏览器。
Server: 服务器信息。
Vary: WEB服务器用该头部的内容告诉 Cache 服务器,在什么条件下才能用本响应所返回的对象响应后续的请求。假如源WEB服务器在接到第一个请求消息时,其响应消息的头部为:Content-Encoding: gzip; Vary: Content-Encoding那么 Cache 服务器会分析后续请求消息的头部,检查其 Accept-Encoding,是否跟先前响应的 Vary 头部值一致,即是否使用相同的内容编码方法,这样就可以防止 Cache 服务器用自己 Cache 里面压缩后的实体响应给不具备解压能力的浏览器。
不得不提一句,apipost支持1-10000的一键并发
- 学习笔记梳理,不对请指正