# 执行计划 - 事务处理时间（Transaction Time）

> **关联 PRD**：`_PRD_事务处理时间TransactionTime.md`
> **创建日期**：2026-08-21
> **预计总工时**：4 天

---

## 一、执行概述

本计划将 PRD 中的「事务处理时间」功能分为 4 个 Phase 实施：

1. **Phase 1**：数据模型扩展 + 后端事务执行引擎（1.5 天）
2. **Phase 2**：报告数据结构 + API 扩展（0.5 天）
3. **Phase 3**：前端任务配置 UI（步骤编辑器）（1 天）
4. **Phase 4**：报告展示（瀑布图 + 步骤明细）+ 联调测试（1 天）

每个 Phase 完成后可独立验收，Phase 1 是后续所有 Phase 的基础。

---

## 二、任务分解

### Phase 1：数据模型扩展 + 后端事务执行引擎

**目标**：扩展 PerformanceTask 增加 steps 字段，实现多步骤事务执行引擎。

| # | 任务 | 关键文件 | 验收标准 |
|---|------|---------|---------|
| 1.1 | PerformanceTask 模型增加 `steps` 字段（JSON, nullable） | `backend/app/models/performance.py` | steps 列存在，to_dict() 输出含 steps |
| 1.2 | 数据库迁移（SQLite ALTER TABLE 增加 steps 列） | `backend/app/database.py` 启动时自动迁移 或 `backend/scripts/migrate_add_steps.py` | 旧库升级后 steps 列存在，默认 NULL |
| 1.3 | TaskCreate/TaskUpdate schema 增加 `steps` 字段 | `backend/app/schemas/performance.py` | 可接收 steps 列表，校验每步骤含 url/method |
| 1.4 | TemplateResolver 扩展支持 `{{captured.key}}` 变量 | `backend/app/executors/template_resolver.py` | 解析 `{{captured.token}}` → shared_context["token"] |
| 1.5 | 新增 `_send_transaction` 方法：按步骤顺序执行 | `backend/app/executors/performance_executor.py` | 顺序执行 steps，每步骧独立记录指标 |
| 1.6 | MetricsCollector 扩展：每步骤指标 + 事务总耗时统计 | `backend/app/executors/performance_executor.py` | summary() 返回 step_metrics 列表 + transaction_time 统计 |
| 1.7 | _worker 逻辑分叉：steps 有值走事务流程 | `backend/app/executors/performance_executor.py` | steps=None 走原 _send_request（完全兼容） |
| 1.8 | 事务级断言与成功判定 | 同上 | 所有步骤成功 → 事务成功；任一步骤失败 → 事务失败 |

**验收方式**：通过 Swagger UI 创建含 2 个步骤的任务并执行，检查报告数据中 step_metrics 存在且正确。

---

### Phase 2：报告数据结构 + API 扩展

**目标**：事务执行结果落库，报告 API 返回事务时间数据。

| # | 任务 | 关键文件 | 验收标准 |
|------|------|---------|---------|
| 2.1 | PerformanceTask 模型增加事务结果字段：`transaction_summary`（JSON） | `backend/app/models/performance.py` | 存储每步骤统计汇总 |
| 2.2 | 服务层执行完成后写入 transaction_summary | `backend/app/services/performance_service.py` | 执行完成后 step 统计数据落库 |
| 2.3 | 报告 API 返回 transaction_summary | `backend/app/routers/performance.py` | GET /api/performance/report/{taskId} 响应含 transactionSummary |
| 2.4 | 报告 schema 增加 transactionSummary 字段 | `backend/app/schemas/performance.py` | PerformanceReportResponse 含 step_metrics 列表 |

**验收方式**：执行多步骤事务后，GET /api/performance/report/{taskId} 返回完整事务数据。

---

### Phase 3：前端任务配置 UI（步骤编辑器）

**目标**：任务创建/编辑弹窗支持多步骤事务配置。

| # | 任务 | 关键文件 | 验收标准 |
|------|------|---------|---------|
| 3.1 | TransactionStep TypeScript 类型定义 | `frontend/src/types/performance.ts` | TransactionStep 接口与后端 schema 对应 |
| 3.2 | 任务表单增加「任务类型」切换（单接口/多步骤） | `frontend/src/views/performance/TaskList.vue` | 切换后显示不同配置区域 |
| 3.3 | 步骤列表编辑器组件 | `frontend/src/views/performance/TaskList.vue`（内嵌）或独立组件 | 可添加/删除/上下移动步骤 |
| 3.4 | 每步骤配置表单（URL/Method/Headers/Body/断言/捕获） | 同上 | 每步骤可独立配置完整请求参数 |
| 3.5 | 步骤间变量引用提示 | 同上 | 显示可用 captured 变量提示（下拉选择已配置的 capture key） |
| 3.6 | 提交时组装 steps 数据 | 同上 | 创建/更新请求 body 含 steps 数组 |

**验收方式**：在前端创建一个含 3 个步骤（登录→查询→下单模拟）的事务任务，保存后数据库中 steps 字段正确。

---

### Phase 2（Phase 4）：报告展示 + 联调测试

