写操作，一定不能直接操作表。

• 写操作：建议调用开放接口
• 读操作：可以直接查询数据库

不好意思，因为内容有误，已修复

过奖啦

工具其实是其次的，最重要的是理解性能如何做，如何做有效的性能测试？

可以看看：服务端性能测试 - 入门指南

这个 BUG 主要还是业务逻辑漏洞，需要深入理解业务，就可以测试出来吧

感谢关注

客气啦

这个回帖打💯分

你是问 debugtalk 的博客吗？

看看 debugTalk 的 httprunner 实战开发文章啊，写的非常好。

当然，如果是手把手的实战教程，说实话，给钱人家也不愿意写，容易挨骂。

这个说法非常错误

建议看看渲染原理：详细内容见：Android 流畅度评估及卡顿定位、优化

从图中可以看出，按照刷新率 60FPS 的屏幕举例，当某帧渲染超过 16.66ms 时，屏幕是不会立马绘制当前帧的，会等待下一帧绘制完成，才会显示当前帧。这样这一秒，最高就只有 59FPS 了。

其次，在描述流畅度或帧率相关问题时，用帧。用图会让不懂的人更加误解。

再通用，也不会像母语一样，大家都用同一套东西

未来源，可以借鉴他们的设计思路

之前没有做过中台的测试。建议按照这样的顺序评估是否需要做性能：
（1）服务是否会面对并发场景？
（2）出现并发或高并发时，是否可以忍受服务出现性能问题，甚至崩溃？
（3）如果不能忍受，那就必须要做性能测试了。一方面用于性能评估，另一方面可以提前暴露性能问题，避免早上线上损失。

我觉得性能评估是比较必要的。但是没必要测试整个集群，可以测试集群单元和单实例性能，然后再综合考虑负载损耗，来评估大集群性能。

那有可能是被平均掉的，因为图显示的是 采样周期 每个采样器的平均响应时间。

还有一个关键因素，就是 Response Over Time 的采样周期控制（Group timeline values for 100 ms），当采样周期为 100ms 的时候，图中数值会更接近聚合报告，但是当采样周期为 2000ms 时，就会差距较大。

如下图所示，前一段采样周期是 100ms，后一段采样周期是 2000ms，这样曲线上能显示的值，距离实际值，差距会较大。

从官方文档来看，Response Over Time 将显示每个采样器的平均响应时间。

关于为什么聚合报告和 Response Over Time 的最大时间不一样，我怀疑是这样的：
聚合报告展示的数据，是全量采集数据的展示。Response Over Time 展示的数据是抽样数据。因为 Response Over Time 有这样一个设置：Limit number of points in row to 20 points.
因为显示的数据点数限制，导致 Response Over Time 并不是显示了所有数据。

厉害，我回头尝试一下，这个还真得第一次看到

Locust 是支持的，笔误了。
Jmeter 的方式我理解你意思了，压力使用变量，然后 BeanShell 中修改变量，即可修改压力值。

请教一下，测试期间，如何通过 BeanShell 远程修改变量的值？

方便贴一下相关代码吗？学习一下，第一次见到这样的方式，长见识了。多谢多谢。

快三年前 面试的 CTO，问的是一个算法题（给出思路就行），一个设计测试平台题（画出结构图）

我们也做了几个版本的遍历了，觉得携程的逻辑更高效，可以看一下：Trip.com 智能自动化探索测试

楼主没有试用字节开源的fastBot？

好文