接口测试理论和实操

一、接口测试基础及理论

一、接口基础知识

1、什么是接口?
软件提供给外部进行数据交互的一种服务。
2、软件为什么需要接口?
通过接口让内部的数据被外部修改。
3、为什么要进行接口测试?
(1)前后端分离进行,开发进度不一样,把开发完的接口先进行测试。
(2)安全性,前端容易被绕过,直接请求接口(身份信息、金钱)。
(3)测试左移,尽早进入测试。

二、接口测试返回数据

1、json格式 三组数据(大部分使用)(https://www.bejson.com/)
{error_code:0,msg:“xxx”,data:[]}
error_code:错误码,开发定义
msg:错误码的中文说明
data:真正返回的数据

1、json就是一种数据类型
2、json由两组数据组成
MAP对象(键值对){key:value}
数组:[value1,value2]

2、html格式

0 …… 3、xml格式 <?xml?versio="1.0"encoding="utf-8"> 0 ……

三、接口测试协议

1、webservice协议:接口地址:http://……?wsdl
soap协议,wsdl,请求方式提现在URL
restful规则:
get获取数据,post提交数据,put修改数据,delete删除数据
请求地址一样,通过不同的请求方式来发送不同的请求
2、dubbo协议:接口地址:dubbo://……
适用于少量数据的传输,大并发。
3、http协议:接口地址:http:// 大多数
https=http+ssl安全传输协议 端口:443
http 端口:80

什么是http协议?
http协议是超文本传输协议,主要用于浏览器和服务器之间交互数据,交互有两个部分:
请求:get、post、put、delete
响应:1xx信息,2xx成功,3xx重定向,4xx客户端错误,5xx服务端错误
http协议报文
1.请求报文(请求行/请求头/请求数据/空行)
请求行
求方法字段、URL字段和HTTP协议版本
例如:GET /index.html HTTP/1.1
get方法将数据拼接在url后面,传递参数受限
请求方法:
GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT
请求头(key value形式)
User-Agent:产生请求的浏览器类型。
Accept:客户端可识别的内容类型列表。
Host:主机地址
请求数据
post方法中,会把数据以key value形式发送请求
空行
发送回车符和换行符,通知服务器以下不再有请求头
2.响应报文(状态行、消息报头、响应正文)
状态行
消息报头
响应正文
(200 OK - [GET]:服务器成功返回用户请求的数据
201 CREATED - [POST/PUT/PATCH]:用户新建或修改数据成功
202 Aceepted - []:表示一个请求已经进入后台排队(异步任务)
204 NO CONTENT - [DELETE]:用户删除数据成功
400 INVALID REQUEST - [POST/PUT/PATCH]:用户发出的请求有错误,服务器没有进行新建或修改数据的操作
401 Unauthorized -[
] :表示用户没有权限(令牌、用户名、密码错误)
403 Forbidden -[] :表示用户得到授权(与401错误相对),但是访问被禁止
404 NOT FOUND -[
]:用户发出的请求针对得到是不存在的记录,服务器没有进行操作,该操作是幂等的
406 Not Acceptable - [GET]:用户请求的格式不可得(比如用户请求JSON格式,但是只有XML格式)
500 INTERNAL SERVER ERROR - [*]:服务器发生错误,用户将无法判断发出的请求是否成功)

四、接口测试流程和方案

1、拿到api接口文档,熟悉接口的业务,接口地址、鉴权、入参、出参、错误码;
2、接口计划和方案
思路:
正例:输入正确的入参,查看接口是否返回成功,
反例:
鉴权反例:鉴权为空、鉴权码错误、鉴权码过期等
参数反例:参数为空、类型异常、长度异常、错误码覆盖
其他:分页异常
3、编写用例和评审
4、执行接口测试
5、输出接口测试报告

二、postman的使用

1.postman介绍

在这里插入图片描述
请求部分:
Params:用于在get请求传参
Authorization:postman自带的鉴权功能
Headers:请求头
Body:post请求传参
none:没有参数
form-data:有文件又有键值对
x-www-form-urlencoded :只传键值对
raw :传json、html、xml、text、js
binary:把文件以二进制方式传输
Pre-request Script 接口请求之前的脚本,js格式
Tests:断言的代码
cookies:postman的cookie管理器
code:生成接口自动化脚本

返回部分:
Body:返回的数据
Pretty:以json格式展示
Raw:以文本格式展示
Preview:以网页的格式展示
cookies:返回的cookies信息
Headers:响应头
TestResults:断言结果
Status:状态码
time:消耗的时间
size:返回的字节数

console:控制台,做调试用

2.postman内置的动态参数

时间戳:{{KaTeX parse error: Expected 'EOF', got '}' at position 11: timesstamp}̲} 生成0-1000的随机整数…randomint}}
生成一个GUID的字符串:{{$guid}} 很长的一个字符串

3.postman之接口变量及关联

开发环境、测试环境、预发布环境、生产环境
在这里插入图片描述
环境变量设置:由于不同环境接口请求地址不同,设置成环境变量,在测试时选择对应环境的变量进行测试(如http://{{ip}}……,接口测试前就要做)
在这里插入图片描述全局变量设置:(英文符号)
1、json提取://发送请求获得token的值并提取
var jsValue =JSON.parse(responseBody)
console.log(jsValue.token) //相当于print
//把提取的值保存到全局变量
pm.globals.set(“token”, jsValue.token); 后续接口需要使用时传入变量{{token}}即可
2、使用正则表达式提取:var title1 = responseBody.match(new RegExp(’“title”:"(.+?)"’))[1]
变量 返回的值 匹配 规则 匹配这个 取匹配到的第一个
pm.globals.set(“title”, “title1”); 设置成全局变量
3、cookie提取器
var token = postman.getResponseCookie(‘token’).value;

4.postman之接口断言

在这里插入图片描述

//八中断言方式
//1、 Status code:Code is 200 返回码为200
pm.test(“Status code is 200”, function () {
pm.response.to.have.status(200);
});
//2、Response body:Contains string 断言返回的结果包含一个指定的字符串
pm.test(“Body matches string”, function () {
pm.expect(pm.response.text()).to.include(“string_you_want_to_search”);
});
//3、Response body:JSON calue check 对返回的结果做json字段检查
pm.test(“Your test name”, function () {
var jsonData = pm.response.json();
pm.expect(jsonData.value).to.eql(100);
});
//4、Response body:is equal to a string 断言返回的结果等于一个字符串
pm.test(“Body is correct”, function () {
pm.response.to.have.body(“response_body_string”);
});
//5、Response headers:Content-Type header check 断言响应头中包含指定的响应头
pm.test(“Content-Type is present”, function () {
pm.response.to.have.header(“Content-Type”);
});
//6、Response time is less than 200ms 断言接口请求的时间小于200ms
pm.test(“Response time is less than 200ms”, function () {
pm.expect(pm.response.responseTime).to.be.below(200);
});
//7、Status code:Successful POST request 断言一个post请求中返回的状态码是否在指定的范围内
pm.test(“Successful POST request”, function () {
pm.expect(pm.response.code).to.be.oneOf([201, 202]);
});
//8、Status code:Code name has string 断言返回的状态码信息中包含指定的字符串
pm.test(“Status code name has string”, function () {
pm.response.to.have.status(“Created”);
});

说明

仅作学习使用

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Keepalived 是一个用于实现 Linux 高可用性的软件,它采用 VRRP 协议实现 IP 负载均衡和故障转移。当某个服务节点出现故障时,Keepalived 会自动将服务 IP 地址迁移到其他正常的节点上,从而保证服务的高可用性。 以下是 Keepalived 的应用步骤和测试结果: 1. 环境准备 在三台 CentOS 服务器上安装 Keepalived,假设它们的 IP 地址分别为 192.168.1.101、192.168.1.102 和 192.168.1.103。 2. 配置 Keepalived 在三台服务器上分别编辑 Keepalived 的配置文件 /etc/keepalived/keepalived.conf,确保它们的配置一致。以下是一个简单的示例配置: ``` global_defs { router_id LVS_DEVEL } vrrp_script chk_http_port { script "/usr/local/bin/check_apache.sh" interval 2 weight 2 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 101 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.1.100/24 dev eth0 } track_script { chk_http_port } } ``` 这个配置文件指定了一个 VRRP 实例 VI_1,其中 192.168.1.100 是虚拟 IP 地址,eth0 是网络接口,101 是本节点的优先级,1111 是认证密码。chk_http_port 是一个检测脚本,用于检测 HTTP 服务的可用性。 3. 启动 Keepalived 在三台服务器上启动 Keepalived 服务: ``` systemctl start keepalived ``` 4. 测试 在任意一台服务器上访问 192.168.1.100,可以看到 HTTP 服务正常运行。此时可以手动关闭其中一台服务器的 HTTP 服务,然后在另外一台服务器上再次访问 192.168.1.100,可以看到虚拟 IP 地址已经迁移到了另外一台服务器上,并且 HTTP 服务仍然正常运行。 通过这个测试可以看出,Keepalived 能够自动检测并处理服务器节点的故障,从而实现服务的高可用性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值