json接口测试测试用例(json调用接口例子)

网友投稿 1176 2023-02-23


本篇文章给大家谈谈json接口测试测试用例,以及json调用接口例子对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。 今天给各位分享json接口测试测试用例的知识,其中也会对json调用接口例子进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!

本文目录一览:

接口自动化测试测试用例设计

浅谈接口自动化测试测试用例设计

一、   前言   

很多中台项目json接口测试测试用例,大部分为接口测试。为了使新入职json接口测试测试用例的测试同事尽快融入项目,以及迭代开发中方便管理测试用例。完成该总结。

二、   测试用例设计思路   

1、 接口类型概述及优先级  

1) 提供给第三方调用的接口  

2) 内部系统使用,核心功能接口  

3) 内部系统使用,非核心功能接口  

基本按照1)2)3)的顺序进行测试,特别情况除外

2、 单接口测试优先级  

1) 优先测试正向测试用例,保证基本功能实现  

2) 设计逆向测试用例,确保接口的健壮性  

3) 满足前提条件的测试用例  

4) 默认参数是否满足  

5) 参数校验  

6) 参数间联动关系

7)多参数错误处理的优先顺序校验

三、   设计分析   

1、 满足前提条件的测试用例  

测试目标接口需要满足前置条件才能成功获取数据。

例如json接口测试测试用例:需要登录token,通过传入参数获取下游接口数据

2、 携带默认参数的测试用例  

携带默认参数的测试用例仅需要设计一条,所有默认参数的字段都不填写,其他字段输入正常。

[if !supportLists]3、 [endif]参数校验  

参数校验包含如下几方面json接口测试测试用例

[if !supportLists]1)[endif]输入参数是否为必须输入项

[if !supportLists]2)[endif]输入参数的类型

[if !supportLists]3)[endif]输入参数的枚举值校验

[if !supportLists]4)[endif]输入参数长度校验

以上测试用例最好根据字段一一校验,排除互相干扰

[if !supportLists]4、 [endif]参数间联动  

有些参数见存在彼此制约的关系,根据实际情况设计测试用例

例如:A字段为1时,B字段一定为空。否则报错。

那么测试用例设计时应为:A字段为1时,B字段为空json接口测试测试用例;A字段为1时,B字段不为空;A字段不为1时,B字段为空;A字段不为1时,B字段不为空;四条测试用例

这样基本覆盖所有分支流程。

[if !supportLists]四、 [endif] 测试用例实践操作

接口测试用例样例:

多条件查询接口

测试方法:使用robotFramework测试doubbo接口

协议请求方式:post

接口协议:JSON

消息请求列表

字段名数据类型默认值必须项备注

IDint 是长度为2

Tokenstring 是设备令牌

Statusstring 是1:正常

2:异常

typeint  Status为1时,为必须输入项

sizestring  默认值
消息返回列表

字段名数据类型必须项备注

Codeint是正常:20000

异常:20001

Messagestring是 

typeMessageint Status=1的所有ID

 

用例设计

 

NO. 测试内容 前置条件 输入参数 输出参数 用例属性

1目标数据为一条预置一条符合条件的数据Status=1,其他参数输入正常返回code=20000

typeMessage中返回的ID与预置数据一致

正向测试用例

2目标数据为多条预置多条符合条件的数据Status=1,其他参数输入正常返回code=20000

typeMessage中返回的ID与预置数据一致

正向测试用例

3 Token必须项检查 预置多条符合条件的数据Status=1,token输入为空,其他参数输入正常返回code=20001

typeMessage中返回为空

满足前提条件

4 Token正确性检查 预置多条符合条件的数据Status=1,token输入错误,其他参数输入正常返回code=20001

typeMessage中返回为空

满足前提条件

5 Status 必须项检查 预置多条符合条件的数据Status为空,其他参数输入正常返回code=20001

typeMessage中返回为空

参数校验

6 Status枚举预置多条符合条件的数据Status为1,其他参数输入正常返回code=20000

typeMessage中返回的ID与预置数据一致

参数校验

7 Status枚举预置多条符合条件的数据Status为2,其他参数输入正常返回code=20000

typeMessage中返回的ID与预置数据一致

参数校验

