接口测试中的业务逻辑

接口测试中的业务逻辑

接口测试作为测试金字塔的第二层，有着低成本、高回报的优势。越来越多的人开始

做接口测试，同时可以选择的工具、框架也越来越多。测试人员甚至不用操作app或平台，通过接口就可以测试不同场景，并测试完全流程，同时接口测试也给造数据也带来了方便。

但是，这就是接口测试了吗？当然不是。完整的接口测试不仅要校验接口能否调通，

还要校验各种组合场景、异常场景、输入参数合法性有效性和边界值、接口安全、接口性

能等。大部分同学的接口测试普遍存在两个问题，一是场景太浅，另一个是断言不足。前

者造成测试范围有局限，后者是对测试结果校验不足。只校验了响应码的接口测试是无意

义的，也不利于持续集成和持续部署。

那么接口测试用例如何设计呢？从输入、处理逻辑、输出三部分入手。输入就是各种

参数类型及组合的校验，如对数值类型，通过负数、0、小数、99999999999999999等，前端可能过滤掉了这些输入，但是在接口层还是要做校验，特别是对金额来说。对输入的

测试可以用等价类、边界值、判定表、因果图等方法来分析。对于输出，则是要覆盖各种

响应吗和返回结果，正常的、异常的、特殊的、失败的情况等等。

我想讨论的，是第二部分，业务逻辑。大家都会对接口做正常场景的测试，也会做参

数校验的测试，但是不知道如何结合业务做接口测试。我们知道在业务流程中，是用户/后台的一些操作，引起数据或者状态的改变，然后引申出各个检查点。比如用户还款，还清

了最后一期，那么这个操作的结果需要列出来：比如更新应收台账、更新回款记录、更新

还款状态、恢复额度；我们的检查点也要列出来：在客户端检查待还列表、检查提现记录、检查卡片状态，以及在后台检查各个表的数据。这些就是可以提供给接口测试的。因为业

务流程有很多条线，场景不仅只有一个主流程，这个还清最后一笔就是一个场景，除了要

校验接口响应中的结果，还要到数据库校验各个值，同时可以通过其它接口，如再次调用

还款接口会还款失败，调用额度查看接口额度已回恢复，查看待还列表接口状态为已还清。要在接口测试中实现比较全的场景和校验点，需要提前把checklist列出来，详细的测试

用例可以不需要，但是checklist一定要有。总结起来就是通过响应结果进行校验、到数

据库进行校验、通过其它接口校验。

接口测试的业务场景如何梳理呢？在app或者平台上可能限制了我们的操作，但是接口不同，只要我们愿意，我们可以设计各种顺序、各种次数的场景，当然都是要和业务逻

辑有关系的。根据状态不同，我们可以测试当用户处于未登录、未绑卡、未借款状态的时

候的一些操作；根据操作路径不同，我们可以让用户通过微信、支付宝、银行卡支付；根

据业务规则不同，可以测试不可部分还款/提前还款的产品可否进行部分还款/提前还款、

无该优惠的用户群可否使用该优惠券；根据操作次数不同，我们可以测试用户重复绑卡、

重复提现、重复还款；根据操作顺序不同，我们可以测试先收到优惠券再还款、还款中收

到优惠券；根据数据不同，可以设计不同期数、不同金额的提现方式。同时在接口中一样

也可以用场景插入、场景替换、场景删除、场景重复、数据替换的方式设计用例。而针对

异常场景，用户权限不允许的操作、状态不允许的操作、数据不允许的操作、极限条件下的操作，都可以用上面的方式通过接口进行测试。

把重要的接口测试用例通过脚本实现，不仅可以提高回归效率，减少版本优化所需要的测试时间；接入持续集成持续部署，还可以起到监控的作用，同时可以让优质的代码更快上线。把重复性的工作通过自动化的方式实现，我们才能有更多的时间去做探索性的测试和其它专项测试。当然接口测试维护成本还是需要的，但和UI自动化相比已经是非常低了。