【软件测试】--接口测试

1. 接口用例设计

接口测试的测试点

功能测试

• 单接口功能：

  • 手工测试中的单个业务模块，一般对应一个接口
    • 登陆业务 --> 登陆接口
    • 加入购物车业务 --> 加入购物车接口
    • 订单业务 --> 订单接口
    • 支付业务 --> 支付接口
  • 借助工具、代码。绕开前端界面，组织接口所需要的数据，展开接口测试

• 业务场景功能

  • 按照用户实际使用场景，梳理接口业务场景
  • 组织业务场景时，一般只需做正向测试即可（与手工一致）
  • 一般建议用最少的用例覆盖最多的业务场景

性能测试

• 响应时长
• 吞吐量
• 并发数
• 服务器资源利用率

安全测试

• 攻击安全 – 与测试工程师无关
• 业务安全 – 测试的方向
  • 敏感数据是否加密
  • SQL注入：在用户输入数据的位置，写入SQL语句

1.1 设计方法与思路

与手工测试相同之处

• 手工测试对应的功能测试点与接口测试对应的功能完全一致

与手工测试不同之处

• 手工测试，测写入到输入框中的数据是否正确。接口测试测参数对应的参数值是否正确
• 接口测试，不单单针对参数值进行进行，还可以针对参数本身进行测试
  • 正向参数：
    • 必选参数：所有的必选（必填）都包含
    • 组合参数；所有的必选+任意一个或多个可选参数
    • 全部参数：所有的必选+所有的可选参数
  • 反向参数：
    • 多参
    • 少参
    • 无参
    • 错误参数

1.2 单接口测试用例

手工测试用例文档8大要素：

用例编号、用例标题、模块、优先级、预置条件、测试数据、操作步骤、预期结果

接口测试用例文档10要素：

用例编号、用例标题、模块、优先级、预置条件、请求方法、URL、请求头、请求体（请求数据）、预期结果

以TPShop为例

登陆模块的接口测试用例测试点

数值

• 正向
  • 登录成功

用例编号	模块	用例名称	接口名称	请求URL	请求方法	请求参数类型	请求参数	预期结果	测试结果	备注
tpshop_login_001	登陆	登陆成功	获取验证码 登陆	http://106.54.9.13/index.php?m=Home&c=User&a=verify http://106.54.9.13/index.php?m=Home&c=User&a=do_login	GET POST	form	data = { “username”: " 18184761327", “password”: “123456”, “verify_code”: 8888 }	获取到验证码图片 登陆成功

• 反向
  • 用户名为空
  • 用户名包含特殊字符、字母
  • 用户名超过11位（12位）
  • 用户名不足11位（10位）
  • 用户名未注册
  • 密码为空
  • 密码包含特殊字符、字母
  • 密码为1位
  • 密码为100位
  • 密码错误

用例编号	模块	用例名称	接口名称	请求URL	请求方法	请求参数类型	请求参数	预期结果	测试结果	备注
tpshop_login_002	登陆	账号不存在	获取验证码 登陆	http://106.54.9.13/index.php?m=Home&c=User&a=verify http://106.54.9.13/index.php?m=Home&c=User&a=do_login	GET POST	form	data = { “username”: " 18184761327", “password”: “123456”, “verify_code”: 8888 }	获取到验证码图片 账号不存在
tpshop_login_003	登陆	密码错误	获取验证码 登陆	http://106.54.9.13/index.php?m=Home&c=User&a=verify http://106.54.9.13/index.php?m=Home&c=User&a=do_login	GET POST	form	data = { “username”: " 18184761327", “password”: “123456”, “verify_code”: 8888 }	获取到验证码图片 密码错误

参数（接口测试特有）

• 正向

  • 必选参数：正确用户名+正确密码
  • 可选参数：忽略
  • 全部参数：正确用户名+正确密码

