接口测试原理
什么是接口:
接口泛指实体把自己提供给外界的一种抽象化物(可以为另一实体),用以由内部操作分离出外部沟通方法,使其能被内部修改而不影响外界其他实体与其交互的方式。
简单一点理解他就是URL,工作原理也就是URL通过get或者post请求像服务器发送一些东西,然后得到一些相应的返回值,本质就是数据的传输与接收。
如果还是感觉抽象,举个例子:
1.我们通过上下和楼层按钮来乘坐电梯,这些按钮就是电梯的接口,不管电梯内的具体的算法怎么变,我们都是这么坐电梯的。
2.现在洗衣机都是自动化的,先泡再洗再漂再甩,那么甩干是怎么知道自己要工作了呢,必须要由漂洗给它发送消息,我干完了到你了,也就是说两者存在交互,就是说两者之间存在接口。我在修改漂洗的程序,让他从3次变成4次,也不会对甩干的过程有任何影响。
从这可以看出,接口一般分两种,一种是程序对外的接口,还有一种就是系统内部的接口
那么接口都帮我们做了哪些事呢?
电梯的接口帮我们传递了下到一楼的信息,洗衣机内部接口,将信息传递到下一流程。
注:
对于程序员来说:前端开发,后端开发,移动端开发,这些是怎么连接起来的呢?本文讲的是什么呢,Yes,答案就是接口
所以综合来说,接口就是不同系统或模块之间信息交流的大门
API的五大要素:
用户提供API时必须要提供的五个要素,如此才能够顺利地完成接口的对接。
1.接口地址——请求的网址
2.请求方法——一般采用的是HTTP协议的POST、GET请求
3.请求参数——你传过去是什么内容
4.返回参数——就是你传参数过去之后得到返回的内容,返回内容的数据交互格式一般为json或xml格式
5.错误代码——也是返回内容的一部分,当接口发生一些意外情况时,错误代码会告诉你原因
什么是接口测试:
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。
再简答的说就是通过URL像服务器或者其他模块等,传输我们想传输的数据,然后看看他们返回的是不是我们预期想要的。
为什么要做接口测试:
1.成本--尽早进行系统集成测试,暴露BUG越早发现解决问题的成本越低
2.减少bug的产生--接口经过测试稳定了,前端页面换肤或者随便改,从一定层面会减少BUG的产生。
3.效率–如今的系统复杂度不断上升,传统的测试方法成本急剧增加且测试效率大幅下降,接口测试可以提供这种情况下的解决方案
4. 稳定--接口测试相对容易实现自动化持续集成,且相对UI自动化也比较稳定,可以减少人工回归测试人力成本与时间,缩短测试周期,支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。
5.安全--现在很多系统前后端架构是分离的,从安全层面来说:
(1)、只依赖前端进行限制已经完全不能满足系统的安全要求(绕过前面实在太容易),检查系统的安全性、稳定性,前端传参不可信;比如京东购物,前端价格不可能传入-1元,但是通过接口可以传入-1元,在这种情况下就需要从接口层面进行验证。
(2)、前后端传输、日志打印等信息是否加密传输也是需要验证的,特别是涉及到用户的隐私信息,如身份证,银行卡等。
综上:所以很多时候,接口测试,可以认为是功能测试的一种补充。它可以让我们的测试做得更深入,更全面。
做接口测试之前需要了解
1. 接口常见请求类型:
如下是对应http协议的常见类型:
2. HTTP协议
HTTP协议非常重要。清楚了HTTP协议,再去使用工具其实就很容易上手
为什么是HTTP协议而不是其他协议?因为90%的系统都是HTTP协议的。
HTTP协议包含请求和响应
请求就是用户的输入,响应就是结果。我们通过请求去找参数,然后输入不同的参数值,然后组合成请求,只要这个请求是合法的,那么就可以发出去,并且能够被服务器接收。所以,首先要能够判断出来什么叫做合法请求。
那么就需要去了解HTTP协议的请求的组成,请求的规范,知道哪些请求项是我们所关心的,哪些请求项是我们一定要遵循的,哪些项是我们可以删除的。
同理,要想检查结果是否正确,就需要去了解响应。
HTTP请求包含两个部分
请求头和请求体,请求头的第一行非常的重要,包含请求方法和URL。这两个东西是非常核心的东西。请求方法有GET方法,POST方法,需要知道他们之间的区别,当然区别最明显的就是GET请求没有请求体,而POST请求有请求体。因为get方式请求的数据是跟在url后面的。URL,相当于接口的入口。请求头里有很多项,每一项最好能知道是什么意思,并且要知道哪些项是比较核心的,其实核心的东西不多。一个是content-type,一个是cookies。
备注:网上很多资料会把请求分为三部分,请求行、请求头和请求体。这里的请求头的第一行其实就是请求行了,下面的响应也是一样
请求体包括参数,一般我们在测试的时候会修改请求体里的东西。
懂了上面这些,就知道该如何组装HTTP请求了。
响应包含两个部分
一个是响应头,一个是响应体。响应头里的第一行有响应的状态码和状态信息,这个非常重要。面试时候一般会被问到:状态码有几类?一般是有五类,1开头(请求正在处理),2开头(请求处理成功),3开头(重定向),4开头(客户端错误),5开头(服务器错误),这五类分别代表什么需要记住。一般5开头的都是系统bug。
如何做接口测试:
接口测试流程
需求以及技术方案包括接口文档的评审
书写接口测试用例
进行用例评审以及review
根据接口文档拿到需要的接口信息(url,接口类型/请求头/请求体)
配置代码覆盖率
执行;发送查看返回结果,校验返回结果是否正确
根据代码覆盖率补全接口用例并执行
编写以及发送测试报告
1. 了解业务需求/接口文档掌握接口测试覆盖范围
1.分析测试需求,技术方案与接口文档结合看
接口测试是黑盒测试。作为黑盒测试,基本的测试思路是通过输入和输出判断被测系统或者对象的逻辑。如下是常见的接口测试需要覆盖的范围
总结:
1、通过性验证,说白了就是传递正确的参数,是否返回正常的结果
2、参数组合,因为参数有必传和非必传,参数的类型和长度,以及传递时可能业务上的一些限制,所以在设计用例时,就要排列组合这些情况,保证所有情况都能覆盖到
3、接口的安全性,这个又分为几种情况:
1)绕过验证,比如提交分数时,在传递分数参数时,修改分数,就要看后端有没有验证了。或者我提交时,抓个包将分数一改,如果能以我改后的分数提交成功,那这个接口就有问题了。
2)绕过身份验证,就是某个功能只有有特殊权限的用户才能操作,那我传递一个普通的用户,是不是也能操作呢
3)参数是否加密,这个关系到风控,比如我们在登录一些网站时,它要将我们的登录信息进行加密,如果不加密我们的信息就会暴露,危害性极大。
4兑吧签名验证方式:请参考如下文档
http://docs.duiba.com.cn/tech_doc_book/appendix/sign_rule.html
工具:https://www.sojson.com/encrypt_md5.html
2. 书写规范的接口测试用例
书写接口用例的要素:
用例名称,用例级别,步骤以及参数输入,预期结果
模版1:适用于数据驱动的接口自动化框架
用例设计重点:通常情况下主要测试最外层的两类接口:数据进入系统接口(调用外部系统的参数为本系统使用)和数据流出系统接口(验证系统处理后的数据是否正常);
一个模块对应一个Excel表
一个接口对应一张sheet表
表中一行对应一条测试用例
在开始要注明测试时需要的sql,如下图开始会创建用户,用完了会删除
这样写一个是用例清晰明了,另外一个是方便兼容后续接口自动化
模版2:关键点输出使用xmind更适用于我们现在的活动
3. 接口测试质量评估标准也就是review用例:
a) 业务功能覆盖是否完整
b) 业务规则覆盖是否完整
c) 参数验证是否达到要求(边界、业务规则)
d) 接口异常场景覆盖是否完整(根据接口文错误码反向补充用例)
e) 代码覆盖率是否达到要求(根据代码覆盖率补充用例)
f) 性能指标是否满足要求
g) 安全指标是否满足要求
接口测试执行以及工具的使用:
八卦台使用如下:
推荐场景:什么时候使用八卦台接口测试工具:测试环境不用想选他
使用指南:http://cf.dui88.com/pages/viewpage.action?pageId=60819229
Postman:
推荐场景:支持接口导入导出很适合大家相互分享,使用简单很容易上手,有软件有插件不占内存,很nice选他
使用postman进行接口测试流程:
新建请求集
添加请求(包含选择接口类型,填写请求url,填写参数,设置cookie)
执行点击send
设置断言也就是tests---可直接看response
举个栗子实操:兑吧活动查询接口
说了这么多,postman工具的其他介绍看如下链接:
https://www.cnblogs.com/yinjia/p/10122178.html
Jmeter:
推荐场景:什么时候使用jmeter,接口并发以及性能测试选他
使用Jmeter进行接口测试的基本步骤如下:
1.测试计划新建
2.线程组新建
3.添加HTTP Cookie管理器
4.添加Http请求默认值
5.添加Sampler(HTTP请求)
6.设置断言---可不设置
7.设置监听器(查看结果树、图形结果、聚合报告等)-可不设置
使用指南:https://www.cnblogs.com/csmashang/p/12762177.html
更多的知识参考这本书
Sopui
如果要测试webservice协议的接口选他
使用指南:https://blog.csdn.net/sinat_20904881/article/details/88196593
FAQ:
线上测试如何测试并发:
一.线上测试和开发者做了对接,这个时候没法使用八卦台进行单用户以及多用户并发测试,怎么整?
方法1:使用charles进行单用户并发测试
配置charles抓包,触发业务
抓到对应接口后右击,然后选择 「Repeat Advanced」菜单项,如下所示:
方法2:使用jmeter进行单用户并发以及多用户并发测试
步骤如下:
单用户并发的话不用进行参数化的操作cookie就用你抓包抓到的数据就好;多用户并发的话,注意设置的用户数量和你实际上文本中配置的cookie数量保持一致;
配置charles抓包,触发业务
打开jmeter,新增线程,配置用户数
新增http信息管理头,将jmeter抓包抓到的数据,复制到jmeter的信息管理头中
新增.txt文件通过抓包的方式获取到多个用户的cookie并放入该文件中保存,参数化cookie,新增csv数据设置文件如截图
新增http请求并配置如下
添加查看结果树
点击执行,并校验结果
接口测试常见问题
服务不通,可能是部署或者环境问题,也可能是代码问题
http状态码:
1)200 2开头的都表示这个请求发送成功,最常见的就是200,就代表这个请求是ok的,服务器也返回了。
2)300 3开头的代表重定向,最常见的是302,把这个请求重定向到别的地方了。
3)400 400代表客户端发送的请求有语法错误,401代表访问的页面没有授权,403表示没有权限访问这个页面,404代表没有这个页面。
4)500 5开头的代表服务器有异常,500代表服务器内部异常,504代表服务器端超时,没返回结果。
具体可参考如下链接:
不合法的传参,导致接口响应出错或 crash
返回的数据不正确或符合业务逻辑
对象权限未校验,存在敏感信息未脱敏
前端存在无意义的重复调用
接口测试小tips
1.计划:在拿到接口文档时,不要急于开始写 case,先将需求文档以及接口文档看几遍,有一个大致的熟悉和了解再去写,接口和业务结合覆盖面会更全
2.沟通,当接口文档或实际结果与预期不符时,有时是开发根据实际开发情况做的处理与我们的预期有一些出入,需要与开发沟通,灵活解决,不必一成不变。
3.不必要将每项的各种异常全都验证一遍,尤其是走同一套逻辑的操作,例如新建和编辑修改,可以挑一些在新建时验证,挑一些在编辑时验证;这样既可以覆盖全面,又可以节约时间和成本;
接口自动化拓展:
接口自动化框架:
rap+postman+jenkins:rap+postman接口自动化搭建指南.doc
Jmeter+ant+jenkins:接口自动化测试指南jmeter+ant+jenkins.docx
Robotframework+HttpLibrary.HTTP+jenkins:RF自动化框架搭建及使用指南.docx
Python+requests+unittest+excel:unittest+excel+jenkins
脚本附件:
2312

被折叠的 条评论
为什么被折叠?



