如何进行接口测试
一、
对于接口测试来说,项目测试用例的重复运行首先是表现在单个测试用例的独立性方面的,也就是说,每一个测试用例的运行除了依赖被测对象和对应的数据库环境外,是不依赖于其他任何测试用例的,并且这个测试用例执行完毕后,对系统来说,也是没有任何痕迹的,这样就保证了每个测试用例运行时,都在一个干净的环境中运行。要实现测试用例的独立性,就必须对被测系统的设计有详细的了解,这样,不会出现测试用例执行后遗漏数据,环境未改变,另外,还需要对测试用例进行详细的设计。另外,要保证测试用例的重复使用,还需要做到测试用例的及时更新,在这个方面,我们是做接口测试的人会维护对应的系统的接口测试用例,要保证,代码每次更新,测试用例都必须全部执行通过。
接口测试用例的设计方法其实和功能测试用例的设计方法是类似的,因为接口是需要满足需求的,而接口测试所依赖的也是需求说明书,但是,因为接口测试毕竟是通过代码去测试代码,所以,为了保证覆盖率,可能会使用到单元测试的方法,具体的测试用例设计,我考虑的如下,请参考,如果有错误,一起讨论。
输入参数测试:针对输入的参数进行测试,也可以说是假定接口参数的不正确性进行的测试,确保接口对任意类型的输入都做了相应的处理:输入参数合法,输入参数不合法,输入参数为空,输入参数为null,输入参数超长。
功能测试:接口是否满足了所提供的功能,相当于是正常情况测试,如果一个接口功能复杂时推荐对接口用例进行结构划分,这样子用例具有更好的可读性和维护性。
逻辑测试:逻辑测试严格讲应为单元测试,单元测试应保持内部逻辑的正确性,可单元测试和接口测试界限并不是那么清楚,所以我们也可以从给出的设计文档中考虑内部逻辑错误的分支情况和异常; 异常情况测试:接口实现是否对异常情况都进行了处理,接口输入参数虽然合法,但是在接口实现中,也会出现异常,因为内部的异常不一定是输入的数据造成的,而有可能是其他逻辑造成的,程序需要对任何的异常都进行处理。
二、
三、
1、什么是接口测试?
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等
2、为什么要做接口测试
a)互联网的快速发展,公司内部系统或与外部系统的关联越来越多,一个业务流程关联多个后端系统,它们的关联都是基于接口来实现,接口测试可以将复杂的系统关联进行简化,只要做好每个接口的测试就能够较好的保证系统质量。
b)单个系统的变更,是否会影响到关联业务系统,比较难用常规的测试方面来覆盖相关的应用系统(例如使用此接口的外部 系统有N个,不可能每个做功能兼容性测试),但可以通过对接口功能的覆盖来验证是否影响它人对接口的调用。
c)接口功能比较单一,能够比较好的进行测试覆盖,也相对容易实现自动化持续集成,,可以减少人工回归成本与时间,缩短测试周期。
d)接口相对于界面功能,会更底层一些,测试覆盖会更容易(如业务在调用接口时做了判断,当不满足条件时链接就不显示,此时从界面无法测试相关功能是否做好判断,通过接口就比较容易)
3、接口测试范围
a)业务功能(包括正常、异常场景是否实现)
b)业务规则(覆盖度是否全面)
c)参数验证(边界、业务规则是否达到要求)
d)异常场景(重复提交、并发提交、事务中断、多机环境、大数据量测试)
e)性能测试(响应时间、吞吐量、并发数、资源要求)
f)安全测试(权限验证、SQL注入等)
4、接口测试的重点
1、检查接口返回的数据是否与预期结果一致。
2、检查接口的容错性,假如传递数据的类型错误时是否可以处理。
3、接口参数的边界值。例如,传递的参数足够大或为负数时,接口是否可以正常处理。
4、接口的性能,http请求接口大多与后端执行的SQL语句性能、算法等比较相关。
5、接口的安全性,外部调用的接口尤为重要。
做好接口测试的前提
1、系统化的接口文档
传统的接口文档,一般采用word或wiki等系统来记录,从单次使用上似乎比较简单,因为大家会更习惯这样的操作,但这种形式存在比较大的问题:
a、接口文档非标准化,无法直接与接口测试工具接口使用
b、接口维护困难,接口有变化时比较难标识清楚,沟通成本很高
系统化接口文档,例如rap(淘宝分源的一个系统),具备接口维护标准化、版本化管理、MOCK测试等功能;对标准化的接口内容做二次开发,可以直接导出Soapui等工具使用的格式,直接导入工具中使用,有以下好处:
A、接口测试时不再需要手工输入相关字段,节省时间成本
B、版本化管理,能够清晰的知道哪些接口有变化
Rap参考 http://rapapi.org/org/index.do
2、标准化的接口规范
接口管理是做好接口测试很重要的前提,如果一个系统有哪些接口都不太清楚,测试就很难覆盖到,接口管理建议采用以下方式:
A、按接口提供方为单位进行首次划分,按接口使用方进行二次划分,再按业务模块进行细分,分类原则根据内容多少进行优化,不需要固定,如本身接口较少就没有必要分得过细,较多时就需要多划分模块
如:系统A,提供有 1、2、3、4、5、6、7、8、9 这9个接口,接口分别给B系统、C系统使用,其中1、2为公用接口,3、4、5为B专用,6、7、8、9为C系统专用,划分如下:
B、按接口链接URL做为唯一,不同的接口参数做为接口变量,接口有参数变更时在原来接口上进行维护,而不是新增加接口
C、为接口增加版本号,方便清楚哪些接口本次有变更,易于维护用例
参考:
https://blog.csdn.net/u012062310/article/details/72475904
https://www.cnblogs.com/yu2000/p/7053089.html