• 反向

  • 多参：多"abc":“123”
  • 少参:少username，正确密码
  • 无参：没有任何参数
  • 错误参数

  用例编号	模块	用例名称	接口名称	请求URL	请求方法	请求参数类型	请求参数	预期结果	测试结果	备注
  tpshop_login_001	登陆	登陆成功	获取验证码 登陆	http://106.54.9.13/index.php?m=Home&c=User&a=verify http://106.54.9.13/index.php?m=Home&c=User&a=do_login	GET POST	form	data = { “username”: " 18184761327", “password”: “123456”, “verify_code”: 8888 }	获取到验证码图片 登陆成功
  tpshop_login_002	登陆	用户名为空	获取验证码 登陆	http://106.54.9.13/index.php?m=Home&c=User&a=verify http://106.54.9.13/index.php?m=Home&c=User&a=do_login	GET POST	form	data = { “username”: " ", “password”: “123456”, “verify_code”: 8888 }	获取到验证码图片 账号不存在
  tpshop_login_003	登陆	多参数	获取验证码 登陆	http://106.54.9.13/index.php?m=Home&c=User&a=verify http://106.54.9.13/index.php?m=Home&c=User&a=do_login	GET POST	form	data = { “username”: " 18184761327", “password”: “123456”, “verify_code”: 8888, “abc”:“123”}	获取到验证码图片 密码错误
  tpshop_login_003	登陆	密码错误	获取验证码 登陆	http://106.54.9.13/index.php?m=Home&c=User&a=verify http://106.54.9.13/index.php?m=Home&c=User&a=do_login	GET POST	form	data = { “username”: " 18184761327", “password”: “123456”, “verify_code”: 8888 }	获取到验证码图片 密码错误
  tpshop_login_001	登陆	无参数	获取验证码 登陆	http://106.54.9.13/index.php?m=Home&c=User&a=verify http://106.54.9.13/index.php?m=Home&c=User&a=do_login	GET POST	form	data = { “username”: " 18184761327", “password”: “123456”, “verify_code”: 8888 }	获取到验证码图片 登陆成功

1.3 业务场景测试用例

• 用户怎么用，怎样设计业务
• 用最少的测试用例，尽量覆盖最多的接口

分析测试点

针对“员工管理”业务场景

• 登陆–添加员工–查询员工–修改员工–再次查询–删除员工–查询员工列表

针对每个业务设计单接口用例

​ 登陆

​ 添加员工-

​ 查询员工

​ 修改员工

​ 再次查询

​ 删除员工

​ 查询员工列表

2. postman

2.1 简介和安装

• 简介
  • postman是一款非常流行的接口调试工具，它使用简单，而且功能也很强大。不仅测试人员会使用，开发人员也会经常使用
  • 特征
    1. 简单易用的图形用户界面
    2. 可以保存接口请求的历史记录
    3. 使用测试集collection可以更有效的管理组织接口
    4. 可以在团队之间同步接口数据

2.2 collection管理测试用例

步骤：

1. 创建用例集

2. add request

2.3 postman断言

2.3.1 postman断言简介

断言：让程序判断预期结果和实际结果是否一致

特点：

• postman的断言是使用JavaScript语言编写的，卸载’Tests’标签页里
• Tests中的脚本在发送请求之后执行，会把断言的结果（Pass/Fail)最终在"Test Results"标签页中展示

2.3.2 常用postman断言

1. Status code :Code is 200

//判断响应状态码是否等于200
pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});
pm:postman的一个实例
test():postman实例的一个方法
	参数1：断言完成后给出的提示信息
    参数2：function(){},匿名函数调用
    

2. Response body :Contains string

//判断响应体中是否包含指定的字符串
pm.test("Body matches string", function () {
    pm.expect(pm.response.text()).to.include("string_you_want_to_search");
});
pm:postman的一个实例
test():postman实例的一个方法
	参数1："Body matches string"断言完成后给出的提示信息
    参数2：function(){},匿名函数调用
 	"string_you_want_to_search" :判断是否包含的字符串

3. Response body : Is equal to a string

//判断响应体数据是否等于指定的字符串
pm.test("Body is correct",function(){
    pm.response.to.have.body("response_body_string");
});
pm:postman的一个实例
test():postman实例的一个方法
	参数1："Body is correct"断言完成后给出的提示信息
    参数2：function(){},匿名函数调用
 	"response_body_string" :判断响应体是否相同的字符串

4. Response body :JSON value check

//校验响应的JSON数据
pm.test("Your test name",function()
       {
    var jsonData = pm.response.json();
    pm.expect(jsonData.value).to.eql(100);
});
pm:postman的一个实例
jsonData:定义的一个json格式的响应体变量
test():postman实例的一个方法
	参数1："Body is correct"断言完成后给出的提示信息
    参数2：function(){},匿名函数调用
 	"response_body_string" :判断响应体是否相同的字符串

5. Response headers:Content-Type header check

