从全局视角来看接口测试

开门见山,什么是接口?通常情况下分为如下两种:

程序内部的接口:方法与方法、模块与模块之间的交互,程序内部抛出的接口;如登录发帖场景,发帖前必须要执行登录动作,因此发帖和登录这两个模块之间存在交互,交互会抛出一个接口,供内部系统进行调用。

程序内部封装的一些方法,模块供程序内部调用。如Java 封装 jar包 ,C++ 封装dll 文件 等。需要通过白盒测试方法进行测试。主要还是通过对模块及方法的调用,输入正向的,异常的测试数据,检验其功能的完整性。

接口测试和app测试的活动有部分重复的内容,主要集中在业务功能测试方面。除此之外,针对各自特性的测试都不一样,需要分别进行有针对性的测试,才能确保整个产品的质量。

接口测试更关注于服务器逻辑验证,而UI层测试可以关注于页面展示逻辑及界面前端与服务器集成验证。

了解接口当然必须了解协议HTTP/HTTPS

超文本传输协议(英文:HyperText Transfer Protocol,缩写:HTTP)是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP是万维网的数据通信的基础。定义啥的看多了也没意义直接上图

可以看到左边请求部分包括,请求行、请求头、请求数据(这个抓包Get请求方法所以请求部分不存在);右边部分响应部分内容,状态行、响应头、响应正文。当然关于协议这块大家可以百度网上一大把这里讲的只是一带而过让大家了解报文组成,然后在我们测试工具中应用,测试工具postman上图:

在我们的测试工具中,输入我们接口相关信息就可以进行测试了。工具类的操作了解协议后大家会上手很快的后面部分才是重点。

接口测试第一步需求分析

我们对接口测试做了一个脑图的需求分析,图中的测试点都是我们需要在用例设计时候需要进行关注和覆盖的。同时下面也是我们测试人员在用例设计时候需要注意的。

关注需求:测试过程中从需求角度出发设计测试用例,不必过度的设计我们异常测试用例。如某需求接口增加请求头,目的是根据请求头字段过滤对应查询信息,我们关注是新增字段业务功能以及老功能点兼容性,而非过度异常测试场景。

必填项校验:测试过程中不填并不是传“”或者空格,对于json数据而言是不传整个Key : Value 这段键值对如:必填项参数{"userid" :"123"}则我们测试不传场景应该传{}而非{"userid":""}或者{"userid":" "}

边界值校验:对于String而言有字符长度限制,对于Int、Double等数值型要了解其限制最大值。如Int取值范围-2147483648~2147483647

必测点:业务返回码以及枚举值全量覆盖。如:返回参数中有枚举值分别为交易成功、交易失败、校验中。必须对状态进行全覆盖。

性能测试:性能测试时应对改服务的网络拓扑、服务架构及链路进行梳理,根据产品或开发提供指标进行需求分析,制定测试方案评审通过后方可进行测试。

安全测试:可通过安全测试工具进行扫描测试如AppScan、 sqlmap等

设计方法:等价类、边界值、判断表等用例设计方法的应用

有了前排的需求分析,我觉得应该覆盖率应该很高了吧,经历过的人都知道无论你怎么去头脑风暴,千丝万缕的系统复杂度还是会让我经常会遗漏一些测试场景或者经常收到线上故障困扰。

覆盖率工具的应用

Jacoco:即 Java Code Coverage,是一款开源的 Java 代码覆盖率统计工具。可以帮助我们在测试过程中统计到我们用力覆盖率。

低投入,高产出;自动化维护成本低,测试效率高,贯穿整个产品生命周期,即构建-测试-发布-监控,更快更早发现问题。从“时间”、“人力”、“收益”方面,值得去实现接口自动化。

设计思路:数据驱动层收集测试数据及测试行为,核心层进行实习测试手机测试结果。

平台展示:

接口测试在持续测试体系中的应用

接口测试在我们持续测试质量体系中应用无处不在,可以应用到我们CI/CD中,作为一种准入准出的标准。

思考:有了上面的这些思路精准测试实现还难吗,欢迎留言讨论~

本站文章资源均来源自网络,除非特别声明,否则均不代表站方观点,并仅供查阅,不作为任何参考依据!
如有侵权请及时跟我们联系,本站将及时删除!
如遇版权问题,请查看 本站版权声明
THE END
分享
二维码
海报
从全局视角来看接口测试
程序内部的接口:方法与方法、模块与模块之间的交互,程序内部抛出的接口;如登录发帖场景,发帖前必须要执行登录动作,因此发帖和登录这两个模块之间存在交互,交互会抛出...
<<上一篇
下一篇>>