接口测试用例的过程(接口测试用例的思路)

网友投稿 1219 2023-01-12


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

本文目录一览:

做接口测试的流程一般是怎么样的?

接口测试8大流程如下:

1、需求分析

项目立项后,对于整体产品的需求进行认识和理解(与功能测试的需求分析是一致的)。注意:此时只有产品需求文档,架构师还没有开始建模,主要目的是保证各部门(产品、开发、测试…)对于需求理解一致。

2 、api文档分析【重点】

该环节主要分析:请求和响应。

请求:请求url是否合理、请求信息头是否明确、请求方法是否合理、请求参数是否必填、含义、参数方式(url\form\json)。

响应:响应状态码是否合理、响应数据格式是否明确、响应信息头内容是否明确。

异常:异常返回信息和错误代码。

业务:接口彼此之间依赖关系。

该流程重点是:请求参数方式和类型、接口之间依赖关系、错误异常。

3、测试计划

由测试Leader编写,目的:分配测试任务进度安排和指导测试方案执行。

核心:测什么、谁来测、怎么测、风险预测及控制。

4、用例设计

提示:该环节主要针对参数、测试数据、安全、依赖、异常进行覆盖。

测试用例大体分为两种:根据需求进行提取测试点、设计用例覆盖测试点。

5、环境搭建

提示:项目环境部署需要根据计划中安排执行,是否需要测试人员部署。

环境搭建可以是LAMP也可以是LNMP。

6、 用例执行

使用公司指定工具执行测试用例。

提示:提测之前最好安排进行冒烟测试,保证提测时准时执行。

7、缺陷管理

使用缺陷管理工具来对执行用例的缺陷进行管理(与功能测试缺陷管理一致)。

提示:缺陷提交-修复-回归-关闭。

8、测试报告

测试报告不同公司有不同的模板,但测试报告主题内容一般分为下列四部分:测试过程、缺陷统计、缺陷分析、测试总结。

总结:

1、接口测试需要围绕测试计划实施。

2、接口测试重点是:api文档分析、用例设计。

3、具体接口应用工具主要根据后台协议和测试计划测试工具来定,可使用工具如:postman、jmeter、requests、抓包(fiddler、charles)。

接口测试流程是怎样的?

我们在做接口测试的时候需要根据流程进行,否则就达不到预期的效果,那下面我们就从测试前、测试中、测试后讲下接口测试的流程
①测试前
1.接口测试计划制定
2.接口测试用例和数据的准备
3.接口测试环境准备
4.编写接口测试脚本
5.测试前准备操作
6.测试脚本调试
7.接口测试内容制定
②测试中
1.接口测试的执行策略(包括执行轮次和顺序)
2.接口测试执行过程监控到失败后的重试
3.线上只读接口的测试
③测试后
1.测试后产生垃圾数据的清除
2.测试失败原因分析
3.接口测试bug的提交和回归验证
4.线上监控到紧急bug的验证
5.接口测试后复盘总结
我朋友当初在黑马程序员学习时候就直接整理文档给了我一份,这些也都有。

请问Jmeter进行接口功能测试操作步骤是怎样的?

操作步骤:
1、指定接口功能测试相关测试计划
2、从 API 文档提取接口清单
3、编写测试用例并设计测试数据
4、编写测试脚本并导入测试数据
5、执行脚本并逐条比对每条测试数据接口测试用例的过程的实际结果与预期结果是否一致
各步骤主要实现:
1、指定接口功能测试相关测试计划
对程序不同模块进行任务划分,一般包括: 模块以及相关描述,指定该模块主要责任人,工期,预期产出以及当前进度等
2、从 API 文档提取接口清单
API 文档对各个接口实现具有完整且详细接口测试用例的过程的流程说明,以及举例,但是对于我们测试而言,内容相对冗余,测试前期,一般会对API文档接口测试用例的过程的各个接口,进行简化,压缩,提取接口测试时必须数据,以提高接口测试效率,其中简化压缩的结果就是接口清单
3、编写测试用例并设计测试数据
功能测试时,模拟用户的多样性操作设计测试数据是核心实现之一,该过程大致通过两步骤实现:
步骤1: 设计测试用例,该过程是抽象的非具体的实现,是要声明预期使用那些类型的测试数据,而不设计具体数据,设计测试用例时原则主要有如下几点:
a)、覆盖所有必选参数
b)、组合可选参数
c)、设计边界值数据
d)、设计超出范围的数据
e)、覆盖所有枚举值
f)、设计错误数据
g)、设计特殊符号数据
.....
另外,设计时需要在测试用例中声明该接口访问的 URL,请求方式以及预期结果等
步骤2: 根据测试用例声明的数据类型,设计具体的测试数据,此过程为具体非抽象的实现,最终设计的数据一般会被保存在csv文件中
4、编写测试脚本并导入测试数据
功能测试时,需要针对同一功能脚本提交多条不同的测试数据,此实现中,一般使用 CSV Data Set Config 来读取批量数据,动态的参数化的获取并设置测试数据,可以提高测试效率
5、执行脚本并逐条比对每条测试数据的实际结果与预期结果是否一致
步骤4批量操作完毕,要将提交的每条测试数据的执行结果与测试用例中对应的执行结果,相比对,如果预期与实际结果一致,一般无 BUG,不一致时,则可能有 BUG,当然对具体实现有疑议,可以写入备注
以上内容均来自传智播客论坛,还有相关配套视频课程。找不到就官网对话框领取。

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

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

一、   前言   

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

