服务器的接口测试通常从功能开始，如请求参数和响应参数的验证，业务逻辑或业务规则的验证，数据库操作的验证。功能正常后，将根据需要进行安全相关的检查、性能测试和一系列扩展测试，如与版本历史的兼容性测试、接口超时验证和设计合理性验证等。用例设计也是从这些方面进行分析和设计的，下面的思维导图是测试关注的一个大致方向:

详情如下:

用于输入

输入主要指界面的参数。在我们通常的测试中，我们会首先考虑正常参数和异常参数，包括异常参数和数据。在用例设计中，等价类划分和边界值分析被广泛使用。

A.正常参与

正常参数通俗易懂，即根据界面设计文件的参数标准，输入正常参数，响应按照界面设计文件约定的条件正常返回。

B.异常参数

参数异常包括:空参数、多参数或少参数、错误参数。

C.异常数据

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

对于处理逻辑

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

A.限制条件分析

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

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

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

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

B.对象分析

对象分析主要是操作合法和非法的对象。比如银行卡用户给卡充值，可能有:用户A给非用户A的卡充值；用户用自己的卡充值，卡已经过期；a用户使用自己的卡充值，卡被列入黑名单或挂失。

C.状态转换分析

比如支付业务，第一次支付成功，票据取消后会进行退款。如果第二次支付不成功，支付会失败，状态之间的切换是否正常，状态如何显示，是否可控，是否存在异常状态，空白状态业务如何处理。

D.时间序列分析

在一些复杂的活动中，一个活动是由一系列动作按照指定的顺序执行的，这就形成了一个动作流。只有按照这个顺序执行动作，我们才能等待预期的结果。其他分支动作程序在执行过程中会发生什么？

比如斑马停车风险管控业务，如果车辆进站后直接掉头不进入高速业务，该如何处理？

针对输出

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

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

数据库操作

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

B.业务数据入库是否正常，是否有重复数据入库，是否有乱码；日志数据入库正常吗？

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

D.数据删除和备份正常吗？

安全性

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

性能相关

A、什么情况下接口会并发，什么是并发场景，什么情况下并发会导致问题？

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

接口超时

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

与历史版本的兼容性分析

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

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

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

接口设计合理

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