79 lines
5.6 KiB
Markdown
79 lines
5.6 KiB
Markdown
# DMS API 集成与“增删改查”流程测试方案总结
|
||
|
||
本文档旨在总结将DMS（动态模型服务）定义的API集成到自动化合规性测试框架中的过程，以及后续为支持“增删改查”（CRUD）端到端场景测试所做的设计与实现。
|
||
|
||
---
|
||
|
||
## 第一阶段：基础 GET 接口集成与测试
|
||
|
||
此阶段的目标是实现对DMS定义的简单GET接口的解析、集成和自动化测试。
|
||
|
||
### 1. DMS 规范解析
|
||
|
||
* **输入源**: 基于DMS提供的三个核心JSON文件（`列表.json`, `domain.json`, `model.json`）作为API规范的来源。
|
||
* **解析器实现 (`parser.py`)**:
|
||
* 创建了新的数据模型 `DMSEndpoint` 和 `ParsedDMSSpec` 用于表示DMS的API结构。
|
||
* 实现了核心解析函数 `parse_dms_spec`，该函数模拟客户端行为，首先从列表接口获取所有API的元数据，然后遍历并获取每个API的详细模型定义。
|
||
* 为了解耦和方便测试，将硬编码的URL重构为可配置的 `base_url`。
|
||
|
||
### 2. 框架集成
|
||
|
||
* **测试编排器 (`test_orchestrator.py`)**:
|
||
* 将新的 `DMSEndpoint` 集成到测试编排器的核心逻辑中，确保框架能够理解和处理来自DMS的API对象。
|
||
* 创建了 `run_tests_from_dms` 方法，作为专门处理DMS测试流程的入口，与已有的YAPI和Swagger流程保持一致。
|
||
* **命令行入口 (`run_api_tests.py`)**:
|
||
* 增加了 `--dms` 命令行参数，允许用户指定DMS作为API规范源。
|
||
* 确保了 `--dms`, `--yapi`, `--swagger` 三个参数的互斥性，保证了调用的明确性。
|
||
|
||
### 3. 模拟服务器与调试
|
||
|
||
* **创建模拟服务器 (`mock_dms_server.py`)**:
|
||
* 为了在没有真实后端的情况下进行开发和测试，我们创建了一个基于Flask的模拟服务器。
|
||
* 该服务器在启动时，能够动态地为API列表中的每个业务对象生成包含 `enum` 和数值范围约束的、独一无二的JSON Schema，并缓存起来按需提供。
|
||
* **调试与迭代**:
|
||
* **智能跳过测试**: 解决了为简单GET接口执行复杂参数测试（如分页、特定查询参数）的问题。通过在测试用例基类中扩展 `applies_to` 方法，我们为7个依赖特定参数的测试用例增加了前置检查逻辑，使它们仅在API规范满足相应条件时才被执行。
|
||
* **修复`400 Bad Request`**: 解决了当Mock服务器收到`Content-Type: application/json`但请求体为空的请求时，Flask返回400错误的问题。通过将请求解析方式从`request.is_json`改为更健壮的`request.get_json(silent=True)`，增强了服务器的稳定性。
|
||
|
||
---
|
||
|
||
## 第二阶段：“增删改查” (CRUD) 场景测试拓展
|
||
|
||
在完成基础集成后，我们提出了一个更高级的需求：将独立的`增`、`删`、`改`、`查`接口串联起来，进行端到端的业务流程测试。
|
||
|
||
### 1. 方案设计
|
||
|
||
* **引入 `test_mode`**:
|
||
* 在 `DMSEndpoint` 模型中增加了一个 `test_mode` 字段，其值可以是 `standalone` (可独立测试) 或 `scenario_only` (仅用于场景测试)。
|
||
* 在DMS解析器中，我们将自动生成的 `Create` 接口标记为 `standalone`，而 `Update`, `Delete` 和 `Get` (单个资源) 接口标记为 `scenario_only`，因为后三者依赖于一个已存在的资源ID。
|
||
* **动态生成CRUD接口**:
|
||
* 重构了 `parse_dms_spec` 方法，使其不再是简单地解析API，而是为每个DMS业务对象（如“项目”、“用户”等）自动生成一套完整的CRUD（Create, Read, Update, Delete, List）API端点。
|
||
* **增强模拟服务器**:
|
||
* 对 `mock_dms_server.py` 进行了重大升级，为其增加了一个内存数据库（一个Python字典）。
|
||
* 完整实现了 `Create`, `Read`, `Update`, `Delete`, `List` 五个操作的后端逻辑，使其能够模拟真实的数据持久化行为。
|
||
|
||
### 2. 场景测试阶段 (`DmsCrudScenarioStage`)
|
||
|
||
* **创建自定义测试阶段**:
|
||
* 我们创建了一个新的测试阶段 `custom_stages/dms_crud_scenario_stage.py`，专门用于执行DMS的CRUD流程测试。
|
||
* **核心功能**:
|
||
* **自动发现**: 该阶段能自动扫描所有解析出的DMS接口，并找出属于同一个业务对象的、可以构成完整CRUD流程的API组合。
|
||
* **静态测试流程**: 定义了一个包含6个固定步骤的测试流程：
|
||
1. **Create**: 调用`POST`接口创建一个新资源。
|
||
2. **Verify Create**: 调用`GET`接口验证该资源是否成功创建。
|
||
3. **Update**: 调用`PUT`/`PATCH`接口修改该资源。
|
||
4. **Verify Update**: 再次调用`GET`接口验证修改是否成功。
|
||
5. **Delete**: 调用`DELETE`接口删除该资源。
|
||
6. **Verify Delete**: 最后调用`GET`接口验证该资源是否已被成功删除。
|
||
* **上下文传递**: 利用框架的 `stage_context` 机制，在`Create`步骤成功后，将其返回的资源ID（主键）传递给后续的所有步骤使用。
|
||
|
||
### 3. 集成与执行
|
||
|
||
* 框架的 `StageRegistry` 能够自动发现并加载我们新的 `DmsCrudScenarioStage`。
|
||
* 通过在命令行中指定 `--stages-dir ./custom_stages`，即可启动这个端到端的场景测试，实现对整个“增删改查”生命周期的自动化验证。
|
||
|
||
---
|
||
|
||
## 总结
|
||
|
||
通过这两个阶段的迭代，我们成功地将一个新的、动态的API规范源（DMS）无缝集成到了现有的测试框架中。我们不仅实现了对单个API接口的合规性检查，还设计并实现了一套强大的场景测试解决方案，能够自动编排和验证复杂的多步骤业务流程，极大地提升了测试的深度和广度。
|