ruoyunbai/compliance
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

.

Browse Source
This commit is contained in:
gongwenxin
2025-08-07 15:07:38 +08:00
parent 1901cf611e
commit fa343eb111
55 changed files with 17850 additions and 16283 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/DMS_Integration_Summary.md
+78
View File
@@ -0,0 +1,78 @@
# 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接口的合规性检查，还设计并实现了一套强大的场景测试解决方案，能够自动编排和验证复杂的多步骤业务流程，极大地提升了测试的深度和广度。
docs/Docker_Deployment_Guide.md
+320
View File
@@ -0,0 +1,320 @@
# DMS合规性测试工具 Docker部署指南
## 🐳 Docker化优势
- **环境一致性**：消除环境差异问题
- **简化部署**：一条命令启动整个服务
- **依赖管理**：所有依赖都打包在镜像中
- **便携性**：可在任何Docker环境中运行
- **版本控制**：支持多版本镜像管理
- **多服务支持**：同时运行API服务和历史查看器
## 🔧 多服务架构
本Docker镜像包含两个服务：
- **API服务器** (api_server.py) - 端口5050：主要的API测试服务
- **历史查看器** (history_viewer.py) - 端口5051：测试历史查看和管理
提供两种多服务管理方案：
1. **Supervisor方案** (推荐)：使用supervisor管理进程，更稳定
2. **Shell脚本方案**：使用自定义脚本管理，更简单
## 📋 前置要求
- Docker 20.10+
- Docker Compose 1.29+ (可选)
- 至少2GB可用内存
- 至少5GB可用磁盘空间
## 🚀 快速开始
### 方法1：使用构建脚本（推荐）
```bash
# 给脚本执行权限
chmod +x docker-build.sh
# 构建并启动服务
./docker-build.sh
# 或者清理后重新构建
./docker-build.sh --clean
# 使用Docker Compose启动
./docker-build.sh --compose
```
### 方法2：手动构建
#### 使用Supervisor方案（推荐）
```bash
# 1. 构建镜像
docker build -f Dockerfile.service -t dms-compliance-tool:latest .
# 2. 创建必要目录
mkdir -p test_reports uploads logs
# 3. 启动容器
docker run -d \
--name dms-compliance-tool \
-p 5050:5050 \
-p 5051:5051 \
-v $(pwd)/test_reports:/app/test_reports \
-v $(pwd)/uploads:/app/uploads \
-v $(pwd)/logs:/app/logs \
-e TZ=Asia/Shanghai \
--restart unless-stopped \
dms-compliance-tool:latest
```
#### 使用Shell脚本方案
```bash
# 1. 构建简单版镜像
docker build -f Dockerfile.simple -t dms-compliance-tool:simple .
# 2. 启动容器
docker run -d \
--name dms-compliance-tool \
-p 5050:5050 \
-p 5051:5051 \
-v $(pwd)/test_reports:/app/test_reports \
-v $(pwd)/uploads:/app/uploads \
-v $(pwd)/logs:/app/logs \
-e TZ=Asia/Shanghai \
--restart unless-stopped \
dms-compliance-tool:simple
```
### 方法3：使用Docker Compose
```bash
# 启动服务
docker-compose up -d
# 查看日志
docker-compose logs -f
# 停止服务
docker-compose down
```
## 📁 目录结构
```
compliance/
├── Dockerfile.service # 服务运行镜像
├── docker-compose.yml # Docker Compose配置
├── docker-build.sh # 构建脚本
├── .dockerignore # Docker忽略文件
├── nginx/
│ └── nginx.conf # Nginx配置（可选）
├── test_reports/ # 测试报告目录（持久化）
├── uploads/ # 上传文件目录（持久化）
├── logs/ # 日志目录（持久化）
└── config/ # 配置文件目录（可选）
```
## 🔧 配置选项
### 环境变量
| 变量名 | 默认值 | 说明 |
|--------|--------|------|
| `FLASK_ENV` | `production` | Flask运行环境 |
| `PYTHONUNBUFFERED` | `1` | Python输出不缓冲 |
| `TZ` | `Asia/Shanghai` | 时区设置 |
### 端口映射
- `5050:5050` - API服务器端口（主服务）
- `5051:5051` - 历史查看器端口
- `80:80` - Nginx HTTP端口（可选）
- `443:443` - Nginx HTTPS端口（可选）
### 数据卷
- `./test_reports:/app/test_reports` - 测试报告持久化
- `./uploads:/app/uploads` - 上传文件持久化
- `./logs:/app/logs` - 日志文件持久化
## 🎯 使用方法
### 1. 启动服务
```bash
./docker-build.sh
```
### 2. 访问Web界面
- **API服务器**：http://localhost:5050
- **历史查看器**：http://localhost:5051
### 3. 使用命令行工具
```bash
# 进入容器
docker exec -it dms-compliance-tool bash
# 运行测试
python run_api_tests.py --base-url http://your-api-server --generate-pdf
```
## 📊 监控和管理
### 查看容器状态
```bash
# 查看运行状态
docker ps
# 查看日志
docker logs dms-compliance-tool
# 实时查看日志
docker logs -f dms-compliance-tool
```
### 健康检查
```bash
# 检查服务健康状态
curl http://localhost:5050/
# 查看健康检查状态
docker inspect dms-compliance-tool | grep Health -A 10
```
### 资源使用
```bash
# 查看资源使用情况
docker stats dms-compliance-tool
```
## 🔄 更新和维护
### 更新镜像
```bash
# 停止服务
docker stop dms-compliance-tool
# 重新构建
./docker-build.sh --clean
# 或使用Docker Compose
docker-compose down
docker-compose build --no-cache
docker-compose up -d
```
### 备份数据
```bash
# 备份测试报告
tar -czf test_reports_backup.tar.gz test_reports/
# 备份上传文件
tar -czf uploads_backup.tar.gz uploads/
```
## 🛠️ 故障排除
### 常见问题
1. **端口被占用**
```bash
# 检查端口占用
lsof -i :5050
# 修改端口映射
docker run -p 8080:5050 ...
```
2. **权限问题**
```bash
# 检查目录权限
ls -la test_reports/ uploads/ logs/
# 修复权限
sudo chown -R $USER:$USER test_reports/ uploads/ logs/
```
3. **内存不足**
```bash
# 检查Docker资源限制
docker system df
# 清理未使用的镜像
docker system prune -a
```
### 调试模式
```bash
# 以调试模式启动
docker run -it --rm \
-p 5050:5050 \
-v $(pwd)/test_reports:/app/test_reports \
-e FLASK_ENV=development \
dms-compliance-tool:latest
```
## 🌐 生产环境部署
### 使用Nginx反向代理
```bash
# 启动包含Nginx的完整服务
docker-compose --profile with-nginx up -d
```
### SSL证书配置
1. 将SSL证书放在 `nginx/ssl/` 目录
2. 修改 `nginx/nginx.conf` 添加HTTPS配置
3. 重启服务
### 性能优化
- 调整容器资源限制
- 配置日志轮转
- 使用外部数据库（如需要）
- 配置负载均衡（多实例部署）
## 📦 镜像管理
### 导出镜像
```bash
# 导出镜像
docker save dms-compliance-tool:latest | gzip > dms-compliance-tool.tar.gz
```
### 导入镜像
```bash
# 导入镜像
gunzip -c dms-compliance-tool.tar.gz | docker load
```
### 推送到私有仓库
```bash
# 标记镜像
docker tag dms-compliance-tool:latest your-registry.com/dms-compliance-tool:latest
# 推送镜像
docker push your-registry.com/dms-compliance-tool:latest
```
## ✅ 验证部署
1. **服务可访问性**：http://localhost:5050
2. **健康检查**：容器状态为healthy
3. **功能测试**：上传API规范并执行测试
4. **PDF生成**：验证PDF报告生成功能
5. **数据持久化**：重启容器后数据仍存在
部署成功后，您就可以在任何支持Docker的环境中快速部署DMS合规性测试工具了！
docs/Docker_Quick_Reference.md
+258
View File
@@ -0,0 +1,258 @@
# DMS合规性测试工具 Docker快速参考
## 🚀 快速命令
### 一键部署
```bash
# 构建并启动服务
./docker-build.sh
# 测试Docker镜像
./test-docker.sh
```
### 基本操作
```bash
# 构建镜像
docker build -f Dockerfile.service -t dms-compliance-tool .
# 启动容器
docker run -d --name dms-compliance-tool -p 5050:5050 dms-compliance-tool
# 查看状态
docker ps
# 查看日志
docker logs dms-compliance-tool
# 停止容器
docker stop dms-compliance-tool
# 删除容器
docker rm dms-compliance-tool
```
## 📁 文件说明
| 文件 | 说明 |
|------|------|
| `Dockerfile.service` | 服务运行镜像定义 |
| `docker-compose.yml` | Docker Compose配置 |
| `docker-build.sh` | 自动化构建脚本 |
| `test-docker.sh` | Docker测试脚本 |
| `.dockerignore` | Docker构建忽略文件 |
| `nginx/nginx.conf` | Nginx反向代理配置 |
## 🔧 常用场景
### 开发环境
```bash
# 构建开发镜像
docker build -f Dockerfile.service -t dms-compliance-tool:dev .
# 启动开发容器（挂载代码目录）
docker run -d \
--name dms-dev \
-p 5050:5050 \
-v $(pwd):/app \
-e FLASK_ENV=development \
dms-compliance-tool:dev
```
### 生产环境
```bash
# 使用Docker Compose启动完整服务
docker-compose up -d
# 查看服务状态
docker-compose ps
# 查看日志
docker-compose logs -f
```
### 测试环境
```bash
# 运行测试
./test-docker.sh
# 仅构建测试镜像
./test-docker.sh --build-only
# 清理测试环境
./test-docker.sh --cleanup-only
```
## 🛠️ 故障排除
### 检查容器状态
```bash
# 查看所有容器
docker ps -a
# 查看容器详细信息
docker inspect dms-compliance-tool
# 进入容器调试
docker exec -it dms-compliance-tool bash
```
### 查看资源使用
```bash
# 实时资源监控
docker stats
# 查看镜像大小
docker images
# 清理未使用资源
docker system prune -a
```
### 网络问题
```bash
# 查看端口映射
docker port dms-compliance-tool
# 测试网络连接
curl http://localhost:5050
# 查看容器网络
docker network ls
```
## 📦 镜像管理
### 本地镜像操作
```bash
# 列出镜像
docker images
# 删除镜像
docker rmi dms-compliance-tool
# 导出镜像
docker save dms-compliance-tool | gzip > dms-tool.tar.gz
# 导入镜像
gunzip -c dms-tool.tar.gz | docker load
```
### 镜像仓库操作
```bash
# 标记镜像
docker tag dms-compliance-tool:latest registry.example.com/dms-tool:v1.0
# 推送镜像
docker push registry.example.com/dms-tool:v1.0
# 拉取镜像
docker pull registry.example.com/dms-tool:v1.0
```
## 🔄 更新流程
### 应用更新
```bash
# 1. 停止现有服务
docker-compose down
# 2. 重新构建镜像
docker-compose build --no-cache
# 3. 启动新服务
docker-compose up -d
# 4. 验证服务
curl http://localhost:5050
```
### 配置更新
```bash
# 1. 修改配置文件
vim docker-compose.yml
# 2. 重新启动服务
docker-compose restart
# 3. 查看更新后的配置
docker-compose config
```
## 📊 监控命令
### 实时监控
```bash
# 容器资源使用
docker stats dms-compliance-tool
# 容器日志
docker logs -f dms-compliance-tool
# 系统事件
docker events
```
### 健康检查
```bash
# 检查容器健康状态
docker inspect dms-compliance-tool | grep -A 5 Health
# 手动健康检查
curl -f http://localhost:5050/ || echo "Service unhealthy"
```
## 🎯 最佳实践
### 安全
- 使用非root用户运行容器
- 限制容器资源使用
- 定期更新基础镜像
- 使用多阶段构建减小镜像大小
### 性能
- 使用.dockerignore减少构建上下文
- 合理设置内存和CPU限制
- 使用数据卷持久化重要数据
- 配置日志轮转避免日志文件过大
### 维护
- 定期清理未使用的镜像和容器
- 备份重要数据和配置
- 监控容器资源使用情况
- 建立镜像版本管理策略
## 🆘 紧急操作
### 服务异常
```bash
# 快速重启
docker restart dms-compliance-tool
# 强制停止
docker kill dms-compliance-tool
# 查看最近日志
docker logs --tail 50 dms-compliance-tool
```
### 数据恢复
```bash
# 从容器复制文件
docker cp dms-compliance-tool:/app/test_reports ./backup/
# 向容器复制文件
docker cp ./backup/config.json dms-compliance-tool:/app/
```
### 完全重置
```bash
# 停止并删除所有相关容器
docker-compose down -v
# 删除镜像
docker rmi dms-compliance-tool
# 重新构建和启动
./docker-build.sh --clean
```
docs/Framework_And_TestCase_Guide.md
+317
View File
@@ -0,0 +1,317 @@
## 技术架构概览
本 API 合规性测试框架主要由以下几个核心组件构成，它们协同工作以完成测试的定义、发现、执行和报告：
1. **命令行接口 (`run_api_tests.py`)**:
* 作为测试执行的入口。
* 负责解析用户通过命令行传入的参数，例如 API 服务的基础 URL、API 规范文件路径（YAPI 或 Swagger）、测试用例目录、输出报告配置以及 LLM 相关配置。
* 初始化并驱动 `APITestOrchestrator`。
2. **测试编排器 (`APITestOrchestrator` 在 `ddms_compliance_suite/test_orchestrator.py`)**:
* **核心控制器**：是整个测试流程的指挥中心。
* **组件初始化**：负责初始化和管理其他关键组件，如 `InputParser`（API 规范解析器）、`APICaller`（API 请求调用器）、`TestCaseRegistry`（测试用例注册表）以及可选的 `LLMService`（大模型服务）。
* **`$ref` 解析**: 在将API端点规范 (`endpoint_spec_dict`) 传递给测试用例构造函数之前，会使用 `schema_utils.resolve_json_schema_references` 解析其中的 schemas (requestBody, parameters, responses)，默认会丢弃原始的 `$ref` 和 `$$` 前缀的键。
* **测试流程管理**：
* 调用 `InputParser` 解析指定的 API 规范文件，获取所有端点的定义。
* 根据用户指定的过滤器（如 YAPI 分类或 Swagger 标签）筛选需要测试的 API 端点。
* 对每一个选定的 API 端点：
* 通过 `TestCaseRegistry` 获取所有适用于该端点的自定义测试用例类。
* 实例化每个测试用例类。
* 调用 `_prepare_initial_request_data` 方法准备初始请求数据（路径参数、查询参数、请求头、请求体）。此方法会根据全局配置和测试用例自身的配置决定是否使用 LLM 进行数据生成，并利用 `LLMService` 和动态 Pydantic 模型创建（`_create_pydantic_model_from_schema`）来实现。如果LLM未启用或不适用，则使用传统的基于 Schema 的数据生成逻辑（`_generate_params_from_list`, `_generate_parameters_from_schema`）。此阶段还实现了端点级别的LLM参数缓存。
* 依次调用测试用例实例中定义的 `generate_*` 方法，允许测试用例修改生成的请求数据。
* 调用测试用例实例中定义的 `validate_request_*` 方法，对即将发送的请求进行预校验。
* 使用 `APICaller` 发送最终构建的 API 请求。
* 接收到 API 响应后，调用测试用例实例中定义的 `validate_response` 和 `check_performance` 方法，对响应进行详细验证。
* **结果汇总**：收集每个测试用例的执行结果 (`ExecutedTestCaseResult`)，汇总成每个端点的测试结果 (`TestResult`)，并最终生成整个测试运行的摘要 (`TestSummary`)。
3. **测试用例注册表 (`TestCaseRegistry` 在 `ddms_compliance_suite/test_case_registry.py`)**:
* **动态发现**：负责在用户指定的目录 (`custom_test_cases_dir`) 下扫描并动态加载所有以 `.py` 结尾的测试用例文件。
* **类识别与注册**：从加载的模块中，识别出所有继承自 `BaseAPITestCase` 的类，并根据其 `id` 属性进行注册。
* **执行顺序排序**：在发现所有测试用例类后，会根据每个类的 `execution_order` 属性（主排序键，升序）和类名 `__name__`（次排序键，字母升序）对它们进行排序。
* **适用性筛选**：提供 `get_applicable_test_cases` 方法，根据 API 端点的 HTTP 方法和路径（通过正则表达式匹配）筛选出适用的、已排序的测试用例类列表给编排器。
4. **测试框架核心 (`test_framework_core.py`)**:
* **`BaseAPITestCase`**：所有自定义测试用例的基类。它定义了测试用例应具备的元数据（如 `id`, `name`, `description`, `severity`, `tags`, `execution_order`, `applicable_methods`, `applicable_paths_regex` 以及 LLM 使用标志位）和一系列生命周期钩子方法（如 `generate_*`, `validate_*`），以及众多辅助方法（见下文）。
* **`APIRequestContext` / `APIResponseContext`**：数据类，分别用于封装 API 请求和响应的上下文信息，在测试用例的钩子方法间传递。
* **`ValidationResult`**：数据类，用于表示单个验证点的结果（通过/失败、消息、详细信息）。
* **`TestSeverity`**：枚举类型，定义测试用例的严重级别。
5. **API 规范解析器 (`InputParser` 在 `ddms_compliance_suite/input_parser/parser.py`)**:
* 负责读取和解析 YAPI（JSON 格式）或 Swagger/OpenAPI（JSON 或 YAML 格式）的 API 规范文件。
* 将原始规范数据转换成框架内部易于处理的结构化对象（如 `ParsedYAPISpec`, `YAPIEndpoint`, `ParsedSwaggerSpec`, `SwaggerEndpoint`）。
6. **API 调用器 (`APICaller` 在 `ddms_compliance_suite/api_caller/caller.py`)**:
* 封装了实际的 HTTP 请求发送逻辑。
* 接收一个 `APIRequest` 对象（包含方法、URL、参数、头部、请求体），使用如 `requests` 库执行请求，并返回一个 `APIResponse` 对象（包含状态码、响应头、响应体内容等）。
7. **LLM 服务 (`LLMService` 在 `ddms_compliance_suite/llm_utils/llm_service.py`)** (可选):
* 如果配置了 LLM 服务（如通义千问的兼容 OpenAI 模式的 API），此组件负责与 LLM API 交互。
* 主要用于根据 Pydantic 模型（从 JSON Schema 动态创建）智能生成复杂的请求参数或请求体。
8. **工具模块 (`ddms_compliance_suite/utils/`)**:
* **`schema_utils.py`**: 包含一系列用于处理 JSON Schema 和 API 参数的实用函数。
* **`common_utils.py`**: 包含通用的辅助函数。
这个架构旨在提供一个灵活、可扩展的 API 测试框架，允许用户通过编写自定义的 Python 测试用例来定义复杂的验证逻辑。
## 自定义 `APITestCase` 编写指南
此指南帮助您创建自定义的 `APITestCase` 类，以扩展 DDMS 合规性验证软件的测试能力。核心理念是 **代码即测试**，并充分利用框架提供的工具函数和基类辅助方法来简化测试用例的编写。
### 1. 创建自定义测试用例
1. **创建 Python 文件**：在您的自定义测试用例目录（例如 `custom_testcases/`）下创建一个新的 `.py` 文件。
2. **导入必要模块**：
```python
from typing import Dict, Any, Optional, List
from ddms_compliance_suite.test_framework_core import BaseAPITestCase, TestSeverity, ValidationResult, APIRequestContext, APIResponseContext
from ddms_compliance_suite.utils import schema_utils, common_utils # 导入工具模块
import logging # 可选，用于自定义日志
```
3. **继承 `BaseAPITestCase`**：定义一个或多个类，使其继承自 `BaseAPITestCase`。
4. **定义元数据 (类属性)**：
* `id: str`: 测试用例的全局唯一标识符 (例如 `"TC-MYFEATURE-001"`)。
* `name: str`: 人类可读的名称。
* `description: str`: 详细描述。
* `severity: TestSeverity`: 严重程度 (例如 `TestSeverity.CRITICAL`, `TestSeverity.HIGH`, 等)。
* `tags: List[str]`: 分类标签 (例如 `["smoke", "regression"]`)。
* `execution_order: int`: 控制测试用例的执行顺序。**数值较小的会比较大的先执行**。默认值为 `100`。
* `applicable_methods: Optional[List[str]]`: 限制适用的 HTTP 方法 (例如 `["POST", "PUT"]`)。`None` 表示所有方法。
* `applicable_paths_regex: Optional[str]`: 限制适用的 API 路径 (Python 正则表达式)。`None` 表示所有路径。
* **LLM 使用标志 (可选)**: 这些标志允许测试用例覆盖全局 LLM 配置。
* `use_llm_for_body: bool = False`
* `use_llm_for_path_params: bool = False`
* `use_llm_for_query_params: bool = False`
* `use_llm_for_headers: bool = False`
5. **实现 `__init__` (如果需要自定义初始化逻辑)**:
* 通常，您会在这里调用基类的 `__init__`。
* 许多测试用例会在这里查找并设置测试目标字段/参数，可以利用 `BaseAPITestCase` 提供的辅助方法（如 `_get_resolved_request_body_schema`, `_find_simple_type_field_in_schema`, `_find_first_simple_type_parameter`, `_find_removable_field_path`）来完成。
```python
class MissingRequiredFieldBodyCase(BaseAPITestCase):
# ...元数据...
def __init__(self, endpoint_spec: Dict[str, Any], global_api_spec: Dict[str, Any], json_schema_validator: Optional[Any] = None, llm_service: Optional[Any] = None):
super().__init__(endpoint_spec, global_api_spec, json_schema_validator, llm_service)
self.removable_field_path: Optional[List[Union[str, int]]] = None
body_schema = self._get_resolved_request_body_schema()
if body_schema:
self.removable_field_path = self._find_removable_field_path(body_schema, "request body")
if not self.removable_field_path:
self.logger.info(f"[{self.id}] No removable required field found in request body.")
```
6. **实现验证逻辑**：重写 `BaseAPITestCase` 中一个或多个 `generate_*` 或 `validate_*` 方法。在这些方法中，积极使用框架提供的工具函数和基类辅助方法。
### 2. `BaseAPITestCase` 核心生命周期方法
这些方法由测试编排器在测试执行的不同阶段调用。
* **`__init__(self, endpoint_spec: Dict[str, Any], global_api_spec: Dict[str, Any], json_schema_validator: Optional[Any], llm_service: Optional[Any])`**:
* 构造函数。`endpoint_spec` 包含当前测试端点的 API 定义（已经过 `$ref` 解析），`global_api_spec` 包含完整的 API 规范。
* 基类会初始化 `self.logger`，可用于记录日志。`json_schema_validator` 和 `llm_service` 也会被存储。
* **请求生成与修改方法**: 在 API 请求发送前调用，用于修改或生成请求数据。
* `generate_path_params(self, current_path_params: Dict[str, Any]) -> Dict[str, Any]`
* `generate_query_params(self, current_query_params: Dict[str, Any]) -> Dict[str, Any]`
* `generate_headers(self, current_headers: Dict[str, str]) -> Dict[str, str]`
* `generate_request_body(self, current_body: Optional[Any]) -> Optional[Any]`
* `modify_request_url(self, current_url: str) -> str`
* **请求预校验方法**: 在请求数据完全构建后、发送前调用，用于静态检查。返回 `List[ValidationResult]`。
* `validate_request_url(self, url: str, request_context: APIRequestContext) -> List[ValidationResult]`
* `validate_request_headers(self, headers: Dict[str, str], request_context: APIRequestContext) -> List[ValidationResult]`
* `validate_request_body(self, body: Optional[Any], request_context: APIRequestContext) -> List[ValidationResult]`
* **响应验证方法**: 在收到 API 响应后调用，这是最主要的验证阶段。返回 `List[ValidationResult]`。
* `validate_response(self, response_context: APIResponseContext, request_context: APIRequestContext) -> List[ValidationResult]`
* 检查状态码、响应头、响应体内容是否符合预期。
* 进行业务逻辑相关的断言。
* **性能检查方法**:
* `check_performance(self, response_context: APIResponseContext, request_context: APIRequestContext) -> List[ValidationResult]`
* 通常用于检查响应时间 `response_context.elapsed_time`。
### 3. `BaseAPITestCase` 提供的辅助方法
这些方法旨在简化测试用例中常见的任务：
* **`_get_resolved_request_body_schema(self) -> Optional[Dict[str, Any]]`**:
* 从 `self.endpoint_spec` 中提取请求体的 schema。它会自动处理常见的 content-type (如 `application/json`) 并考虑 OpenAPI 2.0 的 `in: body` 参数风格。
* 返回的 schema 已经由编排器进行过 `$ref` 解析。
* **`_find_removable_field_path(self, schema_to_search: Optional[Dict[str, Any]], schema_name_for_log: str) -> Optional[List[Union[str, int]]]`**:
* 在给定的 `schema_to_search` 中查找第一个可移除的必填字段的路径。
* 内部调用 `schema_utils.util_find_removable_field_path_recursive`。
* 适用于构造"缺失必填字段"之类的测试场景。
* `schema_name_for_log` 用于日志记录，例如 "request body"。
* **`_find_simple_type_field_in_schema(self, schema_to_search: Optional[Dict[str, Any]], schema_name_for_log: str) -> Optional[Tuple[List[Union[str, int]], str, Dict[str, Any]]]`**:
* 在给定的 `schema_to_search` (应为已解析的字典) 中查找第一个简单类型 (string, integer, number, boolean) 字段。
* 内部调用 `schema_utils.find_first_simple_type_field_recursive`。
* 返回一个元组 `(field_path, field_type, field_schema)` 或 `None`。
* 适用于构造"字段类型不匹配"之类的测试场景。
* **`_find_first_simple_type_parameter(self, param_location: str) -> Optional[Tuple[List[Union[str, int]], str, Dict[str, Any], str]]`**:
* 在指定的参数位置 (`param_location`，如 "query", "header") 查找第一个简单类型的参数或参数内部的简单类型字段。
* 它会检查参数是否直接是简单类型，或者其 `schema` 是否为简单类型或包含简单类型的对象。
* 如果参数的 schema 是对象，它会调用 `_find_simple_type_field_in_schema` 来查找嵌套字段。
* 返回 `(full_path, param_type, param_schema, top_level_param_name)` 或 `None`。
* `full_path` 可能是 `['paramName']` 或 `['paramName', 'nestedField']`。
* **`_find_required_parameter_name(self, param_in: str) -> Optional[str]`**:
* 查找指定位置 (`param_in`，如 "query", "header", "path") 的第一个必填参数的名称。
* **`expect_error_response(self, response_context: APIResponseContext, expected_status_codes: List[int], expected_error_code_in_body: Optional[Union[str, int]] = None, error_code_field_name: str = "code", context_message_prefix: str = "Error response validation") -> List[ValidationResult]` (新增)**:
* 一个标准化的方法来验证错误响应。
* 检查 `response_context.status_code` 是否在 `expected_status_codes` 列表中。
* 可选地，检查响应体 (如果是JSON对象) 中 `error_code_field_name` 字段的值是否等于 `expected_error_code_in_body`。
* 返回包含详细信息的 `ValidationResult` 列表。
* 示例：
```python
# 在某个测试用例的 validate_response 中
if not self.target_field_path: # 假设此用例需要一个目标字段
return [self.passed("Skipped: No target field identified.")]
field_desc = f"body field '{'.'.join(map(str, self.target_field_path))}'"
return self.expect_error_response(
response_context=response_context,
expected_status_codes=[400, 422],
expected_error_code_in_body="4001",
context_message_prefix=f"Missing required {field_desc}"
)
```
* **`validate_data_against_schema(self, data_to_validate: Any, schema_definition: Dict[str, Any], context_message_prefix: str = "Data") -> List[ValidationResult]`**:
* 使用注入的 `JSONSchemaValidator` (如果可用) 来验证数据是否符合给定的 schema。
* **`passed(message: str, details: Optional[Dict[str, Any]] = None) -> ValidationResult` (静态方法)**:
* 快速创建表示"通过"的 `ValidationResult`。
* **`failed(message: str, details: Optional[Dict[str, Any]] = None) -> ValidationResult` (静态方法)**:
* 快速创建表示"失败"的 `ValidationResult`。
### 4. `ddms_compliance_suite.utils` 工具模块
#### 4.1 `schema_utils.py`
这个模块包含处理 JSON Schema、API 参数和数据结构的函数。
* **`resolve_json_schema_references(schema_to_resolve: Any, full_api_spec: Dict[str, Any], ..., discard_refs: bool = True) -> Any`**:
* 递归解析 JSON Schema 中的 `$ref` 引用。
* `discard_refs=True` (默认) 会在解析前移除 `$ref` 和以 `$$` 开头的键。如果为 `False`，则尝试解析 `$ref` 并保留其他键。
* 此函数主要由测试编排器在实例化测试用例前调用。测试用例通常不需要直接使用它，因为 `endpoint_spec` 已经预处理过了。
* **`util_find_removable_field_path_recursive(current_schema: Dict[str, Any], current_path: List[Union[str, int]], full_api_spec_for_refs: Dict[str, Any]) -> Optional[List[Union[str, int]]]`**:
* 递归地在（可能包含 `$ref` 的）`current_schema` 中查找第一个可移除的必填字段的路径。
* 主要被 `BaseAPITestCase._find_removable_field_path` 调用。
* **`util_remove_value_at_path(data_container: Any, path: List[Union[str, int]]) -> Tuple[Any, Any, bool]`**:
* 从嵌套的字典/列表中移除指定路径的值。
* 返回 `(修改后的容器, 被移除的值, 是否成功)`。
* 示例：
```python
# 在某个测试用例的 generate_request_body 中
if self.removable_field_path:
modified_body, removed_value, success = schema_utils.util_remove_value_at_path(
current_body, self.removable_field_path
)
if success:
self.logger.info(f"Removed value '{removed_value}' from path '{'.'.join(map(str, self.removable_field_path))}'.")
return modified_body
return current_body
```
* **`util_set_value_at_path(data_container: Any, path: List[Union[str, int]], new_value: Any) -> Tuple[Any, bool]` (新增)**:
* 在嵌套的字典/列表中为指定路径设置或修改 `new_value`。
* 如果路径中的父级结构不存在，会尝试创建它们（字典会被创建，列表会用 `None` 填充到所需索引）。
* 返回 `(修改后的容器, 是否成功)`。
* 示例：
```python
# 在某个测试用例的 generate_request_body 中
if self.target_field_path and self.mismatched_value is not None:
modified_body, success = schema_utils.util_set_value_at_path(
current_body, self.target_field_path, self.mismatched_value
)
if success:
return modified_body
return current_body
```
* **`generate_mismatched_value(original_type: Optional[str], original_value: Any, field_schema: Optional[Dict[str, Any]], logger_param: Optional[logging.Logger] = None) -> Any` (新增)**:
* 根据字段的 `original_type`、`original_value`（当前未使用）和 `field_schema`（用于检查 `enum` 等约束）生成一个类型不匹配的值。
* 适用于类型不匹配的测试场景。
* 示例：
```python
# 在某个测试用例的 __init__ 或 generate_ 方法中
if self.original_field_type: # 假设 self.original_field_type 已被正确设置
self.mismatched_val = schema_utils.generate_mismatched_value(
self.original_field_type,
None, # original_value, 暂时可以为 None
self.target_field_schema, # 字段的 schema
self.logger
)
```
* **`build_object_schema_for_params(params_spec_list: List[Dict[str, Any]], model_name_base: str, ...) -> Tuple[Optional[Dict[str, Any]], str]`**:
* 从参数规范列表（例如 OpenAPI 参数对象列表）构建一个聚合的 JSON 对象 schema。
* 可用于将多个查询参数或头部参数统一表示为一个对象 schema，方便进行 schema 校验或数据生成。
* **`find_first_simple_type_field_recursive(current_schema: Dict[str, Any], ...) -> Optional[Tuple[List[Union[str, int]], str, Dict[str, Any]]]`**:
* 递归地在已解析的 `current_schema` 中查找第一个简单类型的字段 (string, integer, number, boolean)，包括嵌套在对象或数组中的。
* 主要被 `BaseAPITestCase._find_simple_type_field_in_schema` 调用。
#### 4.2 `common_utils.py`
* **`format_url_with_path_params(base_url: str, path_template: str, path_params: Dict[str, Any]) -> str`**:
* 将路径模板中的占位符 (如 `{userId}`) 替换为 `path_params` 中提供的值，并与 `base_url` 组合成完整的 URL。
### 5. 核心数据类
* **`ValidationResult(passed: bool, message: str, details: Optional[Dict[str, Any]] = None)`**:
* 封装单个验证点的结果。所有 `validate_*` 和 `check_*` 方法都应返回此对象的列表。
* **`APIRequestContext`**: 包含当前请求的详细信息（方法、URL、参数、头、体、端点规范）。
* **`APIResponseContext`**: 包含 API 响应的详细信息（状态码、头、JSON 内容、文本内容、耗时、原始响应对象、关联的请求上下文）。
### 6. 编写测试用例的推荐流程
1. **明确测试目标**：这个测试用例要验证什么？是参数处理、错误响应、数据格式还是业务逻辑？
2. **选择合适的基类方法**：
* 如果需要修改请求数据（参数、头部、请求体），重写相应的 `generate_*` 方法。
* 如果需要在发送前对请求的静态结构进行校验，重写 `validate_request_*` 方法。
* 核心的响应验证逻辑通常在 `validate_response` 中实现。
* 性能相关的检查在 `check_performance` 中。
3. **初始化 (在 `__init__` 中)**:
* 调用 `super().__init__(...)`。
* 如果测试依赖于特定的请求体字段或参数：
* 获取请求体 schema: `body_schema = self._get_resolved_request_body_schema()`。
* 查找必填字段进行移除测试: `path = self._find_removable_field_path(body_schema, "request body")`。
* 查找简单类型字段进行类型不匹配测试 (请求体): `target = self._find_simple_type_field_in_schema(body_schema, "request body")`。
* 查找简单类型参数进行类型不匹配测试 (查询/头部): `target = self._find_first_simple_type_parameter("query")`。
* 查找必填参数名称: `name = self._find_required_parameter_name("query")`。
* 将找到的目标路径、类型、schema 等信息存储在 `self` 的属性中，供后续方法使用。
4. **生成/修改请求数据 (在 `generate_*` 方法中)**:
* 如果需要移除字段，使用 `schema_utils.util_remove_value_at_path()`。
* 如果需要修改字段值（例如进行类型不匹配测试）：
1. 使用 `schema_utils.generate_mismatched_value()` 生成不匹配的值。
2. 使用 `schema_utils.util_set_value_at_path()` 将该值设置到请求数据中。
5. **验证响应 (在 `validate_response` 方法中)**:
* 如果测试期望一个错误响应，优先使用 `self.expect_error_response()`。
* 如果需要验证响应体数据是否符合特定的 JSON Schema，使用 `self.validate_data_against_schema()`。
* 对于其他自定义的断言，直接比较 `response_context` 中的属性（如 `status_code`, `json_content`）并使用 `self.passed()` 或 `self.failed()` 创建 `ValidationResult`。
6. **日志记录**: 在关键步骤使用 `self.logger.info()`, `self.logger.debug()`, `self.logger.warning()` 等记录信息，便于调试。
通过遵循这些指南并善用框架提供的工具，您可以更高效地编写出简洁、健壮且易于维护的 API 合规性测试用例。
docs/Multi_Service_Docker_Summary.md
+236
View File
@@ -0,0 +1,236 @@
# 多服务Docker配置总结
## 🎯 实现目标
成功将DMS合规性测试工具配置为在单个Docker容器中运行两个服务：
1. **API服务器** (api_server.py) - 端口5050
2. **历史查看器** (history_viewer.py) - 端口5051
## 🔧 技术方案
### 方案1：Supervisor管理（推荐）
**文件**: `Dockerfile.service` + `supervisord.conf`
**优势**:
- 进程管理更稳定
- 自动重启失败的服务
- 详细的日志管理
- 生产环境推荐
**配置**:
```dockerfile
# 安装supervisor
RUN apt-get install -y supervisor
# 使用supervisor启动
CMD ["/usr/bin/supervisord", "-c", "/etc/supervisor/conf.d/supervisord.conf"]
```
### 方案2：Shell脚本管理
**文件**: `Dockerfile.simple` + `start_services.sh`
**优势**:
- 配置简单
- 容易理解和调试
- 适合开发环境
**配置**:
```bash
# 后台启动两个服务
python api_server.py &
python history_viewer.py &
```
## 📁 新增文件
| 文件 | 说明 | 方案 |
|------|------|------|
| `supervisord.conf` | Supervisor配置文件 | 方案1 |
| `start_services.sh` | 多服务启动脚本 | 方案2 |
| `Dockerfile.simple` | 简单版Dockerfile | 方案2 |
| `test_multi_service.py` | 多服务测试脚本 | 通用 |
## 🚀 使用方法
### 构建和启动
```bash
# 使用自动化脚本（推荐）
./docker-build.sh
# 手动构建（Supervisor方案）
docker build -f Dockerfile.service -t dms-compliance-tool .
docker run -d --name dms-compliance-tool -p 5050:5050 -p 5051:5051 dms-compliance-tool
# 手动构建（Shell脚本方案）
docker build -f Dockerfile.simple -t dms-compliance-tool:simple .
docker run -d --name dms-compliance-tool -p 5050:5050 -p 5051:5051 dms-compliance-tool:simple
```
### 访问服务
- **API服务器**: http://localhost:5050
- **历史查看器**: http://localhost:5051
### 测试服务
```bash
# 使用专用测试脚本
python test_multi_service.py
# 或使用Docker测试脚本
./test-docker.sh
```
## 📊 端口配置
| 服务 | 容器内端口 | 主机端口 | 说明 |
|------|------------|----------|------|
| API服务器 | 5050 | 5050 | 主要的API测试服务 |
| 历史查看器 | 5051 | 5051 | 测试历史查看和管理 |
## 🔍 服务监控
### 查看服务状态
```bash
# 查看容器状态
docker ps
# 查看所有服务日志
docker logs dms-compliance-tool
# 使用Supervisor查看服务状态（方案1）
docker exec dms-compliance-tool supervisorctl status
# 查看单个服务日志（方案1）
docker exec dms-compliance-tool tail -f /var/log/supervisor/api_server.log
docker exec dms-compliance-tool tail -f /var/log/supervisor/history_viewer.log
```
### 健康检查
```bash
# 自动健康检查
curl http://localhost:5050/
curl http://localhost:5051/
# 使用测试脚本
python test_multi_service.py
```
## 🛠️ 故障排除
### 常见问题
1. **端口冲突**
```bash
# 检查端口占用
lsof -i :5050 -i :5051
# 修改端口映射
docker run -p 8050:5050 -p 8051:5051 ...
```
2. **服务启动失败**
```bash
# 查看详细日志
docker logs dms-compliance-tool
# 进入容器调试
docker exec -it dms-compliance-tool bash
```
3. **服务间通信问题**
```bash
# 检查容器内网络
docker exec dms-compliance-tool netstat -tlnp
```
### 调试命令
```bash
# 查看进程状态
docker exec dms-compliance-tool ps aux
# 查看端口监听
docker exec dms-compliance-tool netstat -tlnp
# 重启单个服务（Supervisor方案）
docker exec dms-compliance-tool supervisorctl restart api_server
docker exec dms-compliance-tool supervisorctl restart history_viewer
```
## 📈 性能优化
### 资源限制
```bash
# 设置内存和CPU限制
docker run -d \
--name dms-compliance-tool \
--memory=1g \
--cpus=1.0 \
-p 5050:5050 -p 5051:5051 \
dms-compliance-tool
```
### 日志管理
```bash
# 限制日志大小
docker run -d \
--log-driver json-file \
--log-opt max-size=10m \
--log-opt max-file=3 \
dms-compliance-tool
```
## 🔄 更新和维护
### 服务更新
```bash
# 停止容器
docker stop dms-compliance-tool
# 重新构建
./docker-build.sh --clean
# 或使用Docker Compose
docker-compose down
docker-compose build --no-cache
docker-compose up -d
```
### 数据备份
```bash
# 备份测试报告和数据
docker cp dms-compliance-tool:/app/test_reports ./backup/
docker cp dms-compliance-tool:/app/uploads ./backup/
```
## ✅ 验证清单
部署完成后，请验证以下项目：
- [ ] 容器正常启动：`docker ps`
- [ ] API服务可访问：`curl http://localhost:5050`
- [ ] 历史查看器可访问：`curl http://localhost:5051`
- [ ] 健康检查通过：`docker inspect dms-compliance-tool | grep Health`
- [ ] 日志正常：`docker logs dms-compliance-tool`
- [ ] 数据持久化：重启容器后数据仍存在
- [ ] 多服务测试通过：`python test_multi_service.py`
## 🎉 优势总结
1. **单容器部署**：简化部署流程，减少管理复杂度
2. **服务隔离**：两个服务独立运行，互不影响
3. **统一管理**：通过一个容器管理多个相关服务
4. **资源共享**：共享文件系统和网络资源
5. **便于维护**：统一的日志、监控和更新流程
现在您可以在一个Docker容器中同时运行API服务器和历史查看器，实现完整的DMS合规性测试工具功能！
docs/PDF_Fix_Summary.md
+155
View File
@@ -0,0 +1,155 @@
# PDF报告修复总结
## 🐛 发现的问题
您在使用mock程序测试时发现了两个重要问题：
1. **测试用例表格只显示了15个用例**：虽然实际有40个测试用例，但PDF报告中的表格被限制只显示前15个
2. **缺少Stage用例**：Stage测试用例没有被包含在测试用例列表中，但Stage用例也应该算作测试用例
## ✅ 修复内容
### 1. 移除数量限制
**修复前**：
```python
for i, case in enumerate(all_test_cases[:15], 1): # 限制显示前15个用例
```
**修复后**：
```python
for i, case in enumerate(all_test_cases, 1): # 显示所有测试用例，不限制数量
```
### 2. 包含Stage测试用例
**新增功能**：
```python
# 2. 收集stage测试用例
stage_results = summary_data.get('stage_results', [])
for stage_result in stage_results:
stage_name = stage_result.get('stage_name', 'N/A')
stage_status = stage_result.get('overall_status', 'N/A')
# 将stage作为一个测试用例添加
all_test_cases.append({
'type': 'Stage',
'endpoint': f"Stage: {stage_name}",
'case_name': stage_result.get('description', stage_name),
'status': stage_status,
'severity': 'HIGH' # Stage用例通常是高优先级
})
```
### 3. 优化表格结构
**新的表格列**：
- 序号
- **类型**（新增：区分Endpoint/Stage）
- 测试用例名称
- 所属端点/阶段
- 优先级
- 执行结果
### 4. 添加统计信息
**新增统计**：
```python
total_cases = len(all_test_cases)
endpoint_cases = len([c for c in all_test_cases if c['type'] == 'Endpoint'])
stage_cases = len([c for c in all_test_cases if c['type'] == 'Stage'])
stats_text = f"测试用例统计：总计 {total_cases} 个用例，其中端点用例 {endpoint_cases} 个，阶段用例 {stage_cases} 个。"
```
## 🔧 修改的文件
1. **`run_api_tests.py`** - 命令行工具的PDF生成函数
2. **`api_server.py`** - Web服务的PDF生成函数
## 🧪 验证结果
### 使用真实测试数据验证：
```
📊 真实测试数据统计:
- 总测试用例数: 40
- 端点数: 10
- Stage数: 2
- 测试成功率: 70.00%
- 实际端点测试用例: 40
- 实际Stage测试用例: 2
- 实际总用例数: 42
✅ PDF报告生成成功!
📄 文件大小: 87.88 KB
🎯 验证结果:
- ✅ 包含所有endpoint测试用例
- ✅ 包含所有stage测试用例
- ✅ 无数量限制，显示完整列表
- ✅ 区分用例类型（Endpoint/Stage）
- ✅ 包含用例统计信息
```
## 📊 修复前后对比
| 项目 | 修复前 | 修复后 |
|------|--------|--------|
| 显示用例数量 | 最多15个 | 全部显示（40+个） |
| Stage用例 | ❌ 不包含 | ✅ 包含 |
| 用例类型区分 | ❌ 无 | ✅ 有（Endpoint/Stage） |
| 统计信息 | ❌ 无 | ✅ 有详细统计 |
| 表格列数 | 5列 | 6列（新增类型列） |
## 🎯 现在的PDF报告包含
### 测试用例列表表格
```
┌────┬────────┬────────────────────┬──────────────┬────────┬────────┐
│序号│ 类型 │ 测试用例名称 │ 所属端点/阶段│ 优先级 │ 执行结果│
├────┼────────┼────────────────────┼──────────────┼────────┼────────┤
│ 1 │Endpoint│ 基本状态码200检查 │ 井信息查询 │CRITICAL│ 通过 │
│ 2 │Endpoint│ 必需请求头验证 │ 井信息查询 │ HIGH │ 失败 │
│...│ ... │ ... │ ... │ ... │ ... │
│ 41 │ Stage │ DMS Full CRUD │Stage: DMS │ HIGH │ 通过 │
│ │ │ Scenario │Full CRUD │ │ │
│ 42 │ Stage │ Keyword Driven │Stage: Keyword│ HIGH │ 通过 │
│ │ │ CRUD Stage │Driven CRUD │ │ │
└────┴────────┴────────────────────┴──────────────┴────────┴────────┘
```
### 用例统计信息
```
测试用例统计：总计 42 个用例，其中端点用例 40 个，阶段用例 2 个。
```
## 🚀 使用方法
### 命令行方式
```bash
python run_api_tests.py --base-url http://localhost:5001 --generate-pdf
```
### Web界面方式
1. 访问 http://localhost:5050
2. 上传API规范文件并执行测试
3. 在历史记录中查看和下载PDF报告
### 验证修复
```bash
# 使用真实数据测试
python test_real_data_pdf.py
# 使用示例数据测试
python test_pdf_optimization.py
```
## 🎉 修复成果
✅ **问题1已解决**：PDF报告现在显示所有40个测试用例，不再有数量限制
✅ **问题2已解决**：Stage用例现在被正确包含在测试用例列表中
✅ **额外改进**：
- 区分用例类型（Endpoint/Stage）
- 添加详细的用例统计信息
- 优化表格布局和可读性
- 保持所有原有的报告格式和内容
现在您的PDF测试报告完全准确地反映了所有测试用例的执行情况！
docs/PDF_Optimization_Summary.md
+143
View File
@@ -0,0 +1,143 @@
# PDF测试报告优化完成总结
## 🎯 优化目标
根据您的需求，我们成功优化了PDF测试报告格式，使其包含以下标准化内容：
### ✅ 已实现的优化内容
1. **报告编码**: 自动生成唯一的报告编码 `DMS-TEST-{时间戳}`
2. **报告名称**: DMS领域数据服务测试分析报告
3. **申请日期**: 自动填入当前日期
4. **申请人**: 系统管理员（可配置）
5. **服务供应商名称**: 数据管理系统(DMS)
6. **摘要**: 包含完整的测试概况和统计信息
### 📊 新增的表格内容
#### API服务列表表格
```
┌────┬──────────────────┬──────────────────┬──────────────┬──────────────┐
│序号│ 服务名称 │ 服务功能描述 │ 服务参数描述 │ 服务返回值描述│
├────┼──────────────────┼──────────────────┼──────────────┼──────────────┤
│ 1 │ 井信息查询服务 │ 提供通过井名检索 │ 标准DMS参数 │ 标准DMS响应 │
│ 2 │ 分层信息表查询 │ 分层数据表CRUD │ 标准DMS参数 │ 标准DMS响应 │
│ 3 │ 测井曲线解析服务 │ wis、las解析 │ 标准DMS参数 │ 标准DMS响应 │
└────┴──────────────────┴──────────────────┴──────────────┴──────────────┘
```
#### 测试用例列表表格
```
┌────┬────────────────────┬──────────────┬────────┬────────┐
│序号│ 测试用例名称 │ 所属端点 │ 优先级 │ 执行结果│
├────┼────────────────────┼──────────────┼────────┼────────┤
│ 1 │ 基本状态码200检查 │ 井信息查询 │ CRITICAL│ 通过 │
│ 2 │ 必需请求头验证 │ 井信息查询 │ HIGH │ 失败 │
│ 3 │ JSON Schema验证 │ 井信息查询 │ CRITICAL│ 通过 │
└────┴────────────────────┴──────────────┴────────┴────────┘
```
### 📝 新增的文档内容
#### 测试情况说明
- 测试版本信息：DMS领域数据管理服务V1.0版本
- 缺陷统计：第一轮测试累计发现缺陷数量
- 测试环境：开发测试环境
- 测试方法：自动化API合规性测试
- 测试时间范围：完整的开始和结束时间
#### 测试结论（智能生成）
根据测试成功率自动生成结论：
- **成功率≥90%**: "本套领域数据服务已通过环境验证，系统可以正常运行。验收测试通过..."
- **成功率70-89%**: "本套领域数据服务基本满足验收要求，但存在部分问题需要修复..."
- **成功率<70%**: "本套领域数据服务未达到验收标准，存在较多问题需要修复..."
#### 检测依据
- 集成开发应用支撑系统开放数据生态数据共享要求和评价第1部分
- 关于DMS领域数据服务的接口要求和测试细则
- 参考标准列表（DMS API规范、RESTful规范等）
## 🔧 技术实现
### 修改的文件
1. **`run_api_tests.py`** - 命令行工具的PDF生成函数
2. **`api_server.py`** - Web服务的PDF生成函数
### 关键技术点
- 使用ReportLab库生成专业PDF报告
- 自动化报告编码生成（基于时间戳）
- 智能测试结论生成（基于成功率）
- 表格数据自动提取和格式化
- 统一的中文字体支持
## 🧪 测试验证
### 测试脚本
创建了 `test_pdf_optimization.py` 用于验证PDF生成功能：
```bash
python test_pdf_optimization.py
```
### 测试结果
✅ PDF报告生成成功
📄 文件大小: 71.55 KB
包含所有优化内容
## 📖 使用方法
### 1. 命令行方式
```bash
python run_api_tests.py --base-url http://localhost:5001 --generate-pdf
```
### 2. Web界面方式
1. 访问 http://localhost:5050
2. 上传API规范文件
3. 配置测试参数
4. 执行测试
5. 在历史记录中查看和下载PDF报告
### 3. 程序化调用
```python
from run_api_tests import save_pdf_report
save_pdf_report(test_data, output_path)
```
## 📄 完整报告结构
```
数据管理服务测试分析报告
├── 1. 报告基本信息表格
│ ├── 报告编码: DMS-TEST-{时间戳}
│ ├── 报告名称: DMS领域数据服务测试分析报告
│ ├── 申请日期: 当前日期
│ ├── 申请人: 系统管理员
│ └── 服务供应商名称: 数据管理系统(DMS)
├── 2. 摘要: 测试概况和统计信息
├── 3. 测试内容包括: API服务列表表格
├── 4. 测试用例列表: 详细的测试用例信息表格
├── 5. 测试情况说明: 测试执行详情
├── 6. 测试结论: 基于成功率的自动结论
├── 7. 检测依据: 相关标准和规范
└── 8. 报告生成信息: 工具和版本信息
```
## 🎉 优化成果
1. **标准化格式**: 符合正式测试报告的标准格式
2. **自动化生成**: 所有内容基于测试数据自动生成
3. **专业外观**: 使用表格和统一样式，外观专业
4. **完整信息**: 包含您要求的所有必要信息
5. **智能结论**: 根据测试结果自动生成合理结论
## 📋 文件清单
- `run_api_tests.py` - 优化后的PDF生成函数
- `api_server.py` - Web服务PDF生成函数
- `test_pdf_optimization.py` - 测试验证脚本
- `example_usage.py` - 使用示例演示
- `PDF_Report_Optimization_Guide.md` - 详细优化指南
- `PDF_Optimization_Summary.md` - 本总结文档
现在您的PDF测试报告已经完全符合标准测试报告格式，包含了报告编码、API列表表格、测试用例列表、测试情况说明、测试结论和检测依据等所有必要内容！
docs/PDF_Report_Optimization_Guide.md
+152
View File
@@ -0,0 +1,152 @@
# PDF测试报告优化指南
## 概述
本文档描述了对DMS合规性测试工具PDF报告格式的优化改进，使其更符合正式测试报告的标准格式。
## 优化前后对比
### 优化前的问题
- 报告格式过于简单，缺乏正式性
- 缺少报告编码、申请人等基本信息
- 没有标准的API服务列表展示
- 缺少测试结论和检测依据
- 整体结构不够规范
### 优化后的改进
- 采用标准测试报告格式
- 增加完整的报告基本信息
- 结构化展示API服务和测试用例
- 包含详细的测试结论和依据
- 提供清晰的测试情况说明
## 新的报告结构
### 1. 报告标题和基本信息
```
数据管理服务测试分析报告
┌─────────────────────────────────────────┐
│ 报告编码 │ DMS-TEST-{时间戳} │
│ 报告名称 │ DMS领域数据服务测试分析报告 │
│ 申请日期 │ 2025年07月30日 │
│ 申请人 │ 系统管理员 │
│ 服务供应商名称│ 数据管理系统(DMS) │
└─────────────────────────────────────────┘
```
### 2. 摘要
包含测试的整体概况，包括：
- 测试目的和范围
- 测试时间和耗时
- 测试统计数据
- 整体成功率
### 3. 测试内容包括（API列表表格）
```
┌────┬──────────────────┬──────────────────┬──────────────┬──────────────┐
│序号│ 服务名称 │ 服务功能描述 │ 服务参数描述 │ 服务返回值描述│
├────┼──────────────────┼──────────────────┼──────────────┼──────────────┤
│ 1 │ 井信息查询服务 │ 提供数据查询服务 │ 标准DMS参数 │ 标准DMS响应 │
│ 2 │ 分层信息表查询服务│ 提供数据查询服务 │ 标准DMS参数 │ 标准DMS响应 │
│ 3 │ 测井曲线解析服务 │ 提供数据管理服务 │ 标准DMS参数 │ 标准DMS响应 │
└────┴──────────────────┴──────────────────┴──────────────┴──────────────┘
```
### 4. 测试用例列表
```
┌────┬────────────────────┬──────────────┬────────┬────────┐
│序号│ 测试用例名称 │ 所属端点 │ 优先级 │ 执行结果│
├────┼────────────────────┼──────────────┼────────┼────────┤
│ 1 │ 基本状态码200检查 │ 井信息查询 │ CRITICAL│ 通过 │
│ 2 │ 必需请求头验证 │ 井信息查询 │ HIGH │ 失败 │
│ 3 │ CRUD操作验证 │ 分层信息表 │ HIGH │ 通过 │
└────┴────────────────────┴──────────────┴────────┴────────┘
```
### 5. 测试情况说明
详细描述测试执行情况，包括：
- 测试版本信息
- 发现的缺陷数量
- 测试环境和方法
- 测试轮次说明
### 6. 测试结论
根据测试结果自动生成结论：
- **成功率≥90%**: 通过验收测试
- **成功率70-89%**: 基本通过，需修复部分问题
- **成功率<70%**: 不通过，需全面检查修复
### 7. 检测依据
列出测试所依据的标准和规范：
- DMS数据管理系统API规范
- RESTful API设计规范
- 数据安全和隐私保护要求
- 系统集成测试标准
### 8. 报告生成信息
```
┌─────────────────────────────────────────┐
│ 生成时间 │ 2025年07月30日 15:45:56 │
│ 生成工具 │ DMS合规性测试工具 │
│ 工具版本 │ V1.0.0 │
│ 测试结论 │ 通过 │
└─────────────────────────────────────────┘
```
## 技术实现
### 主要修改文件
1. `run_api_tests.py` - 命令行工具的PDF生成函数
2. `api_server.py` - Web服务的PDF生成函数
### 关键改进点
1. **报告编码生成**: 使用时间戳生成唯一的报告编码
2. **表格优化**: 使用ReportLab的Table组件创建规范的表格
3. **自动化结论**: 根据测试成功率自动生成测试结论
4. **样式统一**: 定义统一的字体和样式规范
5. **内容结构化**: 按照标准测试报告格式组织内容
### 样式定义
```python
title_style = ParagraphStyle('ChineseTitle', fontSize=22, leading=28)
heading_style = ParagraphStyle('ChineseHeading', fontSize=16, leading=20)
normal_style = ParagraphStyle('ChineseNormal', fontSize=10, leading=14)
small_style = ParagraphStyle('ChineseSmall', fontSize=9, leading=12)
```
## 使用方法
### 命令行使用
```bash
python run_api_tests.py --base-url http://localhost:5001 --generate-pdf
```
### Web界面使用
1. 访问测试工具Web界面
2. 上传API规范文件
3. 配置测试参数
4. 执行测试
5. 在历史记录中查看和下载PDF报告
## 测试验证
运行测试脚本验证PDF生成功能：
```bash
python test_pdf_optimization.py
```
## 注意事项
1. **字体依赖**: 需要确保`assets/fonts/STHeiti-Medium-4.ttc`字体文件存在
2. **ReportLab库**: 需要安装ReportLab库用于PDF生成
3. **内容长度**: 表格内容会自动截断以适应页面布局
4. **编码格式**: 所有文本内容使用UTF-8编码确保中文正确显示
## 后续改进建议
1. **模板化**: 考虑将报告格式模板化，支持自定义报告样式
2. **图表支持**: 添加测试结果的图表展示
3. **多语言**: 支持中英文双语报告
4. **签名功能**: 添加数字签名功能增强报告权威性
5. **导出格式**: 支持导出为Word、Excel等其他格式
docs/Project_Structure.md
+146
View File
@@ -0,0 +1,146 @@
# 项目结构说明
## 📁 整理后的目录结构
```
compliance/
├── 🐍 核心应用文件
│ ├── api_server.py # API服务器 (端口5050)
│ ├── history_viewer.py # 历史查看器 (端口5051)
│ ├── run_api_tests.py # 命令行测试工具
│ └── requirements.txt # Python依赖
│
├── 🐳 Docker相关文件
│ ├── docker-build.sh # Docker构建脚本
│ ├── docker-compose.yml # Docker Compose配置
│ └── docker/
│ ├── Dockerfile.service # 主Dockerfile (Supervisor方案)
│ ├── Dockerfile.simple # 简化版Dockerfile (Shell脚本方案)
│ ├── supervisord.conf # Supervisor配置
│ └── start_services.sh # 多服务启动脚本
│
├── 🧪 测试文件
│ └── tests/
│ ├── test_pdf_optimization.py # PDF优化测试
│ ├── test_strictness_level_pdf.py # 严格等级测试
│ ├── test_updated_summary.py # 摘要更新测试
│ ├── test_multi_service.py # 多服务测试
│ ├── test_real_data_pdf.py # 真实数据测试
│ └── test-docker.sh # Docker测试脚本
│
├── 📚 文档文件
│ └── docs/
│ ├── Docker_Deployment_Guide.md # Docker部署指南
│ ├── Docker_Quick_Reference.md # Docker快速参考
│ ├── Multi_Service_Docker_Summary.md # 多服务Docker总结
│ ├── PDF_Fix_Summary.md # PDF修复总结
│ ├── PDF_Report_Optimization_Guide.md # PDF报告优化指南
│ ├── Strictness_Level_Feature_Summary.md # 严格等级功能总结
│ ├── Summary_Update_Complete.md # 摘要更新完成总结
│ └── Project_Structure.md # 本文档
│
├── 🌐 Web相关文件
│ ├── nginx/
│ │ └── nginx.conf # Nginx反向代理配置
│ ├── static/ # 静态文件
│ └── templates/ # HTML模板
│
├── 📊 数据和配置
│ ├── assets/ # 资源文件
│ ├── memory-bank/ # 项目文档和上下文
│ ├── test_reports/ # 测试报告目录 (运行时生成)
│ ├── uploads/ # 上传文件目录 (运行时生成)
│ └── logs/ # 日志目录 (运行时生成)
│
└── 🔧 配置文件
├── .gitignore # Git忽略文件
├── .dockerignore # Docker忽略文件
└── README.md # 项目说明
```
## 📋 文件分类说明
### 核心应用文件
- **api_server.py**: 主要的API测试服务，提供Web界面和API端点
- **history_viewer.py**: 测试历史查看器，用于管理和查看测试记录
- **run_api_tests.py**: 命令行测试工具，支持批量测试和PDF生成
### Docker相关文件
- **docker-build.sh**: 自动化Docker构建和部署脚本
- **docker-compose.yml**: Docker Compose配置，支持一键部署
- **docker/**: Docker相关配置文件目录
- **Dockerfile.service**: 使用Supervisor管理多进程的主Dockerfile
- **Dockerfile.simple**: 使用Shell脚本管理的简化版Dockerfile
- **supervisord.conf**: Supervisor进程管理配置
- **start_services.sh**: 多服务启动脚本
### 测试文件
- **tests/**: 所有测试脚本的集中目录
- PDF相关测试：验证PDF报告生成功能
- 严格等级测试：验证测试用例分离功能
- 多服务测试：验证Docker多服务部署
- Docker测试：验证Docker镜像构建和运行
### 文档文件
- **docs/**: 所有文档的集中目录
- 部署指南：详细的Docker部署说明
- 功能总结：各个功能的实现总结
- 快速参考：常用命令和操作指南
## 🎯 整理的优势
### 1. 清晰的结构
- 按功能分类，便于查找和维护
- 核心代码与辅助文件分离
- 文档和测试独立管理
### 2. 简化的根目录
- 只保留最重要的核心文件
- 减少根目录的文件数量
- 提高项目的可读性
### 3. 便于维护
- 相关文件集中管理
- 便于版本控制和协作
- 易于添加新的测试和文档
### 4. Docker友好
- Docker相关文件集中管理
- 路径引用已更新
- 支持多种部署方案
## 🔄 迁移说明
### 已完成的文件移动
1. **Docker文件** → `docker/` 目录
2. **测试脚本** → `tests/` 目录
3. **文档文件** → `docs/` 目录
### 已更新的路径引用
1. **docker-build.sh**: 更新Dockerfile路径为 `docker/Dockerfile.service`
2. **docker-compose.yml**: 更新dockerfile路径
3. **Dockerfile**: 更新内部文件复制路径
### Git忽略文件
- 完善的.gitignore文件，包含Python、Docker、IDE等常见忽略项
- 保护敏感文件和临时文件
- 避免提交不必要的文件
## 🚀 使用建议
### 开发时
- 在根目录运行核心应用
- 使用 `tests/` 目录中的脚本进行测试
- 参考 `docs/` 目录中的文档
### 部署时
- 使用 `./docker-build.sh` 进行Docker部署
- 或使用 `docker-compose up -d` 进行服务编排
- 查看 `docs/Docker_Deployment_Guide.md` 获取详细指导
### 维护时
- 新的测试脚本放入 `tests/` 目录
- 新的文档放入 `docs/` 目录
- Docker相关修改在 `docker/` 目录中进行
这样的结构使项目更加专业和易于管理！
docs/Strictness_Level_Feature_Summary.md
+151
View File
@@ -0,0 +1,151 @@
# 严格等级功能实现总结
## 🎯 实现的功能
根据您的需求，我们成功实现了基于严格等级（strictness-level）将PDF报告中的测试用例分为两部分的功能：
### 1. 必须的测试用例
- 严重性等于或高于设定级别的用例
- 这些用例的失败会影响API端点的最终测试结果
- 在PDF中用浅蓝色背景突出显示
### 2. 非必须的测试用例
- 严重性低于设定级别的用例
- 这些用例的失败不会影响API端点的最终测试结果
- 在PDF中用浅灰色背景显示
## 🔧 技术实现
### 严重性等级映射
```python
severity_levels = {
'CRITICAL': 5,
'HIGH': 4,
'MEDIUM': 3,
'LOW': 2,
'INFO': 1
}
```
### 用例分类逻辑
```python
# 根据严格等级判断是否为必须用例
is_required = tc_severity_value >= strictness_value
```
### PDF报告结构
1. **严格等级说明**：显示当前设定的严格等级
2. **必须的测试用例表格**：浅蓝色背景，影响测试结果
3. **非必须的测试用例表格**：浅灰色背景，不影响测试结果
4. **详细统计信息**：包含必须/非必须用例的数量分布
## 📊 摘要内容优化
### 修改前
```
共测试 X 个API端点，执行 Y 个测试用例，
其中 Z 个通过，W 个失败，测试用例成功率为 P%。
```
### 修改后
```
共测试 X 个API端点，其中 A 个通过，B 个失败，端点成功率为 Q%。
执行 Y 个测试用例，其中 Z 个通过，W 个失败，测试用例成功率为 P%。
```
## 🧪 测试验证结果
使用不同严格等级测试，结果如下：
| 严格等级 | 必须用例数 | 非必须用例数 | 总用例数 | 说明 |
|----------|------------|--------------|----------|------|
| CRITICAL | 2个 | 8个 | 10个 | 只有CRITICAL级别用例为必须 |
| HIGH | 6个 | 4个 | 10个 | CRITICAL+HIGH级别用例为必须 |
| MEDIUM | 8个 | 2个 | 10个 | CRITICAL+HIGH+MEDIUM级别用例为必须 |
| LOW | 9个 | 1个 | 10个 | CRITICAL+HIGH+MEDIUM+LOW级别用例为必须 |
## 📋 PDF报告新增内容
### 1. 严格等级说明
```
当前严格等级：HIGH。根据此等级，测试用例被分为必须执行和非必须执行两部分。
```
### 2. 分离的测试用例表格
#### 必须的测试用例（影响测试结果）
- 浅蓝色表头背景
- 包含所有严重性≥设定级别的用例
- 包括Endpoint用例和Stage用例
#### 非必须的测试用例（不影响测试结果）
- 浅灰色表头背景
- 包含所有严重性<设定级别的用例
### 3. 详细统计信息
```
测试用例统计：
总计 10 个用例，其中端点用例 8 个，阶段用例 2 个。
必须用例 6 个，非必须用例 4 个。
严格等级：HIGH（4级及以上为必须）。
```
## 🚀 使用方法
### 命令行方式
```bash
# 使用CRITICAL级别（默认）
python run_api_tests.py --base-url http://localhost:5001 --strictness-level CRITICAL
# 使用HIGH级别
python run_api_tests.py --base-url http://localhost:5001 --strictness-level HIGH
# 使用MEDIUM级别
python run_api_tests.py --base-url http://localhost:5001 --strictness-level MEDIUM
```
### Web界面方式
1. 访问 http://localhost:5050
2. 在测试配置中选择严格等级
3. 上传API规范文件并执行测试
4. 下载PDF报告查看分离的用例列表
## 🎨 视觉区分
### 必须用例表格
- **表头背景**：浅蓝色 (`colors.lightblue`)
- **标题**：必须的测试用例（影响测试结果）
- **含义**：这些用例的失败会导致端点被标记为失败
### 非必须用例表格
- **表头背景**：浅灰色 (`colors.lightgrey`)
- **标题**：非必须的测试用例（不影响测试结果）
- **含义**：这些用例的失败不会影响端点的最终状态
## 📈 实际应用场景
### 1. 严格测试（CRITICAL级别）
- 只有最关键的用例失败才影响结果
- 适用于快速验证核心功能
- 大部分用例为非必须，提供额外信息
### 2. 标准测试（HIGH级别）
- 关键和重要用例失败都影响结果
- 适用于常规的合规性测试
- 平衡了严格性和全面性
### 3. 全面测试（MEDIUM/LOW级别）
- 大部分用例失败都影响结果
- 适用于详细的质量检查
- 确保高质量标准
## ✅ 完成的改进
1. ✅ **根据严格等级分离用例**：必须 vs 非必须
2. ✅ **视觉区分**：不同颜色的表格背景
3. ✅ **详细统计**：显示各类用例的数量分布
4. ✅ **摘要优化**：添加端点通过数量数据
5. ✅ **灵活配置**：支持4个严格等级选择
6. ✅ **完整测试**：验证所有级别的正确性
现在您的PDF测试报告能够根据严格等级智能地将测试用例分为必须和非必须两部分，并提供清晰的视觉区分和详细的统计信息！
docs/Summary_Update_Complete.md
+104
View File
@@ -0,0 +1,104 @@
# 摘要内容更新完成总结
## 🎯 更新内容
根据您的要求，我已经成功在PDF报告的摘要中添加了Stage测试（流程测试）的通过率信息。
## 📊 完整的摘要格式
### 更新后的摘要包含三个部分：
#### 1. API端点测试统计
```
共测试 X 个API端点，其中 A 个通过，B 个失败，C个跳过，端点成功率为 P%。
```
#### 2. 测试用例统计
```
执行 Y 个测试用例，其中 D 个通过，E 个失败，F个跳过，测试用例成功率为 Q%。
```
#### 3. 流程测试统计（新增）
```
执行 Z 个流程测试，其中 G 个通过，H 个失败，I个跳过，流程测试成功率为 R%。
```
## 🔍 实际示例
基于测试数据，摘要内容如下：
```
本次测试针对DMS（数据管理系统）领域数据服务进行全面的合规性验证。
测试时间：2025-07-31 10:00:00 至 2025-07-31 10:08:45，总耗时 525.75 秒。
共测试 10 个API端点，其中 7 个通过，2 个失败，1个跳过，端点成功率为 70.00%。
执行 48 个测试用例，其中 35 个通过，10 个失败，3个跳过，测试用例成功率为 72.92%。
执行 3 个流程测试，其中 2 个通过，1 个失败，0个跳过，流程测试成功率为 66.67%。
```
## 📈 统计信息来源
摘要中的数据来自 `overall_summary` 对象的以下字段：
### 端点统计
- `endpoints_tested` - 测试的端点数量
- `endpoints_passed` - 通过的端点数量
- `endpoints_failed` - 失败的端点数量
- `endpoint_success_rate` - 端点成功率
### 测试用例统计
- `total_test_cases_executed` - 执行的测试用例数量
- `test_cases_passed` - 通过的测试用例数量
- `test_cases_failed` - 失败的测试用例数量
- `test_case_success_rate` - 测试用例成功率
### 流程测试统计（新增）
- `total_stages_executed` - 执行的流程测试数量
- `stages_passed` - 通过的流程测试数量
- `stages_failed` - 失败的流程测试数量
- `stage_success_rate` - 流程测试成功率
## 🔧 技术实现
### 跳过数量计算
对于跳过的数量，使用以下计算方式：
```python
# 端点跳过数量
endpoints_skipped = endpoints_tested - endpoints_passed - endpoints_failed
# 测试用例跳过数量
test_cases_skipped = total_test_cases_executed - test_cases_passed - test_cases_failed
# 流程测试跳过数量
stages_skipped = total_stages_executed - stages_passed - stages_failed
```
### 修改的文件
1. **`run_api_tests.py`** - 命令行工具的PDF生成函数
2. **`api_server.py`** - Web服务的PDF生成函数
## ✅ 验证结果
通过测试脚本验证：
- ✅ PDF报告生成成功
- ✅ 摘要包含完整的三类测试统计
- ✅ 每类统计都包含通过、失败、跳过数量和成功率
- ✅ 格式清晰易读，信息完整
## 🎉 完成的功能
现在PDF报告的摘要部分包含：
1. **基本信息**：测试时间、总耗时
2. **端点测试统计**：数量、通过率、详细分布
3. **测试用例统计**：数量、通过率、详细分布
4. **流程测试统计**：数量、通过率、详细分布（新增）
这样用户可以在摘要中快速了解所有类型测试的执行情况和成功率，包括您特别要求的流程测试（Stage测试）信息！
## 🚀 使用方法
更新后的摘要会自动应用到：
- 命令行生成的PDF报告
- Web界面生成的PDF报告
无需额外配置，所有PDF报告都会包含完整的三类测试统计信息。
docs/example_usage.py
+114
View File
@@ -0,0 +1,114 @@
#!/usr/bin/env python3
"""
优化后PDF报告功能的使用示例
演示如何在实际测试场景中生成标准化的测试报告
"""
import json
import sys
from pathlib import Path
import datetime
# 添加项目根目录到Python路径
sys.path.insert(0, str(Path(__file__).parent))
def demonstrate_pdf_optimization():
"""演示PDF报告优化功能"""
print("=" * 60)
print("DMS合规性测试工具 - PDF报告优化演示")
print("=" * 60)
print("\n📋 优化内容概览:")
print("1. 报告编码: 自动生成唯一的报告编码")
print("2. 报告名称: xxx领域数据服务测试分析报告")
print("3. 申请日期: 自动填入当前日期")
print("4. 申请人: 可配置的申请人信息")
print("5. 服务供应商名称: 数据管理系统(DMS)")
print("6. 摘要: 包含测试概况和统计信息")
print("\n📊 测试内容表格:")
print("┌────┬──────────────────┬──────────────────┬──────────────┬──────────────┐")
print("│序号│ 服务名称 │ 服务功能描述 │ 服务参数描述 │ 服务返回值描述│")
print("├────┼──────────────────┼──────────────────┼──────────────┼──────────────┤")
print("│ 1 │ 井信息查询服务 │ 提供通过井名检索 │ 井名、区块等 │ 井基本信息 │")
print("│ │ │ 等方式的井信息 │ 查询参数 │ JSON格式 │")
print("│ │ │ 查询服务 │ │ │")
print("├────┼──────────────────┼──────────────────┼──────────────┼──────────────┤")
print("│ 2 │ 分层信息表查询 │ 分层数据表新增、 │ 分层ID、深度 │ 分层数据列表 │")
print("│ │ 服务 │ 删除、修改、查询 │ 范围等参数 │ JSON格式 │")
print("│ │ │ 服务 │ │ │")
print("├────┼──────────────────┼──────────────────┼──────────────┼──────────────┤")
print("│ 3 │ 测井曲线解析服务 │ 将测井数据体， │ 文件路径、 │ 解析后的曲线 │")
print("│ │ │ 包含wis、las解析 │ 格式类型等 │ 数据JSON格式 │")
print("└────┴──────────────────┴──────────────────┴──────────────┴──────────────┘")
print("\n🧪 测试用例列表:")
print("┌────┬────────────────────┬──────────────┬────────┬────────┐")
print("│序号│ 测试用例名称 │ 所属端点 │ 优先级 │ 执行结果│")
print("├────┼────────────────────┼──────────────┼────────┼────────┤")
print("│ 1 │ 基本状态码200检查 │ 井信息查询 │ CRITICAL│ 通过 │")
print("│ 2 │ 必需请求头验证 │ 井信息查询 │ HIGH │ 失败 │")
print("│ 3 │ JSON Schema验证 │ 井信息查询 │ CRITICAL│ 通过 │")
print("│ 4 │ CRUD操作验证 │ 分层信息表 │ HIGH │ 通过 │")
print("│ 5 │ 数据解析功能验证 │ 测井曲线解析 │ HIGH │ 通过 │")
print("└────┴────────────────────┴──────────────┴────────┴────────┘")
print("\n📝 测试情况说明:")
print("本次测试是对DMS领域数据管理服务V1.0版本下的12个API进行验证测试。")
print("第一轮测试：累计发现缺陷3个。")
print("测试执行时间：2025-07-30 10:00:00 至 2025-07-30 10:05:30")
print("测试环境：开发测试环境")
print("测试方法：自动化API合规性测试")
print("\n✅ 测试结论:")
print("本套领域数据服务已通过环境验证，系统可以正常运行。")
print("验收测试通过标准关于用例执行、DMS业务流相关文档等两个方面分析，")
print("该项目通过验收测试。测试用例成功率达到90.00%，符合验收标准。")
print("\n📚 检测依据:")
print("集成开发应用支撑系统开放数据生态数据共享要求和评价第1部分：")
print("关于DMS领域数据服务的接口要求和测试细则。")
print("参考标准：")
print("1. DMS数据管理系统API规范V1.0")
print("2. RESTful API设计规范")
print("3. 数据安全和隐私保护要求")
print("4. 系统集成测试标准")
print("\n🔧 如何使用优化后的PDF报告:")
print("1. 命令行方式:")
print(" python run_api_tests.py --base-url http://localhost:5001 --generate-pdf")
print("\n2. Web界面方式:")
print(" - 访问 http://localhost:5050")
print(" - 上传API规范文件")
print(" - 配置测试参数")
print(" - 执行测试并下载PDF报告")
print("\n3. 测试验证:")
print(" python test_pdf_optimization.py")
print("\n" + "=" * 60)
print("优化完成！现在的PDF报告包含完整的测试分析内容。")
print("=" * 60)
def show_report_structure():
"""展示报告结构"""
print("\n📄 优化后的PDF报告结构:")
print("├── 1. 报告标题: 数据管理服务测试分析报告")
print("├── 2. 基本信息表格")
print("│ ├── 报告编码: DMS-TEST-{时间戳}")
print("│ ├── 报告名称: DMS领域数据服务测试分析报告")
print("│ ├── 申请日期: 当前日期")
print("│ ├── 申请人: 系统管理员")
print("│ └── 服务供应商名称: 数据管理系统(DMS)")
print("├── 3. 摘要: 测试概况和统计信息")
print("├── 4. 测试内容包括: API服务列表表格")
print("├── 5. 测试用例列表: 详细的测试用例信息")
print("├── 6. 测试情况说明: 测试执行详情")
print("├── 7. 测试结论: 基于成功率的自动结论")
print("├── 8. 检测依据: 相关标准和规范")
print("└── 9. 报告生成信息: 工具和版本信息")
if __name__ == "__main__":
demonstrate_pdf_optimization()
show_report_structure()