软件测试自学公众号服务端的接口测试关注方向介绍

对于服务器端接口测试，我们一般从功能开始测试，比如请求参数和响应参数的验证、业务逻辑或业务规则的验证、数据库操作的验证等。 功能正常后，根据需要进行安全相关的检查、性能测试以及一系列的扩展测试，如与历史版本的兼容性测试、接口超时验证、设计合理性验证等，并对用例设计进行分析并从这些方面进行设计。 ，下面的思维导图是测试重点的总结：

详情如下所示：

用于输入

输入主要是指接口的输入参数。 在我们平时的测试中，我们首先会考虑正常输入参数和异常输入参数。 异常情况包括：参数异常和数据异常。 用例设计更常用于等效参数。 类划分和边界值分析

A、正常输入

正常的参数输入很容易理解。 是指按照接口设计文档的参数输入标准输入正常的参数，按照接口设计文档约定的条件正常返回响应。

B、参数异常

参数异常包括：参数为空、参数过多或过少、参数错误。

C、数据异常

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

用于处理逻辑

在接口测试之前，一般研发会提供接口设计文档或者业务相关的设计图、流程图。 对于业务流程的处理逻辑，我们可以从输入参数约束、事件操作对象、业务状态转换入手。

A. 制约因素分析

数值限制：词典、级别、行业相关限制、金额限制、分数限制等。

状态限制：有效 | 无效，在线| 离线、列入黑名单 | 粉刷等

关系限制：存在或不存在、有约束力或无约束力等。

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

B. 对象分析

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

C. 状态转换分析

例如，在支付服务中，如果先支付成功，取消订单，就会退款。 如果再次支付仍不成功，则支付失败。 状态切换是否正常？ 当正常业务运行不顺利时，状态如何显示？ 可控，是否出现异常状态，空状态业务如何处理等。

D. 时序分析

在一些复杂的活动中，一项活动由按指定顺序执行的一系列动作组成。 这些动作组成了一个动作流，必须按照这个顺序执行，才能等待预期的结果。 然后在执行过程中会发生其他分支动作。 该程序将做什么？

比如斑马停车风控业务中，车辆进站后掉头不进入高速公路怎么办？

用于输出

在考虑异常时，我们通常会想到正常情况和无效情况，但它可能无法涵盖所有​​错误代码。 接口定义返回的错误码可以帮助我们补充这部分用例，例如网络异常、无效规则、无效参数、无效业务ID、无效任务、服务器异常等，您可以通过以下方式设计更多用例添加所有值。

通过根据输出来设计用例，可以了解前后端输出结果是否正常、提示是否友好、提示中是否出现敏感信息等。

数据库操作

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

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

C、数据更新是否正常，特别是时间字段，时间是否为24小时格式

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

安全

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

性能相关

A、什么情况下接口会出现并发？ 并发场景有哪些？ 什么情况下并发会出现问题？

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

接口超时

接口正常返回，但是如果接口没有返回怎么办？因此接口超时后的处理也是测试中需要考虑的一部分。 如果超时处理不当，可能会导致进程阻塞，或者超时后收到接口返回，造成逻辑混乱。

与历史版本的兼容性分析

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

同一系统内不同服务之间的接口相互调用时，新接口是否会受到历史接口的影响？ 特别是如果新旧接口都处理某个功能，是否存在业务不兼容的问题？

这就需要测试人员对一个系统进行长时间的测试，那么他们可能会想到这个场景，就会清楚地知道什么时候、哪个版本被重构了，哪些接口被废弃了，哪些接口被增加了，哪些场景会触发历史记录A界面的一定规则

合理的界面设计

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