testing驱动分布式事务压测场景测试与案例实战项目部署 - 第4节
4.1 TDD 核心流程：红-绿-重构循环
在分布式事务压测场景中引入 TDD（Testing-Driven Development），本质是将压测场景的预期行为作为测试用例先行定义，再通过压测执行验证系统是否满足该行为。TDD 的经典“红-绿-重构”循环在压测领域同样适用，只是测试对象从单元函数变为分布式事务的吞吐、一致性、超时回滚等非功能性指标。
4.1.1 红-绿-重构循环在压测中的映射
| TDD 阶段 | 压测场景中的含义 | 典型产出物 |
|---|---|---|
| 红（Red） | 编写一个预期会失败的压测用例，定义目标 SLA（如 TPS ≥ 500、P99 延迟 ≤ 200ms、零数据不一致） | 压测场景 YAML / 断言脚本 |
| 绿（Green） | 运行压测，使系统刚好满足该 SLA，通常需要调整资源、配置或代码 | 压测通过报告 + 配置变更记录 |
| 重构（Refactor） | 在不降低 SLA 的前提下，优化压测脚本、数据隔离策略或监控埋点，提升可维护性 | 重构后的压测场景库 + 版本标签 |
关键认知：压测中的“红”不是系统崩溃，而是断言失败。例如：预期 TPS ≥ 500，实际只有 320，则测试红。此时不应盲目调大并发，而应定位瓶颈（数据库连接池、网络带宽、事务日志刷盘）。
4.1.2 TDD 压测循环流程图
下图展示了 TDD 驱动压测场景开发的完整循环，每个阶段都对应明确的输入与验证标准。
4.2 用测试定义压测场景：从断言到场景库
传统压测往往先写脚本再观察结果，而 TDD 要求先定义断言。在分布式事务压测中，断言不仅包括吞吐和延迟，还必须包含数据一致性校验和事务状态收敛。
4.2.1 压测场景的测试定义模板
每个压测场景对应一个测试用例，包含以下四个核心部分：
- 场景元数据：事务模式（TCC / Saga / XA）、参与者数量、超时配置。
- 负载配置：并发用户数、Ramp-up 周期、持续时间。
- 断言规则：TPS 下限、P99 延迟上限、零脏数据、事务最终状态一致。
- 清理与隔离：每次压测前后的数据清理脚本、数据库快照策略。
示例：TCC 事务压测场景定义（伪代码）
// 场景：TCC 分布式事务 - 账户转账
// 目标 SLA：TPS ≥ 300，P99 ≤ 150ms，零资金不一致
scenario "tcc_account_transfer" {
mode: "TCC"
participants: ["account-service-a", "account-service-b"]
timeout: 5000ms
load {
users: 100
rampUp: 30s
duration: 5m
}
assert {
tps >= 300
p99_latency <= 150ms
error_rate < 0.1%
// 一致性断言：转账后 A + B 总余额不变
consistency: "select sum(balance) from accounts" == baseline
}
cleanup {
sql: "delete from transaction_log where run_id = ${runId}"
snapshot: "restore accounts table"
}
}4.2.2 红-绿-重构在压测场景中的具体操作
| 步骤 | 操作内容 | 典型失败原因 | 通过标准 |
|---|---|---|---|
| 红 | 编写包含断言的新压测场景，执行压测 | TPS 不足、延迟超限、数据不一致 | 至少一个断言失败 |
| 绿 | 调整系统配置（连接池、线程数、批处理大小）或修复代码 Bug | 调整后仍不达标，需进一步定位瓶颈 | 所有断言通过 |
| 重构 | 优化压测脚本结构、提取公共配置、增加监控埋点 | 重构后断言仍通过，但可维护性提升 | 断言不变，代码质量提升 |
4.3 压测场景库的组织与版本管理
当压测场景数量增长到数十甚至上百个时，必须建立场景库来管理。每个场景都是一个独立的测试用例，遵循 TDD 的红-绿-重构循环演进。
4.3.1 场景库目录结构建议
stress-scenarios/
├── scenarios/
│ ├── tcc/
│ │ ├── account-transfer.yaml
│ │ ├── order-payment.yaml
│ │ └── inventory-deduction.yaml
│ ├── saga/
│ │ ├── booking-flow.yaml
│ │ └── compensation-test.yaml
│ └── xa/
│ ├── two-phase-commit.yaml
│ └── recovery-test.yaml
├── asserts/
│ ├── consistency-checks.sql
│ └── latency-thresholds.json
├── data/
│ ├── seed-accounts.csv
│ └── cleanup-scripts/
└── reports/
├── baseline/
└── regression/
避坑提示：不要将压测数据（如 CSV 种子文件）硬编码在场景 YAML 中。应通过
data/ 目录统一管理，并在场景定义中引用外部数据源。这样在重构阶段可以独立更新测试数据而不影响场景逻辑。
4.3.2 场景库与 CI/CD 的集成
每个压测场景在 CI/CD 流水线中对应一个测试阶段。TDD 循环在此处体现为：
- 提交阶段：运行“红”场景，预期失败，确认新场景已正确接入。
- 压测阶段：运行“绿”场景，验证系统是否满足 SLA。
- 回归阶段：运行全部历史场景，确保重构未引入性能退化。
下图展示了场景库在 CI/CD 流水线中的 TDD 集成方式：
4.4 本章小结
- TDD 的红-绿-重构循环完全适用于分布式事务压测场景开发，核心是将 SLA 断言作为测试用例先行定义。
- 每个压测场景应包含元数据、负载配置、断言规则、清理隔离四个部分，形成可重复执行的测试用例。
- 压测场景库需要版本管理和目录结构化，并与 CI/CD 流水线集成，实现自动化红-绿-回归循环。
- 重构阶段重点优化脚本可维护性和数据隔离策略，而非盲目调整性能参数。