CNWei
6393414ab2
- 为 core 目录下主要模块 (models, context, creator, base_api, exchange, executor) 添加了详细的类和方法 Docstring。 - 新增 docs/架构改进.md 文件。
80 lines
3.8 KiB
Markdown
80 lines
3.8 KiB
Markdown
# 自动化测试框架架构改进建议
|
||
|
||
本文档基于对当前 `InterfaceAutoTest` 项目代码的深度分析，整理了针对框架稳定性、扩展性和易用性的架构改进建议。
|
||
|
||
## 1. 并发执行支持 (Concurrency Support)
|
||
|
||
### 现状问题
|
||
当前 `VariableStore` 使用简单的文件读写 (`extract.yaml`) 来存储全局变量。
|
||
- 在使用 `pytest-xdist` 进行多进程并发测试时，每个进程会加载独立的内存变量副本。
|
||
- 测试结束写回文件时，不同进程会相互覆盖，导致变量提取丢失或数据不一致。
|
||
|
||
### 改进方案
|
||
1. **引入分布式缓存 (推荐)**:
|
||
- 使用 **Redis** 作为变量存储后端。
|
||
- Redis 天然支持原子操作和并发读写，能完美解决多进程数据共享问题。
|
||
2. **文件锁机制 (轻量级)**:
|
||
- 如果不引入 Redis，需在 `VariableStore` 的读写操作中增加 **文件锁 (File Lock)** (如使用 `filelock` 库)。
|
||
- 这会降低并发性能，但能保证数据一致性。
|
||
|
||
## 2. 配置管理增强 (Configuration Management)
|
||
|
||
### 现状问题
|
||
`settings.py` 中存在大量硬编码配置（如 API 映射、日志路径），且缺乏对多环境（Dev/Test/Prod）的动态切换支持。
|
||
|
||
### 改进方案
|
||
1. **多环境配置文件**:
|
||
- 建立 `config/` 目录，分离 `base_config.yaml`, `dev.yaml`, `prod.yaml`。
|
||
- 运行时通过环境变量 `ENV=prod` 加载对应配置并合并。
|
||
2. **环境变量集成**:
|
||
- 使用 `.env` 文件管理敏感信息和基础路径。
|
||
- 利用 `python-dotenv` 在项目启动时加载环境变量。
|
||
|
||
## 3. 扩展性与钩子机制 (Extensibility & Hooks)
|
||
|
||
### 现状问题
|
||
`WorkflowExecutor` 的执行逻辑（准备 -> 请求 -> 后处理）是固定的。如果需要添加自定义逻辑（如请求签名加密、复杂的响应解密），目前很难插入。
|
||
|
||
### 改进方案
|
||
在执行器中引入 **Hooks (钩子)** 机制，允许注册回调函数：
|
||
- `before_request(request_data)`: 请求发出前调用，用于修改 Header、计算签名。
|
||
- `after_response(response)`: 收到响应后调用，用于全局解密、统一错误码判断。
|
||
- `before_case(context)` / `after_case(result)`: 用例级别的 setup/teardown。
|
||
|
||
## 4. 安全性管理 (Security)
|
||
|
||
### 现状问题
|
||
敏感数据（如密码、SecretKey）可能明文写在 YAML 用例中。
|
||
|
||
### 改进方案
|
||
扩展 `Exchange` 类的变量替换逻辑，增加对环境变量的读取支持：
|
||
- **语法示例**: `password: ${ENV:DB_PASSWORD}`
|
||
- 在运行时从系统环境变量中读取，避免将其提交到代码仓库。
|
||
|
||
## 5. 可观测性增强 (Observability)
|
||
|
||
### 现状问题
|
||
虽然 `Session` 类中有日志记录，但在高并发或海量日志场景下，难以串联单个用例的完整执行链路。
|
||
|
||
### 改进方案
|
||
1. **全链路 Trace ID**:
|
||
- 在用例开始执行时生成唯一的 `trace_id`。
|
||
- 将其注入到 `logging` 的 `Extra` 信息中，使其出现在每一行日志里。
|
||
- 同时将 `trace_id` 添加到 HTTP 请求头中（如 `X-Trace-Id`），便于服务端排查。
|
||
2. **结构化日志**:
|
||
- 考虑使用 JSON 格式输出日志，便于接入 ELK 等日志分析系统。
|
||
|
||
## 6. 代码健壮性 (Robustness)
|
||
|
||
### 修复建议
|
||
- **属性一致性**: 检查 `core/executor.py` 中的 PO 模式反射逻辑，确保属性访问与 `core/models.py` 定义一致。
|
||
- `ApiActionModel` 定义了 `module` (alias=`class`)。
|
||
- 确保执行器中使用 `action.module` 而非 `action.api_class`，防止 `AttributeError`。
|
||
|
||
---
|
||
|
||
**实施路线图建议**:
|
||
1. 优先修复代码健壮性问题（属性一致性）。
|
||
2. 实施配置管理增强，便于环境隔离。
|
||
3. 引入 Redis 或文件锁解决并发问题。
|
||
4. 逐步完善 Hooks 和 Trace ID。 |