以前还没实际作过接口测试的时候呢,对接口测试这个概念比较渺茫,只能靠百度,查看各类接口实例,而后在工做中也没用上,如今呢是各类各样的接口都丢过来,总算是有了个实际的认识。虽然只是接口功能的测试,可是也要记录下本身学到的点滴技能。json
由于只是接口的功能测试,因此目前是用postman作测试,比较简便,固然这只是接口测试的入门而已,了解的只是冰山一角,后续会努力往接口压力、接口性能、接口自动化方向靠拢。(postman的安装方法能够百度一下,这里就不提了)app
各位大佬勿喷哈~post
POST请求是用来发送数据的,下面如下XX系统分配加工厂为例性能
一、产品经理的PRD文档要求以下(分配加工厂接口的修改内容以下):测试
1) 分配加工厂接口里新增长工厂ID字段,整数类型,非必填;ui
2.)若对单领料单已经审核经过,限制只有待审核状态才能分配加工厂,若不是则提示“对单领料单不是待审核,不能分配加工厂”;spa
二、开发人员的接口文档以下:code
接口名称:XX系统分配加工厂接口blog
参数名称 | 参数值 | 是否必须 | 示例 | 备注 |
Content-Type | application/json | 是 |
{ "factoryId": "123",//加工厂ID "factory": "XX服饰",//加工厂名称 "produce_order_id": [//生产制单(纯数字) 多个用,分开 1134360 ] }
返回数据:接口
{ "msg": "success", "code": "0", "info": "操做成功" }
三、测试人员的测试用例以下:
用例编号 | 模块 | 用例标题 | 前提条件 | 操做步骤 | 预期结果 |
01 | XX接口 | 分配加工厂接口里新增长工厂ID字段,整数类型,非必填 | 填写错误的或类型不对的加工厂ID | 略 | 返回具体的错误信息 |
不填写加工厂ID,其余条件符合要求 | 分配加工厂成功,XX系统的领料单正确显示加工厂名称 | ||||
填写正确的加工厂ID,其余条件符合要求 | 分配加工厂成功,XX系统的领料单正确显示加工厂名称 | ||||
填写正确的加工厂ID,对单领料单已经审核经过 | 返回提示“对单领料单不是待审核,不能分配加工厂”; |
四、测试人员执行测试用例以下:
2)结合测试用例,组合变换参数信息后,查看返回的JSON数据与PRD是否一致
3)测试用例遍历完成后,以上即完成了POST请求的接口功能测试。
4)这里描述一下postman的环境配置
第一步,如图
第二步,如图
第三步,如图
第四步,如图
第五步,如图(这是针对有多个环境的状况,好比通常都会有测试环境、验收环境、生产环境)
GET请求是用来获取数据的,下面以XX系统获取出库帐单为例,(如下只列出部分数据信息用于演示)
一、产品经理的PRD文档要求以下:
输入参数 | |||
字段名称 | 是否必填 | 取值逻辑 | 备注说明 |
帐单日期 | 是 | 例如2019-04-10 | |
供应商ID | 否 | ||
输出参数 | |||
帐单编号 | 是 | ML+年月日+流水号 | 一个帐单日期内,一个供应商只对应一个帐单 |
帐单日期 | 是 | 输入参数里的帐单日期 | |
供应商名称 | 是 | 从出库单获取 | |
SKU | 是 | 从出库单明细获取 | |
采购单价 | 是 | 根据SKU获取档案的基准价 | |
数量 | 是 | 出库数量 | |
帐单金额 | 是 | 采购单价*数量,金额为负 |
二、开发人员的接口文档以下:
接口名称:出库帐单同步到XX系统接口
参数名称 | 是否必须 | 示例 | 备注 |
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, //帐单金额 } ] } }
用例编号 | 所属模块 | 用例标题 | 前提条件 | 测试步骤 | 预期结果 |
01 | XX接口 | 输入正确的‘帐单日期’请求参数,接口正确返回相应的帐单数据 | 系统中有在该帐单日期内的帐单 | 一、在请求地址中增长‘billDate’参数; |
{"msg": "success", "code": "0", "info":….} |
02 | XX接口 | 输入不符合规范的‘帐单日期’请求参数,接口返回参数不符合要求 | 填写12/23/45 | 一、在请求地址中增长‘billDate’参数; |
{"msg":"帐单日期不符合规范;","code":"43"} |
03 | XX接口 | 将‘帐单日期’请求参数置空,接口返回参数必填 | 一、在请求地址中增长‘billDate’参数; |
{"msg":"帐单日期不能为空;","code":"43"} | |
04 | XX接口 | ‘供应商ID’请求参数 | 请求中没有‘billDate’ | 一、在请求地址中增长‘supplierId’参数; |
{"msg":"帐单日期不能为空;","code":"43"} |
05 | XX接口 | 请求中有‘billDate’ | 一、在请求地址中增长‘billDate’,‘supplierId’参数; |
{"msg": "success", "code": "0", "info":….} |
|
06 | XX接口 | 请求中有‘billDate’ | 一、在请求地址中增长‘billDate’,‘supplierId’参数; |
{"msg":"供应商ID不存在;","code":"43"} | |
07 | XX接口 | 请求中有‘billDate’ | 一、在请求地址中增长‘billDate’,‘supplierId’参数; |
{"msg": "success", "code": "0", "info":….} |
|
08 | XX接口 | ‘帐单编号’输出参数取值为:ML+年+月+日+4位流水号 | 接口返回正确数据 | 1.GET后,查看返回的JSON数据 | ‘帐单编号’输出参数取值为:ML+年+月+日+4位流水号 |
09 | XX接口 | 以上列举了部分测试用例,其余的测试用例就再也不展现了 |
2)结合测试用例,组合变换参数信息后,查看返回的JSON数据与PRD是否一致
3)测试用例遍历完成后,以上即完成了GET请求的接口功能测试。