**目标**：报告页展示事务时间瀑布图和步骤明细，端到端联调。

| # | 任务 | 关键文件 | 验收标准 |
|------|------|---------|---------|
| 4.1 | ReportPanel 增加事务模式标识 | `frontend/src/views/performance/ReportPanel.vue` | 事务任务显示「多步骤事务」标签 |
| 4.2 | 事务时间瀑布图（ECharts 自定义系列） | 同上 | 各步骤耗时条形堆叠图，含成功/失败颜色标识 |
| 4.3 | 步骤耗时明细表 | 同上 | 表格展示步骤名/方法/URL/耗时/状态码/成功/错误 |
| 4.4 | MonitorPanel 事务时间趋势图（可选） | `frontend/src/views/performance/MonitorPanel.vue` | 实时展示事务 P50/P90/P95 趋势 |
| 4.5 | 端到端联调测试 | 全部相关文件 | 创建 → 执行 → 监控 → 报告全流程正常 |
| 4.6 | 向后兼容验证 | 现有单接口任务 | 旧任务（无 steps）执行、报告完全正常 |
| 4.7 | 前端构建验证 | `frontend/` | npm run build 无错误 |

**验收方式**：端到端流程——创建多步骤事务任务 → 执行 → 实时监控 → 查看报告瀑布图 → 旧任务回归验证。

---

## 三、验收标准总览

| 验收项 | 对应 Phase |
|--------|-----------|
| PerformanceTask.steps 字段存在且向后兼容 | Phase 1 |
| 多步骤任务按顺序执行，每步骤独立计时 | Phase 1 |
| steps=None 的旧任务执行行为完全不变 | Phase 1 |
| `{{captured.key}}` 变量在后续步骤正确解析 | Phase 1 |
| 事务总耗时 = 各步骤耗时之和 | Phase 1 |
| 报告 API 返回 step_metrics 事务数据 | Phase 2 |
| 前端可配置多步骤事务任务 | Phase 3 |
| 报告页展示事务时间瀑布图 | Phase 4 |
| 端到端流程全部正常 | Phase 4 |
| 旧任务回归无影响 | Phase 4 |

---

## 四、测试计划

### 单元测试
- TemplateResolver `{{captured.key}}` 解析测试
- MetricsCollector 事务级统计测试

### 集成测试
- 多步骤任务创建 → 执行 → 报告查询全流程
- 步骤失败策略（失败即终止）验证
- 旧单接口任务回归测试

### 手动测试
- 前端步骤编辑器交互
- 报告瀑布图渲染
- 与真实被测系统（5.44）联调

---

## 五、风险评估

| 风险 | 影响 | 缓解措施 |
|------|------|---------|
| 步骤间数据传递失败导致后续步骤全错 | 事务成功率骤降 | 变量未定义时记录警告并按原样发送，步骤级错误统计可见 |
| 事务模式下 TPS 语义变化 | 用户误解指标 | 报告中明确标注：事务模式下 TPS = 每秒事务数（非请求数） |
| 长事务占用协程 | 并发下降 | 事务超时 60s 默认配置，超时中断 |
| SQLite 存储步骤明细数据量大 | 数据库膨胀 | transaction_summary 只存汇总统计，不存每事务明细 |
| 前端步骤编辑器复杂度高 | 开发周期延长 | 复用现有断言/捕获配置组件，第一版不做拖拽排序（上下移动按钮代替） |

---

## 六、后续工作

- [ ] Phase 1-4 实施完成后更新 CLAUDE.md 当前进度
- [ ] 更新 HANDOFF_性能测试.md 交接文档
- [ ] Git 提交（Conventional Commits）
- [ ] 部署到 5.60 服务器（如需要）

---

## 七、附录

### 关键数据流

```
前端创建多步骤任务（steps 数组）
    ↓
POST /api/performance/tasks → 落库 steps
    ↓
执行：POST /api/performance/tasks/{id}/run
    ↓
PerformanceExecutor.execute()
    ├── steps 为空 → _send_request（原逻辑）
    └── steps 有值 → _send_transaction
        ├── Step1 发送 → 捕获 token → ctx
        ├── Step2 发送（{{captured.token}} 替换）→ 捕获 id → ctx
        └── Step3 发送（{{captured.token}} + {{captured.id}} 替换）
    ↓
MetricsCollector.summary() 含 step_metrics
    ↓
服务层写库 transaction_summary
    ↓
GET /api/performance/report/{taskId} → 前端渲染瀑布图
```

### 参考文件

| 文件 | 用途 |
|------|------|
| `backend/app/executors/performance_executor.py` | 现有执行引擎（_send_request / _worker / MetricsCollector） |
| `backend/app/executors/template_resolver.py` | 现有模板解析（扩展 captured 变量） |
| `backend/app/models/performance.py` | PerformanceTask 模型（扩展 steps 字段） |
| `frontend/src/views/performance/TaskList.vue` | 任务编辑弹窗（扩展步骤编辑器） |
| `frontend/src/views/performance/ReportPanel.vue` | 报告页（增加瀑布图） |

---

*本文档由 prd-plan skill 生成，关联 PRD：`_PRD_事务处理时间TransactionTime.md`*