8 Status枚举预置多条符合条件的数据Status为3,其他参数输入正常返回code=20001

typeMessage中返回null

参数校验

9 Status=1,时联动校验预置多条符合条件的数据Status为1,type为空;其他参数输入正常返回code=20001

typeMessage中返回null

联动校验

10 Status!=1,时联动校验预置多条符合条件的数据Status!=1,type为空;其他参数输入正常返回code=20000

typeMessage中返回对应ID

联动校验

11 Status!=1,时联动校验预置多条符合条件的数据Status!=1,type不为空;其他参数输入正常返回code=20000

typeMessage中返回对应ID

联动校验

12 Size默认值输入校验预置多条符合条件的数据Size输入为空,其他参数输入正常返回code=20000

typeMessage中返回对应ID

默认值校验

13 Size默认值输入校验预置多条符合条件的数据Size输入不为空,其他参数输入正常返回code=20000

typeMessage中返回对应ID

默认值校验

14 ID 必须项检查 预置多条符合条件的数据ID为空,其他参数输入正常返回code=20001

typeMessage中返回为空

参数校验

15 ID 长度检查 预置多条符合条件的数据ID长度大于2,其他参数输入正常返回code=20001

typeMessage中返回为空

参数校验

16 破坏性测试预置多条符合条件的数据输入的参数类型错误请求未接收,返回404 稳定性测试

17 破坏性测试预置多条符合条件的数据输入的参数与提供的参数名称不一致请求未接收,返回404 稳定性测试

18 破坏性测试预置多条符合条件的数据输入的参数与提供的参数数量不一致请求未接收,返回404 稳定性测试

19 破坏性测试预置多条符合条件的数据输入的参数与提供的参数格式不一致请求未接收,返回404 稳定性测试

 

总结:自动化测试过程中会有一条自动化测试用例覆盖多种情况的可能(例如:正向测试用例与联动性验证的 Status=1,type输入不为空的测试用例重复,所以选择一条用例验证 。 ),以上的测试用例满足自动化的要求,手动测试过程中需要增加部分验证性的测试用例。且由于使用的测试工具特殊性,无需检查输入参数的类型。

『居善地』接口测试 — 21.Mock功能介绍(二)

当需要调用接口来编写测试用例json接口测试测试用例的时候json接口测试测试用例,此时该接口并没有被实现,这个时候json接口测试测试用例我们就可以用Mock框架来模拟一个接口出来。

使用Mock模拟接口以下功能json接口测试测试用例

编写一个Json文件,接口所有的信息都配置在该json文件中。

把Moco框架的jar包和上面编辑好的Json文件放在同一个文件夹中。

在cmd命令行或者PyCharm的命令行终端执行启动命令。

Moco服务启动后,我们可以使用Requests库请求接口,也可以用浏览器接口。

浏览器访问接口:

我们主要是看Json文件怎么写,其他步骤和上面练习一样。

1)、没有参数的get请求

2)、有参数的get请求

说明:请求地址为: api/moco/get/param/demo?name=xiaomingage=18

1)、没有参数的post请求

提示:POST请求就不能用浏览器进行查看了。只能用Request库或者JMeter,Postman等进行查看。(能进行接口调用的工具都可以)

2)、有参数的post请求

调用接口查看结果。

使用的是 request 中的 cookies 属性。

1)、get请求

调用接口查看结果。

2)、post请求

调用接口查看结果。

使用的是 request 中的 headers 属性。

Header 是添加请求头信息,关于请求头信息get请求和post请求都是一样的。

调用接口查看结果。

重定向使用的是和 request 同级的 redirectTo 属性。

使用浏览器进行测试就可以。

Json文件的配置属性说明:

像我们上面练习过的Json文件配置,所有的数据值是固定的,

如: description 、 request 、 response 、 redirectTo 等这些都是固定的,不能修改,修改可能连Moco服务都启动不来。

还有 request 的属性值,如: uri 、 method 、 cookies 、 headers ,也是必须这样写的。

还有GET请求传递参数用 queries 属性,POST请求传递参数用 forms 和 json 属性都可以。(PUT,DELETE请求同Post请求。)

Moco框架原理:

