75 lines
5.6 KiB
Markdown
75 lines
5.6 KiB
Markdown
# 活动上下文
|
||
|
||
## 当前工作焦点
|
||
|
||
我们正在维护和改进DDMS合规性测试工具，该工具用于自动化API合规性测试。目前系统已经具备基本功能，支持通过Web界面和命令行方式使用。用户可以提供API规范文件（YAPI或Swagger格式），指定目标服务的Base URL，并配置自定义测试用例目录和报告输出位置等参数。最近我们把系统进行了重构，将测试执行与历史记录查看拆分为两个独立的应用程序。
|
||
|
||
### 优先任务
|
||
1. **功能完善**：确保所有核心功能正常工作，包括API规范解析、测试用例执行和报告生成。
|
||
2. **Bug修复**：解决测试过程中可能出现的错误和异常情况。
|
||
3. **性能优化**：提高测试执行效率，特别是对于大型API规范文件和复杂测试场景。
|
||
4. **用户体验改进**：优化Web界面，提供更友好的操作流程和反馈。
|
||
5. **文档更新**：确保用户手册和开发文档与最新代码保持同步。
|
||
|
||
## 最近变更
|
||
|
||
### 代码变更
|
||
- **系统架构重构**：将原本集成在一起的测试执行和报告查看功能分离，现在使用 `run_api_tests.py` 专门负责执行测试，并在 `test_reports` 目录下创建带时间戳的子文件夹来保存报告；使用新的 `history_viewer.py` 作为独立的Web应用来查看历史测试报告。
|
||
- **测试报告改进**：测试报告现在按时间戳组织，每次测试运行生成一个独立的文件夹，便于管理和查看历史数据。
|
||
- **历史记录查看功能**：添加了直观的历史记录列表，可根据测试成功率显示不同的颜色渐变，并支持详情查看。
|
||
- **LLM配置界面**：增加了易用的LLM合规性标准在线配置页面，支持从Web界面动态添加、编辑和删除规则。
|
||
- **报告下载功能**：在测试详情页面添加了下载原始JSON摘要和Markdown详情报告的功能。
|
||
- **增强导航体验**：添加了浮动导航按钮，方便在长详情页面中快速跳转到不同部分。
|
||
- 实现了用户认证系统，使用SQLite存储用户信息
|
||
- 添加了LLM集成功能，支持使用大模型生成测试数据
|
||
- 新增了数值越界错误处理测试用例 (TC-ERROR-4002)，用于验证API在接收到超出范围的数值参数时是否按预期返回特定业务错误码。
|
||
|
||
### 架构调整
|
||
- 从单一的Web应用变为"命令行执行 + Web查看"的分离架构，提高了系统灵活性和扩展性。
|
||
- 改进了测试报告的存储结构，采用时间戳命名的子目录层次式存储，便于历史数据管理。
|
||
- 重构了测试编排器(APITestOrchestrator)，提高了代码可维护性
|
||
- 引入了更灵活的插件机制，便于扩展测试用例和测试阶段
|
||
- 改进了API规范解析器，增强了对不同格式的兼容性
|
||
- 优化了测试用例注册表的设计，支持更精确的用例筛选
|
||
- 在 `schema_utils.py` 中添加了可复用的辅助函数，用于从描述中解析数值范围，以简化相关测试用例的编写。
|
||
|
||
## 活动决策和考虑
|
||
|
||
### 当前决策
|
||
1. **分离执行与查看**：决定将测试执行和历史记录查看分开，使系统更加模块化，也避免了Web服务器在执行大型测试时可能出现的性能问题。
|
||
2. **LLM集成策略**：继续使用兼容OpenAI API的通义千问大模型作为测试数据生成的后端，同时通过Web界面提供便捷的规则配置功能。
|
||
3. **测试报告格式**：采用JSON格式作为摘要报告，Markdown格式作为详细报告，平衡了机器可读性和人类可读性。
|
||
4. **用户认证方案**：使用基于Flask session的简单认证系统，结合SQLite数据库存储用户信息，避免过度复杂化。
|
||
5. **用户体验优先**：关注用户体验的细节改进，如颜色渐变的状态显示、浮动导航按钮、报告文件下载等。
|
||
6. **部署模式**：支持本地部署，使用简单的Python命令启动，不依赖复杂的容器或云服务。
|
||
|
||
### 开放问题
|
||
1. **多线程执行**：是否应该支持并行执行测试用例以提高性能？需要权衡速度提升与稳定性风险。
|
||
2. **测试用例覆盖度**：如何确保测试用例能全面覆盖各种API合规性要求？考虑引入测试覆盖率分析。
|
||
3. **LLM依赖性**：如何处理LLM服务不可用或响应缓慢的情况？需要实现更强大的回退机制。
|
||
4. **安全性增强**：当前的认证机制是否足够安全？考虑加入更多安全措施如CSRF保护和API密钥轮换。
|
||
|
||
## 下一步计划
|
||
|
||
### 短期目标 (1-2周)
|
||
- 优化命令行测试工具的报告输出
|
||
- 为历史记录查看器添加搜索和过滤功能
|
||
- 增强LLM配置功能，支持规则集的导入/导出
|
||
- 添加更多可视化统计功能
|
||
- 完善用户文档和开发指南
|
||
|
||
### 中期目标 (1-2个月)
|
||
- 实现测试结果的历史记录和比较功能
|
||
- 添加API端点的搜索和过滤功能
|
||
- 改进LLM参数生成的质量和效率
|
||
- 支持更复杂的测试场景和数据依赖
|
||
- **引入响应适配层**: 设计并实现可插拔的"响应适配层"，以灵活适配非标准API响应。该机制包括：
|
||
- **响应数据提取器**: 智能提取被包装的（如`{code, data}`）或直接返回的核心业务数据。
|
||
- **动态Schema提供者**: 支持通过独立API请求获取并缓存数据模型（Schema）。
|
||
- **灵活Schema验证测试用例**: 整合上述机制，实现一个可复用的、用于非标准API风格的验证用例。
|
||
|
||
### 长期目标 (3+个月)
|
||
- 开发更强大的测试报告分析工具
|
||
- 支持团队协作和测试结果共享
|
||
- 集成CI/CD流程，实现自动化测试
|
||
- 开发更高级的测试用例编辑器，降低编写自定义测试用例的门槛 |