compliance/memory-bank/capability_statement.md

项目核心能力说明 (Capability Statement)

1. 引言与愿景

本文档旨在提炼并阐述当前自动化测试框架的核心能力。该框架最初为 API 合规性测试而设计，但其底层架构具备高度的灵活性和可扩展性。我们的愿景是基于这些核心能力，将此项目逐步演进为一个支持多种测试类型（如前端UI测试、性能测试、数据一致性测试等）的通用自动化测试平台。

本文将详细介绍框架的关键设计理念与核心能力，并提供一份清晰的蓝图，展示如何将新的测试领域无缝集成到现有体系中。

2. 核心能力详解

我们的框架通过将测试流程解耦为“目标发现”、“测试执行”、“数据生成”和“结果报告”四个主要阶段，实现了高度的模块化。以下是构成这些阶段的核心能力：

2.1. 可插拔的测试引擎架构 (Pluggable Test Engine)

这是框架最具扩展性的能力。我们通过“注册表模式”和“基类继承”实现。

• 测试用例注册表 (TestCaseRegistry): 系统会自动发现并注册所有继承自 BaseTestCase 的测试用例类。这使得添加新测试用例就像编写一个新类一样简单，无需修改任何核心代码。
• 通用测试基类 (BaseTestCase): 它定义了测试用例的生命周期和必要接口（如 applies_to 判断适用性，execute 执行测试）。

扩展潜力: 此模式不局限于API测试。我们可以定义新的测试基类，如 BaseUITestCase (集成Selenium/Playwright) 或 BasePerformanceTestCase (集成JMeter/Locust)，测试用例注册表可以同样对它们进行管理和调度。

2.2. 配置驱动的测试编排 (Configuration-Driven Orchestration)

测试的执行流程由核心的测试编排器 (Orchestrator) 控制，但其所有行为都通过外部配置（如YAML文件、命令行参数）来驱动。

• 解耦测试逻辑与执行策略: 用户可以指定测试目标、筛选条件、启用的测试用例、报告输出位置等，而无需触碰代码。
• 灵活的测试阶段 (Stage): 编排器支持自定义测试阶段（BaseStage），允许在测试执行前后插入自定义逻辑，如环境准备、数据清理等。

扩展潜力: 当引入新的测试类型时，我们可以为其创建一个新的编排器（如 UIOrchestrator)，复用相同的配置读取和阶段管理逻辑，仅替换核心的目标发现和测试执行部分。

2.3. 智能化的数据与场景生成 (Intelligent Data & Scenario Generation)

框架集成了LLM服务 (LLMService)，使其超越了传统的数据驱动测试。

• 超越静态数据: LLM能够根据API的Schema动态生成各种有效和无效的测试数据，极大地提升了边缘情况的测试覆盖率。
• 场景生成: 未来可以利用LLM生成复杂的用户操作序列（用于UI测试）或模拟真实的用户行为模式（用于性能测试）。

扩展潜力: LLMService 是一个通用能力，可以为任何需要复杂测试数据的场景提供支持，例如为前端表单生成多样化的输入值。

2.4. 标准化的多维报告体系 (Standardized, Multi-dimensional Reporting)

测试框架的核心优势之一是其强大且独立的报告系统。

• 执行与查看分离: run_api_tests.py 负责执行测试并生成原始报告数据，而 history_viewer.py 提供一个独立的Web应用来查询和可视化所有历史报告。
• 多种报告格式: 自动生成机器可读的 summary.json 和人类可读的 api_call_details.md。
• 统一数据模型: 所有测试结果都将被格式化为一个标准的 TestSummary 对象。

扩展潜力: 这个报告系统是完全通用的。任何新的测试引擎（UI测试、性能测试等）只需将其结果构造成 TestSummary 格式，就可以立刻被我们的历史查看器支持，无需任何额外开发。

2.5. 灵活的目标发现与筛选机制 (Flexible Target Discovery & Filtering)

自动化测试的第一步是确定“测什么”。我们的框架将这一过程抽象化。

• 输入源解析器 (InputParser): 当前系统能解析OpenAPI/Swagger文件来发现API端点。
• 目标筛选: 支持通过标签、路径、名称等多种方式筛选出本次需要测试的具体目标。

扩展潜力: 我们可以轻松添加新的解析器。例如，为前端测试添加一个 SitemapParser (解析 sitemap.xml) 或 ComponentManifestParser (解析组件库的清单文件)，以自动发现所有待测页面或组件。

3. 扩展蓝图：集成前端UI自动化测试

为了更具体地说明如何利用上述能力进行扩展，我们以“集成前端UI自动化测试”为例，描绘一个清晰的实施路径：

1. 定义测试目标输入: 约定使用 sitemap.xml 或自定义的 ui-targets.json 文件来描述所有待测试的Web页面及其关键元素。
2. 实现新解析器: 创建一个 SitemapParser 类，用于解析站点地图文件，并返回一个标准化的“待测目标”列表。
3. 实现UI测试基类: 创建 BaseUITestCase(BaseTestCase)，它在内部初始化一个WebDriver实例（如Selenium），并提供一些基础的UI操作方法（如 click, type_text）。
4. 编写具体UI测试用例:
   • TC-UI-001-TitleCheck(BaseUITestCase): 检查页面标题是否正确。
   • TC-UI-002-LoginForm(BaseUITestCase): 测试登录表单的校验逻辑。
   • TC-UI-003-BrokenLinks(BaseUITestCase): 检查页面是否存在死链。
5. 适配/创建编排器: 创建 UIOrchestrator，它使用 SitemapParser 来发现目标，并调度所有适用的 BaseUITestCase 子类来执行测试。
6. 统一报告格式: 确保 UIOrchestrator 在测试结束后，将其执行结果（包括截图、操作日志等）封装到标准的 TestSummary 对象中，并存入报告目录。

完成以上步骤后，history_viewer.py 将能直接展示UI测试的历史结果，实现了新测试能力的无缝集成。

4. 结论

本框架通过其模块化、可插拔和配置驱动的设计，已为成为一个通用测试平台奠定了坚实的基础。其核心能力并非仅仅为API测试服务，而是构成了一套通用的自动化测试解决方案。通过遵循本文档提供的扩展蓝图，我们可以高效、低成本地将新的测试领域整合进来，逐步实现平台的宏伟愿景。