就是把所有接口的数据,包括发送请求的所有数据和返回结果的所有数据,以Json数据格式进行编写。

把这些数据放入Moco框架提供的HTTP或者HTTPS的服务上,就实现了接口数据的模拟。

在使用的时候,我们只要按照json文件中接口配置的信息进行请求即可,如果调用接口传递的数据和Json文件中接口编写要接收的数据不一致,则无法请求成功。

接口测试的测试点有哪些

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。

测试的策略:

接口测试也是属于功能测试,所以跟我们以往的功能测试流程并没有太大区别,测试流程依旧是:

评审测试接口文档(需求文档)

根据接口文档编写测试用例(用例编写完全可以按照以往规则来编写,例如等价类划分,边界值等设计方法)

执行测试,查看不同的参数请求,接口的返回的数据是否达到预期

那么设计测试用例时我们主要考虑如下几个方面:

功能测试:

接口的功能是否正确实现了

接口是否按照设计文档中来实现(比如username参数写为了user,那么这就不符合,因为接口文档在整个开发中都需要使用,所以接口实际的设计要与接口设计文档中保持一致)

兼容性测试: 比如说今天接口进行了调整,但是前端没有进行变更,这时候需要验证新的接口是否满足旧的调用方式

错误码测试: 通用的错误码与业务错误码是否能够清晰的说明调用问题,错误码是否能够尽可能的全的覆盖所有的情况

返回值测试: 返回值除了内容需要是正确的,还需要类型也是正确的,保证调用方拿到这些参数能够正确的解析

参数边界值、等价类测试

json格式测试: 通常我们的接口一般设计的都是传递json串,那么就需要去测试 如果传递非json的情况,这时候程序会不会正确的处理,返回相应的 error code

默认值测试: 很多情况一些非必填的参数会有默认值,比如说一个查询的接口,参数count为返回查询的结果数量, 默认为10,那么就应该有一条case来测试,当然前置条件是数据库里面必须要存在这样的数据超过10条。

逻辑业务:

是否有依赖业务,比如查看订单,是需要用户首先登录的,所以肯定要保证登录了或有相应的cookie

业务逻辑测试: 传递正确的参数,接口对数据库进行查询的操作,需要去验证数据库查询是否正确,接口对数据库进行 增删改的操作,也需要看数据库是否同步进行了这些操作

异常测试:

异常分为两类,参数异常和数据异常

参数异常:

关键字参数:将参数写为开发语言中的关键字

参数为空:比如去掉了username参数

多或少参数:多或者少参数的验证,现在还不确定如果一个接口多了参数如果没有报错是否是合理的,或者是否需要优化,因为就目前开发给予的答案是,一般不对接口多了参数的处理

错误参数:比如将username参数写为了user等看是否能返回相应的error code

数据异常:

关键字数据:将参数的值填为开发语言中的关键字

数据为空:将参数的额值填为空

长度不一致:因为数据库中每个字段都设置有字段长度,填写不符合的长度进行验证

错误数据:就是将参数的值任意填写,或填写不存在的数值

异常类型测试: 比如count参数,这个参数的类型一定是可以转换为int类型的,这时候我们需要测试如果传的一些不可以 转换为int类型值来测试代码是否加入判断

性能测试:

响应时间

吞吐量

并发用户数

占用内存,CPU等

安全性测试:

敏感信息是否加密

必要参数是否后端也进行校验(现在很多系统前后端架构是分离的,从安全层面来说,只依赖前端进行限制已经完全不能满足系统的安全要求(绕过前端太容易了), 需要后端同样进行控制,在这种情况下就需要从接口层面进行验证)

接口是否防恶意请求(SQL注入)

cookie:就是将header中的cookie修改或删除后看是否能返回相应的error code

header:就是删除或修改header中部分参数的值,看是否能返回相应的error code

唯一识别码:删除修改唯一识别码测试

jmeter提取json数据进行接口参数关联

案例场景:在测试创建订单使用系统的企业支付时,需要获取到创建订单后的订单编号才能支付,在jmeter里面可以直接提取上一个接口json里面的值(sysno)作为下一个支付接口的入参。我现在有一个创建订单接口A,创建成功后会返回一个sysno值。企业支付请求接口B必须要获取到接口A返回订单编号才能支付。这里介绍一下jmeter使用后置处理器【json extractor】获取你想要得到的值,根据上一个接口具体返回的json格式去自定义【json path expressions】json路径表达式。

