服务端测试主要分为三大类：web端或app的服务端接口测试；对更后端的数据库、缓存系统、中间件等进行测试；异常测试、稳定性测试、性能测试等。
app业务接口常见有：数据保存、数据查询、数据状态操作
接口测试更多可以理解为前后端的数据交互是否按所约定的协议进行，包括字段以及字段的准确性。
测试用例设计参考文档：产品需求文档、接口协议文档、数据库表结构设计等。
接口测试用例设计方式方法有：
针对输入:因为输入是由客户端提交的，客户端是否按协议提交参数接口侧是无法控制的，此时针对输入测试用例需考虑：按照参数类型进行设计、非法传参的健壮性及稳定性；
针对接口处理逻辑:依据产品业务定义进行用例设计
针对接口输出:针对输出结果（数据操作以及接口返回response）进行分析设计。
关于输入的用例设计：接口文档一般都会标明参数类型及长度，是否必选项等
异常的参数校验有必要做那么多吗？
例如，在购物商城中，客户端和后台的接口，需要要做充分的异常测试。协议通常有加密，但是因为商城有利益可图，总有一些人去攻击，那么一旦攻击成功，就可以绕过客户端直接访问后台接口，如果后台逻辑有漏洞，就有利可图了。
还有，一些提供给外部使用的接口，也需要做好异常测试，因为你不清楚调用者会怎么使用，那么作为一个可靠的提供方，保证自己的稳定和健壮是非常有必要的。另外一些情况，可能这些异常是外部无法触发的，那么这种情况下，异常问题就没有那么高的优先级去解决。
测试中，通常需要去权衡测试成本和产品质量，找到一个平衡点。
用例设计-接口逻辑
约束条件分析
操作对象分析
状态转换分析
时序分析
操作对象分析：测试点针对合法或不合法的对象进行设操作
如：登录帐号A，查看帐号B的数据，风险：个人数据隐私或是安全性。
状态转换分析：业务状态规定流转必须为A>B>C，测试点需关注能否产生A>C，或C>A等情况，避免流程漏洞带来利益损失。（商城订单较常见）
时序分析（更多地可以理解为业务流转流程）：主要为某业务涉及多个接口，非顺序执行导致数据异常或正常数据无法写入的情况
用例设计-输出
针对输出结果
成功
接口response返回字段的准确性；
客户端流程是否正常；
数据更新操作的准确性（数据库、缓存等）；
失败
异常错误是否有捕获处理；
异常流程是否有明确的状态码返回；如：
1001 = 服务异常
1001 = w4ParseResult是null
接口处理时间
超时未返回
未进行超时处理，导致整个流程阻塞；
超时错误返回
服务端处理超时，但返回处理成功；
用例设计还需要考虑其他，比如：
接口兼容性（兼容新旧版本app）
接口字段是否冗余
数据保存是否重复，冗余
接口功能重叠度