如何实现第三方支付功能mock之 Mock方式调研篇

     做支付相关的测试有些年头了，对接的第三方挺多，原来接支付渠道的时候，像宝付支付，连连支付，测试环境都有自己的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

优点：自由度高，易于接入自动化，完成以后，可以一直用

缺点：有一定的代码能力要求，服务运行需要维护，每次使用前都需要保证服务启动中