测试经理：“你做了三年测试，连服务端的接口测试都不会？”

服务端的接口测试我们一般从功能开始进行测试比如请求参数和响应参数的校验业务逻辑或业务规则的校验数据库操作的校验。

功能正常后会根据需要进行安全相关的检查、性能测试以及系列扩展测试比如与历史版本的兼容性测试、接口的超时验证以及设计合理性验证等用例设计也是从这几个方面进行分析设计。

技术提升还得自觉才行功能测试到接口自动化测试技术进阶必看教程

下面的思维导图是一个概要的测试关注方向

详细介绍如下

针对输入

输入主要是指接口的入参我们平常的测试中会先考虑正常的入参以及异常的入参异常情况包括参数异常和数据异常用例设计这块使用较多的是等价类划分和边界值分析

A、正常的入参

正常的入参很好理解就是根据接口设计文档的入参标准输入正常的参数响应按接口设计文档的约定条件正常返回

B、参数异常

参数异常包括参数为空多参或少参错误的参数

C、数据异常

数据异常数据类型错误、非空参数为空长度不符合设计不在字典范围内的数据不合法的成员特殊字符或敏感字符存在关联关系的参数数据异常等

针对处理逻辑

接口测试前一般研发会提供接口设计文档或业务相关的设计图、流程图针对业务流程的处理逻辑我们可以从入参的限制条件、事件的操作对象、业务的状态转换

A、 限制条件分析

数值的限制字典等级行业相关限制金额限制分数限制等

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

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

权限的限制管理员普通用户等

B、 对象分析

对象分析主要是对合法和不合法的对象进行操作比如银行卡用户对卡进行充值则可能存在用户A使用非用户A的卡充值用户A使用自己的卡进行充值卡已过有效期用户A使用自己的卡进行充值卡为黑名单或挂失等。

C、 状态转换的分析

比如支付类业务先支付成功撤单后会退款再次支付如果支付未成功则是支付失败状态之间的切换是否正常未按正常业务顺利进行操作时状态怎么显示是否可控是否出现异常状态空状态业务怎么处理等

D、 时序分析

一些复杂的活动中一个活动是由一系列的动作按照指定顺序进行这些动作形成一个动作流是有按照这个顺序依次执行才能等到预期的结果那么在执行过程中发生的其他分支动作程序会作何处理

比如斑马停车风控业务如果在入站后车辆直接掉头不驶入高速业务如何处理

针对输出

在考虑异常时通常我们都会想到正常情况无效的情况但是不一定能覆盖所有错误码而接口定义返回的错误码可以帮助我们补充这一部分的用例比如网络异常无效的规则无效的参数无效的业务ID无效的任务服务器异常等把errorcode的值都补充上去可以设计更多的用例

这种根据输出进行设计用例可以发现前后端是否正常输出结果提示是否友好提示是否出现敏感信息等

数据库操作

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

B、业务数据入库是否正常是否有重复数据入库是否出现乱码日志数据入库是否正常

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

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

安全性

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

性能相关

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

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

接口超时

接口正常情况下是有返回的那么如果接口不返回呢所以接口超时后的处理也是测试需要考虑的部分如果超时处理不当可能会引起进程阻塞或者超时后又接收到接口返回导致逻辑错乱

与历史版本的兼容性分析

已废弃的协议或接口代码并未注释在某种特定的情况下可能会触发历史版本已废弃的协议或接口导致用户使用或功能调用后出现意想不到的问题损失

同一套系统不同服务之间的接口相互调用时新接口是否受历史接口的影响尤其是新旧接口都对某一个功能进行处理是否存在业务不兼容的问题

这一点需要测试人员是长期的测试一个系统的那么可能会想到这种场景会清楚的知道什么时候哪个版本进行了重构废弃了那些接口新增了那些接口哪些场景会触发历史接口的某个规则

接口设计合理

接口字段是否冗余接口是否返回了调用方期望得到的信息接口定义是否满足所有调用者的需求接口调用是否方便接口是否可扩展接口参数使用是否方便接口的业务规则是否都正确接口都整个服务的使用会产生那些影响