多平台统一管理软件接口,如何实现多平台统一管理软件接口
269
2023-03-05
本文目录一览:
接口测试:
接口:主要是子模块或者子系统间交互并相互作用的部分。
这里说的接口是广义的,客户端与后台服务间的协议;插件间通信的接口;模块间的接口;再小到一个类提供的方法;都可以理解为接口。因此,可以分析,系统间的接口包含三部分:输入、处理逻辑、输出。
接口测试:是指针对模块或系统间接口进行的测试。
分析一个接口:
获取接口文档:和黑盒测试一样,我们是从需求文档中去挖掘测试点,设计测试用例。对于接口测试,同样是有对应的接口文档的。
分析接口文档,提取测试点:
1)输入:接受哪些参数、参数的类型、可选参数和必选参数等;根据输入参数采用等价类、边界值分析法等进行设计。
2)业务逻辑:对于一个接口,不同的输入参数或组合,流程或状态的转移是不同,可以根据业务逻辑画出流程图或状态转移图,确保每种状态至少被访问了一次。
3)输出:根据文档规定的输出,反向设计测试数据,使所有的输出状态都被包含了;
测试用例:同时对输入、业务逻辑、输出进行考虑时,肯定会存在用例的冗余,在最大限度覆盖业务功能和规则下,选取最优用例集合。同时,需要考虑异常数据和场景。
1、可以使用postman软件进行接口测试,这里以较复杂的上传图片的接口为例进行测试,首先打开postman软件选择Post方式,输入后台接口调用地址。
2、然后填写Headers,注意这里的Headers部分不要写任何东西,如果之前是有Content-Type头信息, 那么就会上传失败。
3、接着填写Body,选择form-data,填写Key后台规定的接收文件的名称参数,格式选择为File,此时value会自动变成选择文件。
4、最后点击Send,可以发现下方返回了接口的响应,说明上传图片是成功的,这样简单的图片上传的接口测试就完成了。
基于属性的测试 会产生大量的、随机的参数,特别适合为单元测试和接口测试生成测试用例
尽管早在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小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~