补充项目列表重新分析后端验证记录
This commit is contained in:
@@ -0,0 +1,35 @@
|
|||||||
|
# 项目管理列表重新分析后端实施记录
|
||||||
|
|
||||||
|
## 本次改动
|
||||||
|
|
||||||
|
- 补充后端实施计划中的验收清单与最小化实现结论
|
||||||
|
- 核验现有项目级重打标链路是否已完整覆盖列表页“重新分析”需求
|
||||||
|
- 运行关键后端测试并新增验证记录、实施记录文档
|
||||||
|
|
||||||
|
## 修改内容
|
||||||
|
|
||||||
|
- 复核 `CcdiBankTagController -> ProjectBankTagRebuildCoordinator -> CcdiBankTagServiceImpl -> CcdiProjectOverviewServiceImpl` 现有链路,确认无需新增接口
|
||||||
|
- 确认手动提交仍复用 `POST /ccdi/project/tags/rebuild`,列表页只需传 `projectId` 即可进入既有重打标流程
|
||||||
|
- 确认任务开始时会切换项目状态为 `TAGGING`,成功后调用 `refreshOverviewEmployeeResults(projectId, operator)` 刷新员工风险结果
|
||||||
|
- 确认 `refreshOverviewEmployeeResults(...)` 会同步回写项目高/中/低风险人数,满足“重新分析后重新计算人数”的后端要求
|
||||||
|
- 本次未新增后端 Java 代码、未新增接口、未新增人数重算分支,仅补充文档与验证沉淀
|
||||||
|
|
||||||
|
## 已验证保护场景
|
||||||
|
|
||||||
|
- 项目存在运行中任务时,手动重打标会被拒绝,避免重复提交
|
||||||
|
- 自动触发与手动触发共享同一协调器锁控制与补跑标记能力
|
||||||
|
- 项目不满足打标前置条件时,仍由既有 `ensureProjectCanStartTagging(projectId)` 负责拦截
|
||||||
|
- 概览刷新失败时,任务会进入失败分支,不会误报执行成功
|
||||||
|
|
||||||
|
## 测试与验证
|
||||||
|
|
||||||
|
```bash
|
||||||
|
mvn -pl ccdi-project -Dtest=CcdiBankTagControllerTest,ProjectBankTagRebuildCoordinatorTest,CcdiBankTagServiceRiskCountRefreshTest test
|
||||||
|
```
|
||||||
|
|
||||||
|
## 结果
|
||||||
|
|
||||||
|
- 后端关键契约测试全部通过
|
||||||
|
- 现有后端链路已经覆盖列表页“重新分析”接线需求
|
||||||
|
- 后续只需前端接入真实接口并刷新列表,即可进入联调与页面验证阶段
|
||||||
|
- 本次未启动额外后端服务进程,无需清理测试进程
|
||||||
@@ -0,0 +1,39 @@
|
|||||||
|
# 项目管理列表重新分析后端验证记录
|
||||||
|
|
||||||
|
## 验证范围
|
||||||
|
|
||||||
|
- 手动重打标接口可直接复用于列表页
|
||||||
|
- 重打标开始后项目进入打标中
|
||||||
|
- 重打标成功后自动重算项目风险人数
|
||||||
|
- 运行中任务和归档项目保留既有后端保护
|
||||||
|
|
||||||
|
## 链路核验
|
||||||
|
|
||||||
|
- `POST /ccdi/project/tags/rebuild` 由 `CcdiBankTagController.rebuild(...)` 提供入口,并透传 `projectId`、`modelCode` 与操作人
|
||||||
|
- `CcdiBankTagServiceImpl.submitRebuild(...)` 继续复用 `ProjectBankTagRebuildCoordinator.submitManual(...)`
|
||||||
|
- `CcdiBankTagServiceImpl.rebuildProject(...)` 开始时调用 `projectService.updateProjectStatus(projectId, CcdiProjectStatusConstants.TAGGING, operator)`,满足“打标中”状态切换要求
|
||||||
|
- `CcdiBankTagServiceImpl.rebuildProject(...)` 成功路径会调用 `projectOverviewService.refreshOverviewEmployeeResults(projectId, operator)`
|
||||||
|
- `CcdiProjectOverviewServiceImpl.refreshOverviewEmployeeResults(...)` 会在重建员工结果后同步调用 `projectMapper.updateRiskCountsByProjectId(...)`,刷新高/中/低风险人数
|
||||||
|
|
||||||
|
## 验证命令
|
||||||
|
|
||||||
|
```bash
|
||||||
|
mvn -pl ccdi-project -Dtest=CcdiBankTagControllerTest,ProjectBankTagRebuildCoordinatorTest,CcdiBankTagServiceRiskCountRefreshTest test
|
||||||
|
```
|
||||||
|
|
||||||
|
## 验证结果
|
||||||
|
|
||||||
|
- 结果:通过
|
||||||
|
- `CcdiBankTagControllerTest` 通过 2 个用例,覆盖手动重打标控制器入口
|
||||||
|
- `ProjectBankTagRebuildCoordinatorTest` 通过 6 个用例,覆盖运行中防重提交流程、补跑标记与归档保护
|
||||||
|
- `CcdiBankTagServiceRiskCountRefreshTest` 通过 2 个用例,覆盖成功后刷新员工结果与刷新失败时任务转失败分支
|
||||||
|
- 总计 10 个用例全部通过,Surefire 结果为 `BUILD SUCCESS`
|
||||||
|
- 测试日志中的 `refresh failed` 为失败分支测试主动构造的预期异常,不影响最终通过结论
|
||||||
|
|
||||||
|
## 关键结论
|
||||||
|
|
||||||
|
- 项目列表“重新分析”后端无需新增接口,直接复用现有 `POST /ccdi/project/tags/rebuild`
|
||||||
|
- 现有链路已覆盖“重新打标并重新计算人数”的后端要求,不需要新增服务分支或补充额外人数重算调用
|
||||||
|
- 手动重打标开始后会先切换项目状态为 `TAGGING`
|
||||||
|
- 重打标成功后会同步刷新员工风险结果,并回写项目高/中/低风险人数
|
||||||
|
- 运行中任务重复提交与不可启动项目的保护逻辑已存在,可继续沿用
|
||||||
Reference in New Issue
Block a user