本篇文章给大家谈谈接口对接测试用例图,以及简单的接口测试实例对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。
今天给各位分享接口对接测试用例图的知识,其中也会对简单的接口测试实例进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!
本文目录一览:
接口测试的测试用例该怎么写呢?
接口测试接口对接测试用例图:
接口接口对接测试用例图:主要是子模块或者子系统间交互并相互作用接口对接测试用例图的部分。
这里说接口对接测试用例图的接口是广义的,客户端与后台服务间的协议;插件间通信的接口;模块间的接口;再小到一个类提供的方法;都可以理解为接口。因此,可以分析,系统间的接口包含三部分:输入、处理逻辑、输出。
接口测试:是指针对模块或系统间接口进行的测试。
分析一个接口:
获取接口文档:和黑盒测试一样,接口对接测试用例图我们是从需求文档中去挖掘测试点,设计测试用例。对于接口测试,同样是有对应的接口文档的。
分析接口文档,提取测试点:
1)输入:接受哪些参数、参数的类型、可选参数和必选参数等;根据输入参数采用等价类、边界值分析法等进行设计。
2)业务逻辑:对于一个接口,不同的输入参数或组合,流程或状态的转移是不同,可以根据业务逻辑画出流程图或状态转移图,确保每种状态至少被访问了一次。
3)输出:根据文档规定的输出,反向设计测试数据,使所有的输出状态都被包含了;
测试用例:同时对输入、业务逻辑、输出进行考虑时,肯定会存在用例的冗余,在最大限度覆盖业务功能和规则下,选取最优用例集合。同时,需要考虑异常数据和场景。
接口测试用例怎么设计
在开始接口测试之前
接口对接测试用例图,我们想一下,接口测试的流程是什么?说到这里,有些人就会产生好奇和疑问,心里mmp:接口测试要什么流程哈???不就是参考接口文档,直接利用接口测试工具(例如jmeter和postman)测试。。。其实,如果一个project中,只是几个接口,你完全可以做临时的接口测试,但project可不止几个接口,少则几十条接口,多则成百上千接口。另外,如果你公司的这个项目,第一次做接口测试。而且古人说过:“无规矩不成方圆。”所以哈,我们还是有必要严格遵守接口测试的流程。
二、接口测试的流程
接口测试属于功能测试,接口测试的流程类似于以往的功能测试。接口测试的流程如下:
测试尽早找开发拿接口文档(需求文档)
接口对接测试用例图;
根据接口文档编写测试用例(用例编写可按照以往规则写,比如等价类划分,边界值,场景法等设计方法);
执行测试,查看不同的参数请求,接口返回的数据是否达到预期

