59 lines
2.6 KiB
Markdown
59 lines
2.6 KiB
Markdown
# 测试方案-2026-05-21-00-05-04
|
||
|
||
## 测试方案文档路径
|
||
|
||
`工程分析/测试方案-2026-05-21-00-05-04.md`
|
||
|
||
## 静态检查
|
||
|
||
- 执行 `cd WebSite && npm run lint`，确认 TypeScript 类型检查通过。
|
||
- 使用 `rg` 检查旧的 `fileToBase64` 和 JSON 导入链路是否已移除或不再用于项目资产导入。
|
||
|
||
执行结果：`npm run lint` 已通过；项目库导入已不再使用 `fileToBase64` 或 `Promise.all(files.map(...base64))`。
|
||
|
||
## 构建检查
|
||
|
||
- 执行 `cd WebSite && npm run build`，确认生产构建通过。
|
||
|
||
执行结果：`npm run build` 已通过；Vite 仅提示既有 chunk 体积超过 500 kB。
|
||
|
||
## 关键业务场景验证
|
||
|
||
- 项目库 DICOM 影像导入时显示文件数、上传百分比和进度条。
|
||
- 项目库 3D 模型导入时显示文件数、上传百分比和进度条。
|
||
- 上传完成到服务端解压/解析期间显示“服务器处理中”状态。
|
||
- 已有 DICOM/STL 时仍先弹出覆盖提醒。
|
||
- 文件选择器允许普通 DICOM/STL，也允许 `.zip`、`.tar`、`.tar.gz`、`.tgz`、`.gz`。
|
||
|
||
## 医学影像数据相关边界验证
|
||
|
||
- 导入 ZIP 中的 STL 文件后，项目 `modelCount` 和 `stlFiles` 更新。
|
||
- 导入 ZIP/TAR.GZ 中的 DICOM 文件后，项目 `dicomCount` 更新，并生成 DICOM 信息缓存。
|
||
- 压缩包中无关文件不会进入项目资产目录。
|
||
- 路径穿越条目不会写出上传目标目录。
|
||
- 导入后清理 DICOM/STL/Fusion 缓存，避免旧预览残留。
|
||
|
||
执行结果：使用临时项目上传包含 `会厌.stl` 的 ZIP，接口返回 `modelCount: 1`、`stlFiles: ["会厌.stl"]`；验证后已删除临时项目和临时上传目录。
|
||
|
||
## 部署验证
|
||
|
||
- 重启 `tmux` 会话 `revoxelseg-dicom`。
|
||
- 验证：
|
||
- `curl http://127.0.0.1:4000/api/health`
|
||
- `curl -I http://127.0.0.1:4000/`
|
||
- `curl http://127.0.0.1:4000/api/projects` 中默认项目仍为 DICOM 300、STL 9。
|
||
|
||
执行结果：服务已用新代码临时重启并通过 `/api/health`、首页响应验证；当前运行态中默认项目已被用户导入过肝脏 STL，因此最终不以 STL 9 作为强制断言，恢复演示环境仍可回到默认数据。
|
||
|
||
## Git/Gitea 备份验证
|
||
|
||
- `git status --short` 确认暂存范围不包含无关历史删除或软著材料。
|
||
- commit message 包含 `2026-05-21-00-05-04`。
|
||
- 推送到 Gitea `main` 成功。
|
||
|
||
## 风险与回归关注点
|
||
|
||
- 大文件上传进度是上传阶段进度，不代表服务端解压完全结束。
|
||
- `multer` 内存缓存仍会占用服务端内存，后续如需超大数据集，应改为磁盘临时文件流式处理。
|
||
- STL 预览在导入成功后的渲染精度仍需控制，避免一次性加载过多超大构件。
|