(jmeter版本)
首先开发会给我们一个接口文档,我们根据开发给的接口文档,进行测试点的分析,主要是考虑正常场景与异常场景,正常场景,条件的组合,参数的格式校验等价边界值;异常场景,多一个参数,少个必填参数,参数为空;接着编写测试用例,用的 Jmeter工具去运行,创建线程组,建立http请求,输入测试用例,请求参数,建立察看结果树,运行,看返回的结果,是否跟接口文档里面要求的返回结果一致,其他用例,值需要修改里面的参数,请求地址这些信息。
举例说明:(不要登录跟注册)
比如说原来我们做一个申请借款的接口,对接口进行测试分析,考虑正常场景与异常场景,正常场景,考虑不同参数组合,比如说,不同借款方式,还款期限,还款曰期,借款的利率等参数组合;也要测试每个参数格式校验,异常场景,:多一个参数,少一个必填参数,比如没有借款的利率,参数为空的,比如借款标题为空,编写测试用例
b站最牛Jmeter接口测试和Jmeter接口自动化测试全集_哔哩哔哩_bilibilib站最牛Jmeter接口测试和Jmeter接口自动化测试全集共计100条视频,包括:jmeter【接口测试分类】、jmeter【目前接口架构设计】、jmeter【市面上的接口测试工具】等,UP主更多精彩视频,请关注UP账号。https://www.bilibili.com/video/BV1hq4y1K75i/?spm_id_from=333.999.0.0
在 jmeter中执行,填写参数,更地址就ok,发送请求
(python + request)
原来我们接口主要是用的 python + requests去运行的
首先,开发会给我们一个接口文档,拿到接口文档后,我们就进行测试点的分析,
考虑正确场景,条件的组合,
异常场景,多一个参数,少一个参数,参数为空的情况
比如原来我们做一个生成订单的接口,考虑正常场景,异常场景
正常场景就是不同的订单类型,订单金额,能不能申请订单,每个参数的格式类型的校验,
异常场景,多一个参数,少一个必填参数的时候,还有参数为空的情况
原来我们是用 python + request去做的接口
首先,导入 request包
建立一个 headers,保存请求头的信息,因为订单请求方式是post类型,数据格式是form表单格式,我们把数据保存到data的字典里面
这个时候我们还需求登录的 cookie值跟登录后产生的 token值
我们会去通过动态关联去获取登录的 token跟 cookies,
cookies值的话,我们是直接调用登录返回的 cookies、token值的时候,我能是通过导入re模块,通过正则表达式去提取
当参数, headers、cookies输入完成以后,我们就发送请求,打印返回结果,检返回结果是否跟我们测试用例一致
当运行其他测试用例时,我们去修改data里面的参数就行,在发送请求
有的请求时htps协议的时候,我们发送请求的时候还会very= false去忽略掉证书验
证对应多个接口调用 cookies我们会用到 session去保存接口发现比较多的问题,就是格式校验这块
比如说我们提交订单,订单数据没有显示,订单格式也没有显示,输入字母,汉字都可以
订单类型为空,也会生成订单成功
我觉得接口可以发现接口更多的bug,还可以提早进行测试,提高测试的质量
另外两种问法:上个接口的返回值是下个接口的请求参数,这种如何处理?动态关联有没有了解过?
这个涉及到动态关联,首先要搞清楚后一个接口需要用到上一个接口的什么数据,例外要看数据是在哪里取的,是在head还是在body里,然后如果要取的数据是json格式我会在发请求用json提取器去取这个数据,如果是其他格式的就用边界提取器或正则表达式去取数据
就拿我当时做的那个下单接口来说吧,因为下单接口需要先登录,需要用到登录接口的
cookies来做鉴权,首先就是把登录接口调试通过,然后在登录接口的http请求中添加一
个边界值提取器或者也可以用正则表示式提取器去提取登录接口的响应头中的 cookies值
然后在下单接口中需要添加一个http cookies管理器,在http cookies管理器中引用登录
接口提取出来的 cookies,这样就可以了
如果是不同的线程组的话,那在登录接口中还得添加一个 Beanshell取样器,在
Beanshell取样器中,利用函数助手中的 SetProperty()函数把提取出来的 cookies设置为全局变量,然后在下单接口的http cookies管理器中利用函数助手中的Property()函数引用登录接口中设置的全局变量,这样就可以了。
例外两种问法:接口测试的价值,意义?为什么要做接口测试?
主要就是验证后台服务端的业务逻有没有问题,提高测试的效率
①越底层发现bug,它的修复成本是越低的
②前端页面修改频繁情况下,接口测试不受页面元素改变而影响
③检查系统的安全性,前端传参不可信,比如京东购物,前端价格不可能传入-1元,但是
通过接口可以传入-1元
④如今的系统复杂度不断上升,传统的测试方法成本急剧增加且测试效率大幅下降,接口自动化测试可以提高测试效率
⑤接口测试相对容易实现自动化持续集成,且相对U自动化也比较稳定,可以减少人工,回归测试人力成本与时间,缩短测试周期
1,首先分析开发给到的接口文档
2,接口文档分析完成,编写测试用例
3,然后借助接口测试工具去测试执行测试用例
4,发现bug提交bug,并跟进bug修复
其实这两者测试的侧重点是不同的,接口因为没有界面,更多考虑后台服务器对请求的,处理逻辑问题,业务交互,检测的是后台“容错机制”是否完整;
而ui更多会去关注页面展示,数据转换,界面排序这些功能,当然也会后台数据处理的问题,ui测试其实已经包含了接口测试。系统功能的用例更全面,不仅有界面的,也有业务功能用例,还有其他用户场景的用例功能入口用例,流程用例,而接口测试主要根据各种入参场景来设置用例。
首先要对于每个要测的接口都要先搞清楚这个接口的功能,它的作用是什么,熟悉这个业务功能需要用到什么协议,请求方式是什么,接口有哪些参数。对于每个参数的作用都要搞清楚,像数的类型,是否有约束限制,是否为必填的,长度,其他的限制等等,如果两个参数之间有关联我们还要考虑参数的组合场景,对于参数不理解的,一般都会跟开发沟通下,然后考虑返回数据的类型,返回数据中的返回码和返回信息是什么,通过以上几个点去提炼测试点,设计用例。
参数约束——长度、必选项、格式、数据类型
业务场最——正确的业务场景;错误的业务场景;异常场景:服务器空间不足
组合场景——相互依赖:手机和验证码、用户名和验证码;
相互排斥:二选一当然还有边界值等价类等等
Jmeter测试流程,步骤如下:
创建 jmeter线程组一添加HPPT请求-输入协议-域-端口-路径-编码-请求方式-请求参数-启动
Jmeter测试流程:
先需求,再根据需求写测试点转换成测试用例,根据测试用例编写测试脚本;执行测试脚本;
提交BUG,跟踪BUG
接口文档一般两种形式的,要不就是word版本的要不就是htm的形式,具体内容
1.URL(接口地址)
2.接口功能
3.请求方式:post
4.请求参数,以及接口中每个参数的详细说明,类型,是否为必填,约束条件等等
5.响应数据及格式,返回码,返回码解释等等
一般有需求就会做,后台的接口开发好,就可以开始测。例外,如果增加了新需求,也要做接口测试,还有就是开发对后台的接口做了修改,交互逻辑发生变化,我们也要重新对接口进行测试。
我们主要是根据入参情况,去看接口的返回值,对于返回值,我主要关注的几个点:1.状态码
2.提示信息3.返回数据的具体内容。根据接口文档的说明去检查这个3个点是否满足接口需求文档,4.有些如果要检查数据库的,就连接数据库获取数据与返回的数据做对比。
如果不满足就是有问题,如果满足则通过,如果有Bug我们会先大概分析下,是什么原因,
并进行复测,如果还是有问题,提交Bug给开发,让开发修复,之后再回归测试
接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点测试的重点,
是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等
1、项目处于开发阶段
2、有接口需求文档,开发已完成联调,功能测试展开之前
3、专项测试:参数约束测试,业务场景测试,测试接口请求响应时间(性能)
4、版本上线前,进行整体回归测试,查看接口是否有异常(如404等)
1,需要第三方接口的,接口文档
2,发送请求到第三方接口,检查第三方接口返回的数据是否正确
3,不正确的时候,要跟第三方接口联调,看是请求问题,还是第三方接口返回数据有误,
这个我们公司的第三方接口,我们都是打通的,比如电商,我们通过调用微信接口等等,都是打通的,比如要测试下单第三支付,我们自己开店,收款设置我们自己的账号,然后通过商品设计1分钱,去测试的。
如果不打通的话,基本也只能抓包,主要保证我们发送出去的数据符合需求文档就行,然后真正的上线之前,我们会在预生产环境做一个联调测试,把各自系统连在一起,做一个联调测试没有问题了
我们就可以上线,基本就这么做的
联调测试怎么做的:
其实联调测试就是数据拉通测试,两个子系统,连在一起,形成一个完整的系统,然后从上游下数据,下游接到数据看传过来的数据是否符合下游的系统要求然后下游做了操作,把数据返回给上游,通知上游说数据返回了,上游看返回的数据是否符合要求,如果没有问题,就这个数据就拉通成功这个都是按照用例来执行,上游和下游一起出一份用例,两边都评审通过,然后按照测试用例执行,每条用例测试通过那么联调测就完成了。
(1)通过用户和密码,auth鉴权
(2)通过 cookie和 session
(3)通过 token
(4)通过sign签名
现在app一般是通过 token鉴权,有些是通过把 token放在请求头里面,有些是通过 singn签名这个字段放在body里面去鉴权的,一般的web是通过 session去鉴权的
常见的媒体格式类型如下:
text/html:HTML格式
text/plain:纯文本格式
text/xm:XML格式
Image/gif:gif图片格式
mage/jpeg:jpg图片格式
Image/ng:png图片格式
以 application开头的媒体格式类型
application/xhtm + xml: XHTML格式
application/ml:XML数据格式
application/atom + xml: Atom XML聚合格式
application/json:JsoN数据格式
application/pdf:pdf格式
application/msword:Word文档格式
application/octet-stream:二进制流数据(如常见的文件下载)
application/x-www-form-urlencoded:encoded: