软件测试笔记_17_接口用例设计

一、接口用例设计

为什么写

• 防止测试点漏测。条理清晰
• 方便分配工作，评估工作量和时间
• 面试时使用！

1. 接口测试的测试点/测试维度

（1）功能测试

• 单接口功能
  • 手工测试的单个业务模块，一般对应单个接口
    • 登录业务 – 登录接口
    • 加入购物车业务 – 购物车接口
    • 订单业务 – 订单接口
    • 支付业务 – 支付接口
  • 借助根据、代码。绕开前端界面，组织接口所需要的数据，展开接口测试。
• 业务场景功能
  • 按照用户实际使用场景，去梳理【接口业务场景】
  • 组织业务场景时，一般只需要做【正向】测试即可（单个功能上才需要反向，业务场景不需要，业务场景是看功能连续调用）
  • 一般建议用最少的用例覆盖最多的业务场景
    • 登录 – 搜索商品 – 加购物车 – 下单 – 支付

（2）性能测试

不单单要实现功能，更要有好的用户体验

• 响应时长
• 吞吐量
• 并发数量
• 服务器资源利用率（CPU、内存、显卡、磁盘IO、网络IO）

（3）安全测试

• 攻击安全：专业安全测试工程师完成
• 业务安全

  • 敏感数据是否加密

  • SQL注入：在用户能输入数据的位置，写入SQL语句。

    • SQL注入安全，用户恶意写入的SQL语句，不会执行，查询数据库！

2. 👀与手工设计不同之处

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

3. 👀单接口测试用例

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

（1）接口测试用例文档【要素】

• 要素
  1. 编号
  2. 用例名称（标题）
  3. 模块
  4. 优先级
  5. 预置条件
  6. 请求方法
  7. URL
  8. 请求头
  9. 请求体（对应手工测试的测试数据）
  10. 预期结果

（2）excel举例

（3）登录模块测试点

• 数值
  • 正向
    • 登录成功
  • 反向
    • 用户名为空
    • 用户名包含特殊字符/字母
    • 用户名超出11位（12位）
    • 用户名不足11位（10位）
    • 用户名未注册
    • 密码为空
    • 密码包含特殊字符、字母
    • 密码1位
    • 密码100位
    • 错误密码
• 参数
  • 正向（选一项就行）
    • 必选参数：正确的username+password
    • 可选参数：忽略
    • 全部参数：正确的username+password
  • 反向
    • 多参：多添加一个 abc:123
    • 少参：仅一个username 或者 仅一个password
    • 无参：无参数
    • 错误参数：参数名错误，abc:1245678912, password:123456

4. 👀业务场景测试用例

用户怎么使用，就怎么设计业务
用最少的测试用例覆盖最多的接口

（1）分析测试点

• 以 文章管理业务场景 为例
• 步骤：登录 —— 添加文章 —— 查询单个文章 —— 修改 —— 再次查询 —— 删除文章 —— 查询文章列表

（2）添加文章

• 请求方法：POST
• URL：（协议+域名）/my/article/add
• 请求头
  • Content-Type:application/json
  • Authorization:“tok en”:“Bearer e…具体数据来源 登录成功后 返回的 响应体中的值”
• 请求体（请求数据）
  • {"" : ""， "" : ""， ...}
• 预期结果
  

二、postman

1. 环境安装

2. 使用

3. 使用postman

（1）👀管理测试用例Collections

• 新建用例
  

• 添加请求
  

• 添加子目录folder
  项目 – 模块 – 请求
  

ÿ