82 lines
6.4 KiB
Markdown
82 lines
6.4 KiB
Markdown
# 项目核心能力说明 (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测试服务，而是构成了一套通用的自动化测试解决方案。通过遵循本文档提供的扩展蓝图，我们可以高效、低成本地将新的测试领域整合进来，逐步实现平台的宏伟愿景。 |