接口测试做为测试金字塔的第二层，有着低成本、高回报的优势。越来越多的人起头做接口测试，同时能够选择的东西、框架也越来越多。测试人员以至不消操做app或平台，通过接口就能够测试差别场景，并测试完全流程，同时接口测试也给造数据也带来了便利。
但是，那就是接口测试了吗?当然不是。完好的接口测试不只要校验接口能否调通，还要校验各类组合场景、异常场景、输入参数合法性有效性和鸿沟值、接口平安、接口性能等。大部门同窗的接口测试普及存在两个问题，一是场景太浅，另一个是断言不敷。前者形成测试范畴有局限，后者是对测试成果校验不敷。只校验了响应码的接口测试是无意义的，也倒霉于继续集成和继续摆设。
那么接口测试用例若何设想呢。从输入、处置逻辑、输出三部门动手。输入就是各类参数类型及组合的校验，如对数值类型，通过负数、0、小数、99999999999999999等，前端可能过滤掉了那些输入，但是在接口层仍是要做校验，出格是对金额来说。对输入的测试能够用等价类、鸿沟值、断定表、因果图等办法来阐发。关于输出，则是要笼盖各类响应和返回成果，一般的、异常的、特殊的、失败的情状等等。
我想讨论的，是第二部门，营业逻辑。各人城市对接口做一般场景的测试，也会做参数校验的测试，但是不晓得若何连系营业做接口测试。我们晓得在营业流程中，是用户/后台的一些操做，引起数据或者形态的改动，然后引申出各个查抄点。好比用户还款，还清了最初一期，那么那个操做的成果需要列出来：好比更新应收台账、更新回款笔录、更新还款形态、恢复额度;我们的查抄点也要列出来：在客户端查抄待还列表、查抄提现笔录、查抄卡片形态，以及在后台查抄各个表的数据。那些就是能够提赐与接口测试的。因为营业流程有良多条线，场景不只只要一个支流程，那个还清最初一笔就是一个场景，除了要校验接口响应中的成果，还要到数据库校验各个值，同时能够通过其它接口，如再次挪用还款接口会还款失败，挪用额度查看接口额度已回恢复，查对待还列表接口形态为已还清。要在接口测试中实现比力全的场景和校验点，需要提早把checklist列出来，详细的测试用例能够不需要，但是checklist必然要有。总结起来就是通过响应成果停止校验、到数据库停止校验、通过其它接口校验。
接口测试的营业场景若何梳理呢。在app或者平台上可能限造了我们的操做，但是接口差别，只要我们愿意，我们能够设想各类挨次、各类次数的场景，当然都是要和营业逻辑有关系的。根据形态差别，我们能够测试当用户处于未登录、未绑卡、未告贷形态的时候的一些操做;根据操做途径差别，我们能够让用户通过微信、付出宝、银行卡付出;根据营业规则差别，能够测试不成部门还款/提早还款的产物可否停止部门还款/提早还款、无该优惠的用户群可否利用该优惠券;根据操做次数差别，我们能够测试用户反复绑卡、反复提现、反复还款;根据操做挨次差别，我们能够测试先收到优惠券再还款、还款中收到优惠券;根据数据差别，能够设想差别期数、差别金额的提现体例。同时在接口中一样也能够用场景插入、场景替代、场景删除、场景反复、数据替代的体例设想用例。而针对异常场景，用户权限不允许的操做、形态不允许的操做、数据不允许的操做、极限前提下的操做，都能够用上面的体例通过接口停止测试。
把重要的接口测试用例通过脚本实现，不只能够进步回归效率，削减版本优化所需要的测试时间;接入继续集成继续摆设，还能够起到监控的感化，同时能够让优良的代码更快上线。把反复性的工做通过主动化的体例实现，我们才气有更多的时间去做摸索性的测试和其它专项测试。当然接口测试敬服成本仍是需要的，但和UI主动化比拟已经长短常低了。
以上内容为各人介绍了接口测试背后的营业逻辑是什么，本文由多测师亲身撰写，希望对各人有所搀扶帮助。