API 是 (Application Programming Interface) 首字母缩略词,即应用程序编程接口。 API 是一组用于构建软件应用程序的规程,协议和工具。API 充当软件应用程序之间的接口,并允许两个软件应用程序相互通信。 API 是一组软件功能,可以由其他软件执行。
接口一般来讲分为两种:
(1) 程序内部的接口:方法与方法、模块与模块之间的交互,程序内部抛出的接口,如登录发帖,发帖就必须要登录,如果不登录不能发帖,发帖和登录这两个模块之间就要有交互,就会抛出一个接口,进行内部系统调用。
(2) 系统对外的接口:从别人的网站或服务器上获取资源或信息,对方不会提供数据库共享,只能提供一个写好的方法来获取数据,如购物网站和第三方支付之间,购物网站支付时可选择第三方支付方法,但第三方不会提供自己的数据库给购物网站,只会提供一个接口,供购物网站进行调用
接口分类一般分为两种:
(1) webService 接口:走 soap 协议通过 http 传输,请求报文和返回报文都是 xml 格式的。测试时需要通过工具才能进行调用、测试。少数公司还在使用这种接口,如医院等行业。
(2) http api 接口:走 http 协议,通过路径来区分调用的方法,请求和报文都是 key-value 形式的,返回报文一般都是 json 串,有 get 和 post 等方法。目前来讲,是最常用的。
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。
API 测试是一种软件测试,涉及直接测试 API,也是集成测试的一部分,用于检查 API 是否满足应用程序的功能,可靠性,性能和安全性方面的期望。在 API 测试中,我们主要关注软件架构的业务逻辑层。可以在包含多个 API 的任何软件系统上执行 API 测试。
简略版:
第一步:根据API文档提取接口清单;
第二步:根据接口清单,确定适用于单接口测试的接口。根据需求评审及业务逻辑,确定适用于关联接口测试的接口类。
第三步:根据确定的单接口测试和关联接口测试,搭建测试框架,设计测试用例。这里的重点是用postman或jmeter等工具搭建测试框架(重点是数据驱动和参数传递),并根据等价类法、正交表法等方法设计合理有效的测试用例。
第四步:执行测试用例,并验证结果是否符合预期。如果是bug,提交bug等。
详细版:
1.拿到接口规范。
2.设计接口测试功能用例(主要从用户角度出发看接口能否实现业务需求,用例设计就是黑盒用例那一套)。
3.各种入参验证(正常情况,异常情况包括输入参数个数不对,类型不对,可选/必选, 还有考虑参数有互斥或关联的情况)。
4.接口返回值各种验证(符合接口文档需求)
5.了解接口实现逻辑,实现逻辑覆盖(语句/条件/分支/判定/。。。。。)
6.接口能并发执行吗?
7.采用工具或者自写代码来验证,HTTP接口一般SoapUI, Jmeter, Fiddler,Postman,java+httpclient,Python+ Request,robotframework+httplibrary等。
也可以用接口自动化来实现,就是用代码实现,框架和UI自动化差不多,发送请求用断言来判断。
8.bug跟踪
1、业务功能覆盖是否完整;
2、业务规则覆盖是否完整;
3、参数验证是否达到要求(边界、业务规则);
4、接口异常场景覆盖是否完整;
5、接口的所有参数是否覆盖;
6、接口覆盖率是否达到要求;
7、代码覆盖率是否达到要求;
8、性能指标是否满足要求;
9、安全指标是否满足要求。
1.越底层发现bug,它的修复成本是越低的。
2.前端随便变,接口测好了,后端不用变,前后端是两拨人开发的。
3.检查系统的安全性、稳定性,前端传参不可信,比如京东购物,前端价格不可能传入-1元,但是通过接口可以传入-1元。
4.如今的系统复杂度不断上升,传统的测试方法成本急剧增加且测试效率大幅下降,接口测试可以提供这种情况下的解决方案。
5. 接口测试相对容易实现自动化持续集成,且相对UI自动化也比较稳定,可以减少人工回归测试人力成本与时间,缩短测试周期,支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。
6. 现在很多系统前后端架构是分离的,从安全层面来说:
(1)、只依赖前端进行限制已经完全不能满足系统的安全要求(绕过前面实在太容易), 需要后端同样进行控制,在这种情况下就需要从接口层面进行验证。
(2)、前后端传输、日志打印等信息是否加密传输也是需要验证的,特别是涉及到用户的隐私信息,如身份证,银行卡等。
1.拿到接口规范。
2.设计接口测试功能用例(主要从用户角度出发看接口能否实现业务需求,用例设计就是黑盒用例那一套)。
3.各种入参验证(正常情况,异常情况包括输入参数个数不对,类型不对,可选/必选, 还有考虑参数有互斥或关联的情况)。
4.接口返回值各种验证(符合接口文档需求)
5.了解接口实现逻辑,实现逻辑覆盖(语句/条件/分支/判定/。。。。。)
6.接口能并发执行吗?
7.采用工具或者自写代码来验证,HTTP接口一般SoapUI, Jmeter, Fiddler,Postman,java+httpclient,Python+ Request,robotframework+httplibrary等。也可以用接口自动化来实现,就是用代码实现,框架和UI自动化差不多,发送请求用断言来判断。
8.bug跟踪
通常,设计接口测试用例需要考虑以下几个方面:
①是否满足前提条件
有些接口需要满足前提,才可成功获取数据。常见的,需要登录Token
逆向用例:针对是否满足前置条件(假设为n个条件),设计0~n条用例
②是否携带默认值参数
正向用例:带默认值的参数都不填写、不传参,必填参数都填写正确且存在的“常规”值,其他不填写,设计1条用例
③业务规则、功能需求
这里根据时间情况,结合接口参数说明,可能需要设计N条正向用例和逆向用例
④参数是否必填
逆向用例:针对每个必填参数,都设计1条参数值为空的逆向用例
⑤参数之间是否存在关联
有些参数彼此之间存在相互制约的关系
⑥参数数据类型限制
逆向用例:针对每个参数都设计1条参数值类型不符的逆向用例
⑦参数数据类型自身的数据范围值限制
正向用例:针对所有参数,设计1条每个参数的参数值在数据范围内为最大值的正向用例
对比接口测试和 app 测试点: