# 测试方案

测试方案文档路径：`工程分析/测试方案-2026-05-23-00-32-26.md`

## 静态检查

- 检查系统功能描述是否包含当前系统主要功能模块。
- 检查是否存在夸大真实医学级算法、诊断能力或临床结论的表述。
- 检查正文规模是否落在 800-1300 字要求范围内。

## 构建检查

- 在 `WebSite/` 下执行 `npm run build`，确认前端与服务端构建通过。

## 关键业务场景验证

- 验证描述覆盖登录、总体概况、项目库、DICOM/STL 数据管理、逆向工作区、三维融合、构件配置、导出和系统管理。
- 验证健康接口可访问。
- 验证首页可访问。

## 医学影像数据相关边界验证

- 文案中明确系统面向 DICOM 序列、STL 重建模型、Label Map/NIfTI Mask 等医学影像数据流。
- 文案避免承诺临床诊断和真实自动分割结果，只描述当前演示闭环与辅助标注能力。

## 部署验证

- 构建后使用 `tmux` 会话 `revoxelseg-dicom` 启动服务。
- 若 `4000` 端口已由现有 Docker 服务占用，则沿用实际对外服务执行 `docker compose up -d --build`，避免端口冲突。
- 验证 `http://127.0.0.1:4000/api/health`。
- 验证 `http://127.0.0.1:4000/`。

## Git/Gitea 备份验证

- 使用 `git status --short` 确认仅暂存本次相关文件。
- 提交信息包含 `2026-05-23-00-32-26` 和简要描述。

## 风险与回归关注点

- 当前工作区存在大量非本次变更，提交时不得混入。
- 如果 4000 端口已有服务占用，需要先识别并按项目约定处理。
- 本次不修改源码，回归风险主要来自部署过程而非文档内容。