A接口创建订单接口文档基本信息

请求类型:POST

请求头部:application/json

请求参数:[{"soType":0,"distributorSysNo":100001,"receiverInfo":{"receiveAddress":"收货地址","receiveAreaSysNo":2620,"receiveContact":"联系人","receivePhone":"15878788784"},"products":[{"productSysNo":42753,"quantity":2,"memo":null,"expectDeliveryDate":null},{"productSysNo":41681,"quantity":1,"memo":null,"expectDeliveryDate":null},],"customerMemo":客户备注信息,"deliveyType":54}]

A接口的请求和返回的报文信息如下
B接口企业支付的接口文档基本信息

请求类型:POST

请求头部:application/json

请求参数:{"orderSysNos":["${ordersysno}"],"soSysNo":"${ordersysno}","payTypeId":"balancepay","orderType":0,"balancePwd":"123456"}

创建订单请求

JSON提取器

注意:添加后置提取器时一定要放在http请求下面,不能放在线程组下面否则会一直提取不到下一个接口读取的值就会错误

JSON提取器参数说明:

Names of created variables 参数名称

JSON Path expressions 提取表达式

Match No.(0 for Random) 匹配规则,-1所有,0随机,1第一个

Compute concatenation va 如果有匹配到多个值,选择此项,会将全部值保存到_ALL,并使用逗号分割每个值,注意Match No. (0 for Random)需要为-1才有效,不然只能匹配到一个值了

Default Values 没提取到就给默认值

JSON提取器表达式说明,如果是获取第一层级的直接用$.参数,比如我们要获取接口A返回的code,JSON Path expressions就用$.code;如果是返回的是一个数组就要根据返回内容去找到对应参数即可,比如我们获取的是接口A返回的data第一个sysno,就用data[0].sysNo,注意写参数时一定要和返回的一样(最好是复制),比如写成了data[0].sysno就提取不到,因为在data中找不到sysno

关联请求

如何使用python进行json的接口测试

说明
sepjson接口测试测试用例:分隔符。可以为空
seqjson接口测试测试用例:要连接的元素序列、字符串、元组、字典
上面的语法即json接口测试测试用例:以sep作为分隔符json接口测试测试用例,将seq所有的元素合并成一个新的字符串
返回值:返回一个以分隔符sep连接各个元素后生成的字符串

Apifox写接口自动化测试用例总结-1

最近决定用Apifox写接口自动化测试用例,于是研究了这个工具的具体实践,下面把最近实践过程中遇到的问题和解决方案进行总结,方便回看。

Apifox它是集:接口文档管理、接口调试、Mock、接口自动化测试于一体的全流程集成工具,覆盖从开发-测试-管理等环节,等同于 Postman + Swagger + Mock + JMeter几款工具功能累加。

下面从以下几个方面来进行总结:
1json path语法及使用
2.参数化使用
3.结果验证

JsonPath语法要点:
$ 表示文档的根元素
@ 表示文档的当前元素
.node_name 或 ['node_name'] 匹配下级节点
[index] 检索数组中的元素
[start:end:step] 支持数组切片语法
** 作为通配符,匹配所有成员**
.. 子递归通配符,匹配成员的所有子元素
(<expr) 使用表达式
?(<boolean expr)进行数据筛选

直接从返回结果中获取第一个元素

从返回结果中获取iata=3Q的子节点中的id号

1.用两个{}的形式来传参,如{{flightId}}
2.如果提取变量是列表形式,可以取其中某一个,如{{flightId[0]}}
3.可以选择右侧的“魔法棒”动态值来选择变量/常量或动态变量

关于json接口测试测试用例和json调用接口例子的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。 json接口测试测试用例的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于json调用接口例子、json接口测试测试用例的信息别忘了在本站进行查找喔。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:java 接口 单元测试(接口测试和单元测试)
下一篇:api 接口权限管理框架(api接口权限验证)
相关文章

 发表评论

暂时没有评论,来抢沙发吧~