接口自动化测试
接口测试流程
1.编写测试计划
2.编写、评审接口测试用例
3.执行接口测试
流程
1.拿到api接口文档,熟悉接口业务,地址,端口,鉴权,入参和结果,错误码。
2.编写接口测试用例以及评审
正例:输入正常的参数,验证接口能够正常返回。(只对内部系统)
反例:(只对外部系统)
- 鉴权异常:为空,错误,过期…
- 参数异常:为空,长度异常,类型异常,其他业务异常…
- 其他异常:黑名单,调用次数限制。
- 兼容异常:一个端口被多段调用,版本的兼容。
接口类型
1.基于webservice协议接口,通过xml传输数据
2.基于dubbo(微服务)协议接口,通过json传输数据
3.基于http协议接口,通过json传输数据
函数
Randomxx:生成相对于类型的随机数。
time:生成戳,位数较长,可能会超出边界
加密接口
AES,DES,Base64
RSA
MD5,SHA,HmacSHA
jmeter只封装了Base64,MD5,SHA。扩展口:BeanShell组件:Java语言以及它自带的BeanShell语法;
上面四种可以被破解,下面不能解密。
加密网址:www.bejson.com
md5加密:${__MD5(admin,)} jmeter只支持32位小写
使用digest函数可以包括多种加密方式,如果是SHA1,就输入SHA-1。注意不支持SHA3。
加密算法类型
接口加密测试详解以及实现原理
1.单向加密
2.双向加密
不支持情况下解决方案:
1.使用java代码加密了,然后打包成jar包。然后再测试计划中调用jar包。
2.使用python代码加密。然后在jmeter里面调试python代码。
- 对称加密:加密和解密的秘钥相同
- 特点:加密时间短效率高,算法简单,适合机密大量数据。
- 缺点:安全性差,扩展性差。
- 非对称加密
- 特点:安全性高,加密和解密的秘钥不相同(公钥,私钥)。
- 缺点:加密复杂,只适合加密少量数据。
签名规则:
一般:username(appid),password(appsecret),nonce(流水号,订单号,timestamp(时间戳),params参数,body参数)
Cookie鉴权
Cookie是一段文本,json格式,键值对。
回话级Cookie和持久化Cookie。
token可以通过cookie来传值
HTTP Cookie管理器实现Cookie关联的原理:(默认作用域在同级别的组件)
1:当jmeter第一次请求服务器的时候,如果说服务器有通过响应头的Set-Cookie有返回Cookie,那么HttpCookie管理器就会自动的保存这些Cookie的值。
2:然后当Jmeter第2-N次请求服务器的时候,那么HttpCookie管理器就会自动的把保存的这些Cookie通过请求头的Cookie字段传输给服务器,从而实现Cookie关联。
Jmeter的非GUI命令行的执行
jmeter -n -t test.jmx
-n:指非界面的方式
-t:指要运行的脚本
这个命令运行完之后会出现一个jmeter的日志文件
jmeter -n -t test.jmx -l result.jtl
生成jtl测试报告
jmeter -n -t test.jmx -l result.jtl -e -o
-e:代表生成html报告
-o:代表输出目标位置
此命令需要配置文件中此条配置#jmeter.save.saveservice.output_format=csv
为默认csv才能成功
使用Ant执行接口测试脚本
1.下载并且解压ant,需要配置环境变量
新建ANT_HOME环境变量:
ANT_HOME:D:\BaiduNetdiskDownload\apache-ant-1.9.16
在path下新增:
%ANT_HOME%\bin
2.编辑执行和构建的报告的文件:bulid.xml
更改资源路径
3.配置全局文件jmeter.propties
jmeter.save.saveservice.output_format=xml
csv改为xml
4.运行
在bulid.xml位置在控制台输入ant,出现bulid success就是构建成功
postman使用
Pre-request Script(预请求脚本):请求之前的脚本
Tests(测试):请求之后的脚本
cookie:是用来自动管理cookie的功能
关联
在测试写提取代码,使用{{Authorization}}
json提取器:
var name = JSON.parse(responseBody);
var Authorization = name.token;
pm.environment.set("Authorization", Authorization);
正则表达式提取器:
var token = responseBody.match(new RegExp('"Authorization":"(.*?)"'));
JSON库的时使用
#dumps函数,将python字典序列化成json对象
import json
str1 = {"name":"aaa"}
str1_json = json.dumps(str1)
#loads函数,将json对象反序列化成python字典
str2 = json.loads(str1_json)
自动化测试流程
1.需求分析
2.挑选适合做自动化测试的功能
3.设计测试用例
4.搭建自动化测试环境[可选]
5.设计自动化项目架构[可选]
6.编写代码
7.执行测试用例
8.生成测试报告并分析结果
1.将功能用例转化成自动化用例
2.搭建自动化测试环境(本机依赖的环境)
3.搭建自动化框架(po模式+数据驱动+log+报告)
4.编写代码
5.执行测试用例
6.生成测试报告并分析结果
### cls和self的不同
cls指的是类,而 self 指的是实例。使用cls关键字,我们只能访问类的成员,而使用 self 关键字,我们可以访问实例变量和类属性。
使用cls,我们无法访问类中的实例变量。cls作为参数传递给类方法,而 self 作为参数传递给实例方法。如果我们使用self初始化变量,它们的作用域就是实例的作用域。但是,使用cls初始化的变量将类作为其作用域。
## YAML文件——实现接口自动化
1.用于全局配置文件ini/yaml
2.用于写测试用例(接口测试用例)
yaml读取之后是字典
使用request.session()可以自动获取cookie
yaml中等null就等于python中的none
## requests库以及调用逻辑
```python
def get(url, params=None, **kwargs):
url:接口地址
params:参数
**kwargs:可变长度的字典
def post(url, data=None, json=None, **kwargs):
data:参数(表单参数--x-www-form-urllencoded)
json:参数(json参数)
def put(url, data=None, **kwargs):
def delete(url, **kwargs):
#以上四种方法都是调用的requests.request()方法
def request(method, url, **kwargs):
#此方法调用的是session.request(method=method, url=url, **kwargs)
def request(self,
method,
url,
params=None, 相当于url的?&&
data=None,
headers=None, 请求头
cookies=None, cookies信息
files=None,文件上传
auth=None, 鉴权
timeout=None, 超时时间
allow_redirects=True, 是否允许重定向
proxies=None,设置代理
hooks=None, 钩子
stream=None, 文件下载
verify=None, 证书验证
cert=None, CA证书
json=None):
requests.request()和session.request()的区别:前者的每个请求都是独立的,后者会自动关联所有请求的cookie信息
Requests响应部分:
res.text 返回字符串形式的结果
res.json() 返回字典形式的结果
res.content() 返回字节形式的结果
res.status_code 返回状态码
res.reason 返回状态信息
res.cookie 返回cookie信息
res.encoding 返回编码格式
res.headers 返回响应头
res.request.xx 得到请求数据
正则表达式提取
re.seach() 匹配一个值,通过下标[1]取值,没有则返回none
re.findall() 匹配多个值,通过下标取值,没有则返回none
re.seach('(.*?)',res.text).group(1)
统一请求封装
1.去重很多重复的,冗余的代码
2.实现统一的异常处理以及日志监控、
import requests
class RequestUtil:
session = requests.session()
#统一请求封装
def send_request(self, **kwargs):
res = RequestUtil.session.request(**kwargs)
return res
服务器状态码
- 服务器状态码是在用户试图通过 HTTP 或文件传输协议 (FTP) 访问一台正在运行 Internet 信息的服务器内容时,IIS 返回的一个表示该请求状态的数字代码。
- 该状态代码记录在 IIS 日志中,同时也可能在 Web 浏览器或 FTP 客户端显示。状态代码可以指明具体请求是否已成功,还可以揭示请求失败的确切原因。
状态码首位数字
1
>> 开始发送请求 >>消息
2
>> 请求发送完成 >>成功
3
>> 开始读取响应 >>重定向
4
>> 读取响应结束 >>请求错误
5
表示服务器错误
常见服务器状态码
- 200:服务器响应正常,并正确返回。
- 304:该目标资源在上次请求后没有任何修改(通常用于浏览器的缓存机制,使用GET请求时尤其需要注意)
- 400:无法找到请求的资源,可能原因:
- (1) 语义有误,当前请求无法被服务器理解。
- (2) 请求参数有误。
- 401:要访问的目标资源的权限不够,或者说当前请求需要用户验证;
- 403:没有权限访问资源。
- 404:找不到访问的对象,或者要访问的目标资源不存在。
- 405:要访问的目标资源被禁止。
- 414:请求的URL太长。
- 500:服务器内部代码错误。
更多状态码
- 100——客户必须继续发出请求
- 101——客户要求服务器根据请求转换HTTP协议版本
- 200——交易成功
- 201——提示知道新文件的URL
- 202——接受和处理、但处理未完成
- 203——返回信息不确定或不完整
- 204——请求收到,但返回信息为空
- 205——服务器完成了请求,用户代理必须复位当前已经浏览过的文件
- 206——服务器已经完成了部分用户的GET请求
- 300——请求的资源可在多处得到
- 301——删除请求数据
- 302——在其他地址发现了请求数据
- 303——建议客户访问其他URL或访问方式
- 304——客户端已经执行了GET,但文件未变化
- 305——请求的资源必须从服务器指定的地址得到
- 306——前一版本HTTP中使用的代码,现行版本中不再使用
- 307——申明请求的资源临时性删除
- 400——错误请求,如语法错误
- 401——请求授权失败
- 402——保留有效ChargeTo头响应
- 403——请求不允许
- 404——没有发现文件、查询或URl
- 405——用户在Request-Line字段定义的方法不允许
- 406——根据用户发送的Accept拖,请求资源不可访问
- 407——类似401,用户必须首先在代理服务器上得到授权
- 408——客户端没有在用户指定的时间内完成请求
- 409——对当前资源状态,请求不能完成
- 410——服务器上不再有此资源且无进一步的参考地址
- 411——服务器拒绝用户定义的Content-Length属性请求
- 412——一个或多个请求头字段在当前请求中错误
- 413——请求的资源大于服务器允许的大小
- 414——请求的资源URL长于服务器允许的长度
- 415——请求资源不支持请求项目格式
- 416——请求中包含Range请求头字段,在当前请求资源范围内没有range指示值,请求也不包含If-Range请求头字段
- 417——服务器不满足请求Expect头字段指定的期望值,如果是代理服务器,可能是下一级服务器不能满足请求
- 500——服务器产生内部错误
- 501——服务器不支持请求的函数
- 502——服务器暂时不可用,有时是为了防止发生系统过载
- 503——服务器过载或暂停维修
- 504——关口过载,服务器使用另一个关口或服务来响应用户,等待时间设定值较长
- 505——服务器不支持或拒绝支请求头中指定的HTTP版本