基准测试工具之你不知道的两三事 | 14. 一份可复用的基准测试方案模板

走到这里，我们已经讨论了写入、读写混合、乱序、接口、正确性、单机与集群，也知道一轮结果应该怎样保存。真正开始测试时，仍然可能面对一个现实问题：这些原则怎样组织成一份可以执行的方案？

一份好的测试方案不是参数清单，而是一份实验契约。它提前规定要回答的问题、唯一变量、固定条件、正确性门禁、运行矩阵和结论边界。这样，无论执行者是谁，最后得到的结果都在回答同一个问题。

这一篇给出一份可以直接复制和裁剪的基准测试方案模板。模板中的数值和结果全部使用“待填”，应根据真实业务和实际运行填写。

1. 一份完整方案由什么组成

其中最容易被省略的是“硬门槛”和“结论边界”。如果没有预先规定什么情况下结果无效，测试者很容易在看到数据后临时调整判断标准；如果没有边界，又容易把一个纯写结论扩展成对整个数据库的评价。

2. 测试方案基本信息

复制下面的表格，先建立方案身份。

字段	内容
方案名称	待填
方案版本	待填
负责人	待填
创建 / 更新时间	待填
测试目的	待填
被测对象	待填，例如数据库版本、写入接口或部署方式
计划时间	待填
结果归档位置	待填

测试目的应写成可验证的问题，而不是“测试一下性能”。例如：

• 在固定写入负载下，新版本是否相对基线出现稳定退化？
• 在正确性通过的前提下，哪一种写入接口更满足当前 P99 目标？
• 数据库从单机扩展到三节点后，能否承载按计划增加的总负载？

3. 测试问题、假设和结论边界

项目	待填写内容
核心问题	本轮只回答什么？
对比对象	A、B 或基线版本分别是什么？
唯一变量	哪一个条件允许变化？
固定条件	哪些环境、数据与负载必须一致？
预期现象	测试前的假设是什么？
不覆盖范围	哪些负载、部署或功能不在本轮结论内？

假设不是结论。它可以帮助选择指标，但不能决定怎样解释结果。若实际数据不支持假设，应保留原始结果并修改判断，而不是调整配置直到出现想要的数字。

4. 硬门槛与判断标准

测试前先规定哪些结果没有资格参与比较。

门槛	目标或通过条件	证据来源	未通过如何处理
正确性	待填	验证日志、数量核对、抽样查询	结果无效，先定位原因。
失败率	待填	Benchmark 结果与日志	不进入性能排名。
P99	待填	分操作延迟矩阵	标记不满足业务目标。
运行完整性	正常完成预热和正式阶段	进程日志与时间线	重跑，不与完整轮次混合。
客户端余量	待填	客户端 CPU、网络、GC	增加或拆分发压端后复测。

门槛应来自业务约束、SLA 或测试目标，不能在看到结果后为了保留某个候选临时放宽。

5. 环境清单

5.1 压测客户端

项目	配置
Benchmark 版本 / commit	待填
Java 版本	待填
客户端机器数量	待填
每台 CPU / 内存 / 网络	待填
多实例编号与设备区间	待填，不使用多实例则写“不适用”
启动方式	待填

5.2 数据库服务端

项目	配置
数据库及版本	待填
单机 / 集群	待填
节点数量与角色	待填
副本、分片和一致性配置	待填
每节点 CPU / 内存 / 磁盘 / 网络	待填
关键服务端参数	待填
数据库初始状态	空库 / 固定历史数据 / 其他，待填

5.3 环境控制

检查项	约定
客户端与服务端是否独占	待填
后台任务和定时任务	待填
各机器时钟同步	待填
缓存状态	冷 / 热 / 不控制，待填并说明
每轮是否清库或恢复快照	待填
监控采样间隔	待填

6. 数据模型和数据规模

