compliance/memory-bank/systemPatterns.md

系统架构与设计模式

系统架构概览

合规性测试工具采用了模块化的分层架构，主要由以下核心组件构成：

flowchart TD
    CLI[命令行接口\nrun_api_tests.py] --> Orch[测试编排器\nAPITestOrchestrator]
    Web[Web界面\nflask_app.py] --> Orch
    
    Orch --> Parser[API规范解析器\nInputParser]
    Orch --> Registry[测试用例注册表\nTestCaseRegistry]
    Orch --> Caller[API调用器\nAPICaller]
    Orch --> LLM[LLM服务\nLLMService]
    
    Registry --> TestCases[测试用例\nBaseAPITestCase子类]
    
    Orch --> Reporter[测试报告生成器]

关键技术决策

1. 模块化设计：系统被分解为多个独立的模块，每个模块负责特定功能，便于维护和扩展。
2. 插件式架构：测试用例和测试阶段采用插件式设计，允许用户自定义和扩展。
3. 配置驱动：系统行为通过配置文件和命令行参数控制，无需修改代码即可调整。
4. 双重接口：同时提供Web界面和命令行接口，满足不同使用场景的需求。
5. LLM集成：集成大语言模型API，实现智能测试数据生成。

设计模式应用

1. 工厂模式

• 应用：InputParser根据输入类型（YAPI/Swagger）创建对应的解析器。
• 好处：封装创建逻辑，客户端代码无需关心具体实现细节。

2. 策略模式

• 应用：不同的测试用例实现相同的接口（BaseAPITestCase），但有不同的验证逻辑。
• 好处：允许在运行时选择不同的算法，增强系统灵活性。

3. 观察者模式

• 应用：测试执行过程中的日志和进度更新通过事件通知机制传递给界面。
• 好处：解耦核心测试逻辑和界面展示，提高代码可维护性。

4. 模板方法模式

• 应用：BaseAPITestCase定义测试用例的基本流程和钩子方法，子类只需实现特定步骤。
• 好处：重用代码，确保所有测试用例遵循统一的执行流程。

5. 装饰器模式

• 应用：Web应用中的@login_required装饰器用于保护需要认证的路由。
• 好处：以非侵入方式为函数添加额外功能，如安全检查。

组件关系

测试编排器 (APITestOrchestrator)

• 角色：系统的核心控制器，协调各组件工作。
• 职责：初始化组件、解析API规范、筛选端点、执行测试用例、汇总结果。
• 依赖：依赖于InputParser、TestCaseRegistry、APICaller和可选的LLMService。

测试用例注册表 (TestCaseRegistry)

• 角色：发现和管理测试用例类。
• 职责：扫描指定目录、加载测试用例类、根据端点特征筛选适用的测试用例。
• 依赖：依赖于BaseAPITestCase的子类实现。

API规范解析器 (InputParser)

• 角色：解析API定义文件。
• 职责：读取并解析YAPI或Swagger/OpenAPI格式的API规范文件，转换为内部数据结构。
• 依赖：无外部依赖。

API调用器 (APICaller)

• 角色：执行HTTP请求。
• 职责：根据测试用例生成的请求数据发送HTTP请求，收集响应信息。
• 依赖：依赖于HTTP客户端库（如requests）。

LLM服务 (LLMService)

• 角色：智能生成测试数据。
• 职责：根据API规范生成符合要求的请求参数和请求体。
• 依赖：依赖于外部LLM API服务。

数据流

1. 用户通过Web界面或命令行提供API规范文件和配置。
2. 测试编排器使用InputParser解析API规范文件，获取API端点信息。
3. 测试编排器根据配置筛选需要测试的端点。
4. 对每个端点，测试编排器从TestCaseRegistry获取适用的测试用例。
5. 测试用例生成请求数据（可能使用LLMService）。
6. 测试编排器使用APICaller发送请求并收集响应。
7. 测试用例验证响应是否符合预期。
8. 测试编排器汇总所有测试结果，生成报告。
9. 用户通过Web界面或输出文件查看测试结果。