# 系统架构与设计模式 ## 系统架构概览 合规性测试工具采用了模块化的分层架构,主要由以下核心组件构成: ```mermaid 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界面或输出文件查看测试结果。