维度	配置 / 说明
数据模型	树模型 / 表模型 / 其他，待填
DEVICE_NUMBER	待填
SENSOR_NUMBER	待填
测点数据类型	待填
时间戳精度与间隔	待填
总时间范围	待填
标签或属性基数	待填
初始历史数据量	待填
输入数据来源与校验值	待填

这里记录的是逻辑数据，而不是只记录最终磁盘占用。同样的数据点数，如果设备基数、测点类型和时间分布不同，写入与查询路径也可能完全不同。

7. 工作负载定义

维度	配置 / 说明
BENCHMARK_WORK_MODE	待填
OPERATION_PROPORTION	待填，并解释每类操作的业务含义
DATA_CLIENT_NUMBER	待填
DEVICE_NUM_PER_WRITE	待填
BATCH_SIZE_PER_WRITE	待填
OP_MIN_INTERVAL	待填
INTERVAL_BETWEEN_WRITE_BATCH	待填
乱序比例与乱序形态	待填，不测试则写 0 / 不适用
查询设备数与测点数	待填
查询时间窗口与最近数据比例	待填
运行停止条件	总操作数 / 运行时间 / 其他，待填

操作比例只描述“抽到哪类操作的概率或比例”，还需要把每类查询的范围、设备数、测点数和数据冷热程度写清楚。否则，同样的读写比例仍可能产生完全不同的压力。

8. 变量与固定项

这张表是公平比较的核心。

类型	参数或条件	取值	说明
唯一变量	待填	待填	本轮主动改变的对象。
固定项	数据规模	待填	所有候选一致。
固定项	工作负载	待填	所有候选一致。
固定项	客户端资源	待填	所有候选一致。
固定项	服务端资源	待填	所有候选等价或说明差异。
固定项	预热和运行时长	待填	所有候选一致。
不可避免差异	待填	待填	说明为什么存在，以及如何限制影响。

不同数据库的内部参数不可能逐字相同。公平的重点，是外部业务语义、可用资源和测试过程一致，并公开不可避免的内部差异。

9. 运行矩阵

不要边跑边决定下一轮叫什么。提前给每个场景和重复轮次编号。

场景编号	场景	候选	唯一变量值	预热	正式运行	重复次数	结果状态
W01	顺序纯写基线	A / B	待填	待填	待填	待填	待测
M01	读写混合	A / B	待填	待填	待填	待填	待测
O01	乱序写入	A / B	待填	待填	待填	待填	待测
C01	并发扫描	A / B	待填	待填	待填	待填	待测
B01	批大小扫描	A / B	待填	待填	待填	待填	待测
S01	单机 / 集群扩展	A / B	待填	待填	待填	待填	待测

不是每次评估都要运行整张表。应根据核心问题删除无关场景，但不能在运行结束后只保留对某个候选有利的场景。

10. IoT Benchmark 配置骨架

下面的片段只展示方案中常用的配置入口，不提供通用推荐值。使用时应以当前版本的 config.properties 为准，并把“待填”替换为有效取值。

# 被测对象
DB_SWITCH=待填
BENCHMARK_WORK_MODE=待填

# 数据模型与规模
DEVICE_NUMBER=待填
SENSOR_NUMBER=待填

# 操作与发压
OPERATION_PROPORTION=待填
DATA_CLIENT_NUMBER=待填
DEVICE_NUM_PER_WRITE=待填
BATCH_SIZE_PER_WRITE=待填
OP_MIN_INTERVAL=待填
INTERVAL_BETWEEN_WRITE_BATCH=待填

# 多实例测试；单实例时关闭
BENCHMARK_CLUSTER=false
BENCHMARK_INDEX=0

# 结果与日志
TEST_DATA_PERSISTENCE=CSV
CSV_OUTPUT=true
REMARK=待填_请勿使用特殊字符
IS_QUIET_MODE=false
LOG_PRINT_INTERVAL=待填
RESULT_PRINT_INTERVAL=待填

实际执行前应保存一份完整配置，而不是只保存这段参数摘要。完整配置可以防止某个默认值在版本间变化却未被注意。

11. 标准运行流程

