功能测试报告：M1-货运 取数链路核对与 7 月回归（2026-09-08）
一、功能说明
汇总大表数据驱动改造 M1 第一块：把“货运口径”（规上/规下/合计 × 货运量/周转量 × 当月/累计）固化为可复用的 Java 计算服务 FreightCalc（traffic-audit-server/.../reportexport/calc/FreightCalc.java），并验证：**仅凭数据库即可重算出 7 月已修正母版中货运量排名、货运周转量排名两张成品页的全部规上/规下数值（逐格 diff=0）**，为后续 SummaryFiller 写回母版提供同源矩阵。
二、测试环境
- 库：
traffic_audit（127.0.0.1:3308），数据 = 2026-07 已导入现状；
- 母版基线：
docs/生成汇总大表/2026年7月道路运输量汇总表.xlsx（2026-07 已修正版）；
- 工具：mysql CLI 取数 + Python 重算比对；后端
mvn -q compile 通过（exit=0）。
三、取数口径（与既有 exportFreightRank/exportTurnoverRank 及确认回执 B1 一致）
| 指标 |
来源 |
| 规上货运量（当月/累计，万吨） |
h2032_enterprise_monthly.freight_total（吨）按市州汇总 ÷10000 |
| 合计货运量（万吨） |
freight_turnover_import.freight_mMM（当月）/ freight_m01..mMM（累计） |
| 规下货运量 |
合计 − 规上（拆分表不存货运量列，不可直接取） |
| 规上/合计周转量 |
scale_split_transport MONTH / CUMULATIVE 的 above_scale_turnover / total_turnover |
| 规下周转量 |
合计 − 规上（与拆分表 below 列核对一致） |
| 湖北省行 |
17 市州之和（与母版“全省行=Σ城市行”公式一致） |
四、用例表
| # |
用例 |
输入 |
预期 |
实际 |
结论 |
| 1 |
货运量排名·累计（1-7月） |
库 2026-01~07 |
与母版 B4:B21（规上）、G4:G21（规下）逐格一致 |
diff=0 |
通过 |
| 2 |
货运量排名·当月（7月） |
库 2026-07 |
与母版 B25:B42、G25:G42 逐格一致 |
diff=0 |
通过 |
| 3 |
货运周转量排名·累计 |
scale_split CUMULATIVE |
与母版 B5:B22、G5:G22 一致 |
diff=0 |
通过 |
| 4 |
货运周转量排名·当月 |
scale_split MONTH |
与母版 B27:B44、G27:G44 一致 |
diff=0 |
通过 |
| 5 |
全省行与 Σ 城市一致性 |
17 市州求和 |
全省规上当月=3754.7823（母版） |
计=3754.7823 |
通过 |
| 6 |
Java 编译 |
mvn -q -DskipTests compile |
无错误 |
exit=0 |
通过 |
五、发现的问题与处置
- H2032 按
region_code 汇总时存在“一市多区县代码”，初版脚本误用覆盖而非累加 → 已改累加，0 差异。
- 累计合计首版只加到 6 月（漏 m07）→ 已改 1..7 全加，0 差异。
freight_turnover_import.region_name 存在“林区/神农架林区/天门/天门市”等别名 → 统一经 RegionUtil 别名归一后比对，0 差异。- 周转量两页在任何版本比对中均 0 差异（拆分表口径稳定）。
（上述均为回归脚本问题，非业务口径问题；已在 Python 回归与 Java 实现中同步修正。）
六、结论与下一步
- 结论：货运口径链路可从库完整复算 7 月母版，口径锁定；
FreightCalc 已入库并通过编译。
- 说明：同比未在本服务计算——按 Q1 由写回层以母版缓存 2025 参照组为基准（去年同期 DB 列为空，已核对）。
- 下一步：① M1-PaxCalc（公交/出租/轨道轮渡/网约/班线包车/城市客运口径，用城市客运三表 7 月回归）；② M1-MidCalc；③ M2 SummaryFiller 写回台账+成品页并逐格 diff；④ 8 月实弹。
