作者|田西西
概 述 0 1背景支付的上游业务在测试过程中难免会遇到支付场景,因支付场景需要和第三方交互,单纯通过接口无法绕开。通过改库完成支付又面临账户、记账等逻辑复杂,数据库需要更改的范围过大。
支付中心打款、退款异常取回产品化,测试需要构造各种异常场景,如微信注销、银行卡注销、微信未实名等,真实构造数据周期长且无法保证随用随有。
渠道灾备需要模拟三方服务不可用,如三方出现500、502错误。
支付对账业务需要下载三方账单与平台对账,使用线上数据测试,数据量庞大,对账准确性难以保证。
其他需要和第三方交互的业务也面临同样的困境,比如三方各种异常数据的构造。
前期满足各种异常场景的构造,将难以测试的业务场景变为可测。
中期降低部署成本与已有环境平台打通。
后期降低业务接入的开发成本。
以支付中心为例,支付中心与三方服务的交互统一通过网关服务进行。
网关服务启动加载公钥,并通过httpclient与三方进行交互。
方案1:在服务端配置host,将第三方支付域名指定至mock服务器。
优点:配置简单,对被测服务没有侵入
缺点:支付请求基本都是https协议&