你完全了解接口测试么?
发布时间:2022-06-07

接口测试作为测试金字塔的第二层,有着低成本、高回报的优势。越来越多的人开始做接口测试,同时可以选择的工具、框架也越来越多。


测试人员甚至不用操作APP或平台,通过接口就可以测试不同场景,并测试完全流程,同时接口测试也给造数据也带来了方便。


但是,这就是接口测试了吗?当然不是。


完整的接口测试不仅要校验接口能否调通,还要校验各种组合场景、异常场景、输入参数合法性有效性和边界值、接口安全、接口性能等。


大部分同学的接口测试普遍存在两个问题,一是场景太浅,另一个是断言不足。前者造成测试范围有局限,后者是对测试结果校验不足。


只校验了响应码的接口测试是无意义的,也不利于持续集成和持续部署。



接口测试用例如何设计


从输入、处理逻辑、输出三部分入手。输入就是各种参数类型及组合的校验,如对数值类型,通过负数、0、小数、99999999999999999等。


前端可能过滤掉了这些输入,但是在接口层还是要做校验,特别是对金额来说:


● 对输入的测试可以用等价类、边界值、判定表、因果图等方法来分析;


● 对于输出,则是要覆盖各种响应码和返回结果,正常的、异常的、特殊的、失败的情况等等。



业务逻辑


大家都会对接口做正常场景的测试,也会做参数校验的测试,但是不知道如何结合业务做接口测试。


我们知道在业务流程中,是用户/后台的一些操作,引起数据或者状态的改变,然后引申出各个检查点。


比如用户还款,还清了最后一期,那么这个操作的结果需要列出来:比如更新应收台账、更新回款记录、更新还款状态、恢复额度。


我们的检查点也要列出来:在客户端检查待还列表、检查提现记录、检查卡片状态,以及在后台检查各个表的数据。


这些就是可以提供给接口测试的。因为业务流程有很多条线,场景不仅只有一个主流程,这个还清最后一笔就是一个场景,除了要校验接口响应中的结果,还要到数据库校验各个值,同时可以通过其它接口,如再次调用还款接口会还款失败,调用额度查看接口额度已恢复,查看待还列表接口状态为已还清。


要在接口测试中实现比较全的场景和校验点,需要提前把checklist列出来,详细的测试用例可以不需要,但是checklist一定要有。


总结起来就是通过响应结果进行校验、到数据库进行校验、通过其它接口校验。



接口测试业务场景如何梳理


在APP或者平台上可能限制了我们的操作,但是接口不同,只要我们愿意,我们可以设计各种顺序、各种次数的场景,当然都是要和业务逻辑有关系的:


● 根据状态不同,我们可以测试当用户处于未登录、未绑卡、未借款状态的时候的一些操作;


● 根据操作路径不同,我们可以让用户通过微信、支付宝、银行卡支付;


● 根据业务规则不同,可以测试不可部分还款/提前还款的产品可否进行部分还款/提前还款、无该优惠的用户群可否使用该优惠券;


● 根据操作次数不同,我们可以测试用户重复绑卡、重复提现、重复还款;


● 根据操作顺序不同,我们可以测试先收到优惠券再还款、还款中收到优惠券;


● 根据数据不同,可以设计不同期数、不同金额的提现方式。


同时在接口中一样也可以用场景插入、场景替换、场景删除、场景重复、数据替换的方式设计用例。


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


把重要的接口测试用例通过脚本实现,不仅可以提高回归效率,减少版本优化所需要的测试时间,接入持续集成持续部署,还可以起到监控的作用,同时可以让优质的代码更快上线。


把重复性的工作通过自动化的方式实现,我们才能有更多的时间去做探索性的测试和其它专项测试。当然接口测试维护成本还是需要的,但和UI自动化相比已经是非常低了。



更多软件测试相关推荐:

软件测试更多干货文章

软件测试就业培训


文章来源:网络  版权归原作者所有

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8103),我们将立即处理

相关阅读
/