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

lsekfe

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

　详细介绍如下：
　　针对输入
　　输入主要是指接口的入参。在我们的正常测试中，我们将首先考虑正常入参和异常入参。异常情况包括:参数异常、数据异常。在用例设计中，比较常用的是等价类划分和边界值分析。
　　A、正常的入参
　　正常的入参很好理解，就是根据接口设计文档的入参标准，输入正常的参数，响应按接口设计文档的约定条件正常返回
　　B、参数异常
　　参数为空，多参、少参以及错误的参数
　　C、数据异常
　　数据类型错误、空非空参数、长度不符合设计、数据不在字典中、非法数字、特殊字符或敏感字符、具有关联关系的异常参数数据等。
　　处理逻辑
　　在接口测试之前，R&D会提供接口设计文件或与业务相关的设计图纸和流程图。对于业务流程的处理逻辑，我们可以从入参、事件的操作对象、业务的状态进行转换。
　　1.限制条件分析
　　数值限制:字典、等级、行业相关限制、金额限制、分数限制等。
　　状态限制:有效|无效、在线|离线、拉黑|洗白等。
　　关系的限制:存在或不存在，绑定或解绑等。
　　权限限制:管理员、普通用户等。
　　2.对象分析
　　对象分析主要对合法对象和非法对象进行操作。比如银行卡用户充值卡，可能存在用户充值自己以外的卡；用户用自己的卡充值，卡已经过期；用户使用自己的卡充值，卡被列入黑名单或挂失。
　　3.状态转换分析
　　比如付款业务，先付款成功，取消后退款。如果再次支付不成功，将是支付失败。状态之间的切换是否正常，状态如何显示，是否可控，是否有异常状态，空状态业务如何处理等。
　　4.时序分析
　　在一些复杂的活动中，一个活动是由一系列动作按照指定的顺序执行的，这就形成了一个动作流。只有按照这个顺序执行动作，我们才能得到预期的结果。在执行过程中，将对其他分支动作程序做什么？
　　针对输出
　　在考虑异常时，我们通常会想到正常情况和无效情况，但可能并不能涵盖所有的错误代码，接口定义返回的错误代码可以帮助我们补充这部分用例，比如网络异常、规则无效、参数无效、业务id无效、任务无效、服务器异常等。通过补充errorcode的值可以设计更多的用例。
　　这种基于输出的设计案例可以发现前后端输出结果是否正常，提示是否友好，敏感信息是否出现等等。
　　数据库操作
　　A、数据库是否频繁操作，在写入数据库的过程中是否会占用大量的CPU，写入数据库完成后是否会释放进程。
　　B、业务数据入库是否正常，是否有重复数据入库，是否有乱码；日志数据入库正常吗？
　　C、数据更新是否正常，尤其是时间字段，时间是否为24小时格式。
　　D、数据删除和备份是否正常。
　　安全性
　　敏感信息是否加密（如银行账号，密码，转账金额）
　　性能相关
　　A、接口在什么情况下会出现并发，并发场景是什么，什么情况下的并发会导致问题
　　B、最大并发，响应时间，吞吐量，资源消耗情况
　　接口超时
　　接口正常返回，但是如果接口不返回呢？因此，接口超时后的处理也是测试中需要考虑的一部分。如果超时处理不当，可能导致进程阻塞，或者超时后收到接口返回，导致逻辑混乱。
　　与历史版本的兼容性分析
　　放弃的协议或接口在代码中没有标注，在某些情况下可能会触发版本历史中放弃的协议或接口，导致用户使用或调用函数后出现意外问题和损失。
　　同一系统中不同服务之间的接口相互调用时，新接口是否受到历史接口的影响，特别是新旧接口处理某一功能时，是否存在业务不兼容的情况？
　　这就需要测试人员对一个系统进行长时间的测试，所以他们可能会想到这个场景，他们会清楚地知道什么时候哪个版本被重构了，哪些接口被放弃了，哪些接口被添加了，哪些场景会触发历史接口的某些规则。
　　接口设计合理
　　字段是否冗余，接口是否返回调用方期望的信息，接口定义是否满足所有调用方的需求，接口是否方便调用，接口是否可扩展，接口参数是否方便使用，接口的业务规则是否正确，对整个服务的使用会有什么影响？