接口测试以及接口测试用例设计

1. 测试点

功能测试

• 单接口功能：
  • 手工测试中的单个业务模块，一般对应一个接口
    • 登录业务---->登录接口
    • 加入购物车业务---->加入购物车接口
    • 订单业务---->订单业务接口
    • 支付业务--->支付业务接口
  • 借助工具、代码以此绕开前端界面,组织接口所需要的数据,展开接口测试
• 业务场景功能
  • 按照用户实际使用场景,梳理接口业务场景
  • 组织业务场景时,一般只需做正向测试即可(与手工一致)
  • 一般用最少的用例覆盖最多业务场景
    • 登录---搜索商品---加入购物车---下单---支付---评价

性能测试

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

安全测试

• 攻击安全---与测试工程师无关
• 业务安全---测试方向
  • 敏感数据是否加密
  • SQL注入:用户能输入数据的位置,写入SQL语句
    • SQL注入安全,用户恶意写入的SQL语句,不会执行,查询数据库

2.与手工设计不同之处

1.手工测试,测写入到输入框的数据是否正确.接口测试测参数对应的参数值是否正确

2.接口测试,不单针对参数值进行,还可以对参数本身进行测试

• 正向参数:
  • 必选参数:所有的必填(必选)都包含
  • 组合参数:所有的必填+任意一个或多个可选参数
  • 全部参数:所有必选+所有可选参数
• 反向参数:
  • 多参:多出一个或多个必选参数(可以任意指定)
  • 少参:缺少一个或多个必选参数
  • 无参:没有必选参数
  • 错误参数:参数名输入错误

3.单接口测试用例

手工测试用例文档的8大要素:编号,用例名称(标题),模块,优先级,预置条件,测试数据,操作步骤,预期结果

接口测试用例文档10大要素:编号,用例名称(标题),模块,接口名称,请求方法,URL,请求头,请求体(请求数据),请求数据类型,预期数据,实际数据

分析接口文档，以 “登录接口” 为例：
请求方法：post
URL： “系统信息” 中的 协议和域名 + /api/sys/login
请求头：Content-Type : application/json
请求体：{“mobile”:“13800000002”,“password”:“123456”}
预期结果： {“success”:true,“code”:10000,“message”:“操作成功！”,“data”:“f5050a1b-7919-444c-9ec4-3c1a7286536d”}
data：值为登录成功生成的 令牌数据。该数据 会定时变化。

• 数值
  • 正向
    • 登录成功
  • 反向
    • 用户名为空
    • 用户名包含特殊字符
    • 用户名超过11位(12位)
    • 用户名不足11位(10位)
    • 用户名未注册
    • 密码为空
    • 密码包含特殊字符
    • 密码为1位
    • 密码为100位
    • 密码错误
• 参数
  • 正向
    • 必选参数:正确的用户名+正确密码
    • 组合参数:忽略
    • 全部参数:正确的用户名+密码
  • 反向
    • 多参:多abc:123
    • 少参(少mobile):没有任何参数
    • 无参:没有任何参数
    • 错误参数(手机号参数错误):abc:"13552658896",password:"123456"

 4.业场景测试

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

分析测试点:

针对"员工管理"业务场景:

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

添加员工

• 请求方法：post
  • URL： {协议+域名}/api/sys/user
• 请求头：
  • Content-Type： application/json
  • Authorization： Bearer f5050a1b-7919-444c-9ec4-3c1a7286536d （具体数据 来源 登录成功返回的 响应体中的 data的值）
• 请求体（请求数据）：{“username”:“爱因斯坦”,“mobile”:“17289432100”,“timeOfEntry”:“2021-07-12”,“formOfEmployment”:1,“departmentName”:“测试0607”,“departmentId”:“1412421425733664768”,“workNumber”:“234”,“correctionTime”:“2021-07-30T16:00:00.000Z”}
• 预期结果：
• 状态码：200
• {“success”:true,“code”:10000,“message”:“操作成功！”, “data”:{“id”:“113749504”}}

查询员工

• 请求方法：GET

  • URL： {协议+域名}/api/sys/user/:target
• 请求头：
  • Content-Type： application/json
  • Authorization： Bearer f5050a1b-7919-444c-9ec4-3c1a7286536d （具体数据 来源 登录成功返回的 响应体中的 data的值）
• 请求体:
  • 无
• 返回数据：
  • 状态码：200
  • {“success”: true,
  • “code”: 10000,
  • “message”: “操作成功！”,
  • “data”: { 所查询的员工的详细信息} }