文章目录
- 一、接口测试的测试点
- 1.1 功能测试
- 1.2 性能测试
- 1.3 安全测试
- 二、接口用例设计方法
- 2.1 单接口测试
- 2.2 业务场景测试
一、接口测试的测试点
接口测试点称之为测试维度。
1.1 功能测试
1、单接口功能：
- 手工测试中的单个业务模块，一般一个业务对应一个接口。
- 登录业务 ——> 登录接口 （登录业务对应登录接口）
- 加入购物车业务 ——> 加入购物车接口 （加入购物车业务对应加入购物车接口）
- 订单业务 ——> 订单接口 （订单业务对应订单接口）
- 支付业务 ——> 支付接口（支付业务对应支付接口）
- 借助工具、代码。绕开前端界面，组织接口所需要的数据，展开接口测试。
2、业务场景功能：
- 按照用户实际 使用场景，模拟 连续调用 多个 接口。测试功能正确性。
- 组织业务场景时，一般只需做正向测试即可（与手工一致）。
- 一般建议用最少的 用例 覆盖最多的业务场景。
- 登录 —— 搜索商品 —— 加购物车 —— 下单 —— 支付 —— 评价
功能测试：验证接口功能是否按照接口文档实现（输入+处理+输出） 手工测试对应的 功能测试点，与接口测试对应的功能 完全一致。 tpshop商城 登录 页面，手工功能测试用例设计要点： - ①页面布局是否符合需求 - ②测试 用户名 输入框，输入的数据是否正确。 - ③测试 密码 输入框，输入的数据是否正确。 - ④测试 验证码 输入框， 输入的数据是否正确。 tpshop商城 登录 页面，接口测试用例设计要点： - ①测试 用户名 输入框对应的 username 的值 是否正确。 - ②测试 密码 输入框对应的 password 的值，是否正确。 - ③测试 验证码 输入框对应的 verify_code 的值，是否正确。 ———————————————————————————————————————————————————————————————————————————— 1. 手工测试，测试写入到输入框中的数据是否正确。接口测试 测试参数 对应的 参数值 是否正确。 2. 接口测试，不单单针对 参数值进行，还可以针对 参数本身 进行测试。1.2 性能测试
- 响应时长：从请求发送。到接收到服务器响应所需要的所有时间。
- 吞吐量：衡量服务器处理并发请求的能力。主要参考 TPS 查看。
- 错误率：服务器处理请求失败的 比率。
- 服务器资源占用率: 服务器处理请求时，系统资源（cpu、内存、网络、磁盘）使用情况
1.3 安全测试
1、攻击安全。 —— 与测试工程师无关。
- 木马、病毒、黑客…
- 专业的 安全测试工程师 负责测试。
2、业务安全。 —— 测试的方向。
保证系统在工作过程中，业务上没有 安全漏洞。
敏感数据是否加密。（比如登录用户名和密码）
SQL注入：在用户能输入数据的位置，写入SQL语句。
- SQL注入安全，用户恶意写入的SQL语句，不会执行，查询数据库！
二、接口用例设计方法
2.1 单接口测试
1、正向测试：
- 必选参数：所有的必填参数，给正确数据，得正确结果。 P0
- 组合参数：所有必选 + 部分可选，给 正确数据，得正确结果。p2
- 全部参数：所有必选 + 所有可选，给 正确数据，得正确结果。p1
2、反向测试：
- 功能异常：数据类型正确，不能正确结果。 p1
- 数据异常：数据类型不正确（空、特殊字符、字母、下划线、长度 【等价类、边界值测试法】） p2
- 参数异常： p3
- 多参：多出必选项。（任意设计）
- 少参：缺少必选项。
- 无参：没有参数。
- 错误参数：参数名称错误。
2.2 业务场景测试
多接口测试：业务场景功能测试(站在用户角度考虑常用的使用场景) - 接口之间数据依赖- 必须在 单接口测试完成之后
- 模拟用户实际使用场景，尽量用较少的测试用例，覆盖更多的接口。
- 一般情况下，只需要设计业务场景的 正向测试用例 即可。
