接口自动化--思路与经验
接口测试中的业务逻辑
接口测试作为测试金字塔的第二层,有着低成本、高回报的优势。越来越多的人开始做接口测试,同时可以选择的工具、框架也越来越多。测试人员甚至不用操作app或平台,通过接口就可以测试不同场景,并测试完全流程,同时接口测试也给造数据也带来了方便。
但是,这就是接口测试了吗?当然不是。完整的接口测试不仅要校验接口能否调通,还要校验各种组合场景、异常场景、输入参数合法性有效性和边界值、接口安全、接口性能等。大部分同学的接口测试普遍存在两个问题,一是场景太浅,另一个是断言不足。前者造成测试范围有局限,后者是对测试结果校验不足。只校验了响应码的接口测试是无意义的,也不利于持续集成和持续部署。
那么接口测试用例如何设计呢?从输入、处理逻辑、输出三部分入手。输入就是各种参数类型及组合的校验,如对数值类型,通过负数、0、小数、99999999999999999等,前端可能过滤掉了这些输入,但是在接口层还是要做校验,特别是对金额来说。对输入的测试可以用等价类、边界值、判定表、因果图等方法来分析。对于输出,则是要覆盖各种响应吗和返回结果,正常的、异常的、特殊的、失败的情况等等。
我想讨论的,是第二部分,业务逻辑。大家都会对接口做正常场景的测试,也会做参数校验的测试,但是不知道如何结合业务做接口测试。我们知道在业务流程中,是用户/后台的一些操作,引起数据或者状态的改变,然后引申出各个检查点。比如用户还款,还清了最后一期,那么这个操作的结果需要列出来:比如更新应收台账、更新回款记录、更新还款状态、恢复额度;我们的检查点也要列出来:在客户端检查待还列表、检查提现记录、检查卡片状态,以及在后台检查各个表的数据。这些就是可以提供给接口测试的。因为业务流程有很多条线,场景不仅只有一个主流程,这个还清最后一笔就是一个场景,除了要校验接口响应中的结果,还要到数据库校验各个值,同时可以通过其它接口,如再次调用还款接口会还款失败,调用额度查看接口额度已回恢复,查看待还列表接口状态为已还清。要在接口测试中实现比较全的场景和校验点,需要提前把checklist列出来,详细的测试用例可以不需要,但是checklist一定要有。总结起来就是通过响应结果进行校验、到数据库进行校验、通过其它接口校验。
接口测试的业务场景如何梳理呢?在app或者平台上可能限制了我们的操作,但是接口不同,只要我们愿意,我们可以设计各种顺序、各种次数的场景,当然都是要和业务逻辑有关系的。根据状态不同,我们可以测试当用户处于未登录、未绑卡、未借款状态的时候的一些操作;根据操作路径不同,我们可以让用户通过微信、支付宝、银行卡支付;根据业务规则不同,可以测试不可部分还款/提前还款的产品可否进行部分还款/提前还款、无该优惠的用户群可否使用该优惠券;根据操作次数不同,我们可以测试用户重复绑卡、重复提现、重复还款;根据操作顺序不同,我们可以测试先收到优惠券再还款、还款中收到优惠券;根据数据不同,可以设计不同期数、不同金额的提现方式。同时在接口中一样也可以用场景插入、场景替换、场景删除、场景重复、数据替换的方式设计用例。而针对异常场景,用户权限不允许的操作、状态不允许的操作、数据不允许的操作、极限条件下的操作,都可以用上面的方式通过接口进行测试。
把重要的接口测试用例通过脚本实现,不仅可以提高回归效率,减少版本优化所需要的测试时间;接入持续集成持续部署,还可以起到监控的作用,同时可以让优质的代码更快上线。把重复性的工作通过自动化的方式实现,我们才能有更多的时间去做探索性的测试和其它专项测试。当然接口测试维护成本还是需要的,但和UI自动化相比已经是非常低了。