这篇算是把服务端接口测试彻底讲明白了

玩技站长 测试资讯评论93字数 1473阅读4分54秒阅读模式
摘要我们通常从功能上测试服务器的接口,比如请求参数和响应参数的验证,业务逻辑或业务规则的验证,数据库操作的验证。功能正常后,将按要求进行安全相关检查、性能测试、系列扩展测试,如与版本历...

我们通常从功能上测试服务器的接口,比如请求参数和响应参数的验证,业务逻辑或业务规则的验证,数据库操作的验证。功能正常后,将按要求进行安全相关检查、性能测试、系列扩展测试,如与版本历史的兼容性测试、接口超时验证、设计合理性验证等。用例设计也从这些方面进行了分析和设计。

下图是测试关注方向的概要:
文章源自玩技e族-https://www.playezu.com/194025.html

这篇算是把服务端接口测试彻底讲明白了插图
文章源自玩技e族-https://www.playezu.com/194025.html

详细介绍如下:文章源自玩技e族-https://www.playezu.com/194025.html

针对输入文章源自玩技e族-https://www.playezu.com/194025.html

输入主要是指接口的入参。在我们的正常测试中,我们将首先考虑正常入参和异常入参。异常情况包括:参数异常、数据异常。在用例设计中,比较常用的是等价类划分和边界值分析。文章源自玩技e族-https://www.playezu.com/194025.html

A、正常的入参文章源自玩技e族-https://www.playezu.com/194025.html

正常的入参很好理解,就是根据接口设计文档的入参标准,输入正常的参数,响应按接口设计文档的约定条件正常返回。文章源自玩技e族-https://www.playezu.com/194025.html

B、参数异常文章源自玩技e族-https://www.playezu.com/194025.html

参数为空,多参、少参以及错误的参数。文章源自玩技e族-https://www.playezu.com/194025.html

C、数据异常文章源自玩技e族-https://www.playezu.com/194025.html

数据类型错误、空非空参数、长度不符合设计、数据不在字典中、非法数字、特殊字符或敏感字符、具有关联关系的异常参数数据等。

处理逻辑

在接口测试之前,R&D会提供接口设计文件或与业务相关的设计图纸和流程图。对于业务流程的处理逻辑,我们可以从入参、事件的操作对象、业务的状态进行转换。

1.限制条件分析

数值限制:字典、等级、行业相关限制、金额限制、分数限制等。

状态限制:有效|无效、在线|离线、拉黑|洗白等。

关系的限制:存在或不存在,绑定或解绑等。

权限限制:管理员、普通用户等。

2.对象分析

对象分析主要对合法对象和非法对象进行操作。比如银行卡用户充值卡,可能存在用户充值自己以外的卡;用户用自己的卡充值,卡已经过期;用户使用自己的卡充值,卡被列入黑名单或挂失。

3.状态转换分析

比如付款业务,先付款成功,取消后退款。如果再次支付不成功,将是支付失败。状态之间的切换是否正常,状态如何显示,是否可控,是否有异常状态,空状态业务如何处理等。

4.时序分析

在一些复杂的活动中,一个活动是由一系列动作按照指定的顺序执行的,这就形成了一个动作流。只有按照这个顺序执行动作,我们才能得到预期的结果。在执行过程中,将对其他分支动作程序做什么?

针对输出

在考虑异常时,我们通常会想到正常情况和无效情况,但可能并不能涵盖所有的错误代码,接口定义返回的错误代码可以帮助我们补充这部分用例,比如网络异常、规则无效、参数无效、业务id无效、任务无效、服务器异常等。通过补充errorcode的值可以设计更多的用例。

这种基于输出的设计案例可以发现前后端输出结果是否正常,提示是否友好,敏感信息是否出现等等。

数据库操作

A、数据库是否频繁操作,在写入数据库的过程中是否会占用大量的CPU,写入数据库完成后是否会释放进程。

B、业务数据入库是否正常,是否有重复数据入库,是否有乱码;日志数据入库正常吗?

C、数据更新是否正常,尤其是时间字段,时间是否为24小时格式。

D、数据删除和备份是否正常。

安全性

敏感信息是否加密(如银行账号,密码,转账金额)

性能相关

A、接口在什么情况下会出现并发,并发场景是什么,什么情况下的并发会导致问题。

B、最大并发,响应时间,吞吐量,资源消耗情况。

接口超时

接口正常返回,但是如果接口不返回呢?因此,接口超时后的处理也是测试中需要考虑的一部分。如果超时处理不当,可能导致进程阻塞,或者超时后收到接口返回,导致逻辑混乱。

与历史版本的兼容性分析

放弃的协议或接口在代码中没有标注,在某些情况下可能会触发版本历史中放弃的协议或接口,导致用户使用或调用函数后出现意外问题和损失。

同一系统中不同服务之间的接口相互调用时,新接口是否受到历史接口的影响,特别是新旧接口处理某一功能时,是否存在业务不兼容的情况?

这就需要测试人员对一个系统进行长时间的测试,所以他们可能会想到这个场景,他们会清楚地知道什么时候哪个版本被重构了,哪些接口被放弃了,哪些接口被添加了,哪些场景会触发历史接口的某些规则。

接口设计合理

字段是否冗余,接口是否返回调用方期望的信息,接口定义是否满足所有调用方的需求,接口是否方便调用,接口是否可扩展,接口参数是否方便使用,接口的业务规则是否正确,对整个服务的使用会有什么影响?

 
匿名

发表评论

匿名网友
确定

拖动滑块以完成验证