//判断相应头中是否包含指定的头标签
pm.test("Content-Type is present", function () {
    pm.response.to.have.header("Content-Type");
});

2.4 全局变量与环境变量

2.4.1 概念

• 全局变量：全局变量是全局唯一的，不可重复定义的变量
• 环境变量：
  • 一个变量只能属于某个环境，在某一个环境中变量不可重复定义
  • 在环境与环境之间可以定义重复的变量
  • 一个环境可以包含多个环境变量
  • 常见环境分类：开发环境、测试环境、生产环境

2.4.2 设置变量

• 全局变量
  • 手动测试
  • 代码设置:pm.globals.set(“var_name”,value);
• 环境变量
  • 手动测试
  • 代码设置:pm.environment.set(“var_name”,value);

2.4.3 获取变量值

• 全局变量

  1. 请求参数中获取：{{var_name}}
  2. 代码中获取：var value = pm.globals.get(“var_name”);

• 环境变量

  1. 请求参数中获取：{{var_name}}

  2. 代码中获取：var value = pm.environment.get(“var_name”);

2.5 postman请求前置脚本

假设，这样一种场景：

​ 调某接口时，要输入“时间戳”，如果输入的“时间戳”的绝对值，超过标准时间10分钟。则不允许调用

• 时间戳：表示当前系统时间。表示方式：从1970年1月1日 00:00:00~现在所经历的秒数

• 请求前置脚本：

  • 书写在“pre-request Script”标签中
  • Postman 在http请求发送之前，会自动执行，该脚本中的代码！

  案例

  调用百度首页接口，传时间戳给服务器

  步骤：

  1. 创建“请求前置脚本”用例集和http请求页
  2. 指定请求方法GET，URL：http://www.baidu.com
  3. 在Pre-request Script标签页中，写入代码，获取时间戳，写入到全局变量中

  //获取时间戳
  var timestamp = new Date().getTime()
  
  //将时间戳保存到全局变量中
  pm.globals.set("glb_timestamp",timestamp)
  

  4. 点击Send按钮，促使Pre-request Script 标签页中被自动执行。点击右上角的“眼睛”图标查看Globals中，多出一个全局变量。

  

  5. 在URL中，借助查询参数，使用全局变量{{glb_timestamp}}。点击Send按钮，发送带有时间戳的请求。

  

  6. 查看（View-Show Post Console ）

  

2.6 postman关联

postman的关联，用来解决接口和接口之间调用的依赖关系。需要借助全局变量、环境变量来解决关联问题。

实现步骤：（以A接口返回的数据，供B接口使用为例）

1. 组织A接口http请求，发送A接口请求
2. 获取A接口返回的响应数据，写入全局/环境变量中
3. 组织B接口的请求，从全局/环境变量中获取A返回的数据

案例

请求获取天气接口，提取响应结果中的城市，将城市名，给百度搜索接口使用

实现步骤

1. 创建用例集和请求页面
2. 组织天气接口的请求方法、URL，发送http请求
3. 获取响应结果的json数据，从数据中提取城市名，保存到全局变量中glb_city

//获取响应数据
var jsonData = pm.response.json();
//获取城市名
var city = jsonData.weatherinfo.city
//写入全局变量
pm.globals.set("glb_city",city)

4. 点击小眼睛查看全局变量是否设置正确

5. 组织百度搜索接口的请求方法、URL，在查询参数中，指定使用全局变量{{glb_city}}

2.7 批量执行测试用例

步骤

1. 点击用例集名称，选择“Run”按钮，进入Runner标签页中
2. 在Runner标签页中，用例集内的所有请求页会被默认自动选中
3. 点击Run，即可批量执行

运行结果：

2.8 postman测试报告

使用newman命令，运行导出的测试集脚本，打开cmd输入：

newman run 测试脚本文件 -e 环境变量文件 -d 测试数据文件 -r html --reporter-html-export report.html

eg:
newman run demo.postman_collection.json -r html
newman run demo.postman_collection.json -r html --reporter-html-export report.html

命令说明：

• run xxx.json :表示要执行的postman脚本，即导出的测试集数据
• -e source ：用来指定环境变量文件的路径
• -d source ：用来指定测试文件的路径

生成报告步骤：

1. 导出用例集
2. 在用例集所在目录，输入cmd打开终端
3. 键入命令，生成报告

F:\Four_year\测试\postman> newman run postman关联.postman_collection.json -r html --reporter-html-export postman关联报告.html

点击查看