DMS API 集成与“增删改查”流程测试方案总结

本文档旨在总结将DMS（动态模型服务）定义的API集成到自动化合规性测试框架中的过程，以及后续为支持“增删改查”（CRUD）端到端场景测试所做的设计与实现。

第一阶段：基础 GET 接口集成与测试

此阶段的目标是实现对DMS定义的简单GET接口的解析、集成和自动化测试。

输入源: 基于DMS提供的三个核心JSON文件（列表.json, domain.json, model.json）作为API规范的来源。
解析器实现 (parser.py):
- 创建了新的数据模型 DMSEndpoint 和 ParsedDMSSpec 用于表示DMS的API结构。
- 实现了核心解析函数 parse_dms_spec，该函数模拟客户端行为，首先从列表接口获取所有API的元数据，然后遍历并获取每个API的详细模型定义。
- 为了解耦和方便测试，将硬编码的URL重构为可配置的 base_url。

测试编排器 (test_orchestrator.py):
- 将新的 DMSEndpoint 集成到测试编排器的核心逻辑中，确保框架能够理解和处理来自DMS的API对象。
- 创建了 run_tests_from_dms 方法，作为专门处理DMS测试流程的入口，与已有的YAPI和Swagger流程保持一致。
命令行入口 (run_api_tests.py):
- 增加了 --dms 命令行参数，允许用户指定DMS作为API规范源。
- 确保了 --dms, --yapi, --swagger 三个参数的互斥性，保证了调用的明确性。

创建模拟服务器 (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)，增强了服务器的稳定性。

在完成基础集成后，我们提出了一个更高级的需求：将独立的增、删、改、查接口串联起来，进行端到端的业务流程测试。

引入 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 五个操作的后端逻辑，使其能够模拟真实的数据持久化行为。

创建自定义测试阶段:
- 我们创建了一个新的测试阶段 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（主键）传递给后续的所有步骤使用。

通过这两个阶段的迭代，我们成功地将一个新的、动态的API规范源（DMS）无缝集成到了现有的测试框架中。我们不仅实现了对单个API接口的合规性检查，还设计并实现了一套强大的场景测试解决方案，能够自动编排和验证复杂的多步骤业务流程，极大地提升了测试的深度和广度。