调整工程优化文档中的验证策略
- 去除自动化测试与持续集成相关规划内容 - 将测试建设方向调整为人工验证与回归清单 - 同步更新P0任务列表与迭代路线表述
This commit is contained in:
liuwei
@@ -53,22 +53,22 @@
|
||||
- 配置难以安全迁移到多环境部署
|
||||
- 后台权限控制不足时，容易产生误操作与未授权访问问题
|
||||
|
||||
### 3.2 可测试性不足
|
||||
### 3.2 人工验证体系不足
|
||||
|
||||
当前项目已经很大，但自动化测试覆盖明显不足。
|
||||
当前项目已经很大，但还没有形成稳定、固定、可重复执行的人工验证流程。
|
||||
|
||||
主要体现在：
|
||||
|
||||
- 缺少完整的单元测试体系
|
||||
- 缺少核心链路集成测试
|
||||
- 缺少 CI 自动校验流程
|
||||
- 功能越多，回归风险越高
|
||||
- 缺少统一的改动后检查清单
|
||||
- 缺少核心链路的固定回归步骤
|
||||
- 缺少后台功能、消息链路、插件链路的验收模板
|
||||
- 功能越多，人工测试越容易遗漏
|
||||
|
||||
影响：
|
||||
|
||||
- 每次改动都更依赖人工回归
|
||||
- 插件之间联动问题不容易提前暴露
|
||||
- 随着代码规模继续增长，维护成本会快速上升
|
||||
- 每次改动都更依赖临场经验
|
||||
- 插件之间联动问题不容易在第一时间发现
|
||||
- 后续优化越多，回归成本越高
|
||||
|
||||
### 3.3 可观测性不足
|
||||
|
||||
@@ -177,13 +177,13 @@
|
||||
|
||||
### 4.1 先补工程底座，再扩业务上限
|
||||
|
||||
优先处理安全、测试、监控、性能、插件治理，再继续叠加复杂功能。
|
||||
优先处理安全、人工验证、监控、性能、插件治理，再继续叠加复杂功能。
|
||||
|
||||
### 4.2 优先做“能降低长期维护成本”的能力
|
||||
|
||||
例如：
|
||||
|
||||
- 自动化测试
|
||||
- 人工验证清单
|
||||
- 配置治理
|
||||
- 指标与追踪
|
||||
- 插件治理
|
||||
@@ -271,56 +271,34 @@
|
||||
- `admin/dashboard/blueprints/auth.py`
|
||||
- `db/admin_account_db.py`
|
||||
|
||||
### 6.3 自动化测试基线建设
|
||||
### 6.3 人工验证与回归清单
|
||||
|
||||
目标：
|
||||
|
||||
- 为高风险核心链路补齐最基础的质量门
|
||||
- 让每次改动后都有固定、可重复执行的验证步骤
|
||||
|
||||
建议内容：
|
||||
|
||||
- 建立 `pytest` 测试框架
|
||||
- 补充配置解析测试
|
||||
- 补充插件加载测试
|
||||
- 补充消息归档测试
|
||||
- 补充后台登录测试
|
||||
- 引入基本的 mock 和 fixture 机制
|
||||
- 建立“日常改动验证清单”
|
||||
- 建立“消息主链路回归清单”
|
||||
- 建立“后台页面回归清单”
|
||||
- 建立“插件启停与配置修改回归清单”
|
||||
- 建立“上线前人工检查清单”
|
||||
- 为高风险功能补最基础的手工验收步骤说明
|
||||
|
||||
预期收益：
|
||||
|
||||
- 降低后续改动的回归风险
|
||||
- 提高重构信心
|
||||
- 降低人工测试遗漏概率
|
||||
- 让后续优化更有章法
|
||||
|
||||
涉及模块：
|
||||
|
||||
- `test/`
|
||||
- `base/plugin_common/`
|
||||
- `db/`
|
||||
- `docs/`
|
||||
- `admin/dashboard/`
|
||||
- `robot.py`
|
||||
- `plugins/`
|
||||
|
||||
### 6.4 CI 持续集成
|
||||
|
||||
目标：
|
||||
|
||||
- 每次提交自动做基础质量校验
|
||||
|
||||
建议内容：
|
||||
|
||||
- 增加 GitHub Actions 工作流
|
||||
- 自动执行测试
|
||||
- 自动执行基础 lint
|
||||
- 校验关键文档与配置模板是否存在
|
||||
|
||||
预期收益：
|
||||
|
||||
- 让质量校验前置
|
||||
- 减少“提交后才发现明显问题”的情况
|
||||
|
||||
涉及模块：
|
||||
|
||||
- `.github/workflows/`
|
||||
|
||||
### 6.5 系统健康与观测面板
|
||||
### 6.4 系统健康与观测面板
|
||||
|
||||
目标：
|
||||
|
||||
@@ -347,7 +325,7 @@
|
||||
- `main.py`
|
||||
- `utils/ai/`
|
||||
|
||||
### 6.6 消息链路 Trace 能力
|
||||
### 6.5 消息链路 Trace 能力
|
||||
|
||||
目标：
|
||||
|
||||
@@ -674,8 +652,7 @@
|
||||
|
||||
- 配置与密钥治理
|
||||
- 后台安全增强
|
||||
- 自动化测试基线
|
||||
- CI 持续集成
|
||||
- 人工验证与回归清单
|
||||
- 系统健康与观测面板
|
||||
- 消息链路 Trace
|
||||
|
||||
@@ -719,14 +696,14 @@
|
||||
|
||||
1. 配置脱敏与环境变量化
|
||||
2. 后台管理员安全增强
|
||||
3. `pytest` 测试框架搭建
|
||||
4. GitHub Actions 基础工作流
|
||||
5. 插件处理耗时统计
|
||||
6. 消息 trace_id 全链路打通
|
||||
7. 任务执行历史页面
|
||||
8. 插件错误与健康状态页
|
||||
9. 消息表与统计查询索引优化
|
||||
10. 命令帮助系统自动生成
|
||||
3. 人工回归清单模板建立
|
||||
4. 插件处理耗时统计
|
||||
5. 消息 trace_id 全链路打通
|
||||
6. 任务执行历史页面
|
||||
7. 插件错误与健康状态页
|
||||
8. 消息表与统计查询索引优化
|
||||
9. 命令帮助系统自动生成
|
||||
10. 关键配置变更审计
|
||||
|
||||
## 11. 结论
|
||||
|
||||
@@ -735,7 +712,7 @@ ABOT 当前最大的优势是“功能已经足够丰富，且架构已经有平
|
||||
因此，后续优化不建议继续以“堆新功能”为主，而建议转为以下主线：
|
||||
|
||||
- 先提升安全性
|
||||
- 再补测试与观测
|
||||
- 再补人工验证与观测
|
||||
- 再做插件治理与任务治理
|
||||
- 最后继续扩展产品能力
|
||||
|
||||
|
||||
Reference in New Issue
Block a user