三、为什么要写用例
理清思路,避免漏测和重复测;
提高测试效率;
跟进测试进度;
更好的发现问题,记录问题,复现问题;
跟进重复性工作;
告诉领导:我做过;
接口测试流程中的一个产物(测试用例)
上面7点,有用例,自己心中有数,不用一个测试点重复测好多次,也避免漏测。
各种测试用例简要模板
0 . 文档介绍
提示:请用户根据项目的实际测试状况,裁剪本测试用例模板。
0.1 文档目的
0.2 文档范围
0.3 读者对象
0.4 参考文献
提示: 列出本文档的所有参考文献(可以是非正式出版物),格式如下:
[ 标识符 ] 作者,文献名称,出版单位(或归属单位),日期
例如:
[ AAA ] 作者,《立项建议书》,机构名称,日期
[ SPP-PROC-ST ] SEPG,系统测试规范,机构名称,日期
0.5 术语与缩写解释
缩写、术语 解 释
SPP精简并行过程,Simplified Parallel Process
…
1 . 接口-路径测试用例
1 .1 被测试对象(单元)的介绍
1.2 测试范围与目的
1 . 3 测试环境与测试辅助工具的描述
1.4 测试驱动程序的设计
1.5 接口测试用例
接口A的函数原型
输入/动作期望的输出/相应实际情况
典型值…
边界值…
异常值…
接口B的函数原型
输入/动作期望的输出/相应实际情况
典型值…
边界值…
异常值…
…
1.6 路径测试的检查表
检查项 结论
数据类型问题
(1)变量的数据类型有错误吗?
(2)存在不同数据类型的赋值吗?
(3)存在不同数据类型的比较吗?
变量值问题
(1)变量的初始化或缺省值有错误吗?
(2)变量发生上溢或下溢吗?
(3)变量的精度不够吗?
逻辑判断问题
(1)由于精度原因导致比较无效吗?
(2)表达式中的优先级有误吗?
(3)逻辑判断结果颠倒吗?
循环问题
(1)循环终止条件不正确吗?
(2)无法正常终止(死循环)吗?
(3)错误地修改循环变量吗?
(4)存在误差累积吗?
内存问题
(1)内存没有被正确地初始化却被使用吗?
(2)内存被释放后却继续被使用吗?
(3)内存泄漏吗?
(4)内存越界吗?
(5)出现野指针吗?
文件I/O问题
(1)对不存在的或者错误的文件进行操作吗?
(2)文件以不正确的方式打开吗?
(3)文件结束判断不正确吗?
(4)没有正确地关闭文件吗?
错误处理问题
(1)忘记进行错误处理吗?
(2)错误处理程序块一直没有机会被运行?
(3)错误处理程序块本身就有毛病吗?如报告的错误与实际错误不一致,处理方式不正确等等。
(4)错误处理程序块是“马后炮”吗?如在被它被调用之前软件已经出错。
…
2. 功能测试用例
2 .1 被测试对象的介绍
2 .2 测试范围与目的
2. 3 测试环境与测试辅助工具的描述
2 .4 测试驱动程序的设计
2 .5 功能测试用例
功能A描述
用例目的
前提条件
输入/动作期望的输出/相应实际情况
示例:典型值…
示例:边界值…
示例:异常值…
功能B描述
用例目的
前提条件
输入/动作期望的输出/相应实际情况
……
3. 健壮性测试用例
3 .1 被测试对象的介绍
3 .2 测试范围与目的
3. 3 测试环境与测试辅助工具的描述
3 .4 测试驱动程序的设计
3 .5 容错能力 / 恢复能力测试用例
异常输入/动作容错能力/恢复能力造成的危害、损失
示例:错误的数据类型…
示例:定义域外的值…
示例:错误的操作顺序…
示例:异常中断通信…
示例:异常关闭某个功能…
示例:负荷超出了极限…
4 . 性能测试用例
4 .1 被测试对象的介绍
4 .2 测试范围与目的
4. 3 测试环境与测试辅助工具的描述
4 .4 测试驱动程序的设计
4 .5 性能测试用例
性能A描述
用例目的
前提条件
输入数据期望的性能(平均值)实际性能(平均值)
性能B描述
用例目的
前提条件
输入数据期望的性能(平均值)实际性能(平均值)
……
5 . 图形用户界面测试用例
5 .1 被测试对象的介绍
5 .2 测试范围与目的
5. 3 测试环境与测试辅助工具的描述
5 .4 测试驱动程序的设计
5 .5 测试人员分类
类别特征
A类
B类
……
5.6 用户界面测试的检查表
检查项测试人员的类别及其评价
窗口切换、移动、改变大小时正常吗?
各种界面元素的文字正确吗?(如标题、提示等)
各种界面元素的状态正确吗?(如有效、无效、选中等状态)
各种界面元素支持键盘操作吗?
各种界面元素支持鼠标操作吗?
对话框中的缺省焦点正确吗?
数据项能正确回显吗?
对于常用的功能,用户能否不必阅读手册就能使用?
执行有风险的操作时,有“确认”、“放弃”等提示吗?
操作顺序合理吗?
有联机帮助吗?
各种界面元素的布局合理吗?美观吗?
各种界面元素的颜色协调吗?
各种界面元素的形状美观吗?
字体美观吗?
图标直观吗?
…
6. 信息安全性测试用例
6 .1 被测试对象的介绍
6 .2 测试范围与目的
6. 3 测试环境与测试辅助工具的描述
6 .4 测试驱动程序的设计
6 .5 信息安全性测试用例
假想目标A
前提条件
非法入侵手段是否实现目标代价-利益分析
……
假想目标B
前提条件
非法入侵手段是否实现目标代价-利益分析
……
7. 压力测试用例
7 .1 被测试对象的介绍
7 .2 测试范围与目的
7. 3 测试环境与测试辅助工具的描述
7 .4 测试驱动程序的设计
7 .5 压力测试用例
极限名称A 例如“最大并发用户数量”
前提条件
输入/动作输出/响应是否能正常运行
例如10个用户并发操作
例如20个用户并发操作
…
极限名称B
前提条件
输入/动作输出/响应是否能正常运行
…
8. 可靠性测试用例
8 .1 被测试对象的介绍
8 .2 测试范围与目的
8. 3 测试环境与测试辅助工具的描述
8 .4 测试驱动程序的设计
8 . 5 可靠性测试用例
任务A描述
连续运行时间
故障发生的时刻故障描述
……
统计分析
任务A无故障运行的平均时间间隔(CPU小时)
任务A无故障运行的最小时间间隔(CPU小时)
任务A无故障运行的最大时间间隔(CPU小时)
任务B描述
连续运行时间
故障发生的时刻故障描述
……
统计分析
任务B无故障运行的平均时间间隔(CPU小时)
任务B无故障运行的最小时间间隔(CPU小时)
任务B无故障运行的最大时间间隔(CPU小时)
9. 安装 / 反安装测试用例
9 .1 被测试对象的介绍
9 .2 测试范围与目的
9. 3 测试环境与测试辅助工具的描述
9 .4 测试驱动程序的设计
9 . 5 安装 / 反安装测试用例
配置说明
安装选项描述是否正常使用难易程度
全部
部分
升级
其它
反安装选项描述是否正常使用难易程度
附录:评审意见
如何简单设计接口测试用例
接口测试是项目测试
接口对接测试用例图的一部分 ,它测试的主要对象是接口 ,是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。测试的重点是检查数据交互、传递、和控制管理过程以及系统间的相互依赖关系等。 如何设计接口测试用例?首先,明确出发点,和所有的测试一样 ,接口测试出发点是你要证明所测的程序是错误的。以这个出发点为导向 ,你的设计行为就会尽量朝这个方向,更易发现问题 其次,选择好测试对象。对于一个系统做接口测试选择好的测试对象是接口测试关键。一个系统有无数的接口 ,每个接口如果分别测试 ,那将是很痛苦的一件事情,而且任何一个内部接口的变动 ,都将导致我们用例的不可用。 可将这些最外层的接口分为两类
接口对接测试用例图:一类是数据进入系统的接口;一类是数据流出系统的接口。进入系统的接口实际是我们用例的执行调用的接口。可通过变化参数对这些接口进行调用 ,模拟外部的使用;而流出的接口则是我们用例真正该验证的点。数据从哪里流出,流出时的状态如何 ,此时系统又是什么状态都是我们所应该验证的。 然后,确认完整的测试对象的功能:确认外部接口提供给使用这些接口的外部用户什么样的功能,外部用户真正需要什么样的功能。此两个功能一定要准确详细,用例的设计要严格按照测试对象功能设计才是正确的用例。 最后当出发点、对象、功能都确定了,就可以真正设计用例了。下面详细介绍下如何去设计一个结构好、可读性高、渗透性强的接口测试用例。 接口测试用例设计和测试用例设计一样,用例设计的内容应该包括:主要测试功能点、测试环境、测试数据、执行操作以及预期结果。 1)接口测试环境分为两种:一种是程序内部的环境;一种是程序的所调用外部接口的环境。 2)接口测试测试数据分为接口参数数据和用例执行所需系统数据。数据的设计、准备测试用例的数据上需要花费更多的心思。要通过好的测试数据使用例查找问题。接口参数数据需对每个参数根据测试接口的实际的功能进行分析,在符合业务逻辑的情况下进行逻辑组合排列 ,不要遗漏了某些边界值和错误点的数据。每个用例执行所需系统数据和接口参数数据尽可能的采用不一样的数据 ,使用例更容易发现问题。 3)测试功能点,如果一个接口功能复杂时推荐对接口用例进行结构划分 ,这样子用例具有更好的可读性和维护性。接口划分原则为以接口提供的功能点的不同进行合适粒度的划分。同一功能点的用例又可根据测试环境的不同、数据的不同进行用例的填充。 4)接口测试用例执行操作非常简单,就是所测接口的调用。 5)预期结果验证,这也是接口用例设计的很关键的一步 ,应该细而不冗余。每个用例均需验证 ,避免一个用例中重复做相同的验证 ,提高测试用例的效率。 如何设计接口测试用例小例子: 简单划分可以按照2个基本组成要素进行划分:1. 参数 2. 业务 以下为最简单的一种划分用例的方法,可能涵盖不全,但只为说明一种划分接口用例的方法方式以及需要考虑的测试用例的测试点 为何要如此设计,是为了更好的将用例分类为程序规定型以及业务限制型,尽量的保证覆盖,尽量细化到点的划分形式来保证工作时间的预估和计划。 所有的自动化接口的测试用例 都基本围绕三部曲进行,传数据,执行,校验返回的数据和期望数据是否一致来构成每个简单的测试用例。 有清晰的线路和清晰的思维,才能做好整体测试的掌控。
如何做接口测试
做接口测试流程:
测试接口文档。
根据接口文档编写测试用例(用例编写方法完全可以按照黑盒测试的用例编写规则来编写,如:边界值、正交表等等设计方法)。
执行测试,查看接口返回的接口数据是否正确,主要检查返回的接口是否和接口文档中定义的一样,还有要检查返回的数据是否和数据库中的保持一致。
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。
①目的:测试接口的正确性和稳定性;
②原理:模拟客户端向服务器发送请求报文,服务器接收请求报文后对相应的报文做处理并向客户端返回应答,客户端接收应答的过程;
③重点:检查数据的交换,传递和控制管理过程,还包括处理的次数;
④核心:持续集成是接口测试的核心;
⑤优点:为高复杂性的平台带来高效的缺陷监测和质量监督能力,平台越复杂,系统越庞大,接口测试的效果越明显(提高测试效率,提升用户体验,降低研发成本)。
接口测试范围:
a)业务功能(包括正常、异常场景是否实现)
b)业务规则(覆盖度是否全面)
c)参数验证(边界、业务规则是否达到要求)
d)异常场景(重复提交、并发提交、事务中断、多机环境、大数据量测试)
e)性能测试(响应时间、吞吐量、并发数、资源要求)
f)安全测试(权限验证、SQL注入等)
用 Python 为接口测试自动生成用例
基于属性的测试 会产生大量的、随机的参数,特别适合为单元测试和接口测试生成测试用例
尽管早在2006年haskell语言就有了 QuickCheck 来进行”基于属性的测试“,但是目前来看这依然是一个比较小众的领域,参考资料有限,本文如有不足,欢迎指正。
在过去的测试实践中,执行测试时通常需要明确的内容(Value):
这些内容可以通过”判定树“或者”判断表“来表示,然后测试的执行过程变成了这样
可以称为 基于表的测试
在最初,这给了我们测试的方向,但是缺点也非常明显:
你要足够多的"X-Y" 才能可能覆盖到隐蔽的bug。
这里请大家回答几个问题:
如果以上问题的答案不是yes,那么 基于属性的测试 就是你需要掌握的东西!
基于属性的测试和基于表的测试,最大的区别可以这样描述:
vs
于是利用工具生成大量的X类数据,进行测试,并验证结果是否Y类。
值得注意的是:
在不同的语言中有不同的工具来实现,比如:
本文以python为例进行演示:
假设有add函数,接收两个类型整数参数,并返回它们的相加结果
首先写出一个简单的测试用例
正如前面所说,一个这样的用例,根本没信心覆盖全部的场景,例如:
所以接下来怎么办?
改为基于属性的测试
执行结果
由结果可知,工具根据 参数是整数 这一规范,自动生成、执行了大量的测试用例
接口测试和函数的单元测试非常相似:
此外接口文档作为前后端、甚至测试开发的对接窗口,对参数的要求约定的更加细致,
以OpenAPI为例,每个参数可以有以下属性:
于是为接口生成符合要求的参数就变得可行了,举个例子:
这是以unittest为例进行封装的结果,只需要在TestCase中指定openapi的内容(或路径),
启动测试框架时,会自动读取、解析接口文档,并生成测试用例
下面是部分执行日志,可以看到对接口发送了随机参数,并获得返回值
文章来自https://www.cnblogs.com/dongfangtianyu/p/api_test_by_pbt.html
关于接口对接测试用例图和简单的接口测试实例的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。
接口对接测试用例图的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于简单的接口测试实例、接口对接测试用例图的信息别忘了在本站进行查找喔。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
暂时没有评论,来抢沙发吧~