接口用例设计

背景说明

一个系统可为其他系统提供能力或者直接为UI层提供数据，在设计系统测试方案时应考虑上游调用的各种场景，不仅考虑顺利且正向思维操作的场景，还应逆向的场景。例如：人为操作造成的不合理数据、服务错误的调用、请求时由于网络等环境原因造成的异常。但在此之前，也应考虑系统本身稳定性和规范性，应从本身定义约束。定义自身规范，不仅可从一方面保证系统稳定，同时有了自身的介入规范更适用于多业务接入，而不是单独承接某一上游。系统稳定和规范会规避后续更多的BUG。换句话来说，使用契约式设计的方式，运行前条件必须满足，参数不正确不可运行；运行中内部状态必须不变；运行后结果必须保持一致。

在设计接口用例设计时，除实现功能外，应关注：幂等性、空校验、流程节点限制、异常校验。

01 幂等性

何为幂等性？

幂等为一数学概念，指使用相同参数重复执行，能获取相同结果。换句话说，幂等性就是调用一次成功后，再次调用后仍返回原来结果，即使调用100次后结果都相同。

如何使接口幂等性？

首先引入一个概念—唯一索引，一句话介绍：数据表中每个唯一索引对应的数据记录只会有一条。当第一次调用生成唯一一条记录时，再次调用时，接口内部应前置根据唯一索引进行查询，如果发现存在记录直接返回查询结果，不进行后续操作。例如：调用创建支付单接口会创建一条支付单数据落入支付单数据表，我们定义调用方字段A和调用流水标识字段B为唯一索引，当然接口参数中包含这两个字段。当再次调用接口时，会首先使用A参数和B参数进行查询，当对应记录已存在时，直接返回查询结果。

为什么要做幂等性校验？

试想没有幂等性校验会怎样，还以创建支付单为例，当上游一个单子L准备创建支付单，第一次调用创建成功支付单P1，当触发再次调用时：

如果数据表已建立唯一索引，则会插入数据失败，接口抛出异常，上游可能更是一脸懵逼。不仅仅是造成一条废弃数据，上游可能只是想借助支付中心能力让用户完成支付，当已经创建对应支付单时只需返回结果让用户继续完成支付操作即可。

如果数据表没有唯一索引, 上游多次调用，单子L就会对应多个支付单，没有了唯一关联，试想如果单子L想查询对应的支付单，结果返回多个当然不合理，又如，多个支付单是不是用户就可以多次支付了？当单子L首次支付成功后应该对应哪个支付单置为支付成功呢？对后续针对支付单打款退款等操作影响更是将之大，造成资金混乱和不安全。从另一层面来说，当无数次调用，就要生成无数条数据，造成无数不必要数据或者说无效数据，增加系统压力。

如何进行接口幂等性测试？

• 首先，确认及检验一条数据的唯一标识组合：数据表根据创建唯一索引，接口参数中包含组合中的每个元素。
• 首次调用接口后，观察返回结果，并根据唯一索引确定数据表中的数据已存在。
• 参数无任何改变时，再次调用，结果返回为首次调用的返回结果，且数据表不会生成新的记录。
• 改变除唯一索引外其他参数（此参数对应数据表一个字段），再次调用，返回结果仍为首次调用结果，改变的参数值仍为首次调用的值。数据表不会插入新的记录且记录不会更改，重点关注调用参数中改变参数对应的字段仍为首次调用后的值，不会更新。
• 改变唯一标识中一个元素对应的参数，再次调用，返回结果会生成新的一条记录，且数据表生成一条新的记录。

02 非空校验 && 兼容为空

非空校验即对参数进行非空校验，当参数为空时，接口会前置校验提示错误，不继续向下执行。

为何要做接口非空校验？

增加系统稳定性，接口健壮性。假如接口未做非空校验，向下执行在数据表创建一条数据，再对数据进行操作时由于参数为空无法完成。例如调用打款接口，参数打款金额不可为空。假如去掉前置非空校验，首先会生成一条初始化状态的打款单据，然后打款接口内部中有一套复杂的后续执行逻辑，转入个人余额、记账、提现等，当真实和三方打款交互时，由于金额为空而报错。可见，生成了一系列处于中间节点的脏数据，而且进行了许多无用的调用或执行。

