付钱测啊

测试环境 mock（能发出、且参数正确，你的系统就没问题了。剩下的你的系统也管不了）
线上环境 真人花真钱做 + 灰度小流量测试 。

请教一下恒捷，如果对在线支付做正式环境的拨测的话，是不是只有白名单一条路走了

不知道你这里的白名单，具体是指什么白名单？

我们之前支付环节不怎么做拨测，主要做监控 + 预警。主要原因是一般为了保障高可用会对接多个支付渠道，而支付渠道不同，背后走得第三方系统乃至自家系统配置都不少差异，要通过拨测覆盖成本不低。不如做支付失败数量，或者支付成功订单和前一天环比数量波动情况的预警性价比高。

我理解的白名单，对于测试账号默认不调用支付系统，只覆盖基本逻辑。

这种可以做的，不过这样只校验到自己的系统，可能作用不是特别大。

按我之前的经验，一般支付系统最常见的线上问题是外部第三方渠道的问题（比如他们要维护或者出线上问题导致链路不通，然后需要调整配置把这个渠道的流量比例降低到 0），自家系统出了上线变更或者基础设施负荷太大处理不过来外，相对比较少出问题。

嗯嗯，白名单专注于检测自家系统的质量。

关于第三方服务的监测：
（1）通过 UI 自动化（真实支付用例）监测
（2）第三方支付提供测试账号，用于接口拨测；

hmm，做第三方支付服务的监测会比较麻烦，建议优先建设好预警机制，再补充主动检测机制。

你说的这两个，实际实施会遇到一些难点：

1、UI 自动化，有可能支付环节的输入密码都会做一些安全限制避免系统自动输入，这个会提高 UI 自动化的成本。

2、第三方提供测试账号这个，测试环境可能还可能提供。线上正式环境，三方支付一般只是中间商，背后他们还会再连接很多级的第三方系统直到银行的系统，基本上不可能存在能打通全链路的测试账号。

嗯嗯，是的，横捷，请教一下，你们之前的预警或监测机制大概是什么样的啊？

微信支付团队开发了一套独立的仿真测试系统。该系统根据验收用例金额的不同返回不同的响应报文，以满足商户正常功能测试、安全/异常测试及性能测试的需求。
具体可参考：https://www.likecs.com/show-40094.html

支付宝有一个供开发者测试使用的沙箱环境，会提供一个沙箱版的支付宝 app。
具体可参考：https://blog.csdn.net/weixin_42232931/article/details/114589925

比较好奇，对线上支付接口做拨测的目的是什么？
个人感觉，似乎除了验证自家服务在不同地区节点的性能之外没有更多的结论。
在依赖第三方支付接口的情况下，别人对拨测的响应速度无法控制，咱最多只能帮别人发现问题这样子？
如果不打算连带第三方支付接口一起验证，那确实是 mock 掉第三方支付接口即能达到目的。

我们之前的监测预警有点简单暴力，主要是通过定期统计数据库落库数据来做的。

支付相关检测指标大概有：最近 5 分钟的支付发起数、支付成功数、支付失败数。每个指标除了绝对值，还会在曲线图中展示前一天的曲线和今天的曲线。这些指标的数据来源都是实时查询数据库里的数据（为了这个专门弄了个监控系统专用从库），有一个专门的大盘界面可以直接看到所有指标当前值及预警情况。

预警机制：失败数绝对值达到一定数量会直接自动电话预警（这种一般说明是出现严重故障了），成功数/发起数差值百分比达到一定程度会发消息预警。每个预警在大盘里会记录持续时长、跟进人这类信息。

另外，当时因为比较关注线上质量，还弄了一个专门的监控室，招专人排班 7x24 小时值班看大盘指标及预警数据，如果判断认为问题比较严重，人工通知检测指标对应的负责人（大盘系统里每个指标都会登记负责人信息）去排查确认。