做支付相关的测试有些年头了,对接的第三方挺多,原来接支付渠道的时候,像宝付支付,连连支付,测试环境都有自己的mock规则,传入特定的金额或者银行卡号,会返回相应的结果,没有mock的支付渠道,像余额不足、支付失败、支付次数超限等场景倒是好做,银行卡存在风险、卡注销等场景,总不可能为了测试个场景,就真的去把银行卡弄风险了,把卡注销了是吧,但是身为一个有职业操守的测试人员,这些场景不做又觉得不太妥当,每次让开发人员写死固定返回值又麻烦,那我们测试自己能做什么?
答案是接口mock,当然,mock的本质是自己写一个接口,然后规定返回内容,压根就没调到第三方,最好用在一些比较难以制造的场景、或者自动化中,上线前,肯定还是需要真实地去老老实实地测试大多数的真实场景,不能纯mock进行测试,臆想第三方的返回,测试过程中如果过分依赖Mock,mock测试的场景失去了真实性,可能会导致在后续的系统测试时才发现bug,会使得缺陷发现的较晚,造成后续修复成本更大
实现接口mock有很多种方法,大致分几类:
第一种:上面提到的让开发写死在代码里(某个接口被调用时,强制返回想要的结果,或者请求本地的 JSON 文件)
优点:快,简单,适用大部分场景
缺点:写一些与真实项目或业务无关的代码,测试完成后,需要删除,代码层面的改动也意味着不可控的风险,并且会影响环境,接口越多越容易出错,需要重新发布服务才能结束mock,需要侵入业务代码、重新发布服务才能生效配置的方式是极不友好的,而且,Mock 效果并不好,也不够灵活。
第二种:抓包工具拦截,Fiddler,Charles等都提供了mock和断点功能,当捕获到特定的网络请求时进行拦截,将其替换为我们需要的 Mock 数据,或者断点手动修改其请求和返回,适合链路不长,临时需求的场景
优点:真实性强,适用大部分能抓包的接口
缺点:方式操作步骤相对繁琐,不方便统一配置,无法参与自动化测试。
第三种:大部分的接口管理工具都会提供的接口mock的功能,如postman、yapi、Eolink
优点:
- 配置强大,一般平台已经提供了非常丰富的封装,几乎适用于任何项目和场景。
- 接口管理与 Mock 一体,使用起来更方便。
- 通常提供了丰富的数据生成规则,拿来直用,生成的数据更接近真实
缺点:要花钱(大部分不免费),要出人(私有化部署依赖团队基建,需要运维人员配合搭建),
第四种:自己搭一个服务,如使用python的Flask自己写一个,或者使用java的Moco
优点:自由度高,易于接入自动化,完成以后,可以一直用
缺点:有一定的代码能力要求,服务运行需要维护,每次使用前都需要保证服务启动中