执行约定应明确：

1. 每轮开始前数据库处于什么状态；
2. 预热数据是否计入正式结果；
3. 正式运行按时间还是操作数结束；
4. 重复轮次之间是否重启、清库或等待后台任务结束；
5. 多实例如何同时启动，以及使用哪个公共有效时间窗口；
6. 失败后是立即停止、继续记录还是重试整轮。

12. 正确性门禁记录

检查项	预期	实际	证据文件	结果
写入成功量	待填	待测	待填	待测
设备、行和点数	待填	待测	待填	待测
时间戳与设备定位	无差异	待测	待填	待测
类型与具体值	无差异	待测	待填	待测
关键查询结果	与参考结果一致	待测	待填	待测
验证错误日志	无未解释错误	待测	待填	待测

只有门禁通过的轮次才进入性能统计。若工具汇总显示失败数为 0，但验证日志存在值差异，仍应判定正确性未通过。

13. 指标与结果表

13.1 客户端结果

运行编号	操作	成功点数	失败点数	吞吐量	平均延迟	P99	正确性
待填	待填	待测	待测	待测	待测	待测	待测

13.2 资源结果

运行编号	节点	CPU	内存	磁盘读写	网络	GC / 其他	异常说明
待填	待填	待测	待测	待测	待测	待测	待填

13.3 多轮汇总

场景	候选	吞吐量范围	P99 范围	失败情况	资源瓶颈	是否满足目标
待填	待填	待测	待测	待测	待分析	待判断

多轮汇总优先报告范围和波动，不用“最好的一次”代替稳定能力。如果轮次之间差异很大，应先解释原因，再决定是否增加重复次数。

14. 归档清单

测试结束前逐项勾选：

• 已保存本轮实际使用的完整 Benchmark 配置；
• 已记录 Benchmark、驱动和数据库不可变版本标识；
• 已保存与结论相关的服务端配置；
• 已保存完整客户端和服务端日志；
• 已保存最终 CSV 与过程测量结果；
• 已保存客户端和每个服务端节点的原始监控数据；
• 已保存正确性验证日志与预期量核对；
• 已记录预热、正式运行、异常和人工操作时间；
• 已为输入数据和关键文件生成校验值；
• 已写明结果有效性、异常和不覆盖范围。

15. 结论模板

最终结论可以按下面四句话组织：

在【环境、版本、部署】和【数据、工作负载】条件下，
本轮以【唯一变量】比较了【候选对象】。
通过正确性门禁的多轮结果表明：【吞吐、P99、失败与资源的实际范围】。
因此当前证据支持【选择、回归或调优判断】，但不覆盖【未测试场景】。

如果证据不足，也可以明确写：“当前轮次波动较大，尚不能形成稳定排名；需在固定某项条件后补测。”不下结论本身也是一种有效结论。

16. 小结

一份可复用的 IoT Benchmark 测试方案，应把业务问题翻译为硬门槛、环境、数据模型、工作负载、唯一变量和运行矩阵，再用正确性门禁、指标表和归档清单约束执行过程。

模板不是为了让所有测试长得一样，而是确保每个数字都有来源、每个比较都有控制变量、每个结论都有边界。

系列文章

1. 第一篇：数据库基准测试工具是什么
2. 第二篇：从一次时序数据库写入测试开始
3. 第三篇：如何模拟线上写入负载
4. 第四篇：如何读懂测试结果波动
5. 第五篇：什么是读写混合负载
6. 第六篇：如何模拟线上读写混合负载
7. 第七篇：怎样做一场公平的性能对比
8. 第八篇：怎样找到并发与批大小的合理区间
9. 第九篇：如何模拟乱序写入
10. 第十篇：不同写入接口该怎样比较
11. 第十一篇：性能测试与正确性验证有什么区别
12. 第十二篇：单机测试与集群测试有什么不同
13. 第十三篇：怎样保存和复盘一轮测试
14. 第十四篇：一份可复用的基准测试方案模板