一、什么接口测试
客户端与后台服务间的协议;插件间通信的接口;模块间的接口;再小到一个类提供的方法;都可以理解为接口。接口测试是验证测试系统组件间接口的一种测试。
二、接口采用方式
1、webService接口:是走soap协议通过http传输,请求报文和返回报文都是xml格式的,我们在测试的时候都用通过工具才能进行调用,测试。可以使用的工具有SoapUI、jmeter;webService:返回的格式xml还需要解析麻烦,而且速度可能有降低
2、http -api接口:是走http协议,通过路径来区分调用的方法,请求报文都是key-value形式的,返回报文一般都是json串,有get和post等方法,这也是最常用的两种请求方式。可以使用的工具有postman、jmeter;目前开发平台等都使用的http(get/post实现的) 。
3、http协议时超文本传输协议(不安全);https是安全的超文本传输协议,是安全版的http协议,使用安全套接字层(SSL)进行信息交换 HTTPS就等于HTTP加上TLS(SSL)。
https协议对比http协议:
(1)数据保密---通信使用明文(不加密),内容可能会被窃听
(2)身份验证和授权---不验证通信方身份,应此可能遭遇伪装
(3)数据完整性---无法证明报文的完整性(即准确性),所以可能已遭篡改
https协议的缺点:速度和性能
(1) HTTPS对访问速度的影响非常明显。每个HTTPS连接一般会增加1-3个RTT,加上加解密对性能的消耗,延时还有可能再增加几十毫秒。
(2)HTTPS对CPU计算能力的消耗很严重,完全握手时,web server的处理能力会降低至HTTP的10%甚至以下。
前端和后端:
(1)前端:app,网页统称前端(展示-负责貌美如花)
(2)后端: 后台提供数据,校验,下订单等等处理(负责挣钱养家)
三、接口的组成
a、接口说明,大体说明该接口的用途作用
b、调用url,一般的url地址+路径+参数,https://172.18.19.23/v2/getVIP?usermane=123
c、请求方法(get\post),如果是RESTful协议框架的还有,delete,put等方法
d、请求参数、参数类型、请求参数说明
e、返回参数说明
四、为什么要做接口测试,接口测试的目标
主要是后端的数据的校验,前端校验了不代表后端也校验了
例如一个登陆接口,例如产品上规定用户名6-10个字符数字下划线,但后端没做判断。但我们业务人员测试肯定验证,但只是前端做了校验,后端压根就忘了这个小需求.那么后果来了如果一个懂的直接抓包去篡改你的接口,然后绕过校验,通过sql注入直接随意登录。如果你这是一个下单业务,是不是给公司造成了很大损失
目标:
1.可能发现客户端没有发现的bug(那么也叫隐藏bug)
2.及早爆出风险(保证质量正常上线)
3.接口稳定了,前端随便改
4.最重要检查系统安全性,稳定性,前后端传输、日志打印等信息是否加密传输也是需要验证的,特别是涉及到用户的隐私信息,如身份证,银行卡等
5.接口测试相对容易实现自动化持续集成
接口测试持续集成:
对接口测试而言,持续集成自动化是核心内容,通过持自动化的手段我们才能做到低成本高收益。目前我们已经实现了接口自动化,主要应用于回归阶段,后续还需要加强自动化的程度,包括但不限于下面的内容:
a) 流程方面:在回归阶段加强接口异常场景的覆盖度,并逐步向系统测试,冒烟测试阶段延伸,最终达到全流程自动化。
b) 结果展示:更加丰富的结果展示、趋势分析,质量统计和分析等
c) 问题定位:报错信息、日志更精准,方便问题复现与定位。
d) 结果校验:加强自动化校验能力,如数据库信息校验。
e) 代码覆盖率:不断尝试由目前的黑盒向白盒下探,提高代码覆盖率。
f) 性能需求:完善性能测试体系,通过自动化的手段监控接口性能指标是否正常。
五、
A. 用例设计(根据业务逻辑来设计用例,登录5次,需要2分钟后再登录 删除关注的车,列表少一条数据)
B. 参数组合(传入不同值)参数化
C. 接口安全(绕过验证/绕过身份验证/参数是否加密等)
D. 异常验证(输入异常参数边界值)
接口测试的重点
1、重点是检查数据的交换,传递的正确性,以及接口间逻辑依赖关系,参数化
4、接口测试质量评估标准:
a) 业务功能覆盖是否完整
b) 业务规则覆盖是否完整
c) 参数验证是否达到要求(边界、业务规则)
d) 接口异常场景覆盖是否完整
e) 接口覆盖率是否达到要求
f) 代码覆盖率是否达到要求
g) 性能指标是否满足要求
h) 安全指标是否满足要求