接口测试常用工具:postman,jmeter (现在主流的两个测试接口工具)
把接口分为两类:程序接口和协议接口。
程序接口,也可以看作是程序模块接口,具体到程序中一般就是提供了输入输出的类、方法或函数。 对于程序接口的测试,一般需要使用与开发程序接口相同的编程语言,通过不同的传入不同的参数,来验证 程序接口的功能。
协议接口,一般指系统通过不同的协议来提供的接口,例如 HTTP/SOAP 协议等。这种类型接口对 底层代码做了封装,通过协议的方式对外提供调用。因为不涉及到程序层面,所以,不受编程语言的限制; 我们可以通过其它编程语言或工具对其进行测试。
接口大体可以分成三类:
系统与系统之间的:系统与系统之间的接口,这里可以是公司内部不同系统之间的接口调用,也可以是不同公司之间系统接口的调用。而对于公司的其它系统,如社区网站和微信活动可以调用这些接口快速的实现相应的功能。而对于后者来说,如微信,微博所提供的第三方登录接口,如果你开发的系统不想自建用户体系,完全可以调用这些接口来实现用户的登录。
下层服务对上层服务的接口应用层,从认知上你可以看成是系统所提供的 UI 层功能。对于 Web系统来说,你可以认为是浏览器页面上所提供的功能,登录、注册、查询、删除等。Service 层,可以理解为服务器所提供数据和逻辑的处理。DB 层,(Data Base) 数据库主要用来存放数据,例如用户的个人信息,商品的信息等。
系统内,服务与服务之间的调用 假设系统开发一个用户查询接口,输入用户名,返回用户信息(性别、年龄、手机号、邮箱地址等),如果用户不存在则返回NULL;现在需要新开发一个用户抽奖的接口,该接口需要用户名和抽奖id,抽奖接口得到用户名后可以调用用户查询接口,如果用户查询接口返回NULL,那么投资接口就可以直接返回用户不存在了。在这个例子中,用户抽奖接口就调用的用户查询接口。
接口测试的意义:
更早地发现问题: 测试应该更早地介入到项目开发中,因为越早地发现bug,修复的成本越低。然而功能测试必须等到系统提供可测试的界面才能对系统进行测试。而接口测试可以在功能界面开发出来之前对系统进行测试。系统接口是上层功能的基础,接口测试可以更早更低成本地发现和解决问题。
缩短产品研发周期: 对于产品研发周期来说,如果将所有测试工作都集中在功能测试阶段,那么测试的问题和修复周期就会变长。因为测试可以更早地介入产品开发中,所以,可以有效地控制功能阶段bug的数量;从而有效地缩短产品开发周期。
发现更底层的问题: 系统的有些底层逻辑是在UI功能测试中不太容易触发的,那么这些逻辑可能会存在问题。接口测试可以更容易更全面的测试到这些底层的逻辑。
检查服务器的异常处理能力: 我们通常把前端的验证称为弱验证,因为它很容易被绕过,这个时候如果只站在功能的层面进行测试,就很难发现一些安全的问题。
接口测试的原理:
通过测试程序或工具模拟客户端向服务器发送请求报文,服务器接收请求报文后对相应的报文做出处理然后再把应答报文发送给客户端,客户端接收应答报文这一过程(request→response)
接口测试的流程接口测试的流程:
类似于功能测试,需求讨论→评审需求→确定需求→产出接口定义→根据需求文档及接口定义设计测试用例(测试用例主要从业务场景,功能以及异常测试几个方面考虑)→评审用例→执行测试
接口测试的流程其实和功能测试的流程类似,因为接口测试依赖的主要对象也是需求说明书,所以,最初的流程就是参与需求讨论,评审需求。
需求确定以后,开发会根据需求进行接口设计,会产出接口定义,在开发设计过程中,有能力的话,可以给出一些针对设计的建议,提高可测性,针对需求及设计,进行测试计划,测试设计,然后还需要和配管确定测试环境相关的事情。
在开发完成接口定义之后,就根据需求文档及接口定义进行测试用例设计,测试用例设计主要从业务场景,功能,以及异常测试几个方面考虑。
测试用例设计完成后,针对测试用例进行评审,然后,如果开发代码部分可测时,即可进入测试了,因为是部分可测,可能会使用到mock方法。
已有测试代码时,就要进行测试代码的持续集成了,我们是使用hudson来进行持续集成的在项目结束后,会对每个项目进行总结。
接口测试数据准备:
接口测试的数据准备,可以从下面几个方面去考虑:
如果是只测试一次的接口,可以使用硬编码的方式准备测试数据,在写测试代码的时候,使用到什么数据就写什么数据,为了避免数据重复,可能比较多的会用到随机字符或随机数
可以直接通过调用其他API的方式准备测试数据,这种情况在测试最上层服务的时候比较有用,比如测试团购购买服务,就需要准备要购买的团购数据,购买团购的用户数据,这个时候,可以直接调用生产团购的api和生成用户的api直接生成测试数据
使用excel或xml准备测试数据,这种准备测试数据的方式,主要针对对象数据的准备,比如可以将一条团购数据对应excel中的一条数据,因为一般开发都会使用pojo映射,而在准备测试数据的时候,这些pojo对象属性的设置往往是重复和大工作量的,用excel或XML方式准备,则可以减少在代码当中重复去准备这些数据。
也可以使用工具方法的形式去准备测试数据,通过在代码中写工具方法去实现数据生成,而在测试代码中调用工具方法去得到所需数据。
接口测试的着眼点:
检查接口返回的数据是否与预期的结果一致。
检查接口的容错性,假如传递数据的类型错误时是否可以处理。例如上面的例子是支持整数,传递的是小数或字符串呢?
接口参数的边界值。例如,传递的参数足够大或为负数时,接口是否可以正常处理。
接口的性能,接口处理数据的时间也是测试的一个方面。牵扯到内部就是算法与代码的优化。
接口的安全性,如果是外部接口的话,这点尤为重要。
接口测试用例设计:
接口测试用例的设计方法其实和功能测试用例的设计方法是类似的,因为接口是需要满足需求的,而接口测试所依赖的也是需求说明书,但是,因为接口测试毕竟是通过代码去测试代码,所以,为了保证覆盖率,可能会使用到单元测试的方法,具体的测试用例设计如下:输入参数测试:
针对输入的参数进行测试,也可以说是假定接口参数的不正确性进行的测试,确保接口对任意类型的输入都做了相应的处理:输入参数合法,输入参数不合法,输入参数为空,输入参数为null,输入参数超长;
功能测试:接口是否满足了所提供的功能,相当于是正常情况测试,如果一个接口功能复杂时推荐对接口用例进行结构划分,这样子用例具有更好的可读性和维护性;
逻辑测试:逻辑测试严格讲应为单元测试,单元测试应保持内部逻辑的正确性,可单元测试和接口测试界限并不是那么清楚,所以我们也可以从给出的设计文档中考虑内部逻辑错误的分支情况和异常;
异常情况测试:接口实现是否对异常情况都进行了处理,接口输入参数虽然合法,但是在接口实现中,也会出现异常,因为内部的异常不一定是输入的数据造成的,而有可能是其他逻辑造成的,程序需要对任何的异常都进行处理。
作者:天空之城下的乌托邦
原文链接:https://blog.csdn.net/weixin_42622771/article/details/81002620