二、   测试用例设计思路   

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

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

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

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

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

2、 单接口测试优先级  

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

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

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

4) 默认参数是否满足  

5) 参数校验  

6) 参数间联动关系

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

三、   设计分析   

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

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

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

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

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

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

参数校验包含如下几方面:

[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字段为空接口测试用例的过程;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输入不为空的测试用例重复,所以选择一条用例验证 。 ),以上的测试用例满足自动化的要求,手动测试过程中需要增加部分验证性的测试用例。且由于使用的测试工具特殊性,无需检查输入参数的类型。

如何简单设计接口测试用例

接口测试是项目测试的一部分
,它测试的主要对象是接口
,是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。测试的重点是检查数据交互、传递、和控制管理过程以及系统间的相互依赖关系等。
如何设计接口测试用例?首先,明确出发点,和所有的测试一样
,接口测试出发点是你要证明所测的程序是错误的。以这个出发点为导向
,你的设计行为就会尽量朝这个方向,更易发现问题
其次,选择好测试对象。对于一个系统做接口测试选择好的测试对象是接口测试关键。一个系统有无数的接口
,每个接口如果分别测试
,那将是很痛苦的一件事情,而且任何一个内部接口的变动
,都将导致我们用例的不可用。
可将这些最外层的接口分为两类:一类是数据进入系统的接口;一类是数据流出系统的接口。进入系统的接口实际是我们用例的执行调用的接口。可通过变化参数对这些接口进行调用
,模拟外部的使用;而流出的接口则是我们用例真正该验证的点。数据从哪里流出,流出时的状态如何
,此时系统又是什么状态都是我们所应该验证的。
然后,确认完整的测试对象的功能:确认外部接口提供给使用这些接口的外部用户什么样的功能,外部用户真正需要什么样的功能。此两个功能一定要准确详细,用例的设计要严格按照测试对象功能设计才是正确的用例。
最后当出发点、对象、功能都确定了,就可以真正设计用例了。下面详细介绍下如何去设计一个结构好、可读性高、渗透性强的接口测试用例。
接口测试用例设计和测试用例设计一样,用例设计的内容应该包括:主要测试功能点、测试环境、测试数据、执行操作以及预期结果。
1)接口测试环境分为两种:一种是程序内部的环境;一种是程序的所调用外部接口的环境。
2)接口测试测试数据分为接口参数数据和用例执行所需系统数据。数据的设计、准备测试用例的数据上需要花费更多的心思。要通过好的测试数据使用例查找问题。接口参数数据需对每个参数根据测试接口的实际的功能进行分析,在符合业务逻辑的情况下进行逻辑组合排列
,不要遗漏了某些边界值和错误点的数据。每个用例执行所需系统数据和接口参数数据尽可能的采用不一样的数据
,使用例更容易发现问题。
3)测试功能点,如果一个接口功能复杂时推荐对接口用例进行结构划分
,这样子用例具有更好的可读性和维护性。接口划分原则为以接口提供的功能点的不同进行合适粒度的划分。同一功能点的用例又可根据测试环境的不同、数据的不同进行用例的填充。
4)接口测试用例执行操作非常简单,就是所测接口的调用。
5)预期结果验证,这也是接口用例设计的很关键的一步
,应该细而不冗余。每个用例均需验证
,避免一个用例中重复做相同的验证
,提高测试用例的效率。
如何设计接口测试用例小例子:
简单划分可以按照2个基本组成要素进行划分:1.
参数
2.
业务
以下为最简单的一种划分用例的方法,可能涵盖不全,但只为说明一种划分接口用例的方法方式以及需要考虑的测试用例的测试点
为何要如此设计,是为了更好的将用例分类为程序规定型以及业务限制型,尽量的保证覆盖,尽量细化到点的划分形式来保证工作时间的预估和计划。
所有的自动化接口的测试用例
都基本围绕三部曲进行,传数据,执行,校验返回的数据和期望数据是否一致来构成每个简单的测试用例。
有清晰的线路和清晰的思维,才能做好整体测试的掌控。

接口测试的测试用例该怎么写呢?

接口测试:

接口:主要是子模块或者子系统间交互并相互作用的部分。

这里说的接口是广义的,客户端与后台服务间的协议;插件间通信的接口;模块间的接口;再小到一个类提供的方法;都可以理解为接口。因此,可以分析,系统间的接口包含三部分:输入、处理逻辑、输出。

接口测试:是指针对模块或系统间接口进行的测试。

分析一个接口:

获取接口文档:和黑盒测试一样,我们是从需求文档中去挖掘测试点,设计测试用例。对于接口测试,同样是有对应的接口文档的。

分析接口文档,提取测试点:

1)输入:接受哪些参数、参数的类型、可选参数和必选参数等;根据输入参数采用等价类、边界值分析法等进行设计。

2)业务逻辑:对于一个接口,不同的输入参数或组合,流程或状态的转移是不同,可以根据业务逻辑画出流程图或状态转移图,确保每种状态至少被访问了一次。

3)输出:根据文档规定的输出,反向设计测试数据,使所有的输出状态都被包含了;

测试用例:同时对输入、业务逻辑、输出进行考虑时,肯定会存在用例的冗余,在最大限度覆盖业务功能和规则下,选取最优用例集合。同时,需要考虑异常数据和场景。

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

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

上一篇:微服务网关(微服务网关有哪些)
下一篇:微服务网关是应用专用吗(微服务网关和注册中心区别)
相关文章

 发表评论

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