如何判断哪些需要进行非空校验？

可根据系统本身功能、其他接口依赖情况、依赖下游接口参数判断。具体来说，例如一个简单的积分充值接口，积分币数量不可空。从系统本身来说，无充值数量此充值单据即无意义。而充值数量会作为积分消费、失效等接口调用的起始数据源依赖。同时，积分充值本质为给用户充值钱款，积分数量会转化 为金额且向下请求支付中心进行资金流转，而资金流转功能限制金额不可为空。

除此之外，需注意对功能的严格定义，有些参数不可非空校验且需兼容为空。直接举例，查询支付方式接口，金额字段不是必传字段，当接口内部对金额处理就需兼容为空情况，当金额参数传空时，调用此不可报错。

如何进行具体测试？

• 明确哪些参数为必传，哪些为非必传。
• 依次对 必传参数设置为空进行请求，此时接口不可调用成功，无数据生成，同时关注接口返回信息明确性，如果接口返回提示文案为“XX不可为空”一目了然，极大方便定位问题，提高效率。
• 对非空参数依次传空，观察接口调用情况。

当然，首先需明白业务逻辑，从而进行用例设计。尤其对于参数复杂的接口，当某一条调用规则下 某些非空参数就需要作为必传了。

03 流程节点限制

流程节点限制，即需严格遵守流程流转。当调用某就流程时，必须由上一节点调用。

为何需做流程节点限制？

支付单系统的流程为流程1：创建、支付完成、支付后的使用，流程2：创建、取消。如果目前支付单据为创建状态，对其调用支付后的使用接口，会导致巨大功能问题。如果对支付完成的支付单据进行取消操作，逻辑也不合理，产生问题。故系统需在接口内部前置作流程节点限制。

如何做流程节点限制测试？

明确系统的状态流转，一个系统设计初期就需明确功能及状态流转，会依据产品对系统的定义及依赖的下游或三方产品的功能。

测试正常流程节点。按照正向流程依次调用，观察调用结果及生成状态。调用创建接口，调用成功且生成单据状态为创建， 再使用此单据进行完成接口的调用，观察调用结果及生成状态。然后再进行下一接口调用。

测试不合理流程节点下的调用，包含单一流程和交叉流程，观察接口返回及数据状态。例如单据状态为创建时调用使用接口，单据状态为完成时调用取消接口。首先需观察数据表中单据并未作任何更新，再观察接口并不会出现调用级别的错误，最后观察接口返回信息，提示"XX状态不可进行XX调用"。

04 异常校验

为何做异常校验？

确保主功能可使用，不让非主功能异常影响主功能。且会出现接口内部未校验异常，后续功能不可实现的情况。异常可大致分为三种：

• 环境异常，即非强依赖的服务异常时，应过滤掉此服务继续向下执行。例如收银台查询支付方式接口内部实现为，先查询出支付方式为列表1，然后会将列表1请求风控接口再次过滤得到支付方式列表2。生产环境中如果出现请求风控超时或者服务异常等情况，而查询支付方式并未兼容此异常情况，会直接系统报错导致用户无法支付。而如果查询支付方式接口兼容了请求风控服务异常，会直接返回支付列表1，让用户继续支付。
• 数据异常，当数据值异常时，无法实现功能或者向下执行。例如必须为整数情况不可传入小数，又如积分充值接口需对积分充值数量限制为汇率的整数倍，如果不进行此校验，当执行到钱款流转时，会出现比1分还小的值，导致无法进行。又如，当用户可用支付方式匹配为0条时，应展示出默认的一通道，让用户可支付。
• 前置条件异常：举例来说，通过支付单打款，需对支付可用金额校验，当打款金额大于支付单可用金额应直接前置提示，不可向下执行。

如何测试异常场景？

• 首先深入了解业务特点和系统流转，判断哪些异常场景需要进行测试。
• 通过关闭下游服务构造环境异常和手动构造其他异常场景进行测试。