容量测试可以

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

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

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

嗯嗯，这样可以。 是不是也可以加白名单，对于测试账号默认不调用支付系统，只覆盖基本逻辑。

请教各位有过在线支付接口测试经验的朋友，帮忙回答一下，多谢

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

本文 转自九边的微信公众号，麻烦@Onions将第一作者的名字和文章来源置顶吧，尊重一下原创

飞哥🐮

能分享出来吗？我们最近也在弄

httprunner V3 的文档，可以看这里
https://ontheway.cool/HttpRunner3DocsForCN/

建议使用相对 x,y 控制，找一个稳定的参照物，这样比 x,y 绝对值稳定性高很多

不讲武德啊

wrk

1

可以看看极客时间上，高楼的性能课程

1、新业务

无历史数据可参考。根据业务特点和预估用户数量，将待测试接口分类，分为低并发接口、高并发接口、核心业务必用接口。

低并发接口：QPS 要求最低 10～100（需要评审），同时在线用户量 x 在线用户使用该功能的概率 x 造成并发压力的概率 x 冗余（比如 1 倍）。
高并发接口：同时在线用户量 x 在线用户使用该功能的概率 x 造成并发压力的概率 x 冗余（比如 1 倍），需要评审。
核心业务必用接口：在低并发或高并发接口公式计算的基础上，建议核心业务必用接口性能冗余 2～3 倍，以此增加核心业务的性能稳定性、降低性能风险。

2、历史业务

根据线上历史数据统计，对应业务场景的接口峰值 QPS、接口比例，再结合目标用户与历史用户的比例，计算出性能目标。

每一个点代表采样点，后面有一段没有，是那段时间的采样出现了延迟，或采样没问题图像展示出现了问题。

建议做高并发测试时，使用命令行进行测试，测试后再用 Jmeter 打开查看报告。

因为采样数据比较消耗资源，图像展示同样也非常消耗资源。

使用 Jmeter 非 GUI 模式，可参考：https://testerhome.com/topics/29517#%EF%BC%884%EF%BC%89%E4%BD%BF%E7%94%A8%E9%9D%9EGUI%E6%A8%A1%E5%BC%8F

看错误信息来判断

1

恭喜要有小宝贝出生了，我家去年出生的

哇，赞

即使是技术，也不是都是纯实践性的。
比如很多底层的技术和理论，我们需要了解原理，但是不一定需要实践。

因为 1+1=2 的理论，不需要咱们去实践强化技术什么的。

我想从这些书中，更多的是得到思考方法或方向，比如你看飞哥（高飞）的文章，并不需要全部实践一遍，但是通过文章中的思路或知识点，可以作为参考，也可以作为字典。

从公众号追到这里，打卡

我觉得可以通过写读后感或笔记来强化，持续迭代一本书的读书笔记，可以得到持续的成长

读完觉得有成长吗？