前言
之前还没实际做过接口测试的时候呢, 对接口测试这个概念比较渺茫, 只能靠百度, 查看各种接口实例, 然后在工作中也没用上, 现在呢是各种各样的接口都丢过来, 总算是有了个实际的认识. 虽然只是接口功能的测试, 但是也要记录下自己学到的点滴技能.
因为只是接口的功能测试, 所以目前是用 postman 做测试, 比较简便, 当然这只是接口测试的入门而已, 了解的只是冰山一角, 后续会努力往接口压力, 接口性能, 接口自动化方向靠拢.(postman 的安装方法可以百度一下, 这里就不提了)
各位大佬勿喷哈~
接口理论
我们常说的接口就是 API, 接口测试是测试系统组件间接口的一种测试. 接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点. 测试的重点是要检查数据的交换, 传递和控制管理过程, 以及系统间的相互逻辑依赖关系等.
其实接口测试就和普通功能测试没什么区别, 区别就是功能测试是在页面上输入值, 提交数据看结果, 而接口测试没有页面, 通过接口规范文档上的调用地址, 请求参数, 拼接报文, 然后发送请求, 检查返回结果.
接口实例
一, POST
POST 请求是用来发送数据的, 下面以下 XX 系统分配加工厂为例
1, 产品经理的 PRD 文档要求如下 (分配加工厂接口的修改内容如下):
1) 分配加工厂接口里新增加工厂 ID 字段, 整数类型, 非必填;
2.) 若对单领料单已经审核通过, 限制只有待审核状态才能分配加工厂, 若不是则提示 "对单领料单不是待审核, 不能分配加工厂";
2, 开发人员的接口文档如下:
接口名称: XX 系统分配加工厂接口
接口路径: POST /process/requisitionOrder/updateDistributeStatus
请求参数:
Headers:
参数名称 | 参数值 | 是否必须 | 示例 | 备注 |
Content-Type | application/json | 是 |
Body:
- {
- "factoryId": "123",// 加工厂 ID
- "factory": "XX 服饰",// 加工厂名称
- "produce_order_id": [// 生产制单 (纯数字) 多个用, 分开
- 1134360
- ]
- }
返回数据:
- {
- "msg": "success",
- "code": "0",
- "info": "操作成功"
- }
3, 测试人员的测试用例如下:
用例编号 | 模块 | 用例标题 | 前提条件 | 操作步骤 | 预期结果 |
01 | XX 接口 | 分配加工厂接口里新增加工厂 ID 字段,整数类型,非必填 | 填写错误的或类型不对的加工厂 ID | 略 | 返回具体的错误信息 |
不填写加工厂 ID,其他条件符合要求 | 分配加工厂成功,XX 系统的领料单正确显示加工厂名称 | ||||
填写正确的加工厂 ID,其他条件符合要求 | 分配加工厂成功,XX 系统的领料单正确显示加工厂名称 | ||||
填写正确的加工厂 ID,对单领料单已经审核通过 | 返回提示 “对单领料单不是待审核,不能分配加工厂”; |
4, 测试人员执行测试用例如下:
1) 打开 Postman, 填写接口信息, 具体操作如图
注: 接口文档中的 URL 是不带环境地址的, 所以将 URL 复制到地址栏时, 前面还要加上环境的地址, 比如测试环境的地址 + 接口 URL,
当然如果有多个环境的话, 可以用环境配置功能, 具体配置步骤在第 4) 步进行描述.
2) 结合测试用例, 组合变换参数信息后, 查看返回的 JSON 数据与 PRD 是否一致
3) 测试用例遍历完成后, 以上即完成了 POST 请求的接口功能测试.
4) 这里描述一下 postman 的环境配置
第一步, 如图
第二步, 如图
第三步, 如图
第四步, 如图
第五步, 如图 (这是针对有多个环境的情况, 比如一般都会有测试环境, 验收环境, 生产环境)
二, GET
GET 请求是用来获取数据的, 下面以 XX 系统获取出库账单为例,(以下只列出部分数据信息用于演示)
1, 产品经理的 PRD 文档要求如下:
输入参数 | |||
字段名称 | 是否必填 | 取值逻辑 | 备注说明 |
账单日期 | 是 | 例如 2019-04-10 | |
供应商 ID | 否 | ||
输出参数 | |||
账单编号 | 是 | ML + 年月日 + 流水号 | 一个账单日期内,一个供应商只对应一个账单 |
账单日期 | 是 | 输入参数里的账单日期 | |
供应商名称 | 是 | 从出库单获取 | |
SKU | 是 | 从出库单明细获取 | |
采购单价 | 是 | 根据 SKU 获取档案的基准价 | |
数量 | 是 | 出库数量 | |
账单金额 | 是 | 采购单价 * 数量,金额为负 |
2, 开发人员的接口文档如下:
接口名称: 出库账单同步到 XX 系统接口
接口路径: GET /purchase/prepareOrder/importListFromPlm
请求参数:
Query:
参数名称 | 是否必须 | 示例 | 备注 |
billDate | 是 | 2019-02-20 | 账单日期 |
supplierId | 否 | 1 | 供应商 ID |
返回数据:
- {
- "msg": "success",
- "code": "0",
- "info": {
- "list": [
- {
- "billNo": "ML201902205005", // 账单编号
- "billDate": "2019-02-20", // 账单日期
- "factory": "生产部萨文服饰 - 烨琳", // 供应商名称
- "materialSku": "16MLZS0513-628", // 物料 SKU
- "num": 20, // 数量
- "purchasePrice": 0, // 采购单价
- "billSum": 0, // 账单金额
- }
- ]
- }
- }
3, 测试人员的测试用例如下:
用例编号 | 所属模块 | 用例标题 | 前提条件 | 测试步骤 | 预期结果 |
01 | XX 接口 | 输入正确的‘账单日期’请求参数,接口正确返回相应的账单数据 | 系统中有在该账单日期内的账单 | 1、在请求地址中增加‘billDate’参数; | {"msg": "success", "code": "0", "info":….} |
02 | XX 接口 | 输入不符合规范的‘账单日期’请求参数,接口返回参数不符合要求 | 填写 12/23/45 | 1、在请求地址中增加‘billDate’参数; | {"msg":"账单日期不符合规范;","code":"43"} |
03 | XX 接口 | 将‘账单日期’请求参数置空,接口返回参数必填 | 1、在请求地址中增加‘billDate’参数; | {"msg":"账单日期不能为空;","code":"43"} | |
04 | XX 接口 | ‘供应商 ID’请求参数 | 请求中没有‘billDate’ | 1、在请求地址中增加‘supplierId’参数; | {"msg":"账单日期不能为空;","code":"43"} |
05 | XX 接口 | 请求中有‘billDate’ | 1、在请求地址中增加‘billDate’,‘supplierId’参数; | {"msg": "success", "code": "0", "info":….} | |
06 | XX 接口 | 请求中有‘billDate’ | 1、在请求地址中增加‘billDate’,‘supplierId’参数; | {"msg":"供应商 ID 不存在;","code":"43"} | |
07 | XX 接口 | 请求中有‘billDate’ | 1、在请求地址中增加‘billDate’,‘supplierId’参数; | {"msg": "success", "code": "0", "info":….} | |
08 | XX 接口 | ‘账单编号’输出参数取值为:ML + 年 + 月 + 日 + 4 位流水号 | 接口返回正确数据 | 1.GET 后,查看返回的 JSON 数据 | ‘账单编号’输出参数取值为:ML + 年 + 月 + 日 + 4 位流水号 |
09 | XX 接口 | 以上列举了部分测试用例,其他的测试用例就不再展示了 |
4, 测试人员执行测试用例如下:
1) 打开 Postman, 填写接口信息, 具体操作如图
注: 接口文档中的 URL 是不带环境地址的, 所以将 URL 复制到地址栏时, 前面还要加上环境的地址, 比如测试环境的地址 + 接口 URL,
当然如果有多个环境的话, 可以用环境配置功能, 具体配置步骤可以参考 POST 的描述
2) 结合测试用例, 组合变换参数信息后, 查看返回的 JSON 数据与 PRD 是否一致
3) 测试用例遍历完成后, 以上即完成了 GET 请求的接口功能测试.
来源: https://www.cnblogs.com/Chilam007/p/10639773.html