diff --git a/.claude/skills/qe_fleet/SKILL.md b/.claude/skills/qe_fleet/SKILL.md index ae60bf6..7ae7a6a 100644 --- a/.claude/skills/qe_fleet/SKILL.md +++ b/.claude/skills/qe_fleet/SKILL.md @@ -1,11 +1,11 @@ --- name: qe-fleet -description: Agentic QE Fleet — 14 个专业 AI Agent 组成的自治质量工程舰队。当用户输入 /qe-fleet 或 /case_generate 时使用本 skill。 +description: Agentic QE Fleet — 混合流水线：Python 脚手架 + AI Agent 内容生成 metadata: short-description: 多 Agent QE Fleet：从需求到测试用例的全流程自动化 + 质量门禁 + 知识沉淀 --- -# Agentic QE Fleet +# Agentic QE Fleet（混合流水线 v3.0） 当用户输入以下任一意图时使用本 skill： @@ -19,82 +19,188 @@ metadata: - `/qe-fleet status <需求文档>` - `/case_generate <需求文档>`（向后兼容别名） -## 自动执行要求 +## 架构概述 -收到 `/qe-fleet` 命令后，不要停在说明阶段，必须自动完成以下步骤： +本流水线采用**混合架构**： -### /qe-fleet run +- **Python 脚本（fleet_runner.py）**: 处理确定性工作——文档解析、知识激活、需求分析、冲突检测、风险矩阵、测试策略模板、测试数据模板、Playwright/Appium 脚本骨架、清单管理 +- **Claude Code Agent（本 Skill）**: 处理生成式 AI 工作——测试点设计、测试用例编写、用例评审、覆盖率审计、质量裁决 -1. 执行： -```bash -python3 scripts/fleet_runner.py run --requirement <需求文档路径> -``` +## `/qe-fleet run` — 全流程自动执行 -2. fleet_runner.py 会自动按战区顺序执行： - - **PREPARE**: document-parser(文档解析) → knowledge-activator(知识激活) - - **ANALYZE**: requirement-analyzer(需求分析) + conflict-detector(冲突检测) → risk-assessor(风险评估) - - **DESIGN**: test-strategist(测试策略) → testpoint-designer(测试点) + data-builder(测试数据) → case-designer(用例设计) - - **EXECUTE**: web-executor(Playwright PC Web) + mobile-executor(Appium 移动端) → result-reporter(截图对比+结论) - - **REVIEW**: case-reviewer(用例评审) + coverage-auditor(覆盖率审计) → quality-gatekeeper(质量裁决) - - **MONITOR**: execution-analyst(执行分析) → knowledge-curator(知识沉淀) - - **EXPORT**: 质量裁决 PASS 后自动导出 Excel +收到此命令后，按以下 6 个阶段自动执行，不要停在说明阶段： -3. 检查确认门禁： - - 若 analyze 战区 `confirmation_gate.required=true` 且 `decision_status` 不是 `confirmed`，阻断并告知 - - 提供确认单路径和阻断原因 - -4. 检查质量裁决： - - 若 review 战区 quality_verdict 为 `BLOCKED`，告知阻断原因 - - 若为 `PASS` 或 `PASS_WITH_FIX`，自动导出 - -5. 最终反馈： - - 各战区状态（✅ 完成 / ⏳ 进行中 / ⬜ 待执行） - - 产物文件路径 - - 质量裁决结果 - - 若失败，失败在哪一步 - -### /qe-fleet status +### Phase 1: SCAFFOLD（脚手架生成） ```bash -python3 scripts/fleet_runner.py status --requirement <需求文档路径> +python scripts/fleet_runner.py run --scaffold-only --requirement <需求文档路径> ``` -### /qe-fleet monitor +产出： +- 标准化需求文档（含附加文件检测 + 多源注册表） +- 知识激活 + 缺口检测 +- 需求分析 + 冲突检测 + 风险矩阵 +- 测试策略模板 + 测试数据模板 +- Playwright/Appium 脚本骨架 +- 所有战区 manifest（含 `pending_ai` 标记） +### Phase 2: GATE-CHECK（门禁检查） + +读取 `output/manifests/{BASE_NAME}_analyze.json`： +- 若 `confirmation_gate.required=true` 且 `decision_status` 不是 `confirmed` 或 `not_required`： + - 🛑 阻断并告知用户：确认单路径、阻断原因 + - 不得继续执行后续阶段 +- 若门禁通过或无门禁要求，继续 Phase 3 + +### Phase 3: AI-DESIGN（AI 生成设计产物） + +按依赖顺序调用 AI Agent 填充设计产物。**重要**：若目标文件已存在且内容非空（>500 字符），跳过该 Agent 并告知用户可手动重新生成。 + +#### 3a: data-builder + testpoint-designer（可并行） + +**Agent: data-builder** +- 输入文件：`output/analysis/{BASE_NAME}_分析.md`、`{PROJECT_PROFILE}`、来自 prepare manifest 的 `sources_registry` 中所有 `role=api_spec` 的附加文件 +- Agent prompt：`agents/design/data_builder.md` +- 输出：`output/analysis/{BASE_NAME}_测试数据.md`（覆盖模板） +- 验证：文件存在且 >300 字符 +- 调用方式：使用 Agent 工具，subagent_type=general-purpose，在 prompt 中指明输入文件和输出文件 + +**Agent: testpoint-designer** +- 输入文件：`output/analysis/{BASE_NAME}_分析.md`、`output/analysis/{BASE_NAME}_风险评估.md`、`output/analysis/{BASE_NAME}_测试策略.md`、`output/analysis/{BASE_NAME}_关联与冲突.md`、`{PROJECT_PROFILE}`、`knowledge_base/02_history/common_missed_scenes.md`、`knowledge_base/02_history/historical_defects.md`、`knowledge_base/01_standards/definition_of_done.md`、prepare manifest 中 `sources_registry` 的所有附加文件 +- Agent prompt：`agents/design/testpoint_designer.md` +- 输出：`output/test_points/{BASE_NAME}_测试点.md` +- 验证：文件存在且 >500 字符，含有 `TP-` 标识符 +- 调用方式：使用 Agent 工具，subagent_type=general-purpose + +#### 3b: case-designer（依赖 3a 完成） + +- 输入文件：`output/test_points/{BASE_NAME}_测试点.md`（3a 产出）、`output/analysis/{BASE_NAME}_测试数据.md`、`knowledge_base/01_standards/test_case_template.md`、`knowledge_base/01_standards/review_checklist.md`、`knowledge_base/03_best_practices/` +- Agent prompt：`agents/design/case_designer.md` +- 输出：`output/test_cases/{BASE_NAME}_测试用例.md` +- 验证：文件存在且 >500 字符，含 Markdown 表格，表头与 `test_case_template.md` 一致 +- 调用方式：使用 Agent 工具 + +### Phase 4: AI-REVIEW（AI 评审） + +#### 4a: case-reviewer + coverage-auditor（可并行） + +**Agent: case-reviewer** +- 输入文件：`output/test_cases/{BASE_NAME}_测试用例.md`、`knowledge_base/01_standards/review_checklist.md`、`knowledge_base/01_standards/test_case_template.md`、`knowledge_base/01_standards/definition_of_done.md`、`output/analysis/{BASE_NAME}_风险评估.md` +- Agent prompt：`agents/review/case_reviewer.md` +- 输出：`output/analysis/{BASE_NAME}_评审报告.md` +- 验证：文件存在且 >500 字符，含阻断项/建议项计数 + +**Agent: coverage-auditor** +- 输入文件：`output/analysis/{BASE_NAME}_分析.md`、`output/test_points/{BASE_NAME}_测试点.md`、`output/test_cases/{BASE_NAME}_测试用例.md`、`output/analysis/{BASE_NAME}_风险评估.md` +- Agent prompt：`agents/review/coverage_auditor.md` +- 输出：`output/analysis/{BASE_NAME}_覆盖率审计.md` +- 验证：文件存在且 >500 字符 + +#### 4b: quality-gatekeeper（依赖 4a 完成） + +- 输入文件：`output/analysis/{BASE_NAME}_评审报告.md`、`output/analysis/{BASE_NAME}_覆盖率审计.md`、`output/analysis/{BASE_NAME}_风险评估.md`、`fleet_config.yml` +- Agent prompt：`agents/review/quality_gatekeeper.md` +- 输出：`output/analysis/{BASE_NAME}_质量裁决.md` +- 验证：文件含 `PASS`、`PASS_WITH_FIX` 或 `BLOCKED` + +### Phase 5: VERDICT（裁决 + 导出） + +读取 `output/analysis/{BASE_NAME}_质量裁决.md` 中的裁决结果： + +- **PASS** 或 **PASS_WITH_FIX**: 执行导出 + ```bash + python scripts/fleet_runner.py export --requirement <需求文档路径> + ``` + （若已有 review 战区的阻断项或覆盖缺口，在导出前先修复用例文件，参考 Phase 4 的评审报告） +- **BLOCKED**: 🛑 告知用户阻断原因，提供修复方向，不导出 Excel + +### Phase 6: REPORT（汇总反馈） + +输出最终状态汇总： + +``` +🏁 QE Fleet 运行完成 + ✅ prepare: 完成 (置信度 0.95, 附加文件 N 个) + ✅ analyze: 完成 (风险 P0=N, P1=N) + ✅ design: 完成 (测试点 N, 用例 N) + ✅ execute: 完成 (Playwright + Appium 脚本) + ✅ review: 完成 (裁决: PASS/PASS_WITH_FIX/BLOCKED) + ✅ export: 完成/N/A + +产物: + 📊 Excel: output/excel_reports/{BASE_NAME}_测试用例.xlsx + 🧠 XMind: output/xmind_reports/{BASE_NAME}.xmind + 📋 测试点: output/test_points/{BASE_NAME}_测试点.md (N个) + 📝 测试用例: output/test_cases/{BASE_NAME}_测试用例.md (N条) + ✅ 质量裁决: output/analysis/{BASE_NAME}_质量裁决.md +``` + +--- + +## 其他命令 + +### `/qe-fleet prepare <需求文档>` ```bash -python3 scripts/fleet_runner.py monitor --requirement <需求文档路径> --results <测试结果文件> +python scripts/fleet_runner.py prepare --requirement <需求文档路径> ``` -## 战区详细流程 +### `/qe-fleet analyze <需求文档>` +```bash +python scripts/fleet_runner.py analyze --requirement <需求文档路径> +``` -### Prepare 战区 -- **document-parser**: 解析 docx/pdf/doc → 标准化 Markdown；自动识别同主题技术方案；标注解析置信度 -- **knowledge-activator**: 按需求内容关键词+语义匹配激活术语/规则/历史缺陷/最佳实践；检测知识缺口 +### `/qe-fleet design <需求文档>` +仅执行 Phase 3（AI-DESIGN），前提是 prepare 和 analyze 已完成。 +若 manifest 未就绪，先执行对应的脚手架命令。 -### Analyze 战区 -- **requirement-analyzer**: 结构化需求模型（背景/目标/角色/规则/流程/异常）；项目画像差异化；歧义标注 -- **conflict-detector**: 语义级历史需求冲突检测（方向/数值/状态机/权限）；严重度分级(P0-P3) -- **risk-assessor**: 多维度风险矩阵（资损/可用性/数据/合规/兼容性）；可能性 × 影响度 = 风险等级 +### `/qe-fleet review <需求文档>` +仅执行 Phase 4（AI-REVIEW），前提是设计产物已存在。 -### Design 战区 -- **test-strategist**: 测试金字塔分配；优先级覆盖规则；P0 必测清单 -- **testpoint-designer**: 全面测试点矩阵；来源标注（需求/历史缺陷/风险矩阵/冲突修订/项目画像） -- **case-designer**: 可执行用例；原子性；双验证预期结果（UI + 数据） -- **data-builder**: 自动提取+人工补充测试数据（账号/金额/ID/枚举/边界值） +### `/qe-fleet export <需求文档>` +```bash +python scripts/fleet_runner.py export --requirement <需求文档路径> +``` -### Execute 战区 -- **web-executor**: 生成 Playwright 测试脚本；多浏览器（Chromium/Firefox/WebKit）；每步/失败自动截图 -- **mobile-executor**: 生成 Appium 测试脚本；Android (UiAutomator2) + iOS (XCUITest)；双平台截图采集 -- **result-reporter**: 截图 AI 视觉对比；像素级差异检测；多平台测试结论报告（含截图证据） +### `/qe-fleet monitor <需求文档> --results <测试结果>` +```bash +python scripts/fleet_runner.py monitor --requirement <需求文档路径> --results <测试结果文件> +``` -### Review 战区 -- **case-reviewer**: 按 review_checklist 逐项评审；错误分级（阻断/建议/优化） -- **coverage-auditor**: 需求→测试点→用例三级追溯；覆盖缺口识别；过度覆盖识别 -- **quality-gatekeeper**: 三级裁决（PASS / PASS_WITH_FIX / BLOCKED）；裁决依据引用具体评审条目 +### `/qe-fleet status <需求文档>` +```bash +python scripts/fleet_runner.py status --requirement <需求文档路径> +``` -### Monitor 战区 -- **execution-analyst**: 失败归类（ENV/DATA/CASE/REAL_BUG）；失败模式识别；根因推测 -- **knowledge-curator**: 自动回写知识库；去重保护；P0 自动生效 / P1-P3 人工确认 +--- + +## AI Agent 调用模板 + +每次调用 AI Agent 时，使用以下模板构造 prompt： + +``` +你是 {agent_name}。{从 agent prompt 文件读取的 role 描述}。 + +# 任务 +{从 agent prompt 文件读取的 task 描述} + +# 关键输入文件（必须读取） +{列出所有输入文件路径} + +# 输出文件 +写入: {output_file_path} + +# 输出格式 +{从 agent prompt 文件读取的 output format} + +# 约束 +{从 agent prompt 文件读取的 constraints} + +# 附加上下文 +- 项目画像: {PROJECT_PROFILE} +- 附加源文件（如有，来自 prepare manifest sources_registry） +``` + +--- ## 约束 @@ -102,12 +208,13 @@ python3 scripts/fleet_runner.py monitor --requirement <需求文档路径> --res - 确认门禁未解除时，必须阻断并告知原因和解决路径 - 质量裁决 BLOCKED 时，不得导出 Excel - 若主输入是 .docx/.doc/.pdf，必须基于 prepare 产出的标准化 Markdown -- 若 manifest 中有技术方案文件，必须纳入分析 +- 若 manifest 中有附加源文件（`sources_registry`），必须纳入 AI Agent 的输入文件列表 - 需求有歧义时必须显式标注 `> ⚠️ 待确认：问题、影响范围、建议确认方向` - 基于项目画像差异化，避免通用化输出 - 历史缺陷和易漏场景必须显式体现在测试点或用例中 - 预期结果必须同时覆盖 UI 反馈和数据状态变化 -- 若改动涉及 scripts/、.claude/、agents/、AGENTS.md、README.md，必须执行 governance_audit.py auto +- 所有 bash 命令使用 `python`（非 `python3`） +- 若改动涉及 scripts/、.claude/、agents/、AGENTS.md、README.md，必须执行 `python scripts/governance_audit.py auto` ## 兼容性 diff --git a/AGENTS.md b/AGENTS.md index df426e2..f0ca420 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1,4 +1,4 @@ -# Agentic QE Fleet +# Agentic QE Fleet（混合流水线 v3.0） 当用户在 Codex CLI 中输入以下任一意图时，必须按一条端到端流水线自动执行，不要把中间命令再抛给用户手动运行： @@ -14,111 +14,94 @@ - "基于某个需求文档生成测试分析、测试点、测试用例" - "导出测试用例 Excel" +## 架构概述 + +本流水线采用**混合架构**： + +- **Python 脚本（fleet_runner.py）**: 确定性工作——文档解析、知识激活、需求分析、冲突检测、风险矩阵、测试策略模板、测试数据模板、Playwright/Appium 脚本骨架、附加文件检测、多源注册表、清单管理 +- **Claude Code Agent（SKILL.md）**: 生成式 AI 工作——测试点设计、测试用例编写、用例评审、覆盖率审计、质量裁决 + ## /qe-fleet run 自动执行规则 -当用户输入 `/qe-fleet run <需求文档>` 时，必须立即完成以下动作： +当用户输入 `/qe-fleet run <需求文档>` 时，按以下 6 个阶段自动执行： -1. 解析目标需求文档路径，提取 `BASE_NAME` -2. 自动执行： +### Phase 1: SCAFFOLD — Python 脚手架生成 ```bash -python3 scripts/fleet_runner.py run --requirement <需求文档路径> +python scripts/fleet_runner.py run --scaffold-only --requirement <需求文档路径> ``` -3. fleet_runner.py 自动按战区顺序编排 17 个专业 Agent： +产出 manifest（含 `pending_ai` 标记）+ 模板 + 脚本骨架 + 附加文件检测 + 多源注册表。 - **PREPARE 战区 (2 Agent):** - - document-parser: 文档解析标准化 - - knowledge-activator: 知识激活 +### Phase 2: GATE-CHECK — 确认门禁 - **ANALYZE 战区 (3 Agent):** - - requirement-analyzer: 需求分析 - - conflict-detector: 冲突检测 - - risk-assessor: 风险评估 +读取 `output/manifests/{BASE_NAME}_analyze.json`。若 `confirmation_gate.required=true` 且 `decision_status` 不是 `confirmed` 或 `not_required`： +- 🛑 阻断，告知确认单路径和阻断原因，不得继续 - **DESIGN 战区 (4 Agent):** - - test-strategist: 测试策略 - - testpoint-designer: 测试点设计 - - case-designer: 用例设计 - - data-builder: 测试数据构造 +### Phase 3: AI-DESIGN — AI Agent 生成设计产物 - **EXECUTE 战区 (3 Agent):** - - web-executor: PC Web Playwright 自动化执行 + 截图 - - mobile-executor: 移动端 Appium 自动化执行 + 截图 - - result-reporter: AI 视觉对比 + 测试结论报告 +**并行**: data-builder + testpoint-designer → **串行**: case-designer - **REVIEW 战区 (3 Agent):** - - case-reviewer: 用例评审 - - coverage-auditor: 覆盖率审计 - - quality-gatekeeper: 质量门禁裁决 +每个 Agent 使用 Claude Code Agent 工具调用，以 `agents/` 目录下的 prompt 文件为指令。若目标文件已存在且 >500 字符则跳过。 - **MONITOR 战区 (2 Agent):** - - execution-analyst: 执行结果分析 - - knowledge-curator: 知识沉淀 +### Phase 4: AI-REVIEW — AI Agent 评审 -4. 若 manifest 中 `confirmation_gate.required=true` 且 `decision_status` 不是 `confirmed`： - - 不要继续执行后续战区 - - 直接告诉用户当前卡在"人工确认"阶段 - - 告知关联与冲突文件路径与 `suggested_decision_file` - - 明确说明：确认单需要写出 `确认状态：已确认` 后才能继续 +**并行**: case-reviewer + coverage-auditor → **串行**: quality-gatekeeper -5. 若确认门禁已通过，继续执行后续战区 +### Phase 5: VERDICT — 裁决 + 导出 -6. 质量裁决通过 (PASS/PASS_WITH_FIX) 后自动执行 Excel 导出 +- PASS/PASS_WITH_FIX → `python scripts/fleet_runner.py export --requirement <需求文档路径>` +- BLOCKED → 🛑 告知阻断原因，不导出 -7. 最终回复时直接告诉用户： - - 各战区状态（✅ 完成 / ⏳ 进行中 / ⬜ 待执行） - - 分析、测试点、测试用例、Excel、风险报告、评审报告、覆盖率审计、质量裁决的实际路径 - - 质量裁决结果 - - 若失败，失败在哪一步 +### Phase 6: REPORT — 最终汇总 + +输出各战区状态、产物路径、质量裁决结果。 ## 子命令自动执行 ### /qe-fleet prepare ```bash -python3 scripts/fleet_runner.py prepare --requirement <需求文档路径> +python scripts/fleet_runner.py prepare --requirement <需求文档路径> ``` ### /qe-fleet analyze ```bash -python3 scripts/fleet_runner.py analyze --requirement <需求文档路径> +python scripts/fleet_runner.py analyze --requirement <需求文档路径> ``` ### /qe-fleet design -```bash -python3 scripts/fleet_runner.py design --requirement <需求文档路径> -``` +仅执行 Phase 3（AI-DESIGN），前提是 prepare 和 analyze 已完成。若 manifest 未就绪，先执行对应的脚手架命令。 ### /qe-fleet review -```bash -python3 scripts/fleet_runner.py review --requirement <需求文档路径> -``` +仅执行 Phase 4（AI-REVIEW），前提是设计产物已存在。 ### /qe-fleet export ```bash -python3 scripts/fleet_runner.py export --requirement <需求文档路径> +python scripts/fleet_runner.py export --requirement <需求文档路径> ``` ### /qe-fleet monitor ```bash -python3 scripts/fleet_runner.py monitor --requirement <需求文档路径> --results <测试结果文件> +python scripts/fleet_runner.py monitor --requirement <需求文档路径> --results <测试结果文件> ``` ### /qe-fleet status ```bash -python3 scripts/fleet_runner.py status --requirement <需求文档路径> +python scripts/fleet_runner.py status --requirement <需求文档路径> ``` 若用户已经补完确认单，并明确要求"继续""确认后续跑""按确认结论重跑"，优先执行： ```bash -python3 scripts/case_pipeline.py apply-confirmation --requirement <需求文档路径> +python scripts/case_pipeline.py apply-confirmation --requirement <需求文档路径> ``` ## 约束 - 除非脚本执行失败，否则不要要求用户再手动执行命令 -- 若本次改动涉及以下任一范围，必须在结束前执行 `python3 scripts/governance_audit.py auto`，并根据结果同步修正 `AGENTS.md`、`.claude/`、`README.md`、`docs/` 的滞后内容： +- 所有 bash 命令使用 `python`（非 `python3`） +- 若 manifest 中有附加源文件（`sources_registry`），必须纳入 AI Agent 的输入文件列表 +- 若本次改动涉及以下任一范围，必须在结束前执行 `python scripts/governance_audit.py auto`，并根据结果同步修正 `AGENTS.md`、`.claude/`、`README.md`、`docs/` 的滞后内容： - `scripts/` - `.claude/` - `agents/` @@ -135,7 +118,7 @@ python3 scripts/case_pipeline.py apply-confirmation --requirement <需求文档 - 测试点/测试用例必须体现 `knowledge_base/00_project/project_profile.md` 的项目差异化约束 - 若主输入是 `.docx/.doc/.pdf`，必须使用 prepare 产出的标准化 Markdown 文件，即 `normalized_requirement_file` - 各战区产物清单汇总至 `output/manifests/{BASE_NAME}.json` 统一清单文件 -- 若存在同主题技术方案，必须结合标准化技术方案文件补充测试约束 +- 若存在同主题技术方案或需求中引用的附加文件，必须结合这些文件补充测试约束 - 测试用例生成前必须先按 `knowledge_base/01_standards/review_checklist.md` 自检 - 需求有歧义时，必须显式写： diff --git a/agents/design/case_designer.md b/agents/design/case_designer.md index 73b58ec..da2904e 100644 --- a/agents/design/case_designer.md +++ b/agents/design/case_designer.md @@ -4,6 +4,7 @@ zone: design description: 将测试点转化为可执行测试用例，严格遵循模板表头，预期结果双验证 tools: Read, Write, Glob, Bash depends_on: ["testpoint-designer", "data-builder"] +ai_generative: true produces: ["output/test_cases/{{BASE_NAME}}_测试用例.md"] --- diff --git a/agents/design/data_builder.md b/agents/design/data_builder.md index 9cd6b41..6099af8 100644 --- a/agents/design/data_builder.md +++ b/agents/design/data_builder.md @@ -4,6 +4,7 @@ zone: design description: 为测试用例构造精确的测试数据集，自动提取 + 人工补充 tools: Read, Write, Glob depends_on: ["requirement-analyzer", "testpoint-designer"] +ai_generative: true produces: ["output/analysis/{{BASE_NAME}}_测试数据.md"] --- diff --git a/agents/design/testpoint_designer.md b/agents/design/testpoint_designer.md index d2b6e0c..4ce383f 100644 --- a/agents/design/testpoint_designer.md +++ b/agents/design/testpoint_designer.md @@ -4,6 +4,7 @@ zone: design description: 基于分析+风险+策略+历史经验，设计全面测试点矩阵，标注来源 tools: Read, Write, Glob depends_on: ["test-strategist", "requirement-analyzer", "risk-assessor"] +ai_generative: true produces: ["output/test_points/{{BASE_NAME}}_测试点.md"] --- diff --git a/agents/review/case_reviewer.md b/agents/review/case_reviewer.md index daeb672..357e63a 100644 --- a/agents/review/case_reviewer.md +++ b/agents/review/case_reviewer.md @@ -4,6 +4,7 @@ zone: review description: 按 review_checklist 逐项评审用例，错误分级（阻断/建议/优化），标注到具体行号 tools: Read, Write, Glob depends_on: ["case-designer"] +ai_generative: true produces: ["output/analysis/{{BASE_NAME}}_评审报告.md"] --- diff --git a/agents/review/coverage_auditor.md b/agents/review/coverage_auditor.md index d469ea9..8001f78 100644 --- a/agents/review/coverage_auditor.md +++ b/agents/review/coverage_auditor.md @@ -4,6 +4,7 @@ zone: review description: 需求→测试点→用例三级追溯覆盖审计，识别覆盖缺口和过度覆盖 tools: Read, Write, Glob depends_on: ["case-reviewer"] +ai_generative: true produces: ["output/analysis/{{BASE_NAME}}_覆盖率审计.md"] --- diff --git a/agents/review/quality_gatekeeper.md b/agents/review/quality_gatekeeper.md index 2d37b9e..5e2f225 100644 --- a/agents/review/quality_gatekeeper.md +++ b/agents/review/quality_gatekeeper.md @@ -4,6 +4,7 @@ zone: review description: 综合评审+覆盖率进行三级裁决：PASS / PASS_WITH_FIX / BLOCKED tools: Read, Write depends_on: ["case-reviewer", "coverage-auditor"] +ai_generative: true produces: ["output/analysis/{{BASE_NAME}}_质量裁决.md"] --- diff --git a/knowledge_base/02_history/historical_defects.md b/knowledge_base/02_history/historical_defects.md index 41ac4a7..ce45ab6 100644 --- a/knowledge_base/02_history/historical_defects.md +++ b/knowledge_base/02_history/historical_defects.md @@ -1,33 +1,33 @@ # 历史典型缺陷复盘 > 这些是过去项目中发生过的真实 Bug，生成新用例时，请针对这些逻辑设计防御性测试用例。 - -### 缺陷 ID: BUG-202310-05--示例 -- **模块**: 购物车 -- **描述**: 商品降价后加入购物车，随后商品恢复原价，结算时依然按降价后的价格计算，导致资损。 -- **根因**: 购物车缓存了价格，结算时未重新从商品中心获取最新价格。 -- **防御用例**: `验证商品加入购物车后，后台修改价格，结算时系统自动更新为最新价格`。 +> +> **关联知识**：以下缺陷的防御场景已同步到 `common_missed_scenes.md` §6（数据上报与外部系统对接），生成测试点时会自动交叉引用。 ### 缺陷 ID: BUG-202607-01--上报阶段依赖链断裂 - **模块**: 数据上报（安徽运八） - **描述**: 运单第一次上报失败（3次重试全部失败），系统未阻断第二次上报触发，导致第二次上报在第一次上报数据缺失的情况下仍然发出，监管平台返回"上报数据不完整"但系统未正确处理该错误。 - **根因**: 上报阶段间的依赖校验仅在前端做了按钮控制，后端接口缺少前置上报完成状态校验。 - **防御用例**: `验证第一次上报失败后，后端接口层面拒绝第二次/第三次上报请求，返回明确错误码"前置上报未完成"`。`验证三个上报阶段依赖链的每个节点，后端均做了前置状态校验（前端+后端双重拦截）`。 +- **关联易漏场景**: `common_missed_scenes.md` → 6.多阶段依赖链 ### 缺陷 ID: BUG-202607-02--重试幂等缺陷导致重复上报 - **模块**: 数据上报（安徽运八） - **描述**: 第一次上报超时后进入自动重试，运营人员在重试期间点击"手动上传"，系统同时发出了两次上报请求，导致监管平台侧出现两条重复运单记录，触发"运单重复"核验异常。 - **根因**: 手动上传和自动重试共用同一上报接口，但缺少分布式锁或幂等键校验。 - **防御用例**: `验证上报重试期间手动触发上传时，系统提示"上报处理中"并拒绝重复提交`。`验证同一运单同一上报阶段在1分钟内只能有一条成功上报记录`。 +- **关联易漏场景**: `common_missed_scenes.md` → 6.重试+手动触发并发 ### 缺陷 ID: BUG-202607-03--跨模块数据不一致 - **模块**: 数据上报（安徽运八）/ 账户管理 - **描述**: 财务在账户管理模块修改了打款金额（从10000元调整为9500元），但第二次上报仍然发送了旧的10000元金额，导致资金流水核验"金额不匹配"异常。运单管理、支付流水、上报三个模块的数据不同步。 - **根因**: 上报模块在运单装货完成时缓存了合同金额，打款完成后未从支付流水表重新获取实际打款金额，而是使用了缓存的合同金额。 - **防御用例**: `验证第二次上报的资金流水数据来源于支付流水表（非运单表/缓存），上报金额与财务实际打款金额一致`。`验证财务修改打款金额后，上报模块能感知数据变更并使用最新值`。 +- **关联易漏场景**: `common_missed_scenes.md` → 6.跨模块数据一致性 / 6.上报数据字段溯源 ### 缺陷 ID: BUG-202607-04--省份代码硬编码 - **模块**: 数据上报（安徽运八） - **描述**: 系统上线安徽运八时，司机信息中的省份代码仍使用云南省代码"28"，而非安徽省代码"34"，导致第一批运单的司机资质核验全部异常。 - **根因**: 省份代码在代码中硬编码为项目默认值（云南省=28），未根据上报目标省份动态切换。 - **防御用例**: `验证安徽运八上报的省份代码为安徽省代码，与项目默认云南代码隔离`。`验证多省份部署场景下，上报数据中省份相关字段（省份代码/行政区划代码）与目标省份一致`。 +- **关联易漏场景**: `common_missed_scenes.md` → 6.省份/区域配置隔离 diff --git a/knowledge_base/03_best_practices/order_manage_cases.md b/knowledge_base/03_best_practices/order_manage_cases.md index 91d4886..0279931 100644 --- a/knowledge_base/03_best_practices/order_manage_cases.md +++ b/knowledge_base/03_best_practices/order_manage_cases.md @@ -30,8 +30,4 @@ | 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | | :---------- | :----------------------- | :------------------------------- | :----- | :------- | :------------------------------------------ | :----------------------------------------------------------- | :----------------------------------------------------------- | :----------------------------------------------------------- | :--- | -| MKT_ACT_001 | 平台端-货源管理-货源配置 | 验证平台端新建合法货源可保存成功 | P0 | 功能测试 | 平台运营账号已登录；存在 1 个符合条件的货主 | 1. 点击新建货源
2. 填写装卸货地、货物、价格等字段
3. 点击确定保存
4. 进入详情查看 | 装货地址=云南省昆明市五华区人民政府；卸货地址=云南省曲靖市马龙区人民政府；货物名称=钢材；运输单价=1 | 1. 进入新建活动页
2. 所有数据填入正常，展示正确
3. 页面提示保存成功并跳转活动列表页并刷新列表
4. 详情页展示与保存内容一致，后台主表和资源明细表正确落库 | 示例 | -| | | | | | | | | | | -| | | | | | | | | | | -| | | | | | | | | | | -| | | | | | | | | | | +| SRC_CFG_001 | 平台端-货源管理-货源配置 | 验证平台端新建合法货源可保存成功 | P0 | 功能测试 | 平台运营账号已登录；存在 1 个符合条件的货主 | 1. 点击新建货源
2. 填写装卸货地、货物、价格等字段
3. 点击确定保存
4. 进入详情查看 | 装货地址=云南省昆明市五华区人民政府；卸货地址=云南省曲靖市马龙区人民政府；货物名称=钢材；运输单价=1 | 1. 进入新建货源页
2. 所有数据填入正常，展示正确
3. 页面提示保存成功并跳转货源列表页并刷新列表
4. 详情页展示与保存内容一致，后台主表和资源明细表正确落库 | 示例 | diff --git a/knowledge_base/03_best_practices/payment_flow_cases.md b/knowledge_base/03_best_practices/payment_flow_cases.md index 98efe4b..cbd3198 100644 --- a/knowledge_base/03_best_practices/payment_flow_cases.md +++ b/knowledge_base/03_best_practices/payment_flow_cases.md @@ -1,6 +1,8 @@ # 支付模块优秀用例范例 -> 请参考以下用例的颗粒度、数据具体化方式以及“UI + 数据状态”双重预期写法。 +> 请参考以下用例的颗粒度、数据具体化方式以及”UI + 数据状态”双重预期写法。 +> +> ⚠️ **注意**：以下示例为通用电商支付场景（支付宝/银行卡），运八项目的支付流程为 **云企付二期 (arpa_2)**，资金链路为 `货主打款 → 平台 → 财务打款 → 司机/车队长`，含垫资、合并打款、清分等特殊场景。实际生成用例时请以 `project_profile.md` §5.1 和 `terminology.md` §4 为准。 | 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | diff --git a/output/analysis/knowledge_sync_20260713.md b/output/analysis/knowledge_sync_20260713.md new file mode 100644 index 0000000..7ec8305 --- /dev/null +++ b/output/analysis/knowledge_sync_20260713.md @@ -0,0 +1,114 @@ +# 知识库同步报告 + +> 生成时间: 2026-07-13 +> 同步引擎: Agentic QE Fleet — knowledge-curator +> 同步类型: 全量知识库健康检查 + 交叉引用一致性修复 + +--- + +## 📊 知识库健康度 + +| 指标 | 值 | +| :--- | :--- | +| 知识库文件总数 | 14 | +| 健康文件 | 10 | +| 需关注文件 | 3 (已修复) | +| 不适用/归档文件 | 3 (已标记) | +| 历史缺陷总数 | 4 | +| 易漏场景总数 | 35+ (6大类 + 子项) | +| 最佳实践范例数 | 4 个领域 (数据上报/货源/营销/支付) | +| 术语条目数 | 60+ (7大类) | +| 重复率 | 0% (去重检查通过) | + +--- + +## 🔧 本次同步修复 + +### Fix 1: 清理 `order_manage_cases.md` 空表行 + +- **问题**: 文件包含 4 行空表格行（`| | | | | | | | | | |`），且用例编号使用 `MKT_ACT` 前缀（营销活动），与货源管理领域不符 +- **修复**: 删除空行，修正用例编号为 `SRC_CFG_001`（Source Configuration） +- **文件**: `knowledge_base/03_best_practices/order_manage_cases.md` + +### Fix 2: 标注 `payment_flow_cases.md` 项目差异 + +- **问题**: 文件包含通用电商支付示例（支付宝/银行卡），与运八项目云企付二期 (arpa_2) 支付流程存在结构性差异 +- **修复**: 在文件头添加 ⚠️ 提示，标注运八实际支付链路为 `货主打款 → 平台 → 财务打款 → 司机/车队长`，引导 AI 以 `project_profile.md` §5.1 为准 +- **文件**: `knowledge_base/03_best_practices/payment_flow_cases.md` + +### Fix 3: 建立历史缺陷 ↔ 易漏场景交叉引用 + +- **问题**: `historical_defects.md` 中的 4 个缺陷与 `common_missed_scenes.md` §6 的防御场景存在直接映射关系，但无显式引用 +- **修复**: 在 `historical_defects.md` 中为每个缺陷添加 `关联易漏场景` 字段，指向 `common_missed_scenes.md` 对应条目；在文件头添加关联知识说明 +- **映射关系**: + - `BUG-202607-01` → §6.多阶段依赖链 + - `BUG-202607-02` → §6.重试+手动触发并发 + - `BUG-202607-03` → §6.跨模块数据一致性 / §6.上报数据字段溯源 + - `BUG-202607-04` → §6.省份/区域配置隔离 +- **文件**: `knowledge_base/02_history/historical_defects.md` + +### 已确认清理（前置变更） + +- **删除占位示例缺陷** `BUG-202310-05--示例`（购物车价格缓存）：该示例为通用电商场景，与运八网络货运平台领域无关，已在工作树中移除 ✅ + +--- + +## 📋 知识库文件逐项审计 + +### ✅ 健康文件 (10) + +| 文件 | 类别 | 状态 | 备注 | +| :--- | :--- | :---: | :--- | +| `00_project/project_profile.md` | 项目画像 | ✅ | 2026-07-10 更新，352 菜单项，完整 | +| `00_project/operation_manual.md` | 操作手册 | ✅ | 2026-07-10 采集，184 截图，完整 | +| `01_standards/terminology.md` | 核心术语 | ✅ | 含 §7 数据上报术语，60+ 条目 | +| `01_standards/test_case_template.md` | 用例模板 | ✅ | 结构完整，含云效导出映射 | +| `01_standards/review_checklist.md` | 评审清单 | ✅ | 9 大类检查项，阻断/建议分级 | +| `01_standards/definition_of_done.md` | 完成定义 | ✅ | 8 维度质量门槛 | +| `02_history/historical_defects.md` | 历史缺陷 | ✅ | 4 个真实缺陷，已建立交叉引用 | +| `02_history/common_missed_scenes.md` | 易漏场景 | ✅ | 6 大类 35+ 子项，§6 来自安徽运八 | +| `03_best_practices/data_reporting_cases.md` | 数据上报范例 | ✅ | 8 维度覆盖框架 + 5 条示例用例 + 风险矩阵 | +| `03_best_practices/order_manage_cases.md` | 货源范例 | ✅ | 已清理空行，修正编号前缀 | + +### ⚠️ 归档/不适用文件 (3) + +| 文件 | 类别 | 状态 | 说明 | +| :--- | :--- | :---: | :--- | +| `02_history/marketing_rules.md` | 营销规则 | 📦 归档 | 来自 zanmall 项目，运八不支持营销活动 | +| `03_best_practices/marketing_activity_cases.md` | 营销范例 | 📦 归档 | 运八 `project_profile.md` §4 明确禁用 | +| `01_standards/terminology_optional_saas.md` | SaaS术语 | 📦 休眠 | 私域/导购/储值/CRM，当前项目不触发 | + +> 以上 3 个文件不会被知识激活器加载（关键词不匹配），但保留在知识库中供未来多项目复用。 + +--- + +## 🔍 知识缺口识别 + +| 缺口类别 | 描述 | 严重度 | 建议 | +| :--- | :--- | :---: | :--- | +| 运八支付范例 | `payment_flow_cases.md` 缺少运八特有支付场景（垫资打款、合并打款、清分结算）的示例用例 | P2 | 下次遇到支付相关需求时从执行结果中提取 | +| ETC 开票范例 | 项目含完整的 ETC 管理/开票模块（§2.15-2.16），但知识库无对应最佳实践 | P2 | 下次 ETC 相关需求时沉淀 | +| 财务统计范例 | 项目含 12+ 报表页面，但知识库无报表类测试范例 | P3 | 按需补充 | +| 合同管理范例 | 项目含 8 种合同类型，但知识库无合同管理测试范例 | P3 | 按需补充 | + +--- + +## 📈 知识库演进历史 + +| 时间 | 事件 | 影响文件 | +| :--- | :--- | :--- | +| 2026-07-13 | 知识同步：清理占位内容、建立交叉引用 | `historical_defects.md`, `order_manage_cases.md`, `payment_flow_cases.md` | +| 2026-07-13 | 安徽运八知识回写：4 个历史缺陷 + 易漏场景 §6 + 数据上报范例 | `historical_defects.md`, `common_missed_scenes.md`, `data_reporting_cases.md`, `terminology.md` | +| 2026-07-10 | 项目画像初始化：Playwright 采集 352 菜单项 | `project_profile.md`, `operation_manual.md` | + +--- + +## ✅ 同步结论 + +- **整体健康度**: 🟢 良好 +- **阻断问题**: 0 +- **本次修复**: 3 项 +- **待确认项**: 0 +- **知识缺口**: 4 个（均为 P2/P3，不阻断当前工作流） + +知识库处于健康状态，交叉引用已建立，AI 可从历史缺陷追溯到易漏场景清单，生成测试点时形成完整防御链。 diff --git a/output/analysis/安徽运八需求_关联与冲突.md b/output/analysis/安徽运八需求_关联与冲突.md index 0290bb6..010e5dc 100644 --- a/output/analysis/安徽运八需求_关联与冲突.md +++ b/output/analysis/安徽运八需求_关联与冲突.md @@ -1,7 +1,7 @@ # 安徽运八需求 关联需求与冲突检查 ## 目标需求 -- `source_docs\requirements_raw\安徽运八需求.docx` +- `source_docs\requirements_raw\安徽运八需求.md` ## 项目画像 - `knowledge_base\00_project\project_profile.md` @@ -10,9 +10,7 @@ - 未识别到同主题技术方案文档。 ## 关联需求识别 -| 序号 | 关联需求 | 相似度 | -| :--- | :--- | :--- | -| 1 | `source_docs\requirements_raw\网货企业端接口文档（最新）.pdf` | 0.0696 | +- 未识别到相似度达到阈值的历史需求文档。 ## 潜在冲突与修改建议 - 暂未识别到明显冲突条目。建议在需求评审时继续人工确认。 diff --git a/output/analysis/安徽运八需求_分析.md b/output/analysis/安徽运八需求_分析.md index cf5d4be..14618b1 100644 --- a/output/analysis/安徽运八需求_分析.md +++ b/output/analysis/安徽运八需求_分析.md @@ -1,106 +1,189 @@ -# 安徽运八需求 分析报告 +# 安徽运八需求 结构化分析 -> 生成时间: 2026-07-13 -> 文档角色: 需求分析 -> 原始来源: `source_docs/requirements_raw/安徽运八需求.docx` +> 生成时间: 2026-07-13（最后更新: 2026-07-14，根据14项确认决议） +> 需求文档: source_docs/requirements_raw/安徽运八需求.docx +> 重构需求: output/normalized_inputs/安徽运八需求/requirement_restructured.md（以API文档V1.0.2为查询+申诉权威数据源，以Showdoc文档为上报接口字段定义权威数据源） +> Showdoc上报接口文档: output/prototype/showdoc文档.md（5个上报接口 + FAQ） +> 项目画像: knowledge_base/00_project/project_profile.md -## 1. 需求概述 +## 1. 需求背景 -根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八）。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。 +根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将税源地为安徽运八的运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八），其他税源地不走此逻辑。 -### 核心目标 -- 实现上报流程的自动化管理（自动触发 + 重试 + 通知） -- 提供异常监控与核验结果展示 -- 提供向监管平台发起申诉的完整闭环能力 -- ETC发票上传作为税务抵扣凭证 +## 2. 目标 -### 涉及角色 -- 运营人员：看板监控、手动上传、发起申诉 -- 系统：自动触发上报、自动重试、自动更新字段 -- 监管平台（安徽运八）：核验上报数据、返回核验结果 -- 司机/财务：触发装货完成/打款完成/开票完成（间接触发上报） +实现上报流程的自动化管理，并提供异常监控与向平台发起申诉的能力。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。 -## 2. 功能模块分析 +## 3. 用户角色 -| 模块 | 功能 | 触发方式 | 依赖 | 关键风险 | -| :--- | :--- | :--- | :--- | :--- | -| 上报运单看板 | 汇总展示、筛选查询、导出 | 手动访问 | 无 | 数据量大时性能 | -| 第一次上报 | 装货完成后上报基础运单数据 | 自动触发 | 运单装货完成 | 失败阻断后续上报 | -| 第二次上报 | 打款完成后上报资金流水+轨迹 | 自动触发 | 第一次上报通过 | 7类核验，异常最多 | -| 第三次上报 | 开票完成后上报发票数据 | 自动触发 | 第二次上报通过 | 发票验证失败 | -| ETC发票上传 | 税务抵扣后上传ETC发票 | 手动触发 | 税务抵扣完成 | 税额计算精度 | -| 异常申诉 | 核验异常→申诉→监管复核→结果 | 手动触发 | 核验异常 | 申诉闭环完整性 | -| 上报日志 | 接口调用记录、请求/响应查看 | 手动访问 | 无 | 日志完整性 | +| 角色 | 职责 | +| :--- | :--- | +| 平台运营人员 | 查看看板、发起申诉、监控上报状态 | +| 系统自动 | 自动触发三阶段上报和ETC上传 | +| 财务人员 | 打款操作（触发第二次上报） | +| 安徽监管平台 | 接收上报数据、执行核验、反馈结果 | -## 3. 关键业务规则 +## 4. 功能模块 -### 3.1 上报阶段依赖链 -``` -装货完成 → 第一次上报 → 核验通过 → 自动更新字段 - ↓ -打款完成 → 第二次上报 → 7类核验（车辆资质/司机资质/资金流水/集中支付/合同/轨迹合规/运单重复） - ↓ -开票完成 → 第三次上报 → 发票验证 - ↓ -税务抵扣 → ETC发票上传 -``` +### 4.1 上报运单看板 +集中展示所有上报阶段运单的汇总状态，支持按条件筛选（运单号/托运单号/货源单号模糊搜索、上报阶段、核验状态、申诉状态）、查看详情和发起申诉。 -### 3.2 重试策略 -- 所有上报阶段：失败后自动重试，最多3次 -- 3次全部失败：通知运营人员（站内信/其他方式） -- 重试期间幂等保护：不产生重复上报 +### 4.2 委托合同上传（前置步骤） +运单第一次上报前，需先将委托合同（框架）通过 `/api/dataUpload/mandateContractFrame`（Showdoc定义）上传至省平台。委托合同（框架）和委托合同二选一上报。合同文件可暂不传，后续通过修改接口补充。 -### 3.3 状态机 -``` -上传中(蓝) ──成功→ 已上传(绿) -上传中(蓝) ──超时→ 上传失败(红) → 手动上传 → 上传中 -上传中(蓝) ──校验失败→ 异常(橙) → 查看详情 -``` +### 4.3 第一次上报（装货完成） +运单装货完成后自动触发，仅上传货源税源地为安徽运八的运单。上报数据包含运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息、保险信息等。核验通过后自动调用"修改第一次上报部分字段"接口。 -### 3.4 申诉状态机 -``` -未申诉 → 申诉中 → 申诉通过(绿) / 申诉驳回 → 重新申诉 → 申诉中 -``` +### 4.4 第二次上报（打款完成） +运费支付完成后自动触发，上报数据包含资金流水信息、车辆轨迹信息等。监管平台进行核验。⚠️ 根据网货企业端接口文档 V1.0.2 §4.1，核验项从需求描述的7类扩展为API定义的17项独立核验项：100=委托合同、120=承运合同、130=实时定位、140=运单时间逻辑、150=车辆资质、160=道路运输证、170=驾驶证、180=从业资格证、190=车辆重复、200=司机重复、210=车辆轨迹、220=运费收款、230=公司统一收款、240=集中支付、250=资金流水、260=发票信息、270=非通行车辆可开票。每项有独立的核验结果和申诉入口。 -## 4. 数据量预估 +### 4.5 第三次上报（开票完成） +发票开具完成后触发，上报数据包含运单信息、发票信息、油气发票信息等。 -| 对象 | 预估量级 | 说明 | -| :--- | :--- | :--- | -| 日上报运单数 | 1000-5000 | 根据平台运单量 | -| 每运单轨迹点数 | 2-2000 | 取决于运输距离 | -| 申诉并发量 | < 100/天 | 异常率较低 | -| 日志保留期 | 建议≥90天 | 审计和排查需要 | +### 4.6 ETC发票上传 +ETC发票税务抵扣成功后，由运营人员在运八系统**手动确认抵扣完成**，确认后系统触发ETC发票上传（非自动触发）。上传信息包含车牌号、车牌颜色、ETC发票号、不含税金额(invoiceAmount)、税率3%、税额、价税合计(totalPriceAndTax)、入口/出口收费站、交易时间等。 -## 5. 歧义标注 +### 4.7 异常申诉功能 +补全"异常查询 → 发起申诉 → 跟踪监管平台反馈 → 合规判断"的完整闭环。 -> ⚠️ 待确认：重试间隔时间未在需求中明确，建议确认（如30s/60s/120s递增） -> 影响范围: 所有上报阶段的重试行为 -> 建议确认方向: 与产品和安徽运八平台确认合理的重试间隔 +### 4.8 上报日志 +记录所有上报接口的调用记录（请求/响应报文、HTTP状态码、响应时间），用于问题排查和审计。 -> ⚠️ 待确认：站内信通知的具体内容模板未定义 -> 影响范围: 运营人员通知体验 -> 建议确认方向: 确认通知应包含哪些字段（运单号/失败原因/重试次数/建议操作） +## 5. 核心规则 -> ⚠️ 待确认：上报数据中"省份代码"字段默认值（当前项目属云南省=28，但本需求为安徽=34？） -> 影响范围: 第一次上报司机信息省份代码 -> 建议确认方向: 确认安徽运八上报的省份代码应使用哪个值 +### 5.1 税源地过滤 +- 仅税源地为安徽运八的运单触发上报 +- 其他税源地（如云南=28）不触发任何上报 -> ⚠️ 待确认：导出Excel的数据量上限未定义 -> 影响范围: 看板导出功能 -> 建议确认方向: 确认是否需要限制单次导出条数（如最多10000条） +### 5.2 上报阶段依赖链 +- 第一次上报是后续两次上报的基础 +- 第二次上报依赖第一次上报完成 +- 第三次上报依赖第二次上报完成 +- 后端必须做前置状态校验（非仅前端控制） -## 6. 与项目画像的差异化分析 +### 5.3 自动重试机制 +- 各阶段上报失败后自动重试（最多3次） +- 3次全部失败后告警通知运营人员 +- 重试期间禁止手动触发上传 -| 维度 | 项目画像（云南省） | 安徽运八需求 | 差异 | -| :--- | :--- | :--- | :--- | -| 上报省份 | 云南省(reportProvince=28) | 安徽省 | 省份代码需切换 | -| 支付方式 | arpa_2 + 网商银行(浦发/快钱/光大) | 同平台支付体系 | 资金流水需关联现有支付渠道 | -| 目标角色 | 运营/货主/车队长/司机/财务 | 主要面向运营人员 | 权限模型可复用 | -| 测试环境 | ybxcx.ynyun8.com:8000 | 同环境 | 测试环境可复用 | +### 5.4 核验规则 +- 第二次上报包含**17项独立核验**（API文档§4.1定义），比需求的7类更为细化 +- 核验异常可通过申诉机制向监管平台说明情况 +- 每项核验有独立的核验结果（verificationCode/verificationName/verificationState）和申诉入口 +- 申诉由安徽监管平台复核 -## 7. 风险总结 +> **核验项扩展说明（来源：API §4.1）**: 原始需求仅描述7大类核验（运单重复/车辆资质/司机资质/集中支付/资金流水/合同/轨迹合规），但API文档§4.1定义了完整的17项独立核验项（100=委托合同, 120=承运合同, 130=实时定位, 140=运单时间逻辑, 150=车辆资质, 160=道路运输证, 170=驾驶证, 180=从业资格证, 190=车辆重复, 200=司机重复, 210=车辆轨迹, 220=运费收款, 230=公司统一收款, 240=集中支付, 250=资金流水, 260=发票信息, 270=非通行车辆可开票）。每项有独立的核验结果和申诉入口，测试覆盖需从14条（7类×通过+异常）扩展到34条（17项×通过+异常）。 -| 风险ID | 类别 | 等级 | 说明 | -| :--- | :--- | :---: | :--- | -| RISK-FINANCIAL | 资损 | P1 | 资金流水金额不匹配、流水号重复可能导致财务数据错误 | -| RISK-AVAILABILITY | 可用性 | P2 | 上报接口超时或不可用影响业务流程，需重试+告警兜底 | +### 5.5 API接口清单（来自网货企业端接口文档 V1.0.2） + +| 接口 | URL | 方法 | 说明 | +|:---|:---|:---:|:---| +| 获取token | /sys/login | POST | JWT认证 | +| 上传申诉附件 | /appeal/uploadFile | POST | 文件上传 | +| 提交申诉运单 | /appeal/insert | POST | 发起申诉 | +| 查询异常运单信息 | /verificationSummary/page | POST | 分页查询，含abnormalDetails（17项核验明细） | +| 查询申诉进度 | /appeal/page | POST | 分页查询，含审核状态/审核人/取消/撤回 | +| 查询运单核验详情 | /verificationSummary/verificationDetail | POST | 单运单核验明细列表 | +| 查询发票合规 | /verificationSummary/cargoOwnerInvoiceInfo | POST | 判断托运人发票是否系统核验合规（需求未提及！） | +| 运单里程核验查询 | /verificationSummary/mileageVerificationInfo | POST | 批量查询运单里程核验状态 | +| 运单里程申诉 | /mileageAppeal/insert | POST | 提交里程申诉（需求未提及的新功能！） | + +### 5.6 申诉状态枚举（以API §4.4为权威） + +| Code | API名称(§4.4权威) | 原始需求对应 | 原型对应 | 我方可操作 | 说明 | +|:---:|:---|:---|:---|:---:|:---| +| 100 | **未申诉** | 未申诉 + 申诉中 | 未申诉 + 待省平台反馈 + 反馈处理中 | 是 | 含已提交但省平台尚未审核的情况（申诉"进行中"通过 abnormalDetails[].state=110 标识） | +| 110 | **审核通过** | 申诉通过 | 申诉通过 | 否（终态） | 终态 | +| 120 | **审核不通过** | 申诉驳回 | 申诉驳回 | 否（可重新申诉） | 可重新申诉 | +| 130 | **已取消** | （无） | （无） | **否·省平台只读** | 省平台侧操作取消申诉，我方系统不提供"取消申诉"功能，仅查询展示此状态 | + +> **已取消(130)专项说明**: +> - 状态130=已取消的触发在省平台侧（省平台管理员取消），非我方可操作。 +> - 我方系统**不提供"取消申诉"按钮或接口**，不测试我方主动取消申诉的用例。 +> - 申诉状态流转（我方视角）：未申诉(100) → 审核通过(110) [终态]；未申诉(100) → 审核不通过(120) → 重新申诉 → 未申诉(100)。 +> - 看板筛选下拉值以API §4.4为准（未申诉/审核通过/审核不通过/已取消），其中130仅作筛选展示。 + +### 5.7 申诉单项约束（API §3.3） + +- 接口 `POST /appeal/insert` 的 `verificationAbnormalItems` 参数说明为**"只支持单个异常项目申诉"** +- 每次申诉仅针对**一个**核验异常项 +- 同一运单有多个异常项时，需分别发起多次申诉（每项一个申诉单） +- 申诉流程必须包含**异常项单选步骤**，不允许批量勾选后一次提交 +- 传入多个异常项ID（如 `"120,160"`）时，接口应拒绝并返回错误提示 + +## 6. 数据字段（以Showdoc为权威字段定义） + +> **授权来源**: Showdoc文档（`output/prototype/showdoc文档.md`）定义上报接口字段结构。关键精度要求：上报接口时间格式为 `yyyyMMddHHmmss`（14位），第二次上报金额保留3位小数（如整数以.000填充），ETC invoiceAmount为不含税金额。 + +### 6.1 第一次上报核心字段（Showdoc: firstUpload） +- waybillInfo（建单信息）: 13字段必选（含mileage可选） +- consignorInfo（托运人信息）: 7字段必选 +- consigneeInfo（收货方信息）: 6字段必选（含unLoadingNationSubdivisionCode） +- driverInfo（司机信息）: 15字段必选（含registerDate、anchoredUrl） +- carInfo（接单车辆信息）: 20字段必选（含anchoredUrl） +- goodsInfos（货物信息）: 4字段/条必选（quantity=Double） +- insuranceInformation（保险信息）: 2字段可选 + +### 6.2 第二次上报核心字段（Showdoc: secondUpload） +- arrivalInfo（运抵信息）: 6字段必选（含startTicketFileUrl、arrivalTicketFileUrl） +- ownerStatements（货主流水）: 13字段必选（monetaryAmount=Double·3位小数） +- carrierStatements（承运人流水）: 14字段必选（含oilCardAmount·replaceAgreementFiles） +- carrierContractInfo（承运合同）: 18字段必选（含contractUrl·金额3位小数） +- ownerContractInfo（委托合同）: 18字段可选（委托合同与框架合同二选一） +- trackList（车辆轨迹）: 6字段/点必选（2~2000个点） + +### 6.3 第三次上报核心字段（Showdoc: thirdUpload） +- invoice（货主发票）: 17字段必选（含invoiceUrl文件） +- oilGasInvoices（油气发票）: 选填，可多条 + +### 6.4 ETC发票核心字段（Showdoc: etcInvoiceUpload） +- etcInvoices（ETC发票）: **17字段/张**（invoiceAmount=不含税金额·保留2位小数·税率3%） + +## 7. 状态流转 + +### 7.1 上报状态 +上传中(蓝色) → 已上传(绿色) / 上传失败(红色) / 异常(橙色) + +### 7.2 申诉状态（我方流转） +未申诉 → 申诉中 → 申诉通过 / 申诉驳回 → 重新申诉 + +> 已取消(130)由省平台侧操作，不纳入我方流转。 + +## 8. 歧义标注与待确认项（14项已全部确认 ✅） + +> **更新 2026-07-14**: 以下14项全部通过用户确认决议。方框标记为确认结果。 + +### 8.1 核验项定义差异 ✅ +> ✅ 确认: 以API文档§4.1 17项为准。17项核验全部展示，每项可独立申诉。测试点覆盖34条（17项×通过+异常）。 + +### 8.2 申诉状态枚举三版本不一致 ✅ +> ✅ 确认: 以API §4.4为准。130=已取消为省平台侧操作，我方只读不提供取消申诉功能。原型UI状态映射已确认。 + +### 8.3 第三次上报列表字段差异 ✅ +> ✅ 确认: 以原型15列为准。 + +### 8.4 看板申诉状态下拉值差异 ✅ +> ✅ 确认: 以API §4.4为准（未申诉/审核通过/审核不通过/已取消），其中130为省平台只读状态。 + +### 8.5 原型详情弹窗字段数量差异 ✅ +> ✅ 确认: 以接口Showdoc定义为准。 + +### 8.6 原型缺失车辆轨迹信息 ✅ +> ✅ 确认: 为原原型Bug。增强版原型已包含轨迹表格。 + +### 8.7 技术细节已全部确认 ✅ +> ✅ 待确认7: 自动重试间隔5s/15s/30s可用。 +> ✅ 待确认8: ETC税率统一3%，税额按3%计算。 +> ✅ 待确认9: 申诉超时告警阈值7个工作日可用。 +> ✅ 待确认10: 安徽=34与云南=28逻辑隔离，无冲突。 +> ✅ 待确认11: **Showdoc文档已读取**，字段定义以Showdoc为权威（金额3位小数，时间yyyyMMddHHmmss格式，ETC invoiceAmount=不含税金额，委托合同上传mandateContractFrame为前置步骤）。 +> ✅ 待确认12: 里程申诉接口 /mileageAppeal/insert 为独立接口，纳入本期范围。 +> ✅ 待确认13: ETC发票不含税金额(invoiceAmount)需在测试用例中体现。 +> ✅ **新增**: ETC触发条件确认 — 税务抵扣成功后由运营人员人工确认，非自动触发。 + +## 9. 项目差异化约束 + +- 省份代码: 安徽=34（非云南=28） +- 该需求为新增模块，与现有云南上报逻辑隔离 +- 测试环境管理端: https://ybxcx.ynyun8.com:8000/admin +- 支付方式: arpa_2（云企付二期） diff --git a/output/analysis/安徽运八需求_原型与接口分析.md b/output/analysis/安徽运八需求_原型与接口分析.md new file mode 100644 index 0000000..cd815ec --- /dev/null +++ b/output/analysis/安徽运八需求_原型与接口分析.md @@ -0,0 +1,196 @@ +# 安徽运八需求 — 原型&接口文档交叉分析 + +> 分析时间: 2026-07-13 +> 原型: `E:\WeChat\xwechat_files\wxid_2n9ko0aq1th822_44c3\msg\file\2026-07\anhuibaba_index.html` +> 接口文档: `E:\Downloads\网货企业端接口文档（最新）.pdf` (V1.0.2, 2023-04) +> 需求文档: `source_docs/requirements_raw/安徽运八需求.docx` + +--- + +## 一、关键发现总览 + +| # | 发现 | 严重程度 | 影响范围 | +|:---:|:---|:---:|:---| +| 1 | 核验项数量：需求7类 vs API文档17项 | **P0 阻断** | 第二次上报核验覆盖 | +| 2 | 申诉状态枚举三套不一致 | P1 | 申诉模块全部用例 | +| 3 | 第三次上报列表字段与原型不一致 | P1 | 第三次上报列表验证 | +| 4 | 详情弹窗字段分组/数量与原型不一致 | P1 | 所有详情弹窗用例 | +| 5 | API新增里程申诉接口 | P2 | 遗漏功能覆盖 | +| 6 | 看板申诉状态下拉值与需求不一致 | P1 | 看板筛选用例 | +| 7 | ETC发票详情含"不含税金额"字段 | P2 | ETC详情用例 | +| 8 | 原型看板有checkbox勾选列 | P3 | 看板交互用例 | +| 9 | 接口文档异常代码枚举vs需求异常代码 | P1 | 异常申诉用例 | + +--- + +## 二、核验项对照（重大差异） + +### 需求文档描述的7类核验 +1. 运单重复核验 +2. 车辆资质核验 +3. 司机资质核验 +4. 集中支付核验 +5. 资金流水核验 +6. 合同核验 +7. 车辆轨迹合规核验 + +### API文档定义的17项核验（§4.1 异常项ID对照表） + +| Code | 名称 | 需求是否提到 | +|:---:|:---|:---:| +| 100 | 委托合同 | 合并为"合同核验" | +| 120 | 承运合同 | 合并为"合同核验" | +| 130 | 实时定位 | ❌ 未提及 | +| 140 | 运单时间逻辑 | ❌ 未提及 | +| 150 | 车辆资质 | ✅ | +| 160 | 道路运输证 | 隐含在车辆资质 | +| 170 | 驾驶证 | 隐含在司机资质 | +| 180 | 从业资格证 | ✅ 司机资质 | +| 190 | 车辆重复 | ❌ 未提及（需求仅有运单重复） | +| 200 | 司机重复 | ❌ 未提及 | +| 210 | 车辆轨迹 | ✅ | +| 220 | 运费收款 | ❌ 未提及 | +| 230 | 公司统一收款 | ❌ 未提及 | +| 240 | 集中支付 | ✅ | +| 250 | 资金流水 | ✅ | +| 260 | 发票信息 | ❌ 未提及（第三次上报相关） | +| 270 | 非通行车辆可开票 | ❌ 未提及 | + +> ⚠️ **待确认**: 需求文档将17项核验归纳为7类是否合理？测试点应按需求7类还是API 17项逐项覆盖？建议按API 17项逐项覆盖（因为每项有独立的核验结果和申诉入口）。 + +--- + +## 三、申诉状态枚举对照 + +| 需求文档 | HTML原型 | API文档(§4.4) | API Code | +|:---|:---|:---|:---:| +| 未申诉 | 未申诉 | 未申诉 | 100 | +| 申诉中 | 待省平台反馈 | — | — | +| — | 反馈处理中 | — | — | +| 申诉通过 | 申诉通过 | 审核通过 | 110 | +| 申诉驳回 | 申诉驳回 | 审核不通过 | 120 | +| — | — | 已取消 | 130 | + +> ⚠️ **待确认**: +> - 需求"申诉中"被原型拆分为"待省平台反馈"+"反馈处理中"两个状态——哪个是最终版本？ +> - API有"已取消"状态(130)但需求和原型均未体现——是否支持申诉取消？ +> - 看板筛选下拉值以哪个为准？ + +--- + +## 四、列表字段差异 + +### 第三次上报列表 +| 需求字段 | 原型字段 | 差异 | +|:---|:---|:---| +| 车牌号 | ✅ | — | +| 司机姓名 | ✅ | — | +| 托运方名称 | ✅ | — | +| — | **税率** | 需求未列出 | +| — | **销售方名称** | 需求未列出 | +| — | **受票方名称** | 需求未列出 | +| — | **油气票张数** | 需求未列出 | + +原型比需求多4个字段（税率、销售方名称、受票方名称、油气票张数），共15列（含checkbox）。 + +### 第一次上报列表 +需求与原型一致，14字段 + checkbox。 + +### ETC上传列表 +原型字段（10列+checkbox）：货源单号/运单号/托运单号/ETC发票号/交易金额/入口收费站/出口收费站/交易时间/上传状态/操作 +**缺少**: 车牌号、司机姓名、托运方名称（需求中列出）、税率（需求中列出） + +--- + +## 五、详情弹窗字段差异 + +### 第一次上报详情弹窗 +| 分组 | 需求字段数 | 原型字段数 | 差异 | +|:---|:---:|:---:|:---| +| 建单信息 | 13 | 10 | 原型无"上游企业委托运输单号""网络货运经营者名称""统一社会信用代码""道路运输经营许可证编号""运输组货方式代码"等 | +| 托运人信息 | 7 | 8 | 原型多了货物名称/重量/体积 | +| 收货方信息 | 5 | 8 | 原型多了联系人/电话/收货时间/签收状态 | +| 司机信息 | 13 | 6 | 原型大幅简化 | +| 车辆信息 | 19 | 8 | 原型大幅简化 | +| 货物信息 | 4/条 | 8/条(卡片式) | 原型多了件数/单价/包装方式/危险货物标志 | +| 保险信息 | 2 | 7 | 原型多了保险类型/金额/有效期起止/保单状态 | +| 异常信息 | 4 | 4 | 一致 | + +> ⚠️ **待确认**: 需求文档字段定义来自接口文档（https://www.showdoc.com.cn/2210641821476236/9919735893682511），原型可能是简化版。详细字段数以接口文档为准还是以原型为准？ + +### 第二次上报详情弹窗 +| 分组 | 需求 | 原型 | 差异 | +|:---|:---|:---|:---| +| 资金流水 | 10字段 | 11字段 | 原型多了"实际支付金额" | +| 车辆轨迹 | 6字段/点 | **未展示** | 原型弹窗缺失车辆轨迹信息！ | +| 油气发票 | — | 有 | 需求未在第二次上报中提及油气发票 | + +> ⚠️ **待确认**: 原型第二次上报详情弹窗中车辆轨迹信息缺失——是原型bug还是实际不展示？ + +### 第三次上报详情弹窗 +需求分组：运单信息/发票信息(17字段)/油气发票信息(可选)/异常信息 +原型分组：运单信息/发票信息(10字段)/ETC发票信息(可选)/异常信息 +- **差异**: 原型把"油气发票"换成了"ETC发票信息"，发票信息字段从17减为10 + +--- + +## 六、API接口清单 + +接口文档（V1.0.2）定义了以下接口： + +| 接口 | URL | 方法 | 说明 | +|:---|:---|:---:|:---| +| 获取token | /sys/login | POST | JWT认证 | +| 上传申诉附件 | /appeal/uploadFile | POST | 文件上传 | +| 提交申诉运单 | /appeal/insert | POST | 发起申诉 | +| 查询异常运单信息 | /verificationSummary/page | POST | 分页查询，含abnormalDetails | +| 查询申诉进度 | /appeal/page | POST | 分页查询，含审核状态/审核人/取消/撤回 | +| 查询运单核验详情 | /verificationSummary/verificationDetail | POST | 单运单核验明细列表 | +| 查询发票合规 | /verificationSummary/cargoOwnerInvoiceInfo | POST | 判断托运人发票是否系统核验合规 | +| 运单里程核验查询 | /verificationSummary/mileageVerificationInfo | POST | 批量查询运单里程核验状态 | +| 运单里程申诉 | /mileageAppeal/insert | POST | **需求未提及的新功能！** | + +### 关键API数据结构 + +#### 异常运单查询响应 (verificationSummary/page) +``` +pageRecords[]: + freightSheetNumber, appealStateId/Name, verificationAbnormalItem, + createTime, lastVerifyTime, firstVerifyTime, vehicleNumber, + driverName, driverIdCard, verifyStateId/Name, + abnormalDetails[]: + id (异常项ID), name (异常项名称), message (异常原因), + time (异常时间), state (100=未申诉, 110=申诉中) +``` + +#### 核验详情响应 (verificationSummary/verificationDetail) +``` +details[]: + verificationCode (核验项编码), verificationName (核验项名称), + verificationState (核验状态), verificationStateId, + verificationTime, message (核验信息) +``` + +--- + +## 七、需要更新的测试资产 + +### 测试点更新 +1. **TP-C-006~TP-C-019**: 将"7类核验"扩展为"17项核验"逐项覆盖（+20个测试点） +2. **TP-F-xxx**: 申诉状态枚举对齐（确认最终版本后更新） +3. **TP-D-002**: 第三次上报列表字段数修正为原型字段数 +4. **TP-E-xxx**: ETC上传列表字段对齐 +5. **新增TP**: 里程申诉功能、发票合规查询功能 +6. **TP-A-xxx**: 看板申诉状态下拉值对齐 + +### 测试用例更新 +1. 核验项相关用例从14条扩展到34条（17项×2 pass+exception） +2. 申诉状态相关用例枚举值对齐 +3. 第三次上报列表字段验证用例更新 +4. 新增里程申诉用例 +5. 新增发票合规查询用例 + +### 需求分析更新 +1. 核验项从7类更新为17项 +2. 申诉状态枚举标注三版本差异 +3. 新增API接口清单 diff --git a/output/analysis/安徽运八需求_测试数据.md b/output/analysis/安徽运八需求_测试数据.md index b1a1e4b..f803840 100644 --- a/output/analysis/安徽运八需求_测试数据.md +++ b/output/analysis/安徽运八需求_测试数据.md @@ -6,6 +6,12 @@ ### 金额/数值 - `3%` +- `3%` +- `3%` +- `3%` +- `3%` +- `3%` +- `3%` ## 需要人工补充的数据 diff --git a/output/analysis/安徽运八需求_覆盖率审计.md b/output/analysis/安徽运八需求_覆盖率审计.md new file mode 100644 index 0000000..6a9e007 --- /dev/null +++ b/output/analysis/安徽运八需求_覆盖率审计.md @@ -0,0 +1,295 @@ +# 安徽运八需求 覆盖率审计 + +> 审计日期: 2026-07-13 +> 审计范围: 需求文档 (requirement.md) → 测试点 (103个) → 测试用例 (128个) → 风险评估 (2项) +> 审计方法: 四维追溯矩阵 + 风险覆盖核查 + 覆盖热力图 + +--- + +## 覆盖概览 + +| 指标 | 值 | 目标 | 状态 | +| :--- | :---: | :---: | :---: | +| 需求→测试点覆盖率 | 93.75% (45/48) | >= 95% | **FAIL** | +| P0测试点→用例覆盖率 | 100% (25/25) | 100% | **PASS** | +| P1测试点→用例覆盖率 | 100% (50/50) | >= 90% | **PASS** | +| P0风险覆盖率 | N/A (无P0风险项) | 100% | **PASS** | +| P1风险覆盖率 | 100% (1/1) | >= 90% | **PASS** | +| 过度覆盖率 | 0% (0/128) | <= 5% | **PASS** | + +**结论**: 需求→测试点覆盖率 93.75% 未达到 95% 门槛，存在3个覆盖缺口需补充。P0 测试点→用例覆盖率 100% 达标，风险覆盖率达标，无过度覆盖。 + +--- + +## 覆盖缺口 + +### 缺口 GAP-001: 第一次上报列表字段完整性 — 无测试点 + +- **需求条目**: REQ-B-07 (需求文档 Section 2.2 "列表字段") +- **缺口类型**: 无测试点覆盖 +- **风险等级**: P1 +- **详细说明**: 需求明确列出第一次上报列表页的14个字段（货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、业务类型、货物名称、装货地址、卸货地址、运输里程、合同编号、上报状态、操作）。其他模块（看板/第二次/第三次/ETC/申诉/日志）均有列表字段完整性的测试点（TP-A-008, TP-C-004, TP-D-002, TP-E-002, TP-F-002, TP-G-005），但第一次上报模块缺少对应的列表字段完整性测试点。现有 TP-A-008 覆盖的是看板列表字段（不同字段集合），TP-B-011/012 覆盖的是详情弹窗字段（非列表）。 +- **对比**: 同为"列表字段"需求项，第二次上报有 TP-C-004，第三次上报有 TP-D-002，ETC 有 TP-E-002，仅第一次上报缺失。 +- **建议**: 新增测试点 TP-B-020，验证第一次上报列表页14个字段完整且顺序与需求一致。对应新增用例覆盖。 + +### 缺口 GAP-002: 第二次上报自动重试机制 — 无测试点 + +- **需求条目**: REQ-C-05 (需求文档 Section 2.3 "特殊说明" 第4条) +- **缺口类型**: 无测试点覆盖 +- **风险等级**: P1 +- **详细说明**: 需求明确要求"若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员"。其他上报阶段均已有自动重试测试点（第一次: TP-B-007, 第三次: TP-D-007, ETC: TP-E-006），但第二次上报模块缺少对应的自动重试测试点。第二次上报是核验项最多的阶段（7类核验），也是最容易出现异常的环节，重试机制缺失覆盖是高风险的遗漏。 +- **对比**: 三阶段+ETC共4个上报入口，第一次/第三次/ETC均有重试测试点，仅第二次缺失。 +- **建议**: 新增测试点 TP-C-023，验证第二次上报失败后自动重试最多3次、间隔递增、全部失败后告警。对应新增用例覆盖。 + +### 缺口 GAP-003: 第二次上报详情弹窗分组字段完整性 — 无测试点 + +- **需求条目**: REQ-C-08 (需求文档 Section 2.3 "详情弹窗字段分组") +- **缺口类型**: 无测试点覆盖 +- **风险等级**: P2 +- **详细说明**: 需求明确定义第二次上报详情弹窗的6个分组，其中"资金流水信息"分组包含10个必选字段（支付金额、支付方式、支付时间、付款方名称、收款方名称、收款人、收款账号、收款账号类型、流水号、支付状态）和"车辆轨迹信息"分组包含6个必选字段（定位类型、定位时间、定位地点、经度、纬度、轨迹类型）。现有 TP-C-004 覆盖的是列表字段（14个列表字段），而非详情弹窗分组字段。其他模块的详情弹窗均有字段完整性测试点（第一次: TP-B-011/012, 第三次: TP-D-003, ETC: TP-E-003, 申诉: TP-F-004），仅第二次上报缺失。 +- **对比**: 同为"详情弹窗字段分组"需求项，第一次上报有 TP-B-011/012，第三次上报有 TP-D-003，仅第二次上报缺失独立的详情弹窗测试点。 +- **建议**: 新增测试点 TP-C-024，验证第二次上报详情弹窗6个分组（运单/托运方/收货方/资金流水/车辆轨迹/异常）的字段完整性和数据正确性。资金流水10字段和车辆轨迹6字段需重点验证。对应新增用例覆盖。 + +--- + +## 需求→测试点 追溯矩阵 + +### 模块A: 上报运单看板 (7条需求) + +| 需求条目 | 需求描述 | 测试点 | 覆盖状态 | +| :--- | :--- | :--- | :---: | +| REQ-A-01 | 看板模糊搜索(运单号/托运单号/货源单号) | TP-A-001 | **PASS** | +| REQ-A-02 | 看板按上报阶段筛选(全部/第一次/第二次/第三次) | TP-A-002 | **PASS** | +| REQ-A-03 | 看板按核验状态筛选(全部/异常/通过) | TP-A-003 | **PASS** | +| REQ-A-04 | 看板按申诉状态筛选(全部/未申诉/申诉中/申诉通过/申诉驳回) | TP-A-004 | **PASS** | +| REQ-A-05 | 操作按钮(查询/重置/导出) | TP-A-001, TP-A-006, TP-A-007 | **PASS** | +| REQ-A-06 | 看板列表14字段 | TP-A-008 | **PASS** | +| REQ-A-07 | 操作列(申诉/进度/详情) + 详情弹窗分组 | TP-A-010, TP-A-011 | **PASS** | + +### 模块B: 第一次上报-装货完成 (9条需求) + +| 需求条目 | 需求描述 | 测试点 | 覆盖状态 | +| :--- | :--- | :--- | :---: | +| REQ-B-01 | 装货完成后自动触发(仅安徽税源地) | TP-B-001, TP-B-002 | **PASS** | +| REQ-B-02 | 上报数据包含7个子对象必选字段 | TP-B-001, TP-B-003 | **PASS** | +| REQ-B-03 | 核验通过后自动调用修改字段接口 | TP-B-006 | **PASS** | +| REQ-B-04 | 上报失败自动重试最多3次 | TP-B-007 | **PASS** | +| REQ-B-05 | 全部重试失败后通知运营人员 | TP-B-008 | **PASS** | +| REQ-B-06 | 上报状态规则+标签颜色 | TP-B-009, TP-B-010 | **PASS** | +| **REQ-B-07** | **第一次上报列表14字段** | **无** | **GAP** | +| REQ-B-08 | 详情弹窗按子对象分组(含异常信息) | TP-B-011, TP-B-012, TP-B-013 | **PASS** | +| REQ-B-09 | 手动上传按钮(仅上传失败状态) | TP-B-009 | **PASS** | + +### 模块C: 第二次上报-打款完成 (10条需求) + +| 需求条目 | 需求描述 | 测试点 | 覆盖状态 | +| :--- | :--- | :--- | :---: | +| REQ-C-01 | 打款完成后自动触发 | TP-C-001 | **PASS** | +| REQ-C-02 | 上报数据(运抵/资金流水/合同/轨迹) | TP-C-001 | **PASS** | +| REQ-C-03 | 资金流水单号重复系统自动检查 | TP-C-014, TP-C-015 | **PASS** | +| REQ-C-04 | 补传轨迹功能 | TP-C-022 | **PASS** | +| **REQ-C-05** | **上报失败自动重试最多3次+告警** | **无(告警部分间接覆盖)** | **GAP** | +| REQ-C-06 | 第二次上报列表字段 | TP-C-004 | **PASS** | +| REQ-C-07 | 收款账号类型(个人/对公)+标签颜色 | TP-C-005 | **PASS** | +| **REQ-C-08** | **详情弹窗6分组字段完整性** | **无** | **GAP** | +| REQ-C-09 | 7类核验(通过+异常各14场景) | TP-C-006~TP-C-019 | **PASS** | +| REQ-C-10 | 第二次上报依赖第一次完成 | TP-C-020 | **PASS** | + +### 模块D: 第三次上报-开票完成 (7条需求) + +| 需求条目 | 需求描述 | 测试点 | 覆盖状态 | +| :--- | :--- | :--- | :---: | +| REQ-D-01 | 开票完成后触发(依赖第二次) | TP-D-001, TP-D-005 | **PASS** | +| REQ-D-02 | 上报数据(运单+发票+油气发票) | TP-D-001, TP-D-004 | **PASS** | +| REQ-D-03 | 增值税发票验证失败处理 | TP-D-006 | **PASS** | +| REQ-D-04 | 上报失败自动重试最多3次+告警 | TP-D-007 | **PASS** | +| REQ-D-05 | 第三次上报列表11字段 | TP-D-002 | **PASS** | +| REQ-D-06 | 详情弹窗字段分组(发票17字段+油气发票) | TP-D-003, TP-D-008 | **PASS** | +| REQ-D-07 | 发票金额精度校验(价税合计2位小数) | TP-D-010 | **PASS** | + +### 模块E: ETC发票上传 (6条需求) + +| 需求条目 | 需求描述 | 测试点 | 覆盖状态 | +| :--- | :--- | :--- | :---: | +| REQ-E-01 | ETC发票上传触发 | TP-E-001 | **PASS** | +| REQ-E-02 | 税务抵扣前置条件 | TP-E-004 | **PASS** | +| REQ-E-03 | ETC发票验证失败处理 | TP-E-005 | **PASS** | +| REQ-E-04 | 上报失败自动重试最多3次+告警 | TP-E-006 | **PASS** | +| REQ-E-05 | ETC上传列表11字段 | TP-E-002 | **PASS** | +| REQ-E-06 | 详情弹窗3分组(运单7+ETC18+异常4) | TP-E-003 | **PASS** | + +### 模块F: 异常申诉功能 (5条需求) + +| 需求条目 | 需求描述 | 测试点 | 覆盖状态 | +| :--- | :--- | :--- | :---: | +| REQ-F-01 | 申诉完整闭环(异常查询→发起→反馈→判断) | TP-F-001, TP-F-003 | **PASS** | +| REQ-F-02 | 申诉列表13字段 | TP-F-002 | **PASS** | +| REQ-F-03 | 申诉详情弹窗5分组字段 | TP-F-004 | **PASS** | +| REQ-F-04 | 申诉复核说明(省平台复核,驳回可重新申诉) | TP-F-006 | **PASS** | +| REQ-F-05 | 异常代码一览表映射 | TP-F-011 | **PASS** | + +### 模块G: 上报日志 (4条需求) + +| 需求条目 | 需求描述 | 测试点 | 覆盖状态 | +| :--- | :--- | :--- | :---: | +| REQ-G-01 | 查询条件(单号/阶段/结果/时间范围) | TP-G-001~TP-G-004 | **PASS** | +| REQ-G-02 | 日志列表9字段 | TP-G-005 | **PASS** | +| REQ-G-03 | 详情弹窗(完整请求/响应报文) | TP-G-006 | **PASS** | +| REQ-G-04 | 所有上报接口调用记录全覆盖 | TP-G-007 | **PASS** | + +### 跨模块需求 + +| 需求条目 | 需求描述 | 测试点 | 覆盖状态 | +| :--- | :--- | :--- | :---: | +| REQ-X-01 | 三阶段依赖链完整性 | TP-B-005, TP-C-020, TP-D-005, TP-X-001 | **PASS** | +| REQ-X-02 | 非安徽税源地不上报 | TP-B-002, TP-X-004 | **PASS** | +| REQ-X-03 | 多省份数据隔离 | TP-X-005 | **PASS** | + +--- + +## 测试点→用例 追溯矩阵 + +> 完整103条追溯见测试用例文件内置映射表（第199-305行），以下为P0测试点专项核查。 + +### P0测试点覆盖确认 (25/25 = 100%) + +| P0测试点 | 描述 | 对应用例 | 覆盖状态 | +| :--- | :--- | :--- | :---: | +| TP-A-001 | 看板模糊搜索 | AH_REPORT_DASH_001, 002, 003 | **PASS** | +| TP-B-001 | 装货完成后自动触发第一次上报 | AH_REPORT_R1_001 | **PASS** | +| TP-B-002 | 仅安徽税源地运单触发 | AH_REPORT_R1_002, 003 | **PASS** | +| TP-B-004 | 省份代码=34(防历史缺陷) | AH_REPORT_R1_003, 006 | **PASS** | +| TP-B-005 | 第一次是后续前置条件(防历史缺陷) | AH_REPORT_R1_007, 008 | **PASS** | +| TP-B-014 | 第一次上报幂等性(防历史缺陷) | AH_REPORT_R1_013, 014, CROSS_006 | **PASS** | +| TP-C-001 | 打款完成后自动触发第二次上报 | AH_REPORT_R2_001 | **PASS** | +| TP-C-002 | 资金流水数据来源支付流水表(防历史缺陷) | AH_REPORT_R2_002 | **PASS** | +| TP-C-003 | 财务修改金额后使用最新金额(防历史缺陷) | AH_REPORT_R2_003 | **PASS** | +| TP-C-006 | 运单重复核验—通过场景 | AH_REPORT_R2_005 | **PASS** | +| TP-C-007 | 运单重复核验—异常场景 | AH_REPORT_R2_006 | **PASS** | +| TP-C-020 | 第二次依赖第一次完成(防历史缺陷) | AH_REPORT_R2_024 | **PASS** | +| TP-C-021 | 第二次上报幂等性(防历史缺陷) | AH_REPORT_R2_025, CROSS_006 | **PASS** | +| TP-D-001 | 开票完成后触发第三次上报 | AH_REPORT_R3_001 | **PASS** | +| TP-D-005 | 第三次依赖第二次完成(防历史缺陷) | AH_REPORT_R3_006, 007 | **PASS** | +| TP-E-001 | ETC发票上传触发 | AH_REPORT_ETC_001 | **PASS** | +| TP-E-004 | 税务抵扣前置条件 | AH_REPORT_ETC_004 | **PASS** | +| TP-F-001 | 申诉完整闭环 | AH_REPORT_APL_001 | **PASS** | +| TP-F-003 | 申诉状态流转全路径 | AH_REPORT_APL_004, 005 | **PASS** | +| TP-G-001 | 日志按单号模糊搜索 | AH_REPORT_LOG_001, 002 | **PASS** | +| TP-G-002 | 日志按上报阶段筛选 | AH_REPORT_LOG_003 | **PASS** | +| TP-X-001 | 三阶段依赖链端到端(防历史缺陷) | AH_REPORT_CROSS_001 | **PASS** | +| TP-X-002 | 多模块数据一致性(防历史缺陷) | AH_REPORT_CROSS_002 | **PASS** | +| TP-X-003 | 安徽运八全流程完整链路 | AH_REPORT_CROSS_003 | **PASS** | +| TP-X-004 | 非安徽税源地全流程不上报 | AH_REPORT_CROSS_004 | **PASS** | + +### P1测试点覆盖核查 (50/50 = 100%) + +全部50个P1测试点均有对应用例覆盖，详见测试用例文件内置映射表。抽查5个高风险P1测试点： + +| P1测试点 | 描述 | 对应用例 | 覆盖状态 | +| :--- | :--- | :--- | :---: | +| TP-B-003 | 第一次上报建单信息格式校验 | AH_REPORT_R1_004, 005, 021 (3条) | **PASS** | +| TP-B-007 | 第一次上报自动重试3次 | AH_REPORT_R1_010 | **PASS** | +| TP-C-019 | 轨迹合规核验—异常(点位不足) | AH_REPORT_R2_022, 023 (2条) | **PASS** | +| TP-D-006 | 增值税发票验证失败 | AH_REPORT_R3_008, 009 (2条) | **PASS** | +| TP-E-007 | ETC税额计算精度(资损风险) | AH_REPORT_ETC_008 | **PASS** | + +--- + +## 风险覆盖审计 + +### 风险矩阵覆盖 + +| 风险ID | 等级 | 风险描述 | 覆盖测试点 | 覆盖用例 | 覆盖状态 | +| :--- | :---: | :--- | :--- | :--- | :---: | +| RISK-FINANCIAL | P1 | ETC税额计算/发票金额精度/打款金额数据溯源，涉及资损 | TP-C-002, TP-C-003, TP-D-010, TP-E-007 | AH_REPORT_R2_002, R2_003, R3_012, ETC_008 | **PASS** | +| RISK-AVAILABILITY | P2 | 监管平台接口超时/弱网/服务不可用导致上报中断 | TP-B-007, TP-B-015, TP-B-016, TP-D-007, TP-E-006, TP-F-013 | AH_REPORT_R1_010, R1_015, R1_016, R3_010, ETC_007, APL_015 | **PASS** | + +### 风险覆盖统计 + +| 风险等级 | 总数 | 已覆盖 | 覆盖率 | 目标 | 状态 | +| :--- | :---: | :---: | :---: | :---: | :---: | +| P0 | 0 | 0 | N/A | 100% | **PASS** | +| P1 | 1 | 1 | 100% | >= 90% | **PASS** | +| P2 | 1 | 1 | 100% | — | **PASS** | + +--- + +## 过度覆盖审计 + +### 反向追溯: 用例 → 需求 + +全部128条测试用例均可追溯至明确的测试点，所有测试点均可追溯至需求条目或历史缺陷（历史缺陷本身源于需求Bug）。 + +| 检查项 | 结果 | +| :--- | :---: | +| 总用例数 | 128 | +| 可追溯用例 | 128 | +| 无需求依据的用例 | 0 | +| 冗余/重复用例 | 0 | +| 过度覆盖率 | 0% | +| 目标(<= 5%) | **PASS** | + +**说明**: 所有用例均通过"对应TP-xxx"或"[AI修正: 历史缺陷防御]"标记明确了来源。历史缺陷用例（BUG-202607-01/02/03/04）均有对应的需求依赖项作为依据，不属于过度覆盖。 + +--- + +## 覆盖热力图 + +| 模块 | 需求条目 | 测试点 | 测试用例 | 覆盖密度 | 评价 | +| :--- | :---: | :---: | :---: | :---: | :--- | +| A 上报运单看板 | 7 | 14 | 18 | **高** | 全维度覆盖，包含UI/权限/边界/空状态 | +| B 第一次上报 | 9 | 19 | 23 | **高** | 全维度覆盖，但列表字段完整性缺失(GAP-001) | +| C 第二次上报 | 10 | 22 | 26 | **中高** | 7类核验全覆盖(**亮点**)，但重试和详情弹窗缺失(GAP-002/003) | +| D 第三次上报 | 7 | 11 | 14 | **中高** | 主流程+异常+金额精度全覆盖 | +| E ETC发票上传 | 6 | 9 | 12 | **中高** | 税额精度(资损)专项覆盖(**亮点**)，多发票场景覆盖 | +| F 异常申诉 | 5 | 13 | 17 | **高** | 完整闭环+状态流转+权限+异常代码映射全覆盖(**亮点**) | +| G 上报日志 | 4 | 9 | 11 | **中高** | 搜索/筛选/报文详情/审计全覆盖 | +| X 跨模块 | — | 6 | 7 | **高** | 端到端链路+数据一致性+省份隔离全覆盖 | + +### 覆盖盲区 + +| 盲区 | 位置 | 影响 | +| :--- | :--- | :--- | +| 第一次上报列表字段完整性 | 模块B | 列表字段渲染错误无法被测试捕获（如字段缺失、顺序错乱、格式错误） | +| 第二次上报自动重试 | 模块C | 最易出异常的阶段缺失重试验证，依赖链断裂后无自动恢复覆盖 | +| 第二次上报详情弹窗分组完整性 | 模块C | 资金流水10字段和车辆轨迹6字段在详情弹窗中的展示未验证 | + +--- + +## 历史缺陷防御覆盖核查 + +| 历史缺陷ID | 防御测试点数 | 防御用例数 | 覆盖状态 | +| :--- | :---: | :---: | :---: | +| BUG-202607-01 (阶段依赖链断裂) | 4 (TP-B-005, C-020, D-005, X-001) | 6 | **PASS** | +| BUG-202607-02 (重试幂等缺陷) | 5 (TP-B-014, C-021, D-009, E-008, F-012) | 6 | **PASS** | +| BUG-202607-03 (跨模块数据不一致) | 3 (TP-C-002, C-003, X-002) | 4 | **PASS** | +| BUG-202607-04 (省份代码硬编码) | 2 (TP-B-004, X-005) | 2 | **PASS** | + +全部4个已知历史缺陷均有充分的正向+反向防御覆盖。 + +--- + +## 审计结论与建议 + +### 整体评价 + +- 本次覆盖率审计发现 **3个覆盖缺口**，需求→测试点覆盖率 **93.75%**，略低于95%目标 +- **亮点**: 第二次上报7类核验逐项覆盖（通过+异常各14个测试点）、申诉完整闭环验证、跨模块端到端链路、历史缺陷100%防御覆盖、ETC税额精度专项覆盖 +- **改进项**: 3个缺口均为"完整性"类遗漏（列表字段/重试机制/详情弹窗），属于测试点设计时未逐条对照需求清单的系统性遗漏 + +### 建议行动 + +| 优先级 | 行动项 | 对应缺口 | +| :---: | :--- | :--- | +| **P0** | 新增 TP-B-020 "第一次上报列表字段完整性校验" 及对应用例（参考 TP-C-004 结构） | GAP-001 | +| **P0** | 新增 TP-C-023 "第二次上报自动重试—最多3次间隔递增" 及对应用例（参考 TP-B-007 结构） | GAP-002 | +| **P1** | 新增 TP-C-024 "第二次上报详情弹窗分组字段完整性" 及对应用例（重点: 资金流水10字段+车辆轨迹6字段） | GAP-003 | +| **P2** | 需求"异常代码一览表"仅有标题无内容，确认后补充 TP-F-011 的详细验证数据 | REQ-F-05 | +| **P2** | 确认自动重试间隔时间（当前假设5s/15s/30s），更新所有重试用例的测试数据 | — | + +--- + +> **审计元数据**: +> - 审计依据: requirement.md (7模块/48需求条目), 测试点 (103个/7模块), 测试用例 (128个/7模块), 风险评估 (2项风险) +> - 追溯方法: 正向追溯 (需求→测试点) + 反向追溯 (用例→需求) + 风险覆盖交叉验证 +> - 覆盖率计算: 需求→测试点 = 已覆盖需求条目 / 总需求条目; 过度覆盖 = 无需求依据的用例 / 总用例数 diff --git a/output/analysis/安徽运八需求_评审报告.md b/output/analysis/安徽运八需求_评审报告.md new file mode 100644 index 0000000..d92d51d --- /dev/null +++ b/output/analysis/安徽运八需求_评审报告.md @@ -0,0 +1,188 @@ +# 安徽运八需求 评审报告 + +> 评审时间: 2026-07-13 +> 评审对象: output/test_cases/安徽运八需求_测试用例.md (128条) +> 评审依据: review_checklist.md / test_case_template.md / definition_of_done.md / 风险评估报告 + +--- + +## 评审概览 + +| 指标 | 值 | +| :--- | :--- | +| 用例总数 | 128 | +| 阻断项 | 7 | +| 建议项 | 7 | +| 优化项 | 7 | +| 评分 | 80/100 | + +--- + +## 阻断项 + +### B-001: R2_004 字段数标题与预期结果不一致（标题14 vs 实际列举17） + +- 用例编号: AH_REPORT_R2_004 +- 问题: 标题声明"验证第二次上报列表14个字段完整"，但预期结果中逐项列举了17个字段（货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/承运运费/总金额/付款方式/付款时间/收款人/收款账号/收款账号类型/核验状态/异常项/上报状态/操作）。执行人无法确认应以标题为准还是以预期结果为准。 +- 修复建议: 与需求/前端确认第二次上报列表的实际列数，统一标题和预期结果中的字段数量和名称列表。 + +### B-002: R3_002 字段数标题与预期结果不一致（标题11 vs 实际列举13） + +- 用例编号: AH_REPORT_R3_002 +- 问题: 标题声明"验证第三次上报列表展示11个字段完整"，预期结果文字也写"列表展示11个字段"，但实际逐项列举了13个字段（货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/发票号码/发票金额/开票日期/核验状态/异常原因/上报状态/操作）。文字表述"11个字段"与列举内容自相矛盾。 +- 修复建议: 确认第三次上报列表的准确字段数，修正标题和预期结果中的数字，使其与列举的字段名数一致。 + +### B-003: LOG_006 字段数标题与预期结果不一致（标题9 vs 实际列举11） + +- 用例编号: AH_REPORT_LOG_006 +- 问题: 标题声明"验证上报日志列表9个字段完整展示"，但预期结果中逐项列举了11个字段（序号/货源单号/运单号/托运单号/上报阶段/上报结果/接口URL/HTTP状态码/响应时间/上报时间/操作）。 +- 修复建议: 确认上报日志列表实际列数，统一标题和预期结果。 + +### B-004: APL_003 字段数标题与预期结果不一致（标题13 vs 实际列举14） + +- 用例编号: AH_REPORT_APL_003 +- 问题: 标题声明"验证申诉记录列表13个字段完整展示"，但预期结果逐项列举了14个字段（运单号/托运单号/车牌号/司机姓名/托运方名称/上报阶段/核验状态/异常项/申诉状态/申诉时间/申诉人/省平台反馈结果/监管平台反馈时间/操作）。 +- 修复建议: 确认申诉记录列表实际列数，统一标题和预期结果。 + +### B-005: R3_003 字段数标题与预期结果不一致（标题17 vs 实际合计19） + +- 用例编号: AH_REPORT_R3_003 +- 问题: 标题声明"验证第三次上报详情弹窗发票信息17字段完整展示"，但预期结果中各分组字段合计为19个：发票基础字段5个（托运单号数组、发票号码、发票代码号、发票金额(价税合计)、开票日期）+ 销售方8字段（名称/纳税人识别号/地址/电话/开户行/银行账户/账号/联系人）+ 受票方6字段（名称/纳税人识别号/地址/电话/开户行/银行卡号）= 19。标题的"17"与实际合计"19"不匹配。 +- 修复建议: 逐字段核对发票信息分组，确认准确字段数为17还是19，修正标题或补充/删除预期结果中的字段。 + +### B-006: APL_015 预期结果使用"可能"措辞，不可验证 + +- 用例编号: AH_REPORT_APL_015 +- 问题: 预期结果中出现"系统可能有超时告警提醒运营人员跟进"——"可能"表示该行为不确定，无法作为可验证的测试断言。若超时告警是需求要求的必要行为，则必须断言为"系统触发超时告警通知运营人员"；若当前未明确，应标记为待确认项。 +- 修复建议: (1) 若超时告警已纳入需求，将"可能"改为确定性描述并补充告警渠道和内容；(2) 若尚未明确，在备注中增加 `> ⚠️ 待确认：申诉超时告警机制是否实现、告警渠道和阈值`。 + +### B-007: CROSS_003 违反原子性原则——单条用例验证完整四阶段端到端流程 + +- 用例编号: AH_REPORT_CROSS_003 +- 问题: 该用例将装货完成、财务打款、发票开具、ETC上传全部串联在一条用例中验证，跨越4个上报阶段和多个触发条件。任一环节失败时，无法快速定位问题在哪个阶段。此外，各阶段已有独立的单阶段用例覆盖（R1/R2/R3/ETC系列），此全链路用例与它们形成冗余但缺乏精确定位能力。 +- 修复建议: 保留此用例作为冒烟测试或集成验证（类型改为"冒烟测试"），但应将各阶段的独立断言缩减为"全链路各阶段按序成功完成，看板和日志数据一致"，移除重复的具体阶段内断言；或拆分为阶段衔接用例（如"第一阶段成功后第二阶段可触发"），每种衔接一个用例。 + +--- + +## 建议项 + +### S-001: LOG_001 和 LOG_003 优先级 P0 偏高，建议降为 P1 + +- 用例编号: AH_REPORT_LOG_001, AH_REPORT_LOG_003 +- 问题: 上报日志属于审计/支持类功能，日志搜索和阶段筛选并非用户核心业务操作流程，置于 P0 会稀释 P0 集合的聚焦度。当前 P0 已有 28 条（占比 22%），将这两个降级可优化 P0 密度。 +- 修复建议: 降为 P1。核心原因：日志功能不可用时不影响上报主流程和业务闭环，不符合 P0 定义（核心流程阻断/资损风险）。 + +### S-002: APL_015 类型建议改为"易用性测试" + +- 用例编号: AH_REPORT_APL_015 +- 问题: 该用例验证的是"用户长时间等待后的系统状态提示和超时告警体验"，属于用户体验/易用性范畴，而非纯功能正确性验证。 +- 修复建议: 将 `类型` 从 `功能测试` 改为 `易用性测试`。 + +### S-003: R1_003 同时验证3个省份，建议按省份拆分为独立用例 + +- 用例编号: AH_REPORT_R1_003 +- 问题: 该用例在一条用例中同时验证安徽(34)、云南(28)、四川(51)三个省份的上报触发行为。若仅四川不触发有问题而安徽正常，该用例的单一"通过/失败"结果无法精确区分是哪个省份的问题。 +- 修复建议: 拆分为3条独立用例：R1_003a 安徽触发、R1_003b 云南不触发、R1_003c 四川不触发（或保留 R1_002 覆盖云南，将 R1_003 缩减为四川+其他一省）。确保每个省份的触发/不触发行为有独立可定位的用例。 + +### S-004: DASH_012 测试5种标签颜色，建议至少将申诉状态独立拆分 + +- 用例编号: AH_REPORT_DASH_012 +- 问题: 该用例验证4种上报状态标签颜色（蓝色/绿色/红色/橙色）外加申诉状态标签颜色，共计5个颜色断言。虽然都属于"标签颜色映射"这一验证点，但上报状态和申诉状态是两个不同的状态维度。任一颜色配置错误时，该用例失败但无法直接指示是哪个具体标签。 +- 修复建议: 将申诉状态标签颜色验证拆出为独立用例，或至少在上报状态验证和申诉状态验证之间设立分组。 + +### S-005: R2_004 合并了两个验证关注点（字段完整性 + 标签颜色） + +- 用例编号: AH_REPORT_R2_004 +- 问题: 标题和预期结果同时验证"17个字段完整性"和"收款账号类型标签颜色"，这两个关注点属于不同的验证维度（列表字段结构 vs 视觉样式映射），应拆分。 +- 修复建议: 拆分为 (a) 验证第二次上报列表字段完整且数据正确；(b) 验证收款账号类型标签颜色——个人账户蓝色、对公账户绿色。 + +### S-006: DASH_017 分页测试优先级 P3 偏低，建议升为 P2 + +- 用例编号: AH_REPORT_DASH_017 +- 问题: 分页翻页数据重复/遗漏是列表类功能的常见高频缺陷，直接影响数据完整性和用户信任度。当前置于 P3（最低优先级），与实际风险不匹配。 +- 修复建议: 升为 P2。分页缺陷虽不阻断主流程，但会导致数据不一致，用户可能基于不完整数据做出错误判断。 + +### S-007: R1_019 和 R1_020 预期结果缺少数据库层面的一致性校验 + +- 用例编号: AH_REPORT_R1_019, AH_REPORT_R1_020 +- 问题: R1_019 验证1条货物记录、R1_020 验证5条货物记录，预期结果仅覆盖了请求JSON数组和详情弹窗展示，未包含数据库货物表的落库数据与上报数据的一致性校验。与其他用例（如 R2_002 明确校验数据来源表）相比，数据验证深度不足。 +- 修复建议: 在预期结果中补充"数据库waybill_goods表中货物记录与上报数据一致"或类似断言。 + +--- + +## 优化项 + +### O-001: R1_016 弱网测试预期结果可更精确 + +- 用例编号: AH_REPORT_R1_016 +- 问题: 预期结果中"请求发送成功但响应延迟时不立即判定失败（超时阈值30s）"未明确在弱网（延迟2000ms、丢包30%）下的具体预期行为——例如是否预期在X次重试内成功，或最终应达到何种状态。建议：明确弱网条件下预期最终状态（如"在网络恢复后10s内完成上报，状态变为已上传"）。 +- 修复建议: 补充弱网恢复后的具体时效预期和最终状态断言。 + +### O-002: 部分测试数据列存在与步骤重复的信息 + +- 涉及用例: DASH_001~DASH_007, R1_001~R1_023 等多条 +- 问题: 测试数据列中的内容（如"运单号: YB202607130001"）已在测试步骤或前置条件中出现，数据列未提供独立增量信息。虽然模板允许这样做，但数据列的最佳实践是提供步骤中未提及但执行必需的输入值。 +- 修复建议: 检查并精简测试数据列，使其仅包含步骤中未体现的独立测试数据（如边界金额、特殊字符、长文本等）。 + +### O-003: 导出测试缺少导出取消/中断场景 + +- 涉及用例: AH_REPORT_DASH_008, AH_REPORT_DASH_009 +- 问题: 当前导出相关用例覆盖了正常导出和大数据量导出，但未覆盖"导出进行中取消操作""导出时网络中断""导出时关闭浏览器标签页"等中断场景。对于2000+条的大数据量导出场景，中途取消是常见用户行为。 +- 修复建议: 考虑新增一条 P3 用例覆盖导出中断场景，验证取消后系统资源释放、无残留临时文件。 + +### O-004: 搜索功能缺少特殊字符和注入防护测试 + +- 涉及模块: 模块A（看板搜索）、模块G（日志搜索） +- 问题: 当前搜索用例仅覆盖了正常搜索、模糊搜索、不存在搜索和空结果，未覆盖输入特殊字符（如 ``、SQL注入字符串 `' OR '1'='1`、超长字符串 1000+ 字符）的防御行为。 +- 修复建议: 考虑为看板搜索和日志搜索各新增1条 P2 安全性测试用例，验证特殊字符输入时不触发XSS、不导致SQL注入、不引起页面崩溃。 + +### O-005: 列表字段验证用例中缺少"列宽/截断/换行"展示验证 + +- 涉及用例: AH_REPORT_DASH_011, AH_REPORT_R2_004, AH_REPORT_R3_002, AH_REPORT_APL_003 +- 问题: 当前字段完整性验证聚焦于字段存在性和顺序，未验证字段内容过长时的截断/换行/省略号展示、列宽自适应等展示细节。对于司机姓名、托运方名称、货物名称等文本字段，超长内容展示异常是常见 UI 缺陷。 +- 修复建议: 考虑在现有字段验证用例的预期结果中补充："超长文本字段（如托运方名称50+字符）展示省略号或正确换行，表格不横向溢出"。 + +### O-006: 看板详情弹窗缺少"关闭弹窗后列表状态保持"验证 + +- 涉及用例: AH_REPORT_DASH_014, AH_REPORT_DASH_015 +- 问题: 当前详情弹窗用例验证了弹窗内容完整性，但未验证关闭弹窗后看板列表的筛选状态、分页位置是否保持。这是一个常见的易用性缺陷——关闭弹窗后列表重置为第1页，用户需重新翻页。 +- 修复建议: 在现有详情弹窗用例中补充一步"关闭弹窗→验证看板列表筛选条件和分页保持不变"。 + +### O-007: 前置条件中"系统中存在XX条运单"缺少数据准备指引 + +- 涉及用例: 约 90% 的用例 +- 问题: 大量用例的前置条件使用"系统中存在运单号XXX的运单记录"或"数据库中存在XX条运单"，未说明如何创建或准备这些数据。虽然这些是前置状态描述而非执行步骤，但对首次执行的测试人员而言，缺少数据准备脚本或数据构造指引会增加执行门槛。 +- 修复建议: 在文件头部或每个模块开头增加数据准备工作说明（如 SQL 脚本引用、造数工具说明），或在备注中标注"可参考测试数据文件构造"。 + +--- + +## 维度评分 + +| 维度 | 得分 | 说明 | +| :--- | :---: | :--- | +| 结构完整性 | 13/20 | 表头格式和列数一致，模块路径格式正确，必填列无空值。但存在5处字段数标题与预期结果不一致（B-001~B-005），影响执行可信度。 | +| 可执行性 | 24/25 | 测试步骤具体、有明确操作和数据，前置条件大多清晰。少量用例（R1_016）预期行为在异常条件下不够精确。 | +| 原子性 | 10/15 | 绝大多数用例为单一验证点。CROSS_003（全链路四阶段）明显违反原子性。DASH_012、R2_004、R1_003 存在合并多个关注点的情况。 | +| 预期结果质量 | 18/20 | 几乎全部用例同时覆盖 UI 反馈和数据状态变化，包含数据库层面的 WHERE 条件或记录数断言，质量优秀。APL_015 使用"可能"措辞是唯一明显缺陷。 | +| 类型准确性 | 9/10 | 类型枚举使用规范。APL_015 建议改为"易用性测试"。 | +| 优先级合理性 | 8/10 | 整体分布合理（P0 22% / P1 48% / P2 23% / P3 6%）。LOG_001/LOG_003 置于 P0 偏高；DASH_017 置于 P3 偏低。 | + +**总分: 82/100** + +--- + +## 亮点总结 + +1. **预期结果质量突出**：绝大多数用例的预期结果同时包含前端 UI 状态（标签颜色、文案提示）和后端数据状态（数据库记录数、WHERE条件、字段值），远超行业平均水平。 +2. **历史缺陷防御覆盖完整**：4个历史缺陷（BUG-202607-01~04）均有专门的防御用例并在备注中标注来源，形成可追溯的防御闭环。 +3. **覆盖维度全面**：128条用例覆盖了主流程、异常流程、边界条件、状态流转、幂等与并发、权限与越权、弱网/超时、字段完整性等多个维度，无重大遗漏。 +4. **测试点到用例映射完整**：103个测试点均映射到至少1条用例，无静默遗漏。 +5. **待确认项显式标注**：7项待确认均在文末显式标注，符合 DoD 要求。 + +--- + +## 修复优先级建议 + +1. **优先修复 B-001~B-005**（字段数不一致）：直接修改标题或预期结果中的数字，低改动成本、高信心增益。 +2. **次优先修复 B-006**（APL_015 措辞）和 **B-007**（CROSS_003 原子性）：B-006 改一句话即可，B-007 需要判断保留为冒烟测试还是拆分。 +3. **建议项和优化项**可在下轮迭代中集中处理，不阻塞当前评审通过。 diff --git a/output/analysis/安徽运八需求_质量裁决.md b/output/analysis/安徽运八需求_质量裁决.md index 0469b8e..cf7b889 100644 --- a/output/analysis/安徽运八需求_质量裁决.md +++ b/output/analysis/安徽运八需求_质量裁决.md @@ -1,12 +1,12 @@ # 安徽运八需求 质量裁决 -## 裁决结果: ✅ PASS +## 裁决结果: ❓ PENDING_AI -**裁决理由**: 用例数量: 8，覆盖率达标 +**裁决理由**: 等待 AI Agent 评审（review 战区: case-reviewer → coverage-auditor → quality-gatekeeper） -- 用例数量: 8 -- 裁决时间: 2026-07-13T01:33:01.582202+00:00 +- 用例数量: 18 +- 裁决时间: 2026-07-14T03:40:32.598146+00:00 ## 后续步骤 -- ✅ 可执行 `/qe-fleet export` 导出 Excel +- 🛑 请先解决阻断项，再重新运行 `/qe-fleet design` diff --git a/output/analysis/安徽运八需求_风险评估.md b/output/analysis/安徽运八需求_风险评估.md index 65c060c..3a067a0 100644 --- a/output/analysis/安徽运八需求_风险评估.md +++ b/output/analysis/安徽运八需求_风险评估.md @@ -1,10 +1,10 @@ # 安徽运八需求 风险评估报告 -> 生成时间: 2026-07-13T01:33:01.552872+00:00 +> 生成时间: 2026-07-14T03:40:32.577656+00:00 ## 风险概览 -- 总风险项: 2 +- 总风险项: 5 - P0 高风险: 0 - P1 中风险: 1 @@ -14,5 +14,8 @@ | :--- | :--- | :---: | :---: | :---: | :---: | :---: | | RISK-FINANCIAL | 资损 | 2 | 5 | 10 | **P1** | 否 | | RISK-AVAILABILITY | 可用性 | 2 | 4 | 8 | **P2** | 否 | +| RISK-DATA | 数据 | 2 | 4 | 8 | **P2** | 否 | +| RISK-COMPLIANCE | 合规 | 1 | 5 | 5 | **P2** | 否 | +| RISK-COMPATIBILITY | 兼容性 | 1 | 3 | 3 | **P2** | 否 | ## 风险缓解建议 diff --git a/output/execution/安徽运八需求/appium_tests.py b/output/execution/安徽运八需求/appium_tests.py index 115022a..607429a 100644 --- a/output/execution/安徽运八需求/appium_tests.py +++ b/output/execution/安徽运八需求/appium_tests.py @@ -1,7 +1,7 @@ """ Agentic QE Fleet — Appium 移动端自动化测试脚本 需求: 安徽运八需求 -生成时间: 2026-07-13T01:33:01.578523+00:00 +生成时间: 2026-07-14T03:40:32.593268+00:00 目标平台: android, ios 对应测试用例: E:\test\QaAutomationHub\output\test_cases\安徽运八需求_测试用例.md """ @@ -31,8 +31,8 @@ ANDROID_CAPS = { "platformName": "Android", "automationName": "UiAutomator2", "deviceName": "Android Emulator", - "appPackage": "com.arpa.ynchenggangdriver", # ⚠️ 修改为实际包名 - "appActivity": "com.arpa.ntocc.MainActivity", # ⚠️ 修改为实际 Activity + "appPackage": "com.example.app", # ⚠️ 修改为实际包名 + "appActivity": ".MainActivity", # ⚠️ 修改为实际 Activity "noReset": True, "newCommandTimeout": 120, } @@ -71,6 +71,27 @@ def run_android_test(): print("✅ Android 设备已连接") # ── 自动生成测试步骤 ── + # [P0] AH_REPORT_DASH_001: 验证看板按完整运单号精确搜索运单 + # driver.save_screenshot(screenshot_path('AH_REPORT_DASH_001', 'android')) + + # [P0] AH_REPORT_DASH_002: 验证看板按运单号模糊搜索匹配多条记录 + # driver.save_screenshot(screenshot_path('AH_REPORT_DASH_002', 'android')) + + # [P1] AH_REPORT_DASH_003: 验证看板按不存在的单号搜索显示空结果 + # driver.save_screenshot(screenshot_path('AH_REPORT_DASH_003', 'android')) + + # [P1] AH_REPORT_DASH_004: 验证看板按"第一次上报"阶段筛选运单 + # driver.save_screenshot(screenshot_path('AH_REPORT_DASH_004', 'android')) + + # [P1] AH_REPORT_DASH_005: 验证看板按"异常"核验状态筛选运单 + # driver.save_screenshot(screenshot_path('AH_REPORT_DASH_005', 'android')) + + # [P1] AH_REPORT_DASH_006: 验证看板按"申诉中"申诉状态筛选运单 + # driver.save_screenshot(screenshot_path('AH_REPORT_DASH_006', 'android')) + + # [P1] AH_REPORT_DASH_007: 验证看板组合筛选—第二次上报+异常+申诉中+运单号模糊搜索 + # driver.save_screenshot(screenshot_path('AH_REPORT_DASH_007', 'android')) + results["passed"] += 1 except Exception as exc: diff --git a/output/execution/安徽运八需求/playwright_tests.py b/output/execution/安徽运八需求/playwright_tests.py index 1014f7f..3441db9 100644 --- a/output/execution/安徽运八需求/playwright_tests.py +++ b/output/execution/安徽运八需求/playwright_tests.py @@ -1,10 +1,10 @@ """ Agentic QE Fleet — Playwright 自动化测试脚本 需求: 安徽运八需求 -生成时间: 2026-07-13T01:33:01.577514+00:00 +生成时间: 2026-07-14T03:40:32.591309+00:00 目标浏览器: chromium, firefox, webkit 对应测试用例: E:\test\QaAutomationHub\output\test_cases\安徽运八需求_测试用例.md -用例数量: 8 +用例数量: 18 """ import asyncio @@ -43,7 +43,7 @@ async def run_test(browser_type: str, browser_name: str): # ============================================================ # 以下为测试用例骨架，请根据实际测试环境配置 BASE_URL 和测试数据 # ============================================================ - BASE_URL = "https://ybxcx.ynyun8.com:8000/admin" # ⚠️ 请修改为实际测试环境地址 + BASE_URL = "http://localhost:3000" # ⚠️ 请修改为实际测试环境地址 try: # ── 测试准备: 登录 ── @@ -51,6 +51,34 @@ async def run_test(browser_type: str, browser_name: str): # await page.screenshot(path=screenshot_path('01_login', browser_name)) # ── 从测试用例自动生成的测试步骤 ── + # [P0] AH_REPORT_DASH_001: 验证看板按完整运单号精确搜索运单 + # → 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入完整运单号"YB202607130001"；3. 点击搜索按钮或按回车键 + # await page.screenshot(path=screenshot_path('AH_REPORT_DASH_001', browser_name)) + + # [P0] AH_REPORT_DASH_002: 验证看板按运单号模糊搜索匹配多条记录 + # → 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入"YB20260713"；3. 点击搜索 + # await page.screenshot(path=screenshot_path('AH_REPORT_DASH_002', browser_name)) + + # [P1] AH_REPORT_DASH_003: 验证看板按不存在的单号搜索显示空结果 + # → 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入不存在的单号"NOTEXIST999"；3. 点击搜索 + # await page.screenshot(path=screenshot_path('AH_REPORT_DASH_003', browser_name)) + + # [P1] AH_REPORT_DASH_004: 验证看板按"第一次上报"阶段筛选运单 + # → 进入"监管上报-上报看板"页面，默认为"全部"；2. 点击上报阶段下拉框，选择"第一次上报"；3. 观察列表数据 + # await page.screenshot(path=screenshot_path('AH_REPORT_DASH_004', browser_name)) + + # [P1] AH_REPORT_DASH_005: 验证看板按"异常"核验状态筛选运单 + # → 进入"监管上报-上报看板"页面；2. 点击核验状态下拉框，选择"异常"；3. 观察列表数据 + # await page.screenshot(path=screenshot_path('AH_REPORT_DASH_005', browser_name)) + + # [P1] AH_REPORT_DASH_006: 验证看板按"申诉中"申诉状态筛选运单 + # → 进入"监管上报-上报看板"页面；2. 点击申诉状态下拉框，选择"申诉中"；3. 观察列表数据并与全部列表对比 + # await page.screenshot(path=screenshot_path('AH_REPORT_DASH_006', browser_name)) + + # [P1] AH_REPORT_DASH_007: 验证看板组合筛选—第二次上报+异常+申诉中+运单号模糊搜索 + # → 进入"监管上报-上报看板"页面；2. 上报阶段选"第二次上报"；3. 核验状态选"异常"；4. 申诉状态选"申诉中"；5. 运单号输入"YB2026"；6. 点击搜索 + # await page.screenshot(path=screenshot_path('AH_REPORT_DASH_007', browser_name)) + results["passed"] += 1 except Exception as exc: diff --git a/output/execution/安徽运八需求_执行报告.md b/output/execution/安徽运八需求_执行报告.md index 749a735..93136d4 100644 --- a/output/execution/安徽运八需求_执行报告.md +++ b/output/execution/安徽运八需求_执行报告.md @@ -1,6 +1,6 @@ # 安徽运八需求 自动化测试执行报告 -> 生成时间: 2026-07-13T01:33:01.579566+00:00 +> 生成时间: 2026-07-14T03:40:32.595234+00:00 > 生成引擎: Agentic QE Fleet v2.1.0 — Execute 战区 --- @@ -9,9 +9,9 @@ | 指标 | 值 | | :--- | :--- | -| 测试用例总数 | 8 | -| P0 用例 | 0 | -| P1 用例 | 0 | +| 测试用例总数 | 18 | +| P0 用例 | 2 | +| P1 用例 | 8 | | 执行平台 | PC Web (Playwright) + 移动端 (Appium) | | 目标浏览器 | Chromium / Firefox / WebKit | | 目标移动端 | Android / iOS | diff --git a/output/manifests/安徽运八需求.json b/output/manifests/安徽运八需求.json index 4e663d6..b2d4aff 100644 --- a/output/manifests/安徽运八需求.json +++ b/output/manifests/安徽运八需求.json @@ -1,46 +1,171 @@ { - "base_name": "安徽运八需求", - "review_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_评审报告.md", - "coverage_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_覆盖率审计.md", - "verdict_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_质量裁决.md", - "quality_verdict": { - "verdict": "PASS", - "reason": "用例数量: 8，覆盖率达标", - "case_count": 8, - "min_coverage_required": 0.95, - "max_blockers_allowed": 0 - }, - "agent_notes": { - "case-reviewer": "评审完成，8 条用例", - "coverage-auditor": "覆盖率审计待 AI Agent 执行", - "quality-gatekeeper": "裁决: PASS" - }, "_meta": { - "combined": true, - "updated_at": "2026-07-13T01:33:01.582202+00:00" - }, - "confirmation_gate": { - "required": true, - "reasons": [ - "识别到 1 个历史相似需求，需确认与旧需求的关系类型、生效范围和是否需要回写历史需求。" + "base_name": "安徽运八需求", + "merged_zones": [ + "prepare", + "analyze", + "design", + "execute", + "review", + "monitor" ], - "pending_markers_count": 0, - "decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md", - "decision_status": "confirmed", - "decision_status_label": "已确认", - "allow_export_before_confirmation": true, - "candidate_decision_files": [ - "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" - ], - "suggested_decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" + "merged_at": "2026-07-13T07:31:34.880608+00:00", + "updated_at": "2026-07-13T07:31:34.881584+00:00" }, - "related_requirements": [ - { - "path": "E:\\test\\QaAutomationHub\\source_docs\\requirements_raw\\网货企业端接口文档（最新）.pdf", - "similarity": 0.069578 + "prepare": { + "base_name": "安徽运八需求", + "requirement_source_file": "E:\\test\\QaAutomationHub\\source_docs\\requirements_raw\\安徽运八需求.docx", + "requirement_input_type": "docx", + "normalized_requirement_file": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求\\requirement.md", + "normalized_dir": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求", + "technical_solution_files": [], + "normalized_technical_solution_files": [], + "project_profile_file": "E:\\test\\QaAutomationHub\\knowledge_base\\00_project\\project_profile.md", + "document_confidence": { + "requirement": 0.9, + "issues": [] + }, + "activated_knowledge": { + "terminology": { + "permanent": [ + "E:\\test\\QaAutomationHub\\knowledge_base\\01_standards\\terminology.md" + ], + "optional": [] + }, + "semantic_matches": [ + { + "path": "E:\\test\\QaAutomationHub\\knowledge_base\\03_best_practices\\data_reporting_cases.md", + "score": 0.1155, + "category": "best_practice" + }, + { + "path": "E:\\test\\QaAutomationHub\\knowledge_base\\02_history\\common_missed_scenes.md", + "score": 0.0916, + "category": "history" + } + ] + }, + "knowledge_gaps": [], + "agent_notes": { + "document-parser": "解析完成，置信度 90%", + "knowledge-activator": "激活 1 常驻 + 0 可选术语" + }, + "_meta": { + "zone": "prepare", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.805524+00:00", + "status": "completed" } - ], + }, + "base_name": "安徽运八需求", + "requirement_source_file": "E:\\test\\QaAutomationHub\\source_docs\\requirements_raw\\安徽运八需求.docx", + "requirement_input_type": "docx", + "normalized_requirement_file": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求\\requirement.md", + "normalized_dir": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求", + "technical_solution_files": [], + "normalized_technical_solution_files": [], + "project_profile_file": "E:\\test\\QaAutomationHub\\knowledge_base\\00_project\\project_profile.md", + "document_confidence": { + "requirement": 0.95, + "issues": [] + }, + "activated_knowledge": { + "terminology": { + "permanent": [ + "E:\\test\\QaAutomationHub\\knowledge_base\\01_standards\\terminology.md" + ], + "optional": [] + }, + "semantic_matches": [ + { + "path": "E:\\test\\QaAutomationHub\\knowledge_base\\03_best_practices\\data_reporting_cases.md", + "score": 0.1155, + "category": "best_practice" + }, + { + "path": "E:\\test\\QaAutomationHub\\knowledge_base\\02_history\\common_missed_scenes.md", + "score": 0.0916, + "category": "history" + } + ] + }, + "knowledge_gaps": [], + "agent_notes": { + "execution-analyst": "等待测试结果输入", + "knowledge-curator": "等待执行分析结果" + }, + "analyze": { + "base_name": "安徽运八需求", + "analysis_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_分析.md", + "relation_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_关联与冲突.md", + "risk_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_风险评估.md", + "related_requirements": [], + "conflict_candidates_count": 0, + "conflict_summary": {}, + "risk_matrix": { + "risks": [ + { + "id": "RISK-FINANCIAL", + "category": "资损", + "keywords_matched": [ + "金额", + "支付" + ], + "likelihood": 2, + "impact": 5, + "score": 10, + "level": "P1", + "conflict_amplified": false + }, + { + "id": "RISK-AVAILABILITY", + "category": "可用性", + "keywords_matched": [ + "超时", + "重试" + ], + "likelihood": 2, + "impact": 4, + "score": 8, + "level": "P2", + "conflict_amplified": false + } + ], + "total": 2, + "p0_count": 0, + "p1_count": 1 + }, + "confirmation_gate": { + "required": false, + "reasons": [], + "pending_markers_count": 0, + "decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md", + "decision_status": "not_required", + "decision_status_label": "已确认", + "allow_export_before_confirmation": true, + "candidate_decision_files": [ + "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" + ], + "suggested_decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" + }, + "agent_notes": { + "requirement-analyzer": "识别 0 个关联需求", + "conflict-detector": "检测到 0 个冲突候选", + "risk-assessor": "识别 2 个风险项" + }, + "_meta": { + "zone": "analyze", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.855607+00:00", + "status": "completed" + } + }, + "analysis_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_分析.md", + "relation_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_关联与冲突.md", + "risk_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_风险评估.md", + "related_requirements": [], "conflict_candidates_count": 0, + "conflict_summary": {}, "risk_matrix": { "risks": [ { @@ -74,16 +199,150 @@ "p0_count": 0, "p1_count": 1 }, - "requirement_source_file": "source_docs\\requirements_raw\\安徽运八需求.docx", - "normalized_requirement_file": "output\\normalized_inputs\\安徽运八需求\\requirement.md", + "confirmation_gate": { + "required": false, + "reasons": [], + "pending_markers_count": 0, + "decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md", + "decision_status": "not_required", + "decision_status_label": "已确认", + "allow_export_before_confirmation": true, + "candidate_decision_files": [ + "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" + ], + "suggested_decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" + }, + "design": { + "base_name": "安徽运八需求", + "strategy_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试策略.md", + "test_points_file": "E:\\test\\QaAutomationHub\\output\\test_points\\安徽运八需求_测试点.md", + "test_cases_file": "E:\\test\\QaAutomationHub\\output\\test_cases\\安徽运八需求_测试用例.md", + "test_data_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试数据.md", + "p0_required_coverage": "N/A", + "agent_notes": { + "test-strategist": "策略已生成，0 个 P0 风险需 100% 覆盖", + "testpoint-designer": "待 AI Agent 生成测试点", + "case-designer": "待 AI Agent 生成用例", + "data-builder": "测试数据模板已生成" + }, + "_meta": { + "zone": "design", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.874648+00:00", + "status": "completed" + } + }, + "strategy_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试策略.md", + "test_points_file": "E:\\test\\QaAutomationHub\\output\\test_points\\安徽运八需求_测试点.md", + "test_cases_file": "E:\\test\\QaAutomationHub\\output\\test_cases\\安徽运八需求_测试用例.md", + "test_data_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试数据.md", + "p0_required_coverage": "N/A", + "execute": { + "base_name": "安徽运八需求", + "playwright_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\playwright_tests.py", + "appium_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\appium_tests.py", + "execution_report_file": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求_执行报告.md", + "screenshots_dir": "E:\\test\\QaAutomationHub\\output\\screenshots\\安徽运八需求", + "execution_config": { + "browsers": [ + "chromium", + "firefox", + "webkit" + ], + "mobile_platforms": [ + "android", + "ios" + ], + "screenshot_on_failure": true, + "screenshot_on_step": false + }, + "agent_notes": { + "web-executor": "Playwright 脚本已生成 → E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\playwright_tests.py", + "mobile-executor": "Appium 脚本已生成 → E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\appium_tests.py", + "result-reporter": "执行报告 → E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求_执行报告.md" + }, + "_meta": { + "zone": "execute", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.877678+00:00", + "status": "completed" + } + }, + "playwright_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\playwright_tests.py", + "appium_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\appium_tests.py", + "execution_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_执行分析.md", + "screenshots_dir": "E:\\test\\QaAutomationHub\\output\\screenshots\\安徽运八需求", + "execution_config": { + "browsers": [ + "chromium", + "firefox", + "webkit" + ], + "mobile_platforms": [ + "android", + "ios" + ], + "screenshot_on_failure": true, + "screenshot_on_step": false + }, + "review": { + "base_name": "安徽运八需求", + "review_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_评审报告.md", + "coverage_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_覆盖率审计.md", + "verdict_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_质量裁决.md", + "quality_verdict": { + "verdict": "BLOCKED", + "reason": "测试用例文件尚未生成或为空", + "case_count": 0, + "min_coverage_required": 0.95, + "max_blockers_allowed": 0 + }, + "agent_notes": { + "case-reviewer": "等待用例生成", + "coverage-auditor": "覆盖率审计待 AI Agent 执行", + "quality-gatekeeper": "裁决: BLOCKED" + }, + "_meta": { + "zone": "review", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.879631+00:00", + "status": "completed" + } + }, + "review_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_评审报告.md", + "coverage_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_覆盖率审计.md", + "verdict_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_质量裁决.md", + "quality_verdict": { + "verdict": "BLOCKED", + "reason": "测试用例文件尚未生成或为空", + "case_count": 0, + "min_coverage_required": 0.95, + "max_blockers_allowed": 0 + }, + "monitor": { + "base_name": "安徽运八需求", + "execution_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_执行分析.md", + "agent_notes": { + "execution-analyst": "等待测试结果输入", + "knowledge-curator": "等待执行分析结果" + }, + "curation_suggestions": [], + "_meta": { + "zone": "monitor", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.880608+00:00", + "status": "completed" + } + }, + "curation_suggestions": [], "current_excel_file": "E:\\test\\QaAutomationHub\\output\\excel_reports\\安徽运八需求_测试用例.xlsx", "versioning_scheme": { "current_files": "固定文件名，始终表示当前最新版", "snapshot_rule": "仅在 export 成功且产物内容发生变化时递增版本", "snapshot_dir_pattern": "output/versions/{BASE_NAME}/vN/" }, - "latest_snapshot_version": "v2", - "latest_snapshot_dir": "E:\\test\\QaAutomationHub\\output\\versions\\安徽运八需求\\v2", + "latest_snapshot_version": "v5", + "latest_snapshot_dir": "E:\\test\\QaAutomationHub\\output\\versions\\安徽运八需求\\v5", "latest_snapshot_type": "full_pipeline", "maintained_requirement_file": "E:\\test\\QaAutomationHub\\requirements\\安徽运八需求.md" -} +} \ No newline at end of file diff --git a/output/manifests/安徽运八需求_analyze.json b/output/manifests/安徽运八需求_analyze.json index f5579a7..d83fca5 100644 --- a/output/manifests/安徽运八需求_analyze.json +++ b/output/manifests/安徽运八需求_analyze.json @@ -3,12 +3,7 @@ "analysis_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_分析.md", "relation_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_关联与冲突.md", "risk_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_风险评估.md", - "related_requirements": [ - { - "path": "E:\\test\\QaAutomationHub\\source_docs\\requirements_raw\\网货企业端接口文档（最新）.pdf", - "similarity": 0.069578 - } - ], + "related_requirements": [], "conflict_candidates_count": 0, "conflict_summary": {}, "risk_matrix": { @@ -38,20 +33,55 @@ "score": 8, "level": "P2", "conflict_amplified": false + }, + { + "id": "RISK-DATA", + "category": "数据", + "keywords_matched": [ + "精度", + "删除" + ], + "likelihood": 2, + "impact": 4, + "score": 8, + "level": "P2", + "conflict_amplified": false + }, + { + "id": "RISK-COMPLIANCE", + "category": "合规", + "keywords_matched": [ + "加密" + ], + "likelihood": 1, + "impact": 5, + "score": 5, + "level": "P2", + "conflict_amplified": false + }, + { + "id": "RISK-COMPATIBILITY", + "category": "兼容性", + "keywords_matched": [ + "App" + ], + "likelihood": 1, + "impact": 3, + "score": 3, + "level": "P2", + "conflict_amplified": false } ], - "total": 2, + "total": 5, "p0_count": 0, "p1_count": 1 }, "confirmation_gate": { - "required": true, - "reasons": [ - "识别到 1 个历史相似需求，需确认与旧需求的关系类型、生效范围和是否需要回写历史需求。" - ], + "required": false, + "reasons": [], "pending_markers_count": 0, "decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md", - "decision_status": "confirmed", + "decision_status": "not_required", "decision_status_label": "已确认", "allow_export_before_confirmation": true, "candidate_decision_files": [ @@ -60,14 +90,14 @@ "suggested_decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" }, "agent_notes": { - "requirement-analyzer": "识别 1 个关联需求", + "requirement-analyzer": "识别 0 个关联需求", "conflict-detector": "检测到 0 个冲突候选", - "risk-assessor": "识别 2 个风险项" + "risk-assessor": "识别 5 个风险项" }, "_meta": { "zone": "analyze", "base_name": "安徽运八需求", - "updated_at": "2026-07-13T01:33:01.554826+00:00", + "updated_at": "2026-07-14T03:40:32.586436+00:00", "status": "completed" } } diff --git a/output/manifests/安徽运八需求_design.json b/output/manifests/安徽运八需求_design.json index 9eedbac..7cb95f0 100644 --- a/output/manifests/安徽运八需求_design.json +++ b/output/manifests/安徽运八需求_design.json @@ -6,15 +6,33 @@ "test_data_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试数据.md", "p0_required_coverage": "N/A", "agent_notes": { - "test-strategist": "策略已生成，0 个 P0 风险需 100% 覆盖", - "testpoint-designer": "待 AI Agent 生成测试点", - "case-designer": "待 AI Agent 生成用例", - "data-builder": "测试数据模板已生成" + "test-strategist": { + "status": "completed", + "message": "策略已生成，0 个 P0 风险需 100% 覆盖" + }, + "testpoint-designer": { + "status": "pending_ai", + "message": "待 AI Agent 生成测试点", + "prompt_file": "agents/design/testpoint_designer.md", + "output_file": "E:\\test\\QaAutomationHub\\output\\test_points\\安徽运八需求_测试点.md" + }, + "case-designer": { + "status": "pending_ai", + "message": "待 AI Agent 生成用例", + "prompt_file": "agents/design/case_designer.md", + "output_file": "E:\\test\\QaAutomationHub\\output\\test_cases\\安徽运八需求_测试用例.md" + }, + "data-builder": { + "status": "pending_ai", + "message": "待 AI Agent 完善测试数据", + "prompt_file": "agents/design/data_builder.md", + "output_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试数据.md" + } }, "_meta": { "zone": "design", "base_name": "安徽运八需求", - "updated_at": "2026-07-13T01:33:01.575559+00:00", + "updated_at": "2026-07-14T03:40:32.589407+00:00", "status": "completed" } } diff --git a/output/manifests/安徽运八需求_execute.json b/output/manifests/安徽运八需求_execute.json index b905cc2..99c8bd7 100644 --- a/output/manifests/安徽运八需求_execute.json +++ b/output/manifests/安徽运八需求_execute.json @@ -25,7 +25,7 @@ "_meta": { "zone": "execute", "base_name": "安徽运八需求", - "updated_at": "2026-07-13T01:33:01.579566+00:00", + "updated_at": "2026-07-14T03:40:32.596211+00:00", "status": "completed" } } diff --git a/output/manifests/安徽运八需求_monitor.json b/output/manifests/安徽运八需求_monitor.json index 791ed89..cbeeffd 100644 --- a/output/manifests/安徽运八需求_monitor.json +++ b/output/manifests/安徽运八需求_monitor.json @@ -9,9 +9,7 @@ "_meta": { "zone": "monitor", "base_name": "安徽运八需求", - "updated_at": "2026-07-13T01:56:23.940364+00:00", + "updated_at": "2026-07-14T03:40:32.600097+00:00", "status": "completed" - }, - "export_completed": true, - "export_timestamp": "2026-07-13T01:56:23.940364+00:00" + } } diff --git a/output/manifests/安徽运八需求_prepare.json b/output/manifests/安徽运八需求_prepare.json index 3a2ca31..258fe1c 100644 --- a/output/manifests/安徽运八需求_prepare.json +++ b/output/manifests/安徽运八需求_prepare.json @@ -1,14 +1,14 @@ { "base_name": "安徽运八需求", - "requirement_source_file": "E:\\test\\QaAutomationHub\\source_docs\\requirements_raw\\安徽运八需求.docx", - "requirement_input_type": "docx", + "requirement_source_file": "E:\\test\\QaAutomationHub\\source_docs\\requirements_raw\\安徽运八需求.md", + "requirement_input_type": "md", "normalized_requirement_file": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求\\requirement.md", "normalized_dir": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求", "technical_solution_files": [], "normalized_technical_solution_files": [], "project_profile_file": "E:\\test\\QaAutomationHub\\knowledge_base\\00_project\\project_profile.md", "document_confidence": { - "requirement": 0.9, + "requirement": 1.0, "issues": [] }, "activated_knowledge": { @@ -18,26 +18,54 @@ ], "optional": [] }, - "semantic_matches": [] + "semantic_matches": [ + { + "path": "E:\\test\\QaAutomationHub\\knowledge_base\\03_best_practices\\data_reporting_cases.md", + "score": 0.1001, + "category": "best_practice" + } + ] }, "knowledge_gaps": [ { "category": "history", "suggestion": "未激活任何历史缺陷/易漏场景，建议补充相关知识库条目" + } + ], + "attached_source_files": [ + { + "path": "E:\\Downloads\\网货企业端接口文档（最新）.pdf", + "type": "local_file", + "source": "embedded_path", + "exists": "true", + "context_line": "> **API文档（查询+申诉）**: `E:\\Downloads\\网货企业端接口文档（最新）.pdf` V1.0.2 (2023-04)" + } + ], + "sources_registry": [ + { + "path": "E:\\test\\QaAutomationHub\\source_docs\\requirements_raw\\安徽运八需求.md", + "type": "primary_requirement", + "role": "business_background", + "format": "md", + "authority": "primary" }, { - "category": "best_practice", - "suggestion": "未激活任何最佳实践范例，建议补充同类型需求的优秀用例" + "path": "E:\\Downloads\\网货企业端接口文档（最新）.pdf", + "type": "attached_local_file", + "role": "api_spec", + "format": "pdf", + "authority": "reference", + "exists": "true" } ], "agent_notes": { - "document-parser": "解析完成，置信度 90%", + "document-parser": "解析完成，置信度 100%", "knowledge-activator": "激活 1 常驻 + 0 可选术语" }, "_meta": { "zone": "prepare", "base_name": "安徽运八需求", - "updated_at": "2026-07-13T01:33:01.474632+00:00", + "updated_at": "2026-07-14T03:40:32.569828+00:00", "status": "completed" } } diff --git a/output/manifests/安徽运八需求_review.json b/output/manifests/安徽运八需求_review.json index 70d4eca..a6fd847 100644 --- a/output/manifests/安徽运八需求_review.json +++ b/output/manifests/安徽运八需求_review.json @@ -4,21 +4,36 @@ "coverage_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_覆盖率审计.md", "verdict_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_质量裁决.md", "quality_verdict": { - "verdict": "PASS", - "reason": "用例数量: 8，覆盖率达标", - "case_count": 8, + "verdict": "PENDING_AI", + "reason": "等待 AI Agent 评审（review 战区: case-reviewer → coverage-auditor → quality-gatekeeper）", + "case_count": 18, "min_coverage_required": 0.95, "max_blockers_allowed": 0 }, "agent_notes": { - "case-reviewer": "评审完成，8 条用例", - "coverage-auditor": "覆盖率审计待 AI Agent 执行", - "quality-gatekeeper": "裁决: PASS" + "case-reviewer": { + "status": "pending_ai", + "message": "待 AI Agent 评审用例", + "prompt_file": "agents/review/case_reviewer.md", + "output_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_评审报告.md" + }, + "coverage-auditor": { + "status": "pending_ai", + "message": "待 AI Agent 审计覆盖率", + "prompt_file": "agents/review/coverage_auditor.md", + "output_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_覆盖率审计.md" + }, + "quality-gatekeeper": { + "status": "pending_ai", + "message": "待 AI Agent 质量裁决", + "prompt_file": "agents/review/quality_gatekeeper.md", + "output_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_质量裁决.md" + } }, "_meta": { "zone": "review", "base_name": "安徽运八需求", - "updated_at": "2026-07-13T01:33:01.582202+00:00", + "updated_at": "2026-07-14T03:40:32.599120+00:00", "status": "completed" } } diff --git a/output/normalized_inputs/安徽运八需求/requirement.md b/output/normalized_inputs/安徽运八需求/requirement.md index 80c5f56..299d2e5 100644 --- a/output/normalized_inputs/安徽运八需求/requirement.md +++ b/output/normalized_inputs/安徽运八需求/requirement.md @@ -1,163 +1,589 @@ # 安徽运八需求 > 文档角色：需求文档 -> 原始来源：`source_docs\requirements_raw\安徽运八需求.docx` +> 原始来源：`source_docs\requirements_raw\安徽运八需求.md` -安徽运八需求 -一、需求概述 -根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八）。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。本功能模块旨在实现上报流程的自动化管理，并提供异常监控与向平台发起申诉的能力。 -二、功能说明 -2.1 上报运单看板 -· 功能描述 -上报运单看板是系统的首页，集中展示所有上报阶段运单的汇总状态，支持按条件筛选、查看详情和发起申诉。 -· 查询条件 -运单号/托运单号/货源单号：模糊搜索 -上报阶段：全部 / 第一次上报 / 第二次上报 / 第三次上报 -核验状态：全部 / 异常 / 通过 -申诉状态：全部 / 未申诉 / 申诉中 / 申诉通过 / 申诉驳回 -操作按钮：查询、重置、导出 -· 列表字段 -货源单号、运单号、托运单号、车牌号、司机姓名、 -托运方名称、上报阶段、核验状态、申诉状态、异常项、 -货物名称、合同金额、最新核验时间、操作（申诉/进度/详情） -2.2 第一次上报（装货完成） -功能描述 -第一次上报在运单装货完成后自动触发，上报数据包含运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息、保险信息等。 -特殊说明 -• 上报完成后，若安徽运八平台核验通过，系统会自动调用“修改第一次上报部分字段”接口，更新装货后可能发生变化的字段（如实际里程），无需人工干预。 -• 若上报失败，系统需要自动重试（最多3次），若仍失败则通过系统站内信或者其他方式通知运营人员。 -• 第一次上传是后续两次上传的基础，若失败会导致后续上报无法进行，需重点关注。 -上报状态规则 -| 状态 | 说明 | 操作按钮 | 标签颜色 | -| 上传中 | 数据正在上报中 | 无 | 蓝色 | -| 已上传 | 上报成功 | 无 | 绿色 | -| 上传失败 | 上报超时 | 手动上传 | 红色 | -| 异常 | 数据校验不通过 | 详情查看异常原因 | 橙色 | -列表字段 -货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、业务类型、货物名称、装货地址、卸货地址、运输里程、合同编号、上报状态、操作（详情） -详情弹窗字段分组 -详情弹窗按以下子对象分组展示： -建单信息（必选，13字段）：上游企业委托运输单号、本运单单号、托运人建单时间、网络货运经营者名称、统一社会信用代码、道路运输经营许可证编号、业务类型代码、运输组货方式代码、司机接单时间、司机起运时间、承运合同编号、委托合同编号（可选）、运输里程（可选） -托运人信息（必选，7字段）：托运人名称、托运人统一社会信用代码、框架合同编号（可选）、装货地点、装货经度、装货纬度、装货地行政区划代码 -收货方信息（必选，5字段）：收货方名称、收货方统一社会信用代码/身份证号、收货地点、收货经度、收货纬度 -司机信息（必选，13字段）：司机姓名、身份证号、驾驶证号、驾驶证发证机关、从业资格证号、从业资格证有效期起、从业资格证有效期至、税务登记证号、手机号、驾驶证有效期起、驾驶证有效期至、准驾车型、省份代码 -接单车辆信息（必选，19字段）：车牌号、车牌颜色编码、号牌种类、车辆识别代号VIN)、车主姓名/单位名称、车主证件号、使用性质、车辆类型、能源类型、注册日期、发证日期、发证机关、核定载质量吨)、总质量吨)、道路运输证号、挂车牌照号（可选）、行驶证档案编号（可选）、道路运输证有效期起（可选）、道路运输证有效期至（可选） -货物信息（必选，可多条，4字段）：货物名称、货物类型代码、货物量、计量单位 -保险信息（可选，2字段）：保险单号、保险公司名称 -异常信息：核验状态、异常原因、异常时间、处理状态 -2.3 第二次上报（打款完成） -功能描述 -第二次上报在运费支付完成后系统自动触发，上报数据包含运抵信息、货主资金流水、承运人资金流水、承运合同信息、委托合同信息、车辆轨迹信息等。 -特殊说明 -• 第二次上传核验项最多，是最容易出现异常的环节，需要重点关注。 -• 若资金流水单号重复，会导致上报失败，系统会自动检查并提示。 -• 车辆轨迹点位数量不足或偏差过大，会导致"车辆轨迹合规"核验异常，可通过"补传轨迹"功能补充轨迹数据。 -• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。 -列表字段 -货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、承运运费、总金额、付款方式、付款时间、收款人、收款账号、收款账号类型、核验状态、异常项、上报状态、操作（上报/详情） -收款账号类型说明 -• 个人账户：司机个人银行卡账号，标签为蓝色 -• 对公账户：企业银行账号，标签为绿色 -详情弹窗字段分组 -（1）运单信息（必选）：同第一次上报 -（2）托运方信息（必选）：同第一次上报 -（3）收货方信息（必选）：同第一次上报 -（4）资金流水信息（必选）：支付金额、支付方式、支付时间、付款方名称、收款方名称、收款人、收款账号、收款账号类型、流水号、支付状态 -（5）车辆轨迹信息（必选，可多条，2~2000个点）：定位类型、定位时间、定位地点、经度、纬度、轨迹类型 -（6）异常信息：核验状态、异常原因、异常时间、处理状态 -核验内容（监管平台自动核验，异常时可发起申诉） -| 核验项 | 说明 | -| 运单重复核验 | 检查同一运单是否重复上报 | -| 车辆资质核验 | 检查车辆道路运输证是否在有效期内 | -| 司机资质核验 | 检查司机从业资格证是否在有效期内 | -| 集中支付核验 | 检查资金流水是否通过网货平台集中支付 | -| 资金流水核验 | 检查资金流水单号是否重复、金额是否匹配 | -| 合同核验 | 检查运输合同和委托合同是否有效 | -| 车辆轨迹合规核验 | 检查车辆轨迹是否真实、与运单路线是否匹配 | -2.4 第三次上报（开票完成） -功能描述 -第三次上报在发票开具完成后触发，上报数据包含运单信息（托运单号数组）、发票信息、油气发票信息等。 -特殊说明 -• 第三次上传需要在运单完成第二次上传后方可进行。 -• 若增值税发票验证失败，会导致上报失败，需检查发票信息是否正确。 -• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。 -列表字段 -货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、发票号码、发票金额、开票日期、核验状态、异常原因、上报状态、操作（详情） -详情弹窗字段分组 -（1）运单信息（必选）：同第一次上报 -（2）发票信息（必选，17字段）：托运单号数组、发票号码、发票代码号、发票金额价税合计)、开票日期、销售方名称、销售方纳税人识别号、销售方地址、销售方电话、销售方开户行、销售方银行账户、受票方名称、受票方纳税人识别号、受票方地址、受票方电话、受票方开户行、受票方银行卡号 -（3）油气发票信息（可选，可多条）：油气托运单号、油气发票文件 -（4）异常信息：核验状态、异常原因、异常时间、处理状态 -2.5 ETC发票上传 -功能描述 -ETC发票上传用于上报车辆通行高速公路的ETC发票信息，作为税务抵扣凭证。 -特殊说明 -• ETC发票上传需要在税务抵扣完成后进行，否则会导致上报失败。 -• 若ETC发票验证失败，会导致上报失败，需检查发票信息是否正确。 -• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。 -列表字段 -货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、ETC发票号码、发票金额、税率、上传状态、操作（详情） -详情弹窗字段分组 -（1）运单信息：运单号、货源单号、托运单号、车牌号、司机姓名、托运方名称、收货方名称 -（2）ETC发票信息（每张发票18字段）：ETC发票号码、ETC发票代码、开票时间、发票金额、税率、税额、价税合计、销售方名称、销售方税号、受票方名称、受票方税号、入口收费站、出口收费站、交易时间、交易金额、交易匹配时间、交易流水号、ETC发票文件 -（3）异常信息：核验状态、异常原因、异常时间、处理状态 -2.6 异常申诉功能 -运单完成第二次上传后，安徽省管理平台自动进行 7 大类核验（车辆资质、司机资质、资金流水、合同、轨迹等）。如核验结果为异常时，运营人员可通过申诉机制向平台说明情况并申请重新核验。 -本模块补全“异常查询 → 发起申诉 → 跟踪监管平台反馈 → 合规判断”的完整闭环。 -当上报数据被核验为异常时，运营人员可发起申诉，向安徽监管平台说明情况并申请重新核验。申诉记录管理页面展示所有申诉记录及省平台反馈结果。 -列表字段 -运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、异常项、申诉状态、申诉时间、申诉人、省平台反馈结果、监管平台反馈时间、操作（详情/重新申诉） -详情弹窗字段分组 -（1）申诉信息：申诉单号、上报阶段、异常项、申诉原因、申诉状态、申诉时间、申诉人、申诉附件 -（2）运单信息：运单号、托运单号、车牌号、司机姓名、托运方名称 -（3）异常信息：核验状态、异常原因、异常时间 -（4）省平台反馈信息：反馈结果、反馈时间、反馈意见 -（5）处理记录：操作人、操作时间、操作类型、操作内容（时间线展示） -申诉复核说明 -（注：申诉由安徽监管平台复核，非我方审核） -（复核不通过时，可补充材料后重新发起申诉） -异常代码一览表 -2.7 上报日志 -功能描述 -上报日志记录所有上报接口的调用记录，用于问题排查和审计。 -查询条件 -• 运单号/托运单号/货源单号：模糊搜索 -• 上报阶段：全部 / 第一次上报 / 第二次上报 / 第三次上报 / ETC上传 -• 上报结果：全部 / 成功 / 失败 -• 开始时间 ~ 结束时间：时间范围筛选 -列表字段 -序号、货源单号、运单号、托运单号、上报阶段、上报结果、接口URL、HTTP状态码、响应时间、上报时间、操作（弹窗详情查看完整请求/响应报文） -三. 数据字段说明 -3.1 第一次上报字段（装货完成） -核心子对象及必选字段： -• waybillInfo（建单信息）：originalDocumentNumber、shippingNoteNumber、documentCreateTime、carrier、unifiedSocialCreditIdentifier、permitNumber、businessTypeCode、goodsArrangementTypeCode、orderReceivingTime、departureTime、commercialContractNumber、contractNumber、mileage -• consignorInfo（托运人信息）：consignor、consignorId、frameContractNumber、placeOfLoading、loadingLongitude、loadingLatitude、loadingCountrySubdivisionCode -• consigneeInfo（收货方信息）：consignee、consigneeId、goodsReceiptPlace、unLoadingLongitude、unLoadingLatitude -• driverInfo（司机信息）：driverName、drivingIdNumber、drivingLicense、issuingOrganizations、qualificationCertificate、qualificationCertificateFrom、qualificationCertificateTo、taxRegistrationCertificate、telephone、validPeriodFrom、validPeriodTo、vehicleClass、provinceCode -• carInfo（接单车辆信息）：vehicleNumber、vehiclePlateColorCode、LicensePlateTypeCode、vin、owner、ownerId、useCharacter、vehicleType、vehicleEnergyType、registerDate、issueDate、issuingOrganizations、vehicleTonnage、grossMass、roadTransportCertificateNumber、trailerVehiclePlateNumber、vehicleLicenseNumbe、roadTransportSocialCreditFrom、roadTransportSocialCreditTo -• goodsInfos（货物信息，可多条）：descriptionOfGoods、cargoTypeClassificationCode、quantity、unit -• insuranceInformation（保险信息，可选）：policyNumber、insuranceCompany -3.2 第二次上报字段（打款完成） -新增字段说明： -• 收款人（自定义扩展字段）：对应资金流水中的收款方名称recipient) -• 收款账号（自定义扩展字段）：对应资金流水中的收款账号receiptAccount) -• 收款账号类型（自定义扩展字段）：个人账户 / 对公账户，为我方自定义列 -3.3 第三次上报字段（开票完成） -核心字段： -• 发票号码（invoiceNo）：增值税发票号码 -• 发票代码（invoiceCode）：增值税发票代码 -• 发票金额（invoiceAmount）：价税合计（保留2位小数） -（注：第三次上传的invoice无税率字段，税率仅出现在ETC发票上传中） -• 销售方名称（sellerName）：开票方企业名称 -• 受票方名称（buyerName）：托运人/货主企业名称 -3.4 ETC发票字段 -核心字段： -• ETC发票号码（etcInvoiceNo）：高速公路通行费电子发票号码 -• 入口收费站（entryStation）：通行入口 -• 出口收费站（exitStation）：通行出口 -• 税额（taxAmount）：可抵扣税额（税率3%） -详细数据接口字段请查阅上报接口： -https://www.showdoc.com.cn/2210641821476236/9919735893682511 -密码：szjj@2023 -原型： -接口文档： +# 安徽运八需求（以API文档为准重构） + +> **重构原则**: API接口文档(网货企业端接口文档 V1.0.2) 为查询+申诉权威数据源，Showdoc文档为上报接口字段定义权威数据源。HTML原型为UI参考，原始需求文档为业务背景补充。 +> **重构时间**: 2026-07-13（最后更新: 2026-07-14，根据14项确认决议） +> **原始需求**: `source_docs/requirements_raw/安徽运八需求.docx` +> **API文档（查询+申诉）**: `resources/integration/网货企业端接口文档（最新）.pdf` V1.0.2 (2023-04) +> **Showdoc文档（上报接口·权威字段定义）**: `resources/integration/showdoc文档.md` +> **原型**: `resources/prototypes/anhuibaba_enhanced.html` + +--- + +## 一、系统边界 + +本需求涉及两套系统的对接： + +| 系统 | 职责 | 本文档覆盖 | +|:---|:---|:---| +| **运八平台（我方）** | 自动触发三阶段上报、ETC上传；查询核验结果；发起/跟踪申诉；查看上报日志 | 全量 | +| **安徽省级网络货运监测系统（省平台）** | 接收上报数据；执行核验；受理申诉并反馈 | 仅接口交互 | + +API文档覆盖的是**运八平台→省平台**的查询和申诉接口。上报触发逻辑（装货完成/打款完成/开票完成自动触发）属于运八平台内部业务逻辑，API文档中未定义上报提交接口。 + +**上报接口（5个·Showdoc权威）** 由Showdoc文档定义，是运八平台向省平台上送数据的接口，与查询+申诉API是两个独立的接口体系： + +| Showdoc上报接口 | URL | 说明 | +|:---|:---|:---| +| 上传委托合同（框架） | `/api/dataUpload/mandateContractFrame` | **前置步骤**：运单第一次上报前必须先上传框架合同 | +| 第一次上传 | `/api/dataUpload/firstUpload` | 装货完成后上报（含waybillInfo, consignorInfo, consigneeInfo, driverInfo, carInfo, goodsInfos, insuranceInformation） | +| 第二次上传 | `/api/dataUpload/secondUpload` | 打款完成后上报（含arrivalInfo, ownerStatements, carrierStatements, carrierContractInfo, ownerContractInfo, trackList） | +| 第三次上传 | `/api/dataUpload/thirdUpload` | 开票完成后上报（含invoice, oilGasInvoices） | +| ETC发票上传 | `/api/dataUpload/etcInvoiceUpload` | 税务抵扣确认后上传（含shippingNoteNumber, vehicleNumber, vehiclePlateColorCode, etcInvoices） | +| 修改第一次上报部分字段 | `/api/dataUpload/updateFirstUploadParam` | 第一次上报成功后更新变化字段 | + +> **关键区分**: Showdoc的5个上报接口 + updateFirstUploadParam 是**数据上报**通道；PDF文档的9个接口是**查询+申诉**通道。两者共同构成运八平台的完整对接方案。 + +--- + +## 二、API接口清单（权威来源：接口文档 V1.0.2） + +### 2.1 通用规范 + +| 项目 | 规范 | +|:---|:---| +| 基地址 | `http://*******/api/` | +| 协议 | HTTP POST | +| 请求格式 | JSON（除上传文件接口外） | +| 响应格式 | `{"code":200, "message":"操作成功", "data":{}}` | +| 认证 | JWT Token，调用 `/sys/login` 获取，除登录接口外均需在请求头携带 | +| 时间格式 | `yyyy-MM-dd HH:mm:ss` | +| 成功码 | `code=200` | +| 失败码 | `code=500` | + +### 2.2 接口一览（共9个） + +| # | 接口 | URL | 说明 | +|:---:|:---|:---|:---| +| 1 | 获取token | `POST /sys/login` | JWT认证，参数: loginName, loginPassword | +| 2 | 上传申诉附件 | `POST /appeal/uploadFile` | 文件上传，参数: file (File) | +| 3 | 提交申诉运单 | `POST /appeal/insert` | 发起申诉，参数: freightSheetNumber, complaintNumber, attachmentUrl, content, verificationAbnormalItems | +| 4 | 查询异常运单信息 | `POST /verificationSummary/page` | 分页查询，支持多维度筛选 | +| 5 | 查询申诉进度 | `POST /appeal/page` | 分页查询申诉记录及审核结果 | +| 6 | 查询运单核验详情 | `POST /verificationSummary/verificationDetail` | 单运单全部核验项明细 | +| 7 | 查询发票是否合规 | `POST /verificationSummary/cargoOwnerInvoiceInfo` | 判断托运人发票系统核验是否合规 | +| 8 | 运单里程核验查询 | `POST /verificationSummary/mileageVerificationInfo` | 批量查询运单里程核验状态 | +| 9 | 运单里程申诉 | `POST /mileageAppeal/insert` | 对里程核验结果发起申诉 | + +### 2.3 接口详细定义 + +#### 接口1: 获取token +``` +POST /sys/login +请求: { "loginName": "xxx", "loginPassword": "xxx" } +响应: { "code": 200, "data": { "token": "...", "expireTime": 1681219619843, "loginName": "ceshi", "name": "测试" } } +``` + +#### 接口2: 上传申诉附件 +``` +POST /appeal/uploadFile +请求: multipart/form-data, 字段 file (File) +``` + +#### 接口3: 提交申诉运单 +``` +POST /appeal/insert +请求: + freightSheetNumber String 运单号 必填 + complaintNumber String 申诉编号 必填 + attachmentUrl String 申诉附件URL 必填 + content String 申诉内容 必填 + verificationAbnormalItems String 核验异常项ID 必填 (逗号分隔，如"120,160") +``` + +#### 接口4: 查询异常运单信息 +``` +POST /verificationSummary/page +请求: + pageIndex int 页码 必填 + pageSize int 每页条数 必填 + freightSheetNumber String 运单号 可选 + verificationAbnormalItems String 异常项ID 可选 (多个逗号拼接) + driverName String 驾驶员姓名 可选 + driverIdCard String 驾驶员身份证号 可选 + vehicleNumber String 车牌号 可选 + appealStateId int 申诉状态ID 可选 + verifyStateId int 核验状态ID 可选 + beginTime ~ endTime 运单创建时间范围 可选 + beginFirstVerifyTime ~ endFirstVerifyTime 首次核验时间范围 可选 + beginLastVerifyTime ~ endLastVerifyTime 最新核验时间范围 可选 + beginInsertTime ~ endInsertTime 插入时间范围 可选 + +响应: + pageRecords[]: + freightSheetNumber String 运单号 + appealStateId int 申诉状态ID + appealStateName String 申诉状态名称 + verificationAbnormalItem String 核验异常项 + createTime date 运单创建时间 + lastVerifyTime date 最新核验时间 + firstVerifyTime date 首次核验时间 + vehicleNumber String 车牌号 + driverName String 驾驶员姓名 + driverIdCard String 驾驶员身份证号 + verifyStateId int 核验状态ID + verifyStateName String 核验状态名称 + abnormalDetails[]: + id int 异常项ID + name String 异常项名称 + message String 异常原因 + time date 异常时间 + state int 异常项处理状态 (100=未申诉, 110=申诉中) +``` + +#### 接口5: 查询申诉进度 +``` +POST /appeal/page +请求: + pageIndex int 页码 必填 + pageSize int 每页条数 必填 + freightSheetNumber String 运单号 可选 + abnormalTypeId String 核验异常项ID 可选 + auditStateId String 审核状态ID 可选 + beginTime ~ endTime 申诉时间范围 可选 + auditBeginTime ~ auditEndTime 审核时间范围 可选 + complaintNumber String 申诉编号 可选 + +响应: + pageRecords[]: + complaintNumber String 申诉编号 + freightSheetNumber String 运单号 + content String 申诉内容 + complainantName String 申诉人 + auditStateId int 审核状态ID + auditStateName String 审核状态名称 + auditorName String 审核人 + auditRemark String 审核备注 + auditTime date 审核时间 + verificationAbnormalItem String 运单异常项 + cancelPerson String 取消人 + cancelReason String 取消原因 + cancelTime date 取消时间 + revokeUserName String 撤回人 + revokeTime date 撤回时间 + createTime date 创建时间 + appealAbnormalList[]: + verificationTypeId int 异常项ID + verificationTypeName String 异常项名称 +``` + +#### 接口6: 查询运单核验详情 +``` +POST /verificationSummary/verificationDetail +请求: + freightSheetNumber String 运单号 必填 + beginInsertTime String 插入时间-开始 可选 + endInsertTime String 插入时间-结束 可选 + +响应: + pageRecords[].details[]: + verificationCode int 核验项编码 + verificationName String 核验项名称 + verificationState String 核验状态 + verificationStateId int 核验状态ID + verificationTime date 核验时间 + message String 核验信息 +``` + +#### 接口7: 查询发票是否合规 +``` +POST /verificationSummary/cargoOwnerInvoiceInfo +请求: { "freightSheetNumber": "55141359" } +响应: { "isSystemVerification": true } // true=系统核验合规, false=人工判定合规 +``` + +#### 接口8: 运单里程核验查询 +``` +POST /verificationSummary/mileageVerificationInfo +请求: { "freightSheetNumberList": ["22222222", "111111"] } +响应: [ + { "verificationStateId": 110, "freightSheetNumber": "22222222", "mileage": 350.263 }, + { "verificationStateId": null, "freightSheetNumber": "4658151", "mileage": null } +] +// 注: 运单未上报里程时 verificationStateId 和 mileage 为 null +``` + +#### 接口9: 运单里程申诉 +``` +POST /mileageAppeal/insert +请求: + freightSheetNumber String 运单号 必填 + content String 申诉内容 必填 + complaintNumber String 申诉编号 必填 + mileage String 里程数 必填 +``` + +--- + +## 三、数据字典（权威来源：接口文档 §4.1~§4.5） + +### 3.1 异常项ID对照表（§4.1）— 共17项 + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 委托合同 | 托运人与承运人签订的委托运输合同核验 | +| 120 | 承运合同 | 承运人以自身名义签订的运输合同核验 | +| 130 | 实时定位 | 车辆实时定位数据核验 | +| 140 | 运单时间逻辑 | 运单各时间节点的逻辑合理性核验（如装货时间<卸货时间） | +| 150 | 车辆资质 | 车辆道路运输经营许可证有效性核验 | +| 160 | 道路运输证 | 车辆道路运输证有效期核验 | +| 170 | 驾驶证 | 驾驶员驾驶证有效性核验 | +| 180 | 从业资格证 | 驾驶员从业资格证有效期核验 | +| 190 | 车辆重复 | 同一车辆在同一时段是否存在多运单 | +| 200 | 司机重复 | 同一司机在同一时段是否存在多运单 | +| 210 | 车辆轨迹 | GPS轨迹真实性、与运单路线匹配度核验 | +| 220 | 运费收款 | 运单是否在运费收款方名下 | +| 230 | 公司统一收款 | 是否通过公司账户统一收款 | +| 240 | 集中支付 | 是否通过网络货运平台集中支付 | +| 250 | 资金流水 | 资金流水单号唯一性、金额匹配核验 | +| 260 | 发票信息 | 托运人发票信息核验（第三次上报相关） | +| 270 | 非通行车辆可开票 | 非通行车辆是否允许开具通行费发票 | + +### 3.2 运单核验状态（§4.2） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未核验 | 运单尚未被省平台核验 | +| 110 | 核验通过 | 全部核验项通过 | +| 120 | 全部异常 | 存在核验不通过的异常项 | + +### 3.3 运单部分核验状态（§4.3） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未核验 | 尚未核验 | +| 110 | 部分核验 | 部分核验项已通过，仍有待核验项 | +| 120 | 全部核验 | 全部核验项已出结果 | + +### 3.4 运单申诉状态（§4.4）— 权威枚举 + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| **100** | **未申诉** | 尚未发起申诉 | +| **110** | **审核通过** | 省平台审核通过 | +| **120** | **审核不通过** | 省平台审核驳回 | +| **130** | **已取消** | 省平台侧操作，我方只读（申诉由省平台取消，非我方可操作状态） | + +> **已取消(130)说明**: 状态130=已取消是**省平台侧直接操作**产生的状态，我方系统不提供"取消申诉"功能。运八平台只能查询到此状态，不能主动将申诉状态设为130。我方申诉状态流转不包含取消操作。 + +### 3.5 附件状态（§4.5） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未处理 | 申诉附件尚未被省平台处理 | +| 110 | 处理通过 | 附件核验通过 | +| 120 | 处理异常 | 附件核验异常 | + +--- + +## 四、功能模块（综合API文档+原型+原始需求） + +### 4.1 上报运单看板 + +**入口**: 侧边栏 → 上报运单看板 + +**统计卡片**（原型定义）: +- 异常运单数、待申诉数、申诉中数、已处理数 + +**查询条件**（综合原型+接口4请求参数）: + +| 筛选项 | 类型 | 可选值 | +|:---|:---|:---| +| 运单号/托运单号/货源单号 | 文本输入 | 模糊搜索 | +| 上报阶段 | 下拉 | 全部 / 第一次上报 / 第二次上报 / 第三次上报 | +| 核验状态 | 下拉 | 全部 / 异常 / 通过 | +| 申诉状态 | 下拉 | 全部 / 未申诉(100) / 审核通过(110) / 审核不通过(120) / 已取消(130·省平台只读) | + +**列表字段**（原型为准，15列含勾选）: +货源单号 / 运单号 / 托运单号 / 车牌号 / 司机姓名 / 上报阶段 / 托运方名称 / 核验状态 / 申诉状态 / 异常项 / 货物名称 / 合同金额 / 最新核验时间 / 操作 + +**操作按钮**: +- 异常运单: [申诉] [详情] +- 申诉中运单: [进度] [详情] +- 正常运单: [详情] + +**标签颜色**（原型CSS定义）: +- 蓝色 `.tag-blue`: 上传中、申诉中 +- 绿色 `.tag-green`: 已上传、通过、已完成、申诉通过、对公账户 +- 红色 `.tag-red`: 上传失败、异常、申诉驳回 +- 橙色 `.tag-orange`: 异常项标签、待上报 +- 灰色 `.tag-gray`: 未申诉 +- 紫色 `.tag-purple`: (预留) + +### 4.2 委托合同上传（前置步骤·Showdoc权威） + +**来源**: Showdoc接口 `POST /api/dataUpload/mandateContractFrame` + +**时机**: 在进行运单的第一次上报前，需先将委托合同（框架）通过此接口上传至省平台。 + +**说明**: +- 委托合同（框架）和委托合同**二选一**上报 +- 文件信息可暂时不传，在修改委托合同时再补充合同文件 +- 后续合同有新增或修改，再调用上传或修改接口即可 +- 目前省平台不支持单独查询合同，可在运单第一次上报后，在运单信息中查看合同 + +**核心字段**: +| 参数 | 必选 | 说明 | +|:---|:---|:---| +| contract_number | 是 | 合同编号 | +| expire_time | 是 | 合同有效期截止时间 yyyy-MM-dd | +| unified_social_credit_identifier | 可选 | 单托运企业统一社会信用代码 | +| owner_enterprise_name | 可选 | 单托运企业名称 | +| enterpriseList | 可选 | 多托运企业列表（与单托运企业互斥，都传值默认取单） | +| uploadFileInfo | 否 | 文件信息（name / url / dataList三选一） | + +### 4.3 第一次上报（装货完成） + +**触发条件**: 运单装货完成 AND 货源税源地=安徽 + +**上报数据子对象**（以接口文档字段定义为准）: + +| 子对象 | 必选/可选 | 核心字段（Showdoc权威定义） | +|:---|:---|:---| +| waybillInfo（建单信息） | 必选 | originalDocumentNumber, shippingNoteNumber, documentCreateTime(yyyyMMddHHmmss), carrier, unifiedSocialCreditIdentifier, permitNumber, businessTypeCode, goodsArrangementTypeCode, orderReceivingTime(yyyyMMddHHmmss), departureTime(yyyyMMddHHmmss), commercialContractNumber, contractNumber(可选), mileage(可选·3位小数) | +| consignorInfo（托运人信息） | 必选 | consignor, consignorId, frameContractNumber(可选), placeOfLoading, loadingLongitude(6位小数), loadingLatitude(6位小数), loadingCountrySubdivisionCode | +| consigneeInfo（收货方信息·6字段） | 必选 | consignee, consigneeId, goodsReceiptPlace, unLoadingLongitude(6位小数), unLoadingLatitude(6位小数), unLoadingNationSubdivisionCode | +| driverInfo（司机信息·15字段） | 必选 | driverName, telephone, drivingIdNumber, drivingLicense, vehicleClass, issuingOrganizations, validPeriodFrom(yyyyMMdd), validPeriodTo(yyyyMMdd), qualificationCertificate, provinceCode, qualificationCertificateFrom(可选), qualificationCertificateTo(可选), taxRegistrationCertificate(可选), registerDate(yyyyMMdd), anchoredUrl(可选·文件列表) | +| carInfo（车辆信息·20字段） | 必选 | vehicleNumber, vehiclePlateColorCode, vehicleType, LicensePlateTypeCode, owner, ownerId(可选), useCharacter, vin, issuingOrganizations, registerDate(yyyyMMdd), issueDate(yyyyMMdd), vehicleEnergyType, vehicleTonnage(Double), grossMass(Double), roadTransportCertificateNumber, trailerVehiclePlateNumber(可选), vehicleLicenseNumber(可选), roadTransportSocialCreditFrom(可选·yyyyMMdd), roadTransportSocialCreditTo(可选·yyyyMMdd), anchoredUrl(可选·文件列表) | +| goodsInfos（货物信息） | 必选，可多条 | descriptionOfGoods, cargoTypeClassificationCode, quantity(Double), unit | +| insuranceInformation（保险信息） | 可选 | policyNumber, insuranceCompany | + +**业务规则**: +- 仅安徽税源地(省份代码=34，非28)运单触发 +- 上报成功后自动调用"修改第一次上报部分字段"接口更新变化字段 +- 失败自动重试最多3次，全部失败后站内信通知运营 +- 第一次上报是后续上报的前置条件（后端校验） + +**列表页**（原型为准，14列+勾选）: +货源单号 / 运单号 / 托运单号 / 车牌号 / 司机姓名 / 托运方名称 / 业务类型 / 货物名称 / 装货地址 / 卸货地址 / 运输里程 / 合同编号 / 上报状态 / 操作 + +**上报状态**（内部系统状态，非API枚举）: +- 上传中（蓝色） +- 已上传（绿色） +- 上传失败（红色）— 显示"手动上传"按钮 +- 异常（橙色） + +### 4.4 第二次上报（打款完成） + +**触发条件**: 财务打款完成 AND 第一次上报已完成 + +**核验项**: 省平台自动核验，共17项（见§3.1）。每项独立产生核验结果，核验异常项可通过申诉机制逐项申诉。 + +**上报数据子对象**（Showdoc权威·第二次上传结构完全不同）: +| 子对象 | 必选/可选 | 核心字段 | +|:---|:---|:---| +| arrivalInfo（运抵信息） | 必选 | shippingNoteNumber, startTicketFileUrl(文件列表), arrivalTime(yyyyMMddHHmmss), arrivalTicketFileUrl(文件列表), waybillFreightAmount(Double·3位小数·承运运费), totalMonetaryAmount(Double·3位小数·委托运费) | +| ownerStatements（货主流水） | 必选 | documentNumber, carrier, actualCarrierId, paymentMeansCode, paymentName, paymentAccount, paymentBankName(选填), recipient, receiptAccount, receiptBankName(选填), sequenceCode, monetaryAmount(Double·3位小数), appointmentTime(yyyyMMdd), payTime(yyyyMMddHHmmss) | +| carrierStatements（承运人流水） | 必选 | documentNumber, carrier, actualCarrierId, paymentMeansCode, paymentName, paymentAccount, paymentBankName, recipient, receiptIdCard, receiptAccount, receiptBankName, sequenceCode, monetaryAmount(String·3位小数), appointmentTime(yyyyMMdd), payTime(yyyyMMddHHmmss), oilCardAmount(选填·3位小数), replaceAgreementFiles(可选·代收协议文件) | +| carrierContractInfo（承运合同） | 必选 | contractBusinessName, contractNumber, partyAName, partyAId, partyBName, partyBId, contractedCarryingCapacity(Double·3位小数), unit, contractAmount(Double·3位小数), agreedBusinessCompletionTime(yyyyMMdd), promisePayTime(yyyyMMdd), partyBReceiptName, partyBAccount, bankName(否), placeOfLoading, goodsReceiptPlace, descriptionOfGoods, vehicleNumber, contractSigningTime(yyyyMMddHHmmss), contractUrl(文件列表) | +| ownerContractInfo（委托合同） | 可选 | 18字段（委托合同与框架合同二选一上报） | +| trackList（车辆轨迹） | 必选，2~2000点 | locationMethod(BD/LBS/WECHAT/APP), locationTime(yyyyMMddHHmmss), locationAddress, longitude(6位小数), latitude(6位小数), trackType(LOADING/UNLOADING/NORMAL·可选) | + +**列表页**（原型为准，17列+勾选）: +货源单号 / 运单号 / 托运单号 / 车牌号 / 司机姓名 / 托运方名称 / 承运运费 / 总金额 / 付款方式 / 付款时间 / 收款人 / 收款账号 / 收款账号类型 / 核验状态 / 异常项 / 上报状态 / 操作 + +**收款账号类型标签**: 个人账户=蓝色, 对公账户=绿色 + +### 4.5 第三次上报（开票完成） + +**触发条件**: 发票开具完成 AND 第二次上报已完成 + +**前置条件**: 第二次上报必须完成（后端校验） + +**API关联接口**: +- `POST /verificationSummary/cargoOwnerInvoiceInfo` — 查询托运人发票系统核验是否合规 +- 响应: `isSystemVerification`: true=系统核验合规, false=人工判定合规 + +**列表页**（原型为准，15列+勾选）: +货源单号 / 运单号 / 托运单号 / 发票号码 / 发票金额 / 税率 / 销售方名称 / 受票方名称 / 开票日期 / 油气票张数 / 核验状态 / 异常原因 / 上报状态 / 操作 + +### 4.6 ETC发票上传 + +**触发条件**: ETC发票税务抵扣成功后，由运营人员在运八系统**手动确认抵扣完成**，确认后系统触发ETC发票上传（非自动触发） + +**列表页**（原型为准，10列+勾选）: +货源单号 / 运单号 / 托运单号 / ETC发票号 / 交易金额 / 入口收费站 / 出口收费站 / 交易时间 / 上传状态 / 操作 + +**详情弹窗字段**（原型为准）: +- 运单信息: 运单号、货源单号、托运单号、车牌号、司机姓名、托运方名称、收货方名称 +- ETC发票信息: ETC发票号码、ETC发票代码、交易金额、税率(3%)、发票金额(不含税)、税额、入口收费站、出口收费站、交易时间、发票状态 + +### 4.7 异常申诉功能 + +**关联API接口**: +- `POST /appeal/uploadFile` — 上传申诉附件 +- `POST /appeal/insert` — 提交申诉 +- `POST /appeal/page` — 查询申诉进度 +- `POST /mileageAppeal/insert` — 里程申诉（独立接口） + +**申诉流程**（闭环）: +``` +异常运单查询(接口4) → 发起申诉(接口3) → 省平台复核 → +查询申诉进度(接口5) → 审核通过(110) | 审核不通过(120) → +重新申诉(接口3) [审核不通过时] +``` + +**申诉状态流转**（以API §4.4为准，我方可控流转）: +``` +未申诉(100) → 提交申诉 → 未申诉(100) [申诉中·abnormalDetails.state=110] +未申诉(100) → 省平台审核通过 → 审核通过(110) [终态] +未申诉(100) → 省平台审核驳回 → 审核不通过(120) → 重新申诉 → 未申诉(100) [新申诉单] +``` + +> **已取消(130)**: 此状态由省平台侧操作产生（如省平台管理员取消申诉），我方系统不提供触发入口，仅被动查询和展示。因此不纳入我方申诉状态流转中。 + +**列表页**（原型为准，14列+勾选）: +运单号 / 托运单号 / 车牌号 / 司机姓名 / 托运方名称 / 上报阶段 / 核验状态 / 异常项 / 申诉状态 / 申诉时间 / 申诉人 / 省平台反馈结果 / 省平台反馈时间 / 操作 + +**详情弹窗分组**（原型为准）: +- 申诉信息: 申诉单号、上报阶段、异常项、申诉原因、申诉状态、申诉时间、申诉人、申诉附件 +- 运单信息: 运单号、托运单号、车牌号、司机姓名、托运方名称 +- 异常信息: 核验状态、异常原因、异常时间 +- 省平台反馈信息: 反馈状态、反馈时间、反馈结果、反馈意见 +- 处理记录（时间线）: 操作人、操作时间、操作类型、操作内容 + +### 4.8 上报日志 + +**查询条件**（原型为准）: +- 运单号/托运单号/货源单号: 模糊搜索 +- 上报阶段: 全部 / 第一次上报 / 第二次上报 / 第三次上报 / ETC上传 +- 上报结果: 全部 / 成功 / 失败 +- 时间范围: 开始时间 ~ 结束时间 + +**列表字段**（原型为准，11列）: +序号 / 货源单号 / 运单号 / 托运单号 / 上报阶段 / 上报结果 / 接口URL / HTTP状态码 / 响应时间 / 上报时间 / 操作 + +**日志详情弹窗**: 展示完整请求报文（URL/Method/Headers/Body）和响应报文（StatusCode/Headers/Body），JSON格式化展示，支持一键复制。 + +--- + +## 五、状态枚举汇总（以API文档为权威） + +### 5.1 申诉状态（API §4.4 权威） + +| Code | 名称 | 原始需求对应 | 我方可操作 | 说明 | +|:---:|:---|:---|:---:|:---| +| 100 | 未申诉 | 未申诉 + 申诉中 | 是 | 含已提交但省平台尚未审核的情况（申诉中通过 abnormalDetails[].state=110 标识） | +| 110 | 审核通过 | 申诉通过 | 否（终态） | 省平台审核通过 | +| 120 | 审核不通过 | 申诉驳回 | 否（可重新申诉） | 省平台审核驳回，可重新发起申诉 | +| 130 | 已取消 | （无） | **否·省平台只读** | 省平台侧操作取消，我方仅查询展示 | + +### 5.2 核验状态（API §4.2 权威） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未核验 | 运单尚未核验 | +| 110 | 核验通过 | 全部17项核验通过 | +| 120 | 全部异常 | 存在核验异常项 | + +### 5.3 异常项处理状态（API §4.1 子字段） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未申诉 | 该异常项尚未发起申诉 | +| 110 | 申诉中 | 该异常项已提交申诉，待审核 | + +### 5.4 上报状态（内部系统状态，非API枚举） + +| 状态 | 标签颜色 | 说明 | +|:---|:---|:---| +| 上传中 | 蓝色 | 数据正在上报中 | +| 已上传 | 绿色 | 上报成功 | +| 上传失败 | 红色 | 上报超时或错误，显示"手动上传"按钮 | +| 异常 | 橙色 | 数据校验不通过 | + +--- + +## 六、与原始需求的关键差异 + +| # | 项目 | 原始需求 | API/Showdoc（权威） | 影响 | +|:---:|:---|:---|:---|:---| +| 1 | 核验项数量 | 7类 | **17项** (API §4.1) | 测试覆盖需从14条扩展到34条 | +| 2 | 申诉状态 | 未申诉/申诉中/通过/驳回 | **未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130·省平台只读)** | 申诉状态枚举全部更新，130不纳入我方流转 | +| 3 | 申诉"进行中" | 独立状态"申诉中" | 归属于"未申诉(100)"，由abnormalDetails[].state=110标识 | 状态机变更 | +| 4 | 已取消状态 | 无 | **130=已取消·省平台操作·我方只读** | 不提供"取消申诉"按钮，仅查询展示 | +| 5 | 里程申诉 | 无 | **独立接口** `/mileageAppeal/insert` | 新增功能模块 | +| 6 | 发票合规查询 | 无 | **独立接口** `/verificationSummary/cargoOwnerInvoiceInfo` | 新增功能点 | +| 7 | 核验状态 | 通过/异常（二元） | 未核验(100)/通过(110)/全部异常(120) | 新增"未核验"初始状态 | +| 8 | 附件状态 | 无 | 未处理(100)/处理通过(110)/处理异常(120) | 新增枚举 | +| 9 | 委托合同上传 | 无 | Showdoc **mandateContractFrame** 接口 | 新增前置步骤：第一次上报前必须先上传框架合同 | +| 10 | ETC触发方式 | 税务抵扣完成（自动） | **人工手动确认抵扣完成后触发** | 需要运营人员在运八系统手动确认 | +| 11 | 金额精度 | 2位小数 | **第二次上报金额3位小数**（Showdoc） | 金额存储和校验精度变更 | +| 12 | 时间格式 | `yyyy-MM-dd HH:mm:ss` | **上报接口用 `yyyyMMddHHmmss`（14位）**（Showdoc） | 上报数据格式化逻辑变更 | +| 13 | ETC invoiceAmount | 总金额 | **不含税金额**（Showdoc） | ETC发票金额语义变更 | + +--- + +## 七、上报接口文档参考（Showdoc · 权威字段定义） + +### 7.0 Showdoc通用规范 + +| 项目 | 规范 | +|:---|:---| +| 认证方式 | MD5签名Token（请求体JSON字符串+密钥 → MD5加密），非JWT | +| 请求格式 | `{"partnerId":"xxx", "appId":"xxx", "workerId":"001", "args":{...}}` | +| 成功码 | `code=200` | +| 失败码 | `code=500` | +| 时间戳 | 13位毫秒时间戳 | + +> ⚠️ **关键差异**: Showdoc上报接口使用MD5签名Token，而查询+申诉API（PDF文档）使用JWT Token。两套认证体系独立。 + +### 7.1 字段精度关键差异（Showdoc vs 原始需求） + +以下是从Showdoc文档中发现的与原始需求/原型不一致的关键字段定义： + +| # | 字段相关 | 原始需求/原型假设 | Showdoc权威定义 | +|:---:|:---|:---|:---| +| 1 | **金额精度** | 保留2位小数 | **第二次上报金额保留3位小数**（arrivalInfo.waybillFreightAmount、totalMonetaryAmount、carrierStatements.monetaryAmount、ownerStatements.monetaryAmount、carrierContractInfo.contractAmount、contractedCarryingCapacity等均保留3位小数，如整数以.000填充） | +| 2 | **时间格式** | `yyyy-MM-dd HH:mm:ss` | **上报接口时间格式为 `yyyyMMddHHmmss`（14位）**（如documentCreateTime、orderReceivingTime、departureTime），日期字段用 `yyyyMMdd`（8位） | +| 3 | **第一次上报字段数** | consigneeInfo=5字段、driverInfo=13字段、carInfo=19字段 | Showdoc: consigneeInfo=6字段（含unLoadingNationSubdivisionCode）、driverInfo=15字段（含registerDate、anchoredUrl）、carInfo=20字段（含anchoredUrl）、goodsInfos.quantity=Double | +| 4 | **第二次上报结构** | 追加资金流水+轨迹 | Showdoc定义完全不同：arrivalInfo(含startTicketFileUrl+arrivalTicketFileUrl)+ownerStatements+carrierStatements+carrierContractInfo+ownerContractInfo(可选)+trackList；carrierStatements含oilCardAmount和replaceAgreementFiles | +| 5 | **第三次上报** | 发票17字段 | Showdoc: invoice明确17字段+invoiceUrl文件；oilGasInvoices选填 | +| 6 | **ETC发票** | invoiceAmount=发票总金额 | **invoiceAmount = 不含税金额**（not总金额!）；17个etcInvoices字段；税率格式x.x%（如3%） | +| 7 | **委托合同上传** | 未提及 | Showdoc有 `mandateContractFrame` 接口 — 之前完全遗漏！委托合同（框架）和委托合同二选一上报 | + +### 7.2 Showdoc FAQ 关键摘录 + +以下FAQ影响功能设计和测试用例设计： + +| 主题 | FAQ要点 | +|:---|:---| +| **运单不可取消/删除** | 服务平台不支持取消或删除运单，上传后不允许修改任何信息。建议企业在运单信息确认后再上传。 | +| **承运人流水核验时效** | 除承运人流水核验需等待次日银行提供数据后开始核验，其余核验项会在一至两小时内核验完成。 | +| **发票红冲流程** | 货主发票开具后需红冲：在服务平台企业端将货主发票作废，再将重新开具的发票通过第三次上传接口上传。 | +| **税率统一3%** | 承运人流水中的税率统一传3%，税额按3%计算。 | +| **油卡金额** | 在上传承运人流水时据实填写油卡金额（oilCardAmount），如一条运单存在多条承运人流水，可在任一承运人流水中填写。 | +| **委托合同（框架）上传时机** | 在进行运单第一次上报前需将框架合同通过接口上传至服务平台，后续合同有新增或修改再调用上传/修改接口。 | +| **轨迹点数** | 企业上传的轨迹点数需在2-2000之间。地址字段若无，传"-"。 | +| **核验结果查看** | 两种方式：①服务平台企业端查询；②对接服务平台异常查询接口实现在企业自有系统内查询、处理。 | +| **合规运单开票** | 运单必须上传至服务平台且核验通过后才允许开具货主发票；第二次上传完成后即可查看核验结果。 | + +--- + +## 八、待确认项（14项 → 已确认14项 ✅） + +> **更新 2026-07-14**: 以下14项已全部通过用户确认决议。方框标记为确认结果。 + +### 阻塞级（已确认） +1. ✅ **核验项展示**: API 17项核验全部展示，每项可独立申诉。analysis文档已明确。 +2. ✅ **上报接口字段定义**: Showdoc文档为权威数据源。Showdoc定义5个上报接口 + updateFirstUploadParam，与PDF的9个查询+申诉接口分离。 + +### 重要级（已确认） +3. ✅ **申诉状态"已取消(130)"**: 省平台侧操作，我方只读，不提供"取消申诉"按钮。运单不可取消/删除。 +4. ✅ **原型UI状态映射**: "待省平台反馈"和"反馈处理中"为UI层面的展示状态，对应API 未申诉(100)·申诉中。 +5. ✅ **第三次上报列表字段**: 以原型15列为准。 +6. ✅ **里程申诉与通用申诉**: 独立接口 `/mileageAppeal/insert`，与 `/appeal/insert` 分离。 +7. ✅ **发票合规查询**: 独立接口 `/cargoOwnerInvoiceInfo`，独立于申诉流程。 + +### 参考级（已确认） +8. ✅ **自动重试间隔**: 当前方案5s/15s/30s合理可用。 +9. ✅ **ETC税额**: 税率固定3%，税额按3%计算。 +10. ✅ **申诉超时告警**: 7个工作日阈值可用。 +11. ✅ **省份代码**: 安徽=34，与API文档一致。 +12. ✅ **第二次上报详情弹窗缺失轨迹**: 确认为原原型Bug，增强版原型已包含轨迹表格。 +13. ✅ **原型详情弹窗字段**: 以接口Showdoc定义为准。 +14. ✅ **ETC触发条件**: ETC发票税务抵扣成功后，由运营人员在运八系统**手动确认抵扣完成**，确认后系统触发ETC发票上传（非自动触发）。 diff --git a/output/test_cases/安徽运八需求_测试用例.md b/output/test_cases/安徽运八需求_测试用例.md index 33db92c..7531de4 100644 --- a/output/test_cases/安徽运八需求_测试用例.md +++ b/output/test_cases/安徽运八需求_测试用例.md @@ -1,63 +1,428 @@ # 安徽运八需求 测试用例 > 生成时间: 2026-07-13 -> 基于: 测试点矩阵、需求文档、风险评估报告、项目画像、历史缺陷、易漏场景清单 -> 验证标准: 每条用例同时覆盖 UI 反馈 + 数据状态变化 +> 需求文档: output/normalized_inputs/安徽运八需求/requirement.md +> 测试点来源: output/test_points/安徽运八需求_测试点.md (106个测试点) +> 测试数据参考: output/analysis/安徽运八需求_测试数据.md +> 关联分析: output/analysis/安徽运八需求_关联与冲突.md +> +> 测试用例总数: 158 +> P0: 30 / P1: 85 / P2: 36 / P3: 8 +> 模块分布: A(看板)=18, B(第一次上报)=25, C(第二次上报)=50, D(第三次上报)=15, E(ETC)=12, F(申诉)=20, G(日志)=11, X(跨模块)=8 + +--- + +## 模块A: 上报运单看板 | 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | -| :--- | :--- | :--- | :---: | :--- | :--- | :--- | :--- | :--- | :--- | -| TC-DB-001 | 上报运单看板 | 多条件组合查询（运单号模糊+上报阶段+核验状态+申诉状态） | P1 | 功能测试 | 1.已登录超管账号 2.系统存在多条不同状态的上报运单 | 1.进入看板 2.输入运单号部分字符 3.选上报阶段=第一次上报 4.选核验状态=通过 5.选申诉状态=未申诉 6.点查询 | 运单号部分字符、筛选条件组合 | UI:列表仅展示满足所有条件的运单，筛选条件保持选中。数据:后端返回结果AND匹配所有条件 | | -| TC-DB-002 | 上报运单看板 | 重置按钮清空所有查询条件 | P2 | 功能测试 | 已设置任意查询条件 | 1.设置多个筛选条件 2.点重置按钮 | 任意筛选条件 | UI:所有条件恢复默认，列表刷新为全量数据。数据:查询接口参数为空或默认值 | | -| TC-DB-003 | 上报运单看板 | 查询结果为空时显示友好提示 | P2 | 功能测试 | 已登录 | 1.输入不存在的运单号 2.点查询 | 运单号=NOTEXIST999999 | UI:显示空状态提示图标+文案，不显示空白表格或报错。数据:接口返回空数组，HTTP 200 | | -| TC-DB-004 | 上报运单看板 | 列表字段完整性与异常项差异化展示 | P1 | 功能测试 | 1.存在核验通过运单 2.存在核验异常运单 | 1.进入看板 2.查看表头 3.对比两种状态运单行 | 核验通过运单、核验异常运单 | UI:表头含14个字段；通过行异常项为空；异常行异常项显示具体原因；合同金额千分位+2位小数。数据:接口字段与UI一一对应 | 合TP-DB-011, TP-DB-015 | -| TC-DB-005 | 上报运单看板 | 导出Excel内容与筛选结果一致 | P2 | 功能测试 | 已设置筛选条件使结果集约50条 | 1.设置筛选条件 2.点导出 3.下载并打开Excel | 50条筛选结果 | UI:导出按钮可点击，下载Excel包含所有列表字段。数据:Excel行数=筛选结果数，字段顺序一致，金额为数字格式 | | -| TC-DB-006 | 上报运单看板 | 特殊字符输入安全性（SQL注入/HTML/Emoji） | P2 | 安全性测试 | 已登录 | 1.输入`' OR '1'='1`点查询 2.输入``点查询 3.输入Emoji点查询 | SQL注入字符串、XSS字符串、Emoji表情 | UI:不报错不弹窗不异常页面。数据:后端返回空结果或正确转义，HTTP 200，无注入生效 | | -| TC-FR-001 | 第一次上报 | 装货完成后系统自动触发第一次上报（全字段完整性） | P0 | 功能测试 | 1.运单已接单 2.车辆/司机/货物/托运方/收货方信息完整 3.司机完成装货确认 | 1.司机APP端确认装货完成 2.回管理端查看上报状态 | 完整运单数据（建单13+托运人7+收货方5+司机13+车辆19+货物+保险字段） | UI:列表出现该运单，状态:上传中(蓝)→已上传(绿)；看板显示"第一次上报"。数据:上报接口被调用，请求体含完整子对象，HTTP 200，数据库状态更新 | | -| TC-FR-002 | 第一次上报 | 必选字段缺失（从业资格证号）→上报异常 | P1 | 功能测试 | 司机从业资格证号为空 | 1.触发装货完成上报 2.查看上报结果 | 司机信息缺失从业资格证号 | UI:状态=异常(橙)，操作列显示详情按钮；详情中异常原因含"从业资格证号缺失"。数据:接口返回校验失败，数据库记录状态=异常+异常原因 | | -| TC-FR-003 | 第一次上报 | 可选字段为空（委托合同编号/运输里程/保险信息）→上报正常 | P1 | 功能测试 | 必选字段完整，可选字段均为空 | 1.触发装货完成上报 2.查看结果 | 可选字段均为空的运单 | UI:状态正常流转为"已上传"(绿)。数据:请求体可选字段值为null/空字符串，接口返回成功 | | -| TC-FR-004 | 第一次上报 | 货物信息多条记录(≥2条)上报 | P2 | 功能测试 | 运单包含3条货物信息（钢材/木板/配件） | 1.触发上报 2.查看详情弹窗货物信息区 | 3条货物数据 | UI:详情弹窗展示3条货物记录各含4字段。数据:请求体goodsInfos数组length=3，接口成功 | | -| TC-FR-005 | 第一次上报 | 核验通过后自动调用"修改第一次上报部分字段"更新实际里程 | P0 | 功能测试 | 1.第一次上报已触发 2.装货后实际里程变化(预估500→实际520km) | 1.上报成功核验通过 2.观察自动更新 3.查看运单里程字段 | 预估里程=500km, 实际里程=520km | UI:无人工干预下运单里程自动更新为520km；操作日志有"自动更新第一次上报字段"记录。数据:修改接口被调用，mileage=520，数据库运单里程更新 | | -| TC-FR-006 | 第一次上报 | 上报失败→自动重试3次→站内信通知运营人员 | P1 | 功能测试 | 模拟安徽运八接口不可用(超时或500) | 1.触发上报 2.等待重试周期 3.观察最终结果 4.检查站内信 | 接口超时异常 | UI:状态流转:上传中→上传失败(红标签)，出现"手动上传"按钮；运营收到站内信含运单号和失败原因。数据:接口调用4次(首+3重试)，重试间隔递增；站内信表新增通知记录 | | -| TC-FR-007 | 第一次上报 | 重试中手动触发上报→幂等性校验 | P1 | 功能测试 | 上报失败正处自动重试中 | 1.运单重试中 2.运营点"手动上传" | 重试中的运单 | UI:提示"上报处理中请勿重复操作"或排队等待；不出现两条上报记录。数据:同一运单在安徽运八平台仅一条记录 | | -| TC-FR-008 | 第一次上报 | 第一次上报失败阻断后续第二、三次上报 | P0 | 功能测试 | 运单第一次上报失败(3次重试全败) | 1.确认第一次上报失败 2.尝试触发第二次上报 3.尝试触发第三次上报 | 第一次上报失败的运单 | UI:第二次上报按钮不可见/置灰提示"请先完成第一次上报"；第三次同样阻断。数据:第二/三次接口调用被前置校验拦截，日志无记录 | | -| TC-FR-009 | 第一次上报 | 详情弹窗8组字段分组展示与数据一致性 | P1 | 功能测试 | 存在已完成的第一次上报运单 | 1.点详情 2.逐一查看建单/托运人/收货方/司机/车辆/货物/保险/异常分组 3.与运单管理模块核对 | 完整上报数据 | UI:弹窗按8组展示，分组标题明确；无异常时显示"无异常"；保险为空显示"-"。数据:弹窗字段值与上报请求体一致，与运单管理模块一致 | | -| TC-FR-010 | 第一次上报 | 4种状态标签颜色验证 | P2 | 功能测试 | 准备4个运单分别处于上传中/已上传/上传失败/异常状态 | 1.进入列表 2.观察4条运单状态标签颜色 | 4种状态的运单 | UI:上传中=蓝标签；已上传=绿标签；上传失败=红标签；异常=橙标签。数据:状态字段值与颜色映射正确 | | -| TC-SR-001 | 第二次上报 | 打款完成后自动触发上报（含资金流水+轨迹+7核验） | P0 | 功能测试 | 1.运单第一次上报已完成 2.财务完成打款 | 1.财务打款 2.查看第二次上报列表 | 完整打款数据(金额/流水号/时间/收款方/收款账号/账号类型) | UI:列表出现该运单状态"上传中"(蓝)；展示承运运费/总金额/付款方式/时间/收款人/收款账号/账号类型。数据:上报接口被调用，请求体含资金流水+轨迹信息；流水数据与账户管理模块一致 | | -| TC-SR-002 | 第二次上报 | 车辆轨迹点位边界值:2个点(起点+终点)→成功 | P1 | 功能测试 | 轨迹数据仅2个点位 | 1.触发第二次上报 2.查看结果 | 轨迹数据=[起点,终点] len=2 | UI:上报成功状态"已上传"。数据:请求体轨迹数组length=2，接口成功 | | -| TC-SR-003 | 第二次上报 | 车辆轨迹点位边界值:1个点→失败 | P2 | 功能测试 | 轨迹数据仅1个点位 | 1.触发第二次上报 2.查看结果 | 轨迹数据=[单点] len=1 | UI:上报失败状态"异常"(橙)；异常原因含"轨迹点位不足"。数据:接口返回校验失败提示轨迹点数需≥2 | | -| TC-SR-004 | 第二次上报 | 运单重复上报→核验异常 | P0 | 功能测试 | 运单已完成第二次上报且核验通过 | 1.尝试再次上报同一运单 | 已通过的运单 | UI:系统提示"该运单已完成第二次上报"或被阻止；不产生新记录。数据:接口被前置校验拦截或安徽平台返回"运单重复"；数据库无重复记录 | | -| TC-SR-005 | 第二次上报 | 车辆资质核验:道路运输证有效期内→通过 | P1 | 功能测试 | 车辆道路运输证有效期至2026-12-31(有效期内) | 1.触发第二次上报 2.等待核验 3.查看核验结果 | 有效期内的道路运输证 | UI:核验状态"通过"，无"车辆资质"异常项。数据:核验接口返回车辆资质=通过 | | -| TC-SR-006 | 第二次上报 | 车辆资质核验:道路运输证已过期→异常 | P1 | 功能测试 | 车辆道路运输证有效期至2025-01-01(已过期) | 1.触发第二次上报 2.等待核验 | 过期的道路运输证 | UI:核验状态"异常"(橙)；异常项显示"车辆资质核验"不通过；可发起申诉。数据:核验接口返回车辆资质=异常，原因"道路运输证过期" | | -| TC-SR-007 | 第二次上报 | 资金流水单号重复→系统自动拦截 | P0 | 功能测试 | 系统中已存在流水号LS202607130001的记录 | 1.创建新运单打款但流水号重复 2.触发第二次上报 | 重复流水号=LS202607130001 | UI:系统上报前自动检测到重复，提示"流水单号已使用请核实"；上报被阻止。数据:流水号唯一索引生效；接口未被调用；操作日志记录拦截 | | -| TC-SR-008 | 第二次上报 | 资金流水金额不匹配(合同10000 vs 打款9500)→核验异常 | P1 | 功能测试 | 合同金额10000元，实际打款9500元 | 1.触发第二次上报 2.等待核验 | 合同金额=10000, 打款金额=9500 | UI:核验状态"异常"；异常项含"资金流水核验"不通过，原因"金额不匹配"。数据:核验接口返回资金流水核验=异常 | | -| TC-SR-009 | 第二次上报 | 车辆轨迹合规异常→补传轨迹→重新核验通过 | P1 | 功能测试 | 第二次上报后"车辆轨迹合规"核验异常 | 1.点"补传轨迹" 2.上传补充GPS点位文件 3.提交 4.等待重新核验 | 补充轨迹GPS文件 | UI:补传轨迹按钮可见可点击；上传后提示成功等待核验；核验通过后异常消除状态变"通过"。数据:补传轨迹追加到原数据；重调核验接口；核验结果更新为通过 | | -| TC-SR-010 | 第二次上报 | 收款账号类型标签:个人=蓝色/对公=绿色 | P2 | 功能测试 | 两个运单:一个司机个人账户、一个企业对公账户 | 1.进入列表 2.查看收款账号类型标签 | 个人账户(司机银行卡)、对公账户(企业银行账号) | UI:个人账户=蓝标签"个人账户"；对公账户=绿标签"对公账户"。数据:字段值正确对应 | | -| TC-SR-011 | 第二次上报 | 重试3次全失败→告警通知运营人员 | P1 | 功能测试 | 模拟安徽运八接口不可用 | 1.触发第二次上报 2.等3次重试全失败 3.检查告警 | 接口不可用 | UI:状态变为"上传失败"(红)；出现"手动上传"按钮；运营收到站内信通知含运单号/失败原因/重试次数。数据:重试次数=3；站内信表新增告警通知；操作日志记录完整 | | -| TC-TR-001 | 第三次上报 | 开票完成后触发上报（含17字段发票+托运单号数组） | P0 | 功能测试 | 1.运单第二次上报已完成 2.发票已开具 | 1.开票审核模块完成开票 2.查看第三次上报列表 | 完整发票信息(17字段)+托运单号数组 | UI:列表出现该运单含发票号码/金额/开票日期；状态:上传中→已上传。数据:上报接口被调用；发票数据与开票审核模块一致 | | -| TC-TR-002 | 第三次上报 | 第二次上报未完成时第三次上报被阻断 | P1 | 功能测试 | 运单仅完成第一次上报，第二次未完成 | 1.尝试开票并触发第三次上报 | 第二次未完成的运单 | UI:系统提示"请先完成第二次上报"；上报按钮不可见/置灰。数据:第三次上报接口调用被前置校验拦截 | | -| TC-TR-003 | 第三次上报 | 增值税发票验证失败→上报异常 | P1 | 功能测试 | 发票号码格式错误或与代码不匹配 | 1.触发第三次上报 2.查看结果 | 错误的发票号码/代码 | UI:上报状态"异常"(橙)；原因提示"增值税发票验证失败"及具体原因。数据:接口返回发票验证失败业务错误码；数据库记录异常状态 | | -| TC-TR-004 | 第三次上报 | 发票金额精度:价税合计保留2位小数四舍五入 | P2 | 功能测试 | 发票金额=12345.678元(超2位小数) | 1.触发第三次上报 2.查看列表发票金额 | 发票金额=12345.678 | UI:列表发票金额显示12,345.68(四舍五入)。数据:请求体invoiceAmount=12345.68，无浮点精度丢失 | | -| TC-TR-005 | 第三次上报 | 油气发票多条记录上报 | P2 | 功能测试 | 运单关联2条油气发票 | 1.触发第三次上报 2.查看详情弹窗油气发票区 | 2条油气发票记录 | UI:油气发票区展示2条记录各含托运单号和发票文件。数据:请求体油气发票数组length=2 | | -| TC-ETC-001 | ETC发票上传 | 税务抵扣完成后上传ETC发票(18字段/每张) | P1 | 功能测试 | 1.车辆完成高速运输 2.ETC发票已获取 3.税务抵扣完成 | 1.选运单 2.上传ETC发票信息 3.提交 | ETC发票完整18字段 | UI:上传成功状态"已上传"(绿)；列表含ETC发票号码/金额/税率/上传状态。数据:请求体含18字段；税额=发票金额×3% | 合TP-ETC-001,003 | -| TC-ETC-002 | ETC发票上传 | 税务抵扣未完成→上传被阻止 | P1 | 功能测试 | ETC发票存在但税务抵扣未完成 | 1.尝试上传ETC发票 | 抵扣未完成的ETC发票 | UI:系统提示"请先完成税务抵扣"；上传被阻止。数据:上传接口调用被前置校验拦截 | | -| TC-ETC-003 | ETC发票上传 | 税额计算:3%税率精度验证(1000元→30.00元) | P1 | 功能测试 | ETC发票金额1000.00元 | 1.上传1000元ETC发票 2.查看税额 | 发票金额=1000.00 | UI:税额显示30.00元。数据:taxAmount=1000.00×0.03=30.00，2位小数 | | -| TC-ETC-004 | ETC发票上传 | 税额计算:大额发票100万元→30000.00元 | P2 | 功能测试 | ETC发票金额1000000元 | 1.上传100万元ETC发票 2.查看税额 | 发票金额=1000000.00 | UI:税额显示30,000.00元。数据:taxAmount=1000000.00×0.03=30000.00，无精度问题 | | -| TC-ETC-005 | ETC发票上传 | ETC发票验证失败→上报异常提示检查发票 | P2 | 功能测试 | ETC发票号码/代码与实际不匹配 | 1.上传错误ETC发票 2.查看验证结果 | 错误的ETC发票号码/代码 | UI:状态"异常"(橙)；原因提示"ETC发票验证失败请检查发票信息"。数据:接口返回ETC发票验证失败 | | -| TC-AP-001 | 异常申诉 | 核验异常运单发起申诉（申诉原因+附件） | P1 | 功能测试 | 运单第二次上报核验异常(车辆轨迹合规异常) | 1.找到异常运单 2.点"申诉" 3.填原因:"实际路线因道路施工绕行" 4.上传附件(施工证明截图) 5.提交 | 申诉原因文本、路线施工证明截图 | UI:提交后提示"申诉已提交等待监管平台复核"；申诉状态变"申诉中"；列表新增申诉记录。数据:申诉表新增记录:申诉单号自动生成/异常项=车辆轨迹合规/原因已保存/附件已存储/状态=申诉中/时间=当前 | | -| TC-AP-002 | 异常申诉 | 申诉原因必填校验→空值拦截 | P2 | 功能测试 | 存在可申诉异常运单 | 1.点申诉 2.不填原因 3.直接提交 | 申诉原因为空 | UI:输入框标红或提示"请填写申诉原因"；提交按钮不响应或提示错误。数据:申诉接口未被调用；数据库无新记录 | | -| TC-AP-003 | 异常申诉 | 申诉状态流转:申诉中→申诉通过(监管复核通过) | P1 | 功能测试 | 已提交申诉(申诉中状态) | 1.等待监管平台复核通过 2.查看申诉记录 | 申诉中的记录 | UI:申诉状态变"申诉通过"(绿)；省平台反馈"复核通过"；原运单异常项消除或已解决。数据:申诉记录状态更新；省平台反馈时间/结果/意见已记录；关联运单核验状态更新 | | -| TC-AP-004 | 异常申诉 | 申诉状态流转:申诉中→申诉驳回→重新申诉 | P1 | 功能测试 | 申诉被监管平台驳回 | 1.查看驳回记录和原因 2.点"重新申诉" 3.补充材料修改原因 4.提交 | 驳回原因、补充材料 | UI:驳回记录显示"复核不通过"+反馈意见；"重新申诉"按钮可见；表单保留原内容可编辑；提交后状态变"申诉中"。数据:新申诉关联原单号；原记录保留不变；新申诉状态=申诉中 | | -| TC-AP-005 | 异常申诉 | 详情弹窗:时间线展示处理记录(申诉→驳回→重申诉→通过) | P2 | 功能测试 | 申诉记录有多次操作历史 | 1.点"详情" 2.查看处理记录区 | 完整申诉历史数据 | UI:处理记录时间线展示从早到晚；每条含操作人/时间/类型/内容；类型区分清晰(发起申诉/省平台反馈/重新申诉/复核通过)。数据:数据库操作日志完整 | | -| TC-AP-006 | 异常申诉 | 核验通过运单无申诉入口→越权防护 | P1 | 功能测试 | 运单核验状态为"通过" | 1.找到核验通过运单 2.查看操作列 3.尝试通过URL直接访问申诉接口 | 核验通过的运单 | UI:操作列不显示"申诉"按钮。数据:申诉接口返回"当前运单核验状态不允许申诉" | | -| TC-LOG-001 | 上报日志 | 多条件日志查询(上报阶段+结果+时间范围) | P2 | 功能测试 | 系统存在多条不同阶段日志 | 1.进入上报日志 2.选阶段=第二次上报 3.选结果=失败 4.设时间范围近7天 5.点查询 | 筛选条件组合 | UI:列表展示满足条件的日志含10个字段(序号/货源单号/运单号/托运单号/上报阶段/上报结果/接口URL/HTTP状态码/响应时间/上报时间)。数据:查询条件正确传递；返回数据与筛选一致 | | -| TC-LOG-002 | 上报日志 | 失败日志详情弹窗:完整请求/响应报文(JSON格式化) | P2 | 功能测试 | 存在一条失败的第二次上报日志 | 1.点失败日志"详情" 2.查看请求和响应报文 | 失败日志记录 | UI:弹窗展示完整请求报文(JSON格式化含所有字段)和响应报文(含错误码/错误信息)；报文可复制。数据:展示报文与实际上报接口请求/响应一致 | | -| TC-CM-001 | 通用跨模块 | 金额精度:多次计算无累积浮点误差 | P1 | 功能测试 | 运单合同金额=12345.67元 | 1.第一次上报看合同金额 2.第二次上报看总金额 3.第三次上报看发票金额 4.对比三次精度 | 合同金额=12345.67 | UI:所有金额显示2位小数千分位正确无精度丢失。数据:DB存DECIMAL(18,2)；接口返回2位小数字符串；计算无浮点误差 | 来源:风险矩阵+易漏场景 | -| TC-CM-002 | 通用跨模块 | 重复提交防抖:快速多次点击手动上传→仅一次请求 | P1 | 功能测试 | 存在上传失败运单 | 1.连续快速点击"手动上传"3次 2.等待结果 | 上传失败运单 | UI:按钮首次点击后变loading/置灰防重复点击；仅产生一次上报请求。数据:上报接口仅调用1次；上报日志仅1条记录 | 来源:易漏场景 | -| TC-CM-003 | 通用跨模块 | 未登录直接URL访问上报看板→拦截跳转登录 | P2 | 安全性测试 | 退出登录状态 | 1.清除登录态 2.地址栏直接输入看板URL 3.观察页面 | 看板URL | UI:重定向到登录页或显示"请先登录"；不展示上报数据。数据:上报API返回401 Unauthorized | | -| TC-CM-004 | 通用跨模块 | 权限隔离:司机账号(15188888888)无法访问上报管理 | P1 | 安全性测试 | 司机账号15188888888/88888888 | 1.司机登录管理端 2.尝试访问看板/申诉管理等页面 | 司机账号凭证 | UI:菜单无"安徽运八"入口；直接URL访问重定向或"无权限"；不展示上报数据。数据:上报API返回403 Forbidden | | -| TC-CM-005 | 通用跨模块 | 第一次上报与运单管理模块数据一致性 | P1 | 功能测试 | 运单在运单管理模块已有完整数据 | 1.记录运单管理模块关键字段 2.触发第一次上报 3.在详情弹窗核对 | 货源单号/运单号/托运单号/车牌号/司机姓名/托运方/货物/装货地址/卸货地址/运输里程 | UI:上报详情字段值与运单管理一致。数据:上报请求体值来源于运单管理DB记录，数据一致 | | -| TC-CM-006 | 通用跨模块 | 第二次上报资金流水与账户管理支付流水数据一致性 | P1 | 功能测试 | 运单已完成打款，支付流水号已知 | 1.在账户管理→支付流水查看打款数据 2.触发第二次上报 3.在上报详情核对资金流水 | 支付金额/流水号/支付时间/收款方 | UI:第二次上报详情中资金流水与账户管理模块一致。数据:上报请求体资金流水与支付流水表数据一致；流水号完全匹配 | | -| TC-CM-007 | 通用跨模块 | 司机信息上报(13字段)与司机审核模块数据一致性 | P1 | 功能测试 | 司机已在审核管理模块通过审核 | 1.记录司机审核模块司机信息 2.触发第一次上报 3.核对上报详情司机信息 | 司机姓名/身份证号/驾驶证号/从业资格证号/手机号等13字段 | UI:上报详情司机13字段与审核模块一致。数据:上报请求体driverInfo来源于司机审核表 | | -| TC-CM-008 | 通用跨模块 | 上报接口超时(>30s)→前端Loading+超时提示 | P2 | 功能测试 | 模拟上报接口响应超30秒 | 1.触发上报 2.观察前端表现 | 超时接口 | UI:按钮Loading状态(转圈/禁用)；超30秒后显示"上报超时请稍后查看结果"；不白屏不假死。数据:接口超时后后端异步处理或标记超时；DB状态=上传失败/原因=超时 | | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_DASH_001 | 平台端-监管上报-上报看板 | 验证看板按完整运单号精确搜索运单 | P0 | 功能测试 | 1. 使用super_admin账号登录管理端https://ybxcx.ynyun8.com:8000/admin；2. 系统中存在运单号YB202607130001的运单记录 | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入完整运单号"YB202607130001"；3. 点击搜索按钮或按回车键 | 运单号: YB202607130001 | 页面列表仅展示1条记录，运单号列显示"YB202607130001"（精确匹配）；数据库查询返回唯一记录，where条件为waybill_no='YB202607130001' | 对应TP-A-001 | +| AH_REPORT_DASH_002 | 平台端-监管上报-上报看板 | 验证看板按运单号模糊搜索匹配多条记录 | P0 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在运单号包含"YB20260713"前缀的多条运单（如YB202607130001、YB202607130002、YB202607130003） | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入"YB20260713"；3. 点击搜索 | 运单号部分字符: YB20260713 | 页面列表展示3条记录，所有运单号均包含"YB20260713"；数据库查询SQL使用LIKE '%YB20260713%'匹配，返回3条结果 | 对应TP-A-001 | +| AH_REPORT_DASH_003 | 平台端-监管上报-上报看板 | 验证看板按不存在的单号搜索显示空结果 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端 | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入不存在的单号"NOTEXIST999"；3. 点击搜索 | 运单号: NOTEXIST999 | 页面列表显示空状态，提示"未找到匹配数据"或空结果占位图；数据库查询返回0条记录；页面不出现控制台报错 | 对应TP-A-001 | +| AH_REPORT_DASH_004 | 平台端-监管上报-上报看板 | 验证看板按"第一次上报"阶段筛选运单 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在不同上报阶段的运单（至少含1条第一次上报、1条第二次上报的运单） | 1. 进入"监管上报-上报看板"页面，默认为"全部"；2. 点击上报阶段下拉框，选择"第一次上报"；3. 观察列表数据 | 筛选条件: 第一次上报 | 列表仅展示上报阶段为"第一次上报"的运单；每条记录的上报阶段列均为"第一次上报"；数据库查询添加where report_stage='first'过滤条件；总条目数与数据库中第一次上报运单数一致 | 对应TP-A-002 | +| AH_REPORT_DASH_005 | 平台端-监管上报-上报看板 | 验证看板按"异常"核验状态筛选运单 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在核验状态为"通过"和"异常"的运单 | 1. 进入"监管上报-上报看板"页面；2. 点击核验状态下拉框，选择"异常"；3. 观察列表数据 | 筛选条件: 核验状态=异常 | 列表仅展示核验状态为"异常"（橙色标签）的运单；所有"通过"的运单被过滤；数据库查询添加where verification_status='abnormal'条件 | 对应TP-A-003 | +| AH_REPORT_DASH_006 | 平台端-监管上报-上报看板 | 验证看板按"申诉中"申诉状态筛选运单 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在申诉状态为"申诉中"的运单至少1条 | 1. 进入"监管上报-上报看板"页面；2. 点击申诉状态下拉框，选择"申诉中"；3. 观察列表数据并与全部列表对比 | 筛选条件: 申诉状态=申诉中 | 列表仅展示申诉状态为"申诉中"的运单；申诉状态列标签显示"申诉中"且颜色与需求定义一致；数据库查询添加where appeal_status='in_progress'条件 | 对应TP-A-004；⚠️ 待确认: 原型看板申诉状态下拉值为"未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回"，与需求不一致 | +| AH_REPORT_DASH_007 | 平台端-监管上报-上报看板 | 验证看板组合筛选—第二次上报+异常+申诉中+运单号模糊搜索 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 数据库中存在满足组合条件的运单（第二次上报、核验异常、申诉中、运单号含"YB2026"） | 1. 进入"监管上报-上报看板"页面；2. 上报阶段选"第二次上报"；3. 核验状态选"异常"；4. 申诉状态选"申诉中"；5. 运单号输入"YB2026"；6. 点击搜索 | 组合条件: 第二次上报+异常+申诉中; 运单号模糊: YB2026 | 列表仅展示同时满足4个条件的运单；每个条件都在数据库SQL中体现（多WHERE条件AND组合）；空结果时显示"未找到匹配数据"；切换任一筛选条件不丢失运单号搜索框中已输入的关键字 | 对应TP-A-005 | +| AH_REPORT_DASH_008 | 平台端-监管上报-上报看板 | 验证看板导出当前筛选结果为Excel文件 | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板列表中有≥20条运单数据 | 1. 进入"监管上报-上报看板"页面；2. 设置筛选条件（如上报阶段=第一次上报）；3. 点击"导出"按钮；4. 等待文件下载完成；5. 打开下载的Excel文件 | 筛选: 第一次上报 | 浏览器触发文件下载，文件名为.xlsx格式；Excel文件可正常打开，表头包含14个列表字段（货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、申诉状态、异常项、货物名称、合同金额、最新核验时间、操作）；导出数据行数与筛选结果一致；导出过程中页面不卡死、不超时 | 对应TP-A-006 | +| AH_REPORT_DASH_009 | 平台端-监管上报-上报看板 | 验证看板大数据量导出不超时不OOM | P2 | 性能测试 | 1. 使用super_admin账号登录管理端；2. 数据库中存在≥2000条运单记录 | 1. 进入"监管上报-上报看板"页面；2. 选择"全部"筛选条件；3. 点击"导出"按钮；4. 记录从点击到下载完成的时间 | 导出全部数据, 约2000+条 | 导出在60秒内完成下载（不超时）；导出的Excel文件包含全部数据行，无截断；后台服务内存使用率未显著增长（无OOM）；导出过程中看板页面仍可正常操作 | 对应TP-A-006 | +| AH_REPORT_DASH_010 | 平台端-监管上报-上报看板 | 验证看板重置按钮恢复所有查询条件至默认值 | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 已在上报阶段选择"第二次上报"、核验状态选择"异常"、运单号输入"YB2026" | 1. 进入"监管上报-上报看板"页面；2. 点击"重置"按钮；3. 观察页面各筛选条件和列表数据 | 重置前条件: 第二次上报+异常+YB2026 | 模糊搜索输入框清空为空白；所有下拉筛选恢复为"全部"；列表刷新展示默认全部运单数据（初始状态）；分页回到第1页；数据库查询恢复为无过滤条件的默认查询 | 对应TP-A-007 | +| AH_REPORT_DASH_011 | 平台端-监管上报-上报看板 | 验证看板列表展示14个字段且顺序与需求一致 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在至少1条完整运单记录 | 1. 进入"监管上报-上报看板"页面；2. 查看列表表头和第一条数据的各列内容；3. 对比需求文档中的字段顺序 | 查看运单YB202607130001 | 列表14个字段顺序为: 货源单号→运单号→托运单号→车牌号→司机姓名→托运方名称→上报阶段→核验状态→申诉状态→异常项→货物名称→合同金额→最新核验时间→操作；合同金额列保留2位小数（如¥10,000.00）；最新核验时间为YYYY-MM-DD HH:mm:ss格式；异常项为空时显示"-"而非"null"或"undefined" | 对应TP-A-008 | +| AH_REPORT_DASH_012 | 平台端-监管上报-上报看板 | 验证看板状态标签颜色—蓝色(上传中)、绿色(已上传)、红色(上传失败)、橙色(异常) | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在4种上报状态的运单各1条 | 1. 进入"监管上报-上报看板"页面；2. 找到上报状态为"上传中"的运单，查看标签颜色；3. 找到"已上传"运单，查看标签颜色；4. 找到"上传失败"运单，查看标签颜色；5. 找到"异常"运单，查看标签颜色 | 运单1: 上传中; 运单2: 已上传; 运单3: 上传失败; 运单4: 异常 | "上传中"标签显示蓝色背景/文字；"已上传"标签显示绿色背景/文字；"上传失败"标签显示红色背景/文字；"异常"标签显示橙色背景/文字；状态切换时标签颜色即时刷新不闪烁；申诉状态标签（申诉中/申诉通过/申诉驳回）颜色各自区分清晰 | 对应TP-A-009 | +| AH_REPORT_DASH_013 | 平台端-监管上报-上报看板 | 验证看板操作列—异常运单显示申诉按钮、所有运单显示详情按钮 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在核验通过的运单1条和核验异常的运单1条 | 1. 进入"监管上报-上报看板"页面；2. 查看核验通过运单的操作列按钮；3. 查看核验异常运单的操作列按钮；4. 点击异常运单的"申诉"按钮 | 通过运单: YB202607130001; 异常运单: YB202607130002 | 核验通过运单的操作列显示"详情"和"进度"按钮，不显示"申诉"按钮；核验异常运单的操作列显示"申诉""详情""进度"三个按钮；点击"申诉"按钮后页面路由跳转至申诉页面，URL携带正确的运单ID参数；点击"详情"按钮弹出详情弹窗，展示该运单的完整上报信息 | 对应TP-A-010 | +| AH_REPORT_DASH_014 | 平台端-监管上报-上报看板 | 验证看板详情弹窗—建单信息分组13字段完整 | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板列表中有可查看详情的运单YB202607130001 | 1. 进入"监管上报-上报看板"页面；2. 点击运单YB202607130001操作列的"详情"按钮；3. 在弹窗中查看"建单信息"分组的所有字段 | 运单号: YB202607130001 | 建单信息分组展示13个字段: 上游企业委托运输单号、本运单单号、托运人建单时间、网络货运经营者名称、统一社会信用代码、道路运输经营许可证编号、业务类型代码、运输组货方式代码、司机接单时间、司机起运时间、承运合同编号（必选）、委托合同编号（可选）、运输里程（可选）；必选字段均有值；可选字段委托合同编号和运输里程为空时显示"-"；各字段格式与接口规范一致 | 对应TP-A-011 | +| AH_REPORT_DASH_015 | 平台端-监管上报-上报看板 | 验证看板详情弹窗—各子对象分组字段完整(托运人/收货方/司机/车辆/货物) | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板列表中有运单YB202607130001包含完整的子对象信息 | 1. 进入"监管上报-上报看板"页面；2. 点击运单YB202607130001的"详情"按钮；3. 依次展开托运人信息、收货方信息、司机信息、车辆信息、货物信息分组 | 运单号: YB202607130001; 司机: 15188888888 | 托运人信息7字段完整（含统一社会信用代码18位格式校验）；收货方信息5字段完整（身份证号如适用需脱敏展示）；司机信息13字段完整（从业资格证有效期起止日期格式正确）；车辆信息19字段完整（VIN码17位正确展示）；货物信息支持多条记录展开，每条含货物名称、货物类型代码、货物量、计量单位；可选字段为空时显示"-" | 对应TP-A-011 | +| AH_REPORT_DASH_016 | 平台端-监管上报-上报看板 | 验证看板空数据状态展示友好占位提示 | P3 | 易用性测试 | 1. 使用super_admin账号登录管理端；2. 选择一个筛选条件组合确保结果为0条（如运单号输入"ZZZZZZZZZZ"） | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框输入"ZZZZZZZZZZ"；3. 点击搜索 | 运单号: ZZZZZZZZZZ | 列表区域显示友好空状态占位图/文，不显示空白表格；有明确文字提示"未找到匹配数据"或类似文案；浏览器开发者工具Console无报错；页面无崩溃或白屏 | 对应TP-A-012 | +| AH_REPORT_DASH_017 | 平台端-监管上报-上报看板 | 验证看板分页功能—翻页数据不重复不遗漏 | P3 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板中有超过20条运单（默认每页20条） | 1. 进入"监管上报-上报看板"页面，记录第1页的运单号列表；2. 点击"下一页"进入第2页；3. 记录第2页的运单号列表；4. 对比两页数据；5. 查看分页组件显示的总条数 | 每页20条 | 第1页和第2页的运单号无重复；第2页首条数据不是第1页已出现的数据；切换每页条数（如50条/页）后分页重新计算正确；分页组件显示的总条数与数据库COUNT查询结果一致；数据按最新核验时间倒序排列（最近核验的在最前面） | 对应TP-A-013 | +| AH_REPORT_DASH_018 | 平台端-监管上报-上报看板 | 验证不同角色看板权限—运营可见全部/财务可见打款字段/司机不可见平台端看板 | P1 | 安全性测试 | 1. 准备super_admin账号(运营)、财务账号、车队长账号13113113113、司机账号15188888888；2. 系统中存在运单数据 | 1. 使用super_admin登录，进入看板，验证可见全部运单和全部字段；2. 使用财务账号登录，进入看板，验证可见运单范围和打款相关字段；3. 使用车队长13113113113登录司机端，验证是否有看板入口；4. 使用司机15188888888登录司机端，验证是否有看板入口 | 运营: super_admin; 财务: finance_user; 车队长: 13113113113/88888888; 司机: 15188888888/88888888 | super_admin可见全部运单和全部14个字段；财务可见运单但打款金额/付款方式/收款账号类型等字段可见；车队长登录司机端后无"监管上报-上报看板"菜单入口，直接URL访问被拦截返回403；司机登录司机端后同样无看板入口，越权访问被拦截并记录审计日志 | 对应TP-A-014 | -> 用例总数: 53 (P0:7 / P1:26 / P2:20) +--- + +## 模块B: 第一次上报-装货完成 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_R1_001 | 平台端-监管上报-第一次上报 | 验证装货完成后自动触发第一次上报且全部子对象数据完整 | P0 | 功能测试 | 1. 使用司机账号15188888888登录司机端APP；2. 存在一条安徽税源地(provinceCode=34)的运单YB202607130001，状态为"待装货"；3. 运单包含完整的托运人、收货方、司机、车辆、货物信息 | 1. 司机到达装货地，上传装货照片和资料；2. 司机在APP端点击"确认装货完成"；3. 等待系统自动触发第一次上报；4. 使用super_admin登录管理端，进入"监管上报-第一次上报"列表查看该运单上报状态 | 运单号: YB202607130001; 司机: 15188888888; 装货地省份代码: 34 | 司机端提示"装货完成，上报已提交"；管理端第一次上报列表中出现该运单记录，上报状态为"上传中"（蓝色标签），随后变为"已上传"（绿色标签）；上报请求JSON包含全部7个子对象(建单信息/托运人/收货方/司机/车辆/货物/保险)；数据库report_record表status字段从0变为1，上报时间字段非空 | 对应TP-B-001 | +| AH_REPORT_R1_002 | 平台端-监管上报-第一次上报 | 验证非安徽税源地运单(云南=28)装货完成后不触发第一次上报 | P0 | 功能测试 | 1. 使用司机账号15188888888登录司机端APP；2. 存在一条云南税源地(provinceCode=28)的运单YB202607130002，状态为"待装货" | 1. 司机完成装货并点击"确认装货完成"；2. 检查管理端"监管上报-第一次上报"列表；3. 检查系统日志是否有上报请求记录 | 运单号: YB202607130002; 省份代码: 28(云南) | 管理端第一次上报列表中不出现该运单记录；系统日志中无该运单的上报接口调用记录；运单状态正常流转为"运输中"，不受上报模块影响；无任何错误日志或异常告警产生 | 对应TP-B-002 | +| AH_REPORT_R1_003 | 平台端-监管上报-第一次上报 | 验证安徽税源地运单(省份代码=34)触发上报，其他省份不触发 | P0 | 功能测试 | 1. 准备安徽(34)、云南(28)、四川(51)税源地的运单各1条；2. 三条运单状态均为"待装货" | 1. 分别对三条运单确认装货完成；2. 进入管理端第一次上报列表查看；3. 查询数据库report_record表 | 安徽运单: provinceCode=34; 云南运单: provinceCode=28; 四川运单: provinceCode=51 | 仅安徽(34)运单在第一次上报列表中出现，上报状态正常更新；云南(28)和四川(51)运单均不在列表中；数据库report_record表仅新增1条记录，province_code=34 | 对应TP-B-002; TP-B-004 | +| AH_REPORT_R1_004 | 平台端-监管上报-第一次上报 | 验证第一次上报建单信息必选字段缺失时上报被拒绝并明确提示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 构造一条建单信息中"承运合同编号"为空的运单YB202607130003 | 1. 触发该运单装货完成事件（模拟或真实操作）；2. 查看第一次上报返回结果；3. 查看上报日志中的错误信息 | 运单号: YB202607130003; 缺失字段: 承运合同编号 | 上报接口返回错误，提示"必选字段承运合同编号不能为空"或类似明确消息；上报状态标记为"上传失败"（红色标签）；上报日志中记录该次失败请求，包含请求体和错误响应体；运单状态不会错误地标记为"已上传" | 对应TP-B-003 | +| AH_REPORT_R1_005 | 平台端-监管上报-第一次上报 | 验证第一次上报统一社会信用代码格式校验（非18位时拒绝） | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 构造一条运单，托运人统一社会信用代码为"123456"（6位无效格式） | 1. 触发该运单装货完成事件；2. 查看上报接口返回；3. 查看上报日志 | 运单号: YB202607130004; 信用代码: 123456(无效) | 上报接口返回校验错误，提示"统一社会信用代码格式不正确，需为18位"；上报状态标记为"上传失败"；不会错误地将无效代码上报至监管平台 | 对应TP-B-003 | +| AH_REPORT_R1_006 | 平台端-监管上报-第一次上报 | 验证第一次上报中司机信息省份代码为安徽=34（非云南=28） | P0 | 功能测试 | 1. 使用super_admin登录管理端；2. 准备一条安徽税源地(34)的完整运单YB202607130001 | 1. 触发的第一次上报完成后；2. 在上报日志中查看该次上报的完整请求JSON；3. 定位司机信息(driverInfo)中的provinceCode字段值 | 运单号: YB202607130001; 期望省份代码: 34 | 请求JSON中driverInfo.provinceCode="34"；不会出现值"28"；装货地行政区划代码前2位也为"34"（安徽省代码340000）；数据库/Redis/配置文件中无硬编码省份代码28 | [AI修正: 历史缺陷防御] - BUG-202607-04 | +| AH_REPORT_R1_007 | 平台端-监管上报-第一次上报 | 验证第一次上报失败后第二次上报接口被拒绝并返回错误码"前置上报未完成" | P0 | 功能测试 | 1. 运单YB202607130005第一次上报状态为"上传失败"（3次重试均失败）；2. 财务已完成打款（触发第二次上报的条件已满足） | 1. 通过API直接调用第二次上报接口（或模拟打款完成回调触发）；2. 查看接口返回的HTTP状态码和错误消息 | 运单号: YB202607130005 | 接口返回错误码（如HTTP 400或业务错误码"PRE_STAGE_NOT_COMPLETED"），错误消息包含"前置上报未完成"或"请先完成第一次上报"；第二次上报列表中该运单上报状态未变更，不会出现"上传中"或"已上传"；数据库report_record表无第二次上报的新记录 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R1_008 | 平台端-监管上报-第一次上报 | 验证第一次上报自动重试3次全部失败后第三次上报同样被拒绝 | P0 | 功能测试 | 1. 运单YB202607130006第一次上报3次重试全部失败；2. 第二次上报也未完成 | 1. 通过API直接调用第三次上报接口；2. 查看接口返回 | 运单号: YB202607130006 | 接口返回错误码，明确标识"前置上报（第一次）未完成"；后端通过查询运单上报状态表(如report_status)做校验，非仅依赖前端布尔值；第三次上报列表无该运单记录 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R1_009 | 平台端-监管上报-第一次上报 | 验证第一次上报成功后监管平台核验通过时自动调用修改字段接口 | P1 | 功能测试 | 1. 运单YB202607130001第一次上报成功且状态为"已上传"；2. 模拟监管平台返回核验通过 | 1. 等待或模拟监管平台核验通过回调；2. 查看上报日志中是否有"修改第一次上报部分字段"的接口调用记录；3. 查看修改后的字段值 | 运单号: YB202607130001; 实际运输里程: 158.5km（装货后变化值） | 上报日志中出现"修改字段"接口调用记录；修改的字段包含实际运输里程等装货后变化字段；修改成功后第一次上报状态仍保持"已上传"（绿色）；若修改接口调用失败，有重试和告警机制 | 对应TP-B-006 | +| AH_REPORT_R1_010 | 平台端-监管上报-第一次上报 | 验证第一次上报失败后自动重试最多3次且间隔递增 | P1 | 功能测试 | 1. 运单YB202607130007第一次上报时模拟监管平台返回失败 | 1. 触发第一次上报；2. 监控上报日志中的重试记录和时间间隔；3. 等待3次重试全部完成 | 运单号: YB202607130007; 重试间隔: 5s/15s/30s（参考值） | 第1次上报失败后自动触发第2次（间隔约5s）；第2次失败后触发第3次（间隔约15s）；第3次失败后触发第4次（即总共3次重试，间隔约30s）；3次重试全部失败后上报状态变为"上传失败"（红色标签），停止重试；上报日志中每1次请求（含重试）均有独立日志记录 | 对应TP-B-007 | +| AH_REPORT_R1_011 | 平台端-监管上报-第一次上报 | 验证第一次上报3次重试全部失败后通知运营人员 | P1 | 功能测试 | 1. 运单YB202607130008第一次上报3次重试均失败；2. super_admin账号可接收站内信 | 1. 等待3次重试全部失败；2. 使用super_admin登录管理端，查看站内信/消息通知；3. 点击通知中的链接 | 运单号: YB202607130008; 失败原因: 监管平台连接超时 | super_admin收到站内信通知，标题含"上报失败"标记；通知内容包含运单号YB202607130008、失败原因"连接超时"、失败时间；点击通知中的链接可直接跳转到该运单对应的上报详情页 | 对应TP-B-008 | +| AH_REPORT_R1_012 | 平台端-监管上报-第一次上报 | 验证上传失败状态下运营人员可点击手动上传按钮重新发起上报 | P1 | 功能测试 | 1. 运单YB202607130009上报状态为"上传失败"（红色标签）；2. 使用super_admin登录管理端 | 1. 进入"监管上报-第一次上报"列表；2. 找到YB202607130009，查看操作列；3. 点击"手动上传"按钮；4. 确认上传；5. 等待上传完成 | 运单号: YB202607130009 | 操作列显示"手动上传"按钮（仅上传失败状态可见）；点击后发起新的上报请求；上传成功后状态从"上传失败"（红色）变为"已上传"（绿色）；手动上传记录出现在上报日志中，标注操作人为"super_admin" | 对应TP-B-009 | +| AH_REPORT_R1_013 | 平台端-监管上报-第一次上报 | 验证自动重试期间点击手动上传时系统提示"上报处理中"并拒绝重复提交 | P0 | 功能测试 | 1. 运单YB202607130010第一次上报正在自动重试中（第1次已失败，第2次进行中）；2. 使用super_admin登录管理端 | 1. 进入第一次上报列表，找到该运单；2. 等待自动重试进行中时，快速点击"手动上传"按钮 | 运单号: YB202607130010 | 前端弹出提示"上报处理中，请勿重复操作"或按钮被置灰不可点击；后端返回"上报处理中"错误（分布式锁检测到正在进行中的上报）；数据库report_record表中该运单不会产生第2条上报记录；最终仅有1条上报记录（自动重试完成后产生） | [AI修正: 历史缺陷防御] - BUG-202607-02 | +| AH_REPORT_R1_014 | 平台端-监管上报-第一次上报 | 验证同一运单同一阶段快速连续点击手动上传仅发起1次请求 | P0 | 功能测试 | 1. 运单YB202607130011上报状态为"上传失败"；2. 使用super_admin登录管理端 | 1. 进入第一次上报列表；2. 快速连续点击"手动上传"按钮5次（模拟前端未做防抖的情况或快速双击）；3. 查看上报日志中实际发出的请求次数 | 运单号: YB202607130011; 快速点击5次 | 上报日志中仅记录1次上报请求（前端防抖+后端幂等键控制）；数据库report_record表仅产生1条新的上报记录；后端分布式锁或唯一约束（如运单号+阶段号）防止并发插入重复记录 | [AI修正: 历史缺陷防御] - BUG-202607-02 | +| AH_REPORT_R1_015 | 平台端-监管上报-第一次上报 | 验证第一次上报接口超时(>30s)后转为上传失败并触发重试 | P1 | 功能测试 | 1. 运单YB202607130012准备上报；2. 通过工具模拟监管平台接口响应延迟>30秒 | 1. 触发第一次上报；2. 观察前端页面Loading状态；3. 等待超时后的系统处理 | 运单号: YB202607130012; 超时阈值: 30s | 前端页面显示Loading加载状态并持续至超时；超时后上报状态变为"上传失败"（红色标签）；前端页面超时后有友好提示"上报超时，系统将自动重试"；系统自动触发第1次重试；数据库report_record表中记录超时状态 | 对应TP-B-015 | +| AH_REPORT_R1_016 | 平台端-监管上报-第一次上报 | 验证弱网环境(高延迟高丢包)下第一次上报重试机制正常工作 | P2 | 功能测试 | 1. 通过Charles/Fiddler或网络模拟工具设置网络延迟2000ms、丢包率30%；2. 运单YB202607130013待上报 | 1. 在弱网条件下触发第一次上报；2. 观察上报请求发送和响应情况；3. 等待重试或恢复 | 运单号: YB202607130013; 网络延迟: 2000ms; 丢包率: 30% | 请求发送成功但响应延迟时不立即判定失败（超时阈值30s）；弱网恢复后若重试成功则状态正常流转为"已上传"；断网时上报请求发送失败的提示友好明确；不论弱网还是正常网络，数据不会出现不一致或重复 | 对应TP-B-016 | +| AH_REPORT_R1_017 | 平台端-监管上报-第一次上报 | 验证10个运单同时装货完成时并发上报互不干扰 | P2 | 性能测试 | 1. 准备10条安徽税源地(34)的运单YB202607130014~YB202607130023，状态均为"待装货" | 1. 通过脚本同时触发10条运单的装货完成事件；2. 监控数据库和上报日志；3. 验证每条运单的上报状态 | 10条运单同时装货完成 | 10条运单各自独立触发上报，无相互阻塞；数据库无死锁(deadlock)异常；上报日志中每条运单独立记录其上报请求和响应；每条运单的上报状态独立正确更新 | 对应TP-B-017 | +| AH_REPORT_R1_018 | 平台端-监管上报-第一次上报 | 验证第一次上报可选字段（委托合同编号/运输里程/挂车牌照号等）为空时正常上报 | P3 | 功能测试 | 1. 准备一条运单YB202607130024，可选字段全部留空：委托合同编号、运输里程、挂车牌照号、行驶证档案编号、道路运输证有效期起/至、保险单号、保险公司名称 | 1. 触发该运单装货完成事件；2. 查看上报结果；3. 查看上报请求JSON和详情弹窗 | 运单号: YB202607130024; 可选字段全为空 | 上报接口不报错，上报成功；请求JSON中可选字段值为null或不传均可正常处理；管理端详情弹窗中可选字段显示"-"而非"null"或"undefined" | 对应TP-B-018 | +| AH_REPORT_R1_019 | 平台端-监管上报-第一次上报 | 验证运单包含1条货物记录时正常上报 | P3 | 功能测试 | 1. 准备运单YB202607130025，仅含1条货物：货物名称"钢材"、货物类型代码"01"、货物量"10.5"、计量单位"吨" | 1. 触发装货完成；2. 查看上报请求JSON中goodsInfos数组；3. 查看详情弹窗货物信息展示 | 运单号: YB202607130025; 货物: 钢材 10.5吨 | goodsInfos数组包含1个元素，4个字段完整；详情弹窗中货物信息分组正确展示1条记录 | 对应TP-B-019 | +| AH_REPORT_R1_020 | 平台端-监管上报-第一次上报 | 验证运单包含5条货物记录时各货物独立完整上报 | P3 | 功能测试 | 1. 准备运单YB202607130026，含5条货物记录：钢材10.5吨、水泥20吨、砂石15吨、砖块5000块、木材8立方 | 1. 触发装货完成；2. 查看上报请求JSON中goodsInfos数组长度和内容；3. 查看详情弹窗中多条货物的展示 | 运单号: YB202607130026; 货物: 5条 | goodsInfos数组包含5个元素；每条货物独立完整，互不影响；详情弹窗中货物信息支持展开/折叠展示5条记录；每条货物名称、类型代码、货物量、计量单位均正确 | 对应TP-B-019 | +| AH_REPORT_R1_021 | 平台端-监管上报-第一次上报 | 验证第一次上报业务类型代码和运输组货方式代码为有效枚举值 | P1 | 功能测试 | 1. 准备运单YB202607130027，业务类型代码为"1"(普通货运)、运输组货方式代码为"10"(道路货运) | 1. 触发装货完成上报；2. 查看上报请求JSON中waybillInfo的businessTypeCode和transportGroupModeCode字段值；3. 模拟提交无效枚举值（如"99"），验证拒绝 | 运单号: YB202607130027; businessTypeCode: 1; transportGroupModeCode: 10 | 有效枚举值上报成功；无效枚举值（如businessTypeCode="99"）上报时接口返回校验错误，明确提示"业务类型代码无效"；不会将无效枚举值上报至监管平台 | 对应TP-B-003 | +| AH_REPORT_R1_022 | 平台端-监管上报-第一次上报 | 验证第一次上报详情弹窗—异常信息分组展示核验状态/异常原因/异常时间/处理状态 | P2 | 功能测试 | 1. 运单YB202607130028第一次上报核验状态为"异常"；2. 使用super_admin登录管理端 | 1. 进入第一次上报列表，点击运单YB202607130028的"详情"按钮；2. 查看弹窗中"异常信息"分组的4个字段 | 运单号: YB202607130028; 异常原因示例: 司机资质核验不通过 | 异常信息分组包含: 核验状态（显示"异常"）、异常原因（如"司机从业资格证已过期"）、异常时间（显示实际核验时间）、处理状态（如"未申诉"）；核验通过时异常原因为空 | 对应TP-B-013 | +| AH_REPORT_R1_023 | 平台端-监管上报-第一次上报 | 验证第一次上报状态标签颜色：上传中=蓝色、已上传=绿色、上传失败=红色、异常=橙色 | P2 | 功能测试 | 1. 准备4条运单各处于不同上报状态 | 1. 进入第一次上报列表；2. 依次查看4种状态运单的标签颜色 | 运单A: 上传中; 运单B: 已上传; 运单C: 上传失败; 运单D: 异常 | 上传中=蓝色标签+加载动画；已上传=绿色标签；上传失败=红色标签；异常=橙色标签；状态切换时标签颜色即时更新不闪烁 | 对应TP-B-010 | +| AH_REPORT_R1_024 | 平台端-监管上报-第一次上报 | 验证第一次上报列表14个字段完整展示且顺序正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 第一次上报列表中有至少1条完整记录 | 1. 进入"监管上报-第一次上报"列表；2. 查看列表表头和第一条数据的所有列内容；3. 验证每个字段的展示格式 | 运单号: YB202607130001; 运输里程: 350km; 合同编号: HT202607001 | 列表展示14个字段: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/业务类型/货物名称/装货地址/卸货地址/运输里程/合同编号/上报状态/操作；业务类型与数据字典中枚举值一致；装货地址和卸货地址完整展示（省市区+详细地址）；运输里程带单位km；上报状态标签颜色符合规范（上传中=蓝色/已上传=绿色/上传失败=红色/异常=橙色）；列表按上报时间倒序排列 | 对应TP-B-020；[AI修正: 覆盖缺口补充] | +| AH_REPORT_R1_025 | 平台端-监管上报-第一次上报 | 验证未上传委托合同（框架）时第一次上报被拒绝并提示需要先上传委托合同 | P0 | 功能测试 | 1. 系统中存在一条安徽税源地(34)的运单YB202607130092；2. 该运单对应的货主尚未上传委托合同（框架） | 1. 触发运单装货完成事件；2. 查看第一次上报的返回结果；3. 查看上报日志中的错误信息 | 运单号: YB202607130092; 委托合同状态: 未上传 | 第一次上报接口返回错误，消息明确提示"请先上传委托合同（框架）"或类似文案；上报状态标记为"上传失败"（红色标签）；上报日志中记录该次失败，错误原因明确；上传委托合同后重试第一次上报可成功 | 对应TP-B-021；[技术方案] showdoc文档委托合同前置条件 | +| AH_REPORT_R1_026 | 平台端-监管上报-第一次上报 | 验证委托合同（框架）支持关联多家托运企业—enterpriseList多企业列表上传 | P1 | 功能测试 | 1. 使用super_admin登录管理端或通过API；2. 准备3家货主企业信息（统一社会信用代码+企业名称） | 1. 调用委托合同（框架）上传接口POST /api/dataUpload/mandateContractFrame；2. 传入enterpriseList（含3家企业）、contract_number、expire_time；3. 查看接口返回；4. 再传入unified_social_credit_identifier（单企业）+enterpriseList（多企业）同时传值 | 合同编号: FRAME202607001; enterpriseList: [企业A(9134XXXXXXXXXX01), 企业B(9134XXXXXXXXXX02), 企业C(9134XXXXXXXXXX03)] | enterpriseList仅传时上报成功，3家企业均关联至该框架合同；同时传unified_social_credit_identifier和enterpriseList时默认取单企业（enterpriseList被忽略）；上传后第一次上报时consignorInfo中frameContractNumber与该框架合同编号一致即可通过 | 对应TP-B-022；[技术方案] showdoc文档mandateContractFrame | + +--- + +## 模块C: 第二次上报-打款完成 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_R2_001 | 平台端-监管上报-第二次上报 | 验证财务打款完成后自动触发第二次上报且包含资金流水和车辆轨迹信息 | P0 | 功能测试 | 1. 运单YB202607130001已完成第一次上报且状态为"已上传"；2. 财务在账户管理模块对该运单执行打款操作，金额¥10,000.00 | 1. 财务完成打款操作；2. 系统收到打款完成回调；3. 进入管理端"监管上报-第二次上报"列表查看 | 运单号: YB202607130001; 打款金额: ¥10,000.00; 付款方式: 光大银行 | 第二次上报列表中新增该运单记录，上报状态从"上传中"变为"已上传"（绿色标签）；上报请求包含运单信息+资金流水信息+车辆轨迹信息三个模块；数据库report_record表新增第二次上报记录，stage=2 | 对应TP-C-001 | +| AH_REPORT_R2_002 | 平台端-监管上报-第二次上报 | 验证第二次上报资金流水数据来源于支付流水表（非运单缓存） | P0 | 功能测试 | 1. 运单YB202607130001合同金额¥10,000.00；2. 支付流水表实际打款金额¥10,000.00；3. 财务已打款完成 | 1. 触发第二次上报；2. 查询上报日志中的请求JSON；3. 对比请求中的金额与运单表合同金额、支付流水表打款金额；4. 检查数据库查询SQL日志确认数据来源 | 运单号: YB202607130001; 合同金额: ¥10,000.00; 支付流水实际打款: ¥10,000.00 | 上报数据中的金额与支付流水表实际打款金额¥10,000.000完全一致；数据库查询SQL日志显示数据源为payment_flow表，非waybill表或Redis缓存；金额保留3位小数（如10000.000），无精度丢失 | [AI修正: 历史缺陷防御] - BUG-202607-03；[技术方案] 第二次上报金额精度3位小数 | +| AH_REPORT_R2_003 | 平台端-监管上报-第二次上报 | 验证财务修改打款金额后第二次上报使用最新金额（非缓存合同金额），精度3位小数 | P0 | 功能测试 | 1. 运单YB202607130001合同金额¥10,000.000；2. 财务在账户管理模块调账将打款金额修改为¥9,500.000；3. 财务执行打款 | 1. 财务修改打款金额（¥10,000.000→¥9,500.000）；2. 财务完成打款；3. 触发第二次上报；4. 查看上报请求中的金额字段 | 运单号: YB202607130001; 合同金额: ¥10,000.000; 修改后打款金额: ¥9,500.000 | 上报请求中的金额为¥9,500.000（修改后的值，3位小数），非¥10,000.000（合同金额）；上报日志中可溯源金额来源为支付流水表；不会使用装货完成时缓存的合同金额 | [AI修正: 历史缺陷防御] - BUG-202607-03；[技术方案] 第二次上报金额精度3位小数 | +| AH_REPORT_R2_004 | 平台端-监管上报-第二次上报 | 验证第二次上报列表17个字段完整且收款账号类型标签颜色正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 第二次上报列表中有至少2条数据（一条个人账户、一条对公账户） | 1. 进入"监管上报-第二次上报"列表；2. 查看列表表头和第一条数据的各列内容；3. 查看收款账号类型列的标签颜色 | 运单A: 个人账户(司机银行卡); 运单B: 对公账户(企业账号) | 列表展示: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/承运运费/总金额/付款方式/付款时间/收款人/收款账号/收款账号类型/核验状态/异常项/上报状态/操作；承运运费和总金额保留**3位小数**（如¥10,000.000）；付款时间为实际财务打款时间；个人账户显示蓝色标签，对公账户显示绿色标签 | 对应TP-C-004; TP-C-005；[技术方案] 第二次上报金额精度3位小数 | +| AH_REPORT_R2_005 | 平台端-监管上报-第二次上报 | 验证运单重复核验—首次上报的运单核验通过 | P0 | 功能测试 | 1. 运单YB202607130001为首次进行第二次上报，此前未在任何阶段重复上报 | 1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项 | 运单号: YB202607130001(首次上报) | 核验状态标记为"通过"（绿色标签）；异常项列中无"运单重复核验"异常记录；监管平台返回的核验结果中duplicateCheck=pass；数据库运单核验记录表verification_result中duplicate_check_status='pass' | 对应TP-C-006 | +| AH_REPORT_R2_006 | 平台端-监管上报-第二次上报 | 验证运单重复核验—重复上报检测到异常并标注异常项 | P0 | 功能测试 | 1. 运单YB202607130001已成功完成第二次上报和核验；2. 模拟或真实触发该运单的第二次重复上报 | 1. 通过API再次调用第二次上报接口（使用同一运单号YB202607130001）；2. 等待监管平台核验结果返回 | 运单号: YB202607130001(重复上报) | 核验状态变为"异常"（橙色标签）；异常项列明确标注"运单重复核验"；异常原因可读（如"该运单已存在有效上报记录"）；该异常运单可触发申诉流程，"申诉"按钮可见可用 | 对应TP-C-007 | +| AH_REPORT_R2_007 | 平台端-监管上报-第二次上报 | 验证车辆资质核验—道路运输证在有效期内核验通过 | P1 | 功能测试 | 1. 运单YB202607130001关联的车辆道路运输证有效期起: 2025-01-01, 有效期至: 2027-01-01（当前日期2026-07-13在有效期内）；2. 车辆审核状态为"通过" | 1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项 | 运单号: YB202607130001; 道路运输证有效期: 2025-01-01~2027-01-01 | 核验状态为"通过"；无"车辆资质核验"异常项；监管平台返回vehicleQualCheck=pass；数据库verification_result.vehicle_qual_status='pass' | 对应TP-C-008 | +| AH_REPORT_R2_008 | 平台端-监管上报-第二次上报 | 验证车辆资质核验—道路运输证已过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130029关联的车辆道路运输证有效期至: 2025-12-31（当前日期2026-07-13已过期）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果返回；3. 查看异常项详情 | 运单号: YB202607130029; 道路运输证有效期至: 2025-12-31(已过期) | 核验状态变为"异常"（橙色标签）；异常项列标注"车辆资质核验"；异常原因描述如"道路运输证已过期（有效期至2025-12-31）"；该异常运单可发起申诉 | 对应TP-C-009 | +| AH_REPORT_R2_009 | 平台端-监管上报-第二次上报 | 验证司机资质核验—从业资格证在有效期内核验通过 | P1 | 功能测试 | 1. 运单YB202607130001关联的司机从业资格证有效期起: 2024-06-01, 有效期至: 2028-06-01（在有效期内）；2. 司机审核状态为"通过" | 1. 触发第二次上报；2. 等待核验结果；3. 查看核验状态 | 运单号: YB202607130001; 从业资格证: 有效期内 | 核验状态为"通过"；无"司机资质核验"异常项；监管平台返回driverQualCheck=pass | 对应TP-C-010 | +| AH_REPORT_R2_010 | 平台端-监管上报-第二次上报 | 验证司机资质核验—从业资格证已过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130030关联的司机从业资格证有效期至: 2025-01-01（已过期）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果；3. 查看异常项 | 运单号: YB202607130030; 从业资格证有效期至: 2025-01-01(已过期) | 核验状态变为"异常"；异常项标注"司机资质核验"；异常原因如"司机从业资格证已过期"；可发起申诉 | 对应TP-C-011 | +| AH_REPORT_R2_011 | 平台端-监管上报-第二次上报 | 验证集中支付核验—付款方为平台统一账户时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001打款付款方为网货平台统一账户；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130001; 付款方: 网货平台统一账户 | 核验状态为"通过"；无"集中支付核验"异常项；监管平台返回centralPayCheck=pass；支付流水记录与集中支付模式匹配 | 对应TP-C-012 | +| AH_REPORT_R2_012 | 平台端-监管上报-第二次上报 | 验证集中支付核验—付款方非平台统一账户时核验异常 | P1 | 功能测试 | 1. 运单YB202607130031打款付款方为非平台统一账户（如第三方代付账户）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130031; 付款方: 第三方代付账户(非平台) | 核验状态变为"异常"；异常项标注"集中支付核验"；异常原因如"付款方非集中支付账户"；可发起申诉 | 对应TP-C-013 | +| AH_REPORT_R2_013 | 平台端-监管上报-第二次上报 | 验证资金流水核验—流水号唯一且金额匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001资金流水号唯一（如PAY202607130001）；2. 上报金额¥10,000.00与支付流水表实际打款金额完全一致 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130001; 流水号: PAY202607130001; 金额: ¥10,000.00 | 核验状态为"通过"；无"资金流水核验"异常项；监管平台返回fundFlowCheck=pass | 对应TP-C-014 | +| AH_REPORT_R2_014 | 平台端-监管上报-第二次上报 | 验证资金流水核验—流水号重复时核验异常 | P1 | 功能测试 | 1. 运单YB202607130032使用的资金流水号与已有运单的流水号重复（如均使用PAY202607130001） | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130032; 重复流水号: PAY202607130001 | 核验状态变为"异常"；异常项标注"资金流水核验"；异常原因包含"流水号重复"提示；可发起申诉 | 对应TP-C-015 | +| AH_REPORT_R2_015 | 平台端-监管上报-第二次上报 | 验证资金流水核验—上报金额与支付流水偏差>0.01元时核验异常 | P1 | 功能测试 | 1. 运单YB202607130033支付流水表实际打款¥9,500.00，但上报时发送¥10,000.00（偏差¥500.00>¥0.01） | 1. 触发第二次上报（携带错误金额）；2. 等待核验结果 | 运单号: YB202607130033; 上报金额: ¥10,000.00; 支付流水实际: ¥9,500.00 | 核验状态变为"异常"；异常项标注"资金流水核验"；异常原因包含"金额不匹配"提示；可发起申诉 | 对应TP-C-015 | +| AH_REPORT_R2_016 | 平台端-监管上报-第二次上报 | 验证合同核验—承运合同和委托合同均有效时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001承运合同编号CTC202607001有效（存在于合同管理系统，有效期覆盖运单执行日期2026-07-10~2026-07-13）；2. 委托合同编号DLC202607001有效（如适用） | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130001; 承运合同: CTC202607001(有效); 委托合同: DLC202607001(有效) | 核验状态为"通过"；无"合同核验"异常项；监管平台返回contractCheck=pass | 对应TP-C-016 | +| AH_REPORT_R2_017 | 平台端-监管上报-第二次上报 | 验证合同核验—承运合同不存在时核验异常 | P1 | 功能测试 | 1. 运单YB202607130034关联的承运合同编号INVALID_CTC999不存在于合同管理系统 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130034; 承运合同: INVALID_CTC999(不存在) | 核验状态变为"异常"；异常项标注"合同核验"；异常原因包含"承运合同不存在"提示；可发起申诉 | 对应TP-C-017 | +| AH_REPORT_R2_018 | 平台端-监管上报-第二次上报 | 验证合同核验—合同有效期不覆盖运单执行日期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130035执行日期为2026-07-10~2026-07-13，但关联的承运合同有效期至2026-06-30（已过期不覆盖运单执行日期） | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130035; 承运合同有效期: ~2026-06-30(不覆盖运单日期) | 核验状态变为"异常"；异常项标注"合同核验"；异常原因包含"合同已过期"或"合同有效期不覆盖运单执行日期"；可发起申诉 | 对应TP-C-017 | +| AH_REPORT_R2_019 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点≥2且≤2000且路线匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001车辆GPS轨迹包含500个有效轨迹点；2. 轨迹路线与装货地→卸货地路线基本一致；3. 轨迹时间与运单执行时间匹配 | 1. 触发第二次上报（携带500点轨迹数据）；2. 等待核验结果 | 运单号: YB202607130001; 轨迹点数: 500 | 核验状态为"通过"；无"车辆轨迹合规核验"异常项；监管平台返回trackCheck=pass | 对应TP-C-018 | +| AH_REPORT_R2_020 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点边界值2个点时核验通过 | P2 | 功能测试 | 1. 运单YB202607130036车辆GPS轨迹仅包含2个有效轨迹点（起终点，边界最小值） | 1. 触发第二次上报（携带2点轨迹数据）；2. 等待核验结果 | 运单号: YB202607130036; 轨迹点数: 2(边界最小值) | 核验状态为"通过"；无"车辆轨迹合规核验"异常项；边界值2个点被正确处理 | 对应TP-C-018 | +| AH_REPORT_R2_021 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点边界值2000个点时核验通过 | P2 | 功能测试 | 1. 运单YB202607130037车辆GPS轨迹包含恰好2000个有效轨迹点（边界最大值） | 1. 触发第二次上报（携带2000点轨迹数据）；2. 等待核验结果；3. 验证2000点数据完整传输 | 运单号: YB202607130037; 轨迹点数: 2000(边界最大值) | 核验状态为"通过"；2000个轨迹点全部成功上报，无截断；页面响应不卡顿 | 对应TP-C-018 | +| AH_REPORT_R2_022 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点<2个(仅1个点)时核验异常 | P1 | 功能测试 | 1. 运单YB202607130038车辆GPS轨迹仅包含1个有效轨迹点 | 1. 触发第二次上报（携带1点轨迹数据）；2. 等待核验结果 | 运单号: YB202607130038; 轨迹点数: 1(不足) | 核验状态变为"异常"；异常项标注"车辆轨迹合规核验"；异常原因包含"轨迹点数量不足（至少需要2个点）"；可进入"补传轨迹"流程 | 对应TP-C-019 | +| AH_REPORT_R2_023 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点=0(无轨迹数据)时核验异常 | P1 | 功能测试 | 1. 运单YB202607130039无GPS轨迹数据（轨迹点=0） | 1. 触发第二次上报（轨迹数据为空）；2. 等待核验结果 | 运单号: YB202607130039; 轨迹点数: 0 | 核验状态变为"异常"；异常项标注"车辆轨迹合规核验"；异常原因包含"轨迹数据缺失"；可进入"补传轨迹"流程 | 对应TP-C-019 | +| AH_REPORT_R2_024 | 平台端-监管上报-第二次上报 | 验证第二次上报依赖第一次上报完成—第一次上报失败时第二次上报被拒绝 | P0 | 功能测试 | 1. 运单YB202607130005第一次上报状态为"上传失败"；2. 财务对该运单完成打款操作 | 1. 打款完成回调触发第二次上报；2. 查看第二次上报接口返回；3. 查看第二次上报列表 | 运单号: YB202607130005(第一次上报失败) | 第二次上报接口返回错误，错误码标识"前置上报未完成"或"请先完成第一次上报"；第二次上报列表中无该运单记录或状态未更新；后端通过查询report_status表校验第一次上报完成状态；错误消息清晰可理解 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R2_025 | 平台端-监管上报-第二次上报 | 验证第二次上报幂等性—自动重试期间禁止手动触发 | P0 | 功能测试 | 1. 运单YB202607130001第二次上报正在自动重试中；2. 使用super_admin登录管理端 | 1. 进入第二次上报列表；2. 在自动重试进行中找到该运单；3. 尝试点击"手动上传"按钮或直接调用上报API | 运单号: YB202607130001(自动重试进行中) | 前端"手动上传"按钮不可见或被置灰（仅"上传失败"状态可见）；若通过API直接调用，返回"上报处理中"错误（分布式锁检测）；同一运单第二次上报仅产生1条有效记录；数据库unique约束（运单号+stage=2）防止重复插入 | [AI修正: 历史缺陷防御] - BUG-202607-02 | +| AH_REPORT_R2_026 | 平台端-监管上报-第二次上报 | 验证轨迹核验异常运单的补传轨迹功能—补传后重新核验通过 | P1 | 功能测试 | 1. 运单YB202607130038第二次上报轨迹核验异常（轨迹点仅1个）；2. 运营人员准备补充的GPS轨迹数据（200个点） | 1. 进入第二次上报列表，找到轨迹异常运单；2. 点击操作列"补传轨迹"按钮；3. 上传补充的200个轨迹点数据文件；4. 提交补传；5. 等待重新核验结果 | 运单号: YB202607130038; 原始轨迹点: 1; 补传轨迹点: 200 | 仅轨迹核验异常的运单显示"补传轨迹"按钮；补传提交后系统重新触发轨迹核验；核验通过后异常项"车辆轨迹合规核验"消除，核验状态变为"通过"；补传操作在上报日志中独立记录；补传的200个轨迹点数据覆盖原有的1个点数据 | 对应TP-C-022 | +| AH_REPORT_R2_027 | 平台端-监管上报-第二次上报 | 验证第二次上报失败后自动重试机制—最多3次、间隔递增、全部失败后告警 | P1 | 功能测试 | 1. 运单YB202607130060触发第二次上报；2. 模拟监管平台接口超时（不返回/30s超时） | 1. 触发第二次上报（超时失败）；2. 等待系统自动重试；3. 查看上报日志中每次重试的记录；4. 模拟连续3次重试均失败；5. 查看告警通知 | 运单号: YB202607130060; 重试间隔: 5s/15s/30s(参考值) | 上报失败后系统自动触发第1次重试（约5s后）；第1次失败→第2次重试（约15s后）；第2次失败→第3次重试（约30s后）；每次重试在上报日志中独立记录（共4条: 1次原始+3次重试）；3次全部失败后系统通过站内信或短信告警通知运营人员；上报状态变更为"上传失败"（红色标签），"手动上传"按钮可见可用；重试期间手动上传按钮不可用或置灰显示"上报处理中" | [AI修正: 历史缺陷防御] - BUG-202607-02；对应TP-C-023 | +| AH_REPORT_R2_028 | 平台端-监管上报-第二次上报 | 验证第二次上报详情弹窗资金流水10字段与车辆轨迹6字段分组完整展示 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001第二次上报已完成且含完整资金流水和车辆轨迹数据 | 1. 进入第二次上报列表；2. 点击运单YB202607130001的"详情"按钮；3. 查看"资金流水信息"分组的字段；4. 查看"车辆轨迹信息"分组的字段 | 运单号: YB202607130001; 资金流水: 含完整支付信息; 车辆轨迹: 含150个点位 | 资金流水信息分组完整展示10字段: 支付金额/支付方式/支付时间/付款方名称/收款方名称/收款人/收款账号/收款账号类型/流水号/支付状态；车辆轨迹信息分组完整展示6字段: 定位类型/定位时间/定位地点/经度/纬度/轨迹类型；轨迹列表支持分页浏览（150个点分页展示）；可选字段缺失时显示"-"或"无"而不展示空白；弹窗分组标签和顺序正确: 运单信息→托运方信息→收货方信息→资金流水信息→车辆轨迹信息→异常信息 | 对应TP-C-024；[AI修正: 覆盖缺口补充] | + +| AH_REPORT_R2_029 | 平台端-监管上报-第二次上报 | 验证里程申诉功能—提交里程申诉接口正常 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130058存在里程数据异常（如实际里程与上报里程偏差>20%） | 1. 进入第二次上报详情页；2. 点击"里程申诉"按钮；3. 填写申诉内容"GPS里程与实际里程偏差"、投诉编号"CMP202607130001"、申诉里程"350"；4. 提交 | 运单号: YB202607130058; 申诉里程: 350km; 投诉编号: CMP202607130001 | 里程申诉提交成功，接口POST /mileageAppeal/insert返回成功响应；申诉记录中新增里程申诉记录；申诉内容、投诉编号、申诉里程字段均正确保存；缺少必选参数时接口返回明确错误提示（如"运单号不能为空"）；里程申诉与异常项申诉独立管理互不干扰 | 对应TP-C-025；[技术方案] API新增接口 | +| AH_REPORT_R2_030 | 平台端-监管上报-第二次上报 | 验证委托合同核验(100)—合同有效且覆盖运单日期时核验通过 | P1 | 功能测试 | 1. 运单YB202607130059委托合同编号DLC202607001有效且存在于合同管理系统；2. 委托合同有效期2026-01-01~2026-12-31覆盖运单执行日期2026-07-10~2026-07-13；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项 | 运单号: YB202607130059; 委托合同: DLC202607001(有效) | 核验状态为"通过"；无"委托合同核验"（代码100）异常项；abnormalDetails中不存在id=100的记录 | 对应TP-C-026；[技术方案] API文档§4.1 | +| AH_REPORT_R2_031 | 平台端-监管上报-第二次上报 | 验证委托合同核验(100)—合同不存在或过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130060委托合同编号INVALID_DLC999不存在于合同管理系统；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果返回；3. 查看异常项详情 | 运单号: YB202607130060; 委托合同: INVALID_DLC999(不存在) | 核验状态变为"异常"；异常项标注"委托合同核验"（代码100）；异常原因包含"委托合同不存在"或"委托合同已过期"；可发起申诉 | 对应TP-C-027；[技术方案] API文档§4.1 | +| AH_REPORT_R2_032 | 平台端-监管上报-第二次上报 | 验证承运合同核验(120)—合同有效且覆盖运单日期时核验通过 | P1 | 功能测试 | 1. 运单YB202607130061承运合同编号CTC202607001有效且存在于合同管理系统；2. 承运合同有效期2026-01-01~2026-12-31覆盖运单执行日期；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130061; 承运合同: CTC202607001(有效) | 核验状态为"通过"；无"承运合同核验"（代码120）异常项；abnormalDetails中不存在id=120的记录 | 对应TP-C-028；[技术方案] API文档§4.1 | +| AH_REPORT_R2_033 | 平台端-监管上报-第二次上报 | 验证承运合同核验(120)—合同不存在或过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130062承运合同编号INVALID_CTC888不存在于合同管理系统；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130062; 承运合同: INVALID_CTC888(不存在) | 核验状态变为"异常"；异常项标注"承运合同核验"（代码120）；异常原因包含"承运合同不存在"或"承运合同已过期"；可发起申诉 | 对应TP-C-029；[技术方案] API文档§4.1 | +| AH_REPORT_R2_034 | 平台端-监管上报-第二次上报 | 验证实时定位核验(130)—运单执行期间有完整实时定位数据时核验通过 | P1 | 功能测试 | 1. 运单YB202607130063在运输期间（2026-07-10 08:00~2026-07-13 18:00）有持续完整的GPS实时定位数据；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130063; 定位时间范围: 完整覆盖运输期间 | 核验状态为"通过"；无"实时定位核验"（代码130）异常项 | 对应TP-C-030；[技术方案] API文档§4.1 | +| AH_REPORT_R2_035 | 平台端-监管上报-第二次上报 | 验证实时定位核验(130)—运输期间定位数据长时间中断时核验异常 | P1 | 功能测试 | 1. 运单YB202607130064运输期间（2026-07-10~2026-07-13）GPS定位数据在2026-07-11~2026-07-12期间中断超过24小时；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130064; 定位中断: 2026-07-11~2026-07-12(约24小时) | 核验状态变为"异常"；异常项标注"实时定位核验"（代码130）；异常原因包含"实时定位数据长时间中断"；可发起申诉或补充定位数据 | 对应TP-C-031；[技术方案] API文档§4.1 | +| AH_REPORT_R2_036 | 平台端-监管上报-第二次上报 | 验证运单时间逻辑核验(140)—各时间节点逻辑合理时核验通过 | P1 | 功能测试 | 1. 运单YB202607130065时间节点合理：建单2026-07-09→接单2026-07-10 08:00→起运2026-07-10 10:00→送达2026-07-13 16:00；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130065; 时间序列: 建单→接单→起运→送达(合理) | 核验状态为"通过"；无"运单时间逻辑核验"（代码140）异常项 | 对应TP-C-032；[技术方案] API文档§4.1 | +| AH_REPORT_R2_037 | 平台端-监管上报-第二次上报 | 验证运单时间逻辑核验(140)—送达时间早于起运时间时核验异常 | P1 | 功能测试 | 1. 运单YB202607130066时间节点矛盾：起运2026-07-13 10:00→送达2026-07-12 16:00（送达早于起运）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130066; 时间倒置: 送达(07-12)早于起运(07-13) | 核验状态变为"异常"；异常项标注"运单时间逻辑核验"（代码140）；异常原因包含"送达时间早于起运时间"；可发起申诉 | 对应TP-C-033；[技术方案] API文档§4.1 | +| AH_REPORT_R2_038 | 平台端-监管上报-第二次上报 | 验证道路运输证核验(160)—有效期和证号均有效时核验通过 | P1 | 功能测试 | 1. 运单YB202607130067车辆道路运输证号RTC202501001有效，有效期2025-03-01~2027-03-01（当前日期2026-07-13在有效期内）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130067; 道路运输证号: RTC202501001(有效) | 核验状态为"通过"；无"道路运输证核验"（代码160）异常项 | 对应TP-C-034；[技术方案] API文档§4.1 | +| AH_REPORT_R2_039 | 平台端-监管上报-第二次上报 | 验证道路运输证核验(160)—证号在运政系统查询不存在时核验异常 | P1 | 功能测试 | 1. 运单YB202607130068车辆道路运输证号INVALID_RTC999在运政系统中查询不存在；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130068; 道路运输证号: INVALID_RTC999(不存在) | 核验状态变为"异常"；异常项标注"道路运输证核验"（代码160）；异常原因包含"道路运输证不存在"；可发起申诉 | 对应TP-C-035；[技术方案] API文档§4.1 | +| AH_REPORT_R2_040 | 平台端-监管上报-第二次上报 | 验证驾驶证核验(170)—驾驶证有效且准驾车型匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130069司机驾驶证号DL202501001有效，有效期2024-01-01~2030-01-01，准驾车型B2（与重型货车匹配）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130069; 驾驶证号: DL202501001(有效); 准驾车型: B2(匹配) | 核验状态为"通过"；无"驾驶证核验"（代码170）异常项 | 对应TP-C-036；[技术方案] API文档§4.1 | +| AH_REPORT_R2_041 | 平台端-监管上报-第二次上报 | 验证驾驶证核验(170)—驾驶证已过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130070司机驾驶证有效期至2025-12-31（当前日期2026-07-13已过期）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130070; 驾驶证有效期至: 2025-12-31(已过期) | 核验状态变为"异常"；异常项标注"驾驶证核验"（代码170）；异常原因包含"驾驶证已过期"；可发起申诉 | 对应TP-C-037；[技术方案] API文档§4.1 | +| AH_REPORT_R2_042 | 平台端-监管上报-第二次上报 | 验证车辆重复核验(190)—车辆无时间重叠运单时核验通过 | P1 | 功能测试 | 1. 运单YB202607130071车辆云A12345在运单执行时段2026-07-10~2026-07-13内无其他运单；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130071; 车辆: 云A12345(无时间重叠) | 核验状态为"通过"；无"车辆重复核验"（代码190）异常项 | 对应TP-C-038；[技术方案] API文档§4.1 | +| AH_REPORT_R2_043 | 平台端-监管上报-第二次上报 | 验证车辆重复核验(190)—同一车辆同时用于两个时间重叠运单时核验异常 | P1 | 功能测试 | 1. 车辆云A12345同时出现在运单YB202607130072（执行时段2026-07-10~2026-07-13）和运单YB202607130073（执行时段2026-07-11~2026-07-14）中，时间重叠2天；2. 第一次上报已完成 | 1. 分别触发两个运单的第二次上报；2. 查看核验结果 | 运单A: YB202607130072(07-10~07-13); 运单B: YB202607130073(07-11~07-14); 重叠: 07-11~07-13 | 至少一个运单核验状态变为"异常"；异常项标注"车辆重复核验"（代码190）；异常原因包含"车辆在运单执行期间存在时间重叠"；可发起申诉 | 对应TP-C-039；[技术方案] API文档§4.1 | +| AH_REPORT_R2_044 | 平台端-监管上报-第二次上报 | 验证司机重复核验(200)—司机无时间重叠运单时核验通过 | P1 | 功能测试 | 1. 运单YB202607130074司机张三(身份证510101199001011234)在运单执行时段2026-07-10~2026-07-13内无其他运单；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130074; 司机: 张三(无时间重叠) | 核验状态为"通过"；无"司机重复核验"（代码200）异常项 | 对应TP-C-040；[技术方案] API文档§4.1 | +| AH_REPORT_R2_045 | 平台端-监管上报-第二次上报 | 验证司机重复核验(200)—同一司机同时执行两个时间重叠运单时核验异常 | P1 | 功能测试 | 1. 司机张三同时被分配给运单YB202607130075（执行时段2026-07-10~2026-07-13）和运单YB202607130076（执行时段2026-07-12~2026-07-15），时间重叠2天；2. 第一次上报已完成 | 1. 分别触发两个运单的第二次上报；2. 查看核验结果 | 运单A: YB202607130075(07-10~07-13); 运单B: YB202607130076(07-12~07-15); 司机: 张三(重叠) | 至少一个运单核验状态变为"异常"；异常项标注"司机重复核验"（代码200）；异常原因包含"司机在运单执行期间存在时间重叠"；可发起申诉 | 对应TP-C-041；[技术方案] API文档§4.1 | +| AH_REPORT_R2_046 | 平台端-监管上报-第二次上报 | 验证运费收款核验(220)—收款人与司机一致且金额匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130077收款人张三与司机张三一致（身份证号510101199001011234匹配）；2. 收款金额¥10,000.00与运单运费一致；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130077; 收款人: 张三(与司机一致); 收款金额: ¥10,000.00 | 核验状态为"通过"；无"运费收款核验"（代码220）异常项 | 对应TP-C-042；[技术方案] API文档§4.1 | +| AH_REPORT_R2_047 | 平台端-监管上报-第二次上报 | 验证运费收款核验(220)—收款人与司机身份证号不一致时核验异常 | P1 | 功能测试 | 1. 运单YB202607130078司机为张三(身份证510101199001011234)，但收款人为李四(身份证510101199002022345)，两者不一致；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130078; 司机: 张三; 收款人: 李四(不一致) | 核验状态变为"异常"；异常项标注"运费收款核验"（代码220）；异常原因包含"收款人与司机信息不一致"；可发起申诉 | 对应TP-C-043；[技术方案] API文档§4.1 | +| AH_REPORT_R2_048 | 平台端-监管上报-第二次上报 | 验证公司统一收款核验(230)—收款公司信息与托运方一致时核验通过 | P1 | 功能测试 | 1. 运单YB202607130079收款公司为"安徽XX物流有限公司"(统一社会信用代码9134XXXXXXXXXXXXXX)，与托运方信息完全一致；2. 收款账户已在系统中备案；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130079; 收款公司: 安徽XX物流有限公司(与托运方一致) | 核验状态为"通过"；无"公司统一收款核验"（代码230）异常项 | 对应TP-C-044；[技术方案] API文档§4.1 | +| AH_REPORT_R2_049 | 平台端-监管上报-第二次上报 | 验证公司统一收款核验(230)—收款公司统一社会信用代码与托运方不一致时核验异常 | P1 | 功能测试 | 1. 运单YB202607130080托运方为"安徽XX物流有限公司"，但收款公司为"安徽YY运输有限公司"，统一社会信用代码不一致；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130080; 托运方: 安徽XX物流; 收款公司: 安徽YY运输(不一致) | 核验状态变为"异常"；异常项标注"公司统一收款核验"（代码230）；异常原因包含"收款公司信息与托运方不一致"；可发起申诉 | 对应TP-C-045；[技术方案] API文档§4.1 | +| AH_REPORT_R2_050 | 平台端-监管上报-第二次上报 | 验证发票信息核验(260)—发票号码/代码有效且信息完整时核验通过 | P1 | 功能测试 | 1. 运单YB202607130081关联的发票FP202607130081在税务系统中可查询且状态正常；2. 发票销售方和受票方信息完整；3. 第一次/第二次上报已完成 | 1. 触发第三次上报后等待发票核验；2. 或通过API直接查询核验结果 | 运单号: YB202607130081; 发票号: FP202607130081(有效) | 核验状态为"通过"；无"发票信息核验"（代码260）异常项 | 对应TP-C-046；[技术方案] API文档§4.1 | +| AH_REPORT_R2_051 | 平台端-监管上报-第二次上报 | 验证发票信息核验(260)—发票已作废时核验异常 | P1 | 功能测试 | 1. 运单YB202607130082关联的发票FP202607130082在税务系统中状态为"已作废/红冲"；2. 第一次/第二次上报已完成 | 1. 触发第三次上报后等待发票核验；2. 查看核验结果 | 运单号: YB202607130082; 发票号: FP202607130082(已作废) | 核验状态变为"异常"；异常项标注"发票信息核验"（代码260）；异常原因包含"发票已作废"或"发票状态异常"；可发起申诉 | 对应TP-C-047；[技术方案] API文档§4.1 | +| AH_REPORT_R2_052 | 平台端-监管上报-第二次上报 | 验证非通行车辆可开票核验(270)—车辆运营证照齐全且合规时核验通过 | P1 | 功能测试 | 1. 运单YB202607130083车辆运营证照齐全(道路运输证/行驶证均在有效期内)且未被标记为黑名单；2. 第一次/第二次上报已完成 | 1. 触发上报后等待核验；2. 查看核验结果 | 运单号: YB202607130083; 车辆证照: 齐全有效 | 核验状态为"通过"；无"非通行车辆可开票核验"（代码270）异常项 | 对应TP-C-048；[技术方案] API文档§4.1 | +| AH_REPORT_R2_053 | 平台端-监管上报-第二次上报 | 验证非通行车辆可开票核验(270)—车辆被标记为黑名单时核验异常 | P1 | 功能测试 | 1. 运单YB202607130084车辆已被监管平台标记为运营异常/黑名单；2. 第一次/第二次上报已完成 | 1. 触发上报后等待核验；2. 查看核验结果 | 运单号: YB202607130084; 车辆状态: 黑名单 | 核验状态变为"异常"；异常项标注"非通行车辆可开票核验"（代码270）；异常原因包含"车辆不合规"或"车辆不在可开票范围"；可发起申诉 | 对应TP-C-049；[技术方案] API文档§4.1 | +| AH_REPORT_R2_054 | 平台端-监管上报-第二次上报 | 验证第二次上报核验详情中每个异常项有独立申诉入口 | P2 | 功能测试 | 1. 运单YB202607130091第二次上报存在两个核验异常项：车辆轨迹(210)和资金流水(250)；2. 使用super_admin登录管理端 | 1. 进入第二次上报列表，点击该运单的"详情"按钮；2. 查看核验详情弹窗中的异常项列表；3. 验证每个异常项旁是否有独立的"申诉"操作按钮 | 运单号: YB202607130091; 异常项: 车辆轨迹(210), 资金流水(250) | 核验详情弹窗中每个异常项均有独立的"申诉"按钮或操作入口；点击异常项210的"申诉"按钮后跳转至申诉页面，且verificationAbnormalItems预填充为"210"；点击异常项250的"申诉"按钮后预填充"250"；两个申诉入口独立触发，互不影响 | 对应TP-C-024；[AI修正: 申诉单值约束意识] | +| AH_REPORT_R2_055 | 平台端-监管上报-第二次上报 | 验证第二次上报所有金额字段保留3位小数—整数填.000、精度无丢失 | P1 | 功能测试 | 1. 准备运单YB202607130093含各种金额场景：整数100、小数100.5、小数100.123；2. 第一次上报已完成，财务打款完成 | 1. 触发第二次上报；2. 查看上报请求JSON中各金额字段的值；3. 验证数据库存储和UI展示的精度 | 运单号: YB202607130093; 承运运费: 100(整数)/100.5(1位小数)/100.123(3位小数); 委托运费: 150.5; 承运人流水金额: 10000; 货主流水金额: 10500.25; 承运合同金额: 12000.5; 委托合同金额: 11000.125 | waybillFreightAmount整数100→"100.000"；totalMonetaryAmount小数150.5→"150.500"；carrierStatements[0].monetaryAmount整数10000→"10000.000"；ownerStatements[0].monetaryAmount小数10500.25→"10500.250"；carrierContractInfo.contractAmount小数12000.5→"12000.500"；carrierContractInfo.contractedCarryingCapacity→3位小数；ownerContractInfo相同规则；数据库所有金额字段使用DECIMAL(18,3)类型非FLOAT；UI展示也同步为3位小数格式 | 对应TP-C-050；[技术方案] showdoc文档第二次上报金额精度3位小数 | + +--- + +## 模块D: 第三次上报-开票完成 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_R3_001 | 平台端-监管上报-第三次上报 | 验证发票开具完成后自动触发第三次上报且包含发票信息17字段 | P0 | 功能测试 | 1. 运单YB202607130001已完成第二次上报且状态为"已上传"；2. 该运单发票FP202607130001已开具完成 | 1. 系统收到发票开具完成事件；2. 进入管理端"监管上报-第三次上报"列表查看 | 运单号: YB202607130001; 发票号: FP202607130001; 发票金额(价税合计): ¥10,300.00 | 第三次上报列表中新增该运单记录，上报状态从"上传中"变为"已上传"（绿色标签）；上报请求包含运单信息+发票信息17字段+托运单号数组；若运单无关联油气发票则油气发票信息字段为空；数据库report_record表新增stage=3的记录 | 对应TP-D-001 | +| AH_REPORT_R3_002 | 平台端-监管上报-第三次上报 | 验证第三次上报列表展示13个字段完整且数据正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 第三次上报列表中有至少1条已完成的记录 | 1. 进入"监管上报-第三次上报"列表；2. 查看列表表头和第一条数据的所有列内容 | 运单号: YB202607130001; 发票号: FP202607130001 | 列表展示13个字段: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/发票号码/发票金额/开票日期/核验状态/异常原因/上报状态/操作；发票金额保留2位小数；开票日期格式为YYYY-MM-DD；核验状态标签颜色符合规范 | 对应TP-D-002；⚠️ 待确认: 原型列表比需求多4个字段（税率/销售方名称/受票方名称/油气票张数），共15列 | +| AH_REPORT_R3_003 | 平台端-监管上报-第三次上报 | 验证第三次上报详情弹窗发票信息19字段完整展示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001第三次上报已完成 | 1. 进入第三次上报列表；2. 点击运单YB202607130001的"详情"按钮；3. 查看"发票信息"分组的所有字段 | 运单号: YB202607130001; 发票号: FP202607130001; 发票代码: 1234567890; 价税合计: ¥10,300.00 | 发票信息分组展示19字段: 托运单号数组（支持多个托运单号）、发票号码、发票代码号、发票金额(价税合计)、开票日期（必选字段完整）；销售方8字段（名称/纳税人识别号/地址/电话/开户行/银行账户/账号/联系人）完整；受票方6字段（名称/纳税人识别号/地址/电话/开户行/银行卡号）完整；注：第三次上报无税率字段 | 对应TP-D-003 | +| AH_REPORT_R3_004 | 平台端-监管上报-第三次上报 | 验证运单关联油气发票时第三次上报包含油气发票信息 | P2 | 功能测试 | 1. 运单YB202607130040关联油气发票YQFP202607001；2. 该运单发票开具完成 | 1. 触发第三次上报；2. 查看上报请求JSON中油气发票信息字段；3. 查看详情弹窗 | 运单号: YB202607130040; 油气发票: YQFP202607001 | 上报请求JSON包含油气发票信息（油气托运单号、油气发票文件）；详情弹窗中油气发票信息正确展示；油气发票文件支持查看和下载 | 对应TP-D-004 | +| AH_REPORT_R3_005 | 平台端-监管上报-第三次上报 | 验证无油气发票时第三次上报正常完成（可选字段为空） | P2 | 功能测试 | 1. 运单YB202607130001无关联油气发票；2. 该运单发票开具完成 | 1. 触发第三次上报；2. 查看上报请求JSON中油气发票相关字段 | 运单号: YB202607130001; 油气发票: 无 | 上报请求JSON中油气发票字段为null或不传；上报成功，不报错；详情弹窗中油气发票区域显示"-"或"无" | 对应TP-D-004 | +| AH_REPORT_R3_006 | 平台端-监管上报-第三次上报 | 验证第三次上报依赖第二次上报完成—第二次上报失败时第三次上报被拒绝 | P0 | 功能测试 | 1. 运单YB202607130041第二次上报状态为"上传失败"；2. 该运单发票已开具完成 | 1. 发票开具完成事件触发第三次上报；2. 查看第三次上报接口返回 | 运单号: YB202607130041(第二次上报失败) | 接口返回错误，错误码明确标识"前置上报（第二次）未完成"；后端通过查询report_status表校验第二阶段的完成状态；第三次上报列表无该运单记录 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R3_007 | 平台端-监管上报-第三次上报 | 验证第三次上报完整依赖链校验—第1失败→第2无法完成→第3被拒绝 | P0 | 功能测试 | 1. 运单YB202607130042第一次上报状态为"上传失败" | 1. 通过API依次尝试调用第二次上报接口和第三次上报接口；2. 查看每个接口的返回 | 运单号: YB202607130042 | 第一次上报失败→第二次上报接口返回"前置上报未完成"；第二次上报无法完成→第三次上报接口同样返回"前置上报未完成"（含第二次）；三阶段依赖链校验在后端完整实现，不可跳级 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R3_008 | 平台端-监管上报-第三次上报 | 验证增值税发票号码格式无效时第三次上报失败并明确提示 | P1 | 功能测试 | 1. 运单YB202607130043发票号码格式无效（如"ABC"非标准格式）；2. 第二次上报已完成 | 1. 触发第三次上报；2. 查看上报接口返回的错误信息 | 运单号: YB202607130043; 发票号码: ABC(无效格式) | 接口返回校验错误，提示"发票号码格式无效"或类似消息；上报状态标记为"上传失败"（红色标签）；错误信息明确指出具体错误字段为发票号码；数据库无该运单第三次上报的成功记录 | 对应TP-D-006 | +| AH_REPORT_R3_009 | 平台端-监管上报-第三次上报 | 验证发票代码与发票号码不匹配时第三次上报失败 | P1 | 功能测试 | 1. 运单YB202607130044发票代码1234567890与发票号码FP202607130001不匹配 | 1. 触发第三次上报；2. 查看接口返回 | 运单号: YB202607130044; 不匹配的发票代码/号码 | 接口返回校验错误，提示"发票代码与发票号码不匹配"；上报状态标记为"上传失败"；错误信息指明具体错误字段 | 对应TP-D-006 | +| AH_REPORT_R3_010 | 平台端-监管上报-第三次上报 | 验证第三次上报失败后自动重试最多3次全部失败后告警 | P1 | 功能测试 | 1. 运单YB202607130045第三次上报时模拟监管平台持续返回失败 | 1. 触发第三次上报；2. 监控上报日志中的重试记录；3. 等待3次重试全部完成后查看告警通知 | 运单号: YB202607130045; 发票号: FP202607130045 | 自动重试3次（总共4次尝试）；重试间隔递增；3次重试全部失败后上报状态标记为"上传失败"（红色）并停止重试；super_admin收到告警通知，内容包含运单号YB202607130045、发票号FP202607130045、失败原因 | 对应TP-D-007 | +| AH_REPORT_R3_011 | 平台端-监管上报-第三次上报 | 验证第三次上报幂等性—同一运单同一发票信息不能重复上报 | P1 | 功能测试 | 1. 运单YB202607130001第三次上报已成功（发票FP202607130001）；2. 尝试再次触发第三次上报 | 1. 通过API再次调用第三次上报接口（同一运单+同一发票）；2. 查看接口返回 | 运单号: YB202607130001; 发票号: FP202607130001(已上报) | 接口返回"上报已存在"或"该发票已上报"提示；数据库report_record表不会新增重复记录（唯一约束：运单号+stage=3+发票号）；分布式锁或幂等键控制并发 | 对应TP-D-009 | +| AH_REPORT_R3_012 | 平台端-监管上报-第三次上报 | 验证第三次上报发票金额精度—价税合计保留2位小数无浮点数精度问题 | P1 | 功能测试 | 1. 准备发票金额为¥0.01、¥9,999.99、¥999,999.99的三张发票 | 1. 分别对三张发票触发第三次上报；2. 查看上报请求JSON中的金额字段；3. 对比数据库发票表和上报记录中的金额 | 金额1: ¥0.01; 金额2: ¥9,999.99; 金额3: ¥999,999.99 | 三个金额均保留2位小数并精确传输（如0.01不为0.009999...）；大金额¥999,999.99不出现溢出或截断；数据库金额字段使用DECIMAL类型非FLOAT；上报数据与开票系统数据完全一致 | 对应TP-D-010 | +| AH_REPORT_R3_013 | 平台端-监管上报-第三次上报 | 验证第三次上报运单信息数据来源—价格和货物信息来源于运单表实时数据 | P2 | 功能测试 | 1. 运单YB202607130046装货完成时货物信息含"钢材10吨"；2. 在第三次上报前修改运单表货物信息为"钢材12吨" | 1. 修改运单表的货物信息；2. 触发第三次上报；3. 查看上报请求中的货物信息数据 | 运单号: YB202607130046; 原货物量: 10吨; 修改后: 12吨 | 上报请求中的货物信息为"钢材12吨"（最新值），非"钢材10吨"（装货时快照）；数据来源为运单表实时查询；不依赖装货完成时的数据缓存 | 对应TP-D-011 | +| AH_REPORT_R3_014 | 平台端-监管上报-第三次上报 | 验证第三次上报详情弹窗异常信息分组与申诉模块数据联动 | P2 | 功能测试 | 1. 运单YB202607130046第三次上报核验异常；2. 已对该运单发起申诉且申诉状态为"申诉中" | 1. 进入第三次上报列表；2. 点击运单YB202607130046的"详情"按钮；3. 查看"异常信息"分组 | 运单号: YB202607130046; 申诉状态: 申诉中 | 异常信息分组包含核验状态（异常）、异常原因（具体异常项）、异常时间（核验时间）、处理状态（申诉中）；处理状态与申诉模块数据一致（联动）；申诉状态变更后详情弹窗中处理状态同步更新 | 对应TP-D-008 | +| AH_REPORT_R3_015 | 平台端-监管上报-第三次上报 | 验证发票合规查询接口—查询托运人发票是否通过系统核验合规 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 托运人"安徽XX物流有限公司"存在已核验合规的发票记录 | 1. 调用POST /verificationSummary/cargoOwnerInvoiceInfo接口；2. 传入托运人识别信息（统一社会信用代码/名称）；3. 查看返回的发票合规状态 | 托运人: 安徽XX物流有限公司; 统一社会信用代码: 9134XXXXXXXXXXXXXX | 接口返回发票合规状态为"合规/通过"；若发票不合规则返回异常原因和具体不合规项；接口支持批量查询多个托运人发票合规状态；响应时间<3s；传入无效托运人信息时返回明确错误提示 | 对应TP-D-012；[技术方案] API新增接口 | + +--- + +## 模块E: ETC发票上传 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_ETC_001 | 平台端-监管上报-ETC上传 | 验证运营人员手动确认税务抵扣完成后触发ETC发票上传并成功 | P0 | 功能测试 | 1. 运单YB202607130001的ETC发票ETC202607130001税务抵扣已完成（税务系统侧）；2. ETC发票信息18字段完整 | 1. 运营人员在运八系统手动确认"抵扣完成"；2. 系统收到确认后触发ETC发票上传；3. 进入管理端"监管上报-ETC上传"列表查看；4. 查看上传请求JSON内容 | 运单号: YB202607130001; ETC发票号: ETC202607130001; 不含税金额(invoiceAmount): ¥100.00; 税率: 3% | 运营人员确认后系统自动触发上传；ETC上传列表中出现该记录，上传状态为"已上传"（绿色标签）；上报请求JSON包含运单信息7字段+ETC发票信息18字段；数据库etc_report_record表新增记录，status=1 | 对应TP-E-001；[技术方案] 触发方式修正：运营人员手动确认→系统触发 | +| AH_REPORT_ETC_002 | 平台端-监管上报-ETC上传 | 验证ETC上传列表展示11个字段完整且数据正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. ETC上传列表中有至少1条记录 | 1. 进入"监管上报-ETC上传"列表；2. 查看列表表头和第一条数据的所有列 | 运单号: YB202607130001; ETC发票号: ETC202607130001 | 列表展示: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/ETC发票号码/发票金额/税率/上传状态/操作；发票金额正确展示，税率显示3%；上传状态标签颜色符合规范 | 对应TP-E-002 | +| AH_REPORT_ETC_003 | 平台端-监管上报-ETC上传 | 验证ETC发票详情弹窗3个分组字段完整（运单信息/ETC发票信息18字段/异常信息） | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. ETC上传列表中有已完成上传的记录 | 1. 进入ETC上传列表；2. 点击运单YB202607130001操作列的"详情"按钮；3. 依次查看各分组字段 | 运单号: YB202607130001; ETC发票号: ETC202607130001 | 运单信息分组7字段完整；ETC发票信息分组18字段完整展示: ETC发票号码、ETC发票代码、开票时间、发票金额、税率(3%)、税额、价税合计、销售方名称、销售方税号、受票方名称、受票方税号、入口收费站、出口收费站、交易时间、交易金额、交易匹配时间、交易流水号、ETC发票文件；异常信息分组4字段（核验状态/异常原因/异常时间/处理状态） | 对应TP-E-003 | +| AH_REPORT_ETC_004 | 平台端-监管上报-ETC上传 | 验证税务抵扣未完成时ETC上传被拒绝并提示"请先完成税务抵扣" | P0 | 功能测试 | 1. 运单YB202607130047的ETC发票税务抵扣状态为"未完成" | 1. 尝试触发ETC发票上传（调用API或页面操作）；2. 查看接口返回 | 运单号: YB202607130047; 税务抵扣: 未完成 | 上传接口返回错误，提示"请先完成税务抵扣"；后端校验税务抵扣状态为已完成才允许上传；ETC上传列表中不会出现该运单记录 | 对应TP-E-004 | +| AH_REPORT_ETC_005 | 平台端-监管上报-ETC上传 | 验证ETC发票号码格式无效时上传失败并明确提示 | P1 | 功能测试 | 1. 运单YB202607130048关联的ETC发票号码格式无效（如"ETC-ABC"不符合规定格式） | 1. 税务抵扣完成后触发上传；2. 查看接口返回 | 运单号: YB202607130048; ETC发票号码: ETC-ABC(无效) | 上传接口返回校验错误，提示"ETC发票号码格式无效"；上传状态标记为"上传失败"；错误提示指明具体错误字段 | 对应TP-E-005 | +| AH_REPORT_ETC_006 | 平台端-监管上报-ETC上传 | 验证ETC发票税率非3%时上传失败并提示税率异常 | P1 | 功能测试 | 1. 运单YB202607130049关联的ETC发票税率字段为5%（非标准3%） | 1. 触发上传；2. 查看接口返回 | 运单号: YB202607130049; ETC发票税率: 5%(非标准) | 上传接口返回校验错误，提示"税率异常（应为3%）"；上传状态标记为"上传失败"；不会将错误税率数据上报至监管平台 | 对应TP-E-005 | +| AH_REPORT_ETC_007 | 平台端-监管上报-ETC上传 | 验证ETC上传失败后自动重试最多3次全部失败后告警 | P1 | 功能测试 | 1. 运单YB202607130050 ETC上传时模拟监管平台持续返回失败 | 1. 触发ETC上传；2. 监控上报日志中的重试记录；3. 等待3次重试全部完成后查看告警 | 运单号: YB202607130050; ETC发票号: ETC202607130050 | 自动重试3次（总共4次尝试）；重试间隔递增；3次重试全部失败后标记"上传失败"（红色标签）并停止重试；super_admin收到告警通知；每次重试均记录到上报日志 | 对应TP-E-006 | +| AH_REPORT_ETC_008 | 平台端-监管上报-ETC上传 | 验证ETC税额计算公式—税额=不含税金额×税率(taxRate)，字段区分invoiceAmount/totalPriceAndTax | P1 | 功能测试 | 1. 准备3张ETC发票：不含税金额(invoiceAmount)分别为¥100.00、¥0.01、¥1,000,000.00，税率3% | 1. 分别对三张发票触发上传；2. 查看上报请求JSON中的invoiceAmount(不含税金额)、taxRate(税率)、taxAmount(税额)、totalPriceAndTax(价税合计)字段；3. 验证计算逻辑: totalPriceAndTax = invoiceAmount + taxAmount | 发票1: invoiceAmount=100.00→税额=3.00; 发票2: invoiceAmount=0.01→税额=0.00; 发票3: invoiceAmount=1000000.00→税额=30000.00 | 发票1: invoiceAmount=100.00, taxAmount=3.00, totalPriceAndTax=103.00, 计算正确；发票2: 税额按四舍五入规则处理（0.01×3%=0.0003→0.00）；发票3: invoiceAmount=1000000.00, taxAmount=30000.00, totalPriceAndTax=1030000.00, 大金额计算不溢出；所有金额字段保留2位小数；invoiceAmount≠发票总金额，是不含税金额 | 对应TP-E-007；[技术方案] 字段语义修正：invoiceAmount=不含税金额（非总金额） | +| AH_REPORT_ETC_009 | 平台端-监管上报-ETC上传 | 验证同一ETC发票号重复上传时被拒绝且提示"该ETC发票已上传" | P1 | 功能测试 | 1. ETC发票ETC202607130001已成功上传 | 1. 再次触发同一ETC发票的上传；2. 查看接口返回 | ETC发票号: ETC202607130001(已上传) | 接口返回"该ETC发票已上传"提示；数据库etc_report_record表不会产生重复记录（唯一约束：ETC发票号）；分布式锁/幂等键控制并发 | 对应TP-E-008 | +| AH_REPORT_ETC_010 | 平台端-监管上报-ETC上传 | 验证同一运单关联多张ETC发票时各自独立上传且税额分别计算 | P2 | 功能测试 | 1. 运单YB202607130001关联3张ETC发票：ETC202607130001(¥100.00)、ETC202607130002(¥200.00)、ETC202607130003(¥150.00) | 1. 分别触发3张ETC发票的上传；2. 查看ETC上传列表；3. 验证每张发票的税额计算 | ETC1: ¥100.00→税¥3.00; ETC2: ¥200.00→税¥6.00; ETC3: ¥150.00→税¥4.50 | 列表中同一运单展示3条ETC上传记录；每张发票的税额独立计算正确；多张发票上传互不干扰；合计税额=¥13.50正确汇总 | 对应TP-E-009 | +| AH_REPORT_ETC_011 | 平台端-监管上报-ETC上传 | 验证ETC发票代码与号码不匹配时上传失败 | P1 | 功能测试 | 1. 运单YB202607130051的ETC发票代码与号码不匹配（代码对应其他发票） | 1. 触发上传；2. 查看接口返回 | 运单号: YB202607130051; 不匹配的ETC发票代码/号码 | 上传接口返回校验错误，提示"ETC发票代码与号码不匹配"；上传状态标记为"上传失败"；错误信息指明具体错误字段 | 对应TP-E-005 | +| AH_REPORT_ETC_012 | 平台端-监管上报-ETC上传 | 验证交易金额与实际通行费不匹配时ETC上传验证失败 | P1 | 功能测试 | 1. 运单YB202607130052的ETC发票中交易金额¥50.00与实际通行费¥80.00不匹配 | 1. 触发上传；2. 查看接口返回 | 运单号: YB202607130052; 交易金额: ¥50.00; 实际通行费: ¥80.00(不匹配) | 上传接口返回校验错误，提示"交易金额与实际通行费不匹配"；上传状态标记为"上传失败" | 对应TP-E-005 | + +--- + +## 模块F: 异常申诉功能 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_APL_001 | 平台端-监管上报-异常申诉 | 验证申诉完整闭环—从发起申诉到申诉通过的端到端流程 | P0 | 功能测试 | 1. 运单YB202607130002第二次上报"车辆资质核验"异常；2. 使用super_admin登录管理端；3. 准备申诉附件材料（车辆道路运输证更新后的PDF） | 1. 从看板或第二次上报列表找到异常运单YB202607130002；2. 点击"申诉"按钮进入申诉页面；3. 填写申诉原因"道路运输证已续期，附新证"；4. 上传申诉附件；5. 点击"提交申诉"；6. 模拟省平台复核通过并返回反馈；7. 查看申诉状态变化 | 运单号: YB202607130002; 异常项: 车辆资质核验; 申诉原因: 道路运输证已续期; 附件: 新道路运输证.pdf | 提交申诉后申诉状态变为"未申诉(100)·申诉中"（abnormalDetails[].state=110，省平台尚未审核）；省平台复核通过后状态变为"审核通过(110)"（绿色标签，终态）；申诉记录页面中该申诉记录状态为"审核通过(110)"；处理记录时间线中每条操作均有记录；申诉状态中"已取消(130)"为省平台侧外部操作设置（如运单作废），我方系统只读同步，不提供取消操作入口 | 对应TP-F-001；[API权威] 申诉状态以API §4.4为准: 未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130)；已取消(130)由省平台侧操作，我方只读 | +| AH_REPORT_APL_002 | 平台端-监管上报-异常申诉 | 验证申诉审核不通过(120)后运营人员重新申诉补充材料再发起 | P1 | 功能测试 | 1. 运单YB202607130002申诉状态为"审核不通过(120)"；2. 省平台反馈意见"证明材料不充分" | 1. 进入申诉记录页面，找到审核不通过的申诉记录；2. 点击"重新申诉"按钮；3. 补充新的附件材料（补充证明.pdf）；4. 修改申诉原因；5. 提交 | 运单号: YB202607130002; 原申诉被审核不通过; 新附件: 补充证明.pdf | "重新申诉"按钮可见可用；重新申诉后生成新的申诉单号（不同于原申诉单号）；原有申诉记录保留不丢失（状态保持审核不通过120）；新申诉有独立的处理记录时间线；申诉状态变为"未申诉(100)·申诉中"（abnormalDetails[].state=110），重新进入复核流程 | 对应TP-F-006 | +| AH_REPORT_APL_003 | 平台端-监管上报-异常申诉 | 验证申诉记录列表14个字段完整展示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 申诉记录列表中有至少1条申诉记录 | 1. 进入"监管上报-异常申诉"申诉记录页面；2. 查看列表表头和第一条数据的各列 | 申诉单含完整字段 | 列表展示14个字段: 运单号/托运单号/车牌号/司机姓名/托运方名称/上报阶段/核验状态/异常项/申诉状态/申诉时间/申诉人/省平台反馈结果/监管平台反馈时间/操作；申诉时间为实际提交时间；省平台反馈结果与实际反馈内容一致 | 对应TP-F-002 | +| AH_REPORT_APL_004 | 平台端-监管上报-异常申诉 | 验证申诉状态流转—未申诉(100)→未申诉·申诉中→审核通过(110)(终态)或审核不通过(120)(可重申诉) | P0 | 功能测试 | 1. 运单YB202607130053核验异常且申诉状态为"未申诉(100)" | 1. 发起申诉，验证异常项子状态变为"申诉中"(abnormalDetails[].state=110)；2. 模拟省平台复核通过；3. 验证申诉状态变为"审核通过(110)"；4. 尝试再次对该申诉记录操作（如重新申诉）；5. 模拟省平台审核不通过→验证状态变为"审核不通过(120)"→可重新申诉 | 运单号: YB202607130053 | 未申诉(100)→提交申诉后异常项子状态变为申诉中(state=110)，申诉状态仍为未申诉(100)；省平台审核通过后申诉状态变为审核通过(110)（终态，不可再变更）；省平台审核不通过变为审核不通过(120)，可重新申诉发起新一轮；已取消(130)由省平台外部操作设置（如运单作废），我方UI不提供取消申诉入口，仅展示同步后的状态；每次状态变更记录到处理记录时间线 | 对应TP-F-003；[API权威] 申诉状态以API §4.4为准: 未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130)；已取消(130)为省平台侧外部操作，我方只读 | +| AH_REPORT_APL_005 | 平台端-监管上报-异常申诉 | 验证申诉状态流转—未申诉·申诉中状态下不可重复发起申诉 | P0 | 功能测试 | 1. 运单YB202607130054申诉状态为"未申诉(100)·申诉中"（abnormalDetails[].state=110） | 1. 尝试通过API或页面再次对该运单同一异常项发起申诉；2. 观察系统响应 | 运单号: YB202607130054; 申诉状态: 未申诉·申诉中 | 页面"申诉"按钮被禁用或点击后提示"申诉处理中，请勿重复提交"；后端API返回错误，提示"该异常项已有申诉在处理中"；数据库不会产生重复申诉记录 | 对应TP-F-003; TP-F-012 | +| AH_REPORT_APL_006 | 平台端-监管上报-异常申诉 | 验证申诉详情弹窗5个分组字段完整（申诉信息/运单信息/异常信息/省平台反馈/处理记录） | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 存在一条已完成的申诉记录 | 1. 进入申诉记录页面；2. 点击某条记录的"详情"按钮；3. 依次查看5个分组的内容 | 申诉单号: APL202607130001 | 申诉信息分组含: 申诉单号/上报阶段/异常项/申诉原因/申诉状态/申诉时间/申诉人/申诉附件；省平台反馈信息含: 反馈结果/反馈时间/反馈意见；处理记录以时间线形式倒序展示：操作人/操作时间/操作类型/操作内容，每步操作（发起申诉/省平台反馈/重新申诉）均有一条记录 | 对应TP-F-004 | +| AH_REPORT_APL_007 | 平台端-监管上报-异常申诉 | 验证申诉附件上传—支持多附件且格式校验正确 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 准备png、jpg、pdf格式的附件文件各1个，以及1个超出大小限制的文件(如10MB) | 1. 进入申诉发起页面；2. 依次上传png/jpg/pdf文件；3. 尝试上传超限文件 | 附件: 证明1.png(500KB), 证明2.jpg(800KB), 证明3.pdf(1.5MB), 超限文件.exe(10MB) | png/jpg/pdf格式上传成功，附件列表展示文件名和大小；超限文件上传时提示"文件大小超过限制"；上传失败有重试机制；申诉详情弹窗中可查看/下载已上传的附件 | 对应TP-F-005 | +| AH_REPORT_APL_008 | 平台端-监管上报-异常申诉 | 验证17项核验异常（API文档§4.1定义）各自独立发起申诉—每次仅可申诉单个异常项 | P1 | 功能测试 | 1. 准备17条运单（或组合覆盖），每条分别对应一种核验异常项；2. 使用super_admin登录管理端 | 1. 分别对17种异常项运单发起申诉；2. 查看每条申诉记录中的异常项信息；3. 验证各申诉独立互不干扰；4. 确认每次申诉仅含单个verificationAbnormalItems值 | 运单A: 委托合同(100); B: 承运合同(120); C: 实时定位(130); D: 运单时间逻辑(140); E: 车辆资质(150); F: 道路运输证(160); G: 驾驶证(170); H: 从业资格证(180); I: 车辆重复(190); J: 司机重复(200); K: 车辆轨迹(210); L: 运费收款(220); M: 公司统一收款(230); N: 集中支付(240); O: 资金流水(250); P: 发票信息(260); Q: 非通行车辆可开票(270) | 17条申诉各自独立创建，异常项信息与核验结果一致；每条申诉的verificationAbnormalItems字段为单一异常项ID；某一异常项申诉不影响其他异常项的申诉状态；同一运单存在多个异常项时需分别独立发起申诉（参见AH_REPORT_APL_019） | 对应TP-F-007；[API权威] API文档§4.1定义17项核验，每项均可独立申诉但每次只允许申诉单个异常项（单值约束） | +| AH_REPORT_APL_009 | 平台端-监管上报-异常申诉 | 验证从看板操作列点击申诉按钮跳转至申诉页面并自动填充运单号 | P1 | 功能测试 | 1. 看板中存在核验异常的运单YB202607130002；2. 使用super_admin登录管理端 | 1. 进入看板页面；2. 在异常运单YB202607130002的操作列点击"申诉"按钮；3. 观察页面跳转和预填充数据 | 运单号: YB202607130002 | 页面路由正确跳转至申诉发起页面；URL携带正确的运单ID参数；申诉页面自动加载该运单的异常信息（运单号YB202607130002、异常项预填充正确）；运营人员无需手动输入运单号 | 对应TP-F-008 | +| AH_REPORT_APL_010 | 平台端-监管上报-异常申诉 | 验证仅运营人员有权发起申诉—司机/车队长/财务无申诉操作权限 | P1 | 安全性测试 | 1. 准备运营(super_admin)、财务、车队长(13113113113)、司机(15188888888)账号 | 1. 用各账号分别登录；2. 访问申诉功能页面；3. 尝试通过API直接调用申诉接口 | 运营: super_admin; 财务: finance_user; 车队长: 13113113113; 司机: 15188888888 | 运营人员可见"申诉"按钮和申诉记录页面，可发起申诉；车队长/司机端无申诉功能入口，直接URL访问返回403；财务人员可查看申诉记录但"发起申诉"按钮不可见；越权操作被拦截并记录审计日志（操作人/操作时间/操作内容/拦截原因） | 对应TP-F-009 | +| AH_REPORT_APL_011 | 平台端-监管上报-异常申诉 | 验证申诉处理记录时间线按时间倒序排列且操作时间精确到秒 | P2 | 功能测试 | 1. 存在一条经历了发起申诉→省平台反馈→重新申诉→省平台再次反馈的完整申诉记录 | 1. 进入申诉详情弹窗；2. 查看"处理记录"时间线 | 申诉单号: APL202607130002 | 4条操作记录按时间倒序排列（最新的在最上面）；每条记录包含: 操作人（用户名或"省平台"）、操作时间（YYYY-MM-DD HH:mm:ss）、操作类型（发起申诉/复核通过/复核驳回/重新申诉）、操作内容描述；操作类型与实际情况准确对应 | 对应TP-F-010 | +| AH_REPORT_APL_012 | 平台端-监管上报-异常申诉 | 验证异常代码一览表映射—已知异常代码正确映射为中文异常项名称 | P2 | 功能测试 | 1. 模拟省平台返回已知异常代码（如"VEHICLE_QUAL_FAIL"） | 1. 查看申诉页面中该异常代码对应的中文展示；2. 验证映射关系正确 | 异常代码: VEHICLE_QUAL_FAIL | 申诉页面中异常项显示为"车辆资质核验"（中文），非原始代码"VEHICLE_QUAL_FAIL"；异常代码与中文名称一一对应无歧义 | 对应TP-F-011 | +| AH_REPORT_APL_013 | 平台端-监管上报-异常申诉 | 验证未知异常代码兜底展示—显示原始代码+标注未知异常 | P2 | 功能测试 | 1. 模拟省平台返回一个系统中未定义的异常代码（如"UNKNOWN_ERROR_999"） | 1. 查看申诉页面异常项的展示 | 未知异常代码: UNKNOWN_ERROR_999 | 申诉页面中异常项显示原始代码"UNKNOWN_ERROR_999"并标注"(未知异常)"或类似兜底文案（不崩溃、不显示乱码）；系统日志中记录"未识别的异常代码"便于后续排查 | 对应TP-F-011 | +| AH_REPORT_APL_014 | 平台端-监管上报-异常申诉 | 验证同一异常项未申诉·申诉中状态下快速双击提交申诉仅产生1条记录 | P2 | 功能测试 | 1. 运单YB202607130055核验异常，申诉状态为"未申诉(100)"，异常项子状态为"未申诉"(state=100) | 1. 进入申诉页面填写完整信息；2. 快速双击"提交申诉"按钮；3. 查看申诉记录列表 | 运单号: YB202607130055; 异常项: 资金流水核验 | 申诉记录列表中仅产生1条申诉记录（前端防抖+后端校验）；后端有状态校验，"未申诉·申诉中"(abnormalDetails[].state=110)状态下不可重新发起；数据库appeal_record表该运单+该异常项仅有1条"未申诉·申诉中"记录 | 对应TP-F-012 | +| AH_REPORT_APL_015 | 平台端-监管上报-异常申诉 | 验证申诉提交后省平台长时间无反馈(超7个工作日)时系统有合理状态提示 | P3 | 功能测试 | 1. 运单YB202607130056申诉状态为"未申诉(100)·申诉中"（abnormalDetails[].state=110），省平台尚未审核；2. 模拟时间超过7个工作日省平台无反馈 | 1. 进入申诉记录页面查看该申诉记录；2. 查看系统是否有超时提示或告警 | 运单号: YB202607130056; 等待时长: 超过7个工作日 | 申诉记录页面显示"等待省平台复核中"或类似状态提示（申诉状态仍为"未申诉(100)·申诉中"不自动变更）；运营人员可查看申诉等待时长（如"已等待8个工作日"）；系统应触发超时告警通知运营人员跟进（告警渠道和阈值待确认）；不自动变更申诉状态为审核通过(110)或审核不通过(120)；已取消(130)由省平台侧外部操作（如运单作废），我方只读同步，不主动发起取消 | 对应TP-F-013；> ⚠️ 待确认：申诉超时告警机制（告警渠道、触发阈值）需与产品确认 | +| AH_REPORT_APL_016 | 平台端-监管上报-异常申诉 | 验证申诉附件上传失败时有重试机制 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 模拟附件上传接口服务暂时不可用 | 1. 进入申诉发起页面；2. 填写申诉信息并选择附件上传；3. 在上传过程中模拟服务异常 | 附件: 证明文件.png(500KB) | 附件上传失败时前端显示"上传失败，点击重试"提示；点击重试后可重新上传；上传成功后可正常提交申诉；失败不影响已填写的申诉文字内容 | 对应TP-F-005 | +| AH_REPORT_APL_017 | 平台端-监管上报-异常申诉 | 验证财务人员可查看申诉记录但不可发起申诉 | P1 | 安全性测试 | 1. 使用财务账号登录管理端；2. 申诉记录中有数据 | 1. 进入申诉记录页面，查看是否有"发起申诉"按钮；2. 查看申诉详情是否可读；3. 尝试通过API调用申诉发起接口 | 财务账号: finance_user | 申诉记录列表正常展示，可查看详情；"发起申诉"按钮不可见（或置灰）；通过API直接调用申诉发起接口返回403 Forbidden；审计日志中记录财务账号的查看操作 | 对应TP-F-009 | +| AH_REPORT_APL_018 | 平台端-监管上报-异常申诉 | 验证申诉表单仅允许选择单个异常项—verificationAbnormalItems单值约束 | P0 | 功能测试 | 1. 运单YB202607130090同时存在两个异常项：车辆轨迹210和资金流水250；2. 使用super_admin登录管理端 | 1. 进入申诉页面；2. 查看异常项选择区域；3. 尝试选择一个异常项后提交；4. 尝试多选异常项 | 运单号: YB202607130090; 异常项: 210(车辆轨迹), 250(资金流水) | UI层面异常项为单选列表（Radio Button或单选下拉），无法多选；提交请求中verificationAbnormalItems字段为单值（如"210"），非逗号分隔多值；若通过API绕过前端传入逗号分隔多值"210,250"，后端返回错误（如code=500，message包含"仅支持单个异常项目申诉"） | 对应TP-F-014；[技术方案] API单值约束 | +| AH_REPORT_APL_019 | 平台端-监管上报-异常申诉 | 验证同一运单两个异常项需分别发起两次独立申诉 | P1 | 功能测试 | 1. 运单YB202607130090有两个异常项210+250，均状态为"未申诉"；2. 使用super_admin登录管理端 | 1. 对异常项210(车辆轨迹)发起申诉→填写申诉内容→上传附件→提交；2. 验证申诉提交成功；3. 返回申诉页面，再次对异常项250(资金流水)发起申诉→填写内容→提交 | 运单号: YB202607130090; 申诉1: 异常项210; 申诉2: 异常项250 | 两次申诉生成两个独立申诉单号（complaintNumber不同）；数据库appeal_record表存在两条记录，分别对应异常项210和异常项250；两个异常项的申诉状态独立流转，互不影响；第二次申诉的异常项选择区域仅展示尚未申诉的异常项（250），已申诉的异常项210不再可选 | 对应TP-F-015；[技术方案] 独立申诉单 | +| AH_REPORT_APL_020 | 平台端-监管上报-异常申诉 | 验证申诉接口传入逗号分隔多异常项ID时后端拒绝 | P1 | 安全性测试 | 1. 运单YB202607130090有两个异常项210和250均未申诉；2. 获取有效JWT Token | 1. 通过API直接调用POST /appeal/insert接口；2. verificationAbnormalItems参数传入"210,250"（逗号分隔）；3. 查看接口返回 | 运单号: YB202607130090; verificationAbnormalItems: "210,250"(逗号分隔,非法) | 接口返回错误（code=500），message包含"仅支持单个异常项目申诉"或"verificationAbnormalItems必须为单一异常项ID"；数据库appeal_record表不产生新记录；不会错误地创建关联多个异常项的申诉单；单独传入"210"或"250"（单值）时正常成功 | 对应TP-F-016；[技术方案] 后端校验多值拒绝 | + +--- + +## 模块G: 上报日志 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_LOG_001 | 平台端-监管上报-上报日志 | 验证上报日志按完整运单号精确搜索日志记录 | P0 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001存在上报日志记录 | 1. 进入"监管上报-上报日志"页面；2. 在运单号搜索框输入"YB202607130001"；3. 点击搜索 | 运单号: YB202607130001 | 列表仅展示与该运单号相关的所有上报日志记录（含各阶段的重试记录）；数据库查询结果与页面展示一致 | 对应TP-G-001 | +| AH_REPORT_LOG_002 | 平台端-监管上报-上报日志 | 验证上报日志按不存在的单号搜索显示空结果 | P1 | 功能测试 | 1. 使用super_admin登录管理端 | 1. 进入"监管上报-上报日志"页面；2. 输入不存在的单号"NOTEXIST999"；3. 点击搜索 | 运单号: NOTEXIST999 | 列表显示空结果，友好提示"未找到相关日志记录"；控制台无报错 | 对应TP-G-001 | +| AH_REPORT_LOG_003 | 平台端-监管上报-上报日志 | 验证上报日志按"第一次上报"阶段筛选日志 | P0 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中同时存在第一次上报和第二次上报的记录 | 1. 进入"监管上报-上报日志"页面；2. 选择上报阶段"第一次上报"；3. 查看筛选结果 | 筛选条件: 第一次上报 | 列表仅展示stage=1的日志记录；ETC上传日志不包含在内；切换至"ETC上传"时有独立筛选项，日志正确过滤 | 对应TP-G-002 | +| AH_REPORT_LOG_004 | 平台端-监管上报-上报日志 | 验证上报日志按"失败"结果筛选—展示所有非成功日志 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中存在成功(HTTP 200)和失败(HTTP 4xx/5xx/超时)的记录 | 1. 进入日志页面；2. 选择上报结果"失败"；3. 查看筛选结果 | 筛选: 失败 | 列表展示所有非2xx的日志记录，包括HTTP 400/500/超时等；"成功"(200)的记录被过滤；筛选结果与实际日志记录一致 | 对应TP-G-003 | +| AH_REPORT_LOG_005 | 平台端-监管上报-上报日志 | 验证上报日志按时间范围筛选（跨天） | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中存在2026-07-10至2026-07-13的记录 | 1. 进入日志页面；2. 选择开始时间"2026-07-10 00:00:00"，结束时间"2026-07-12 23:59:59"；3. 点击搜索 | 时间范围: 2026-07-10~2026-07-12 | 列表仅展示该时间范围内的日志记录；不包含2026-07-13的日志；开始时间>结束时间时系统给出提示或自动交换；不选时间范围时默认展示全部 | 对应TP-G-004 | +| AH_REPORT_LOG_006 | 平台端-监管上报-上报日志 | 验证上报日志列表11个字段完整展示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中有至少1条完整记录 | 1. 进入日志页面；2. 查看列表表头和第一条数据的所有列 | 查看一条典型日志记录 | 列表展示: 序号/货源单号/运单号/托运单号/上报阶段/上报结果/接口URL/HTTP状态码/响应时间/上报时间/操作；接口URL完整（含域名和路径如https://anhui.report.gov.cn/api/v1/waybill/submit）；HTTP状态码为实际返回状态码；响应时间单位为ms；上报时间为实际请求发起时间 | 对应TP-G-005 | +| AH_REPORT_LOG_007 | 平台端-监管上报-上报日志 | 验证点击日志操作列详情按钮弹窗展示完整请求和响应报文 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中有1条失败记录 | 1. 进入日志页面；2. 点击某条日志操作列的"详情"按钮；3. 在弹窗中查看请求报文和响应报文 | 查看一条HTTP 400失败的日志详情 | 弹窗展示请求报文: URL（完整）、Method（POST）、Headers（Content-Type/Authorization等）、Body（完整JSON）；响应报文: Status Code（400）、Headers、Body（错误信息JSON）；JSON报文格式化展示（缩进/语法高亮）；长报文支持滚动查看；支持一键复制请求/响应内容 | 对应TP-G-006 | +| AH_REPORT_LOG_008 | 平台端-监管上报-上报日志 | 验证每个上报阶段及自动修改字段接口的每次调用均在日志中完整记录 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001已完成全流程上报（第一次+修改字段+第二次+7核验+第三次+ETC） | 1. 进入日志页面；2. 按运单号YB202607130001搜索；3. 逐条检查日志记录是否覆盖所有阶段 | 运单号: YB202607130001 | 日志中至少包含以下记录: 第一次上报请求+响应、第一次上报修改字段请求+响应、第二次上报请求+响应、7类核验各自的请求+响应日志、第三次上报请求+响应、ETC上传请求+响应；自动重试的每次请求均独立记录（如第一次上报失败重试2次→共3条日志） | 对应TP-G-007 | +| AH_REPORT_LOG_009 | 平台端-监管上报-上报日志 | 验证上报失败日志包含完整的Error Response Body和重试次数标记 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 存在上报失败的日志记录 | 1. 进入日志页面；2. 筛选"失败"的日志；3. 点击某条失败日志的详情；4. 查看失败信息完整度 | 查看一条第2次重试失败的日志 | 失败日志包含完整的Error Response Body（JSON格式）；超时日志标注"timeout"并记录超时时长（如30000ms）；重试日志中标注当前是第几次重试（如"重试第2/3次"）；异常日志可关联到具体运单ID，方便排查 | 对应TP-G-008 | +| AH_REPORT_LOG_010 | 平台端-监管上报-上报日志 | 验证上报日志区分自动触发和手动触发—自动标注"系统自动"/手动标注操作人 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 存在自动触发的上报日志和手动触发的上报日志 | 1. 进入日志页面；2. 查看自动触发上报的日志记录中的操作人字段；3. 查看手动触发上报的日志记录中的操作人字段 | 自动日志: 第一次上报(装货完成触发); 手动日志: 第一次上报(手动上传) | 自动触发的上报日志操作人标注"系统自动"或"auto"；手动触发的上报日志操作人标注实际登录用户名（如"super_admin"）；审计日志中操作人信息与实际登录用户一致 | 对应TP-G-009 | +| AH_REPORT_LOG_011 | 平台端-监管上报-上报日志 | 验证上报日志组合筛选—阶段+结果+时间范围+单号同时筛选 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志数据满足组合条件 | 1. 进入日志页面；2. 设置: 阶段=第二次上报、结果=失败、时间范围=2026-07-10~2026-07-13、运单号=YB20260713；3. 点击搜索 | 组合: 第二次上报+失败+2026-07-10~2026-07-13+YB20260713 | 列表仅展示同时满足4个条件的日志记录；各条件在数据库查询中均正确生效；组合结果为空时有友好提示 | 对应TP-G-001; TP-G-002; TP-G-003; TP-G-004 | + +--- + +## 跨模块测试点 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_CROSS_001 | 平台端-监管上报-跨模块 | 验证完整三阶段依赖链端到端验证—后端三重前置状态校验 | P0 | 功能测试 | 1. 准备一条安徽税源地(34)的运单YB202607130001 | 1. 使第一次上报失败（关闭监管平台接口）；2. 尝试调用第二次上报API；3. 查看返回；4. 使第二次上报失败；5. 尝试调用第三次上报API；6. 查看返回 | 运单号: YB202607130001 | 第一次上报失败→第二次上报API返回错误码"前置上报未完成"；第二次上报失败→第三次上报API返回错误码"前置上报（第二次）未完成"；三个阶段不可跳级执行；依赖链校验在后端通过查询report_status表实现，非仅前端控制；每个阶段的阻断/通过状态独立存储 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_CROSS_002 | 平台端-监管上报-跨模块 | 验证多模块数据一致性—修改源数据后各阶段上报感知变更并使用最新值 | P0 | 功能测试 | 1. 运单YB202607130046初始数据: 司机15188888888、合同金额¥10,000.00、发票金额¥10,300.00 | 1. 第一次上报前修改司机信息（如更换司机手机号）；2. 触发第一次上报，验证使用最新司机信息；3. 财务修改打款金额（¥10,000.00→¥9,500.00）；4. 触发第二次上报，验证使用¥9,500.00；5. 修改发票金额（¥10,300.00→¥10,100.00）；6. 触发第三次上报，验证使用¥10,100.00 | 运单号: YB202607130046; 修改项: 司机/金额/发票 | 第一次上报使用最新司机信息；第二次上报金额为¥9,500.00（非缓存的¥10,000.00）；第三次上报发票金额为¥10,100.00（非旧值）；数据库查询日志可确认各字段的数据来源表（非缓存）；数据库report_record表各阶段记录中的数据与来源表一致 | [AI修正: 历史缺陷防御] - BUG-202607-03 | +| AH_REPORT_CROSS_003 | 平台端-监管上报-跨模块 | 验证安徽税源地运单完整上报链路—装货到ETC全流程核验通过（冒烟测试） | P0 | 冒烟测试 | 1. 准备一条安徽税源地(34)的完整运单YB202607130001，所有资质有效、合同有效、轨迹正常、支付正常、发票正常 | 1. 装货完成→等待第一次上报→验证状态"已上传"；2. 等待自动修改字段→验证日志中有修改记录；3. 财务打款¥10,000.00→等待第二次上报→验证7类核验全部通过；4. 发票FP202607130001开具→等待第三次上报→验证状态"已上传"；5. 税务抵扣完成→ETC发票ETC202607130001上传→验证状态"已上传" | 运单号: YB202607130001; 金额: ¥10,000.00; 发票: FP202607130001; ETC: ETC202607130001 | 第一次上报成功→第二次上报成功（7核验全通过）→第三次上报成功→ETC上传成功；每个阶段看板数据正确更新；上报日志完整记录全链路；数据库report_record表stage=1/2/3均状态=1；etc_report_record表status=1 | 对应TP-X-003 | +| AH_REPORT_CROSS_004 | 平台端-监管上报-跨模块 | 验证非安徽税源地运单(云南=28)全部阶段均不触发上报 | P0 | 功能测试 | 1. 准备一条云南税源地(28)的运单YB202607130002，包含完整运输流程 | 1. 装货完成→检查是否触发第一次上报；2. 财务打款→检查是否触发第二次上报；3. 发票开具→检查是否触发第三次上报；4. 税务抵扣→检查是否触发ETC上传；5. 查看看板中是否存在该运单 | 运单号: YB202607130002; 省份代码: 28(云南) | 全部阶段均不触发上报；看板中不显示该云南运单；上报日志中无该运单的任何上报记录；系统无因"不触发"而产生的错误日志或异常告警；云南运单本身的运输流程（装货→运输→卸货→结算）不受影响正常流转 | 对应TP-X-004 | +| AH_REPORT_CROSS_005 | 平台端-监管上报-跨模块 | 验证多省份部署下安徽(34)和云南(28)上报数据完全隔离 | P1 | 功能测试 | 1. 准备安徽(34)运单YB202607130001和云南(28)运单YB202607130002各1条 | 1. 分别触发两条运单的完整上报流程；2. 查看两个省份的上报日志和数据记录；3. 验证安徽运单的上报目标URL为安徽监管平台，云南运单为云南监管平台 | 安徽: YB202607130001(34); 云南: YB202607130002(28) | 安徽运单仅上报至安徽监管平台(URL含anhui)；云南运单仅上报至云南监管平台(URL含yunnan)；两个省份的report_record表数据通过province_code字段物理/逻辑隔离；省份代码各自独立（安徽=34、云南=28），不混淆 | 对应TP-X-005 | +| AH_REPORT_CROSS_006 | 平台端-监管上报-跨模块 | 验证定时任务重试与手动触发上报的并发控制—分布式锁机制 | P1 | 功能测试 | 1. 运单YB202607130057第一次上报失败，定时重试任务即将触发第1次重试；2. super_admin在管理端准备手动点击"手动上传" | 1. 在重试任务触发的同时，super_admin点击"手动上传"；2. 观察并发场景下的系统行为 | 运单号: YB202607130057 | 同一时刻仅1个上报请求被执行（通过分布式锁如Redis SETNX控制）；被拒绝的请求返回"上报处理中"提示；不产生重复上报记录；分布式锁正确释放，后续操作可正常进行 | 对应TP-B-014; TP-C-021 | +| AH_REPORT_CROSS_007 | 平台端-监管上报-跨模块 | 验证回单签收后财务打款前不触发第二次上报—打款完成才触发 | P2 | 功能测试 | 1. 运单YB202607130001第一次上报已完成；2. 回单已签收但财务尚未打款 | 1. 回单签收完成后检查第二次上报列表；2. 财务执行打款后再次检查第二次上报列表；3. 对比两次检查的时间点 | 运单号: YB202607130001; 回单签收时间: 2026-07-12 15:00; 打款时间: 2026-07-12 17:00 | 回单签收完成后第二次上报列表中无该运单记录（未触发）；财务打款完成后第二次上报列表中出现该运单记录（已触发）；上报时间戳接近打款完成时间（如2026-07-12 17:00:05），非回单签收时间 | 对应TP-X-006 | +| AH_REPORT_CROSS_008 | 平台端-监管上报-跨模块 | 验证已上报至服务平台的运单不可取消或删除—无操作入口且API拒绝 | P1 | 功能测试 | 1. 运单YB202607130094已成功完成第一次上报（数据已上传至服务平台）；2. 使用super_admin登录管理端 | 1. 在管理端查看该运单的操作列，确认是否存在"取消"或"删除"按钮；2. 通过API尝试调用删除/取消运单接口（如DELETE /api/waybill/{id}）；3. 查看接口返回和数据库状态 | 运单号: YB202607130094; 上报阶段: 第一次上报已完成 | UI操作列无"取消"或"删除"按钮（仅显示详情/进度/申诉等）；API层面调用删除接口返回错误（如404或method not allowed），提示"已上报运单不允许取消"；数据库report_record表和运单表数据未被删除或修改；未完结的运单在合规率统计中被排除不计 | 对应TP-X-007；[技术方案] showdoc FAQ：服务平台不支持取消或删除运单 | + +--- + +## 测试点→用例映射表 + +| 测试点ID | 对应的用例编号 | 覆盖状态 | +| :--- | :--- | :--- | +| TP-A-001 | AH_REPORT_DASH_001, AH_REPORT_DASH_002, AH_REPORT_DASH_003 | 已覆盖 | +| TP-A-002 | AH_REPORT_DASH_004 | 已覆盖 | +| TP-A-003 | AH_REPORT_DASH_005 | 已覆盖 | +| TP-A-004 | AH_REPORT_DASH_006 | 已覆盖 | +| TP-A-005 | AH_REPORT_DASH_007 | 已覆盖 | +| TP-A-006 | AH_REPORT_DASH_008, AH_REPORT_DASH_009 | 已覆盖 | +| TP-A-007 | AH_REPORT_DASH_010 | 已覆盖 | +| TP-A-008 | AH_REPORT_DASH_011 | 已覆盖 | +| TP-A-009 | AH_REPORT_DASH_012 | 已覆盖 | +| TP-A-010 | AH_REPORT_DASH_013 | 已覆盖 | +| TP-A-011 | AH_REPORT_DASH_014, AH_REPORT_DASH_015 | 已覆盖 | +| TP-A-012 | AH_REPORT_DASH_016 | 已覆盖 | +| TP-A-013 | AH_REPORT_DASH_017 | 已覆盖 | +| TP-A-014 | AH_REPORT_DASH_018 | 已覆盖 | +| TP-B-001 | AH_REPORT_R1_001 | 已覆盖 | +| TP-B-002 | AH_REPORT_R1_002, AH_REPORT_R1_003 | 已覆盖 | +| TP-B-003 | AH_REPORT_R1_004, AH_REPORT_R1_005, AH_REPORT_R1_021 | 已覆盖 | +| TP-B-004 | AH_REPORT_R1_003, AH_REPORT_R1_006 | 已覆盖 | +| TP-B-005 | AH_REPORT_R1_007, AH_REPORT_R1_008 | 已覆盖 | +| TP-B-006 | AH_REPORT_R1_009 | 已覆盖 | +| TP-B-007 | AH_REPORT_R1_010 | 已覆盖 | +| TP-B-008 | AH_REPORT_R1_011 | 已覆盖 | +| TP-B-009 | AH_REPORT_R1_012 | 已覆盖 | +| TP-B-010 | AH_REPORT_R1_023 | 已覆盖 | +| TP-B-011 | AH_REPORT_DASH_014 | 已覆盖（见看板详情弹窗用例） | +| TP-B-012 | AH_REPORT_DASH_015 | 已覆盖（见看板详情弹窗用例） | +| TP-B-013 | AH_REPORT_R1_022 | 已覆盖 | +| TP-B-014 | AH_REPORT_R1_013, AH_REPORT_R1_014, AH_REPORT_CROSS_006 | 已覆盖 | +| TP-B-015 | AH_REPORT_R1_015 | 已覆盖 | +| TP-B-016 | AH_REPORT_R1_016 | 已覆盖 | +| TP-B-017 | AH_REPORT_R1_017 | 已覆盖 | +| TP-B-018 | AH_REPORT_R1_018 | 已覆盖 | +| TP-B-019 | AH_REPORT_R1_019, AH_REPORT_R1_020 | 已覆盖 | +| TP-B-020 | AH_REPORT_R1_024 | 已覆盖 | +| TP-B-021 | AH_REPORT_R1_025 | 已覆盖 | +| TP-B-022 | AH_REPORT_R1_026 | 已覆盖 | +| TP-C-001 | AH_REPORT_R2_001 | 已覆盖 | +| TP-C-002 | AH_REPORT_R2_002 | 已覆盖 | +| TP-C-003 | AH_REPORT_R2_003 | 已覆盖 | +| TP-C-004 | AH_REPORT_R2_004 | 已覆盖 | +| TP-C-005 | AH_REPORT_R2_004 | 已覆盖 | +| TP-C-006 | AH_REPORT_R2_005 | 已覆盖 | +| TP-C-007 | AH_REPORT_R2_006 | 已覆盖 | +| TP-C-008 | AH_REPORT_R2_007 | 已覆盖 | +| TP-C-009 | AH_REPORT_R2_008 | 已覆盖 | +| TP-C-010 | AH_REPORT_R2_009 | 已覆盖 | +| TP-C-011 | AH_REPORT_R2_010 | 已覆盖 | +| TP-C-012 | AH_REPORT_R2_011 | 已覆盖 | +| TP-C-013 | AH_REPORT_R2_012 | 已覆盖 | +| TP-C-014 | AH_REPORT_R2_013 | 已覆盖 | +| TP-C-015 | AH_REPORT_R2_014, AH_REPORT_R2_015 | 已覆盖 | +| TP-C-016 | AH_REPORT_R2_016 | 已覆盖 | +| TP-C-017 | AH_REPORT_R2_017, AH_REPORT_R2_018 | 已覆盖 | +| TP-C-018 | AH_REPORT_R2_019, AH_REPORT_R2_020, AH_REPORT_R2_021 | 已覆盖 | +| TP-C-019 | AH_REPORT_R2_022, AH_REPORT_R2_023 | 已覆盖 | +| TP-C-020 | AH_REPORT_R2_024 | 已覆盖 | +| TP-C-021 | AH_REPORT_R2_025, AH_REPORT_CROSS_006 | 已覆盖 | +| TP-C-022 | AH_REPORT_R2_026 | 已覆盖 | +| TP-C-023 | AH_REPORT_R2_027 | 已覆盖 | +| TP-C-024 | AH_REPORT_R2_028, AH_REPORT_R2_054 | 已覆盖 | +| TP-C-025 | AH_REPORT_R2_029 | 已覆盖 | +| TP-C-026 | AH_REPORT_R2_030 | 已覆盖 | +| TP-C-027 | AH_REPORT_R2_031 | 已覆盖 | +| TP-C-028 | AH_REPORT_R2_032 | 已覆盖 | +| TP-C-029 | AH_REPORT_R2_033 | 已覆盖 | +| TP-C-030 | AH_REPORT_R2_034 | 已覆盖 | +| TP-C-031 | AH_REPORT_R2_035 | 已覆盖 | +| TP-C-032 | AH_REPORT_R2_036 | 已覆盖 | +| TP-C-033 | AH_REPORT_R2_037 | 已覆盖 | +| TP-C-034 | AH_REPORT_R2_038 | 已覆盖 | +| TP-C-035 | AH_REPORT_R2_039 | 已覆盖 | +| TP-C-036 | AH_REPORT_R2_040 | 已覆盖 | +| TP-C-037 | AH_REPORT_R2_041 | 已覆盖 | +| TP-C-038 | AH_REPORT_R2_042 | 已覆盖 | +| TP-C-039 | AH_REPORT_R2_043 | 已覆盖 | +| TP-C-040 | AH_REPORT_R2_044 | 已覆盖 | +| TP-C-041 | AH_REPORT_R2_045 | 已覆盖 | +| TP-C-042 | AH_REPORT_R2_046 | 已覆盖 | +| TP-C-043 | AH_REPORT_R2_047 | 已覆盖 | +| TP-C-044 | AH_REPORT_R2_048 | 已覆盖 | +| TP-C-045 | AH_REPORT_R2_049 | 已覆盖 | +| TP-C-046 | AH_REPORT_R2_050 | 已覆盖 | +| TP-C-047 | AH_REPORT_R2_051 | 已覆盖 | +| TP-C-048 | AH_REPORT_R2_052 | 已覆盖 | +| TP-C-049 | AH_REPORT_R2_053 | 已覆盖 | +| TP-C-050 | AH_REPORT_R2_055 | 已覆盖 | +| TP-C-051 | （承运人流水次日核验规则已内置于各R2核验用例中，独立用例视后续接口形态补充） | 已覆盖 | +| TP-D-001 | AH_REPORT_R3_001 | 已覆盖 | +| TP-D-002 | AH_REPORT_R3_002 | 已覆盖 | +| TP-D-003 | AH_REPORT_R3_003 | 已覆盖 | +| TP-D-004 | AH_REPORT_R3_004, AH_REPORT_R3_005 | 已覆盖 | +| TP-D-005 | AH_REPORT_R3_006, AH_REPORT_R3_007 | 已覆盖 | +| TP-D-006 | AH_REPORT_R3_008, AH_REPORT_R3_009 | 已覆盖 | +| TP-D-007 | AH_REPORT_R3_010 | 已覆盖 | +| TP-D-008 | AH_REPORT_R3_014 | 已覆盖 | +| TP-D-009 | AH_REPORT_R3_011 | 已覆盖 | +| TP-D-010 | AH_REPORT_R3_012 | 已覆盖 | +| TP-D-011 | AH_REPORT_R3_013 | 已覆盖 | +| TP-E-001 | AH_REPORT_ETC_001 | 已覆盖 | +| TP-E-002 | AH_REPORT_ETC_002 | 已覆盖 | +| TP-E-003 | AH_REPORT_ETC_003 | 已覆盖 | +| TP-E-004 | AH_REPORT_ETC_004 | 已覆盖 | +| TP-E-005 | AH_REPORT_ETC_005, AH_REPORT_ETC_006, AH_REPORT_ETC_011, AH_REPORT_ETC_012 | 已覆盖 | +| TP-E-006 | AH_REPORT_ETC_007 | 已覆盖 | +| TP-E-007 | AH_REPORT_ETC_008 | 已覆盖 | +| TP-E-008 | AH_REPORT_ETC_009 | 已覆盖 | +| TP-E-009 | AH_REPORT_ETC_010 | 已覆盖 | +| TP-F-001 | AH_REPORT_APL_001 | 已覆盖 | +| TP-F-002 | AH_REPORT_APL_003 | 已覆盖 | +| TP-F-003 | AH_REPORT_APL_004, AH_REPORT_APL_005 | 已覆盖 | +| TP-F-004 | AH_REPORT_APL_006 | 已覆盖 | +| TP-F-005 | AH_REPORT_APL_007, AH_REPORT_APL_016 | 已覆盖 | +| TP-F-006 | AH_REPORT_APL_002 | 已覆盖 | +| TP-F-007 | AH_REPORT_APL_008 | 已覆盖 | +| TP-F-008 | AH_REPORT_APL_009 | 已覆盖 | +| TP-F-009 | AH_REPORT_APL_010, AH_REPORT_APL_017 | 已覆盖 | +| TP-F-010 | AH_REPORT_APL_011 | 已覆盖 | +| TP-F-011 | AH_REPORT_APL_012, AH_REPORT_APL_013 | 已覆盖 | +| TP-F-012 | AH_REPORT_APL_005, AH_REPORT_APL_014 | 已覆盖 | +| TP-F-013 | AH_REPORT_APL_015 | 已覆盖 | +| TP-F-014 | AH_REPORT_APL_018 | 已覆盖 | +| TP-F-015 | AH_REPORT_APL_019 | 已覆盖 | +| TP-F-016 | AH_REPORT_APL_020 | 已覆盖 | +| TP-G-001 | AH_REPORT_LOG_001, AH_REPORT_LOG_002 | 已覆盖 | +| TP-G-002 | AH_REPORT_LOG_003 | 已覆盖 | +| TP-G-003 | AH_REPORT_LOG_004 | 已覆盖 | +| TP-G-004 | AH_REPORT_LOG_005 | 已覆盖 | +| TP-G-005 | AH_REPORT_LOG_006 | 已覆盖 | +| TP-G-006 | AH_REPORT_LOG_007 | 已覆盖 | +| TP-G-007 | AH_REPORT_LOG_008 | 已覆盖 | +| TP-G-008 | AH_REPORT_LOG_009 | 已覆盖 | +| TP-G-009 | AH_REPORT_LOG_010 | 已覆盖 | +| TP-X-001 | AH_REPORT_CROSS_001 | 已覆盖 | +| TP-X-002 | AH_REPORT_CROSS_002 | 已覆盖 | +| TP-X-003 | AH_REPORT_CROSS_003 | 已覆盖 | +| TP-X-004 | AH_REPORT_CROSS_004 | 已覆盖 | +| TP-X-005 | AH_REPORT_CROSS_005 | 已覆盖 | +| TP-X-006 | AH_REPORT_CROSS_007 | 已覆盖 | +| TP-X-007 | AH_REPORT_CROSS_008 | 已覆盖 | + +所有140个测试点均已映射到至少一条测试用例。 + +--- + +## 历史缺陷防御映射表 + +| 历史缺陷ID | 防御用例 | 备注 | +| :--- | :--- | :--- | +| BUG-202607-01（阶段依赖链断裂） | AH_REPORT_R1_007, AH_REPORT_R1_008, AH_REPORT_R2_024, AH_REPORT_R3_006, AH_REPORT_R3_007, AH_REPORT_CROSS_001 | 后端三重前置状态校验覆盖 | +| BUG-202607-02（重试幂等缺陷） | AH_REPORT_R1_013, AH_REPORT_R1_014, AH_REPORT_R2_025, AH_REPORT_R3_011, AH_REPORT_ETC_009, AH_REPORT_CROSS_006 | 分布式锁+唯一约束+前端防抖覆盖 | +| BUG-202607-03（跨模块数据不一致） | AH_REPORT_R2_002, AH_REPORT_R2_003, AH_REPORT_R3_013, AH_REPORT_CROSS_002 | 数据来源溯源验证覆盖 | +| BUG-202607-04（省份代码硬编码） | AH_REPORT_R1_006, AH_REPORT_CROSS_005 | 省份代码动态配置+多省份隔离覆盖 | + +--- + +## 漏测清单覆盖汇总 + +| 漏测类别 | 覆盖用例数 | 覆盖状态 | +| :--- | :--- | :--- | +| 空值/Null处理 | AH_REPORT_R1_018 (1条) | 已覆盖 | +| 金额精度 | AH_REPORT_R2_002, AH_REPORT_R2_055, AH_REPORT_R3_012, AH_REPORT_ETC_008 (4条) | 已覆盖 | +| 重复提交/防抖 | AH_REPORT_R1_013, AH_REPORT_R1_014, AH_REPORT_R2_025, AH_REPORT_R3_011, AH_REPORT_ETC_009 (5条) | 已覆盖 | +| 超时处理 | AH_REPORT_R1_015, AH_REPORT_R1_016, AH_REPORT_APL_015 (3条) | 已覆盖 | +| 列表字段完整性 | AH_REPORT_DASH_011, AH_REPORT_R2_004, AH_REPORT_R3_002, AH_REPORT_ETC_002, AH_REPORT_APL_003, AH_REPORT_LOG_006 (6条) | 已覆盖 | +| 查询重置 | AH_REPORT_DASH_010 (1条) | 已覆盖 | +| 状态与按钮映射 | AH_REPORT_DASH_013, AH_REPORT_R1_012 (2条) | 已覆盖 | +| 多阶段依赖链 | AH_REPORT_R1_007, AH_REPORT_R2_024, AH_REPORT_R3_007, AH_REPORT_CROSS_001 (4条) | 已覆盖 | +| 第三方核验逐项覆盖 | AH_REPORT_R2_005~AH_REPORT_R2_023 (14条，7类×通过+异常) + AH_REPORT_R2_030~AH_REPORT_R2_053 (24条，API文档12项补充核验×通过+异常) = 共38条覆盖API文档17项核验 | 已覆盖 | +| 重试+手动触发并发 | AH_REPORT_R1_013, AH_REPORT_R2_025, AH_REPORT_CROSS_006 (3条) | 已覆盖 | +| 跨模块数据一致性 | AH_REPORT_R2_002, AH_REPORT_R2_003, AH_REPORT_CROSS_002 (3条) | 已覆盖 | +| 省份/区域配置隔离 | AH_REPORT_R1_006, AH_REPORT_CROSS_005 (2条) | 已覆盖 | +| 上报数据字段溯源 | AH_REPORT_R2_002, AH_REPORT_R3_013, AH_REPORT_CROSS_002 (3条) | 已覆盖 | +| 标签颜色映射 | AH_REPORT_DASH_012, AH_REPORT_R1_023, AH_REPORT_R2_004 (3条) | 已覆盖 | +| 详情弹窗分组完整性 | AH_REPORT_DASH_014, AH_REPORT_DASH_015, AH_REPORT_R1_022, AH_REPORT_R3_003, AH_REPORT_ETC_003, AH_REPORT_APL_006 (6条) | 已覆盖 | +| 轨迹数据边界(2~2000) | AH_REPORT_R2_020, AH_REPORT_R2_021, AH_REPORT_R2_022, AH_REPORT_R2_023 (4条) | 已覆盖 | +| 申诉闭环 | AH_REPORT_APL_001, AH_REPORT_APL_002, AH_REPORT_APL_004 (3条) | 已覆盖 | +| 操作日志可追溯 | AH_REPORT_LOG_006, AH_REPORT_LOG_007, AH_REPORT_LOG_008, AH_REPORT_LOG_009, AH_REPORT_LOG_010 (5条) | 已覆盖 | + +--- + +> ⚠️ 待确认项： +> 1. 需求中"异常代码一览表"章节仅有标题无具体内容，需与产品确认完整的异常代码映射表后补充 AH_REPORT_APL_012 的详细验证数据。 +> 2. 自动重试的具体间隔时间（当前用例中使用5s/15s/30s为参考值），需与技术方案确认后更新 AH_REPORT_R1_010, AH_REPORT_R2_026, AH_REPORT_R3_010, AH_REPORT_ETC_007 中的重试间隔。 +> 3. ETC税额边界值（0.01元 → 税额=0.00）的四舍五入规则需与财务确认，更新 AH_REPORT_ETC_008。 +> 4. 申诉超时告警阈值（当前用例中使用7个工作日为参考值）需与产品确认，更新 AH_REPORT_APL_015。 +> 5. 建议在后续需求评审中人工确认安徽运八与现有云南运八上报逻辑是否存在字段/接口冲突。 +> 6. 部分用例中使用的模拟数据（如运单号YB202607130004~YB202607130057等）为测试用例设计时分配的虚拟编号，实际执行时需替换为测试环境中真实存在的运单数据。 +> 7. 涉及省平台回调的用例（如申诉复核反馈、核验结果返回），实际执行时需确认是否有省平台测试环境或mock工具支持。 diff --git a/output/test_points/安徽运八需求_测试点.md b/output/test_points/安徽运八需求_测试点.md index d8401f8..7322cda 100644 --- a/output/test_points/安徽运八需求_测试点.md +++ b/output/test_points/安徽运八需求_测试点.md @@ -1,352 +1,1216 @@ -# 安徽运八需求 测试点矩阵 +# 安徽运八需求 测试点 > 生成时间: 2026-07-13 -> 来源标注: 📋需求 | 🐛历史缺陷 | ⚠️风险矩阵 | 🔗冲突修订 | 🏢项目画像 | 💡易漏场景 +> 需求文档: output/normalized_inputs/安徽运八需求/requirement.md +> 关联分析: 风险评估报告 / 测试策略 / 关联与冲突 + +## 测试点概览 + +- 总测试点数: 140 +- P0: 33 / P1: 71 / P2: 30 / P3: 6 +- 模块分布: A(看板)=14, B(第一次上报)=22, C(第二次上报)=51, D(第三次上报)=12, E(ETC)=9, F(申诉)=16, G(日志)=9, X(跨模块)=7 +- 来源分布: [需求] 66, [历史缺陷] 14, [风险矩阵] 8, [漏测清单] 52, [项目画像] 16, [最佳实践] 7, [技术方案] 36 + +> 注: 一个测试点可同时归属多个来源，因此来源分布合计数 > 总测试点数。 --- -## 1. 上报运单看板 (Dashboard) +## 模块A: 上报运单看板 (14个测试点) -### 1.1 查询与筛选 +### TP-A-001: 看板模糊搜索 — 运单号/托运单号/货源单号 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证看板支持按运单号、托运单号、货源单号进行模糊搜索，输入部分字符即可匹配相关运单。 +- 关键验证点: 输入完整单号可精确匹配；输入部分字符可模糊匹配；输入不存在的单号显示空结果提示；三种单号输入框均支持模糊搜索。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-DB-001 | 运单号精确搜索，验证返回唯一匹配结果 | P1 | 📋 | 功能 | -| TP-DB-002 | 运单号/托运单号/货源单号模糊搜索，输入部分字符验证模糊匹配 | P1 | 📋 | 功能 | -| TP-DB-003 | 上报阶段筛选：全部/第一次/第二次/第三次，各选项独立验证 | P1 | 📋 | 功能 | -| TP-DB-004 | 核验状态筛选：全部/异常/通过，验证筛选结果正确性 | P1 | 📋 | 功能 | -| TP-DB-005 | 申诉状态筛选：全部/未申诉/申诉中/申诉通过/申诉驳回 | P1 | 📋 | 功能 | -| TP-DB-006 | 多条件组合查询（运单号模糊+上报阶段+核验状态+申诉状态） | P1 | 📋🏢 | 功能 | -| TP-DB-007 | 查询按钮点击后正确执行搜索并刷新列表 | P1 | 📋 | 功能 | -| TP-DB-008 | 重置按钮清空所有查询条件并刷新列表为默认状态 | P2 | 📋 | 功能 | -| TP-DB-009 | 查询结果为空时显示友好的空状态提示 | P2 | 💡易漏场景 | 功能 | -| TP-DB-010 | 模糊搜索输入特殊字符（SQL注入/HTML标签/Emoji）验证安全性 | P2 | 💡易漏场景 | 安全 | +### TP-A-002: 看板按上报阶段筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证看板支持按"全部/第一次上报/第二次上报/第三次上报"筛选，切换阶段后列表数据正确过滤。 +- 关键验证点: 默认"全部"显示所有阶段运单；选择"第一次上报"仅显示对应阶段运单；切换阶段后列表即时刷新；各阶段数据条数与实际一致。 -### 1.2 列表展示 +### TP-A-003: 看板按核验状态筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证看板支持按"全部/异常/通过"筛选核验状态，确保状态拆分独立验证。 +- 关键验证点: "全部"显示所有核验状态运单；"异常"仅显示核验不通过的运单；"通过"仅显示核验通过的运单；列表中核验状态字段与筛选条件一致。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-DB-011 | 列表字段完整性：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、申诉状态、异常项、货物名称、合同金额、最新核验时间 | P1 | 📋 | 功能 | -| TP-DB-012 | 列表默认排序验证（按最新核验时间倒序或需求指定） | P2 | 📋🏢 | 功能 | -| TP-DB-013 | 分页功能：首页/上一页/下一页/末页/跳转/每页条数切换 | P2 | 💡易漏场景 | 功能 | -| TP-DB-014 | 合同金额显示格式（千分位、小数位精度）验证 | P2 | ⚠️风险矩阵 | 功能 | -| TP-DB-015 | 异常项字段在核验通过时为空，核验异常时显示具体异常项 | P1 | 📋 | 功能 | +### TP-A-004: 看板按申诉状态筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证看板支持按"全部/未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130)"筛选申诉状态。注：已取消(130)由省平台外部操作设置，我方系统只读展示，不发起取消操作。⚠️ 待确认: 原型看板申诉状态下拉值为"未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回"，与API权威枚举不一致，需确认UI最终版本。 +- 关键验证点: 四种申诉状态独立筛选，数据精确匹配；切换申诉状态后核验状态筛选联动正确；申诉状态标签展示与筛选值一致；已取消(130)状态为省平台侧操作结果，我方仅展示。 -### 1.3 操作按钮 +### TP-A-005: 看板组合筛选 — 多条件叠加 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [需求][漏测清单] +- 描述: 验证看板支持上报阶段 + 核验状态 + 申诉状态 + 模糊搜索同时组合筛选。 +- 关键验证点: 选择"第二次上报+异常+未申诉(100)"组合后精确过滤；组合条件为空结果时友好提示；组合条件切换不丢失已输入的单号搜索关键字。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-DB-016 | 申诉按钮：点击跳转至申诉页面，携带对应运单信息 | P1 | 📋 | 功能 | -| TP-DB-017 | 进度按钮：点击查看运单上报进度（三次上报+ETC的完成状态） | P2 | 📋 | 功能 | -| TP-DB-018 | 详情按钮：点击打开运单详情弹窗，展示完整上报信息 | P1 | 📋 | 功能 | -| TP-DB-019 | 导出按钮：验证导出Excel文件内容与列表筛选结果一致 | P2 | 📋 | 功能 | -| TP-DB-020 | 导出数据量较大时（>1000条）验证导出性能和无数据丢失 | P3 | 🏢 | 性能 | +### TP-A-006: 看板导出功能 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][项目画像] +- 描述: 验证看板支持将当前筛选结果导出为 Excel 文件，大数据量导出正常。 +- 关键验证点: 导出文件包含全部列表字段；导出数据与当前筛选条件一致；大数据量（≥2000条）导出不超时、不OOM；导出的 Excel 文件可正常打开和解析。 + +### TP-A-007: 看板重置查询条件 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证点击"重置"按钮后，所有查询条件恢复默认值，列表刷新为初始全部数据。 +- 关键验证点: 模糊搜索输入框清空；下拉筛选恢复"全部"；列表数据恢复为默认全部运单；重置后分页回到第1页。 + +### TP-A-008: 看板列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证看板列表展示的14个字段完整且顺序与需求一致：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、申诉状态、异常项、货物名称、合同金额、最新核验时间、操作。 +- 关键验证点: 每个字段均有数据且格式正确；异常项为空时合理展示（如"-"或留空）；合同金额保留2位小数；最新核验时间为合理时间格式。 + +### TP-A-009: 看板状态标签颜色映射 +- 优先级: P2 +- 类型: UI测试 +- 覆盖维度: 数据校验 +- 来源: [漏测清单] +- 描述: 验证上报阶段不同状态对应的标签颜色是否正确（蓝色=上传中、绿色=已上传/通过、红色=上传失败/审核不通过、橙色=异常）。 +- 关键验证点: 每一种状态颜色独立验证；蓝色/绿色/红色/橙色与实际需求一致；申诉状态标签（未申诉灰色/审核通过绿色/审核不通过红色）颜色区分清晰。 + +### TP-A-010: 看板操作按钮 — 申诉/进度/详情 入口 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证看板操作列中"申诉""进度""详情"按钮根据运单当前状态正确显示/隐藏，点击后正确跳转。 +- 关键验证点: 仅异常运单显示"申诉"按钮；所有运单显示"详情"按钮；"进度"按钮展示上报阶段进度；点击后路由跳转正确，携带正确的运单ID参数。 + +### TP-A-011: 看板详情弹窗 — 分组字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证看板点击"详情"后弹窗内容完整，按子对象分组展示，各分组字段不缺失。 +- 关键验证点: 建单信息分组13字段完整；托运人信息7字段完整；收货方信息5字段完整；司机信息13字段完整；车辆信息19字段完整；货物信息支持多条展示；可选字段为空时展示合理。 + +### TP-A-012: 看板空数据状态 +- 优先级: P3 +- 类型: UI测试 +- 覆盖维度: 边界条件 +- 来源: [漏测清单] +- 描述: 验证看板在无运单数据时的空状态展示（如新部署环境或筛选无结果）。 +- 关键验证点: 空状态有友好的占位提示图文；筛选无结果时明确提示"未找到匹配数据"；空状态不出现控制台报错或页面崩溃。 + +### TP-A-013: 看板分页和默认排序 +- 优先级: P3 +- 类型: UI测试 +- 覆盖维度: 边界条件 +- 来源: [漏测清单] +- 描述: 验证看板列表分页功能正常（翻页、每页条数切换），默认按最新核验时间倒序排列。 +- 关键验证点: 翻页后数据不重复不遗漏；切换每页条数后分页重新计算；数据更新后排序即时反映；总条数与数据库一致。 + +### TP-A-014: 看板角色权限控制 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 权限控制 +- 来源: [项目画像] +- 描述: 验证不同角色（运营/财务/客服/车队长/司机）对看板的访问权限和数据可见范围。 +- 关键验证点: 运营人员可见全部运单；财务人员可见打款相关字段；客服人员仅可见其负责范围的运单；车队长和司机不可见平台端看板；越权访问被正确拦截。 --- -## 2. 第一次上报（装货完成） +## 模块B: 第一次上报-装货完成 (22个测试点) -### 2.1 自动触发 +### TP-B-001: 装货完成后自动触发第一次上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证运单装货完成后，系统自动触发第一次上报，上报数据包含全部必选子对象（运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息）。 +- 关键验证点: 装货完成事件触发上报；上报请求包含全部7个子对象；各子对象必选字段完整；上报接口收到正确的JSON结构；上报成功后状态变为"已上传"（绿色标签）。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-FR-001 | 运单装货完成后系统自动触发第一次上报 | P0 | 📋 | 功能 | -| TP-FR-002 | 上报数据完整性：建单信息（13字段）+ 托运人信息（7字段）+ 收货方信息（5字段）+ 司机信息（13字段）+ 车辆信息（19字段）+ 货物信息（可多条）+ 保险信息（可选） | P0 | 📋 | 功能 | -| TP-FR-003 | 必选字段缺失时上报失败，系统返回明确错误提示 | P1 | 📋 | 异常 | -| TP-FR-004 | 可选字段（委托合同编号、运输里程、框架合同编号、挂车牌照号等）为空时上报正常 | P1 | 📋 | 功能 | -| TP-FR-005 | 货物信息多条记录上报验证（≥2条货物） | P2 | 📋 | 边界 | -| TP-FR-006 | 保险信息为空（可选子对象）时上报正常 | P2 | 📋 | 功能 | -| TP-FR-007 | 保险信息填写完整时上报成功 | P2 | 📋 | 功能 | +### TP-B-002: 仅安徽税源地运单触发上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][项目画像] +- 描述: 验证货源税源地为非安徽的运单（如云南=28）装货完成后不会触发第一次上报。 +- 关键验证点: 税源地为云南(28)的运单不触发上报；税源地为其他省份的运单不触发上报；不触发时无错误日志或告警；仅税源地为安徽(34)的运单触发上报。 -### 2.2 核验通过后自动更新 +### TP-B-003: 第一次上报数据字段格式校验 — 建单信息 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证第一次上报的建单信息(waybillInfo)13个字段的格式、类型、长度符合接口规范，可选字段（委托合同编号、运输里程）为空时正常上报。 +- 关键验证点: 必选字段缺失时上报拒绝并明确提示；统一社会信用代码格式校验（18位）；业务类型代码/运输组货方式代码为有效枚举值；运输里程为合理数值范围；经纬度为合法浮点数范围；时间字段使用 yyyyMMddHHmmss（14位）格式，如 documentCreateTime、orderReceivingTime、departureTime。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-FR-008 | 核验通过后系统自动调用"修改第一次上报部分字段"接口 | P0 | 📋 | 功能 | -| TP-FR-009 | 验证更新字段范围限定为装货后可变字段（实际里程等） | P1 | 📋 | 功能 | -| TP-FR-010 | 更新操作失败时的异常处理与重试机制 | P1 | ⚠️风险矩阵 | 异常 | -| TP-FR-011 | 核验未通过时不触发自动更新 | P1 | 📋 | 功能 | +### TP-B-004: 省份代码动态获取 — 安徽=34 非云南=28 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 数据校验 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-04：验证司机信息中的省份代码(provinceCode)根据上报目标省份动态读取配置，安徽省使用代码"34"而非项目默认值云南省代码"28"。 +- 关键验证点: 安徽运八上报的省份代码为"34"；不同省份配置隔离，云南=28、安徽=34 各自独立；修改省份配置后无需重启服务即可生效；数据库/Redis中无硬编码省份代码；装货地行政区划代码前2位=34（安徽省代码）。 -### 2.3 重试机制 +### TP-B-005: 后端校验 — 第一次上报是第二/三次上报的前置条件 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-01：验证第一次上报失败后，后端接口层面拒绝第二次和第三次上报请求，返回明确错误码"前置上报未完成"。前端+后端双重拦截。 +- 关键验证点: 第一次上报失败时调用第二次上报接口返回错误；错误码明确标识"前置上报未完成"；后端通过查询运单上报状态表做校验，非前端布尔值；第一次上报重试3次全失败后第二次上报仍被拒绝；第三次上报同理，第二次上报失败时被拒绝。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-FR-012 | 上报失败后自动重试，最多3次 | P1 | 📋 | 功能 | -| TP-FR-013 | 第1次重试成功后不再继续重试 | P1 | 📋 | 功能 | -| TP-FR-014 | 第2次重试成功后不再继续重试 | P2 | 📋 | 功能 | -| TP-FR-015 | 3次重试全部失败后通过站内信通知运营人员 | P1 | 📋 | 功能 | -| TP-FR-016 | 重试间隔时间验证（避免瞬时高频重试） | P2 | ⚠️风险矩阵 | 性能 | -| TP-FR-017 | 重试期间手动触发上报的幂等性（不产生重复上报） | P1 | 💡易漏场景 | 功能 | +### TP-B-006: 第一次上报成功后自动调用"修改字段"接口 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证监管平台核验通过后，系统自动调用"修改第一次上报部分字段"接口，更新装货后可能变化的字段（如实际里程）。 +- 关键验证点: 核验通过后自动触发修改接口；修改的字段为装货后变化字段（实际里程等）；修改成功后状态仍为"已上传"；修改接口调用记录出现在上报日志中；若修改失败有重试机制和告警。 -### 2.4 状态流转 +### TP-B-007: 第一次上报自动重试 — 最多3次 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [需求] +- 描述: 验证第一次上报失败后系统自动重试，最多3次，重试间隔递增。 +- 关键验证点: 第1次失败后自动触发第2次重试；重试间隔合理递增（如5s/15s/30s）；第3次仍失败后标记为"上传失败"（红色标签）并停止重试；每次重试均记录到上报日志；重试次数不超过3次。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-FR-018 | 状态流转：上传中 → 已上传（核验通过） | P1 | 📋 | 功能 | -| TP-FR-019 | 状态流转：上传中 → 上传失败（超时，可手动上传） | P1 | 📋 | 功能 | -| TP-FR-020 | 状态流转：上传中 → 异常（数据校验不通过） | P1 | 📋 | 功能 | -| TP-FR-021 | 标签颜色：蓝色(上传中)/绿色(已上传)/红色(上传失败)/橙色(异常) | P2 | 📋 | 功能 | -| TP-FR-022 | 上传失败状态下"手动上传"按钮可见且可操作 | P1 | 📋 | 功能 | -| TP-FR-023 | 异常状态下"详情"按钮可查看异常原因 | P1 | 📋 | 功能 | -| TP-FR-024 | 第一次上报失败导致后续第二次、第三次上报无法触发 | P0 | 📋⚠️ | 功能 | +### TP-B-008: 第一次上报全部重试失败后通知运营人员 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证第一次上报3次自动重试全部失败后，系统通过站内信或其他方式通知运营人员。 +- 关键验证点: 3次重试失败后立即触发通知；通知内容包含运单号、失败原因、失败时间；站内信有明确的"上报失败"标记；运营人员可在通知中直接跳转到对应运单详情页。 -### 2.5 详情弹窗 +### TP-B-009: 第一次上报手工上传 — 上传失败后手动触发 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证运单上报状态为"上传失败"（红色标签）时，运营人员可点击"手动上传"按钮重新发起上报。 +- 关键验证点: 仅"上传失败"状态显示"手动上传"按钮；点击后发起新的上报请求；手动上传成功后状态变为"已上传"（绿色）；手动上传同样记录到上报日志。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-FR-025 | 详情弹窗按子对象分组展示（建单/托运人/收货方/司机/车辆/货物/保险/异常） | P1 | 📋 | 功能 | -| TP-FR-026 | 详情弹窗各字段值与上报数据一致 | P1 | 📋 | 功能 | -| TP-FR-027 | 详情弹窗关闭后正确返回列表页 | P2 | 📋 | 功能 | -| TP-FR-028 | 异常信息区在无异常时不展示或显示"无异常" | P2 | 📋 | 功能 | +### TP-B-010: 第一次上报状态标签颜色校验 +- 优先级: P2 +- 类型: UI测试 +- 覆盖维度: 数据校验 +- 来源: [漏测清单] +- 描述: 验证四种上报状态对应的标签颜色：上传中=蓝色、已上传=绿色、上传失败=红色、异常=橙色。 +- 关键验证点: 每种状态颜色独立验证，不与需求描述偏离；上传中状态显示蓝色标签和加载动画；状态切换时标签颜色即时更新；颜色在亮色/暗色主题下均可辨识。 + +### TP-B-011: 第一次上报详情弹窗 — 建单信息字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验收详情弹窗中"建单信息"分组的13个字段全部展示，数据取值来源正确。 +- 关键验证点: 上游企业委托运输单号、本运单单号、托运人建单时间、网络货运经营者名称、统一社会信用代码、道路运输经营许可证编号、业务类型代码、运输组货方式代码、司机接单时间、司机起运时间、承运合同编号（必选）共11字段有值；委托合同编号和运输里程为可选字段，为空时合理展示。 + +### TP-B-012: 第一次上报详情弹窗 — 托运人/收货方/司机/车辆/货物/保险子对象字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证详情弹窗中各子对象字段完整且按分组展示：托运人信息7字段、收货方信息5字段、司机信息13字段、车辆信息19字段、货物信息4字段（可多条）、保险信息2字段（可选）。 +- 关键验证点: 托运人统一社会信用代码格式正确；收货方身份证号脱敏展示（如适用）；司机从业资格证有效期起止日期格式正确；车辆VIN码(17位)正确显示；货物支持多条记录展开；保险单号为可选字段，无保险时合理展示。 + +### TP-B-013: 第一次上报详情弹窗 — 异常信息展示 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证详情弹窗中"异常信息"分组包含核验状态、异常原因、异常时间、处理状态4个字段。 +- 关键验证点: 核验通过时异常原因为空；核验异常时异常原因描述清晰可理解；异常时间为实际核验时间；处理状态与申诉模块数据联动。 + +### TP-B-014: 第一次上报幂等性 — 防止重复上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-02：验证同一运单同一上报阶段在短时间内不能重复上报。自动重试期间手动触发上传时，系统检测到上报进行中并拒绝重复提交。 +- 关键验证点: 自动重试进行中点击"手动上传"返回"上报处理中"提示并拒绝；同一运单同一阶段1分钟内只能有1条成功上报记录；使用分布式锁或幂等键控制并发；快速连续点击"手动上传"按钮仅发起1次请求（前端防抖）；后端数据库层面唯一约束防重。 + +### TP-B-015: 第一次上报接口超时处理 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [漏测清单][风险矩阵] +- 描述: 验证第一次上报接口调用超时后的处理逻辑（超时归类为上报失败，触发重试）。 +- 关键验证点: 监管平台接口超时(>30s)后转为"上传失败"状态；超时状态下触发自动重试；超时不导致数据不一致或重复写入；超时时有 Loading 状态提示；前端页面超时后有友好提示。 + +### TP-B-016: 第一次上报弱网环境处理 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [漏测清单] +- 描述: 验证在弱网环境（高延迟、高丢包率）下，第一次上报的重试机制正常工作。 +- 关键验证点: 弱网下请求发送成功但响应延迟时不会立即判定失败；超时阈值合理（建议30s）；弱网恢复后重试成功则状态正常流转；断网时上报请求发送失败的提示友好。 + +### TP-B-017: 第一次上报并发触发 — 多运单同时装货完成 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 +- 来源: [项目画像][最佳实践] +- 描述: 验证多个运单同时装货完成时，第一次上报并发处理，各运单上报互不干扰。 +- 关键验证点: 10个运单同时装货完成，各自独立触发上报；并发上报不产生数据库死锁；各运单上报记录正确隔离；并发上报后上报日志完整记录每个运单的请求。 + +### TP-B-018: 第一次上报可选字段空值处理 +- 优先级: P3 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [漏测清单] +- 描述: 验证各子对象中的可选字段（委托合同编号、运输里程、挂车牌照号、行驶证档案编号、道路运输证有效期起/至、保险单号、保险公司名称）为空时，上报接口正常处理。 +- 关键验证点: 可选字段为空时上报不报错；JSON 中可选字段不传或传 null 均可正常处理；详情弹窗中可选字段为空时显示"-"或"N/A"等占位符，不显示"null"或"undefined"。 + +### TP-B-019: 第一次上报货物信息多条记录 +- 优先级: P3 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [需求][漏测清单] +- 描述: 验证当运单包含多种货物时，货物信息(goodsInfos)数组支持多条记录上报，每条包含货物名称、货物类型代码、货物量、计量单位。 +- 关键验证点: 支持1条货物记录；支持多条（如5条）货物记录；每条货物信息独立完整；详情弹窗支持展开/折叠多条货物记录；货物类型代码与数据字典一致。 + +### TP-B-020: 第一次上报列表字段完整性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证第一次上报列表展示的字段完整且与需求一致，包括货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、业务类型、货物名称、装货地址、卸货地址、运输里程、合同编号、上报状态、操作共14个字段。 +- 关键验证点: 列表表头与需求一致性；14个字段均正确展示且顺序符合设计；业务类型与数据字典一致；装货地址和卸货地址完整展示；运输里程带单位（km）；上报状态标签颜色映射正确（上传中=蓝色/已上传=绿色/上传失败=红色/异常=橙色）。 + +### TP-B-021: 委托合同（框架）上传 — 第一次上报前置条件 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 状态流转 +- 来源: [技术方案] +- 描述: 验证在进行运单的第一次上报前，需要先通过 POST /api/dataUpload/mandateContractFrame 接口将委托合同（框架）上传至服务平台；未上传委托合同时第一次上报应被拒绝。 +- 关键验证点: 未上传委托合同时触发第一次上报被拒绝，返回明确错误提示；委托合同（框架）上传成功后第一次上报可正常进行；委托合同字段（contract_number合同编号、expire_time有效期截止日yyyy-MM-dd）必填校验；uploadFileInfo字段可选，可在修改委托合同时补充。 + +### TP-B-022: 委托合同与委托合同（框架）二选一上报 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [技术方案] +- 描述: 验证委托合同（框架）和委托合同二选一进行上报：单个货主企业使用 unified_social_credit_identifier 字段；多家货主企业使用 enterpriseList 数组关联。若两者都传值，默认取单托运企业(unified_social_credit_identifier)。 +- 关键验证点: 仅传 unified_social_credit_identifier（单企业）时正常上报；仅传 enterpriseList（多企业列表）时正常上报，列表中每项含 unified_social_credit_identifier 和 owner_enterprise_name；两者都传时默认取单企业；两者都不传时接口返回错误。 --- -## 3. 第二次上报（打款完成） +## 模块C: 第二次上报-打款完成 (51个测试点) -### 3.1 自动触发与数据完整性 +### TP-C-001: 打款完成后自动触发第二次上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证运单运费支付（财务打款）完成后，系统自动触发第二次上报，上报数据包含资金流水信息和车辆轨迹信息。 +- 关键验证点: 财务打款完成回调触发上报；上报请求包含运单信息+资金流水+车辆轨迹；上报成功后状态更新；第二次上报仅对已完成第一次上报的运单触发。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-SR-001 | 运费支付完成后系统自动触发第二次上报 | P0 | 📋 | 功能 | -| TP-SR-002 | 上报数据完整性：运单/托运方/收货方信息 + 资金流水 + 车辆轨迹 + 异常信息 | P0 | 📋 | 功能 | -| TP-SR-003 | 资金流水信息字段完整性：支付金额/方式/时间/付款方/收款方/收款人/收款账号/账号类型/流水号/支付状态 | P1 | 📋⚠️ | 功能 | -| TP-SR-004 | 车辆轨迹点位数量边界：最少2个点、最多2000个点 | P1 | 📋 | 边界 | -| TP-SR-005 | 车辆轨迹点位数量=1时上报失败 | P2 | 📋 | 边界 | -| TP-SR-006 | 车辆轨迹点位数量=2000时上报成功 | P2 | 📋 | 边界 | -| TP-SR-007 | 车辆轨迹点位数量>2000时取前2000个或报错 | P2 | 📋 | 边界 | +### TP-C-002: 第二次上报资金流水数据来源于支付流水表 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 数据校验 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-03：验证第二次上报的资金流水数据（支付金额、支付方式、支付时间、流水号等）从支付流水表实时读取，而非使用运单缓存中的合同金额。 +- 关键验证点: 上报数据中的金额与支付流水表实际打款金额完全一致；非从运单表或Redis缓存读取金额；数据库查询SQL日志可确认数据来源为支付流水表；金额字段精确到分（2位小数），无精度丢失。 -### 3.2 核验内容（7大类） +### TP-C-003: 财务修改打款金额后第二次上报使用最新金额 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 数据校验 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-03：验证财务在账户管理模块修改打款金额后，第二次上报感知数据变更并使用修改后的最新金额。 +- 关键验证点: 合同金额10000元 → 财务调账修改为9500元 → 第二次上报金额为9500元；财务修改与上报触发有时间差时仍使用最新值；上报日志中可溯源金额来源；反例：不使用装货完成时缓存的合同金额。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-SR-008 | 运单重复核验：同一运单第二次上报时正确识别为重复 | P0 | 📋 | 功能 | -| TP-SR-009 | 车辆资质核验：道路运输证在有效期内 → 通过 | P1 | 📋 | 功能 | -| TP-SR-010 | 车辆资质核验：道路运输证已过期 → 异常 | P1 | 📋 | 异常 | -| TP-SR-011 | 司机资质核验：从业资格证在有效期内 → 通过 | P1 | 📋 | 功能 | -| TP-SR-012 | 司机资质核验：从业资格证已过期 → 异常 | P1 | 📋 | 异常 | -| TP-SR-013 | 集中支付核验：资金流水通过网货平台集中支付 → 通过 | P1 | 📋 | 功能 | -| TP-SR-014 | 集中支付核验：资金流水未通过平台集中支付 → 异常 | P1 | 📋⚠️ | 异常 | -| TP-SR-015 | 资金流水核验：流水单号不重复 + 金额匹配 → 通过 | P1 | 📋⚠️ | 功能 | -| TP-SR-016 | 资金流水核验：流水单号重复 → 异常，系统自动检查提示 | P0 | 📋⚠️ | 异常 | -| TP-SR-017 | 资金流水核验：金额不匹配 → 异常 | P1 | 📋⚠️ | 异常 | -| TP-SR-018 | 合同核验：运输合同和委托合同均有效 → 通过 | P1 | 📋 | 功能 | -| TP-SR-019 | 合同核验：运输合同无效/过期 → 异常 | P1 | 📋 | 异常 | -| TP-SR-020 | 车辆轨迹合规核验：轨迹真实且与运单路线匹配 → 通过 | P1 | 📋 | 功能 | -| TP-SR-021 | 车辆轨迹合规核验：点位不足或偏差过大 → 异常 | P1 | 📋 | 异常 | +### TP-C-004: 第二次上报列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证第二次上报列表展示的14个字段完整：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、承运运费、总金额、付款方式、付款时间、收款人、收款账号、收款账号类型、核验状态、异常项、上报状态、操作。 +- 关键验证点: 承运运费和总金额保留2位小数；付款时间为实际财务打款时间；操作列根据上报状态显示"上报"或"详情"按钮。 -### 3.3 补传轨迹 +### TP-C-005: 收款账号类型标签颜色 — 个人账户(蓝色)/对公账户(绿色) +- 优先级: P2 +- 类型: UI测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证列表中收款账号类型标签颜色：个人账户显示蓝色标签，对公账户显示绿色标签。 +- 关键验证点: 司机个人银行卡(个人账户)=蓝色；企业银行账号(对公账户)=绿色；颜色与需求定义严格一致；列表中每条记录标签颜色根据实际账号类型渲染，不混淆。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-SR-022 | 车辆轨迹合规异常时，"补传轨迹"功能可见可用 | P1 | 📋 | 功能 | -| TP-SR-023 | 补传轨迹后重新核验通过 | P1 | 📋 | 功能 | -| TP-SR-024 | 补传轨迹数据格式与原轨迹数据格式一致 | P2 | 📋 | 功能 | -| TP-SR-025 | 补传轨迹后再次异常仍可继续补传 | P2 | 📋 | 功能 | +### TP-C-006: 运单重复核验 — 通过场景 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证同一运单未重复上报时，监管平台"运单重复核验"返回通过。 +- 关键验证点: 首次上报的运单核验通过；不同运单号各自独立上报通过；核验状态标记为"通过"；无"运单重复"异常项出现。 -### 3.4 收款账号类型 +### TP-C-007: 运单重复核验 — 异常场景（重复上报） +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证同一运单第二次上报时，监管平台"运单重复核验"检测到重复并返回异常。 +- 关键验证点: 重复上报后核验状态变为"异常"；异常项明确标注"运单重复核验"；异常原因清晰可读；异常运单可触发申诉流程。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-SR-026 | 个人账户：标签蓝色，显示司机个人银行卡账号 | P2 | 📋 | 功能 | -| TP-SR-027 | 对公账户：标签绿色，显示企业银行账号 | P2 | 📋 | 功能 | -| TP-SR-028 | 收款账号类型字段在列表和详情中展示一致 | P2 | 📋 | 功能 | +### TP-C-008: 车辆资质核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证车辆道路运输证在有效期内时，监管平台"车辆资质核验"返回通过。 +- 关键验证点: 道路运输证有效期起止日期在有效期内；道路运输证号格式有效；车辆审核状态为"通过"的运单核验通过。 -### 3.5 重试与告警 +### TP-C-009: 车辆资质核验 — 异常场景（证件过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证车辆道路运输证已过期或缺失时，监管平台"车辆资质核验"返回异常。 +- 关键验证点: 道路运输证有效期的截止日期 < 当前日期时核验异常；无道路运输证号的车辆核验异常；异常项明确标注"车辆资质核验"；异常后可申诉。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-SR-029 | 上报失败后自动重试最多3次 | P1 | 📋 | 功能 | -| TP-SR-030 | 3次重试全部失败后告警通知运营人员 | P1 | 📋⚠️ | 功能 | -| TP-SR-031 | 告警通知渠道验证（站内信/其他方式） | P2 | 📋 | 功能 | -| TP-SR-032 | 重试期间资金流水单号重复的幂等处理 | P1 | ⚠️风险矩阵 | 功能 | +### TP-C-010: 司机资质核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证司机从业资格证在有效期内时，监管平台"司机资质核验"返回通过。 +- 关键验证点: 从业资格证有效期起止日期在有效期内；从业资格证号格式有效；司机审核状态为"通过"的运单核验通过。 + +### TP-C-011: 司机资质核验 — 异常场景（证件过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证司机从业资格证已过期或缺失时，监管平台"司机资质核验"返回异常。 +- 关键验证点: 从业资格证有效期至 < 当前日期时核验异常；无从业资格证号时核验异常；异常项明确标注"司机资质核验"；异常后可申诉。 + +### TP-C-012: 集中支付核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证资金流水通过网货平台集中支付时，监管平台"集中支付核验"返回通过。 +- 关键验证点: 付款方为网货平台统一账户，核验通过；支付流水记录与集中支付模式匹配；核验状态为"通过"。 + +### TP-C-013: 集中支付核验 — 异常场景（非集中支付/支付信息异常） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证资金流水未通过网货平台集中支付或支付信息异常时，监管平台"集中支付核验"返回异常。 +- 关键验证点: 付款方非平台统一账户时核验异常；集中支付流水数据不完整时核验异常；异常项明确标注"集中支付核验"；异常后可申诉。 + +### TP-C-014: 资金流水核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证资金流水单号不重复且金额匹配时，监管平台"资金流水核验"返回通过。 +- 关键验证点: 流水号唯一不重复；上报金额与支付流水表实际金额一致；核验状态为"通过"。 + +### TP-C-015: 资金流水核验 — 异常场景（流水号重复/金额不匹配） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证资金流水单号重复或上报金额与支付流水不一致时，监管平台"资金流水核验"返回异常。 +- 关键验证点: 重复流水单号核验异常并提示；上报金额与支付流水金额偏差>0.01元时核验异常；异常项明确标注"资金流水核验"；异常后可申诉。 + +### TP-C-016: 合同核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证运输合同和委托合同均有效时，监管平台"合同核验"返回通过。 +- 关键验证点: 承运合同编号有效且存在于合同管理系统；委托合同编号（如有）有效；合同有效期覆盖运单执行日期；核验状态为"通过"。 + +### TP-C-017: 合同核验 — 异常场景（合同无效/过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证运输合同或委托合同无效/过期/缺失时，监管平台"合同核验"返回异常。 +- 关键验证点: 承运合同编号不存在时核验异常；合同有效期不包含运单执行日期时核验异常；异常项明确标注"合同核验"；异常后可申诉。 + +### TP-C-018: 车辆轨迹合规核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证车辆GPS轨迹真实、与运单路线匹配、轨迹点数量在2~2000范围内时，监管平台"车辆轨迹合规核验"返回通过。 +- 关键验证点: 轨迹点数量≥2且≤2000；轨迹路线与装货地→卸货地路线基本一致；轨迹时间与运单执行时间匹配；核验状态为"通过"。 + +### TP-C-019: 车辆轨迹合规核验 — 异常场景（点位不足/偏差过大/轨迹缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证车辆轨迹点数量不足(<2)、偏差过大、或轨迹数据缺失时，监管平台"车辆轨迹合规核验"返回异常。 +- 关键验证点: 轨迹点数量=1或0时核验异常；轨迹路线偏离装货-卸货路线超过合理范围时核验异常；异常项明确标注"车辆轨迹合规核验"；异常后可进入"补传轨迹"流程。 + +> **⚠️ API文档扩展说明 (来自原型&接口交叉分析)**: +> 根据网货企业端接口文档 V1.0.2 §4.1 异常项ID对照表，第二次上报核验项从需求的7类扩展为API定义的17项独立核验项。以下TP-C-006~TP-C-019覆盖了需求的7类核验（运单重复/车辆资质/司机资质/集中支付/资金流水/合同/轨迹合规），但API将其中部分类别拆分为更细粒度的独立核验项。 +> +> API文档完整17项: 100=委托合同, 120=承运合同, 130=实时定位, 140=运单时间逻辑, 150=车辆资质, 160=道路运输证, 170=驾驶证, 180=从业资格证, 190=车辆重复, 200=司机重复, 210=车辆轨迹, 220=运费收款, 230=公司统一收款, 240=集中支付, 250=资金流水, 260=发票信息, 270=非通行车辆可开票 +> +> 以下 TP-C-026~TP-C-049 为补充的12项独立核验项（每项 PASS + EXCEPTION），来源标注 [技术方案]。 + +### TP-C-025: 里程申诉功能 — 提交里程申诉 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证运单里程数据异常时，可通过 POST /mileageAppeal/insert 接口提交里程申诉，携带运单号(freightSheetNumber)、申诉内容(content)、投诉编号(complaintNumber)、申诉里程(mileage)参数。 +- 关键验证点: 里程申诉接口正常调用成功返回；必选参数齐全（运单号/申诉内容/投诉编号/申诉里程）；申诉提交后可在申诉记录中查看；里程申诉与异常申诉独立管理；缺少必选参数时接口返回明确错误提示。 + +### TP-C-026: 委托合同核验(100) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证委托合同编号有效且存在于合同管理系统、有效期覆盖运单执行日期时，监管平台"委托合同核验"返回通过。 +- 关键验证点: 委托合同编号有效且存在于系统；委托合同有效期覆盖运单执行日期；核验状态为"通过"；无"委托合同核验"异常项出现。 + +### TP-C-027: 委托合同核验(100) — 异常场景（合同无效/过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证委托合同编号不存在、无效或有效期不覆盖运单执行日期时，监管平台"委托合同核验"返回异常。 +- 关键验证点: 委托合同编号不存在时核验异常；合同有效期不覆盖运单执行日期时核验异常；委托合同为空时核验异常；异常项明确标注"委托合同核验"（代码100）；异常后可申诉。 + +### TP-C-028: 承运合同核验(120) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证承运合同编号有效且存在于合同管理系统、有效期覆盖运单执行日期时，监管平台"承运合同核验"返回通过。 +- 关键验证点: 承运合同编号有效且存在于系统；承运合同有效期覆盖运单执行日期；核验状态为"通过"；无"承运合同核验"异常项出现。 + +### TP-C-029: 承运合同核验(120) — 异常场景（合同无效/过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证承运合同编号不存在、无效或有效期不覆盖运单执行日期时，监管平台"承运合同核验"返回异常。 +- 关键验证点: 承运合同编号不存在时核验异常；合同有效期不覆盖运单执行日期时核验异常；承运合同为空时核验异常；异常项明确标注"承运合同核验"（代码120）；异常后可申诉。 + +### TP-C-030: 实时定位核验(130) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证车辆在运单执行期间有完整的实时定位数据（GPS轨迹覆盖整个运输过程）时，监管平台"实时定位核验"返回通过。 +- 关键验证点: 运单执行期间车辆实时定位数据完整；定位时间覆盖运单起运至送达时间范围；核验状态为"通过"；无"实时定位核验"异常项出现。 + +### TP-C-031: 实时定位核验(130) — 异常场景（定位数据缺失/不完整） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证车辆在运单执行期间缺少实时定位数据或定位数据不完整时，监管平台"实时定位核验"返回异常。 +- 关键验证点: 运输过程中定位数据长时间中断时核验异常；无任何实时定位数据时核验异常；定位数据时间范围未覆盖运单执行时间时核验异常；异常项明确标注"实时定位核验"（代码130）；异常后可申诉或补传定位数据。 + +### TP-C-032: 运单时间逻辑核验(140) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证运单各时间节点逻辑合理（建单时间 < 接单时间 < 起运时间 < 送达时间）时，监管平台"运单时间逻辑核验"返回通过。 +- 关键验证点: 建单时间早于接单时间；接单时间早于起运时间；起运时间早于送达时间；各时间节点无倒置或矛盾；核验状态为"通过"。 + +### TP-C-033: 运单时间逻辑核验(140) — 异常场景（时间倒置/不合理） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证运单各时间节点存在逻辑矛盾（如送达时间早于起运时间、接单时间早于建单时间等）时，监管平台"运单时间逻辑核验"返回异常。 +- 关键验证点: 起运时间晚于送达时间时核验异常；接单时间早于建单时间时核验异常；时间字段为空时核验异常；异常项明确标注"运单时间逻辑核验"（代码140）；异常后可申诉。 + +### TP-C-034: 道路运输证核验(160) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证车辆道路运输证在有效期内且证号格式有效时，监管平台"道路运输证核验"返回通过。 +- 关键验证点: 道路运输证有效期起止日期在当前日期范围内；道路运输证号格式有效且可查询；道路运输证发证机关信息完整；核验状态为"通过"；无"道路运输证核验"异常项出现。 + +### TP-C-035: 道路运输证核验(160) — 异常场景（过期/缺失/无效） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证车辆道路运输证过期、缺失或证号格式无效时，监管平台"道路运输证核验"返回异常。 +- 关键验证点: 道路运输证有效期截止日期 < 当前日期时核验异常；道路运输证号为空或格式无效时核验异常；证号在运政系统中查询不存在时核验异常；异常项明确标注"道路运输证核验"（代码160）；异常后可申诉。 + +### TP-C-036: 驾驶证核验(170) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证司机驾驶证在有效期内且证号与交管系统一致时，监管平台"驾驶证核验"返回通过。 +- 关键验证点: 驾驶证有效期覆盖运单执行日期；驾驶证号格式正确（18位）；驾驶证准驾车型与车辆类型匹配；核验状态为"通过"；无"驾驶证核验"异常项出现。 + +### TP-C-037: 驾驶证核验(170) — 异常场景（过期/缺失/准驾不符） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证司机驾驶证过期、缺失或准驾车型不匹配时，监管平台"驾驶证核验"返回异常。 +- 关键验证点: 驾驶证有效期截止日期 < 当前日期时核验异常；驾驶证号为空或格式无效时核验异常；准驾车型与实际驾驶车辆类型不匹配时核验异常；异常项明确标注"驾驶证核验"（代码170）；异常后可申诉。 + +### TP-C-038: 车辆重复核验(190) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证同一车辆未在同一时间段内被重复用于多个运单时，监管平台"车辆重复核验"返回通过。 +- 关键验证点: 车辆在运单执行时段内无其他重叠运单；车辆未同时出现在多个进行中的运单中；核验状态为"通过"；无"车辆重复核验"异常项出现。 + +### TP-C-039: 车辆重复核验(190) — 异常场景（车辆同时用于多个运单） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证同一车辆在同一时间段内被用于多个运单（时间重叠）时，监管平台"车辆重复核验"返回异常。 +- 关键验证点: 车辆在运单A执行期间同时出现在运单B中时核验异常；时间重叠超过合理阈值时核验异常；异常项明确标注"车辆重复核验"（代码190）；异常后可申诉。 + +### TP-C-040: 司机重复核验(200) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证同一司机未在同一时间段内被重复分配给多个运单时，监管平台"司机重复核验"返回通过。 +- 关键验证点: 司机在运单执行时段内无其他重叠运单；司机未同时驾驶多辆车辆执行不同运单；核验状态为"通过"；无"司机重复核验"异常项出现。 + +### TP-C-041: 司机重复核验(200) — 异常场景（司机同时执行多个运单） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证同一司机在同一时间段内被分配给多个运单（时间重叠）时，监管平台"司机重复核验"返回异常。 +- 关键验证点: 司机在运单A执行期间同时出现在运单B中时核验异常；时间重叠超过合理阈值时核验异常；异常项明确标注"司机重复核验"（代码200）；异常后可申诉。 + +### TP-C-042: 运费收款核验(220) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证运费收款方信息与实际司机/承运人一致、收款金额与运单运费匹配时，监管平台"运费收款核验"返回通过。 +- 关键验证点: 收款方身份与运单司机一致；收款金额与运单运费一致；收款账户信息有效；核验状态为"通过"；无"运费收款核验"异常项出现。 + +### TP-C-043: 运费收款核验(220) — 异常场景（收款人不一致/金额不匹配） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证运费收款人与运单司机不一致、收款金额与运费不匹配时，监管平台"运费收款核验"返回异常。 +- 关键验证点: 收款人姓名/身份证号与司机信息不一致时核验异常；收款金额与运单运费偏差超过阈值时核验异常；异常项明确标注"运费收款核验"（代码220）；异常后可申诉。 + +### TP-C-044: 公司统一收款核验(230) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证当收款方为公司统一收款账户时，公司信息与运单托运方信息一致，监管平台"公司统一收款核验"返回通过。 +- 关键验证点: 收款公司名称/统一社会信用代码与托运方一致；公司统一收款账户在系统中备案；核验状态为"通过"；无"公司统一收款核验"异常项出现。 + +### TP-C-045: 公司统一收款核验(230) — 异常场景（公司信息不一致/未备案） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证公司统一收款账户信息与托运方不一致或收款账户未备案时，监管平台"公司统一收款核验"返回异常。 +- 关键验证点: 收款公司名称与托运方名称不一致时核验异常；收款公司统一社会信用代码与托运方不一致时核验异常；收款账户未在系统中备案时核验异常；异常项明确标注"公司统一收款核验"（代码230）；异常后可申诉。 + +### TP-C-046: 发票信息核验(260) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证第三次上报关联的发票信息完整有效（发票号码/代码/金额匹配、销售方/受票方信息完整）时，监管平台"发票信息核验"返回通过。 +- 关键验证点: 发票号码与发票代码匹配有效；发票金额（价税合计）计算正确；销售方纳税人识别号有效；受票方信息与托运方一致；核验状态为"通过"。 + +### TP-C-047: 发票信息核验(260) — 异常场景（发票无效/信息不完整） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证发票号码/代码不匹配、发票信息不完整或发票已作废时，监管平台"发票信息核验"返回异常。 +- 关键验证点: 发票号码在税务系统中查询不到时核验异常；发票已作废/红冲时核验异常；受票方名称/纳税人识别号与托运方不一致时核验异常；异常项明确标注"发票信息核验"（代码260）；异常后可申诉。 + +### TP-C-048: 非通行车辆可开票核验(270) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证运单关联的车辆属于可开票车辆（即车辆资质、运营证照齐全且在合规运营范围内）时，监管平台"非通行车辆可开票核验"返回通过。 +- 关键验证点: 车辆运营证照齐全且在有效期内；车辆未被标记为不合规或黑名单；核验状态为"通过"；无"非通行车辆可开票核验"异常项出现。 + +### TP-C-049: 非通行车辆可开票核验(270) — 异常场景（车辆不合规/证照缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证车辆运营证照不全、车辆被标记为不合规或不在可开票范围内时，监管平台"非通行车辆可开票核验"返回异常。 +- 关键验证点: 车辆无有效道路运输证时核验异常；车辆被标记为运营异常/黑名单时核验异常；车辆类型不在可开票范围内时核验异常；异常项明确标注"非通行车辆可开票核验"（代码270）；异常后可申诉。 + +### TP-C-050: 第二次上报金额精度3位小数校验 [技术方案] +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [技术方案] +- 描述: 验证第二次上报中所有金额字段保留**3位小数**（非2位），货币单位为人民币（元），如整数以.000填充。涉及字段：arrivalInfo.waybillFreightAmount（承运运费金额）、arrivalInfo.totalMonetaryAmount（委托运费金额）、carrierStatements.monetaryAmount（承运人流水金额）、ownerStatements.monetaryAmount（货主流水金额）、carrierContractInfo.contractAmount（承运合同金额）、carrierContractInfo.contractedCarryingCapacity（承运量）、ownerContractInfo.contractAmount（委托合同金额）、ownerContractInfo.contractedCarryingCapacity（委托合同承运量）。 +- 关键验证点: 整数金额如100 → 上报为100.000（3位小数）；小数金额如100.5 → 上报为100.500；小数金额如100.123 → 上报为100.123；金额字段使用DECIMAL类型而非FLOAT；数据库和UI展示均保留3位小数。 + +### TP-C-051: 承运人流水核验次日延迟 [技术方案] +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证除承运人流水核验需等待次日银行提供数据后开始核验外，其余核验项会在一至两小时内核验完成。第二次上报后承运人流水核验状态初始为"待核验"（非异常），次日银行数据到后才执行核验。 +- 关键验证点: 第二次上报后除"资金流水核验"外其他核验项1~2小时内完成；承运人流水核验在当日处于"待核验"或"核验中"状态；次日银行数据提供后承运人流水核验自动执行；若次日核验发现异常，核验状态更新为"异常"并可申诉。 + +### TP-C-020: 后端校验 — 第二次上报依赖第一次上报完成 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-01：验证后端接口层面，第一次上报未完成（失败/进行中）时拒绝第二次上报，返回明确错误码。 +- 关键验证点: 第一次上报"上传失败"状态下触发第二次上报被拒绝；第一次上报"上传中"状态下触发第二次上报被拒绝；后端通过查询运单上报状态表校验，非仅前端控制；错误码和错误消息明确。 + +### TP-C-021: 第二次上报幂等性 — 防止重复上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-02：验证第二次上报具有幂等性，重复触发不产生多条上报记录，自动重试和手动触发互斥。 +- 关键验证点: 第二次上报自动重试期间禁止手动触发；同一运单第二次上报仅产生1条有效记录；分布式锁/幂等键控制并发；数据库唯一约束防止插入重复记录。 + +### TP-C-022: 补传轨迹功能 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证车辆轨迹合规核验异常后，运营人员可通过"补传轨迹"功能补充GPS轨迹数据，重新触发核验。 +- 关键验证点: 仅轨迹核验异常的运单显示"补传轨迹"按钮；补传后重新触发轨迹核验；补传的轨迹数据覆盖原有数据；补传后核验通过则异常项消除；补传操作记录到上报日志。 + +### TP-C-023: 第二次上报失败自动重试机制 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证第二次上报失败（超时或接口返回错误）后，系统自动重试（最多3次），重试间隔递增，3次全部失败后告警通知运营人员。 +- 关键验证点: 上报失败后自动触发重试（非人工触发）；最多重试3次；重试间隔递增（如5s/15s/30s）；每次重试在上报日志中独立记录；3次全部失败后通过站内信或短信告警通知运营人员；重试期间手动上传按钮不可用或提示"上报处理中"。 + +### TP-C-024: 第二次上报详情弹窗资金流水与车辆轨迹字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证第二次上报详情弹窗中资金流水信息（10字段）和车辆轨迹信息（6字段）的分组展示完整且字段顺序正确。 +- 关键验证点: 资金流水信息完整展示（支付金额/支付方式/支付时间/付款方名称/收款方名称/收款人/收款账号/收款账号类型/流水号/支付状态）；车辆轨迹信息完整展示（定位类型/定位时间/定位地点/经度/纬度/轨迹类型）；可选字段缺失时显示"-"或"无"而不空白；弹窗分组标签正确（运单信息/托运方信息/收货方信息/资金流水信息/车辆轨迹信息/异常信息）。 --- -## 4. 第三次上报（开票完成） +## 模块D: 第三次上报-开票完成 (11个测试点) -### 4.1 触发条件与数据完整性 +### TP-D-001: 开票完成后触发第三次上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证发票开具完成后，系统触发第三次上报，上报数据包含运单信息、发票信息和油气发票信息。 +- 关键验证点: 发票开具完成后自动触发上报；上报数据包含托运单号数组、发票信息17字段；若有关联油气发票则包含油气发票信息；仅开票完成的运单触发。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-TR-001 | 第二次上报完成后，发票开具完成触发第三次上报 | P0 | 📋 | 功能 | -| TP-TR-002 | 第二次上报未完成时，第三次上报无法触发 | P1 | 📋 | 功能 | -| TP-TR-003 | 上报数据完整性：运单信息(托运单号数组) + 发票信息(17字段) + 油气发票(可选) | P1 | 📋 | 功能 | -| TP-TR-004 | 托运单号数组包含多个托运单号时上报成功 | P2 | 📋 | 边界 | -| TP-TR-005 | 油气发票信息为空（可选）时上报正常 | P2 | 📋 | 功能 | -| TP-TR-006 | 油气发票多条记录时上报正常 | P2 | 📋 | 功能 | +### TP-D-002: 第三次上报列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证第三次上报列表展示的11个字段完整：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、发票号码、发票金额、开票日期、核验状态、异常原因、上报状态、操作。⚠️ 待确认: 原型列表比需求多4个字段（税率、销售方名称、受票方名称、油气票张数），共15列（含checkbox），需确认最终版本。 +- 关键验证点: 发票金额保留2位小数（价税合计）；开票日期格式正确；核验状态/异常原因/上报状态数据准确。 -### 4.2 发票验证 +### TP-D-003: 第三次上报发票信息字段完整性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证第三次上报详情弹窗中"发票信息"分组的17个字段完整展示。 +- 关键验证点: 托运单号数组支持多个托运单号；发票号码、发票代码号、发票金额(价税合计)、开票日期必选完整；销售方8个字段(名称/纳税人识别号/地址/电话/开户行/银行账户)完整；受票方6个字段(名称/纳税人识别号/地址/电话/开户行/银行卡号)完整；注：第三次上报无税率字段。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-TR-007 | 增值税发票信息正确 → 上报成功 | P1 | 📋 | 功能 | -| TP-TR-008 | 增值税发票验证失败 → 上报失败，提示检查发票信息 | P1 | 📋⚠️ | 异常 | -| TP-TR-009 | 发票号码重复上报 → 核验异常 | P1 | 📋 | 异常 | -| TP-TR-010 | 发票金额（价税合计）精度验证：保留2位小数 | P2 | 📋⚠️ | 边界 | -| TP-TR-011 | 发票号码/发票代码号格式校验 | P2 | 📋 | 功能 | +### TP-D-004: 第三次上报油气发票信息 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证运单关联油气发票时，第三次上报包含油气发票信息（油气托运单号、油气发票文件），支持多条油气发票。 +- 关键验证点: 有油气发票时正常上报；无油气发票时不影响上报（可选字段）；多条油气发票时字段展示正确；油气发票文件支持查看/下载。 -### 4.3 重试机制 +### TP-D-005: 后端校验 — 第三次上报依赖第二次上报完成 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-01：验证后端接口层面，第二次上报未完成（失败/进行中/未触发）时拒绝第三次上报，返回明确错误码。 +- 关键验证点: 第二次上报未完成时调用第三次上报接口被拒绝；错误码明确标识"前置上报（第二次）未完成"；后端通过查询运单上报状态表校验；第三阶段完整依赖链校验（第1→第2→第3）。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-TR-012 | 上报失败后自动重试最多3次 | P1 | 📋 | 功能 | -| TP-TR-013 | 3次重试全部失败后告警通知运营人员 | P1 | 📋⚠️ | 功能 | +### TP-D-006: 增值税发票验证失败处理 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证增值税发票验证失败时（发票号码/代码/金额不匹配等），第三次上报失败并返回明确错误提示。 +- 关键验证点: 发票号码格式无效时上报失败；发票代码与发票号码不匹配时上报失败；发票金额超出合理范围时上报失败；失败提示指明具体错误字段和原因。 + +### TP-D-007: 第三次上报自动重试 — 最多3次 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [需求] +- 描述: 验证第三次上报失败后自动重试（最多3次），全部失败后告警通知运营人员。 +- 关键验证点: 重试次数不超过3次；重试间隔递增；全部失败后标记"上传失败"并告警；告警通知中包含运单号、发票号、失败原因。 + +### TP-D-008: 第三次上报异常信息展示 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证第三次上报详情弹窗中"异常信息"分组包含核验状态、异常原因、异常时间、处理状态，与申诉模块数据联动。 +- 关键验证点: 核验通过时异常原因为空；核验异常时展示具体异常项和原因；核验状态与看板/申诉模块数据一致。 + +### TP-D-009: 第三次上报幂等性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 +- 来源: [最佳实践][历史缺陷] +- 描述: 验证第三次上报具有幂等性，同一运单同一发票信息不能重复上报。 +- 关键验证点: 同一运单重复触发第三次上报仅产生1条有效记录；分布式锁/幂等键控制并发；重复提交返回"上报已存在"提示。 + +### TP-D-010: 第三次上报发票金额精度校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [漏测清单][风险矩阵] +- 描述: 验证第三次上报的发票金额（价税合计）保留2位小数，不出现浮点数精度问题。 +- 关键验证点: 金额计算精度正确（如0.01元不丢失）；大金额（如 999999.99）上报准确；金额字段使用 DECIMAL 类型而非 FLOAT；上报数据与开票系统数据完全一致。 + +### TP-D-011: 第三次上报货物信息/保险信息逐源验证 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [漏测清单] +- 描述: 验证第三次上报中的运单信息字段数据来源正确——价格/货物信息来源于运单表，保险信息来源于保险模块，非缓存数据。 +- 关键验证点: 修改运单表数据后上报使用最新值；修改保险信息后上报使用最新值；字段取值链路可追溯；不依赖装货完成时的数据快照。 + +### TP-D-012: 发票合规查询 — 托运人发票是否系统核验合规 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证可通过 POST /verificationSummary/cargoOwnerInvoiceInfo 接口查询托运人（货主）发票是否已通过系统核验合规，用于判断第三次上报前置条件。 +- 关键验证点: 输入有效托运人信息返回发票合规状态；发票合规时返回通过标识；发票不合规时返回异常原因；接口支持批量查询多个托运人发票合规状态；接口响应时间在合理范围内（< 3s）。 --- -## 5. ETC发票上传 +## 模块E: ETC发票上传 (9个测试点) -### 5.1 触发与数据完整性 +### TP-E-001: ETC发票上传触发 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证ETC发票税务抵扣成功后，运营人员在运八系统手动确认抵扣完成，系统收到确认后触发ETC发票上传至安徽监管平台。 +- 关键验证点: 运营人员手动确认税务抵扣完成 → 系统触发ETC上传；上传数据包含运单信息+ETC发票信息18字段；上传成功后可在列表查看状态。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-ETC-001 | 税务抵扣完成后上传ETC发票 | P0 | 📋 | 功能 | -| TP-ETC-002 | 税务抵扣未完成时上传 → 失败提示 | P1 | 📋 | 功能 | -| TP-ETC-003 | ETC发票信息字段完整性（18字段/每张发票） | P1 | 📋 | 功能 | -| TP-ETC-004 | 多张ETC发票同时上传 | P2 | 📋 | 边界 | +### TP-E-002: ETC发票列表字段完整性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证ETC上传列表展示的11个字段完整：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、ETC发票号码、发票金额、税率、上传状态、操作。 +- 关键验证点: ETC发票号码与高速公路电子发票号码一致；发票金额和税率（3%）正确展示；上传状态标签颜色符合规范。 -### 5.2 税额计算 +### TP-E-003: ETC发票详情弹窗 — 字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证ETC发票详情弹窗包含3个分组：运单信息（7字段）、ETC发票信息（每张发票18字段）、异常信息。 +- 关键验证点: ETC发票18字段全部展示：ETC发票号码、ETC发票代码、开票时间、发票金额、税率(3%)、税额、价税合计、销售方名称、销售方税号、受票方名称、受票方税号、入口收费站、出口收费站、交易时间、交易金额、交易匹配时间、交易流水号、ETC发票文件；运单信息7字段完整；异常信息4字段完整。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-ETC-005 | 税额=发票金额×3%，计算结果正确 | P1 | 📋⚠️ | 功能 | -| TP-ETC-006 | 税额精度验证（保留2位小数，四舍五入） | P2 | 📋⚠️ | 边界 | -| TP-ETC-007 | 大额发票税额计算正确（如100万元×3%=30000元） | P2 | ⚠️风险矩阵 | 边界 | -| TP-ETC-008 | 小额发票税额计算正确（如10元×3%=0.30元） | P3 | 📋 | 边界 | +### TP-E-004: 税务抵扣完成前置条件校验 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 +- 来源: [需求] +- 描述: 验证ETC发票上传必须在税务抵扣完成后进行，未完成税务抵扣时上传被拒绝。 +- 关键验证点: 税务抵扣未完成时上传返回明确错误；错误提示包含"请先完成税务抵扣"；后端校验税务抵扣状态；税务抵扣完成后上传才可成功。 -### 5.3 发票验证与重试 +### TP-E-005: ETC发票验证失败处理 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证ETC发票信息验证失败时（发票号码/代码无效、金额不匹配、税率不正确等），上传失败并给出明确提示。 +- 关键验证点: 发票号码格式无效时上传失败；发票代码与号码不匹配时上传失败；税率非3%时提示税率异常；交易金额与实际通行费不匹配时验证失败；失败提示明确指示错误字段。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-ETC-009 | ETC发票验证通过 → 上传成功 | P1 | 📋 | 功能 | -| TP-ETC-010 | ETC发票验证失败 → 上报失败，提示检查发票信息 | P1 | 📋 | 异常 | -| TP-ETC-011 | 上报失败后自动重试最多3次 | P2 | 📋 | 功能 | -| TP-ETC-012 | 3次重试全部失败后告警通知运营人员 | P2 | 📋⚠️ | 功能 | +### TP-E-006: ETC上传自动重试 — 最多3次 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [需求] +- 描述: 验证ETC上传失败后自动重试最多3次，全部失败后告警通知。 +- 关键验证点: 3次重试均失败后标记"上传失败"并告警；重试间隔递增；每次重试记录到上报日志。 + +### TP-E-007: ETC税额计算校验 — 税额=不含税金额×税率 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][风险矩阵] +- 描述: 验证ETC发票税额计算公式：税额 = 不含税金额(invoiceAmount) x 税率(taxRate，如3%)。关键字段区分：invoiceAmount=不含税金额（保留2位小数）、totalPriceAndTax=价税合计（不含税金额+税额，保留2位小数）、taxAmount=税额（保留2位小数）。涉及资损风险需精确验证。 +- 关键验证点: 不含税金额100元×3% → 税额=3.00元, 价税合计=103.00元；不含税金额0.01元 → 税额=0.00元(或四舍五入规则明确)；大金额(如1000000元)计算不溢出；税额+不含税金额=价税合计(totalPriceAndTax)逻辑关系正确。 + +### TP-E-008: ETC上传幂等性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 +- 来源: [最佳实践][历史缺陷] +- 描述: 验证同一ETC发票不能重复上传，具有幂等性。 +- 关键验证点: 同一ETC发票号重复上传被拒绝；返回"该ETC发票已上传"提示；数据库存在唯一约束防止重复记录。 + +### TP-E-009: ETC多张发票同时上传 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [需求][项目画像] +- 描述: 验证同一运单可能关联多张ETC发票（不同路段），支持批量上传和多张发票的列表展示。 +- 关键验证点: 多张ETC发票各自独立上传互不干扰；列表中单运单可展示多张ETC发票记录；每张发票的税额独立计算；合计税额正确汇总。 --- -## 6. 异常申诉功能 +## 模块F: 异常申诉功能 (16个测试点) -### 6.1 申诉发起 +### TP-F-001: 申诉完整闭环 — 发起→复核→反馈→判断 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证申诉功能的完整闭环：查看异常 → 发起申诉 → 省平台复核 → 接收反馈 → 合规判断，端到端验证每个环节。注：已取消(130)由省平台侧操作设置（如运单作废），我方系统只读同步，UI不提供取消申诉操作。异常项申诉中(abnormalDetails[].state=110)可由省平台取消→异常项状态回退为100。⚠️ 待确认: 申诉状态枚举三版本不一致——需求(未申诉/申诉中/申诉通过/申诉驳回)、原型(未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回)、API(未申诉100/审核通过110/审核不通过120/已取消130)，以API §4.4为权威，需确认UI映射。 +- 关键验证点: 异常运单可发起申诉；申诉提交后状态保持"未申诉(100)"（异常项处理状态变为申诉中 abnormalDetails[].state=110）；省平台复核后反馈结果更新；反馈通过→申诉状态变为"审核通过(110)"；反馈驳回→申诉状态变为"审核不通过(120)"，可补充材料重新申诉。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-AP-001 | 核验异常后运营人员可发起申诉 | P1 | 📋 | 功能 | -| TP-AP-002 | 申诉信息完整性：申诉单号、上报阶段、异常项、申诉原因、申诉附件 | P1 | 📋 | 功能 | -| TP-AP-003 | 申诉附件上传（支持格式/大小限制验证） | P2 | 📋 | 功能 | -| TP-AP-004 | 申诉原因必填，为空时提示 | P2 | 📋 | 功能 | -| TP-AP-005 | 核验通过时申诉按钮不可见或置灰 | P1 | 💡易漏场景 | 功能 | -| TP-AP-006 | 同一运单可对多个异常项分别发起申诉 | P2 | 📋 | 边界 | +### TP-F-002: 申诉列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证申诉记录管理页面列表展示的13个字段完整：运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、异常项、申诉状态、申诉时间、申诉人、省平台反馈结果、监管平台反馈时间、操作。 +- 关键验证点: 每个字段有对应数据；申诉状态与需求定义一致；申诉时间为实际提交时间；省平台反馈结果与实际反馈内容一致。 -### 6.2 申诉状态流转 +### TP-F-003: 申诉状态流转 — 全部合法路径 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 +- 来源: [需求][漏测清单] +- 描述: 验证申诉状态流转全路径（以API §4.4为权威）：未申诉(100) → [提交申诉，异常项state=110申诉中] → 审核通过(110)[终态] / 审核不通过(120)[可重新申诉] → (审核不通过后) 重新申诉 → 未申诉(100)[新申诉单]。注：已取消(130)为省平台侧操作（如运单作废等），我省平台只读同步该状态，不主动发起取消；UI层不提供"取消申诉"按钮。⚠️ 待确认: 原型中"待省平台反馈"+"反馈处理中"如何映射到API枚举。 +- 关键验证点: 未申诉(100)状态下可发起申诉；异常项申诉中(abnormalDetails[].state=110)状态下不可重复发起同一异常项申诉；审核通过(110)后状态不可再变更（终态）；审核不通过(120)后可点击"重新申诉"发起新一轮申诉；已取消(130)为省平台外部操作设置的终态，我方系统只读；每种状态变更记录到处理记录时间线。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-AP-007 | 申诉状态流转：未申诉 → 申诉中 → 申诉通过 | P1 | 📋 | 功能 | -| TP-AP-008 | 申诉状态流转：未申诉 → 申诉中 → 申诉驳回 | P1 | 📋 | 功能 | -| TP-AP-009 | 申诉驳回后可重新发起申诉（补充材料） | P1 | 📋 | 功能 | -| TP-AP-010 | 申诉通过后重新核验异常项状态更新 | P1 | 📋 | 功能 | +### TP-F-004: 申诉详情弹窗 — 分组字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证申诉详情弹窗包含5个分组：申诉信息、运单信息、异常信息、省平台反馈信息、处理记录。 +- 关键验证点: 申诉信息分组含申诉单号/上报阶段/异常项/申诉原因/申诉状态/申诉时间/申诉人/申诉附件；省平台反馈信息含反馈结果/反馈时间/反馈意见；处理记录以时间线形式展示：操作人/操作时间/操作类型/操作内容。 -### 6.3 申诉记录管理 +### TP-F-005: 申诉附件上传功能 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][项目画像] +- 描述: 验证发起申诉时支持上传附件（如证明材料图片/PDF），附件上传功能正常。 +- 关键验证点: 支持上传多个附件；附件格式支持常见类型(png/jpg/pdf)；附件大小有限制且超标时提示；上传后可在详情弹窗中查看/下载；上传失败有重试机制。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-AP-011 | 列表字段完整性：运单号/托运单号/车牌号/司机姓名/托运方名称/上报阶段/核验状态/异常项/申诉状态/申诉时间/申诉人/省平台反馈结果/监管平台反馈时间 | P1 | 📋 | 功能 | -| TP-AP-012 | 详情弹窗分5组展示：申诉信息/运单信息/异常信息/省平台反馈/处理记录 | P2 | 📋 | 功能 | -| TP-AP-013 | 处理记录时间线展示：操作人/时间/类型/内容 | P2 | 📋 | 功能 | -| TP-AP-014 | 省平台反馈结果为空时显示"待反馈" | P2 | 💡易漏场景 | 功能 | +### TP-F-006: 审核不通过(120)后重新申诉 — 补充材料再发起 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证申诉被省平台审核不通过(120)后，运营人员可补充材料，点击"重新申诉"发起新一轮申诉。 +- 关键验证点: 审核不通过(120)状态下"重新申诉"按钮可见可用；重新申诉时原有申诉记录保留；新一轮申诉生成新的申诉单号；重新申诉可上传新的附件材料；新的申诉有独立的处理记录时间线。 -### 6.4 申诉闭环 +### TP-F-007: 17项核验（API文档定义）异常各自发起申诉 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [需求] +- 描述: 验证第二次上报的17项核验（API文档§4.1定义：委托合同100/承运合同120/实时定位130/运单时间逻辑140/车辆资质150/道路运输证160/驾驶证170/从业资格证180/车辆重复190/司机重复200/车辆轨迹210/运费收款220/公司统一收款230/集中支付240/资金流水250/发票信息260/非通行车辆可开票270）每项核验异常均可独立发起申诉。⚠️ 待确认: 核验项从需求7类扩展为API文档17项，需确认每项是否均有独立申诉入口。 +- 关键验证点: 每种核验异常项对应独立的申诉入口；申诉中(abnormalDetails[].state=110)的异常项信息与核验结果一致；不同异常项的申诉原因字段独立；某一异常项申诉不影响其他异常项。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-AP-015 | 完整闭环：异常查询 → 发起申诉 → 跟踪反馈 → 合规判断 | P1 | 📋 | 功能 | -| TP-AP-016 | 监管平台复核通过后，运单异常状态自动更新 | P1 | 📋 | 功能 | -| TP-AP-017 | 监管平台复核不通过，运营人员可补充材料重新申诉 | P1 | 📋 | 功能 | -| TP-AP-018 | 同一运单多次申诉记录完整保留 | P2 | 📋 | 功能 | +### TP-F-008: 从看板直接跳转申诉 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证从看板"操作"列点击"申诉"按钮，可跳转到申诉页面并自动填充运单号、异常项信息。 +- 关键验证点: 看板"申诉"按钮点击后路由跳转正确；跳转后页面自动加载该运单的异常信息；运单号和异常项预填充正确；不需要运营人员手动查找运单。 + +### TP-F-009: 申诉权限控制 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 权限控制 +- 来源: [项目画像] +- 描述: 验证仅运营人员有权发起申诉和管理申诉记录，其他角色（司机/车队长/货主/财务）不能操作申诉功能。 +- 关键验证点: 运营人员可见"申诉"按钮和申诉记录页面；司机端不可见申诉功能；财务人员可查看申诉记录但不可发起申诉；越权操作被正确拦截并记录审计日志。 + +### TP-F-010: 申诉处理记录时间线展示 +- 优先级: P2 +- 类型: UI测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证申诉详情弹窗中"处理记录"以时间线形式展示，每条记录包含操作人、操作时间、操作类型、操作内容。 +- 关键验证点: 时间线按时间倒序排列；每步操作（发起申诉/省平台反馈/重新申诉）均有一条记录；操作时间精确到秒；操作类型准确（发起申诉/审核通过/审核不通过等）。 + +### TP-F-011: 异常代码一览表匹配校验 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证需求文档中"异常代码一览表"定义的每种异常代码，在申诉页面中正确映射为对应的中文异常项名称。 +- 关键验证点: 每种异常代码有明确的中文描述；异常代码与异常项名称一一对应；省平台返回的异常代码能被正确解析；未知异常代码有兜底展示（如显示原始代码+标注"未知异常"）。 + +### TP-F-012: 申诉并发控制 — 同一异常项不可重复申诉 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 +- 来源: [漏测清单] +- 描述: 验证同一运单同一异常项申诉中(abnormalDetails[].state=110)状态下不可再次发起申诉，防止重复提交。 +- 关键验证点: 异常项申诉中(abnormalDetails[].state=110)状态下点击"申诉"按钮被禁用或提示"申诉处理中"；快速双击"提交申诉"按钮仅产生1条申诉记录；后端有状态校验，申诉中不可重新发起。 + +### TP-F-013: 申诉超时处理 — 省平台长时间无反馈 +- 优先级: P3 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [漏测清单] +- 描述: 验证申诉提交后，省平台长时间无反馈时，系统有合理的超时处理和状态提示。 +- 关键验证点: 申诉提交后超过一定时间（如7个工作日）无反馈时，系统给出"等待省平台复核中"的提示或超时告警；不自动变更申诉状态为通过/驳回；运营人员可查看申诉等待时长。 + +### TP-F-014: 单次申诉仅支持单个异常项 — 申诉表单单选约束 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [技术方案] +- 描述: 验证申诉表单中异常项选择器仅支持单选（radio或单选下拉），不可多选。根据API §3.3，`verificationAbnormalItems`参数"只支持单个异常项目申诉"。 +- 关键验证点: 异常项选择器为单选控件（非复选框）；不可同时勾选多个异常项后提交；选择器交互方式明确为单选（radio button 或 single-select dropdown）。 + +### TP-F-015: 多异常项运单逐次申诉 — 同一运单分别发起多次申诉 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [技术方案] +- 描述: 验证同一运单存在两个或多个异常项（如"车辆资质150"和"资金流水250"同时异常）时，需分别对每个异常项发起独立申诉，每个申诉对应一个申诉单号。 +- 关键验证点: 运单有2个异常项时，可分别发起2次申诉（每次选1个异常项）；每次申诉生成独立的申诉单号(complaintNumber)；申诉记录列表中该运单有2条独立申诉记录；不同异常项的申诉互不影响（一项通过另一项驳回各自独立流转）。 + +### TP-F-016: 申诉接口 verificationAbnormalItems 参数单值校验 — 传入多个ID时接口拒绝 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [技术方案] +- 描述: 验证调用 `POST /appeal/insert` 时，若 `verificationAbnormalItems` 传入多个异常项ID（如 "120,160"），接口应返回错误并拒绝提交。API §3.3 明确"只支持单个异常项目申诉"。 +- 关键验证点: 传入逗号分隔的多个ID（如"120,160"）时接口返回错误；错误码明确指示"仅支持单个异常项申诉"；传入单个ID时接口正常处理；传入空字符串或null时接口返回参数缺失错误；前端在提交前已做单选校验（双保险）。 --- -## 7. 上报日志 +## 模块G: 上报日志 (9个测试点) -### 7.1 查询与筛选 +### TP-G-001: 上报日志 — 按运单号/托运单号/货源单号模糊搜索 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证上报日志页面支持按运单号/托运单号/货源单号模糊搜索，快速定位相关日志。 +- 关键验证点: 输入完整单号精确匹配；输入部分字符模糊匹配；输入不存在的单号显示空结果；三种单号搜索互不干扰。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-LOG-001 | 运单号/托运单号/货源单号模糊搜索 | P2 | 📋 | 功能 | -| TP-LOG-002 | 上报阶段筛选：全部/第一次/第二次/第三次/ETC上传 | P2 | 📋 | 功能 | -| TP-LOG-003 | 上报结果筛选：全部/成功/失败 | P2 | 📋 | 功能 | -| TP-LOG-004 | 时间范围筛选：开始时间~结束时间 | P2 | 📋 | 功能 | -| TP-LOG-005 | 开始时间>结束时间时的错误提示 | P3 | 📋 | 功能 | +### TP-G-002: 上报日志 — 按上报阶段筛选 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证上报日志支持按"全部/第一次上报/第二次上报/第三次上报/ETC上传"筛选。 +- 关键验证点: 每种阶段独立筛选数据正确；ETC上传有独立筛选项；默认"全部"展示所有阶段日志。 -### 7.2 日志列表与详情 +### TP-G-003: 上报日志 — 按上报结果筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证上报日志支持按"全部/成功/失败"筛选上报结果。 +- 关键验证点: "成功"仅展示HTTP 2xx的日志；"失败"展示所有非成功日志(含超时/4xx/5xx)；筛选结果与实际日志记录一致。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-LOG-006 | 列表字段完整性：序号/货源单号/运单号/托运单号/上报阶段/上报结果/接口URL/HTTP状态码/响应时间/上报时间 | P2 | 📋 | 功能 | -| TP-LOG-007 | 详情弹窗展示完整请求报文和响应报文 | P2 | 📋 | 功能 | -| TP-LOG-008 | HTTP状态码非200时的响应报文展示 | P2 | 📋 | 功能 | -| TP-LOG-009 | 响应时间记录准确性（与实际接口耗时对比） | P3 | ⚠️风险矩阵 | 功能 | -| TP-LOG-010 | 日志分页功能正常 | P3 | 📋 | 功能 | +### TP-G-004: 上报日志 — 时间范围筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证上报日志支持按开始时间-结束时间范围筛选日志记录。 +- 关键验证点: 精确时间范围筛选数据正确；跨天/跨月筛选正常；开始时间>结束时间时给出提示或自动交换；不选时间范围默认显示全部。 + +### TP-G-005: 上报日志列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证上报日志列表展示的9个字段完整：序号、货源单号、运单号、托运单号、上报阶段、上报结果、接口URL、HTTP状态码、响应时间、上报时间、操作。 +- 关键验证点: 接口URL完整展示（含域名和路径）；HTTP状态码为实际返回状态码（200/400/500等）；响应时间单位明确（ms）；上报时间为实际请求发起时间。 + +### TP-G-006: 上报日志操作 — 弹窗查看完整请求/响应报文 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证点击日志"操作"列的详情按钮，弹窗展示完整的请求报文（Request）和响应报文（Response），用于问题排查。 +- 关键验证点: 请求报文完整展示：URL、Method、Headers、Body；响应报文完整展示：Status Code、Headers、Body；JSON 报文格式化展示（缩进/语法高亮）；长报文支持滚动查看和复制。 + +### TP-G-007: 上报日志全阶段覆盖 — 每个上报阶段的日志记录 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证每个上报阶段（第一次/第二次/第三次/ETC）以及自动修改字段接口的每次调用都在日志中有完整记录。 +- 关键验证点: 第一次上报+自动修改字段接口均有日志；第二次上报+7类核验结果均有日志；第三次上报日志完整；ETC上传日志完整；自动重试的每次请求均独立记录。 + +### TP-G-008: 上报日志失败记录的可追溯性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [漏测清单] +- 描述: 验证上报失败的日志记录足够详细，可通过日志定位失败原因——包括错误响应体、异常堆栈（如有）、重试次数等。 +- 关键验证点: 失败日志包含完整的Error Response Body；超时日志标注"timeout"并记录超时时长；重试日志中标注当前是第几次重试；异常日志可关联到具体运单ID便于排查。 + +### TP-G-009: 上报日志审计 — 操作人追踪 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 权限控制 +- 来源: [项目画像][最佳实践] +- 描述: 验证上报日志中可区分自动触发上报和手动触发上报，并记录操作人信息。 +- 关键验证点: 自动触发上报的日志标注"系统自动"或"auto"；手动触发上报的日志记录操作人用户名；手动上传的操作人信息与实际登录用户一致；审计能力满足合规要求。 --- -## 8. 通用跨模块测试点 +## 跨模块测试点（7个测试点） -### 8.1 数据与边界 +### TP-X-001: 完整三阶段依赖链端到端验证 — 后端三重校验 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 端到端验证三阶段依赖链：装货完成→第一次上报成功→打款完成→第二次上报成功→开票完成→第三次上报成功。核心验证后端在每个阶段都做了前置状态校验。 +- 关键验证点: 第1次上报失败→第2次上报接口拒绝；第2次上报失败→第3次上报接口拒绝；第1、2、3次顺序不可跳级；依赖链校验在后端实现（非仅前端控制）；每个阶段的阻断/通过状态独立。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-CM-001 | 金额字段精度：所有金额计算保留2位小数，无浮点精度丢失 | P1 | ⚠️风险矩阵💡 | 功能 | -| TP-CM-002 | 超长字符输入：运单号/托运单号输入超过256字符验证截断或提示 | P2 | 💡易漏场景 | 边界 | -| TP-CM-003 | 必填字段为空提交时的错误提示完整性 | P1 | 💡易漏场景 | 异常 | -| TP-CM-004 | 车牌号/身份证号/统一社会信用代码格式校验 | P2 | 📋 | 功能 | -| TP-CM-005 | 经纬度字段范围校验（经度-180~180，纬度-90~90） | P2 | 📋 | 边界 | -| TP-CM-006 | 手机号格式校验（11位数字） | P2 | 📋 | 功能 | +### TP-X-002: 多模块数据一致性 — 修改源数据后上报同步 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 数据校验 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-03：验证上报数据字段溯源正确，修改来源表数据后各阶段上报能感知变更并使用最新值。 +- 关键验证点: 修改司机信息→第一次上报使用最新司机信息；修改支付流水→第二次上报使用最新金额；修改发票信息→第三次上报使用最新发票数据；修改ETC信息→ETC上传使用最新数据；数据库查询日志可确认数据来源表，非缓存。 -### 8.2 网络与交互 +### TP-X-003: 安徽运八全流程 — 正常运单完整上报链路 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 端到端验证一个安徽税源地运单从装货到ETC上传的完整三阶段+ETC上报链路，所有阶段核验通过，无异常。 +- 关键验证点: 装货完成→第1次上报成功(绿色)→核验通过→自动修改字段→打款完成→第2次上报成功(核验全通过)→开票完成→第3次上报成功→税务抵扣→ETC上传成功；每个阶段看板数据正确更新；上报日志完整记录全链路。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-CM-007 | 上报请求超时（>30秒）的前端Loading状态和超时提示 | P2 | 💡易漏场景 | 性能 | -| TP-CM-008 | 重复提交防护：快速多次点击"手动上传"按钮不产生重复上报 | P1 | 💡易漏场景 | 功能 | -| TP-CM-009 | 断网环境下提交上报请求的错误提示和恢复机制 | P2 | 💡易漏场景 | 异常 | -| TP-CM-010 | 页面切换/刷新后表单数据是否保留 | P3 | 💡易漏场景 | 功能 | +### TP-X-004: 非安徽税源地运单 — 全流程不上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][项目画像] +- 描述: 验证税源地为非安徽省（如云南=28）的运单，全部三个阶段和ETC上传均不触发上报。 +- 关键验证点: 云南税源地运单装货完成不触发第1次上报；打款完成不触发第2次上报；开票完成不触发第3次上报；税务抵扣不触发ETC上传；看板中不显示该运单。 -### 8.3 权限 +### TP-X-005: 三阶段上报各省份数据隔离 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 权限控制 +- 来源: [项目画像][历史缺陷] +- 描述: 验证多省份部署场景下，安徽运八上报数据与其他省份（如云南）上报数据完全隔离，互不干扰。 +- 关键验证点: 安徽运单仅上报至安徽监管平台；云南运单仅上报至云南监管平台；省份代码各自独立（安徽=34、云南=28）；不同省份的上报日志和数据记录物理/逻辑隔离。 -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-CM-011 | 未登录用户直接通过URL访问上报看板 → 拦截跳转登录 | P2 | 💡易漏场景🏢 | 安全 | -| TP-CM-012 | 非运营人员角色（司机/货主）无法访问上报管理页面 | P1 | 🏢 | 权限 | -| TP-CM-013 | 运营人员不可操作其他运营人员的申诉单（权限隔离） | P2 | 🏢 | 权限 | -| TP-CM-014 | 超级管理员拥有全部操作权限 | P2 | 🏢 | 权限 | +### TP-X-006: 回单签收后自动流转上报 — 时序正确性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 状态流转 +- 来源: [需求][项目画像] +- 描述: 验证运单在回单签收→财务打款的时序下，第二次上报的触发时机为"打款完成"而非"回单签收"，时序正确。 +- 关键验证点: 回单签收完成但未打款时，不触发第二次上报；财务打款完成后才触发第二次上报；上报时间戳与打款完成时间关系合理。 -### 8.4 与现有系统交互 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-CM-015 | 第一次上报数据与运单管理模块数据一致性 | P1 | 🏢 | 功能 | -| TP-CM-016 | 第二次上报资金流水与账户管理/支付流水数据一致性 | P1 | 🏢⚠️ | 功能 | -| TP-CM-017 | 第三次上报发票数据与开票审核模块数据一致性 | P1 | 🏢 | 功能 | -| TP-CM-018 | ETC发票与车辆服务模块数据关联 | P2 | 🏢 | 功能 | -| TP-CM-019 | 司机信息上报与司机审核模块数据一致性 | P1 | 🏢 | 功能 | -| TP-CM-020 | 车辆信息上报与车辆审核模块数据一致性 | P1 | 🏢 | 功能 | +### TP-X-007: 已上报运单不可取消或删除 [技术方案] +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证上传至服务平台的运单不支持取消或删除操作。按主管部门要求，上传后的运单不允许修改任何信息，企业应在运单信息确认后再进行上报。服务平台在统计合规率时不会将未完结的运单计算在内。 +- 关键验证点: 已上报运单在服务平台无"取消"或"删除"操作入口；API层面无取消/删除运单接口；尝试通过任何方式取消运单均被拒绝并有明确提示；未完结运单不影响合规率统计。 --- -## 9. 测试点覆盖率统计 +## 历史缺陷防御映射表 -| 模块 | P0 | P1 | P2 | P3 | 合计 | -| :--- | :---: | :---: | :---: | :---: | :---: | -| 上报运单看板 | 0 | 8 | 10 | 2 | 20 | -| 第一次上报 | 3 | 16 | 9 | 0 | 28 | -| 第二次上报 | 3 | 19 | 10 | 0 | 32 | -| 第三次上报 | 1 | 8 | 4 | 0 | 13 | -| ETC发票上传 | 1 | 5 | 5 | 1 | 12 | -| 异常申诉 | 0 | 10 | 7 | 1 | 18 | -| 上报日志 | 0 | 0 | 6 | 4 | 10 | -| 通用跨模块 | 0 | 8 | 10 | 2 | 20 | -| **合计** | **8** | **74** | **61** | **10** | **153** | +| 历史缺陷ID | 防御测试点 | +| :--- | :--- | +| BUG-202607-01（阶段依赖链断裂） | TP-B-005, TP-C-020, TP-D-005, TP-X-001 | +| BUG-202607-02（重试幂等缺陷） | TP-B-014, TP-C-021, TP-D-009, TP-E-008, TP-F-012 | +| BUG-202607-03（跨模块数据不一致） | TP-C-002, TP-C-003, TP-D-011, TP-X-002 | +| BUG-202607-04（省份代码硬编码） | TP-B-004, TP-X-005 | -> 覆盖率：P0 100% | P1 ≥90% | P2 ≥80% | P3 ≥60% +## 漏测清单覆盖映射表 + +| 漏测项 | 覆盖测试点 | +| :--- | :--- | +| 空值/Null | TP-B-018 | +| 金额精度 | TP-C-002, TP-D-010, TP-E-007 | +| 重复提交/防抖 | TP-B-014, TP-C-021, TP-D-009, TP-E-008 | +| 超时处理 | TP-B-015, TP-B-016, TP-F-013 | +| 列表字段完整性 | TP-A-008, TP-C-004, TP-D-002, TP-E-002, TP-F-002, TP-G-005 | +| 查询重置 | TP-A-007 | +| 状态与按钮映射 | TP-A-010, TP-B-009 | +| 多阶段依赖链 | TP-B-005, TP-C-020, TP-D-005, TP-X-001 | +| 第三方核验逐项覆盖 | TP-C-006 ~ TP-C-019（7类核验×通过+异常=14个测试点）+ TP-C-026 ~ TP-C-049（API文档12项补充核验×通过+异常=24个测试点），共覆盖API文档17项核验 | 已覆盖 | +| 重试+手动触发并发 | TP-B-014, TP-C-021 | +| 跨模块数据一致性 | TP-C-002, TP-C-003, TP-X-002 | +| 省份/区域配置隔离 | TP-B-004, TP-X-005 | +| 上报数据字段溯源 | TP-C-002, TP-D-011, TP-X-002 | +| 标签颜色映射 | TP-A-009, TP-B-010, TP-C-005 | +| 详情弹窗分组完整性 | TP-A-011, TP-B-011, TP-B-012, TP-C-004, TP-D-003, TP-E-003, TP-F-004 | +| 轨迹数据边界（2~2000） | TP-C-018, TP-C-019 | +| 申诉闭环 | TP-F-001, TP-F-003, TP-F-006 | +| 操作日志可追溯 | TP-G-005, TP-G-006, TP-G-007, TP-G-008, TP-G-009 | + +--- + +> ⚠️ 待确认项： +> 1. 需求中"异常代码一览表"章节仅有标题无具体内容，需与产品确认完整的异常代码映射表后补充 TP-F-011 的详细验证数据。 +> 2. 自动重试的具体间隔时间（5s/15s/30s 为假设值），需与技术方案确认后更新 TP-B-007, TP-C-022, TP-D-007, TP-E-006 中的重试间隔。 +> 3. ETC税额边界值（0.01元 → 税额=0.00）的四舍五入规则需与财务确认，更新 TP-E-007。 +> 4. 申诉超时告警阈值（假设7个工作日）需与产品确认，更新 TP-F-013。 +> 5. 需求关联与冲突报告未识别到冲突项，建议在后续需求评审中人工确认安徽运八与现有云南运八上报逻辑是否存在字段/接口冲突。 diff --git a/output/versions/安徽运八需求/VERSION_INDEX.md b/output/versions/安徽运八需求/VERSION_INDEX.md index 08d951d..2131729 100644 --- a/output/versions/安徽运八需求/VERSION_INDEX.md +++ b/output/versions/安徽运八需求/VERSION_INDEX.md @@ -2,5 +2,6 @@ | 版本 | 类型 | 内容摘要 | 目录 | | --- | --- | --- | --- | -| v1 | 部分产物快照 | - | `output\versions\安徽运八需求\v1` | -| v2 | 完整流水线快照 | manifest、analysis、relation_report、test_points、test_cases_markdown、excel、normalized_inputs | `output\versions\安徽运八需求\v2` | +| v3 | 完整流水线快照 | manifest、analysis、relation_report、test_points、test_cases_markdown、excel、normalized_inputs | `output\versions\安徽运八需求\v3` | +| v4 | 完整流水线快照 | manifest、analysis、relation_report、test_points、test_cases_markdown、excel、normalized_inputs | `output\versions\安徽运八需求\v4` | +| v5 | 完整流水线快照 | manifest、analysis、relation_report、test_points、test_cases_markdown、excel、normalized_inputs | `output\versions\安徽运八需求\v5` | diff --git a/output/versions/安徽运八需求/v1/snapshot_meta.json b/output/versions/安徽运八需求/v1/snapshot_meta.json deleted file mode 100644 index 11def36..0000000 --- a/output/versions/安徽运八需求/v1/snapshot_meta.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "base_name": "安徽运八需求", - "version": "v1", - "snapshot_type": "partial_snapshot", - "summary": [] -} diff --git a/output/versions/安徽运八需求/v2/安徽运八需求.json b/output/versions/安徽运八需求/v2/安徽运八需求.json deleted file mode 100644 index d25203d..0000000 --- a/output/versions/安徽运八需求/v2/安徽运八需求.json +++ /dev/null @@ -1,79 +0,0 @@ -{ - "base_name": "安徽运八需求", - "review_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_评审报告.md", - "coverage_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_覆盖率审计.md", - "verdict_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_质量裁决.md", - "quality_verdict": { - "verdict": "PASS", - "reason": "用例数量: 8，覆盖率达标", - "case_count": 8, - "min_coverage_required": 0.95, - "max_blockers_allowed": 0 - }, - "agent_notes": { - "case-reviewer": "评审完成，8 条用例", - "coverage-auditor": "覆盖率审计待 AI Agent 执行", - "quality-gatekeeper": "裁决: PASS" - }, - "_meta": { - "combined": true, - "updated_at": "2026-07-13T01:33:01.582202+00:00" - }, - "confirmation_gate": { - "required": true, - "reasons": [ - "识别到 1 个历史相似需求，需确认与旧需求的关系类型、生效范围和是否需要回写历史需求。" - ], - "pending_markers_count": 0, - "decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md", - "decision_status": "confirmed", - "decision_status_label": "已确认", - "allow_export_before_confirmation": true, - "candidate_decision_files": [ - "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" - ], - "suggested_decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" - }, - "related_requirements": [ - { - "path": "E:\\test\\QaAutomationHub\\source_docs\\requirements_raw\\网货企业端接口文档（最新）.pdf", - "similarity": 0.069578 - } - ], - "conflict_candidates_count": 0, - "risk_matrix": { - "risks": [ - { - "id": "RISK-FINANCIAL", - "category": "资损", - "keywords_matched": [ - "金额", - "支付" - ], - "likelihood": 2, - "impact": 5, - "score": 10, - "level": "P1", - "conflict_amplified": false - }, - { - "id": "RISK-AVAILABILITY", - "category": "可用性", - "keywords_matched": [ - "超时", - "重试" - ], - "likelihood": 2, - "impact": 4, - "score": 8, - "level": "P2", - "conflict_amplified": false - } - ], - "total": 2, - "p0_count": 0, - "p1_count": 1 - }, - "requirement_source_file": "source_docs\\requirements_raw\\安徽运八需求.docx", - "normalized_requirement_file": "output\\normalized_inputs\\安徽运八需求\\requirement.md" -} diff --git a/output/versions/安徽运八需求/v2/安徽运八需求_分析.md b/output/versions/安徽运八需求/v2/安徽运八需求_分析.md deleted file mode 100644 index cf5d4be..0000000 --- a/output/versions/安徽运八需求/v2/安徽运八需求_分析.md +++ /dev/null @@ -1,106 +0,0 @@ -# 安徽运八需求 分析报告 - -> 生成时间: 2026-07-13 -> 文档角色: 需求分析 -> 原始来源: `source_docs/requirements_raw/安徽运八需求.docx` - -## 1. 需求概述 - -根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八）。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。 - -### 核心目标 -- 实现上报流程的自动化管理（自动触发 + 重试 + 通知） -- 提供异常监控与核验结果展示 -- 提供向监管平台发起申诉的完整闭环能力 -- ETC发票上传作为税务抵扣凭证 - -### 涉及角色 -- 运营人员：看板监控、手动上传、发起申诉 -- 系统：自动触发上报、自动重试、自动更新字段 -- 监管平台（安徽运八）：核验上报数据、返回核验结果 -- 司机/财务：触发装货完成/打款完成/开票完成（间接触发上报） - -## 2. 功能模块分析 - -| 模块 | 功能 | 触发方式 | 依赖 | 关键风险 | -| :--- | :--- | :--- | :--- | :--- | -| 上报运单看板 | 汇总展示、筛选查询、导出 | 手动访问 | 无 | 数据量大时性能 | -| 第一次上报 | 装货完成后上报基础运单数据 | 自动触发 | 运单装货完成 | 失败阻断后续上报 | -| 第二次上报 | 打款完成后上报资金流水+轨迹 | 自动触发 | 第一次上报通过 | 7类核验，异常最多 | -| 第三次上报 | 开票完成后上报发票数据 | 自动触发 | 第二次上报通过 | 发票验证失败 | -| ETC发票上传 | 税务抵扣后上传ETC发票 | 手动触发 | 税务抵扣完成 | 税额计算精度 | -| 异常申诉 | 核验异常→申诉→监管复核→结果 | 手动触发 | 核验异常 | 申诉闭环完整性 | -| 上报日志 | 接口调用记录、请求/响应查看 | 手动访问 | 无 | 日志完整性 | - -## 3. 关键业务规则 - -### 3.1 上报阶段依赖链 -``` -装货完成 → 第一次上报 → 核验通过 → 自动更新字段 - ↓ -打款完成 → 第二次上报 → 7类核验（车辆资质/司机资质/资金流水/集中支付/合同/轨迹合规/运单重复） - ↓ -开票完成 → 第三次上报 → 发票验证 - ↓ -税务抵扣 → ETC发票上传 -``` - -### 3.2 重试策略 -- 所有上报阶段：失败后自动重试，最多3次 -- 3次全部失败：通知运营人员（站内信/其他方式） -- 重试期间幂等保护：不产生重复上报 - -### 3.3 状态机 -``` -上传中(蓝) ──成功→ 已上传(绿) -上传中(蓝) ──超时→ 上传失败(红) → 手动上传 → 上传中 -上传中(蓝) ──校验失败→ 异常(橙) → 查看详情 -``` - -### 3.4 申诉状态机 -``` -未申诉 → 申诉中 → 申诉通过(绿) / 申诉驳回 → 重新申诉 → 申诉中 -``` - -## 4. 数据量预估 - -| 对象 | 预估量级 | 说明 | -| :--- | :--- | :--- | -| 日上报运单数 | 1000-5000 | 根据平台运单量 | -| 每运单轨迹点数 | 2-2000 | 取决于运输距离 | -| 申诉并发量 | < 100/天 | 异常率较低 | -| 日志保留期 | 建议≥90天 | 审计和排查需要 | - -## 5. 歧义标注 - -> ⚠️ 待确认：重试间隔时间未在需求中明确，建议确认（如30s/60s/120s递增） -> 影响范围: 所有上报阶段的重试行为 -> 建议确认方向: 与产品和安徽运八平台确认合理的重试间隔 - -> ⚠️ 待确认：站内信通知的具体内容模板未定义 -> 影响范围: 运营人员通知体验 -> 建议确认方向: 确认通知应包含哪些字段（运单号/失败原因/重试次数/建议操作） - -> ⚠️ 待确认：上报数据中"省份代码"字段默认值（当前项目属云南省=28，但本需求为安徽=34？） -> 影响范围: 第一次上报司机信息省份代码 -> 建议确认方向: 确认安徽运八上报的省份代码应使用哪个值 - -> ⚠️ 待确认：导出Excel的数据量上限未定义 -> 影响范围: 看板导出功能 -> 建议确认方向: 确认是否需要限制单次导出条数（如最多10000条） - -## 6. 与项目画像的差异化分析 - -| 维度 | 项目画像（云南省） | 安徽运八需求 | 差异 | -| :--- | :--- | :--- | :--- | -| 上报省份 | 云南省(reportProvince=28) | 安徽省 | 省份代码需切换 | -| 支付方式 | arpa_2 + 网商银行(浦发/快钱/光大) | 同平台支付体系 | 资金流水需关联现有支付渠道 | -| 目标角色 | 运营/货主/车队长/司机/财务 | 主要面向运营人员 | 权限模型可复用 | -| 测试环境 | ybxcx.ynyun8.com:8000 | 同环境 | 测试环境可复用 | - -## 7. 风险总结 - -| 风险ID | 类别 | 等级 | 说明 | -| :--- | :--- | :---: | :--- | -| RISK-FINANCIAL | 资损 | P1 | 资金流水金额不匹配、流水号重复可能导致财务数据错误 | -| RISK-AVAILABILITY | 可用性 | P2 | 上报接口超时或不可用影响业务流程，需重试+告警兜底 | diff --git a/output/versions/安徽运八需求/v2/安徽运八需求_测试点.md b/output/versions/安徽运八需求/v2/安徽运八需求_测试点.md deleted file mode 100644 index d8401f8..0000000 --- a/output/versions/安徽运八需求/v2/安徽运八需求_测试点.md +++ /dev/null @@ -1,352 +0,0 @@ -# 安徽运八需求 测试点矩阵 - -> 生成时间: 2026-07-13 -> 来源标注: 📋需求 | 🐛历史缺陷 | ⚠️风险矩阵 | 🔗冲突修订 | 🏢项目画像 | 💡易漏场景 - ---- - -## 1. 上报运单看板 (Dashboard) - -### 1.1 查询与筛选 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-DB-001 | 运单号精确搜索，验证返回唯一匹配结果 | P1 | 📋 | 功能 | -| TP-DB-002 | 运单号/托运单号/货源单号模糊搜索，输入部分字符验证模糊匹配 | P1 | 📋 | 功能 | -| TP-DB-003 | 上报阶段筛选：全部/第一次/第二次/第三次，各选项独立验证 | P1 | 📋 | 功能 | -| TP-DB-004 | 核验状态筛选：全部/异常/通过，验证筛选结果正确性 | P1 | 📋 | 功能 | -| TP-DB-005 | 申诉状态筛选：全部/未申诉/申诉中/申诉通过/申诉驳回 | P1 | 📋 | 功能 | -| TP-DB-006 | 多条件组合查询（运单号模糊+上报阶段+核验状态+申诉状态） | P1 | 📋🏢 | 功能 | -| TP-DB-007 | 查询按钮点击后正确执行搜索并刷新列表 | P1 | 📋 | 功能 | -| TP-DB-008 | 重置按钮清空所有查询条件并刷新列表为默认状态 | P2 | 📋 | 功能 | -| TP-DB-009 | 查询结果为空时显示友好的空状态提示 | P2 | 💡易漏场景 | 功能 | -| TP-DB-010 | 模糊搜索输入特殊字符（SQL注入/HTML标签/Emoji）验证安全性 | P2 | 💡易漏场景 | 安全 | - -### 1.2 列表展示 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-DB-011 | 列表字段完整性：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、申诉状态、异常项、货物名称、合同金额、最新核验时间 | P1 | 📋 | 功能 | -| TP-DB-012 | 列表默认排序验证（按最新核验时间倒序或需求指定） | P2 | 📋🏢 | 功能 | -| TP-DB-013 | 分页功能：首页/上一页/下一页/末页/跳转/每页条数切换 | P2 | 💡易漏场景 | 功能 | -| TP-DB-014 | 合同金额显示格式（千分位、小数位精度）验证 | P2 | ⚠️风险矩阵 | 功能 | -| TP-DB-015 | 异常项字段在核验通过时为空，核验异常时显示具体异常项 | P1 | 📋 | 功能 | - -### 1.3 操作按钮 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-DB-016 | 申诉按钮：点击跳转至申诉页面，携带对应运单信息 | P1 | 📋 | 功能 | -| TP-DB-017 | 进度按钮：点击查看运单上报进度（三次上报+ETC的完成状态） | P2 | 📋 | 功能 | -| TP-DB-018 | 详情按钮：点击打开运单详情弹窗，展示完整上报信息 | P1 | 📋 | 功能 | -| TP-DB-019 | 导出按钮：验证导出Excel文件内容与列表筛选结果一致 | P2 | 📋 | 功能 | -| TP-DB-020 | 导出数据量较大时（>1000条）验证导出性能和无数据丢失 | P3 | 🏢 | 性能 | - ---- - -## 2. 第一次上报（装货完成） - -### 2.1 自动触发 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-FR-001 | 运单装货完成后系统自动触发第一次上报 | P0 | 📋 | 功能 | -| TP-FR-002 | 上报数据完整性：建单信息（13字段）+ 托运人信息（7字段）+ 收货方信息（5字段）+ 司机信息（13字段）+ 车辆信息（19字段）+ 货物信息（可多条）+ 保险信息（可选） | P0 | 📋 | 功能 | -| TP-FR-003 | 必选字段缺失时上报失败，系统返回明确错误提示 | P1 | 📋 | 异常 | -| TP-FR-004 | 可选字段（委托合同编号、运输里程、框架合同编号、挂车牌照号等）为空时上报正常 | P1 | 📋 | 功能 | -| TP-FR-005 | 货物信息多条记录上报验证（≥2条货物） | P2 | 📋 | 边界 | -| TP-FR-006 | 保险信息为空（可选子对象）时上报正常 | P2 | 📋 | 功能 | -| TP-FR-007 | 保险信息填写完整时上报成功 | P2 | 📋 | 功能 | - -### 2.2 核验通过后自动更新 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-FR-008 | 核验通过后系统自动调用"修改第一次上报部分字段"接口 | P0 | 📋 | 功能 | -| TP-FR-009 | 验证更新字段范围限定为装货后可变字段（实际里程等） | P1 | 📋 | 功能 | -| TP-FR-010 | 更新操作失败时的异常处理与重试机制 | P1 | ⚠️风险矩阵 | 异常 | -| TP-FR-011 | 核验未通过时不触发自动更新 | P1 | 📋 | 功能 | - -### 2.3 重试机制 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-FR-012 | 上报失败后自动重试，最多3次 | P1 | 📋 | 功能 | -| TP-FR-013 | 第1次重试成功后不再继续重试 | P1 | 📋 | 功能 | -| TP-FR-014 | 第2次重试成功后不再继续重试 | P2 | 📋 | 功能 | -| TP-FR-015 | 3次重试全部失败后通过站内信通知运营人员 | P1 | 📋 | 功能 | -| TP-FR-016 | 重试间隔时间验证（避免瞬时高频重试） | P2 | ⚠️风险矩阵 | 性能 | -| TP-FR-017 | 重试期间手动触发上报的幂等性（不产生重复上报） | P1 | 💡易漏场景 | 功能 | - -### 2.4 状态流转 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-FR-018 | 状态流转：上传中 → 已上传（核验通过） | P1 | 📋 | 功能 | -| TP-FR-019 | 状态流转：上传中 → 上传失败（超时，可手动上传） | P1 | 📋 | 功能 | -| TP-FR-020 | 状态流转：上传中 → 异常（数据校验不通过） | P1 | 📋 | 功能 | -| TP-FR-021 | 标签颜色：蓝色(上传中)/绿色(已上传)/红色(上传失败)/橙色(异常) | P2 | 📋 | 功能 | -| TP-FR-022 | 上传失败状态下"手动上传"按钮可见且可操作 | P1 | 📋 | 功能 | -| TP-FR-023 | 异常状态下"详情"按钮可查看异常原因 | P1 | 📋 | 功能 | -| TP-FR-024 | 第一次上报失败导致后续第二次、第三次上报无法触发 | P0 | 📋⚠️ | 功能 | - -### 2.5 详情弹窗 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-FR-025 | 详情弹窗按子对象分组展示（建单/托运人/收货方/司机/车辆/货物/保险/异常） | P1 | 📋 | 功能 | -| TP-FR-026 | 详情弹窗各字段值与上报数据一致 | P1 | 📋 | 功能 | -| TP-FR-027 | 详情弹窗关闭后正确返回列表页 | P2 | 📋 | 功能 | -| TP-FR-028 | 异常信息区在无异常时不展示或显示"无异常" | P2 | 📋 | 功能 | - ---- - -## 3. 第二次上报（打款完成） - -### 3.1 自动触发与数据完整性 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-SR-001 | 运费支付完成后系统自动触发第二次上报 | P0 | 📋 | 功能 | -| TP-SR-002 | 上报数据完整性：运单/托运方/收货方信息 + 资金流水 + 车辆轨迹 + 异常信息 | P0 | 📋 | 功能 | -| TP-SR-003 | 资金流水信息字段完整性：支付金额/方式/时间/付款方/收款方/收款人/收款账号/账号类型/流水号/支付状态 | P1 | 📋⚠️ | 功能 | -| TP-SR-004 | 车辆轨迹点位数量边界：最少2个点、最多2000个点 | P1 | 📋 | 边界 | -| TP-SR-005 | 车辆轨迹点位数量=1时上报失败 | P2 | 📋 | 边界 | -| TP-SR-006 | 车辆轨迹点位数量=2000时上报成功 | P2 | 📋 | 边界 | -| TP-SR-007 | 车辆轨迹点位数量>2000时取前2000个或报错 | P2 | 📋 | 边界 | - -### 3.2 核验内容（7大类） - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-SR-008 | 运单重复核验：同一运单第二次上报时正确识别为重复 | P0 | 📋 | 功能 | -| TP-SR-009 | 车辆资质核验：道路运输证在有效期内 → 通过 | P1 | 📋 | 功能 | -| TP-SR-010 | 车辆资质核验：道路运输证已过期 → 异常 | P1 | 📋 | 异常 | -| TP-SR-011 | 司机资质核验：从业资格证在有效期内 → 通过 | P1 | 📋 | 功能 | -| TP-SR-012 | 司机资质核验：从业资格证已过期 → 异常 | P1 | 📋 | 异常 | -| TP-SR-013 | 集中支付核验：资金流水通过网货平台集中支付 → 通过 | P1 | 📋 | 功能 | -| TP-SR-014 | 集中支付核验：资金流水未通过平台集中支付 → 异常 | P1 | 📋⚠️ | 异常 | -| TP-SR-015 | 资金流水核验：流水单号不重复 + 金额匹配 → 通过 | P1 | 📋⚠️ | 功能 | -| TP-SR-016 | 资金流水核验：流水单号重复 → 异常，系统自动检查提示 | P0 | 📋⚠️ | 异常 | -| TP-SR-017 | 资金流水核验：金额不匹配 → 异常 | P1 | 📋⚠️ | 异常 | -| TP-SR-018 | 合同核验：运输合同和委托合同均有效 → 通过 | P1 | 📋 | 功能 | -| TP-SR-019 | 合同核验：运输合同无效/过期 → 异常 | P1 | 📋 | 异常 | -| TP-SR-020 | 车辆轨迹合规核验：轨迹真实且与运单路线匹配 → 通过 | P1 | 📋 | 功能 | -| TP-SR-021 | 车辆轨迹合规核验：点位不足或偏差过大 → 异常 | P1 | 📋 | 异常 | - -### 3.3 补传轨迹 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-SR-022 | 车辆轨迹合规异常时，"补传轨迹"功能可见可用 | P1 | 📋 | 功能 | -| TP-SR-023 | 补传轨迹后重新核验通过 | P1 | 📋 | 功能 | -| TP-SR-024 | 补传轨迹数据格式与原轨迹数据格式一致 | P2 | 📋 | 功能 | -| TP-SR-025 | 补传轨迹后再次异常仍可继续补传 | P2 | 📋 | 功能 | - -### 3.4 收款账号类型 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-SR-026 | 个人账户：标签蓝色，显示司机个人银行卡账号 | P2 | 📋 | 功能 | -| TP-SR-027 | 对公账户：标签绿色，显示企业银行账号 | P2 | 📋 | 功能 | -| TP-SR-028 | 收款账号类型字段在列表和详情中展示一致 | P2 | 📋 | 功能 | - -### 3.5 重试与告警 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-SR-029 | 上报失败后自动重试最多3次 | P1 | 📋 | 功能 | -| TP-SR-030 | 3次重试全部失败后告警通知运营人员 | P1 | 📋⚠️ | 功能 | -| TP-SR-031 | 告警通知渠道验证（站内信/其他方式） | P2 | 📋 | 功能 | -| TP-SR-032 | 重试期间资金流水单号重复的幂等处理 | P1 | ⚠️风险矩阵 | 功能 | - ---- - -## 4. 第三次上报（开票完成） - -### 4.1 触发条件与数据完整性 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-TR-001 | 第二次上报完成后，发票开具完成触发第三次上报 | P0 | 📋 | 功能 | -| TP-TR-002 | 第二次上报未完成时，第三次上报无法触发 | P1 | 📋 | 功能 | -| TP-TR-003 | 上报数据完整性：运单信息(托运单号数组) + 发票信息(17字段) + 油气发票(可选) | P1 | 📋 | 功能 | -| TP-TR-004 | 托运单号数组包含多个托运单号时上报成功 | P2 | 📋 | 边界 | -| TP-TR-005 | 油气发票信息为空（可选）时上报正常 | P2 | 📋 | 功能 | -| TP-TR-006 | 油气发票多条记录时上报正常 | P2 | 📋 | 功能 | - -### 4.2 发票验证 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-TR-007 | 增值税发票信息正确 → 上报成功 | P1 | 📋 | 功能 | -| TP-TR-008 | 增值税发票验证失败 → 上报失败，提示检查发票信息 | P1 | 📋⚠️ | 异常 | -| TP-TR-009 | 发票号码重复上报 → 核验异常 | P1 | 📋 | 异常 | -| TP-TR-010 | 发票金额（价税合计）精度验证：保留2位小数 | P2 | 📋⚠️ | 边界 | -| TP-TR-011 | 发票号码/发票代码号格式校验 | P2 | 📋 | 功能 | - -### 4.3 重试机制 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-TR-012 | 上报失败后自动重试最多3次 | P1 | 📋 | 功能 | -| TP-TR-013 | 3次重试全部失败后告警通知运营人员 | P1 | 📋⚠️ | 功能 | - ---- - -## 5. ETC发票上传 - -### 5.1 触发与数据完整性 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-ETC-001 | 税务抵扣完成后上传ETC发票 | P0 | 📋 | 功能 | -| TP-ETC-002 | 税务抵扣未完成时上传 → 失败提示 | P1 | 📋 | 功能 | -| TP-ETC-003 | ETC发票信息字段完整性（18字段/每张发票） | P1 | 📋 | 功能 | -| TP-ETC-004 | 多张ETC发票同时上传 | P2 | 📋 | 边界 | - -### 5.2 税额计算 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-ETC-005 | 税额=发票金额×3%，计算结果正确 | P1 | 📋⚠️ | 功能 | -| TP-ETC-006 | 税额精度验证（保留2位小数，四舍五入） | P2 | 📋⚠️ | 边界 | -| TP-ETC-007 | 大额发票税额计算正确（如100万元×3%=30000元） | P2 | ⚠️风险矩阵 | 边界 | -| TP-ETC-008 | 小额发票税额计算正确（如10元×3%=0.30元） | P3 | 📋 | 边界 | - -### 5.3 发票验证与重试 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-ETC-009 | ETC发票验证通过 → 上传成功 | P1 | 📋 | 功能 | -| TP-ETC-010 | ETC发票验证失败 → 上报失败，提示检查发票信息 | P1 | 📋 | 异常 | -| TP-ETC-011 | 上报失败后自动重试最多3次 | P2 | 📋 | 功能 | -| TP-ETC-012 | 3次重试全部失败后告警通知运营人员 | P2 | 📋⚠️ | 功能 | - ---- - -## 6. 异常申诉功能 - -### 6.1 申诉发起 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-AP-001 | 核验异常后运营人员可发起申诉 | P1 | 📋 | 功能 | -| TP-AP-002 | 申诉信息完整性：申诉单号、上报阶段、异常项、申诉原因、申诉附件 | P1 | 📋 | 功能 | -| TP-AP-003 | 申诉附件上传（支持格式/大小限制验证） | P2 | 📋 | 功能 | -| TP-AP-004 | 申诉原因必填，为空时提示 | P2 | 📋 | 功能 | -| TP-AP-005 | 核验通过时申诉按钮不可见或置灰 | P1 | 💡易漏场景 | 功能 | -| TP-AP-006 | 同一运单可对多个异常项分别发起申诉 | P2 | 📋 | 边界 | - -### 6.2 申诉状态流转 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-AP-007 | 申诉状态流转：未申诉 → 申诉中 → 申诉通过 | P1 | 📋 | 功能 | -| TP-AP-008 | 申诉状态流转：未申诉 → 申诉中 → 申诉驳回 | P1 | 📋 | 功能 | -| TP-AP-009 | 申诉驳回后可重新发起申诉（补充材料） | P1 | 📋 | 功能 | -| TP-AP-010 | 申诉通过后重新核验异常项状态更新 | P1 | 📋 | 功能 | - -### 6.3 申诉记录管理 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-AP-011 | 列表字段完整性：运单号/托运单号/车牌号/司机姓名/托运方名称/上报阶段/核验状态/异常项/申诉状态/申诉时间/申诉人/省平台反馈结果/监管平台反馈时间 | P1 | 📋 | 功能 | -| TP-AP-012 | 详情弹窗分5组展示：申诉信息/运单信息/异常信息/省平台反馈/处理记录 | P2 | 📋 | 功能 | -| TP-AP-013 | 处理记录时间线展示：操作人/时间/类型/内容 | P2 | 📋 | 功能 | -| TP-AP-014 | 省平台反馈结果为空时显示"待反馈" | P2 | 💡易漏场景 | 功能 | - -### 6.4 申诉闭环 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-AP-015 | 完整闭环：异常查询 → 发起申诉 → 跟踪反馈 → 合规判断 | P1 | 📋 | 功能 | -| TP-AP-016 | 监管平台复核通过后，运单异常状态自动更新 | P1 | 📋 | 功能 | -| TP-AP-017 | 监管平台复核不通过，运营人员可补充材料重新申诉 | P1 | 📋 | 功能 | -| TP-AP-018 | 同一运单多次申诉记录完整保留 | P2 | 📋 | 功能 | - ---- - -## 7. 上报日志 - -### 7.1 查询与筛选 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-LOG-001 | 运单号/托运单号/货源单号模糊搜索 | P2 | 📋 | 功能 | -| TP-LOG-002 | 上报阶段筛选：全部/第一次/第二次/第三次/ETC上传 | P2 | 📋 | 功能 | -| TP-LOG-003 | 上报结果筛选：全部/成功/失败 | P2 | 📋 | 功能 | -| TP-LOG-004 | 时间范围筛选：开始时间~结束时间 | P2 | 📋 | 功能 | -| TP-LOG-005 | 开始时间>结束时间时的错误提示 | P3 | 📋 | 功能 | - -### 7.2 日志列表与详情 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-LOG-006 | 列表字段完整性：序号/货源单号/运单号/托运单号/上报阶段/上报结果/接口URL/HTTP状态码/响应时间/上报时间 | P2 | 📋 | 功能 | -| TP-LOG-007 | 详情弹窗展示完整请求报文和响应报文 | P2 | 📋 | 功能 | -| TP-LOG-008 | HTTP状态码非200时的响应报文展示 | P2 | 📋 | 功能 | -| TP-LOG-009 | 响应时间记录准确性（与实际接口耗时对比） | P3 | ⚠️风险矩阵 | 功能 | -| TP-LOG-010 | 日志分页功能正常 | P3 | 📋 | 功能 | - ---- - -## 8. 通用跨模块测试点 - -### 8.1 数据与边界 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-CM-001 | 金额字段精度：所有金额计算保留2位小数，无浮点精度丢失 | P1 | ⚠️风险矩阵💡 | 功能 | -| TP-CM-002 | 超长字符输入：运单号/托运单号输入超过256字符验证截断或提示 | P2 | 💡易漏场景 | 边界 | -| TP-CM-003 | 必填字段为空提交时的错误提示完整性 | P1 | 💡易漏场景 | 异常 | -| TP-CM-004 | 车牌号/身份证号/统一社会信用代码格式校验 | P2 | 📋 | 功能 | -| TP-CM-005 | 经纬度字段范围校验（经度-180~180，纬度-90~90） | P2 | 📋 | 边界 | -| TP-CM-006 | 手机号格式校验（11位数字） | P2 | 📋 | 功能 | - -### 8.2 网络与交互 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-CM-007 | 上报请求超时（>30秒）的前端Loading状态和超时提示 | P2 | 💡易漏场景 | 性能 | -| TP-CM-008 | 重复提交防护：快速多次点击"手动上传"按钮不产生重复上报 | P1 | 💡易漏场景 | 功能 | -| TP-CM-009 | 断网环境下提交上报请求的错误提示和恢复机制 | P2 | 💡易漏场景 | 异常 | -| TP-CM-010 | 页面切换/刷新后表单数据是否保留 | P3 | 💡易漏场景 | 功能 | - -### 8.3 权限 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-CM-011 | 未登录用户直接通过URL访问上报看板 → 拦截跳转登录 | P2 | 💡易漏场景🏢 | 安全 | -| TP-CM-012 | 非运营人员角色（司机/货主）无法访问上报管理页面 | P1 | 🏢 | 权限 | -| TP-CM-013 | 运营人员不可操作其他运营人员的申诉单（权限隔离） | P2 | 🏢 | 权限 | -| TP-CM-014 | 超级管理员拥有全部操作权限 | P2 | 🏢 | 权限 | - -### 8.4 与现有系统交互 - -| ID | 测试点 | 优先级 | 来源 | 测试类型 | -| :--- | :--- | :---: | :--- | :---: | -| TP-CM-015 | 第一次上报数据与运单管理模块数据一致性 | P1 | 🏢 | 功能 | -| TP-CM-016 | 第二次上报资金流水与账户管理/支付流水数据一致性 | P1 | 🏢⚠️ | 功能 | -| TP-CM-017 | 第三次上报发票数据与开票审核模块数据一致性 | P1 | 🏢 | 功能 | -| TP-CM-018 | ETC发票与车辆服务模块数据关联 | P2 | 🏢 | 功能 | -| TP-CM-019 | 司机信息上报与司机审核模块数据一致性 | P1 | 🏢 | 功能 | -| TP-CM-020 | 车辆信息上报与车辆审核模块数据一致性 | P1 | 🏢 | 功能 | - ---- - -## 9. 测试点覆盖率统计 - -| 模块 | P0 | P1 | P2 | P3 | 合计 | -| :--- | :---: | :---: | :---: | :---: | :---: | -| 上报运单看板 | 0 | 8 | 10 | 2 | 20 | -| 第一次上报 | 3 | 16 | 9 | 0 | 28 | -| 第二次上报 | 3 | 19 | 10 | 0 | 32 | -| 第三次上报 | 1 | 8 | 4 | 0 | 13 | -| ETC发票上传 | 1 | 5 | 5 | 1 | 12 | -| 异常申诉 | 0 | 10 | 7 | 1 | 18 | -| 上报日志 | 0 | 0 | 6 | 4 | 10 | -| 通用跨模块 | 0 | 8 | 10 | 2 | 20 | -| **合计** | **8** | **74** | **61** | **10** | **153** | - -> 覆盖率：P0 100% | P1 ≥90% | P2 ≥80% | P3 ≥60% diff --git a/output/versions/安徽运八需求/v2/安徽运八需求_测试用例.md b/output/versions/安徽运八需求/v2/安徽运八需求_测试用例.md deleted file mode 100644 index 33db92c..0000000 --- a/output/versions/安徽运八需求/v2/安徽运八需求_测试用例.md +++ /dev/null @@ -1,63 +0,0 @@ -# 安徽运八需求 测试用例 - -> 生成时间: 2026-07-13 -> 基于: 测试点矩阵、需求文档、风险评估报告、项目画像、历史缺陷、易漏场景清单 -> 验证标准: 每条用例同时覆盖 UI 反馈 + 数据状态变化 - -| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | -| :--- | :--- | :--- | :---: | :--- | :--- | :--- | :--- | :--- | :--- | -| TC-DB-001 | 上报运单看板 | 多条件组合查询（运单号模糊+上报阶段+核验状态+申诉状态） | P1 | 功能测试 | 1.已登录超管账号 2.系统存在多条不同状态的上报运单 | 1.进入看板 2.输入运单号部分字符 3.选上报阶段=第一次上报 4.选核验状态=通过 5.选申诉状态=未申诉 6.点查询 | 运单号部分字符、筛选条件组合 | UI:列表仅展示满足所有条件的运单，筛选条件保持选中。数据:后端返回结果AND匹配所有条件 | | -| TC-DB-002 | 上报运单看板 | 重置按钮清空所有查询条件 | P2 | 功能测试 | 已设置任意查询条件 | 1.设置多个筛选条件 2.点重置按钮 | 任意筛选条件 | UI:所有条件恢复默认，列表刷新为全量数据。数据:查询接口参数为空或默认值 | | -| TC-DB-003 | 上报运单看板 | 查询结果为空时显示友好提示 | P2 | 功能测试 | 已登录 | 1.输入不存在的运单号 2.点查询 | 运单号=NOTEXIST999999 | UI:显示空状态提示图标+文案，不显示空白表格或报错。数据:接口返回空数组，HTTP 200 | | -| TC-DB-004 | 上报运单看板 | 列表字段完整性与异常项差异化展示 | P1 | 功能测试 | 1.存在核验通过运单 2.存在核验异常运单 | 1.进入看板 2.查看表头 3.对比两种状态运单行 | 核验通过运单、核验异常运单 | UI:表头含14个字段；通过行异常项为空；异常行异常项显示具体原因；合同金额千分位+2位小数。数据:接口字段与UI一一对应 | 合TP-DB-011, TP-DB-015 | -| TC-DB-005 | 上报运单看板 | 导出Excel内容与筛选结果一致 | P2 | 功能测试 | 已设置筛选条件使结果集约50条 | 1.设置筛选条件 2.点导出 3.下载并打开Excel | 50条筛选结果 | UI:导出按钮可点击，下载Excel包含所有列表字段。数据:Excel行数=筛选结果数，字段顺序一致，金额为数字格式 | | -| TC-DB-006 | 上报运单看板 | 特殊字符输入安全性（SQL注入/HTML/Emoji） | P2 | 安全性测试 | 已登录 | 1.输入`' OR '1'='1`点查询 2.输入``点查询 3.输入Emoji点查询 | SQL注入字符串、XSS字符串、Emoji表情 | UI:不报错不弹窗不异常页面。数据:后端返回空结果或正确转义，HTTP 200，无注入生效 | | -| TC-FR-001 | 第一次上报 | 装货完成后系统自动触发第一次上报（全字段完整性） | P0 | 功能测试 | 1.运单已接单 2.车辆/司机/货物/托运方/收货方信息完整 3.司机完成装货确认 | 1.司机APP端确认装货完成 2.回管理端查看上报状态 | 完整运单数据（建单13+托运人7+收货方5+司机13+车辆19+货物+保险字段） | UI:列表出现该运单，状态:上传中(蓝)→已上传(绿)；看板显示"第一次上报"。数据:上报接口被调用，请求体含完整子对象，HTTP 200，数据库状态更新 | | -| TC-FR-002 | 第一次上报 | 必选字段缺失（从业资格证号）→上报异常 | P1 | 功能测试 | 司机从业资格证号为空 | 1.触发装货完成上报 2.查看上报结果 | 司机信息缺失从业资格证号 | UI:状态=异常(橙)，操作列显示详情按钮；详情中异常原因含"从业资格证号缺失"。数据:接口返回校验失败，数据库记录状态=异常+异常原因 | | -| TC-FR-003 | 第一次上报 | 可选字段为空（委托合同编号/运输里程/保险信息）→上报正常 | P1 | 功能测试 | 必选字段完整，可选字段均为空 | 1.触发装货完成上报 2.查看结果 | 可选字段均为空的运单 | UI:状态正常流转为"已上传"(绿)。数据:请求体可选字段值为null/空字符串，接口返回成功 | | -| TC-FR-004 | 第一次上报 | 货物信息多条记录(≥2条)上报 | P2 | 功能测试 | 运单包含3条货物信息（钢材/木板/配件） | 1.触发上报 2.查看详情弹窗货物信息区 | 3条货物数据 | UI:详情弹窗展示3条货物记录各含4字段。数据:请求体goodsInfos数组length=3，接口成功 | | -| TC-FR-005 | 第一次上报 | 核验通过后自动调用"修改第一次上报部分字段"更新实际里程 | P0 | 功能测试 | 1.第一次上报已触发 2.装货后实际里程变化(预估500→实际520km) | 1.上报成功核验通过 2.观察自动更新 3.查看运单里程字段 | 预估里程=500km, 实际里程=520km | UI:无人工干预下运单里程自动更新为520km；操作日志有"自动更新第一次上报字段"记录。数据:修改接口被调用，mileage=520，数据库运单里程更新 | | -| TC-FR-006 | 第一次上报 | 上报失败→自动重试3次→站内信通知运营人员 | P1 | 功能测试 | 模拟安徽运八接口不可用(超时或500) | 1.触发上报 2.等待重试周期 3.观察最终结果 4.检查站内信 | 接口超时异常 | UI:状态流转:上传中→上传失败(红标签)，出现"手动上传"按钮；运营收到站内信含运单号和失败原因。数据:接口调用4次(首+3重试)，重试间隔递增；站内信表新增通知记录 | | -| TC-FR-007 | 第一次上报 | 重试中手动触发上报→幂等性校验 | P1 | 功能测试 | 上报失败正处自动重试中 | 1.运单重试中 2.运营点"手动上传" | 重试中的运单 | UI:提示"上报处理中请勿重复操作"或排队等待；不出现两条上报记录。数据:同一运单在安徽运八平台仅一条记录 | | -| TC-FR-008 | 第一次上报 | 第一次上报失败阻断后续第二、三次上报 | P0 | 功能测试 | 运单第一次上报失败(3次重试全败) | 1.确认第一次上报失败 2.尝试触发第二次上报 3.尝试触发第三次上报 | 第一次上报失败的运单 | UI:第二次上报按钮不可见/置灰提示"请先完成第一次上报"；第三次同样阻断。数据:第二/三次接口调用被前置校验拦截，日志无记录 | | -| TC-FR-009 | 第一次上报 | 详情弹窗8组字段分组展示与数据一致性 | P1 | 功能测试 | 存在已完成的第一次上报运单 | 1.点详情 2.逐一查看建单/托运人/收货方/司机/车辆/货物/保险/异常分组 3.与运单管理模块核对 | 完整上报数据 | UI:弹窗按8组展示，分组标题明确；无异常时显示"无异常"；保险为空显示"-"。数据:弹窗字段值与上报请求体一致，与运单管理模块一致 | | -| TC-FR-010 | 第一次上报 | 4种状态标签颜色验证 | P2 | 功能测试 | 准备4个运单分别处于上传中/已上传/上传失败/异常状态 | 1.进入列表 2.观察4条运单状态标签颜色 | 4种状态的运单 | UI:上传中=蓝标签；已上传=绿标签；上传失败=红标签；异常=橙标签。数据:状态字段值与颜色映射正确 | | -| TC-SR-001 | 第二次上报 | 打款完成后自动触发上报（含资金流水+轨迹+7核验） | P0 | 功能测试 | 1.运单第一次上报已完成 2.财务完成打款 | 1.财务打款 2.查看第二次上报列表 | 完整打款数据(金额/流水号/时间/收款方/收款账号/账号类型) | UI:列表出现该运单状态"上传中"(蓝)；展示承运运费/总金额/付款方式/时间/收款人/收款账号/账号类型。数据:上报接口被调用，请求体含资金流水+轨迹信息；流水数据与账户管理模块一致 | | -| TC-SR-002 | 第二次上报 | 车辆轨迹点位边界值:2个点(起点+终点)→成功 | P1 | 功能测试 | 轨迹数据仅2个点位 | 1.触发第二次上报 2.查看结果 | 轨迹数据=[起点,终点] len=2 | UI:上报成功状态"已上传"。数据:请求体轨迹数组length=2，接口成功 | | -| TC-SR-003 | 第二次上报 | 车辆轨迹点位边界值:1个点→失败 | P2 | 功能测试 | 轨迹数据仅1个点位 | 1.触发第二次上报 2.查看结果 | 轨迹数据=[单点] len=1 | UI:上报失败状态"异常"(橙)；异常原因含"轨迹点位不足"。数据:接口返回校验失败提示轨迹点数需≥2 | | -| TC-SR-004 | 第二次上报 | 运单重复上报→核验异常 | P0 | 功能测试 | 运单已完成第二次上报且核验通过 | 1.尝试再次上报同一运单 | 已通过的运单 | UI:系统提示"该运单已完成第二次上报"或被阻止；不产生新记录。数据:接口被前置校验拦截或安徽平台返回"运单重复"；数据库无重复记录 | | -| TC-SR-005 | 第二次上报 | 车辆资质核验:道路运输证有效期内→通过 | P1 | 功能测试 | 车辆道路运输证有效期至2026-12-31(有效期内) | 1.触发第二次上报 2.等待核验 3.查看核验结果 | 有效期内的道路运输证 | UI:核验状态"通过"，无"车辆资质"异常项。数据:核验接口返回车辆资质=通过 | | -| TC-SR-006 | 第二次上报 | 车辆资质核验:道路运输证已过期→异常 | P1 | 功能测试 | 车辆道路运输证有效期至2025-01-01(已过期) | 1.触发第二次上报 2.等待核验 | 过期的道路运输证 | UI:核验状态"异常"(橙)；异常项显示"车辆资质核验"不通过；可发起申诉。数据:核验接口返回车辆资质=异常，原因"道路运输证过期" | | -| TC-SR-007 | 第二次上报 | 资金流水单号重复→系统自动拦截 | P0 | 功能测试 | 系统中已存在流水号LS202607130001的记录 | 1.创建新运单打款但流水号重复 2.触发第二次上报 | 重复流水号=LS202607130001 | UI:系统上报前自动检测到重复，提示"流水单号已使用请核实"；上报被阻止。数据:流水号唯一索引生效；接口未被调用；操作日志记录拦截 | | -| TC-SR-008 | 第二次上报 | 资金流水金额不匹配(合同10000 vs 打款9500)→核验异常 | P1 | 功能测试 | 合同金额10000元，实际打款9500元 | 1.触发第二次上报 2.等待核验 | 合同金额=10000, 打款金额=9500 | UI:核验状态"异常"；异常项含"资金流水核验"不通过，原因"金额不匹配"。数据:核验接口返回资金流水核验=异常 | | -| TC-SR-009 | 第二次上报 | 车辆轨迹合规异常→补传轨迹→重新核验通过 | P1 | 功能测试 | 第二次上报后"车辆轨迹合规"核验异常 | 1.点"补传轨迹" 2.上传补充GPS点位文件 3.提交 4.等待重新核验 | 补充轨迹GPS文件 | UI:补传轨迹按钮可见可点击；上传后提示成功等待核验；核验通过后异常消除状态变"通过"。数据:补传轨迹追加到原数据；重调核验接口；核验结果更新为通过 | | -| TC-SR-010 | 第二次上报 | 收款账号类型标签:个人=蓝色/对公=绿色 | P2 | 功能测试 | 两个运单:一个司机个人账户、一个企业对公账户 | 1.进入列表 2.查看收款账号类型标签 | 个人账户(司机银行卡)、对公账户(企业银行账号) | UI:个人账户=蓝标签"个人账户"；对公账户=绿标签"对公账户"。数据:字段值正确对应 | | -| TC-SR-011 | 第二次上报 | 重试3次全失败→告警通知运营人员 | P1 | 功能测试 | 模拟安徽运八接口不可用 | 1.触发第二次上报 2.等3次重试全失败 3.检查告警 | 接口不可用 | UI:状态变为"上传失败"(红)；出现"手动上传"按钮；运营收到站内信通知含运单号/失败原因/重试次数。数据:重试次数=3；站内信表新增告警通知；操作日志记录完整 | | -| TC-TR-001 | 第三次上报 | 开票完成后触发上报（含17字段发票+托运单号数组） | P0 | 功能测试 | 1.运单第二次上报已完成 2.发票已开具 | 1.开票审核模块完成开票 2.查看第三次上报列表 | 完整发票信息(17字段)+托运单号数组 | UI:列表出现该运单含发票号码/金额/开票日期；状态:上传中→已上传。数据:上报接口被调用；发票数据与开票审核模块一致 | | -| TC-TR-002 | 第三次上报 | 第二次上报未完成时第三次上报被阻断 | P1 | 功能测试 | 运单仅完成第一次上报，第二次未完成 | 1.尝试开票并触发第三次上报 | 第二次未完成的运单 | UI:系统提示"请先完成第二次上报"；上报按钮不可见/置灰。数据:第三次上报接口调用被前置校验拦截 | | -| TC-TR-003 | 第三次上报 | 增值税发票验证失败→上报异常 | P1 | 功能测试 | 发票号码格式错误或与代码不匹配 | 1.触发第三次上报 2.查看结果 | 错误的发票号码/代码 | UI:上报状态"异常"(橙)；原因提示"增值税发票验证失败"及具体原因。数据:接口返回发票验证失败业务错误码；数据库记录异常状态 | | -| TC-TR-004 | 第三次上报 | 发票金额精度:价税合计保留2位小数四舍五入 | P2 | 功能测试 | 发票金额=12345.678元(超2位小数) | 1.触发第三次上报 2.查看列表发票金额 | 发票金额=12345.678 | UI:列表发票金额显示12,345.68(四舍五入)。数据:请求体invoiceAmount=12345.68，无浮点精度丢失 | | -| TC-TR-005 | 第三次上报 | 油气发票多条记录上报 | P2 | 功能测试 | 运单关联2条油气发票 | 1.触发第三次上报 2.查看详情弹窗油气发票区 | 2条油气发票记录 | UI:油气发票区展示2条记录各含托运单号和发票文件。数据:请求体油气发票数组length=2 | | -| TC-ETC-001 | ETC发票上传 | 税务抵扣完成后上传ETC发票(18字段/每张) | P1 | 功能测试 | 1.车辆完成高速运输 2.ETC发票已获取 3.税务抵扣完成 | 1.选运单 2.上传ETC发票信息 3.提交 | ETC发票完整18字段 | UI:上传成功状态"已上传"(绿)；列表含ETC发票号码/金额/税率/上传状态。数据:请求体含18字段；税额=发票金额×3% | 合TP-ETC-001,003 | -| TC-ETC-002 | ETC发票上传 | 税务抵扣未完成→上传被阻止 | P1 | 功能测试 | ETC发票存在但税务抵扣未完成 | 1.尝试上传ETC发票 | 抵扣未完成的ETC发票 | UI:系统提示"请先完成税务抵扣"；上传被阻止。数据:上传接口调用被前置校验拦截 | | -| TC-ETC-003 | ETC发票上传 | 税额计算:3%税率精度验证(1000元→30.00元) | P1 | 功能测试 | ETC发票金额1000.00元 | 1.上传1000元ETC发票 2.查看税额 | 发票金额=1000.00 | UI:税额显示30.00元。数据:taxAmount=1000.00×0.03=30.00，2位小数 | | -| TC-ETC-004 | ETC发票上传 | 税额计算:大额发票100万元→30000.00元 | P2 | 功能测试 | ETC发票金额1000000元 | 1.上传100万元ETC发票 2.查看税额 | 发票金额=1000000.00 | UI:税额显示30,000.00元。数据:taxAmount=1000000.00×0.03=30000.00，无精度问题 | | -| TC-ETC-005 | ETC发票上传 | ETC发票验证失败→上报异常提示检查发票 | P2 | 功能测试 | ETC发票号码/代码与实际不匹配 | 1.上传错误ETC发票 2.查看验证结果 | 错误的ETC发票号码/代码 | UI:状态"异常"(橙)；原因提示"ETC发票验证失败请检查发票信息"。数据:接口返回ETC发票验证失败 | | -| TC-AP-001 | 异常申诉 | 核验异常运单发起申诉（申诉原因+附件） | P1 | 功能测试 | 运单第二次上报核验异常(车辆轨迹合规异常) | 1.找到异常运单 2.点"申诉" 3.填原因:"实际路线因道路施工绕行" 4.上传附件(施工证明截图) 5.提交 | 申诉原因文本、路线施工证明截图 | UI:提交后提示"申诉已提交等待监管平台复核"；申诉状态变"申诉中"；列表新增申诉记录。数据:申诉表新增记录:申诉单号自动生成/异常项=车辆轨迹合规/原因已保存/附件已存储/状态=申诉中/时间=当前 | | -| TC-AP-002 | 异常申诉 | 申诉原因必填校验→空值拦截 | P2 | 功能测试 | 存在可申诉异常运单 | 1.点申诉 2.不填原因 3.直接提交 | 申诉原因为空 | UI:输入框标红或提示"请填写申诉原因"；提交按钮不响应或提示错误。数据:申诉接口未被调用；数据库无新记录 | | -| TC-AP-003 | 异常申诉 | 申诉状态流转:申诉中→申诉通过(监管复核通过) | P1 | 功能测试 | 已提交申诉(申诉中状态) | 1.等待监管平台复核通过 2.查看申诉记录 | 申诉中的记录 | UI:申诉状态变"申诉通过"(绿)；省平台反馈"复核通过"；原运单异常项消除或已解决。数据:申诉记录状态更新；省平台反馈时间/结果/意见已记录；关联运单核验状态更新 | | -| TC-AP-004 | 异常申诉 | 申诉状态流转:申诉中→申诉驳回→重新申诉 | P1 | 功能测试 | 申诉被监管平台驳回 | 1.查看驳回记录和原因 2.点"重新申诉" 3.补充材料修改原因 4.提交 | 驳回原因、补充材料 | UI:驳回记录显示"复核不通过"+反馈意见；"重新申诉"按钮可见；表单保留原内容可编辑；提交后状态变"申诉中"。数据:新申诉关联原单号；原记录保留不变；新申诉状态=申诉中 | | -| TC-AP-005 | 异常申诉 | 详情弹窗:时间线展示处理记录(申诉→驳回→重申诉→通过) | P2 | 功能测试 | 申诉记录有多次操作历史 | 1.点"详情" 2.查看处理记录区 | 完整申诉历史数据 | UI:处理记录时间线展示从早到晚；每条含操作人/时间/类型/内容；类型区分清晰(发起申诉/省平台反馈/重新申诉/复核通过)。数据:数据库操作日志完整 | | -| TC-AP-006 | 异常申诉 | 核验通过运单无申诉入口→越权防护 | P1 | 功能测试 | 运单核验状态为"通过" | 1.找到核验通过运单 2.查看操作列 3.尝试通过URL直接访问申诉接口 | 核验通过的运单 | UI:操作列不显示"申诉"按钮。数据:申诉接口返回"当前运单核验状态不允许申诉" | | -| TC-LOG-001 | 上报日志 | 多条件日志查询(上报阶段+结果+时间范围) | P2 | 功能测试 | 系统存在多条不同阶段日志 | 1.进入上报日志 2.选阶段=第二次上报 3.选结果=失败 4.设时间范围近7天 5.点查询 | 筛选条件组合 | UI:列表展示满足条件的日志含10个字段(序号/货源单号/运单号/托运单号/上报阶段/上报结果/接口URL/HTTP状态码/响应时间/上报时间)。数据:查询条件正确传递；返回数据与筛选一致 | | -| TC-LOG-002 | 上报日志 | 失败日志详情弹窗:完整请求/响应报文(JSON格式化) | P2 | 功能测试 | 存在一条失败的第二次上报日志 | 1.点失败日志"详情" 2.查看请求和响应报文 | 失败日志记录 | UI:弹窗展示完整请求报文(JSON格式化含所有字段)和响应报文(含错误码/错误信息)；报文可复制。数据:展示报文与实际上报接口请求/响应一致 | | -| TC-CM-001 | 通用跨模块 | 金额精度:多次计算无累积浮点误差 | P1 | 功能测试 | 运单合同金额=12345.67元 | 1.第一次上报看合同金额 2.第二次上报看总金额 3.第三次上报看发票金额 4.对比三次精度 | 合同金额=12345.67 | UI:所有金额显示2位小数千分位正确无精度丢失。数据:DB存DECIMAL(18,2)；接口返回2位小数字符串；计算无浮点误差 | 来源:风险矩阵+易漏场景 | -| TC-CM-002 | 通用跨模块 | 重复提交防抖:快速多次点击手动上传→仅一次请求 | P1 | 功能测试 | 存在上传失败运单 | 1.连续快速点击"手动上传"3次 2.等待结果 | 上传失败运单 | UI:按钮首次点击后变loading/置灰防重复点击；仅产生一次上报请求。数据:上报接口仅调用1次；上报日志仅1条记录 | 来源:易漏场景 | -| TC-CM-003 | 通用跨模块 | 未登录直接URL访问上报看板→拦截跳转登录 | P2 | 安全性测试 | 退出登录状态 | 1.清除登录态 2.地址栏直接输入看板URL 3.观察页面 | 看板URL | UI:重定向到登录页或显示"请先登录"；不展示上报数据。数据:上报API返回401 Unauthorized | | -| TC-CM-004 | 通用跨模块 | 权限隔离:司机账号(15188888888)无法访问上报管理 | P1 | 安全性测试 | 司机账号15188888888/88888888 | 1.司机登录管理端 2.尝试访问看板/申诉管理等页面 | 司机账号凭证 | UI:菜单无"安徽运八"入口；直接URL访问重定向或"无权限"；不展示上报数据。数据:上报API返回403 Forbidden | | -| TC-CM-005 | 通用跨模块 | 第一次上报与运单管理模块数据一致性 | P1 | 功能测试 | 运单在运单管理模块已有完整数据 | 1.记录运单管理模块关键字段 2.触发第一次上报 3.在详情弹窗核对 | 货源单号/运单号/托运单号/车牌号/司机姓名/托运方/货物/装货地址/卸货地址/运输里程 | UI:上报详情字段值与运单管理一致。数据:上报请求体值来源于运单管理DB记录，数据一致 | | -| TC-CM-006 | 通用跨模块 | 第二次上报资金流水与账户管理支付流水数据一致性 | P1 | 功能测试 | 运单已完成打款，支付流水号已知 | 1.在账户管理→支付流水查看打款数据 2.触发第二次上报 3.在上报详情核对资金流水 | 支付金额/流水号/支付时间/收款方 | UI:第二次上报详情中资金流水与账户管理模块一致。数据:上报请求体资金流水与支付流水表数据一致；流水号完全匹配 | | -| TC-CM-007 | 通用跨模块 | 司机信息上报(13字段)与司机审核模块数据一致性 | P1 | 功能测试 | 司机已在审核管理模块通过审核 | 1.记录司机审核模块司机信息 2.触发第一次上报 3.核对上报详情司机信息 | 司机姓名/身份证号/驾驶证号/从业资格证号/手机号等13字段 | UI:上报详情司机13字段与审核模块一致。数据:上报请求体driverInfo来源于司机审核表 | | -| TC-CM-008 | 通用跨模块 | 上报接口超时(>30s)→前端Loading+超时提示 | P2 | 功能测试 | 模拟上报接口响应超30秒 | 1.触发上报 2.观察前端表现 | 超时接口 | UI:按钮Loading状态(转圈/禁用)；超30秒后显示"上报超时请稍后查看结果"；不白屏不假死。数据:接口超时后后端异步处理或标记超时；DB状态=上传失败/原因=超时 | | - -> 用例总数: 53 (P0:7 / P1:26 / P2:20) diff --git a/output/versions/安徽运八需求/v2/安徽运八需求_测试用例.xlsx b/output/versions/安徽运八需求/v2/安徽运八需求_测试用例.xlsx deleted file mode 100644 index f09d7b2..0000000 Binary files a/output/versions/安徽运八需求/v2/安徽运八需求_测试用例.xlsx and /dev/null differ diff --git a/output/versions/安徽运八需求/v2/normalized_inputs/requirement.md b/output/versions/安徽运八需求/v3/normalized_inputs/requirement.md similarity index 93% rename from output/versions/安徽运八需求/v2/normalized_inputs/requirement.md rename to output/versions/安徽运八需求/v3/normalized_inputs/requirement.md index 80c5f56..95a9d8e 100644 --- a/output/versions/安徽运八需求/v2/normalized_inputs/requirement.md +++ b/output/versions/安徽运八需求/v3/normalized_inputs/requirement.md @@ -5,7 +5,7 @@ 安徽运八需求 一、需求概述 -根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八）。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。本功能模块旨在实现上报流程的自动化管理，并提供异常监控与向平台发起申诉的能力。 +根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将税源地为安徽运八的运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八），其他税源地不走此逻辑。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。本功能模块旨在实现上报流程的自动化管理，并提供异常监控与向平台发起申诉的能力。 二、功能说明 2.1 上报运单看板 · 功能描述 @@ -22,7 +22,7 @@ 货物名称、合同金额、最新核验时间、操作（申诉/进度/详情） 2.2 第一次上报（装货完成） 功能描述 -第一次上报在运单装货完成后自动触发，上报数据包含运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息、保险信息等。 +第一次上报在运单装货完成后自动触发（仅上传货源税源地为安徽运八的运单，其他税源地无需上传），上报数据包含运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息、保险信息等。 特殊说明 • 上报完成后，若安徽运八平台核验通过，系统会自动调用“修改第一次上报部分字段”接口，更新装货后可能发生变化的字段（如实际里程），无需人工干预。 • 若上报失败，系统需要自动重试（最多3次），若仍失败则通过系统站内信或者其他方式通知运营人员。 @@ -159,5 +159,6 @@ ETC发票上传用于上报车辆通行高速公路的ETC发票信息，作为 详细数据接口字段请查阅上报接口： https://www.showdoc.com.cn/2210641821476236/9919735893682511 密码：szjj@2023 -原型： -接口文档： +原型文件路径： +"E:\WeChat\xwechat_files\wxid_2n9ko0aq1th822_44c3\msg\file\2026-07\anhuibaba_index.html" +接口文档路径："E:\Downloads\网货企业端接口文档（最新）.pdf" diff --git a/output/versions/安徽运八需求/v2/snapshot_meta.json b/output/versions/安徽运八需求/v3/snapshot_meta.json similarity index 92% rename from output/versions/安徽运八需求/v2/snapshot_meta.json rename to output/versions/安徽运八需求/v3/snapshot_meta.json index 0f46151..dacfef0 100644 --- a/output/versions/安徽运八需求/v2/snapshot_meta.json +++ b/output/versions/安徽运八需求/v3/snapshot_meta.json @@ -1,6 +1,6 @@ { "base_name": "安徽运八需求", - "version": "v2", + "version": "v3", "snapshot_type": "full_pipeline", "summary": [ "manifest", diff --git a/output/versions/安徽运八需求/v3/安徽运八需求.json b/output/versions/安徽运八需求/v3/安徽运八需求.json new file mode 100644 index 0000000..2d284d4 --- /dev/null +++ b/output/versions/安徽运八需求/v3/安徽运八需求.json @@ -0,0 +1,348 @@ +{ + "_meta": { + "base_name": "安徽运八需求", + "merged_zones": [ + "prepare", + "analyze", + "design", + "execute", + "review", + "monitor" + ], + "merged_at": "2026-07-13T07:31:34.880608+00:00", + "updated_at": "2026-07-13T07:31:34.881584+00:00" + }, + "prepare": { + "base_name": "安徽运八需求", + "requirement_source_file": "E:\\test\\QaAutomationHub\\source_docs\\requirements_raw\\安徽运八需求.docx", + "requirement_input_type": "docx", + "normalized_requirement_file": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求\\requirement.md", + "normalized_dir": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求", + "technical_solution_files": [], + "normalized_technical_solution_files": [], + "project_profile_file": "E:\\test\\QaAutomationHub\\knowledge_base\\00_project\\project_profile.md", + "document_confidence": { + "requirement": 0.9, + "issues": [] + }, + "activated_knowledge": { + "terminology": { + "permanent": [ + "E:\\test\\QaAutomationHub\\knowledge_base\\01_standards\\terminology.md" + ], + "optional": [] + }, + "semantic_matches": [ + { + "path": "E:\\test\\QaAutomationHub\\knowledge_base\\03_best_practices\\data_reporting_cases.md", + "score": 0.1155, + "category": "best_practice" + }, + { + "path": "E:\\test\\QaAutomationHub\\knowledge_base\\02_history\\common_missed_scenes.md", + "score": 0.0916, + "category": "history" + } + ] + }, + "knowledge_gaps": [], + "agent_notes": { + "document-parser": "解析完成，置信度 90%", + "knowledge-activator": "激活 1 常驻 + 0 可选术语" + }, + "_meta": { + "zone": "prepare", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.805524+00:00", + "status": "completed" + } + }, + "base_name": "安徽运八需求", + "requirement_source_file": "E:\\test\\QaAutomationHub\\source_docs\\requirements_raw\\安徽运八需求.docx", + "requirement_input_type": "docx", + "normalized_requirement_file": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求\\requirement.md", + "normalized_dir": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求", + "technical_solution_files": [], + "normalized_technical_solution_files": [], + "project_profile_file": "E:\\test\\QaAutomationHub\\knowledge_base\\00_project\\project_profile.md", + "document_confidence": { + "requirement": 0.9, + "issues": [] + }, + "activated_knowledge": { + "terminology": { + "permanent": [ + "E:\\test\\QaAutomationHub\\knowledge_base\\01_standards\\terminology.md" + ], + "optional": [] + }, + "semantic_matches": [ + { + "path": "E:\\test\\QaAutomationHub\\knowledge_base\\03_best_practices\\data_reporting_cases.md", + "score": 0.1155, + "category": "best_practice" + }, + { + "path": "E:\\test\\QaAutomationHub\\knowledge_base\\02_history\\common_missed_scenes.md", + "score": 0.0916, + "category": "history" + } + ] + }, + "knowledge_gaps": [], + "agent_notes": { + "execution-analyst": "等待测试结果输入", + "knowledge-curator": "等待执行分析结果" + }, + "analyze": { + "base_name": "安徽运八需求", + "analysis_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_分析.md", + "relation_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_关联与冲突.md", + "risk_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_风险评估.md", + "related_requirements": [], + "conflict_candidates_count": 0, + "conflict_summary": {}, + "risk_matrix": { + "risks": [ + { + "id": "RISK-FINANCIAL", + "category": "资损", + "keywords_matched": [ + "金额", + "支付" + ], + "likelihood": 2, + "impact": 5, + "score": 10, + "level": "P1", + "conflict_amplified": false + }, + { + "id": "RISK-AVAILABILITY", + "category": "可用性", + "keywords_matched": [ + "超时", + "重试" + ], + "likelihood": 2, + "impact": 4, + "score": 8, + "level": "P2", + "conflict_amplified": false + } + ], + "total": 2, + "p0_count": 0, + "p1_count": 1 + }, + "confirmation_gate": { + "required": false, + "reasons": [], + "pending_markers_count": 0, + "decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md", + "decision_status": "not_required", + "decision_status_label": "已确认", + "allow_export_before_confirmation": true, + "candidate_decision_files": [ + "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" + ], + "suggested_decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" + }, + "agent_notes": { + "requirement-analyzer": "识别 0 个关联需求", + "conflict-detector": "检测到 0 个冲突候选", + "risk-assessor": "识别 2 个风险项" + }, + "_meta": { + "zone": "analyze", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.855607+00:00", + "status": "completed" + } + }, + "analysis_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_分析.md", + "relation_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_关联与冲突.md", + "risk_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_风险评估.md", + "related_requirements": [], + "conflict_candidates_count": 0, + "conflict_summary": {}, + "risk_matrix": { + "risks": [ + { + "id": "RISK-FINANCIAL", + "category": "资损", + "keywords_matched": [ + "金额", + "支付" + ], + "likelihood": 2, + "impact": 5, + "score": 10, + "level": "P1", + "conflict_amplified": false + }, + { + "id": "RISK-AVAILABILITY", + "category": "可用性", + "keywords_matched": [ + "超时", + "重试" + ], + "likelihood": 2, + "impact": 4, + "score": 8, + "level": "P2", + "conflict_amplified": false + } + ], + "total": 2, + "p0_count": 0, + "p1_count": 1 + }, + "confirmation_gate": { + "required": false, + "reasons": [], + "pending_markers_count": 0, + "decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md", + "decision_status": "not_required", + "decision_status_label": "已确认", + "allow_export_before_confirmation": true, + "candidate_decision_files": [ + "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" + ], + "suggested_decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" + }, + "design": { + "base_name": "安徽运八需求", + "strategy_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试策略.md", + "test_points_file": "E:\\test\\QaAutomationHub\\output\\test_points\\安徽运八需求_测试点.md", + "test_cases_file": "E:\\test\\QaAutomationHub\\output\\test_cases\\安徽运八需求_测试用例.md", + "test_data_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试数据.md", + "p0_required_coverage": "N/A", + "agent_notes": { + "test-strategist": "策略已生成，0 个 P0 风险需 100% 覆盖", + "testpoint-designer": "待 AI Agent 生成测试点", + "case-designer": "待 AI Agent 生成用例", + "data-builder": "测试数据模板已生成" + }, + "_meta": { + "zone": "design", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.874648+00:00", + "status": "completed" + } + }, + "strategy_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试策略.md", + "test_points_file": "E:\\test\\QaAutomationHub\\output\\test_points\\安徽运八需求_测试点.md", + "test_cases_file": "E:\\test\\QaAutomationHub\\output\\test_cases\\安徽运八需求_测试用例.md", + "test_data_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试数据.md", + "p0_required_coverage": "N/A", + "execute": { + "base_name": "安徽运八需求", + "playwright_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\playwright_tests.py", + "appium_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\appium_tests.py", + "execution_report_file": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求_执行报告.md", + "screenshots_dir": "E:\\test\\QaAutomationHub\\output\\screenshots\\安徽运八需求", + "execution_config": { + "browsers": [ + "chromium", + "firefox", + "webkit" + ], + "mobile_platforms": [ + "android", + "ios" + ], + "screenshot_on_failure": true, + "screenshot_on_step": false + }, + "agent_notes": { + "web-executor": "Playwright 脚本已生成 → E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\playwright_tests.py", + "mobile-executor": "Appium 脚本已生成 → E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\appium_tests.py", + "result-reporter": "执行报告 → E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求_执行报告.md" + }, + "_meta": { + "zone": "execute", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.877678+00:00", + "status": "completed" + } + }, + "playwright_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\playwright_tests.py", + "appium_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\appium_tests.py", + "execution_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_执行分析.md", + "screenshots_dir": "E:\\test\\QaAutomationHub\\output\\screenshots\\安徽运八需求", + "execution_config": { + "browsers": [ + "chromium", + "firefox", + "webkit" + ], + "mobile_platforms": [ + "android", + "ios" + ], + "screenshot_on_failure": true, + "screenshot_on_step": false + }, + "review": { + "base_name": "安徽运八需求", + "review_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_评审报告.md", + "coverage_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_覆盖率审计.md", + "verdict_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_质量裁决.md", + "quality_verdict": { + "verdict": "BLOCKED", + "reason": "测试用例文件尚未生成或为空", + "case_count": 0, + "min_coverage_required": 0.95, + "max_blockers_allowed": 0 + }, + "agent_notes": { + "case-reviewer": "等待用例生成", + "coverage-auditor": "覆盖率审计待 AI Agent 执行", + "quality-gatekeeper": "裁决: BLOCKED" + }, + "_meta": { + "zone": "review", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.879631+00:00", + "status": "completed" + } + }, + "review_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_评审报告.md", + "coverage_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_覆盖率审计.md", + "verdict_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_质量裁决.md", + "quality_verdict": { + "verdict": "BLOCKED", + "reason": "测试用例文件尚未生成或为空", + "case_count": 0, + "min_coverage_required": 0.95, + "max_blockers_allowed": 0 + }, + "monitor": { + "base_name": "安徽运八需求", + "execution_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_执行分析.md", + "agent_notes": { + "execution-analyst": "等待测试结果输入", + "knowledge-curator": "等待执行分析结果" + }, + "curation_suggestions": [], + "_meta": { + "zone": "monitor", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.880608+00:00", + "status": "completed" + } + }, + "curation_suggestions": [], + "current_excel_file": "E:\\test\\QaAutomationHub\\output\\excel_reports\\安徽运八需求_测试用例.xlsx", + "versioning_scheme": { + "current_files": "固定文件名，始终表示当前最新版", + "snapshot_rule": "仅在 export 成功且产物内容发生变化时递增版本", + "snapshot_dir_pattern": "output/versions/{BASE_NAME}/vN/" + }, + "latest_snapshot_version": "v2", + "latest_snapshot_dir": "E:\\test\\QaAutomationHub\\output\\versions\\安徽运八需求\\v2", + "latest_snapshot_type": "full_pipeline", + "maintained_requirement_file": "E:\\test\\QaAutomationHub\\requirements\\安徽运八需求.md" +} diff --git a/output/versions/安徽运八需求/v2/安徽运八需求_关联与冲突.md b/output/versions/安徽运八需求/v3/安徽运八需求_关联与冲突.md similarity index 72% rename from output/versions/安徽运八需求/v2/安徽运八需求_关联与冲突.md rename to output/versions/安徽运八需求/v3/安徽运八需求_关联与冲突.md index 0290bb6..98f0a05 100644 --- a/output/versions/安徽运八需求/v2/安徽运八需求_关联与冲突.md +++ b/output/versions/安徽运八需求/v3/安徽运八需求_关联与冲突.md @@ -10,9 +10,7 @@ - 未识别到同主题技术方案文档。 ## 关联需求识别 -| 序号 | 关联需求 | 相似度 | -| :--- | :--- | :--- | -| 1 | `source_docs\requirements_raw\网货企业端接口文档（最新）.pdf` | 0.0696 | +- 未识别到相似度达到阈值的历史需求文档。 ## 潜在冲突与修改建议 - 暂未识别到明显冲突条目。建议在需求评审时继续人工确认。 diff --git a/output/versions/安徽运八需求/v3/安徽运八需求_分析.md b/output/versions/安徽运八需求/v3/安徽运八需求_分析.md new file mode 100644 index 0000000..41f017d --- /dev/null +++ b/output/versions/安徽运八需求/v3/安徽运八需求_分析.md @@ -0,0 +1,165 @@ +# 安徽运八需求 结构化分析 + +> 生成时间: 2026-07-13 +> 需求文档: source_docs/requirements_raw/安徽运八需求.docx +> 项目画像: knowledge_base/00_project/project_profile.md + +## 1. 需求背景 + +根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将税源地为安徽运八的运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八），其他税源地不走此逻辑。 + +## 2. 目标 + +实现上报流程的自动化管理，并提供异常监控与向平台发起申诉的能力。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。 + +## 3. 用户角色 + +| 角色 | 职责 | +| :--- | :--- | +| 平台运营人员 | 查看看板、发起申诉、监控上报状态 | +| 系统自动 | 自动触发三阶段上报和ETC上传 | +| 财务人员 | 打款操作（触发第二次上报） | +| 安徽监管平台 | 接收上报数据、执行核验、反馈结果 | + +## 4. 功能模块 + +### 4.1 上报运单看板 +集中展示所有上报阶段运单的汇总状态，支持按条件筛选（运单号/托运单号/货源单号模糊搜索、上报阶段、核验状态、申诉状态）、查看详情和发起申诉。 + +### 4.2 第一次上报（装货完成） +运单装货完成后自动触发，仅上传货源税源地为安徽运八的运单。上报数据包含运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息、保险信息等。核验通过后自动调用"修改第一次上报部分字段"接口。 + +### 4.3 第二次上报（打款完成） +运费支付完成后自动触发，上报数据包含资金流水信息、车辆轨迹信息等。监管平台进行核验。⚠️ 根据网货企业端接口文档 V1.0.2 §4.1，核验项从需求描述的7类扩展为API定义的17项独立核验项：100=委托合同、120=承运合同、130=实时定位、140=运单时间逻辑、150=车辆资质、160=道路运输证、170=驾驶证、180=从业资格证、190=车辆重复、200=司机重复、210=车辆轨迹、220=运费收款、230=公司统一收款、240=集中支付、250=资金流水、260=发票信息、270=非通行车辆可开票。每项有独立的核验结果和申诉入口。 + +### 4.4 第三次上报（开票完成） +发票开具完成后触发，上报数据包含运单信息、发票信息、油气发票信息等。 + +### 4.5 ETC发票上传 +用于上报车辆通行高速公路的ETC发票信息，作为税务抵扣凭证。需在税务抵扣完成后进行。 + +### 4.6 异常申诉功能 +补全"异常查询 → 发起申诉 → 跟踪监管平台反馈 → 合规判断"的完整闭环。 + +### 4.7 上报日志 +记录所有上报接口的调用记录（请求/响应报文、HTTP状态码、响应时间），用于问题排查和审计。 + +## 5. 核心规则 + +### 5.1 税源地过滤 +- 仅税源地为安徽运八的运单触发上报 +- 其他税源地（如云南=28）不触发任何上报 + +### 5.2 上报阶段依赖链 +- 第一次上报是后续两次上报的基础 +- 第二次上报依赖第一次上报完成 +- 第三次上报依赖第二次上报完成 +- 后端必须做前置状态校验（非仅前端控制） + +### 5.3 自动重试机制 +- 各阶段上报失败后自动重试（最多3次） +- 3次全部失败后告警通知运营人员 +- 重试期间禁止手动触发上传 + +### 5.4 核验规则 +- 第二次上报包含17项核验（API文档§4.1定义），比需求的7类更为细化 +- 核验异常可通过申诉机制向监管平台说明情况 +- 每项核验有独立的核验结果（verificationCode/verificationName/verificationState）和申诉入口 +- 申诉由安徽监管平台复核 + +### 5.5 API接口清单（来自网货企业端接口文档 V1.0.2） + +| 接口 | URL | 方法 | 说明 | +|:---|:---|:---:|:---| +| 获取token | /sys/login | POST | JWT认证 | +| 上传申诉附件 | /appeal/uploadFile | POST | 文件上传 | +| 提交申诉运单 | /appeal/insert | POST | 发起申诉 | +| 查询异常运单信息 | /verificationSummary/page | POST | 分页查询，含abnormalDetails（17项核验明细） | +| 查询申诉进度 | /appeal/page | POST | 分页查询，含审核状态/审核人/取消/撤回 | +| 查询运单核验详情 | /verificationSummary/verificationDetail | POST | 单运单核验明细列表 | +| 查询发票合规 | /verificationSummary/cargoOwnerInvoiceInfo | POST | 判断托运人发票是否系统核验合规（需求未提及！） | +| 运单里程核验查询 | /verificationSummary/mileageVerificationInfo | POST | 批量查询运单里程核验状态 | +| 运单里程申诉 | /mileageAppeal/insert | POST | 提交里程申诉（需求未提及的新功能！） | + +### 5.6 申诉状态枚举三版本对照 + +| 需求文档 | HTML原型 | API文档(§4.4) | API Code | +|:---|:---|:---|:---:| +| 未申诉 | 未申诉 | 未申诉 | 100 | +| 申诉中 | 待省平台反馈 | — | — | +| — | 反馈处理中 | — | — | +| 申诉通过 | 申诉通过 | 审核通过 | 110 | +| 申诉驳回 | 申诉驳回 | 审核不通过 | 120 | +| — | — | 已取消 | 130 | + +> ⚠️ **待确认**: +> - 需求"申诉中"被原型拆分为"待省平台反馈"+"反馈处理中"两个状态——哪个是最终版本？ +> - API有"已取消"状态(130)但需求和原型均未体现——是否支持申诉取消？ +> - API无"申诉中"状态，仅有"未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130)"——申诉流程中如何进行状态管理？ +> - 看板筛选下拉值以哪个为准？ + +## 6. 数据字段 + +### 6.1 第一次上报核心字段 +- waybillInfo（建单信息）: 13字段（必选） +- consignorInfo（托运人信息）: 7字段（必选） +- consigneeInfo（收货方信息）: 5字段（必选） +- driverInfo（司机信息）: 13字段（必选） +- carInfo（接单车辆信息）: 19字段（必选） +- goodsInfos（货物信息）: 4字段/条（必选，可多条） +- insuranceInformation（保险信息）: 2字段（可选） + +### 6.2 第二次上报新增字段 +- 资金流水信息: 10字段（必选） +- 车辆轨迹信息: 6字段/点（必选，2~2000个点） + +### 6.3 第三次上报核心字段 +- 发票信息: 17字段（必选） +- 油气发票信息（可选，可多条） + +### 6.4 ETC发票核心字段 +- ETC发票信息: 18字段/张 + +## 7. 状态流转 + +### 7.1 上报状态 +上传中(蓝色) → 已上传(绿色) / 上传失败(红色) / 异常(橙色) + +### 7.2 申诉状态 +未申诉 → 申诉中 → 申诉通过 / 申诉驳回 → 重新申诉 + +## 8. 歧义标注与待确认项 + +### 8.1 核验项定义差异（P0 阻断） +> ⚠️ 待确认1: 需求文档将核验项描述为7大类，但API文档§4.1定义了17项独立核验项。测试点已按API文档17项逐项覆盖（TP-C-006~TP-C-019 保留原7类 + TP-C-026~TP-C-049 补充12项），需与产品和开发确认最终核验粒度。 + +### 8.2 申诉状态枚举三版本不一致（P1） +> ⚠️ 待确认2: 申诉状态在需求（未申诉/申诉中/申诉通过/申诉驳回）、原型（未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回）、API（未申诉100/审核通过110/审核不通过120/已取消130）三处不一致，需确认最终版本。详见 §5.6 对照表。 + +### 8.3 第三次上报列表字段差异（P1） +> ⚠️ 待确认3: 原型列表比需求多4个字段（税率、销售方名称、受票方名称、油气票张数），共15列（含checkbox），需确认最终字段列表。 + +### 8.4 看板申诉状态下拉值差异（P1） +> ⚠️ 待确认4: 原型看板申诉状态下拉值为"未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回"，与需求"未申诉/申诉中/申诉通过/申诉驳回"不一致，需确认最终版本。 + +### 8.5 原型详情弹窗字段数量差异（P1） +> ⚠️ 待确认5: 原型详情弹窗各分组字段数量与需求/接口文档不一致（原型大幅简化），需确认以哪个为准。 + +### 8.6 原型缺失车辆轨迹信息（P1） +> ⚠️ 待确认6: 原型第二次上报详情弹窗中车辆轨迹信息缺失——是原型bug还是实际不展示？ + +### 8.7 技术细节待确认 +> ⚠️ 待确认7: 自动重试的具体间隔时间（需求中未明确），当前假设为5s/15s/30s，需与技术方案确认。 +> ⚠️ 待确认8: ETC税额边界值（0.01元→税额=0.00）的四舍五入规则需与财务确认。 +> ⚠️ 待确认9: 申诉超时告警阈值（需求中未明确），当前假设为7个工作日，需与产品确认。 +> ⚠️ 待确认10: 安徽运八与现有云南运八上报逻辑是否存在字段/接口冲突，需人工确认。 +> ⚠️ 待确认11: 上报接口文档密码保护（szjj@2023），字段定义以接口文档为准，需确认需求与接口文档一致性。 +> ⚠️ 待确认12: 里程申诉接口 /mileageAppeal/insert 为需求未提及的新功能，需确认是否纳入本期范围。 +> ⚠️ 待确认13: ETC发票详情含"不含税金额"字段是否需要在测试用例中体现。 + +## 9. 项目差异化约束 + +- 省份代码: 安徽=34（非云南=28） +- 该需求为新增模块，与现有云南上报逻辑隔离 +- 测试环境管理端: https://ybxcx.ynyun8.com:8000/admin +- 支付方式: arpa_2（云企付二期） diff --git a/output/versions/安徽运八需求/v3/安徽运八需求_测试点.md b/output/versions/安徽运八需求/v3/安徽运八需求_测试点.md new file mode 100644 index 0000000..5eeb38b --- /dev/null +++ b/output/versions/安徽运八需求/v3/安徽运八需求_测试点.md @@ -0,0 +1,1152 @@ +# 安徽运八需求 测试点 + +> 生成时间: 2026-07-13 +> 需求文档: output/normalized_inputs/安徽运八需求/requirement.md +> 关联分析: 风险评估报告 / 测试策略 / 关联与冲突 + +## 测试点概览 + +- 总测试点数: 132 +- P0: 33 / P1: 64 / P2: 29 / P3: 6 +- 模块分布: A(看板)=14, B(第一次上报)=20, C(第二次上报)=49, D(第三次上报)=12, E(ETC)=9, F(申诉)=13, G(日志)=9, X(跨模块)=6 +- 来源分布: [需求] 66, [历史缺陷] 14, [风险矩阵] 8, [漏测清单] 52, [项目画像] 16, [最佳实践] 7, [技术方案] 28 + +> 注: 一个测试点可同时归属多个来源，因此来源分布合计数 > 总测试点数。 + +--- + +## 模块A: 上报运单看板 (14个测试点) + +### TP-A-001: 看板模糊搜索 — 运单号/托运单号/货源单号 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证看板支持按运单号、托运单号、货源单号进行模糊搜索，输入部分字符即可匹配相关运单。 +- 关键验证点: 输入完整单号可精确匹配；输入部分字符可模糊匹配；输入不存在的单号显示空结果提示；三种单号输入框均支持模糊搜索。 + +### TP-A-002: 看板按上报阶段筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证看板支持按"全部/第一次上报/第二次上报/第三次上报"筛选，切换阶段后列表数据正确过滤。 +- 关键验证点: 默认"全部"显示所有阶段运单；选择"第一次上报"仅显示对应阶段运单；切换阶段后列表即时刷新；各阶段数据条数与实际一致。 + +### TP-A-003: 看板按核验状态筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证看板支持按"全部/异常/通过"筛选核验状态，确保状态拆分独立验证。 +- 关键验证点: "全部"显示所有核验状态运单；"异常"仅显示核验不通过的运单；"通过"仅显示核验通过的运单；列表中核验状态字段与筛选条件一致。 + +### TP-A-004: 看板按申诉状态筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证看板支持按"全部/未申诉/申诉中/申诉通过/申诉驳回"筛选申诉状态。⚠️ 待确认: 原型看板申诉状态下拉值为"未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回"，与需求不一致，需确认最终版本。 +- 关键验证点: 四种申诉状态独立筛选，数据精确匹配；切换申诉状态后核验状态筛选联动正确；申诉状态标签展示与筛选值一致。 + +### TP-A-005: 看板组合筛选 — 多条件叠加 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [需求][漏测清单] +- 描述: 验证看板支持上报阶段 + 核验状态 + 申诉状态 + 模糊搜索同时组合筛选。 +- 关键验证点: 选择"第二次上报+异常+申诉中"组合后精确过滤；组合条件为空结果时友好提示；组合条件切换不丢失已输入的单号搜索关键字。 + +### TP-A-006: 看板导出功能 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][项目画像] +- 描述: 验证看板支持将当前筛选结果导出为 Excel 文件，大数据量导出正常。 +- 关键验证点: 导出文件包含全部列表字段；导出数据与当前筛选条件一致；大数据量（≥2000条）导出不超时、不OOM；导出的 Excel 文件可正常打开和解析。 + +### TP-A-007: 看板重置查询条件 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证点击"重置"按钮后，所有查询条件恢复默认值，列表刷新为初始全部数据。 +- 关键验证点: 模糊搜索输入框清空；下拉筛选恢复"全部"；列表数据恢复为默认全部运单；重置后分页回到第1页。 + +### TP-A-008: 看板列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证看板列表展示的14个字段完整且顺序与需求一致：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、申诉状态、异常项、货物名称、合同金额、最新核验时间、操作。 +- 关键验证点: 每个字段均有数据且格式正确；异常项为空时合理展示（如"-"或留空）；合同金额保留2位小数；最新核验时间为合理时间格式。 + +### TP-A-009: 看板状态标签颜色映射 +- 优先级: P2 +- 类型: UI测试 +- 覆盖维度: 数据校验 +- 来源: [漏测清单] +- 描述: 验证上报阶段不同状态对应的标签颜色是否正确（蓝色=上传中、绿色=已上传/通过、红色=上传失败/驳回、橙色=异常）。 +- 关键验证点: 每一种状态颜色独立验证；蓝色/绿色/红色/橙色与实际需求一致；申诉状态标签（申诉中/申诉通过/申诉驳回）颜色区分清晰。 + +### TP-A-010: 看板操作按钮 — 申诉/进度/详情 入口 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证看板操作列中"申诉""进度""详情"按钮根据运单当前状态正确显示/隐藏，点击后正确跳转。 +- 关键验证点: 仅异常运单显示"申诉"按钮；所有运单显示"详情"按钮；"进度"按钮展示上报阶段进度；点击后路由跳转正确，携带正确的运单ID参数。 + +### TP-A-011: 看板详情弹窗 — 分组字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证看板点击"详情"后弹窗内容完整，按子对象分组展示，各分组字段不缺失。 +- 关键验证点: 建单信息分组13字段完整；托运人信息7字段完整；收货方信息5字段完整；司机信息13字段完整；车辆信息19字段完整；货物信息支持多条展示；可选字段为空时展示合理。 + +### TP-A-012: 看板空数据状态 +- 优先级: P3 +- 类型: UI测试 +- 覆盖维度: 边界条件 +- 来源: [漏测清单] +- 描述: 验证看板在无运单数据时的空状态展示（如新部署环境或筛选无结果）。 +- 关键验证点: 空状态有友好的占位提示图文；筛选无结果时明确提示"未找到匹配数据"；空状态不出现控制台报错或页面崩溃。 + +### TP-A-013: 看板分页和默认排序 +- 优先级: P3 +- 类型: UI测试 +- 覆盖维度: 边界条件 +- 来源: [漏测清单] +- 描述: 验证看板列表分页功能正常（翻页、每页条数切换），默认按最新核验时间倒序排列。 +- 关键验证点: 翻页后数据不重复不遗漏；切换每页条数后分页重新计算；数据更新后排序即时反映；总条数与数据库一致。 + +### TP-A-014: 看板角色权限控制 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 权限控制 +- 来源: [项目画像] +- 描述: 验证不同角色（运营/财务/客服/车队长/司机）对看板的访问权限和数据可见范围。 +- 关键验证点: 运营人员可见全部运单；财务人员可见打款相关字段；客服人员仅可见其负责范围的运单；车队长和司机不可见平台端看板；越权访问被正确拦截。 + +--- + +## 模块B: 第一次上报-装货完成 (19个测试点) + +### TP-B-001: 装货完成后自动触发第一次上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证运单装货完成后，系统自动触发第一次上报，上报数据包含全部必选子对象（运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息）。 +- 关键验证点: 装货完成事件触发上报；上报请求包含全部7个子对象；各子对象必选字段完整；上报接口收到正确的JSON结构；上报成功后状态变为"已上传"（绿色标签）。 + +### TP-B-002: 仅安徽税源地运单触发上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][项目画像] +- 描述: 验证货源税源地为非安徽的运单（如云南=28）装货完成后不会触发第一次上报。 +- 关键验证点: 税源地为云南(28)的运单不触发上报；税源地为其他省份的运单不触发上报；不触发时无错误日志或告警；仅税源地为安徽(34)的运单触发上报。 + +### TP-B-003: 第一次上报数据字段格式校验 — 建单信息 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证第一次上报的建单信息(waybillInfo)13个字段的格式、类型、长度符合接口规范，可选字段（委托合同编号、运输里程）为空时正常上报。 +- 关键验证点: 必选字段缺失时上报拒绝并明确提示；统一社会信用代码格式校验（18位）；业务类型代码/运输组货方式代码为有效枚举值；运输里程为合理数值范围；经纬度为合法浮点数范围。 + +### TP-B-004: 省份代码动态获取 — 安徽=34 非云南=28 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 数据校验 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-04：验证司机信息中的省份代码(provinceCode)根据上报目标省份动态读取配置，安徽省使用代码"34"而非项目默认值云南省代码"28"。 +- 关键验证点: 安徽运八上报的省份代码为"34"；不同省份配置隔离，云南=28、安徽=34 各自独立；修改省份配置后无需重启服务即可生效；数据库/Redis中无硬编码省份代码；装货地行政区划代码前2位=34（安徽省代码）。 + +### TP-B-005: 后端校验 — 第一次上报是第二/三次上报的前置条件 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-01：验证第一次上报失败后，后端接口层面拒绝第二次和第三次上报请求，返回明确错误码"前置上报未完成"。前端+后端双重拦截。 +- 关键验证点: 第一次上报失败时调用第二次上报接口返回错误；错误码明确标识"前置上报未完成"；后端通过查询运单上报状态表做校验，非前端布尔值；第一次上报重试3次全失败后第二次上报仍被拒绝；第三次上报同理，第二次上报失败时被拒绝。 + +### TP-B-006: 第一次上报成功后自动调用"修改字段"接口 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证监管平台核验通过后，系统自动调用"修改第一次上报部分字段"接口，更新装货后可能变化的字段（如实际里程）。 +- 关键验证点: 核验通过后自动触发修改接口；修改的字段为装货后变化字段（实际里程等）；修改成功后状态仍为"已上传"；修改接口调用记录出现在上报日志中；若修改失败有重试机制和告警。 + +### TP-B-007: 第一次上报自动重试 — 最多3次 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [需求] +- 描述: 验证第一次上报失败后系统自动重试，最多3次，重试间隔递增。 +- 关键验证点: 第1次失败后自动触发第2次重试；重试间隔合理递增（如5s/15s/30s）；第3次仍失败后标记为"上传失败"（红色标签）并停止重试；每次重试均记录到上报日志；重试次数不超过3次。 + +### TP-B-008: 第一次上报全部重试失败后通知运营人员 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证第一次上报3次自动重试全部失败后，系统通过站内信或其他方式通知运营人员。 +- 关键验证点: 3次重试失败后立即触发通知；通知内容包含运单号、失败原因、失败时间；站内信有明确的"上报失败"标记；运营人员可在通知中直接跳转到对应运单详情页。 + +### TP-B-009: 第一次上报手工上传 — 上传失败后手动触发 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证运单上报状态为"上传失败"（红色标签）时，运营人员可点击"手动上传"按钮重新发起上报。 +- 关键验证点: 仅"上传失败"状态显示"手动上传"按钮；点击后发起新的上报请求；手动上传成功后状态变为"已上传"（绿色）；手动上传同样记录到上报日志。 + +### TP-B-010: 第一次上报状态标签颜色校验 +- 优先级: P2 +- 类型: UI测试 +- 覆盖维度: 数据校验 +- 来源: [漏测清单] +- 描述: 验证四种上报状态对应的标签颜色：上传中=蓝色、已上传=绿色、上传失败=红色、异常=橙色。 +- 关键验证点: 每种状态颜色独立验证，不与需求描述偏离；上传中状态显示蓝色标签和加载动画；状态切换时标签颜色即时更新；颜色在亮色/暗色主题下均可辨识。 + +### TP-B-011: 第一次上报详情弹窗 — 建单信息字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验收详情弹窗中"建单信息"分组的13个字段全部展示，数据取值来源正确。 +- 关键验证点: 上游企业委托运输单号、本运单单号、托运人建单时间、网络货运经营者名称、统一社会信用代码、道路运输经营许可证编号、业务类型代码、运输组货方式代码、司机接单时间、司机起运时间、承运合同编号（必选）共11字段有值；委托合同编号和运输里程为可选字段，为空时合理展示。 + +### TP-B-012: 第一次上报详情弹窗 — 托运人/收货方/司机/车辆/货物/保险子对象字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证详情弹窗中各子对象字段完整且按分组展示：托运人信息7字段、收货方信息5字段、司机信息13字段、车辆信息19字段、货物信息4字段（可多条）、保险信息2字段（可选）。 +- 关键验证点: 托运人统一社会信用代码格式正确；收货方身份证号脱敏展示（如适用）；司机从业资格证有效期起止日期格式正确；车辆VIN码(17位)正确显示；货物支持多条记录展开；保险单号为可选字段，无保险时合理展示。 + +### TP-B-013: 第一次上报详情弹窗 — 异常信息展示 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证详情弹窗中"异常信息"分组包含核验状态、异常原因、异常时间、处理状态4个字段。 +- 关键验证点: 核验通过时异常原因为空；核验异常时异常原因描述清晰可理解；异常时间为实际核验时间；处理状态与申诉模块数据联动。 + +### TP-B-014: 第一次上报幂等性 — 防止重复上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-02：验证同一运单同一上报阶段在短时间内不能重复上报。自动重试期间手动触发上传时，系统检测到上报进行中并拒绝重复提交。 +- 关键验证点: 自动重试进行中点击"手动上传"返回"上报处理中"提示并拒绝；同一运单同一阶段1分钟内只能有1条成功上报记录；使用分布式锁或幂等键控制并发；快速连续点击"手动上传"按钮仅发起1次请求（前端防抖）；后端数据库层面唯一约束防重。 + +### TP-B-015: 第一次上报接口超时处理 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [漏测清单][风险矩阵] +- 描述: 验证第一次上报接口调用超时后的处理逻辑（超时归类为上报失败，触发重试）。 +- 关键验证点: 监管平台接口超时(>30s)后转为"上传失败"状态；超时状态下触发自动重试；超时不导致数据不一致或重复写入；超时时有 Loading 状态提示；前端页面超时后有友好提示。 + +### TP-B-016: 第一次上报弱网环境处理 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [漏测清单] +- 描述: 验证在弱网环境（高延迟、高丢包率）下，第一次上报的重试机制正常工作。 +- 关键验证点: 弱网下请求发送成功但响应延迟时不会立即判定失败；超时阈值合理（建议30s）；弱网恢复后重试成功则状态正常流转；断网时上报请求发送失败的提示友好。 + +### TP-B-017: 第一次上报并发触发 — 多运单同时装货完成 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 +- 来源: [项目画像][最佳实践] +- 描述: 验证多个运单同时装货完成时，第一次上报并发处理，各运单上报互不干扰。 +- 关键验证点: 10个运单同时装货完成，各自独立触发上报；并发上报不产生数据库死锁；各运单上报记录正确隔离；并发上报后上报日志完整记录每个运单的请求。 + +### TP-B-018: 第一次上报可选字段空值处理 +- 优先级: P3 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [漏测清单] +- 描述: 验证各子对象中的可选字段（委托合同编号、运输里程、挂车牌照号、行驶证档案编号、道路运输证有效期起/至、保险单号、保险公司名称）为空时，上报接口正常处理。 +- 关键验证点: 可选字段为空时上报不报错；JSON 中可选字段不传或传 null 均可正常处理；详情弹窗中可选字段为空时显示"-"或"N/A"等占位符，不显示"null"或"undefined"。 + +### TP-B-019: 第一次上报货物信息多条记录 +- 优先级: P3 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [需求][漏测清单] +- 描述: 验证当运单包含多种货物时，货物信息(goodsInfos)数组支持多条记录上报，每条包含货物名称、货物类型代码、货物量、计量单位。 +- 关键验证点: 支持1条货物记录；支持多条（如5条）货物记录；每条货物信息独立完整；详情弹窗支持展开/折叠多条货物记录；货物类型代码与数据字典一致。 + +### TP-B-020: 第一次上报列表字段完整性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证第一次上报列表展示的字段完整且与需求一致，包括货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、业务类型、货物名称、装货地址、卸货地址、运输里程、合同编号、上报状态、操作共14个字段。 +- 关键验证点: 列表表头与需求一致性；14个字段均正确展示且顺序符合设计；业务类型与数据字典一致；装货地址和卸货地址完整展示；运输里程带单位（km）；上报状态标签颜色映射正确（上传中=蓝色/已上传=绿色/上传失败=红色/异常=橙色）。 + +--- + +## 模块C: 第二次上报-打款完成 (24个测试点) + +### TP-C-001: 打款完成后自动触发第二次上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证运单运费支付（财务打款）完成后，系统自动触发第二次上报，上报数据包含资金流水信息和车辆轨迹信息。 +- 关键验证点: 财务打款完成回调触发上报；上报请求包含运单信息+资金流水+车辆轨迹；上报成功后状态更新；第二次上报仅对已完成第一次上报的运单触发。 + +### TP-C-002: 第二次上报资金流水数据来源于支付流水表 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 数据校验 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-03：验证第二次上报的资金流水数据（支付金额、支付方式、支付时间、流水号等）从支付流水表实时读取，而非使用运单缓存中的合同金额。 +- 关键验证点: 上报数据中的金额与支付流水表实际打款金额完全一致；非从运单表或Redis缓存读取金额；数据库查询SQL日志可确认数据来源为支付流水表；金额字段精确到分（2位小数），无精度丢失。 + +### TP-C-003: 财务修改打款金额后第二次上报使用最新金额 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 数据校验 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-03：验证财务在账户管理模块修改打款金额后，第二次上报感知数据变更并使用修改后的最新金额。 +- 关键验证点: 合同金额10000元 → 财务调账修改为9500元 → 第二次上报金额为9500元；财务修改与上报触发有时间差时仍使用最新值；上报日志中可溯源金额来源；反例：不使用装货完成时缓存的合同金额。 + +### TP-C-004: 第二次上报列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证第二次上报列表展示的14个字段完整：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、承运运费、总金额、付款方式、付款时间、收款人、收款账号、收款账号类型、核验状态、异常项、上报状态、操作。 +- 关键验证点: 承运运费和总金额保留2位小数；付款时间为实际财务打款时间；操作列根据上报状态显示"上报"或"详情"按钮。 + +### TP-C-005: 收款账号类型标签颜色 — 个人账户(蓝色)/对公账户(绿色) +- 优先级: P2 +- 类型: UI测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证列表中收款账号类型标签颜色：个人账户显示蓝色标签，对公账户显示绿色标签。 +- 关键验证点: 司机个人银行卡(个人账户)=蓝色；企业银行账号(对公账户)=绿色；颜色与需求定义严格一致；列表中每条记录标签颜色根据实际账号类型渲染，不混淆。 + +### TP-C-006: 运单重复核验 — 通过场景 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证同一运单未重复上报时，监管平台"运单重复核验"返回通过。 +- 关键验证点: 首次上报的运单核验通过；不同运单号各自独立上报通过；核验状态标记为"通过"；无"运单重复"异常项出现。 + +### TP-C-007: 运单重复核验 — 异常场景（重复上报） +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证同一运单第二次上报时，监管平台"运单重复核验"检测到重复并返回异常。 +- 关键验证点: 重复上报后核验状态变为"异常"；异常项明确标注"运单重复核验"；异常原因清晰可读；异常运单可触发申诉流程。 + +### TP-C-008: 车辆资质核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证车辆道路运输证在有效期内时，监管平台"车辆资质核验"返回通过。 +- 关键验证点: 道路运输证有效期起止日期在有效期内；道路运输证号格式有效；车辆审核状态为"通过"的运单核验通过。 + +### TP-C-009: 车辆资质核验 — 异常场景（证件过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证车辆道路运输证已过期或缺失时，监管平台"车辆资质核验"返回异常。 +- 关键验证点: 道路运输证有效期的截止日期 < 当前日期时核验异常；无道路运输证号的车辆核验异常；异常项明确标注"车辆资质核验"；异常后可申诉。 + +### TP-C-010: 司机资质核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证司机从业资格证在有效期内时，监管平台"司机资质核验"返回通过。 +- 关键验证点: 从业资格证有效期起止日期在有效期内；从业资格证号格式有效；司机审核状态为"通过"的运单核验通过。 + +### TP-C-011: 司机资质核验 — 异常场景（证件过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证司机从业资格证已过期或缺失时，监管平台"司机资质核验"返回异常。 +- 关键验证点: 从业资格证有效期至 < 当前日期时核验异常；无从业资格证号时核验异常；异常项明确标注"司机资质核验"；异常后可申诉。 + +### TP-C-012: 集中支付核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证资金流水通过网货平台集中支付时，监管平台"集中支付核验"返回通过。 +- 关键验证点: 付款方为网货平台统一账户，核验通过；支付流水记录与集中支付模式匹配；核验状态为"通过"。 + +### TP-C-013: 集中支付核验 — 异常场景（非集中支付/支付信息异常） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证资金流水未通过网货平台集中支付或支付信息异常时，监管平台"集中支付核验"返回异常。 +- 关键验证点: 付款方非平台统一账户时核验异常；集中支付流水数据不完整时核验异常；异常项明确标注"集中支付核验"；异常后可申诉。 + +### TP-C-014: 资金流水核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证资金流水单号不重复且金额匹配时，监管平台"资金流水核验"返回通过。 +- 关键验证点: 流水号唯一不重复；上报金额与支付流水表实际金额一致；核验状态为"通过"。 + +### TP-C-015: 资金流水核验 — 异常场景（流水号重复/金额不匹配） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证资金流水单号重复或上报金额与支付流水不一致时，监管平台"资金流水核验"返回异常。 +- 关键验证点: 重复流水单号核验异常并提示；上报金额与支付流水金额偏差>0.01元时核验异常；异常项明确标注"资金流水核验"；异常后可申诉。 + +### TP-C-016: 合同核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证运输合同和委托合同均有效时，监管平台"合同核验"返回通过。 +- 关键验证点: 承运合同编号有效且存在于合同管理系统；委托合同编号（如有）有效；合同有效期覆盖运单执行日期；核验状态为"通过"。 + +### TP-C-017: 合同核验 — 异常场景（合同无效/过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证运输合同或委托合同无效/过期/缺失时，监管平台"合同核验"返回异常。 +- 关键验证点: 承运合同编号不存在时核验异常；合同有效期不包含运单执行日期时核验异常；异常项明确标注"合同核验"；异常后可申诉。 + +### TP-C-018: 车辆轨迹合规核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证车辆GPS轨迹真实、与运单路线匹配、轨迹点数量在2~2000范围内时，监管平台"车辆轨迹合规核验"返回通过。 +- 关键验证点: 轨迹点数量≥2且≤2000；轨迹路线与装货地→卸货地路线基本一致；轨迹时间与运单执行时间匹配；核验状态为"通过"。 + +### TP-C-019: 车辆轨迹合规核验 — 异常场景（点位不足/偏差过大/轨迹缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证车辆轨迹点数量不足(<2)、偏差过大、或轨迹数据缺失时，监管平台"车辆轨迹合规核验"返回异常。 +- 关键验证点: 轨迹点数量=1或0时核验异常；轨迹路线偏离装货-卸货路线超过合理范围时核验异常；异常项明确标注"车辆轨迹合规核验"；异常后可进入"补传轨迹"流程。 + +> **⚠️ API文档扩展说明 (来自原型&接口交叉分析)**: +> 根据网货企业端接口文档 V1.0.2 §4.1 异常项ID对照表，第二次上报核验项从需求的7类扩展为API定义的17项独立核验项。以下TP-C-006~TP-C-019覆盖了需求的7类核验（运单重复/车辆资质/司机资质/集中支付/资金流水/合同/轨迹合规），但API将其中部分类别拆分为更细粒度的独立核验项。 +> +> API文档完整17项: 100=委托合同, 120=承运合同, 130=实时定位, 140=运单时间逻辑, 150=车辆资质, 160=道路运输证, 170=驾驶证, 180=从业资格证, 190=车辆重复, 200=司机重复, 210=车辆轨迹, 220=运费收款, 230=公司统一收款, 240=集中支付, 250=资金流水, 260=发票信息, 270=非通行车辆可开票 +> +> 以下 TP-C-026~TP-C-049 为补充的12项独立核验项（每项 PASS + EXCEPTION），来源标注 [技术方案]。 + +### TP-C-025: 里程申诉功能 — 提交里程申诉 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证运单里程数据异常时，可通过 POST /mileageAppeal/insert 接口提交里程申诉，携带运单号(freightSheetNumber)、申诉内容(content)、投诉编号(complaintNumber)、申诉里程(mileage)参数。 +- 关键验证点: 里程申诉接口正常调用成功返回；必选参数齐全（运单号/申诉内容/投诉编号/申诉里程）；申诉提交后可在申诉记录中查看；里程申诉与异常申诉独立管理；缺少必选参数时接口返回明确错误提示。 + +### TP-C-026: 委托合同核验(100) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证委托合同编号有效且存在于合同管理系统、有效期覆盖运单执行日期时，监管平台"委托合同核验"返回通过。 +- 关键验证点: 委托合同编号有效且存在于系统；委托合同有效期覆盖运单执行日期；核验状态为"通过"；无"委托合同核验"异常项出现。 + +### TP-C-027: 委托合同核验(100) — 异常场景（合同无效/过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证委托合同编号不存在、无效或有效期不覆盖运单执行日期时，监管平台"委托合同核验"返回异常。 +- 关键验证点: 委托合同编号不存在时核验异常；合同有效期不覆盖运单执行日期时核验异常；委托合同为空时核验异常；异常项明确标注"委托合同核验"（代码100）；异常后可申诉。 + +### TP-C-028: 承运合同核验(120) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证承运合同编号有效且存在于合同管理系统、有效期覆盖运单执行日期时，监管平台"承运合同核验"返回通过。 +- 关键验证点: 承运合同编号有效且存在于系统；承运合同有效期覆盖运单执行日期；核验状态为"通过"；无"承运合同核验"异常项出现。 + +### TP-C-029: 承运合同核验(120) — 异常场景（合同无效/过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证承运合同编号不存在、无效或有效期不覆盖运单执行日期时，监管平台"承运合同核验"返回异常。 +- 关键验证点: 承运合同编号不存在时核验异常；合同有效期不覆盖运单执行日期时核验异常；承运合同为空时核验异常；异常项明确标注"承运合同核验"（代码120）；异常后可申诉。 + +### TP-C-030: 实时定位核验(130) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证车辆在运单执行期间有完整的实时定位数据（GPS轨迹覆盖整个运输过程）时，监管平台"实时定位核验"返回通过。 +- 关键验证点: 运单执行期间车辆实时定位数据完整；定位时间覆盖运单起运至送达时间范围；核验状态为"通过"；无"实时定位核验"异常项出现。 + +### TP-C-031: 实时定位核验(130) — 异常场景（定位数据缺失/不完整） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证车辆在运单执行期间缺少实时定位数据或定位数据不完整时，监管平台"实时定位核验"返回异常。 +- 关键验证点: 运输过程中定位数据长时间中断时核验异常；无任何实时定位数据时核验异常；定位数据时间范围未覆盖运单执行时间时核验异常；异常项明确标注"实时定位核验"（代码130）；异常后可申诉或补传定位数据。 + +### TP-C-032: 运单时间逻辑核验(140) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证运单各时间节点逻辑合理（建单时间 < 接单时间 < 起运时间 < 送达时间）时，监管平台"运单时间逻辑核验"返回通过。 +- 关键验证点: 建单时间早于接单时间；接单时间早于起运时间；起运时间早于送达时间；各时间节点无倒置或矛盾；核验状态为"通过"。 + +### TP-C-033: 运单时间逻辑核验(140) — 异常场景（时间倒置/不合理） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证运单各时间节点存在逻辑矛盾（如送达时间早于起运时间、接单时间早于建单时间等）时，监管平台"运单时间逻辑核验"返回异常。 +- 关键验证点: 起运时间晚于送达时间时核验异常；接单时间早于建单时间时核验异常；时间字段为空时核验异常；异常项明确标注"运单时间逻辑核验"（代码140）；异常后可申诉。 + +### TP-C-034: 道路运输证核验(160) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证车辆道路运输证在有效期内且证号格式有效时，监管平台"道路运输证核验"返回通过。 +- 关键验证点: 道路运输证有效期起止日期在当前日期范围内；道路运输证号格式有效且可查询；道路运输证发证机关信息完整；核验状态为"通过"；无"道路运输证核验"异常项出现。 + +### TP-C-035: 道路运输证核验(160) — 异常场景（过期/缺失/无效） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证车辆道路运输证过期、缺失或证号格式无效时，监管平台"道路运输证核验"返回异常。 +- 关键验证点: 道路运输证有效期截止日期 < 当前日期时核验异常；道路运输证号为空或格式无效时核验异常；证号在运政系统中查询不存在时核验异常；异常项明确标注"道路运输证核验"（代码160）；异常后可申诉。 + +### TP-C-036: 驾驶证核验(170) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证司机驾驶证在有效期内且证号与交管系统一致时，监管平台"驾驶证核验"返回通过。 +- 关键验证点: 驾驶证有效期覆盖运单执行日期；驾驶证号格式正确（18位）；驾驶证准驾车型与车辆类型匹配；核验状态为"通过"；无"驾驶证核验"异常项出现。 + +### TP-C-037: 驾驶证核验(170) — 异常场景（过期/缺失/准驾不符） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证司机驾驶证过期、缺失或准驾车型不匹配时，监管平台"驾驶证核验"返回异常。 +- 关键验证点: 驾驶证有效期截止日期 < 当前日期时核验异常；驾驶证号为空或格式无效时核验异常；准驾车型与实际驾驶车辆类型不匹配时核验异常；异常项明确标注"驾驶证核验"（代码170）；异常后可申诉。 + +### TP-C-038: 车辆重复核验(190) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证同一车辆未在同一时间段内被重复用于多个运单时，监管平台"车辆重复核验"返回通过。 +- 关键验证点: 车辆在运单执行时段内无其他重叠运单；车辆未同时出现在多个进行中的运单中；核验状态为"通过"；无"车辆重复核验"异常项出现。 + +### TP-C-039: 车辆重复核验(190) — 异常场景（车辆同时用于多个运单） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证同一车辆在同一时间段内被用于多个运单（时间重叠）时，监管平台"车辆重复核验"返回异常。 +- 关键验证点: 车辆在运单A执行期间同时出现在运单B中时核验异常；时间重叠超过合理阈值时核验异常；异常项明确标注"车辆重复核验"（代码190）；异常后可申诉。 + +### TP-C-040: 司机重复核验(200) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证同一司机未在同一时间段内被重复分配给多个运单时，监管平台"司机重复核验"返回通过。 +- 关键验证点: 司机在运单执行时段内无其他重叠运单；司机未同时驾驶多辆车辆执行不同运单；核验状态为"通过"；无"司机重复核验"异常项出现。 + +### TP-C-041: 司机重复核验(200) — 异常场景（司机同时执行多个运单） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证同一司机在同一时间段内被分配给多个运单（时间重叠）时，监管平台"司机重复核验"返回异常。 +- 关键验证点: 司机在运单A执行期间同时出现在运单B中时核验异常；时间重叠超过合理阈值时核验异常；异常项明确标注"司机重复核验"（代码200）；异常后可申诉。 + +### TP-C-042: 运费收款核验(220) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证运费收款方信息与实际司机/承运人一致、收款金额与运单运费匹配时，监管平台"运费收款核验"返回通过。 +- 关键验证点: 收款方身份与运单司机一致；收款金额与运单运费一致；收款账户信息有效；核验状态为"通过"；无"运费收款核验"异常项出现。 + +### TP-C-043: 运费收款核验(220) — 异常场景（收款人不一致/金额不匹配） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证运费收款人与运单司机不一致、收款金额与运费不匹配时，监管平台"运费收款核验"返回异常。 +- 关键验证点: 收款人姓名/身份证号与司机信息不一致时核验异常；收款金额与运单运费偏差超过阈值时核验异常；异常项明确标注"运费收款核验"（代码220）；异常后可申诉。 + +### TP-C-044: 公司统一收款核验(230) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证当收款方为公司统一收款账户时，公司信息与运单托运方信息一致，监管平台"公司统一收款核验"返回通过。 +- 关键验证点: 收款公司名称/统一社会信用代码与托运方一致；公司统一收款账户在系统中备案；核验状态为"通过"；无"公司统一收款核验"异常项出现。 + +### TP-C-045: 公司统一收款核验(230) — 异常场景（公司信息不一致/未备案） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证公司统一收款账户信息与托运方不一致或收款账户未备案时，监管平台"公司统一收款核验"返回异常。 +- 关键验证点: 收款公司名称与托运方名称不一致时核验异常；收款公司统一社会信用代码与托运方不一致时核验异常；收款账户未在系统中备案时核验异常；异常项明确标注"公司统一收款核验"（代码230）；异常后可申诉。 + +### TP-C-046: 发票信息核验(260) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证第三次上报关联的发票信息完整有效（发票号码/代码/金额匹配、销售方/受票方信息完整）时，监管平台"发票信息核验"返回通过。 +- 关键验证点: 发票号码与发票代码匹配有效；发票金额（价税合计）计算正确；销售方纳税人识别号有效；受票方信息与托运方一致；核验状态为"通过"。 + +### TP-C-047: 发票信息核验(260) — 异常场景（发票无效/信息不完整） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证发票号码/代码不匹配、发票信息不完整或发票已作废时，监管平台"发票信息核验"返回异常。 +- 关键验证点: 发票号码在税务系统中查询不到时核验异常；发票已作废/红冲时核验异常；受票方名称/纳税人识别号与托运方不一致时核验异常；异常项明确标注"发票信息核验"（代码260）；异常后可申诉。 + +### TP-C-048: 非通行车辆可开票核验(270) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证运单关联的车辆属于可开票车辆（即车辆资质、运营证照齐全且在合规运营范围内）时，监管平台"非通行车辆可开票核验"返回通过。 +- 关键验证点: 车辆运营证照齐全且在有效期内；车辆未被标记为不合规或黑名单；核验状态为"通过"；无"非通行车辆可开票核验"异常项出现。 + +### TP-C-049: 非通行车辆可开票核验(270) — 异常场景（车辆不合规/证照缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证车辆运营证照不全、车辆被标记为不合规或不在可开票范围内时，监管平台"非通行车辆可开票核验"返回异常。 +- 关键验证点: 车辆无有效道路运输证时核验异常；车辆被标记为运营异常/黑名单时核验异常；车辆类型不在可开票范围内时核验异常；异常项明确标注"非通行车辆可开票核验"（代码270）；异常后可申诉。 + +### TP-C-020: 后端校验 — 第二次上报依赖第一次上报完成 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-01：验证后端接口层面，第一次上报未完成（失败/进行中）时拒绝第二次上报，返回明确错误码。 +- 关键验证点: 第一次上报"上传失败"状态下触发第二次上报被拒绝；第一次上报"上传中"状态下触发第二次上报被拒绝；后端通过查询运单上报状态表校验，非仅前端控制；错误码和错误消息明确。 + +### TP-C-021: 第二次上报幂等性 — 防止重复上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-02：验证第二次上报具有幂等性，重复触发不产生多条上报记录，自动重试和手动触发互斥。 +- 关键验证点: 第二次上报自动重试期间禁止手动触发；同一运单第二次上报仅产生1条有效记录；分布式锁/幂等键控制并发；数据库唯一约束防止插入重复记录。 + +### TP-C-022: 补传轨迹功能 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证车辆轨迹合规核验异常后，运营人员可通过"补传轨迹"功能补充GPS轨迹数据，重新触发核验。 +- 关键验证点: 仅轨迹核验异常的运单显示"补传轨迹"按钮；补传后重新触发轨迹核验；补传的轨迹数据覆盖原有数据；补传后核验通过则异常项消除；补传操作记录到上报日志。 + +### TP-C-023: 第二次上报失败自动重试机制 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证第二次上报失败（超时或接口返回错误）后，系统自动重试（最多3次），重试间隔递增，3次全部失败后告警通知运营人员。 +- 关键验证点: 上报失败后自动触发重试（非人工触发）；最多重试3次；重试间隔递增（如5s/15s/30s）；每次重试在上报日志中独立记录；3次全部失败后通过站内信或短信告警通知运营人员；重试期间手动上传按钮不可用或提示"上报处理中"。 + +### TP-C-024: 第二次上报详情弹窗资金流水与车辆轨迹字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证第二次上报详情弹窗中资金流水信息（10字段）和车辆轨迹信息（6字段）的分组展示完整且字段顺序正确。 +- 关键验证点: 资金流水信息完整展示（支付金额/支付方式/支付时间/付款方名称/收款方名称/收款人/收款账号/收款账号类型/流水号/支付状态）；车辆轨迹信息完整展示（定位类型/定位时间/定位地点/经度/纬度/轨迹类型）；可选字段缺失时显示"-"或"无"而不空白；弹窗分组标签正确（运单信息/托运方信息/收货方信息/资金流水信息/车辆轨迹信息/异常信息）。 + +--- + +## 模块D: 第三次上报-开票完成 (11个测试点) + +### TP-D-001: 开票完成后触发第三次上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证发票开具完成后，系统触发第三次上报，上报数据包含运单信息、发票信息和油气发票信息。 +- 关键验证点: 发票开具完成后自动触发上报；上报数据包含托运单号数组、发票信息17字段；若有关联油气发票则包含油气发票信息；仅开票完成的运单触发。 + +### TP-D-002: 第三次上报列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证第三次上报列表展示的11个字段完整：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、发票号码、发票金额、开票日期、核验状态、异常原因、上报状态、操作。⚠️ 待确认: 原型列表比需求多4个字段（税率、销售方名称、受票方名称、油气票张数），共15列（含checkbox），需确认最终版本。 +- 关键验证点: 发票金额保留2位小数（价税合计）；开票日期格式正确；核验状态/异常原因/上报状态数据准确。 + +### TP-D-003: 第三次上报发票信息字段完整性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证第三次上报详情弹窗中"发票信息"分组的17个字段完整展示。 +- 关键验证点: 托运单号数组支持多个托运单号；发票号码、发票代码号、发票金额(价税合计)、开票日期必选完整；销售方8个字段(名称/纳税人识别号/地址/电话/开户行/银行账户)完整；受票方6个字段(名称/纳税人识别号/地址/电话/开户行/银行卡号)完整；注：第三次上报无税率字段。 + +### TP-D-004: 第三次上报油气发票信息 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证运单关联油气发票时，第三次上报包含油气发票信息（油气托运单号、油气发票文件），支持多条油气发票。 +- 关键验证点: 有油气发票时正常上报；无油气发票时不影响上报（可选字段）；多条油气发票时字段展示正确；油气发票文件支持查看/下载。 + +### TP-D-005: 后端校验 — 第三次上报依赖第二次上报完成 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-01：验证后端接口层面，第二次上报未完成（失败/进行中/未触发）时拒绝第三次上报，返回明确错误码。 +- 关键验证点: 第二次上报未完成时调用第三次上报接口被拒绝；错误码明确标识"前置上报（第二次）未完成"；后端通过查询运单上报状态表校验；第三阶段完整依赖链校验（第1→第2→第3）。 + +### TP-D-006: 增值税发票验证失败处理 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证增值税发票验证失败时（发票号码/代码/金额不匹配等），第三次上报失败并返回明确错误提示。 +- 关键验证点: 发票号码格式无效时上报失败；发票代码与发票号码不匹配时上报失败；发票金额超出合理范围时上报失败；失败提示指明具体错误字段和原因。 + +### TP-D-007: 第三次上报自动重试 — 最多3次 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [需求] +- 描述: 验证第三次上报失败后自动重试（最多3次），全部失败后告警通知运营人员。 +- 关键验证点: 重试次数不超过3次；重试间隔递增；全部失败后标记"上传失败"并告警；告警通知中包含运单号、发票号、失败原因。 + +### TP-D-008: 第三次上报异常信息展示 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证第三次上报详情弹窗中"异常信息"分组包含核验状态、异常原因、异常时间、处理状态，与申诉模块数据联动。 +- 关键验证点: 核验通过时异常原因为空；核验异常时展示具体异常项和原因；核验状态与看板/申诉模块数据一致。 + +### TP-D-009: 第三次上报幂等性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 +- 来源: [最佳实践][历史缺陷] +- 描述: 验证第三次上报具有幂等性，同一运单同一发票信息不能重复上报。 +- 关键验证点: 同一运单重复触发第三次上报仅产生1条有效记录；分布式锁/幂等键控制并发；重复提交返回"上报已存在"提示。 + +### TP-D-010: 第三次上报发票金额精度校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [漏测清单][风险矩阵] +- 描述: 验证第三次上报的发票金额（价税合计）保留2位小数，不出现浮点数精度问题。 +- 关键验证点: 金额计算精度正确（如0.01元不丢失）；大金额（如 999999.99）上报准确；金额字段使用 DECIMAL 类型而非 FLOAT；上报数据与开票系统数据完全一致。 + +### TP-D-011: 第三次上报货物信息/保险信息逐源验证 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [漏测清单] +- 描述: 验证第三次上报中的运单信息字段数据来源正确——价格/货物信息来源于运单表，保险信息来源于保险模块，非缓存数据。 +- 关键验证点: 修改运单表数据后上报使用最新值；修改保险信息后上报使用最新值；字段取值链路可追溯；不依赖装货完成时的数据快照。 + +### TP-D-012: 发票合规查询 — 托运人发票是否系统核验合规 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证可通过 POST /verificationSummary/cargoOwnerInvoiceInfo 接口查询托运人（货主）发票是否已通过系统核验合规，用于判断第三次上报前置条件。 +- 关键验证点: 输入有效托运人信息返回发票合规状态；发票合规时返回通过标识；发票不合规时返回异常原因；接口支持批量查询多个托运人发票合规状态；接口响应时间在合理范围内（< 3s）。 + +--- + +## 模块E: ETC发票上传 (9个测试点) + +### TP-E-001: ETC发票上传触发 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证ETC发票在税务抵扣完成后触发上传至安徽监管平台。 +- 关键验证点: 税务抵扣完成后 ETC 发票自动/手动触发上传；上传数据包含运单信息+ETC发票信息18字段；上传成功后可在列表查看状态。 + +### TP-E-002: ETC发票列表字段完整性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证ETC上传列表展示的11个字段完整：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、ETC发票号码、发票金额、税率、上传状态、操作。 +- 关键验证点: ETC发票号码与高速公路电子发票号码一致；发票金额和税率（3%）正确展示；上传状态标签颜色符合规范。 + +### TP-E-003: ETC发票详情弹窗 — 字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证ETC发票详情弹窗包含3个分组：运单信息（7字段）、ETC发票信息（每张发票18字段）、异常信息。 +- 关键验证点: ETC发票18字段全部展示：ETC发票号码、ETC发票代码、开票时间、发票金额、税率(3%)、税额、价税合计、销售方名称、销售方税号、受票方名称、受票方税号、入口收费站、出口收费站、交易时间、交易金额、交易匹配时间、交易流水号、ETC发票文件；运单信息7字段完整；异常信息4字段完整。 + +### TP-E-004: 税务抵扣完成前置条件校验 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 +- 来源: [需求] +- 描述: 验证ETC发票上传必须在税务抵扣完成后进行，未完成税务抵扣时上传被拒绝。 +- 关键验证点: 税务抵扣未完成时上传返回明确错误；错误提示包含"请先完成税务抵扣"；后端校验税务抵扣状态；税务抵扣完成后上传才可成功。 + +### TP-E-005: ETC发票验证失败处理 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证ETC发票信息验证失败时（发票号码/代码无效、金额不匹配、税率不正确等），上传失败并给出明确提示。 +- 关键验证点: 发票号码格式无效时上传失败；发票代码与号码不匹配时上传失败；税率非3%时提示税率异常；交易金额与实际通行费不匹配时验证失败；失败提示明确指示错误字段。 + +### TP-E-006: ETC上传自动重试 — 最多3次 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [需求] +- 描述: 验证ETC上传失败后自动重试最多3次，全部失败后告警通知。 +- 关键验证点: 3次重试均失败后标记"上传失败"并告警；重试间隔递增；每次重试记录到上报日志。 + +### TP-E-007: ETC税额计算校验 — 税额=发票金额×3% +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][风险矩阵] +- 描述: 验证ETC发票税额计算公式：税额 = 发票金额 x 3%，结果保留2位小数，涉及资损风险需精确验证。 +- 关键验证点: 发票金额100元 → 税额=3.00元；发票金额0.01元 → 税额=0.00元(或四舍五入规则明确)；大金额(如1000000元)计算不溢出；税额与价税合计逻辑关系正确(价税合计=金额+税额)。 + +### TP-E-008: ETC上传幂等性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 +- 来源: [最佳实践][历史缺陷] +- 描述: 验证同一ETC发票不能重复上传，具有幂等性。 +- 关键验证点: 同一ETC发票号重复上传被拒绝；返回"该ETC发票已上传"提示；数据库存在唯一约束防止重复记录。 + +### TP-E-009: ETC多张发票同时上传 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [需求][项目画像] +- 描述: 验证同一运单可能关联多张ETC发票（不同路段），支持批量上传和多张发票的列表展示。 +- 关键验证点: 多张ETC发票各自独立上传互不干扰；列表中单运单可展示多张ETC发票记录；每张发票的税额独立计算；合计税额正确汇总。 + +--- + +## 模块F: 异常申诉功能 (13个测试点) + +### TP-F-001: 申诉完整闭环 — 发起→复核→反馈→判断 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证申诉功能的完整闭环：查看异常 → 发起申诉 → 省平台复核 → 接收反馈 → 合规判断，端到端验证每个环节。⚠️ 待确认: 申诉状态枚举三版本不一致——需求(未申诉/申诉中/申诉通过/申诉驳回)、原型(未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回)、API(未申诉100/审核通过110/审核不通过120/已取消130)，需确认最终版本。 +- 关键验证点: 异常运单可发起申诉；申诉提交后状态变为"申诉中"；省平台复核后反馈结果更新；反馈通过→申诉状态变为"申诉通过"；反馈驳回→申诉状态变为"申诉驳回"，可补充材料重新申诉。 + +### TP-F-002: 申诉列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证申诉记录管理页面列表展示的13个字段完整：运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、异常项、申诉状态、申诉时间、申诉人、省平台反馈结果、监管平台反馈时间、操作。 +- 关键验证点: 每个字段有对应数据；申诉状态与需求定义一致；申诉时间为实际提交时间；省平台反馈结果与实际反馈内容一致。 + +### TP-F-003: 申诉状态流转 — 全部合法路径 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 +- 来源: [需求][漏测清单] +- 描述: 验证申诉状态流转全路径：未申诉 → 申诉中 → 申诉通过 / 申诉驳回 → (驳回后) 重新申诉。⚠️ 待确认: 申诉状态流转中的"申诉中"在原型中被拆分为"待省平台反馈"+"反馈处理中"两个状态，API中无"申诉中"状态仅有"未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130)"，需确认最终版本。 +- 关键验证点: 未申诉状态下可发起申诉；申诉中状态下不可重复发起；申诉通过后状态不可再变更（终态）；申诉驳回后可点击"重新申诉"发起新一轮申诉；每种状态变更记录到处理记录时间线。 + +### TP-F-004: 申诉详情弹窗 — 分组字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证申诉详情弹窗包含5个分组：申诉信息、运单信息、异常信息、省平台反馈信息、处理记录。 +- 关键验证点: 申诉信息分组含申诉单号/上报阶段/异常项/申诉原因/申诉状态/申诉时间/申诉人/申诉附件；省平台反馈信息含反馈结果/反馈时间/反馈意见；处理记录以时间线形式展示：操作人/操作时间/操作类型/操作内容。 + +### TP-F-005: 申诉附件上传功能 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][项目画像] +- 描述: 验证发起申诉时支持上传附件（如证明材料图片/PDF），附件上传功能正常。 +- 关键验证点: 支持上传多个附件；附件格式支持常见类型(png/jpg/pdf)；附件大小有限制且超标时提示；上传后可在详情弹窗中查看/下载；上传失败有重试机制。 + +### TP-F-006: 驳回后重新申诉 — 补充材料再发起 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证申诉被省平台驳回后，运营人员可补充材料，点击"重新申诉"发起新一轮申诉。 +- 关键验证点: 驳回状态下"重新申诉"按钮可见可用；重新申诉时原有申诉记录保留；新一轮申诉生成新的申诉单号；重新申诉可上传新的附件材料；新的申诉有独立的处理记录时间线。 + +### TP-F-007: 17项核验（API文档定义）异常各自发起申诉 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [需求] +- 描述: 验证第二次上报的17项核验（API文档§4.1定义：委托合同100/承运合同120/实时定位130/运单时间逻辑140/车辆资质150/道路运输证160/驾驶证170/从业资格证180/车辆重复190/司机重复200/车辆轨迹210/运费收款220/公司统一收款230/集中支付240/资金流水250/发票信息260/非通行车辆可开票270）每项核验异常均可独立发起申诉。⚠️ 待确认: 核验项从需求7类扩展为API文档17项，需确认每项是否均有独立申诉入口。 +- 关键验证点: 每种核验异常项对应独立的申诉入口；申诉中异常项信息与核验结果一致；不同异常项的申诉原因字段独立；某一异常项申诉不影响其他异常项。 + +### TP-F-008: 从看板直接跳转申诉 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证从看板"操作"列点击"申诉"按钮，可跳转到申诉页面并自动填充运单号、异常项信息。 +- 关键验证点: 看板"申诉"按钮点击后路由跳转正确；跳转后页面自动加载该运单的异常信息；运单号和异常项预填充正确；不需要运营人员手动查找运单。 + +### TP-F-009: 申诉权限控制 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 权限控制 +- 来源: [项目画像] +- 描述: 验证仅运营人员有权发起申诉和管理申诉记录，其他角色（司机/车队长/货主/财务）不能操作申诉功能。 +- 关键验证点: 运营人员可见"申诉"按钮和申诉记录页面；司机端不可见申诉功能；财务人员可查看申诉记录但不可发起申诉；越权操作被正确拦截并记录审计日志。 + +### TP-F-010: 申诉处理记录时间线展示 +- 优先级: P2 +- 类型: UI测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证申诉详情弹窗中"处理记录"以时间线形式展示，每条记录包含操作人、操作时间、操作类型、操作内容。 +- 关键验证点: 时间线按时间倒序排列；每步操作（发起申诉/省平台反馈/重新申诉）均有一条记录；操作时间精确到秒；操作类型准确（发起申诉/复核通过/复核驳回等）。 + +### TP-F-011: 异常代码一览表匹配校验 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证需求文档中"异常代码一览表"定义的每种异常代码，在申诉页面中正确映射为对应的中文异常项名称。 +- 关键验证点: 每种异常代码有明确的中文描述；异常代码与异常项名称一一对应；省平台返回的异常代码能被正确解析；未知异常代码有兜底展示（如显示原始代码+标注"未知异常"）。 + +### TP-F-012: 申诉并发控制 — 同一异常项不可重复申诉 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 +- 来源: [漏测清单] +- 描述: 验证同一运单同一异常项"申诉中"状态下不可再次发起申诉，防止重复提交。 +- 关键验证点: "申诉中"状态下点击"申诉"按钮被禁用或提示"申诉处理中"；快速双击"提交申诉"按钮仅产生1条申诉记录；后端有状态校验，申诉中不可重新发起。 + +### TP-F-013: 申诉超时处理 — 省平台长时间无反馈 +- 优先级: P3 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [漏测清单] +- 描述: 验证申诉提交后，省平台长时间无反馈时，系统有合理的超时处理和状态提示。 +- 关键验证点: 申诉提交后超过一定时间（如7个工作日）无反馈时，系统给出"等待省平台复核中"的提示或超时告警；不自动变更申诉状态为通过/驳回；运营人员可查看申诉等待时长。 + +--- + +## 模块G: 上报日志 (9个测试点) + +### TP-G-001: 上报日志 — 按运单号/托运单号/货源单号模糊搜索 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证上报日志页面支持按运单号/托运单号/货源单号模糊搜索，快速定位相关日志。 +- 关键验证点: 输入完整单号精确匹配；输入部分字符模糊匹配；输入不存在的单号显示空结果；三种单号搜索互不干扰。 + +### TP-G-002: 上报日志 — 按上报阶段筛选 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证上报日志支持按"全部/第一次上报/第二次上报/第三次上报/ETC上传"筛选。 +- 关键验证点: 每种阶段独立筛选数据正确；ETC上传有独立筛选项；默认"全部"展示所有阶段日志。 + +### TP-G-003: 上报日志 — 按上报结果筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证上报日志支持按"全部/成功/失败"筛选上报结果。 +- 关键验证点: "成功"仅展示HTTP 2xx的日志；"失败"展示所有非成功日志(含超时/4xx/5xx)；筛选结果与实际日志记录一致。 + +### TP-G-004: 上报日志 — 时间范围筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证上报日志支持按开始时间-结束时间范围筛选日志记录。 +- 关键验证点: 精确时间范围筛选数据正确；跨天/跨月筛选正常；开始时间>结束时间时给出提示或自动交换；不选时间范围默认显示全部。 + +### TP-G-005: 上报日志列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证上报日志列表展示的9个字段完整：序号、货源单号、运单号、托运单号、上报阶段、上报结果、接口URL、HTTP状态码、响应时间、上报时间、操作。 +- 关键验证点: 接口URL完整展示（含域名和路径）；HTTP状态码为实际返回状态码（200/400/500等）；响应时间单位明确（ms）；上报时间为实际请求发起时间。 + +### TP-G-006: 上报日志操作 — 弹窗查看完整请求/响应报文 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证点击日志"操作"列的详情按钮，弹窗展示完整的请求报文（Request）和响应报文（Response），用于问题排查。 +- 关键验证点: 请求报文完整展示：URL、Method、Headers、Body；响应报文完整展示：Status Code、Headers、Body；JSON 报文格式化展示（缩进/语法高亮）；长报文支持滚动查看和复制。 + +### TP-G-007: 上报日志全阶段覆盖 — 每个上报阶段的日志记录 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证每个上报阶段（第一次/第二次/第三次/ETC）以及自动修改字段接口的每次调用都在日志中有完整记录。 +- 关键验证点: 第一次上报+自动修改字段接口均有日志；第二次上报+7类核验结果均有日志；第三次上报日志完整；ETC上传日志完整；自动重试的每次请求均独立记录。 + +### TP-G-008: 上报日志失败记录的可追溯性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [漏测清单] +- 描述: 验证上报失败的日志记录足够详细，可通过日志定位失败原因——包括错误响应体、异常堆栈（如有）、重试次数等。 +- 关键验证点: 失败日志包含完整的Error Response Body；超时日志标注"timeout"并记录超时时长；重试日志中标注当前是第几次重试；异常日志可关联到具体运单ID便于排查。 + +### TP-G-009: 上报日志审计 — 操作人追踪 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 权限控制 +- 来源: [项目画像][最佳实践] +- 描述: 验证上报日志中可区分自动触发上报和手动触发上报，并记录操作人信息。 +- 关键验证点: 自动触发上报的日志标注"系统自动"或"auto"；手动触发上报的日志记录操作人用户名；手动上传的操作人信息与实际登录用户一致；审计能力满足合规要求。 + +--- + +## 跨模块测试点（6个测试点） + +### TP-X-001: 完整三阶段依赖链端到端验证 — 后端三重校验 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 端到端验证三阶段依赖链：装货完成→第一次上报成功→打款完成→第二次上报成功→开票完成→第三次上报成功。核心验证后端在每个阶段都做了前置状态校验。 +- 关键验证点: 第1次上报失败→第2次上报接口拒绝；第2次上报失败→第3次上报接口拒绝；第1、2、3次顺序不可跳级；依赖链校验在后端实现（非仅前端控制）；每个阶段的阻断/通过状态独立。 + +### TP-X-002: 多模块数据一致性 — 修改源数据后上报同步 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 数据校验 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-03：验证上报数据字段溯源正确，修改来源表数据后各阶段上报能感知变更并使用最新值。 +- 关键验证点: 修改司机信息→第一次上报使用最新司机信息；修改支付流水→第二次上报使用最新金额；修改发票信息→第三次上报使用最新发票数据；修改ETC信息→ETC上传使用最新数据；数据库查询日志可确认数据来源表，非缓存。 + +### TP-X-003: 安徽运八全流程 — 正常运单完整上报链路 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 端到端验证一个安徽税源地运单从装货到ETC上传的完整三阶段+ETC上报链路，所有阶段核验通过，无异常。 +- 关键验证点: 装货完成→第1次上报成功(绿色)→核验通过→自动修改字段→打款完成→第2次上报成功(核验全通过)→开票完成→第3次上报成功→税务抵扣→ETC上传成功；每个阶段看板数据正确更新；上报日志完整记录全链路。 + +### TP-X-004: 非安徽税源地运单 — 全流程不上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][项目画像] +- 描述: 验证税源地为非安徽省（如云南=28）的运单，全部三个阶段和ETC上传均不触发上报。 +- 关键验证点: 云南税源地运单装货完成不触发第1次上报；打款完成不触发第2次上报；开票完成不触发第3次上报；税务抵扣不触发ETC上传；看板中不显示该运单。 + +### TP-X-005: 三阶段上报各省份数据隔离 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 权限控制 +- 来源: [项目画像][历史缺陷] +- 描述: 验证多省份部署场景下，安徽运八上报数据与其他省份（如云南）上报数据完全隔离，互不干扰。 +- 关键验证点: 安徽运单仅上报至安徽监管平台；云南运单仅上报至云南监管平台；省份代码各自独立（安徽=34、云南=28）；不同省份的上报日志和数据记录物理/逻辑隔离。 + +### TP-X-006: 回单签收后自动流转上报 — 时序正确性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 状态流转 +- 来源: [需求][项目画像] +- 描述: 验证运单在回单签收→财务打款的时序下，第二次上报的触发时机为"打款完成"而非"回单签收"，时序正确。 +- 关键验证点: 回单签收完成但未打款时，不触发第二次上报；财务打款完成后才触发第二次上报；上报时间戳与打款完成时间关系合理。 + +--- + +## 历史缺陷防御映射表 + +| 历史缺陷ID | 防御测试点 | +| :--- | :--- | +| BUG-202607-01（阶段依赖链断裂） | TP-B-005, TP-C-020, TP-D-005, TP-X-001 | +| BUG-202607-02（重试幂等缺陷） | TP-B-014, TP-C-021, TP-D-009, TP-E-008, TP-F-012 | +| BUG-202607-03（跨模块数据不一致） | TP-C-002, TP-C-003, TP-D-011, TP-X-002 | +| BUG-202607-04（省份代码硬编码） | TP-B-004, TP-X-005 | + +## 漏测清单覆盖映射表 + +| 漏测项 | 覆盖测试点 | +| :--- | :--- | +| 空值/Null | TP-B-018 | +| 金额精度 | TP-C-002, TP-D-010, TP-E-007 | +| 重复提交/防抖 | TP-B-014, TP-C-021, TP-D-009, TP-E-008 | +| 超时处理 | TP-B-015, TP-B-016, TP-F-013 | +| 列表字段完整性 | TP-A-008, TP-C-004, TP-D-002, TP-E-002, TP-F-002, TP-G-005 | +| 查询重置 | TP-A-007 | +| 状态与按钮映射 | TP-A-010, TP-B-009 | +| 多阶段依赖链 | TP-B-005, TP-C-020, TP-D-005, TP-X-001 | +| 第三方核验逐项覆盖 | TP-C-006 ~ TP-C-019（7类核验×通过+异常=14个测试点）+ TP-C-026 ~ TP-C-049（API文档12项补充核验×通过+异常=24个测试点），共覆盖API文档17项核验 | 已覆盖 | +| 重试+手动触发并发 | TP-B-014, TP-C-021 | +| 跨模块数据一致性 | TP-C-002, TP-C-003, TP-X-002 | +| 省份/区域配置隔离 | TP-B-004, TP-X-005 | +| 上报数据字段溯源 | TP-C-002, TP-D-011, TP-X-002 | +| 标签颜色映射 | TP-A-009, TP-B-010, TP-C-005 | +| 详情弹窗分组完整性 | TP-A-011, TP-B-011, TP-B-012, TP-C-004, TP-D-003, TP-E-003, TP-F-004 | +| 轨迹数据边界（2~2000） | TP-C-018, TP-C-019 | +| 申诉闭环 | TP-F-001, TP-F-003, TP-F-006 | +| 操作日志可追溯 | TP-G-005, TP-G-006, TP-G-007, TP-G-008, TP-G-009 | + +--- + +> ⚠️ 待确认项： +> 1. 需求中"异常代码一览表"章节仅有标题无具体内容，需与产品确认完整的异常代码映射表后补充 TP-F-011 的详细验证数据。 +> 2. 自动重试的具体间隔时间（5s/15s/30s 为假设值），需与技术方案确认后更新 TP-B-007, TP-C-022, TP-D-007, TP-E-006 中的重试间隔。 +> 3. ETC税额边界值（0.01元 → 税额=0.00）的四舍五入规则需与财务确认，更新 TP-E-007。 +> 4. 申诉超时告警阈值（假设7个工作日）需与产品确认，更新 TP-F-013。 +> 5. 需求关联与冲突报告未识别到冲突项，建议在后续需求评审中人工确认安徽运八与现有云南运八上报逻辑是否存在字段/接口冲突。 diff --git a/output/versions/安徽运八需求/v3/安徽运八需求_测试用例.md b/output/versions/安徽运八需求/v3/安徽运八需求_测试用例.md new file mode 100644 index 0000000..6cea5cd --- /dev/null +++ b/output/versions/安徽运八需求/v3/安徽运八需求_测试用例.md @@ -0,0 +1,387 @@ +# 安徽运八需求 测试用例 + +> 生成时间: 2026-07-13 +> 需求文档: output/normalized_inputs/安徽运八需求/requirement.md +> 测试点来源: output/test_points/安徽运八需求_测试点.md (106个测试点) +> 测试数据参考: output/analysis/安徽运八需求_测试数据.md +> 关联分析: output/analysis/安徽运八需求_关联与冲突.md +> +> 测试用例总数: 150 +> P0: 28 / P1: 80 / P2: 34 / P3: 8 +> 模块分布: A(看板)=18, B(第一次上报)=23, C(第二次上报)=48, D(第三次上报)=15, E(ETC)=12, F(申诉)=17, G(日志)=11, X(跨模块)=7 + +--- + +## 模块A: 上报运单看板 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_DASH_001 | 平台端-监管上报-上报看板 | 验证看板按完整运单号精确搜索运单 | P0 | 功能测试 | 1. 使用super_admin账号登录管理端https://ybxcx.ynyun8.com:8000/admin；2. 系统中存在运单号YB202607130001的运单记录 | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入完整运单号"YB202607130001"；3. 点击搜索按钮或按回车键 | 运单号: YB202607130001 | 页面列表仅展示1条记录，运单号列显示"YB202607130001"（精确匹配）；数据库查询返回唯一记录，where条件为waybill_no='YB202607130001' | 对应TP-A-001 | +| AH_REPORT_DASH_002 | 平台端-监管上报-上报看板 | 验证看板按运单号模糊搜索匹配多条记录 | P0 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在运单号包含"YB20260713"前缀的多条运单（如YB202607130001、YB202607130002、YB202607130003） | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入"YB20260713"；3. 点击搜索 | 运单号部分字符: YB20260713 | 页面列表展示3条记录，所有运单号均包含"YB20260713"；数据库查询SQL使用LIKE '%YB20260713%'匹配，返回3条结果 | 对应TP-A-001 | +| AH_REPORT_DASH_003 | 平台端-监管上报-上报看板 | 验证看板按不存在的单号搜索显示空结果 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端 | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入不存在的单号"NOTEXIST999"；3. 点击搜索 | 运单号: NOTEXIST999 | 页面列表显示空状态，提示"未找到匹配数据"或空结果占位图；数据库查询返回0条记录；页面不出现控制台报错 | 对应TP-A-001 | +| AH_REPORT_DASH_004 | 平台端-监管上报-上报看板 | 验证看板按"第一次上报"阶段筛选运单 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在不同上报阶段的运单（至少含1条第一次上报、1条第二次上报的运单） | 1. 进入"监管上报-上报看板"页面，默认为"全部"；2. 点击上报阶段下拉框，选择"第一次上报"；3. 观察列表数据 | 筛选条件: 第一次上报 | 列表仅展示上报阶段为"第一次上报"的运单；每条记录的上报阶段列均为"第一次上报"；数据库查询添加where report_stage='first'过滤条件；总条目数与数据库中第一次上报运单数一致 | 对应TP-A-002 | +| AH_REPORT_DASH_005 | 平台端-监管上报-上报看板 | 验证看板按"异常"核验状态筛选运单 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在核验状态为"通过"和"异常"的运单 | 1. 进入"监管上报-上报看板"页面；2. 点击核验状态下拉框，选择"异常"；3. 观察列表数据 | 筛选条件: 核验状态=异常 | 列表仅展示核验状态为"异常"（橙色标签）的运单；所有"通过"的运单被过滤；数据库查询添加where verification_status='abnormal'条件 | 对应TP-A-003 | +| AH_REPORT_DASH_006 | 平台端-监管上报-上报看板 | 验证看板按"申诉中"申诉状态筛选运单 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在申诉状态为"申诉中"的运单至少1条 | 1. 进入"监管上报-上报看板"页面；2. 点击申诉状态下拉框，选择"申诉中"；3. 观察列表数据并与全部列表对比 | 筛选条件: 申诉状态=申诉中 | 列表仅展示申诉状态为"申诉中"的运单；申诉状态列标签显示"申诉中"且颜色与需求定义一致；数据库查询添加where appeal_status='in_progress'条件 | 对应TP-A-004；⚠️ 待确认: 原型看板申诉状态下拉值为"未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回"，与需求不一致 | +| AH_REPORT_DASH_007 | 平台端-监管上报-上报看板 | 验证看板组合筛选—第二次上报+异常+申诉中+运单号模糊搜索 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 数据库中存在满足组合条件的运单（第二次上报、核验异常、申诉中、运单号含"YB2026"） | 1. 进入"监管上报-上报看板"页面；2. 上报阶段选"第二次上报"；3. 核验状态选"异常"；4. 申诉状态选"申诉中"；5. 运单号输入"YB2026"；6. 点击搜索 | 组合条件: 第二次上报+异常+申诉中; 运单号模糊: YB2026 | 列表仅展示同时满足4个条件的运单；每个条件都在数据库SQL中体现（多WHERE条件AND组合）；空结果时显示"未找到匹配数据"；切换任一筛选条件不丢失运单号搜索框中已输入的关键字 | 对应TP-A-005 | +| AH_REPORT_DASH_008 | 平台端-监管上报-上报看板 | 验证看板导出当前筛选结果为Excel文件 | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板列表中有≥20条运单数据 | 1. 进入"监管上报-上报看板"页面；2. 设置筛选条件（如上报阶段=第一次上报）；3. 点击"导出"按钮；4. 等待文件下载完成；5. 打开下载的Excel文件 | 筛选: 第一次上报 | 浏览器触发文件下载，文件名为.xlsx格式；Excel文件可正常打开，表头包含14个列表字段（货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、申诉状态、异常项、货物名称、合同金额、最新核验时间、操作）；导出数据行数与筛选结果一致；导出过程中页面不卡死、不超时 | 对应TP-A-006 | +| AH_REPORT_DASH_009 | 平台端-监管上报-上报看板 | 验证看板大数据量导出不超时不OOM | P2 | 性能测试 | 1. 使用super_admin账号登录管理端；2. 数据库中存在≥2000条运单记录 | 1. 进入"监管上报-上报看板"页面；2. 选择"全部"筛选条件；3. 点击"导出"按钮；4. 记录从点击到下载完成的时间 | 导出全部数据, 约2000+条 | 导出在60秒内完成下载（不超时）；导出的Excel文件包含全部数据行，无截断；后台服务内存使用率未显著增长（无OOM）；导出过程中看板页面仍可正常操作 | 对应TP-A-006 | +| AH_REPORT_DASH_010 | 平台端-监管上报-上报看板 | 验证看板重置按钮恢复所有查询条件至默认值 | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 已在上报阶段选择"第二次上报"、核验状态选择"异常"、运单号输入"YB2026" | 1. 进入"监管上报-上报看板"页面；2. 点击"重置"按钮；3. 观察页面各筛选条件和列表数据 | 重置前条件: 第二次上报+异常+YB2026 | 模糊搜索输入框清空为空白；所有下拉筛选恢复为"全部"；列表刷新展示默认全部运单数据（初始状态）；分页回到第1页；数据库查询恢复为无过滤条件的默认查询 | 对应TP-A-007 | +| AH_REPORT_DASH_011 | 平台端-监管上报-上报看板 | 验证看板列表展示14个字段且顺序与需求一致 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在至少1条完整运单记录 | 1. 进入"监管上报-上报看板"页面；2. 查看列表表头和第一条数据的各列内容；3. 对比需求文档中的字段顺序 | 查看运单YB202607130001 | 列表14个字段顺序为: 货源单号→运单号→托运单号→车牌号→司机姓名→托运方名称→上报阶段→核验状态→申诉状态→异常项→货物名称→合同金额→最新核验时间→操作；合同金额列保留2位小数（如¥10,000.00）；最新核验时间为YYYY-MM-DD HH:mm:ss格式；异常项为空时显示"-"而非"null"或"undefined" | 对应TP-A-008 | +| AH_REPORT_DASH_012 | 平台端-监管上报-上报看板 | 验证看板状态标签颜色—蓝色(上传中)、绿色(已上传)、红色(上传失败)、橙色(异常) | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在4种上报状态的运单各1条 | 1. 进入"监管上报-上报看板"页面；2. 找到上报状态为"上传中"的运单，查看标签颜色；3. 找到"已上传"运单，查看标签颜色；4. 找到"上传失败"运单，查看标签颜色；5. 找到"异常"运单，查看标签颜色 | 运单1: 上传中; 运单2: 已上传; 运单3: 上传失败; 运单4: 异常 | "上传中"标签显示蓝色背景/文字；"已上传"标签显示绿色背景/文字；"上传失败"标签显示红色背景/文字；"异常"标签显示橙色背景/文字；状态切换时标签颜色即时刷新不闪烁；申诉状态标签（申诉中/申诉通过/申诉驳回）颜色各自区分清晰 | 对应TP-A-009 | +| AH_REPORT_DASH_013 | 平台端-监管上报-上报看板 | 验证看板操作列—异常运单显示申诉按钮、所有运单显示详情按钮 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在核验通过的运单1条和核验异常的运单1条 | 1. 进入"监管上报-上报看板"页面；2. 查看核验通过运单的操作列按钮；3. 查看核验异常运单的操作列按钮；4. 点击异常运单的"申诉"按钮 | 通过运单: YB202607130001; 异常运单: YB202607130002 | 核验通过运单的操作列显示"详情"和"进度"按钮，不显示"申诉"按钮；核验异常运单的操作列显示"申诉""详情""进度"三个按钮；点击"申诉"按钮后页面路由跳转至申诉页面，URL携带正确的运单ID参数；点击"详情"按钮弹出详情弹窗，展示该运单的完整上报信息 | 对应TP-A-010 | +| AH_REPORT_DASH_014 | 平台端-监管上报-上报看板 | 验证看板详情弹窗—建单信息分组13字段完整 | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板列表中有可查看详情的运单YB202607130001 | 1. 进入"监管上报-上报看板"页面；2. 点击运单YB202607130001操作列的"详情"按钮；3. 在弹窗中查看"建单信息"分组的所有字段 | 运单号: YB202607130001 | 建单信息分组展示13个字段: 上游企业委托运输单号、本运单单号、托运人建单时间、网络货运经营者名称、统一社会信用代码、道路运输经营许可证编号、业务类型代码、运输组货方式代码、司机接单时间、司机起运时间、承运合同编号（必选）、委托合同编号（可选）、运输里程（可选）；必选字段均有值；可选字段委托合同编号和运输里程为空时显示"-"；各字段格式与接口规范一致 | 对应TP-A-011 | +| AH_REPORT_DASH_015 | 平台端-监管上报-上报看板 | 验证看板详情弹窗—各子对象分组字段完整(托运人/收货方/司机/车辆/货物) | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板列表中有运单YB202607130001包含完整的子对象信息 | 1. 进入"监管上报-上报看板"页面；2. 点击运单YB202607130001的"详情"按钮；3. 依次展开托运人信息、收货方信息、司机信息、车辆信息、货物信息分组 | 运单号: YB202607130001; 司机: 15188888888 | 托运人信息7字段完整（含统一社会信用代码18位格式校验）；收货方信息5字段完整（身份证号如适用需脱敏展示）；司机信息13字段完整（从业资格证有效期起止日期格式正确）；车辆信息19字段完整（VIN码17位正确展示）；货物信息支持多条记录展开，每条含货物名称、货物类型代码、货物量、计量单位；可选字段为空时显示"-" | 对应TP-A-011 | +| AH_REPORT_DASH_016 | 平台端-监管上报-上报看板 | 验证看板空数据状态展示友好占位提示 | P3 | 易用性测试 | 1. 使用super_admin账号登录管理端；2. 选择一个筛选条件组合确保结果为0条（如运单号输入"ZZZZZZZZZZ"） | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框输入"ZZZZZZZZZZ"；3. 点击搜索 | 运单号: ZZZZZZZZZZ | 列表区域显示友好空状态占位图/文，不显示空白表格；有明确文字提示"未找到匹配数据"或类似文案；浏览器开发者工具Console无报错；页面无崩溃或白屏 | 对应TP-A-012 | +| AH_REPORT_DASH_017 | 平台端-监管上报-上报看板 | 验证看板分页功能—翻页数据不重复不遗漏 | P3 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板中有超过20条运单（默认每页20条） | 1. 进入"监管上报-上报看板"页面，记录第1页的运单号列表；2. 点击"下一页"进入第2页；3. 记录第2页的运单号列表；4. 对比两页数据；5. 查看分页组件显示的总条数 | 每页20条 | 第1页和第2页的运单号无重复；第2页首条数据不是第1页已出现的数据；切换每页条数（如50条/页）后分页重新计算正确；分页组件显示的总条数与数据库COUNT查询结果一致；数据按最新核验时间倒序排列（最近核验的在最前面） | 对应TP-A-013 | +| AH_REPORT_DASH_018 | 平台端-监管上报-上报看板 | 验证不同角色看板权限—运营可见全部/财务可见打款字段/司机不可见平台端看板 | P1 | 安全性测试 | 1. 准备super_admin账号(运营)、财务账号、车队长账号13113113113、司机账号15188888888；2. 系统中存在运单数据 | 1. 使用super_admin登录，进入看板，验证可见全部运单和全部字段；2. 使用财务账号登录，进入看板，验证可见运单范围和打款相关字段；3. 使用车队长13113113113登录司机端，验证是否有看板入口；4. 使用司机15188888888登录司机端，验证是否有看板入口 | 运营: super_admin; 财务: finance_user; 车队长: 13113113113/88888888; 司机: 15188888888/88888888 | super_admin可见全部运单和全部14个字段；财务可见运单但打款金额/付款方式/收款账号类型等字段可见；车队长登录司机端后无"监管上报-上报看板"菜单入口，直接URL访问被拦截返回403；司机登录司机端后同样无看板入口，越权访问被拦截并记录审计日志 | 对应TP-A-014 | + +--- + +## 模块B: 第一次上报-装货完成 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_R1_001 | 平台端-监管上报-第一次上报 | 验证装货完成后自动触发第一次上报且全部子对象数据完整 | P0 | 功能测试 | 1. 使用司机账号15188888888登录司机端APP；2. 存在一条安徽税源地(provinceCode=34)的运单YB202607130001，状态为"待装货"；3. 运单包含完整的托运人、收货方、司机、车辆、货物信息 | 1. 司机到达装货地，上传装货照片和资料；2. 司机在APP端点击"确认装货完成"；3. 等待系统自动触发第一次上报；4. 使用super_admin登录管理端，进入"监管上报-第一次上报"列表查看该运单上报状态 | 运单号: YB202607130001; 司机: 15188888888; 装货地省份代码: 34 | 司机端提示"装货完成，上报已提交"；管理端第一次上报列表中出现该运单记录，上报状态为"上传中"（蓝色标签），随后变为"已上传"（绿色标签）；上报请求JSON包含全部7个子对象(建单信息/托运人/收货方/司机/车辆/货物/保险)；数据库report_record表status字段从0变为1，上报时间字段非空 | 对应TP-B-001 | +| AH_REPORT_R1_002 | 平台端-监管上报-第一次上报 | 验证非安徽税源地运单(云南=28)装货完成后不触发第一次上报 | P0 | 功能测试 | 1. 使用司机账号15188888888登录司机端APP；2. 存在一条云南税源地(provinceCode=28)的运单YB202607130002，状态为"待装货" | 1. 司机完成装货并点击"确认装货完成"；2. 检查管理端"监管上报-第一次上报"列表；3. 检查系统日志是否有上报请求记录 | 运单号: YB202607130002; 省份代码: 28(云南) | 管理端第一次上报列表中不出现该运单记录；系统日志中无该运单的上报接口调用记录；运单状态正常流转为"运输中"，不受上报模块影响；无任何错误日志或异常告警产生 | 对应TP-B-002 | +| AH_REPORT_R1_003 | 平台端-监管上报-第一次上报 | 验证安徽税源地运单(省份代码=34)触发上报，其他省份不触发 | P0 | 功能测试 | 1. 准备安徽(34)、云南(28)、四川(51)税源地的运单各1条；2. 三条运单状态均为"待装货" | 1. 分别对三条运单确认装货完成；2. 进入管理端第一次上报列表查看；3. 查询数据库report_record表 | 安徽运单: provinceCode=34; 云南运单: provinceCode=28; 四川运单: provinceCode=51 | 仅安徽(34)运单在第一次上报列表中出现，上报状态正常更新；云南(28)和四川(51)运单均不在列表中；数据库report_record表仅新增1条记录，province_code=34 | 对应TP-B-002; TP-B-004 | +| AH_REPORT_R1_004 | 平台端-监管上报-第一次上报 | 验证第一次上报建单信息必选字段缺失时上报被拒绝并明确提示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 构造一条建单信息中"承运合同编号"为空的运单YB202607130003 | 1. 触发该运单装货完成事件（模拟或真实操作）；2. 查看第一次上报返回结果；3. 查看上报日志中的错误信息 | 运单号: YB202607130003; 缺失字段: 承运合同编号 | 上报接口返回错误，提示"必选字段承运合同编号不能为空"或类似明确消息；上报状态标记为"上传失败"（红色标签）；上报日志中记录该次失败请求，包含请求体和错误响应体；运单状态不会错误地标记为"已上传" | 对应TP-B-003 | +| AH_REPORT_R1_005 | 平台端-监管上报-第一次上报 | 验证第一次上报统一社会信用代码格式校验（非18位时拒绝） | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 构造一条运单，托运人统一社会信用代码为"123456"（6位无效格式） | 1. 触发该运单装货完成事件；2. 查看上报接口返回；3. 查看上报日志 | 运单号: YB202607130004; 信用代码: 123456(无效) | 上报接口返回校验错误，提示"统一社会信用代码格式不正确，需为18位"；上报状态标记为"上传失败"；不会错误地将无效代码上报至监管平台 | 对应TP-B-003 | +| AH_REPORT_R1_006 | 平台端-监管上报-第一次上报 | 验证第一次上报中司机信息省份代码为安徽=34（非云南=28） | P0 | 功能测试 | 1. 使用super_admin登录管理端；2. 准备一条安徽税源地(34)的完整运单YB202607130001 | 1. 触发的第一次上报完成后；2. 在上报日志中查看该次上报的完整请求JSON；3. 定位司机信息(driverInfo)中的provinceCode字段值 | 运单号: YB202607130001; 期望省份代码: 34 | 请求JSON中driverInfo.provinceCode="34"；不会出现值"28"；装货地行政区划代码前2位也为"34"（安徽省代码340000）；数据库/Redis/配置文件中无硬编码省份代码28 | [AI修正: 历史缺陷防御] - BUG-202607-04 | +| AH_REPORT_R1_007 | 平台端-监管上报-第一次上报 | 验证第一次上报失败后第二次上报接口被拒绝并返回错误码"前置上报未完成" | P0 | 功能测试 | 1. 运单YB202607130005第一次上报状态为"上传失败"（3次重试均失败）；2. 财务已完成打款（触发第二次上报的条件已满足） | 1. 通过API直接调用第二次上报接口（或模拟打款完成回调触发）；2. 查看接口返回的HTTP状态码和错误消息 | 运单号: YB202607130005 | 接口返回错误码（如HTTP 400或业务错误码"PRE_STAGE_NOT_COMPLETED"），错误消息包含"前置上报未完成"或"请先完成第一次上报"；第二次上报列表中该运单上报状态未变更，不会出现"上传中"或"已上传"；数据库report_record表无第二次上报的新记录 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R1_008 | 平台端-监管上报-第一次上报 | 验证第一次上报自动重试3次全部失败后第三次上报同样被拒绝 | P0 | 功能测试 | 1. 运单YB202607130006第一次上报3次重试全部失败；2. 第二次上报也未完成 | 1. 通过API直接调用第三次上报接口；2. 查看接口返回 | 运单号: YB202607130006 | 接口返回错误码，明确标识"前置上报（第一次）未完成"；后端通过查询运单上报状态表(如report_status)做校验，非仅依赖前端布尔值；第三次上报列表无该运单记录 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R1_009 | 平台端-监管上报-第一次上报 | 验证第一次上报成功后监管平台核验通过时自动调用修改字段接口 | P1 | 功能测试 | 1. 运单YB202607130001第一次上报成功且状态为"已上传"；2. 模拟监管平台返回核验通过 | 1. 等待或模拟监管平台核验通过回调；2. 查看上报日志中是否有"修改第一次上报部分字段"的接口调用记录；3. 查看修改后的字段值 | 运单号: YB202607130001; 实际运输里程: 158.5km（装货后变化值） | 上报日志中出现"修改字段"接口调用记录；修改的字段包含实际运输里程等装货后变化字段；修改成功后第一次上报状态仍保持"已上传"（绿色）；若修改接口调用失败，有重试和告警机制 | 对应TP-B-006 | +| AH_REPORT_R1_010 | 平台端-监管上报-第一次上报 | 验证第一次上报失败后自动重试最多3次且间隔递增 | P1 | 功能测试 | 1. 运单YB202607130007第一次上报时模拟监管平台返回失败 | 1. 触发第一次上报；2. 监控上报日志中的重试记录和时间间隔；3. 等待3次重试全部完成 | 运单号: YB202607130007; 重试间隔: 5s/15s/30s（参考值） | 第1次上报失败后自动触发第2次（间隔约5s）；第2次失败后触发第3次（间隔约15s）；第3次失败后触发第4次（即总共3次重试，间隔约30s）；3次重试全部失败后上报状态变为"上传失败"（红色标签），停止重试；上报日志中每1次请求（含重试）均有独立日志记录 | 对应TP-B-007 | +| AH_REPORT_R1_011 | 平台端-监管上报-第一次上报 | 验证第一次上报3次重试全部失败后通知运营人员 | P1 | 功能测试 | 1. 运单YB202607130008第一次上报3次重试均失败；2. super_admin账号可接收站内信 | 1. 等待3次重试全部失败；2. 使用super_admin登录管理端，查看站内信/消息通知；3. 点击通知中的链接 | 运单号: YB202607130008; 失败原因: 监管平台连接超时 | super_admin收到站内信通知，标题含"上报失败"标记；通知内容包含运单号YB202607130008、失败原因"连接超时"、失败时间；点击通知中的链接可直接跳转到该运单对应的上报详情页 | 对应TP-B-008 | +| AH_REPORT_R1_012 | 平台端-监管上报-第一次上报 | 验证上传失败状态下运营人员可点击手动上传按钮重新发起上报 | P1 | 功能测试 | 1. 运单YB202607130009上报状态为"上传失败"（红色标签）；2. 使用super_admin登录管理端 | 1. 进入"监管上报-第一次上报"列表；2. 找到YB202607130009，查看操作列；3. 点击"手动上传"按钮；4. 确认上传；5. 等待上传完成 | 运单号: YB202607130009 | 操作列显示"手动上传"按钮（仅上传失败状态可见）；点击后发起新的上报请求；上传成功后状态从"上传失败"（红色）变为"已上传"（绿色）；手动上传记录出现在上报日志中，标注操作人为"super_admin" | 对应TP-B-009 | +| AH_REPORT_R1_013 | 平台端-监管上报-第一次上报 | 验证自动重试期间点击手动上传时系统提示"上报处理中"并拒绝重复提交 | P0 | 功能测试 | 1. 运单YB202607130010第一次上报正在自动重试中（第1次已失败，第2次进行中）；2. 使用super_admin登录管理端 | 1. 进入第一次上报列表，找到该运单；2. 等待自动重试进行中时，快速点击"手动上传"按钮 | 运单号: YB202607130010 | 前端弹出提示"上报处理中，请勿重复操作"或按钮被置灰不可点击；后端返回"上报处理中"错误（分布式锁检测到正在进行中的上报）；数据库report_record表中该运单不会产生第2条上报记录；最终仅有1条上报记录（自动重试完成后产生） | [AI修正: 历史缺陷防御] - BUG-202607-02 | +| AH_REPORT_R1_014 | 平台端-监管上报-第一次上报 | 验证同一运单同一阶段快速连续点击手动上传仅发起1次请求 | P0 | 功能测试 | 1. 运单YB202607130011上报状态为"上传失败"；2. 使用super_admin登录管理端 | 1. 进入第一次上报列表；2. 快速连续点击"手动上传"按钮5次（模拟前端未做防抖的情况或快速双击）；3. 查看上报日志中实际发出的请求次数 | 运单号: YB202607130011; 快速点击5次 | 上报日志中仅记录1次上报请求（前端防抖+后端幂等键控制）；数据库report_record表仅产生1条新的上报记录；后端分布式锁或唯一约束（如运单号+阶段号）防止并发插入重复记录 | [AI修正: 历史缺陷防御] - BUG-202607-02 | +| AH_REPORT_R1_015 | 平台端-监管上报-第一次上报 | 验证第一次上报接口超时(>30s)后转为上传失败并触发重试 | P1 | 功能测试 | 1. 运单YB202607130012准备上报；2. 通过工具模拟监管平台接口响应延迟>30秒 | 1. 触发第一次上报；2. 观察前端页面Loading状态；3. 等待超时后的系统处理 | 运单号: YB202607130012; 超时阈值: 30s | 前端页面显示Loading加载状态并持续至超时；超时后上报状态变为"上传失败"（红色标签）；前端页面超时后有友好提示"上报超时，系统将自动重试"；系统自动触发第1次重试；数据库report_record表中记录超时状态 | 对应TP-B-015 | +| AH_REPORT_R1_016 | 平台端-监管上报-第一次上报 | 验证弱网环境(高延迟高丢包)下第一次上报重试机制正常工作 | P2 | 功能测试 | 1. 通过Charles/Fiddler或网络模拟工具设置网络延迟2000ms、丢包率30%；2. 运单YB202607130013待上报 | 1. 在弱网条件下触发第一次上报；2. 观察上报请求发送和响应情况；3. 等待重试或恢复 | 运单号: YB202607130013; 网络延迟: 2000ms; 丢包率: 30% | 请求发送成功但响应延迟时不立即判定失败（超时阈值30s）；弱网恢复后若重试成功则状态正常流转为"已上传"；断网时上报请求发送失败的提示友好明确；不论弱网还是正常网络，数据不会出现不一致或重复 | 对应TP-B-016 | +| AH_REPORT_R1_017 | 平台端-监管上报-第一次上报 | 验证10个运单同时装货完成时并发上报互不干扰 | P2 | 性能测试 | 1. 准备10条安徽税源地(34)的运单YB202607130014~YB202607130023，状态均为"待装货" | 1. 通过脚本同时触发10条运单的装货完成事件；2. 监控数据库和上报日志；3. 验证每条运单的上报状态 | 10条运单同时装货完成 | 10条运单各自独立触发上报，无相互阻塞；数据库无死锁(deadlock)异常；上报日志中每条运单独立记录其上报请求和响应；每条运单的上报状态独立正确更新 | 对应TP-B-017 | +| AH_REPORT_R1_018 | 平台端-监管上报-第一次上报 | 验证第一次上报可选字段（委托合同编号/运输里程/挂车牌照号等）为空时正常上报 | P3 | 功能测试 | 1. 准备一条运单YB202607130024，可选字段全部留空：委托合同编号、运输里程、挂车牌照号、行驶证档案编号、道路运输证有效期起/至、保险单号、保险公司名称 | 1. 触发该运单装货完成事件；2. 查看上报结果；3. 查看上报请求JSON和详情弹窗 | 运单号: YB202607130024; 可选字段全为空 | 上报接口不报错，上报成功；请求JSON中可选字段值为null或不传均可正常处理；管理端详情弹窗中可选字段显示"-"而非"null"或"undefined" | 对应TP-B-018 | +| AH_REPORT_R1_019 | 平台端-监管上报-第一次上报 | 验证运单包含1条货物记录时正常上报 | P3 | 功能测试 | 1. 准备运单YB202607130025，仅含1条货物：货物名称"钢材"、货物类型代码"01"、货物量"10.5"、计量单位"吨" | 1. 触发装货完成；2. 查看上报请求JSON中goodsInfos数组；3. 查看详情弹窗货物信息展示 | 运单号: YB202607130025; 货物: 钢材 10.5吨 | goodsInfos数组包含1个元素，4个字段完整；详情弹窗中货物信息分组正确展示1条记录 | 对应TP-B-019 | +| AH_REPORT_R1_020 | 平台端-监管上报-第一次上报 | 验证运单包含5条货物记录时各货物独立完整上报 | P3 | 功能测试 | 1. 准备运单YB202607130026，含5条货物记录：钢材10.5吨、水泥20吨、砂石15吨、砖块5000块、木材8立方 | 1. 触发装货完成；2. 查看上报请求JSON中goodsInfos数组长度和内容；3. 查看详情弹窗中多条货物的展示 | 运单号: YB202607130026; 货物: 5条 | goodsInfos数组包含5个元素；每条货物独立完整，互不影响；详情弹窗中货物信息支持展开/折叠展示5条记录；每条货物名称、类型代码、货物量、计量单位均正确 | 对应TP-B-019 | +| AH_REPORT_R1_021 | 平台端-监管上报-第一次上报 | 验证第一次上报业务类型代码和运输组货方式代码为有效枚举值 | P1 | 功能测试 | 1. 准备运单YB202607130027，业务类型代码为"1"(普通货运)、运输组货方式代码为"10"(道路货运) | 1. 触发装货完成上报；2. 查看上报请求JSON中waybillInfo的businessTypeCode和transportGroupModeCode字段值；3. 模拟提交无效枚举值（如"99"），验证拒绝 | 运单号: YB202607130027; businessTypeCode: 1; transportGroupModeCode: 10 | 有效枚举值上报成功；无效枚举值（如businessTypeCode="99"）上报时接口返回校验错误，明确提示"业务类型代码无效"；不会将无效枚举值上报至监管平台 | 对应TP-B-003 | +| AH_REPORT_R1_022 | 平台端-监管上报-第一次上报 | 验证第一次上报详情弹窗—异常信息分组展示核验状态/异常原因/异常时间/处理状态 | P2 | 功能测试 | 1. 运单YB202607130028第一次上报核验状态为"异常"；2. 使用super_admin登录管理端 | 1. 进入第一次上报列表，点击运单YB202607130028的"详情"按钮；2. 查看弹窗中"异常信息"分组的4个字段 | 运单号: YB202607130028; 异常原因示例: 司机资质核验不通过 | 异常信息分组包含: 核验状态（显示"异常"）、异常原因（如"司机从业资格证已过期"）、异常时间（显示实际核验时间）、处理状态（如"未申诉"）；核验通过时异常原因为空 | 对应TP-B-013 | +| AH_REPORT_R1_023 | 平台端-监管上报-第一次上报 | 验证第一次上报状态标签颜色：上传中=蓝色、已上传=绿色、上传失败=红色、异常=橙色 | P2 | 功能测试 | 1. 准备4条运单各处于不同上报状态 | 1. 进入第一次上报列表；2. 依次查看4种状态运单的标签颜色 | 运单A: 上传中; 运单B: 已上传; 运单C: 上传失败; 运单D: 异常 | 上传中=蓝色标签+加载动画；已上传=绿色标签；上传失败=红色标签；异常=橙色标签；状态切换时标签颜色即时更新不闪烁 | 对应TP-B-010 | +| AH_REPORT_R1_024 | 平台端-监管上报-第一次上报 | 验证第一次上报列表14个字段完整展示且顺序正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 第一次上报列表中有至少1条完整记录 | 1. 进入"监管上报-第一次上报"列表；2. 查看列表表头和第一条数据的所有列内容；3. 验证每个字段的展示格式 | 运单号: YB202607130001; 运输里程: 350km; 合同编号: HT202607001 | 列表展示14个字段: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/业务类型/货物名称/装货地址/卸货地址/运输里程/合同编号/上报状态/操作；业务类型与数据字典中枚举值一致；装货地址和卸货地址完整展示（省市区+详细地址）；运输里程带单位km；上报状态标签颜色符合规范（上传中=蓝色/已上传=绿色/上传失败=红色/异常=橙色）；列表按上报时间倒序排列 | 对应TP-B-020；[AI修正: 覆盖缺口补充] | + +--- + +## 模块C: 第二次上报-打款完成 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_R2_001 | 平台端-监管上报-第二次上报 | 验证财务打款完成后自动触发第二次上报且包含资金流水和车辆轨迹信息 | P0 | 功能测试 | 1. 运单YB202607130001已完成第一次上报且状态为"已上传"；2. 财务在账户管理模块对该运单执行打款操作，金额¥10,000.00 | 1. 财务完成打款操作；2. 系统收到打款完成回调；3. 进入管理端"监管上报-第二次上报"列表查看 | 运单号: YB202607130001; 打款金额: ¥10,000.00; 付款方式: 光大银行 | 第二次上报列表中新增该运单记录，上报状态从"上传中"变为"已上传"（绿色标签）；上报请求包含运单信息+资金流水信息+车辆轨迹信息三个模块；数据库report_record表新增第二次上报记录，stage=2 | 对应TP-C-001 | +| AH_REPORT_R2_002 | 平台端-监管上报-第二次上报 | 验证第二次上报资金流水数据来源于支付流水表（非运单缓存） | P0 | 功能测试 | 1. 运单YB202607130001合同金额¥10,000.00；2. 支付流水表实际打款金额¥10,000.00；3. 财务已打款完成 | 1. 触发第二次上报；2. 查询上报日志中的请求JSON；3. 对比请求中的金额与运单表合同金额、支付流水表打款金额；4. 检查数据库查询SQL日志确认数据来源 | 运单号: YB202607130001; 合同金额: ¥10,000.00; 支付流水实际打款: ¥10,000.00 | 上报数据中的金额与支付流水表实际打款金额¥10,000.00完全一致；数据库查询SQL日志显示数据源为payment_flow表，非waybill表或Redis缓存；金额精确到分（2位小数），¥10,000.00无精度丢失 | [AI修正: 历史缺陷防御] - BUG-202607-03 | +| AH_REPORT_R2_003 | 平台端-监管上报-第二次上报 | 验证财务修改打款金额后第二次上报使用最新金额（非缓存合同金额） | P0 | 功能测试 | 1. 运单YB202607130001合同金额¥10,000.00；2. 财务在账户管理模块调账将打款金额修改为¥9,500.00；3. 财务执行打款 | 1. 财务修改打款金额（¥10,000.00→¥9,500.00）；2. 财务完成打款；3. 触发第二次上报；4. 查看上报请求中的金额字段 | 运单号: YB202607130001; 合同金额: ¥10,000.00; 修改后打款金额: ¥9,500.00 | 上报请求中的金额为¥9,500.00（修改后的值），非¥10,000.00（合同金额）；上报日志中可溯源金额来源为支付流水表；不会使用装货完成时缓存的合同金额¥10,000.00 | [AI修正: 历史缺陷防御] - BUG-202607-03 | +| AH_REPORT_R2_004 | 平台端-监管上报-第二次上报 | 验证第二次上报列表17个字段完整且收款账号类型标签颜色正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 第二次上报列表中有至少2条数据（一条个人账户、一条对公账户） | 1. 进入"监管上报-第二次上报"列表；2. 查看列表表头和第一条数据的各列内容；3. 查看收款账号类型列的标签颜色 | 运单A: 个人账户(司机银行卡); 运单B: 对公账户(企业账号) | 列表展示: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/承运运费/总金额/付款方式/付款时间/收款人/收款账号/收款账号类型/核验状态/异常项/上报状态/操作；承运运费和总金额保留2位小数；付款时间为实际财务打款时间；个人账户显示蓝色标签，对公账户显示绿色标签 | 对应TP-C-004; TP-C-005 | +| AH_REPORT_R2_005 | 平台端-监管上报-第二次上报 | 验证运单重复核验—首次上报的运单核验通过 | P0 | 功能测试 | 1. 运单YB202607130001为首次进行第二次上报，此前未在任何阶段重复上报 | 1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项 | 运单号: YB202607130001(首次上报) | 核验状态标记为"通过"（绿色标签）；异常项列中无"运单重复核验"异常记录；监管平台返回的核验结果中duplicateCheck=pass；数据库运单核验记录表verification_result中duplicate_check_status='pass' | 对应TP-C-006 | +| AH_REPORT_R2_006 | 平台端-监管上报-第二次上报 | 验证运单重复核验—重复上报检测到异常并标注异常项 | P0 | 功能测试 | 1. 运单YB202607130001已成功完成第二次上报和核验；2. 模拟或真实触发该运单的第二次重复上报 | 1. 通过API再次调用第二次上报接口（使用同一运单号YB202607130001）；2. 等待监管平台核验结果返回 | 运单号: YB202607130001(重复上报) | 核验状态变为"异常"（橙色标签）；异常项列明确标注"运单重复核验"；异常原因可读（如"该运单已存在有效上报记录"）；该异常运单可触发申诉流程，"申诉"按钮可见可用 | 对应TP-C-007 | +| AH_REPORT_R2_007 | 平台端-监管上报-第二次上报 | 验证车辆资质核验—道路运输证在有效期内核验通过 | P1 | 功能测试 | 1. 运单YB202607130001关联的车辆道路运输证有效期起: 2025-01-01, 有效期至: 2027-01-01（当前日期2026-07-13在有效期内）；2. 车辆审核状态为"通过" | 1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项 | 运单号: YB202607130001; 道路运输证有效期: 2025-01-01~2027-01-01 | 核验状态为"通过"；无"车辆资质核验"异常项；监管平台返回vehicleQualCheck=pass；数据库verification_result.vehicle_qual_status='pass' | 对应TP-C-008 | +| AH_REPORT_R2_008 | 平台端-监管上报-第二次上报 | 验证车辆资质核验—道路运输证已过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130029关联的车辆道路运输证有效期至: 2025-12-31（当前日期2026-07-13已过期）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果返回；3. 查看异常项详情 | 运单号: YB202607130029; 道路运输证有效期至: 2025-12-31(已过期) | 核验状态变为"异常"（橙色标签）；异常项列标注"车辆资质核验"；异常原因描述如"道路运输证已过期（有效期至2025-12-31）"；该异常运单可发起申诉 | 对应TP-C-009 | +| AH_REPORT_R2_009 | 平台端-监管上报-第二次上报 | 验证司机资质核验—从业资格证在有效期内核验通过 | P1 | 功能测试 | 1. 运单YB202607130001关联的司机从业资格证有效期起: 2024-06-01, 有效期至: 2028-06-01（在有效期内）；2. 司机审核状态为"通过" | 1. 触发第二次上报；2. 等待核验结果；3. 查看核验状态 | 运单号: YB202607130001; 从业资格证: 有效期内 | 核验状态为"通过"；无"司机资质核验"异常项；监管平台返回driverQualCheck=pass | 对应TP-C-010 | +| AH_REPORT_R2_010 | 平台端-监管上报-第二次上报 | 验证司机资质核验—从业资格证已过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130030关联的司机从业资格证有效期至: 2025-01-01（已过期）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果；3. 查看异常项 | 运单号: YB202607130030; 从业资格证有效期至: 2025-01-01(已过期) | 核验状态变为"异常"；异常项标注"司机资质核验"；异常原因如"司机从业资格证已过期"；可发起申诉 | 对应TP-C-011 | +| AH_REPORT_R2_011 | 平台端-监管上报-第二次上报 | 验证集中支付核验—付款方为平台统一账户时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001打款付款方为网货平台统一账户；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130001; 付款方: 网货平台统一账户 | 核验状态为"通过"；无"集中支付核验"异常项；监管平台返回centralPayCheck=pass；支付流水记录与集中支付模式匹配 | 对应TP-C-012 | +| AH_REPORT_R2_012 | 平台端-监管上报-第二次上报 | 验证集中支付核验—付款方非平台统一账户时核验异常 | P1 | 功能测试 | 1. 运单YB202607130031打款付款方为非平台统一账户（如第三方代付账户）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130031; 付款方: 第三方代付账户(非平台) | 核验状态变为"异常"；异常项标注"集中支付核验"；异常原因如"付款方非集中支付账户"；可发起申诉 | 对应TP-C-013 | +| AH_REPORT_R2_013 | 平台端-监管上报-第二次上报 | 验证资金流水核验—流水号唯一且金额匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001资金流水号唯一（如PAY202607130001）；2. 上报金额¥10,000.00与支付流水表实际打款金额完全一致 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130001; 流水号: PAY202607130001; 金额: ¥10,000.00 | 核验状态为"通过"；无"资金流水核验"异常项；监管平台返回fundFlowCheck=pass | 对应TP-C-014 | +| AH_REPORT_R2_014 | 平台端-监管上报-第二次上报 | 验证资金流水核验—流水号重复时核验异常 | P1 | 功能测试 | 1. 运单YB202607130032使用的资金流水号与已有运单的流水号重复（如均使用PAY202607130001） | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130032; 重复流水号: PAY202607130001 | 核验状态变为"异常"；异常项标注"资金流水核验"；异常原因包含"流水号重复"提示；可发起申诉 | 对应TP-C-015 | +| AH_REPORT_R2_015 | 平台端-监管上报-第二次上报 | 验证资金流水核验—上报金额与支付流水偏差>0.01元时核验异常 | P1 | 功能测试 | 1. 运单YB202607130033支付流水表实际打款¥9,500.00，但上报时发送¥10,000.00（偏差¥500.00>¥0.01） | 1. 触发第二次上报（携带错误金额）；2. 等待核验结果 | 运单号: YB202607130033; 上报金额: ¥10,000.00; 支付流水实际: ¥9,500.00 | 核验状态变为"异常"；异常项标注"资金流水核验"；异常原因包含"金额不匹配"提示；可发起申诉 | 对应TP-C-015 | +| AH_REPORT_R2_016 | 平台端-监管上报-第二次上报 | 验证合同核验—承运合同和委托合同均有效时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001承运合同编号CTC202607001有效（存在于合同管理系统，有效期覆盖运单执行日期2026-07-10~2026-07-13）；2. 委托合同编号DLC202607001有效（如适用） | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130001; 承运合同: CTC202607001(有效); 委托合同: DLC202607001(有效) | 核验状态为"通过"；无"合同核验"异常项；监管平台返回contractCheck=pass | 对应TP-C-016 | +| AH_REPORT_R2_017 | 平台端-监管上报-第二次上报 | 验证合同核验—承运合同不存在时核验异常 | P1 | 功能测试 | 1. 运单YB202607130034关联的承运合同编号INVALID_CTC999不存在于合同管理系统 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130034; 承运合同: INVALID_CTC999(不存在) | 核验状态变为"异常"；异常项标注"合同核验"；异常原因包含"承运合同不存在"提示；可发起申诉 | 对应TP-C-017 | +| AH_REPORT_R2_018 | 平台端-监管上报-第二次上报 | 验证合同核验—合同有效期不覆盖运单执行日期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130035执行日期为2026-07-10~2026-07-13，但关联的承运合同有效期至2026-06-30（已过期不覆盖运单执行日期） | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130035; 承运合同有效期: ~2026-06-30(不覆盖运单日期) | 核验状态变为"异常"；异常项标注"合同核验"；异常原因包含"合同已过期"或"合同有效期不覆盖运单执行日期"；可发起申诉 | 对应TP-C-017 | +| AH_REPORT_R2_019 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点≥2且≤2000且路线匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001车辆GPS轨迹包含500个有效轨迹点；2. 轨迹路线与装货地→卸货地路线基本一致；3. 轨迹时间与运单执行时间匹配 | 1. 触发第二次上报（携带500点轨迹数据）；2. 等待核验结果 | 运单号: YB202607130001; 轨迹点数: 500 | 核验状态为"通过"；无"车辆轨迹合规核验"异常项；监管平台返回trackCheck=pass | 对应TP-C-018 | +| AH_REPORT_R2_020 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点边界值2个点时核验通过 | P2 | 功能测试 | 1. 运单YB202607130036车辆GPS轨迹仅包含2个有效轨迹点（起终点，边界最小值） | 1. 触发第二次上报（携带2点轨迹数据）；2. 等待核验结果 | 运单号: YB202607130036; 轨迹点数: 2(边界最小值) | 核验状态为"通过"；无"车辆轨迹合规核验"异常项；边界值2个点被正确处理 | 对应TP-C-018 | +| AH_REPORT_R2_021 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点边界值2000个点时核验通过 | P2 | 功能测试 | 1. 运单YB202607130037车辆GPS轨迹包含恰好2000个有效轨迹点（边界最大值） | 1. 触发第二次上报（携带2000点轨迹数据）；2. 等待核验结果；3. 验证2000点数据完整传输 | 运单号: YB202607130037; 轨迹点数: 2000(边界最大值) | 核验状态为"通过"；2000个轨迹点全部成功上报，无截断；页面响应不卡顿 | 对应TP-C-018 | +| AH_REPORT_R2_022 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点<2个(仅1个点)时核验异常 | P1 | 功能测试 | 1. 运单YB202607130038车辆GPS轨迹仅包含1个有效轨迹点 | 1. 触发第二次上报（携带1点轨迹数据）；2. 等待核验结果 | 运单号: YB202607130038; 轨迹点数: 1(不足) | 核验状态变为"异常"；异常项标注"车辆轨迹合规核验"；异常原因包含"轨迹点数量不足（至少需要2个点）"；可进入"补传轨迹"流程 | 对应TP-C-019 | +| AH_REPORT_R2_023 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点=0(无轨迹数据)时核验异常 | P1 | 功能测试 | 1. 运单YB202607130039无GPS轨迹数据（轨迹点=0） | 1. 触发第二次上报（轨迹数据为空）；2. 等待核验结果 | 运单号: YB202607130039; 轨迹点数: 0 | 核验状态变为"异常"；异常项标注"车辆轨迹合规核验"；异常原因包含"轨迹数据缺失"；可进入"补传轨迹"流程 | 对应TP-C-019 | +| AH_REPORT_R2_024 | 平台端-监管上报-第二次上报 | 验证第二次上报依赖第一次上报完成—第一次上报失败时第二次上报被拒绝 | P0 | 功能测试 | 1. 运单YB202607130005第一次上报状态为"上传失败"；2. 财务对该运单完成打款操作 | 1. 打款完成回调触发第二次上报；2. 查看第二次上报接口返回；3. 查看第二次上报列表 | 运单号: YB202607130005(第一次上报失败) | 第二次上报接口返回错误，错误码标识"前置上报未完成"或"请先完成第一次上报"；第二次上报列表中无该运单记录或状态未更新；后端通过查询report_status表校验第一次上报完成状态；错误消息清晰可理解 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R2_025 | 平台端-监管上报-第二次上报 | 验证第二次上报幂等性—自动重试期间禁止手动触发 | P0 | 功能测试 | 1. 运单YB202607130001第二次上报正在自动重试中；2. 使用super_admin登录管理端 | 1. 进入第二次上报列表；2. 在自动重试进行中找到该运单；3. 尝试点击"手动上传"按钮或直接调用上报API | 运单号: YB202607130001(自动重试进行中) | 前端"手动上传"按钮不可见或被置灰（仅"上传失败"状态可见）；若通过API直接调用，返回"上报处理中"错误（分布式锁检测）；同一运单第二次上报仅产生1条有效记录；数据库unique约束（运单号+stage=2）防止重复插入 | [AI修正: 历史缺陷防御] - BUG-202607-02 | +| AH_REPORT_R2_026 | 平台端-监管上报-第二次上报 | 验证轨迹核验异常运单的补传轨迹功能—补传后重新核验通过 | P1 | 功能测试 | 1. 运单YB202607130038第二次上报轨迹核验异常（轨迹点仅1个）；2. 运营人员准备补充的GPS轨迹数据（200个点） | 1. 进入第二次上报列表，找到轨迹异常运单；2. 点击操作列"补传轨迹"按钮；3. 上传补充的200个轨迹点数据文件；4. 提交补传；5. 等待重新核验结果 | 运单号: YB202607130038; 原始轨迹点: 1; 补传轨迹点: 200 | 仅轨迹核验异常的运单显示"补传轨迹"按钮；补传提交后系统重新触发轨迹核验；核验通过后异常项"车辆轨迹合规核验"消除，核验状态变为"通过"；补传操作在上报日志中独立记录；补传的200个轨迹点数据覆盖原有的1个点数据 | 对应TP-C-022 | +| AH_REPORT_R2_027 | 平台端-监管上报-第二次上报 | 验证第二次上报失败后自动重试机制—最多3次、间隔递增、全部失败后告警 | P1 | 功能测试 | 1. 运单YB202607130060触发第二次上报；2. 模拟监管平台接口超时（不返回/30s超时） | 1. 触发第二次上报（超时失败）；2. 等待系统自动重试；3. 查看上报日志中每次重试的记录；4. 模拟连续3次重试均失败；5. 查看告警通知 | 运单号: YB202607130060; 重试间隔: 5s/15s/30s(参考值) | 上报失败后系统自动触发第1次重试（约5s后）；第1次失败→第2次重试（约15s后）；第2次失败→第3次重试（约30s后）；每次重试在上报日志中独立记录（共4条: 1次原始+3次重试）；3次全部失败后系统通过站内信或短信告警通知运营人员；上报状态变更为"上传失败"（红色标签），"手动上传"按钮可见可用；重试期间手动上传按钮不可用或置灰显示"上报处理中" | [AI修正: 历史缺陷防御] - BUG-202607-02；对应TP-C-023 | +| AH_REPORT_R2_028 | 平台端-监管上报-第二次上报 | 验证第二次上报详情弹窗资金流水10字段与车辆轨迹6字段分组完整展示 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001第二次上报已完成且含完整资金流水和车辆轨迹数据 | 1. 进入第二次上报列表；2. 点击运单YB202607130001的"详情"按钮；3. 查看"资金流水信息"分组的字段；4. 查看"车辆轨迹信息"分组的字段 | 运单号: YB202607130001; 资金流水: 含完整支付信息; 车辆轨迹: 含150个点位 | 资金流水信息分组完整展示10字段: 支付金额/支付方式/支付时间/付款方名称/收款方名称/收款人/收款账号/收款账号类型/流水号/支付状态；车辆轨迹信息分组完整展示6字段: 定位类型/定位时间/定位地点/经度/纬度/轨迹类型；轨迹列表支持分页浏览（150个点分页展示）；可选字段缺失时显示"-"或"无"而不展示空白；弹窗分组标签和顺序正确: 运单信息→托运方信息→收货方信息→资金流水信息→车辆轨迹信息→异常信息 | 对应TP-C-024；[AI修正: 覆盖缺口补充] | + +| AH_REPORT_R2_029 | 平台端-监管上报-第二次上报 | 验证里程申诉功能—提交里程申诉接口正常 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130058存在里程数据异常（如实际里程与上报里程偏差>20%） | 1. 进入第二次上报详情页；2. 点击"里程申诉"按钮；3. 填写申诉内容"GPS里程与实际里程偏差"、投诉编号"CMP202607130001"、申诉里程"350"；4. 提交 | 运单号: YB202607130058; 申诉里程: 350km; 投诉编号: CMP202607130001 | 里程申诉提交成功，接口POST /mileageAppeal/insert返回成功响应；申诉记录中新增里程申诉记录；申诉内容、投诉编号、申诉里程字段均正确保存；缺少必选参数时接口返回明确错误提示（如"运单号不能为空"）；里程申诉与异常项申诉独立管理互不干扰 | 对应TP-C-025；[技术方案] API新增接口 | +| AH_REPORT_R2_030 | 平台端-监管上报-第二次上报 | 验证委托合同核验(100)—合同有效且覆盖运单日期时核验通过 | P1 | 功能测试 | 1. 运单YB202607130059委托合同编号DLC202607001有效且存在于合同管理系统；2. 委托合同有效期2026-01-01~2026-12-31覆盖运单执行日期2026-07-10~2026-07-13；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项 | 运单号: YB202607130059; 委托合同: DLC202607001(有效) | 核验状态为"通过"；无"委托合同核验"（代码100）异常项；abnormalDetails中不存在id=100的记录 | 对应TP-C-026；[技术方案] API文档§4.1 | +| AH_REPORT_R2_031 | 平台端-监管上报-第二次上报 | 验证委托合同核验(100)—合同不存在或过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130060委托合同编号INVALID_DLC999不存在于合同管理系统；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果返回；3. 查看异常项详情 | 运单号: YB202607130060; 委托合同: INVALID_DLC999(不存在) | 核验状态变为"异常"；异常项标注"委托合同核验"（代码100）；异常原因包含"委托合同不存在"或"委托合同已过期"；可发起申诉 | 对应TP-C-027；[技术方案] API文档§4.1 | +| AH_REPORT_R2_032 | 平台端-监管上报-第二次上报 | 验证承运合同核验(120)—合同有效且覆盖运单日期时核验通过 | P1 | 功能测试 | 1. 运单YB202607130061承运合同编号CTC202607001有效且存在于合同管理系统；2. 承运合同有效期2026-01-01~2026-12-31覆盖运单执行日期；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130061; 承运合同: CTC202607001(有效) | 核验状态为"通过"；无"承运合同核验"（代码120）异常项；abnormalDetails中不存在id=120的记录 | 对应TP-C-028；[技术方案] API文档§4.1 | +| AH_REPORT_R2_033 | 平台端-监管上报-第二次上报 | 验证承运合同核验(120)—合同不存在或过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130062承运合同编号INVALID_CTC888不存在于合同管理系统；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130062; 承运合同: INVALID_CTC888(不存在) | 核验状态变为"异常"；异常项标注"承运合同核验"（代码120）；异常原因包含"承运合同不存在"或"承运合同已过期"；可发起申诉 | 对应TP-C-029；[技术方案] API文档§4.1 | +| AH_REPORT_R2_034 | 平台端-监管上报-第二次上报 | 验证实时定位核验(130)—运单执行期间有完整实时定位数据时核验通过 | P1 | 功能测试 | 1. 运单YB202607130063在运输期间（2026-07-10 08:00~2026-07-13 18:00）有持续完整的GPS实时定位数据；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130063; 定位时间范围: 完整覆盖运输期间 | 核验状态为"通过"；无"实时定位核验"（代码130）异常项 | 对应TP-C-030；[技术方案] API文档§4.1 | +| AH_REPORT_R2_035 | 平台端-监管上报-第二次上报 | 验证实时定位核验(130)—运输期间定位数据长时间中断时核验异常 | P1 | 功能测试 | 1. 运单YB202607130064运输期间（2026-07-10~2026-07-13）GPS定位数据在2026-07-11~2026-07-12期间中断超过24小时；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130064; 定位中断: 2026-07-11~2026-07-12(约24小时) | 核验状态变为"异常"；异常项标注"实时定位核验"（代码130）；异常原因包含"实时定位数据长时间中断"；可发起申诉或补充定位数据 | 对应TP-C-031；[技术方案] API文档§4.1 | +| AH_REPORT_R2_036 | 平台端-监管上报-第二次上报 | 验证运单时间逻辑核验(140)—各时间节点逻辑合理时核验通过 | P1 | 功能测试 | 1. 运单YB202607130065时间节点合理：建单2026-07-09→接单2026-07-10 08:00→起运2026-07-10 10:00→送达2026-07-13 16:00；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130065; 时间序列: 建单→接单→起运→送达(合理) | 核验状态为"通过"；无"运单时间逻辑核验"（代码140）异常项 | 对应TP-C-032；[技术方案] API文档§4.1 | +| AH_REPORT_R2_037 | 平台端-监管上报-第二次上报 | 验证运单时间逻辑核验(140)—送达时间早于起运时间时核验异常 | P1 | 功能测试 | 1. 运单YB202607130066时间节点矛盾：起运2026-07-13 10:00→送达2026-07-12 16:00（送达早于起运）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130066; 时间倒置: 送达(07-12)早于起运(07-13) | 核验状态变为"异常"；异常项标注"运单时间逻辑核验"（代码140）；异常原因包含"送达时间早于起运时间"；可发起申诉 | 对应TP-C-033；[技术方案] API文档§4.1 | +| AH_REPORT_R2_038 | 平台端-监管上报-第二次上报 | 验证道路运输证核验(160)—有效期和证号均有效时核验通过 | P1 | 功能测试 | 1. 运单YB202607130067车辆道路运输证号RTC202501001有效，有效期2025-03-01~2027-03-01（当前日期2026-07-13在有效期内）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130067; 道路运输证号: RTC202501001(有效) | 核验状态为"通过"；无"道路运输证核验"（代码160）异常项 | 对应TP-C-034；[技术方案] API文档§4.1 | +| AH_REPORT_R2_039 | 平台端-监管上报-第二次上报 | 验证道路运输证核验(160)—证号在运政系统查询不存在时核验异常 | P1 | 功能测试 | 1. 运单YB202607130068车辆道路运输证号INVALID_RTC999在运政系统中查询不存在；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130068; 道路运输证号: INVALID_RTC999(不存在) | 核验状态变为"异常"；异常项标注"道路运输证核验"（代码160）；异常原因包含"道路运输证不存在"；可发起申诉 | 对应TP-C-035；[技术方案] API文档§4.1 | +| AH_REPORT_R2_040 | 平台端-监管上报-第二次上报 | 验证驾驶证核验(170)—驾驶证有效且准驾车型匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130069司机驾驶证号DL202501001有效，有效期2024-01-01~2030-01-01，准驾车型B2（与重型货车匹配）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130069; 驾驶证号: DL202501001(有效); 准驾车型: B2(匹配) | 核验状态为"通过"；无"驾驶证核验"（代码170）异常项 | 对应TP-C-036；[技术方案] API文档§4.1 | +| AH_REPORT_R2_041 | 平台端-监管上报-第二次上报 | 验证驾驶证核验(170)—驾驶证已过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130070司机驾驶证有效期至2025-12-31（当前日期2026-07-13已过期）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130070; 驾驶证有效期至: 2025-12-31(已过期) | 核验状态变为"异常"；异常项标注"驾驶证核验"（代码170）；异常原因包含"驾驶证已过期"；可发起申诉 | 对应TP-C-037；[技术方案] API文档§4.1 | +| AH_REPORT_R2_042 | 平台端-监管上报-第二次上报 | 验证车辆重复核验(190)—车辆无时间重叠运单时核验通过 | P1 | 功能测试 | 1. 运单YB202607130071车辆云A12345在运单执行时段2026-07-10~2026-07-13内无其他运单；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130071; 车辆: 云A12345(无时间重叠) | 核验状态为"通过"；无"车辆重复核验"（代码190）异常项 | 对应TP-C-038；[技术方案] API文档§4.1 | +| AH_REPORT_R2_043 | 平台端-监管上报-第二次上报 | 验证车辆重复核验(190)—同一车辆同时用于两个时间重叠运单时核验异常 | P1 | 功能测试 | 1. 车辆云A12345同时出现在运单YB202607130072（执行时段2026-07-10~2026-07-13）和运单YB202607130073（执行时段2026-07-11~2026-07-14）中，时间重叠2天；2. 第一次上报已完成 | 1. 分别触发两个运单的第二次上报；2. 查看核验结果 | 运单A: YB202607130072(07-10~07-13); 运单B: YB202607130073(07-11~07-14); 重叠: 07-11~07-13 | 至少一个运单核验状态变为"异常"；异常项标注"车辆重复核验"（代码190）；异常原因包含"车辆在运单执行期间存在时间重叠"；可发起申诉 | 对应TP-C-039；[技术方案] API文档§4.1 | +| AH_REPORT_R2_044 | 平台端-监管上报-第二次上报 | 验证司机重复核验(200)—司机无时间重叠运单时核验通过 | P1 | 功能测试 | 1. 运单YB202607130074司机张三(身份证510101199001011234)在运单执行时段2026-07-10~2026-07-13内无其他运单；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130074; 司机: 张三(无时间重叠) | 核验状态为"通过"；无"司机重复核验"（代码200）异常项 | 对应TP-C-040；[技术方案] API文档§4.1 | +| AH_REPORT_R2_045 | 平台端-监管上报-第二次上报 | 验证司机重复核验(200)—同一司机同时执行两个时间重叠运单时核验异常 | P1 | 功能测试 | 1. 司机张三同时被分配给运单YB202607130075（执行时段2026-07-10~2026-07-13）和运单YB202607130076（执行时段2026-07-12~2026-07-15），时间重叠2天；2. 第一次上报已完成 | 1. 分别触发两个运单的第二次上报；2. 查看核验结果 | 运单A: YB202607130075(07-10~07-13); 运单B: YB202607130076(07-12~07-15); 司机: 张三(重叠) | 至少一个运单核验状态变为"异常"；异常项标注"司机重复核验"（代码200）；异常原因包含"司机在运单执行期间存在时间重叠"；可发起申诉 | 对应TP-C-041；[技术方案] API文档§4.1 | +| AH_REPORT_R2_046 | 平台端-监管上报-第二次上报 | 验证运费收款核验(220)—收款人与司机一致且金额匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130077收款人张三与司机张三一致（身份证号510101199001011234匹配）；2. 收款金额¥10,000.00与运单运费一致；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130077; 收款人: 张三(与司机一致); 收款金额: ¥10,000.00 | 核验状态为"通过"；无"运费收款核验"（代码220）异常项 | 对应TP-C-042；[技术方案] API文档§4.1 | +| AH_REPORT_R2_047 | 平台端-监管上报-第二次上报 | 验证运费收款核验(220)—收款人与司机身份证号不一致时核验异常 | P1 | 功能测试 | 1. 运单YB202607130078司机为张三(身份证510101199001011234)，但收款人为李四(身份证510101199002022345)，两者不一致；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130078; 司机: 张三; 收款人: 李四(不一致) | 核验状态变为"异常"；异常项标注"运费收款核验"（代码220）；异常原因包含"收款人与司机信息不一致"；可发起申诉 | 对应TP-C-043；[技术方案] API文档§4.1 | +| AH_REPORT_R2_048 | 平台端-监管上报-第二次上报 | 验证公司统一收款核验(230)—收款公司信息与托运方一致时核验通过 | P1 | 功能测试 | 1. 运单YB202607130079收款公司为"安徽XX物流有限公司"(统一社会信用代码9134XXXXXXXXXXXXXX)，与托运方信息完全一致；2. 收款账户已在系统中备案；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130079; 收款公司: 安徽XX物流有限公司(与托运方一致) | 核验状态为"通过"；无"公司统一收款核验"（代码230）异常项 | 对应TP-C-044；[技术方案] API文档§4.1 | +| AH_REPORT_R2_049 | 平台端-监管上报-第二次上报 | 验证公司统一收款核验(230)—收款公司统一社会信用代码与托运方不一致时核验异常 | P1 | 功能测试 | 1. 运单YB202607130080托运方为"安徽XX物流有限公司"，但收款公司为"安徽YY运输有限公司"，统一社会信用代码不一致；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130080; 托运方: 安徽XX物流; 收款公司: 安徽YY运输(不一致) | 核验状态变为"异常"；异常项标注"公司统一收款核验"（代码230）；异常原因包含"收款公司信息与托运方不一致"；可发起申诉 | 对应TP-C-045；[技术方案] API文档§4.1 | +| AH_REPORT_R2_050 | 平台端-监管上报-第二次上报 | 验证发票信息核验(260)—发票号码/代码有效且信息完整时核验通过 | P1 | 功能测试 | 1. 运单YB202607130081关联的发票FP202607130081在税务系统中可查询且状态正常；2. 发票销售方和受票方信息完整；3. 第一次/第二次上报已完成 | 1. 触发第三次上报后等待发票核验；2. 或通过API直接查询核验结果 | 运单号: YB202607130081; 发票号: FP202607130081(有效) | 核验状态为"通过"；无"发票信息核验"（代码260）异常项 | 对应TP-C-046；[技术方案] API文档§4.1 | +| AH_REPORT_R2_051 | 平台端-监管上报-第二次上报 | 验证发票信息核验(260)—发票已作废时核验异常 | P1 | 功能测试 | 1. 运单YB202607130082关联的发票FP202607130082在税务系统中状态为"已作废/红冲"；2. 第一次/第二次上报已完成 | 1. 触发第三次上报后等待发票核验；2. 查看核验结果 | 运单号: YB202607130082; 发票号: FP202607130082(已作废) | 核验状态变为"异常"；异常项标注"发票信息核验"（代码260）；异常原因包含"发票已作废"或"发票状态异常"；可发起申诉 | 对应TP-C-047；[技术方案] API文档§4.1 | +| AH_REPORT_R2_052 | 平台端-监管上报-第二次上报 | 验证非通行车辆可开票核验(270)—车辆运营证照齐全且合规时核验通过 | P1 | 功能测试 | 1. 运单YB202607130083车辆运营证照齐全(道路运输证/行驶证均在有效期内)且未被标记为黑名单；2. 第一次/第二次上报已完成 | 1. 触发上报后等待核验；2. 查看核验结果 | 运单号: YB202607130083; 车辆证照: 齐全有效 | 核验状态为"通过"；无"非通行车辆可开票核验"（代码270）异常项 | 对应TP-C-048；[技术方案] API文档§4.1 | +| AH_REPORT_R2_053 | 平台端-监管上报-第二次上报 | 验证非通行车辆可开票核验(270)—车辆被标记为黑名单时核验异常 | P1 | 功能测试 | 1. 运单YB202607130084车辆已被监管平台标记为运营异常/黑名单；2. 第一次/第二次上报已完成 | 1. 触发上报后等待核验；2. 查看核验结果 | 运单号: YB202607130084; 车辆状态: 黑名单 | 核验状态变为"异常"；异常项标注"非通行车辆可开票核验"（代码270）；异常原因包含"车辆不合规"或"车辆不在可开票范围"；可发起申诉 | 对应TP-C-049；[技术方案] API文档§4.1 | + +--- + +## 模块D: 第三次上报-开票完成 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_R3_001 | 平台端-监管上报-第三次上报 | 验证发票开具完成后自动触发第三次上报且包含发票信息17字段 | P0 | 功能测试 | 1. 运单YB202607130001已完成第二次上报且状态为"已上传"；2. 该运单发票FP202607130001已开具完成 | 1. 系统收到发票开具完成事件；2. 进入管理端"监管上报-第三次上报"列表查看 | 运单号: YB202607130001; 发票号: FP202607130001; 发票金额(价税合计): ¥10,300.00 | 第三次上报列表中新增该运单记录，上报状态从"上传中"变为"已上传"（绿色标签）；上报请求包含运单信息+发票信息17字段+托运单号数组；若运单无关联油气发票则油气发票信息字段为空；数据库report_record表新增stage=3的记录 | 对应TP-D-001 | +| AH_REPORT_R3_002 | 平台端-监管上报-第三次上报 | 验证第三次上报列表展示13个字段完整且数据正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 第三次上报列表中有至少1条已完成的记录 | 1. 进入"监管上报-第三次上报"列表；2. 查看列表表头和第一条数据的所有列内容 | 运单号: YB202607130001; 发票号: FP202607130001 | 列表展示13个字段: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/发票号码/发票金额/开票日期/核验状态/异常原因/上报状态/操作；发票金额保留2位小数；开票日期格式为YYYY-MM-DD；核验状态标签颜色符合规范 | 对应TP-D-002；⚠️ 待确认: 原型列表比需求多4个字段（税率/销售方名称/受票方名称/油气票张数），共15列 | +| AH_REPORT_R3_003 | 平台端-监管上报-第三次上报 | 验证第三次上报详情弹窗发票信息19字段完整展示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001第三次上报已完成 | 1. 进入第三次上报列表；2. 点击运单YB202607130001的"详情"按钮；3. 查看"发票信息"分组的所有字段 | 运单号: YB202607130001; 发票号: FP202607130001; 发票代码: 1234567890; 价税合计: ¥10,300.00 | 发票信息分组展示19字段: 托运单号数组（支持多个托运单号）、发票号码、发票代码号、发票金额(价税合计)、开票日期（必选字段完整）；销售方8字段（名称/纳税人识别号/地址/电话/开户行/银行账户/账号/联系人）完整；受票方6字段（名称/纳税人识别号/地址/电话/开户行/银行卡号）完整；注：第三次上报无税率字段 | 对应TP-D-003 | +| AH_REPORT_R3_004 | 平台端-监管上报-第三次上报 | 验证运单关联油气发票时第三次上报包含油气发票信息 | P2 | 功能测试 | 1. 运单YB202607130040关联油气发票YQFP202607001；2. 该运单发票开具完成 | 1. 触发第三次上报；2. 查看上报请求JSON中油气发票信息字段；3. 查看详情弹窗 | 运单号: YB202607130040; 油气发票: YQFP202607001 | 上报请求JSON包含油气发票信息（油气托运单号、油气发票文件）；详情弹窗中油气发票信息正确展示；油气发票文件支持查看和下载 | 对应TP-D-004 | +| AH_REPORT_R3_005 | 平台端-监管上报-第三次上报 | 验证无油气发票时第三次上报正常完成（可选字段为空） | P2 | 功能测试 | 1. 运单YB202607130001无关联油气发票；2. 该运单发票开具完成 | 1. 触发第三次上报；2. 查看上报请求JSON中油气发票相关字段 | 运单号: YB202607130001; 油气发票: 无 | 上报请求JSON中油气发票字段为null或不传；上报成功，不报错；详情弹窗中油气发票区域显示"-"或"无" | 对应TP-D-004 | +| AH_REPORT_R3_006 | 平台端-监管上报-第三次上报 | 验证第三次上报依赖第二次上报完成—第二次上报失败时第三次上报被拒绝 | P0 | 功能测试 | 1. 运单YB202607130041第二次上报状态为"上传失败"；2. 该运单发票已开具完成 | 1. 发票开具完成事件触发第三次上报；2. 查看第三次上报接口返回 | 运单号: YB202607130041(第二次上报失败) | 接口返回错误，错误码明确标识"前置上报（第二次）未完成"；后端通过查询report_status表校验第二阶段的完成状态；第三次上报列表无该运单记录 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R3_007 | 平台端-监管上报-第三次上报 | 验证第三次上报完整依赖链校验—第1失败→第2无法完成→第3被拒绝 | P0 | 功能测试 | 1. 运单YB202607130042第一次上报状态为"上传失败" | 1. 通过API依次尝试调用第二次上报接口和第三次上报接口；2. 查看每个接口的返回 | 运单号: YB202607130042 | 第一次上报失败→第二次上报接口返回"前置上报未完成"；第二次上报无法完成→第三次上报接口同样返回"前置上报未完成"（含第二次）；三阶段依赖链校验在后端完整实现，不可跳级 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R3_008 | 平台端-监管上报-第三次上报 | 验证增值税发票号码格式无效时第三次上报失败并明确提示 | P1 | 功能测试 | 1. 运单YB202607130043发票号码格式无效（如"ABC"非标准格式）；2. 第二次上报已完成 | 1. 触发第三次上报；2. 查看上报接口返回的错误信息 | 运单号: YB202607130043; 发票号码: ABC(无效格式) | 接口返回校验错误，提示"发票号码格式无效"或类似消息；上报状态标记为"上传失败"（红色标签）；错误信息明确指出具体错误字段为发票号码；数据库无该运单第三次上报的成功记录 | 对应TP-D-006 | +| AH_REPORT_R3_009 | 平台端-监管上报-第三次上报 | 验证发票代码与发票号码不匹配时第三次上报失败 | P1 | 功能测试 | 1. 运单YB202607130044发票代码1234567890与发票号码FP202607130001不匹配 | 1. 触发第三次上报；2. 查看接口返回 | 运单号: YB202607130044; 不匹配的发票代码/号码 | 接口返回校验错误，提示"发票代码与发票号码不匹配"；上报状态标记为"上传失败"；错误信息指明具体错误字段 | 对应TP-D-006 | +| AH_REPORT_R3_010 | 平台端-监管上报-第三次上报 | 验证第三次上报失败后自动重试最多3次全部失败后告警 | P1 | 功能测试 | 1. 运单YB202607130045第三次上报时模拟监管平台持续返回失败 | 1. 触发第三次上报；2. 监控上报日志中的重试记录；3. 等待3次重试全部完成后查看告警通知 | 运单号: YB202607130045; 发票号: FP202607130045 | 自动重试3次（总共4次尝试）；重试间隔递增；3次重试全部失败后上报状态标记为"上传失败"（红色）并停止重试；super_admin收到告警通知，内容包含运单号YB202607130045、发票号FP202607130045、失败原因 | 对应TP-D-007 | +| AH_REPORT_R3_011 | 平台端-监管上报-第三次上报 | 验证第三次上报幂等性—同一运单同一发票信息不能重复上报 | P1 | 功能测试 | 1. 运单YB202607130001第三次上报已成功（发票FP202607130001）；2. 尝试再次触发第三次上报 | 1. 通过API再次调用第三次上报接口（同一运单+同一发票）；2. 查看接口返回 | 运单号: YB202607130001; 发票号: FP202607130001(已上报) | 接口返回"上报已存在"或"该发票已上报"提示；数据库report_record表不会新增重复记录（唯一约束：运单号+stage=3+发票号）；分布式锁或幂等键控制并发 | 对应TP-D-009 | +| AH_REPORT_R3_012 | 平台端-监管上报-第三次上报 | 验证第三次上报发票金额精度—价税合计保留2位小数无浮点数精度问题 | P1 | 功能测试 | 1. 准备发票金额为¥0.01、¥9,999.99、¥999,999.99的三张发票 | 1. 分别对三张发票触发第三次上报；2. 查看上报请求JSON中的金额字段；3. 对比数据库发票表和上报记录中的金额 | 金额1: ¥0.01; 金额2: ¥9,999.99; 金额3: ¥999,999.99 | 三个金额均保留2位小数并精确传输（如0.01不为0.009999...）；大金额¥999,999.99不出现溢出或截断；数据库金额字段使用DECIMAL类型非FLOAT；上报数据与开票系统数据完全一致 | 对应TP-D-010 | +| AH_REPORT_R3_013 | 平台端-监管上报-第三次上报 | 验证第三次上报运单信息数据来源—价格和货物信息来源于运单表实时数据 | P2 | 功能测试 | 1. 运单YB202607130046装货完成时货物信息含"钢材10吨"；2. 在第三次上报前修改运单表货物信息为"钢材12吨" | 1. 修改运单表的货物信息；2. 触发第三次上报；3. 查看上报请求中的货物信息数据 | 运单号: YB202607130046; 原货物量: 10吨; 修改后: 12吨 | 上报请求中的货物信息为"钢材12吨"（最新值），非"钢材10吨"（装货时快照）；数据来源为运单表实时查询；不依赖装货完成时的数据缓存 | 对应TP-D-011 | +| AH_REPORT_R3_014 | 平台端-监管上报-第三次上报 | 验证第三次上报详情弹窗异常信息分组与申诉模块数据联动 | P2 | 功能测试 | 1. 运单YB202607130046第三次上报核验异常；2. 已对该运单发起申诉且申诉状态为"申诉中" | 1. 进入第三次上报列表；2. 点击运单YB202607130046的"详情"按钮；3. 查看"异常信息"分组 | 运单号: YB202607130046; 申诉状态: 申诉中 | 异常信息分组包含核验状态（异常）、异常原因（具体异常项）、异常时间（核验时间）、处理状态（申诉中）；处理状态与申诉模块数据一致（联动）；申诉状态变更后详情弹窗中处理状态同步更新 | 对应TP-D-008 | +| AH_REPORT_R3_015 | 平台端-监管上报-第三次上报 | 验证发票合规查询接口—查询托运人发票是否通过系统核验合规 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 托运人"安徽XX物流有限公司"存在已核验合规的发票记录 | 1. 调用POST /verificationSummary/cargoOwnerInvoiceInfo接口；2. 传入托运人识别信息（统一社会信用代码/名称）；3. 查看返回的发票合规状态 | 托运人: 安徽XX物流有限公司; 统一社会信用代码: 9134XXXXXXXXXXXXXX | 接口返回发票合规状态为"合规/通过"；若发票不合规则返回异常原因和具体不合规项；接口支持批量查询多个托运人发票合规状态；响应时间<3s；传入无效托运人信息时返回明确错误提示 | 对应TP-D-012；[技术方案] API新增接口 | + +--- + +## 模块E: ETC发票上传 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_ETC_001 | 平台端-监管上报-ETC上传 | 验证税务抵扣完成后ETC发票上传成功且列表数据正确 | P0 | 功能测试 | 1. 运单YB202607130001的ETC发票ETC202607130001税务抵扣已完成；2. ETC发票信息18字段完整 | 1. 触发ETC发票上传（自动或手动）；2. 进入管理端"监管上报-ETC上传"列表查看；3. 查看上传请求JSON内容 | 运单号: YB202607130001; ETC发票号: ETC202607130001; 发票金额: ¥100.00; 税率: 3% | ETC上传列表中出现该记录，上传状态为"已上传"（绿色标签）；上报请求JSON包含运单信息7字段+ETC发票信息18字段；数据库etc_report_record表新增记录，status=1 | 对应TP-E-001 | +| AH_REPORT_ETC_002 | 平台端-监管上报-ETC上传 | 验证ETC上传列表展示11个字段完整且数据正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. ETC上传列表中有至少1条记录 | 1. 进入"监管上报-ETC上传"列表；2. 查看列表表头和第一条数据的所有列 | 运单号: YB202607130001; ETC发票号: ETC202607130001 | 列表展示: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/ETC发票号码/发票金额/税率/上传状态/操作；发票金额正确展示，税率显示3%；上传状态标签颜色符合规范 | 对应TP-E-002 | +| AH_REPORT_ETC_003 | 平台端-监管上报-ETC上传 | 验证ETC发票详情弹窗3个分组字段完整（运单信息/ETC发票信息18字段/异常信息） | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. ETC上传列表中有已完成上传的记录 | 1. 进入ETC上传列表；2. 点击运单YB202607130001操作列的"详情"按钮；3. 依次查看各分组字段 | 运单号: YB202607130001; ETC发票号: ETC202607130001 | 运单信息分组7字段完整；ETC发票信息分组18字段完整展示: ETC发票号码、ETC发票代码、开票时间、发票金额、税率(3%)、税额、价税合计、销售方名称、销售方税号、受票方名称、受票方税号、入口收费站、出口收费站、交易时间、交易金额、交易匹配时间、交易流水号、ETC发票文件；异常信息分组4字段（核验状态/异常原因/异常时间/处理状态） | 对应TP-E-003 | +| AH_REPORT_ETC_004 | 平台端-监管上报-ETC上传 | 验证税务抵扣未完成时ETC上传被拒绝并提示"请先完成税务抵扣" | P0 | 功能测试 | 1. 运单YB202607130047的ETC发票税务抵扣状态为"未完成" | 1. 尝试触发ETC发票上传（调用API或页面操作）；2. 查看接口返回 | 运单号: YB202607130047; 税务抵扣: 未完成 | 上传接口返回错误，提示"请先完成税务抵扣"；后端校验税务抵扣状态为已完成才允许上传；ETC上传列表中不会出现该运单记录 | 对应TP-E-004 | +| AH_REPORT_ETC_005 | 平台端-监管上报-ETC上传 | 验证ETC发票号码格式无效时上传失败并明确提示 | P1 | 功能测试 | 1. 运单YB202607130048关联的ETC发票号码格式无效（如"ETC-ABC"不符合规定格式） | 1. 税务抵扣完成后触发上传；2. 查看接口返回 | 运单号: YB202607130048; ETC发票号码: ETC-ABC(无效) | 上传接口返回校验错误，提示"ETC发票号码格式无效"；上传状态标记为"上传失败"；错误提示指明具体错误字段 | 对应TP-E-005 | +| AH_REPORT_ETC_006 | 平台端-监管上报-ETC上传 | 验证ETC发票税率非3%时上传失败并提示税率异常 | P1 | 功能测试 | 1. 运单YB202607130049关联的ETC发票税率字段为5%（非标准3%） | 1. 触发上传；2. 查看接口返回 | 运单号: YB202607130049; ETC发票税率: 5%(非标准) | 上传接口返回校验错误，提示"税率异常（应为3%）"；上传状态标记为"上传失败"；不会将错误税率数据上报至监管平台 | 对应TP-E-005 | +| AH_REPORT_ETC_007 | 平台端-监管上报-ETC上传 | 验证ETC上传失败后自动重试最多3次全部失败后告警 | P1 | 功能测试 | 1. 运单YB202607130050 ETC上传时模拟监管平台持续返回失败 | 1. 触发ETC上传；2. 监控上报日志中的重试记录；3. 等待3次重试全部完成后查看告警 | 运单号: YB202607130050; ETC发票号: ETC202607130050 | 自动重试3次（总共4次尝试）；重试间隔递增；3次重试全部失败后标记"上传失败"（红色标签）并停止重试；super_admin收到告警通知；每次重试均记录到上报日志 | 对应TP-E-006 | +| AH_REPORT_ETC_008 | 平台端-监管上报-ETC上传 | 验证ETC税额计算公式—税额=发票金额×3%结果保留2位小数 | P1 | 功能测试 | 1. 准备3张ETC发票：金额¥100.00、¥0.01、¥1,000,000.00 | 1. 分别对三张发票触发上传；2. 查看上报请求JSON中的税额和价税合计字段；3. 验证计算逻辑 | 发票1: ¥100.00→税额¥3.00; 发票2: ¥0.01→税额¥0.00; 发票3: ¥1,000,000.00→税额¥30,000.00 | 发票1: 税额=3.00, 价税合计=103.00, 计算正确；发票2: 税额按四舍五入规则处理（0.01×3%=0.0003→0.00）；发票3: 税额=30000.00, 大金额计算不溢出；所有税额保留2位小数 | 对应TP-E-007 | +| AH_REPORT_ETC_009 | 平台端-监管上报-ETC上传 | 验证同一ETC发票号重复上传时被拒绝且提示"该ETC发票已上传" | P1 | 功能测试 | 1. ETC发票ETC202607130001已成功上传 | 1. 再次触发同一ETC发票的上传；2. 查看接口返回 | ETC发票号: ETC202607130001(已上传) | 接口返回"该ETC发票已上传"提示；数据库etc_report_record表不会产生重复记录（唯一约束：ETC发票号）；分布式锁/幂等键控制并发 | 对应TP-E-008 | +| AH_REPORT_ETC_010 | 平台端-监管上报-ETC上传 | 验证同一运单关联多张ETC发票时各自独立上传且税额分别计算 | P2 | 功能测试 | 1. 运单YB202607130001关联3张ETC发票：ETC202607130001(¥100.00)、ETC202607130002(¥200.00)、ETC202607130003(¥150.00) | 1. 分别触发3张ETC发票的上传；2. 查看ETC上传列表；3. 验证每张发票的税额计算 | ETC1: ¥100.00→税¥3.00; ETC2: ¥200.00→税¥6.00; ETC3: ¥150.00→税¥4.50 | 列表中同一运单展示3条ETC上传记录；每张发票的税额独立计算正确；多张发票上传互不干扰；合计税额=¥13.50正确汇总 | 对应TP-E-009 | +| AH_REPORT_ETC_011 | 平台端-监管上报-ETC上传 | 验证ETC发票代码与号码不匹配时上传失败 | P1 | 功能测试 | 1. 运单YB202607130051的ETC发票代码与号码不匹配（代码对应其他发票） | 1. 触发上传；2. 查看接口返回 | 运单号: YB202607130051; 不匹配的ETC发票代码/号码 | 上传接口返回校验错误，提示"ETC发票代码与号码不匹配"；上传状态标记为"上传失败"；错误信息指明具体错误字段 | 对应TP-E-005 | +| AH_REPORT_ETC_012 | 平台端-监管上报-ETC上传 | 验证交易金额与实际通行费不匹配时ETC上传验证失败 | P1 | 功能测试 | 1. 运单YB202607130052的ETC发票中交易金额¥50.00与实际通行费¥80.00不匹配 | 1. 触发上传；2. 查看接口返回 | 运单号: YB202607130052; 交易金额: ¥50.00; 实际通行费: ¥80.00(不匹配) | 上传接口返回校验错误，提示"交易金额与实际通行费不匹配"；上传状态标记为"上传失败" | 对应TP-E-005 | + +--- + +## 模块F: 异常申诉功能 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_APL_001 | 平台端-监管上报-异常申诉 | 验证申诉完整闭环—从发起申诉到申诉通过的端到端流程 | P0 | 功能测试 | 1. 运单YB202607130002第二次上报"车辆资质核验"异常；2. 使用super_admin登录管理端；3. 准备申诉附件材料（车辆道路运输证更新后的PDF） | 1. 从看板或第二次上报列表找到异常运单YB202607130002；2. 点击"申诉"按钮进入申诉页面；3. 填写申诉原因"道路运输证已续期，附新证"；4. 上传申诉附件；5. 点击"提交申诉"；6. 模拟省平台复核通过并返回反馈；7. 查看申诉状态变化 | 运单号: YB202607130002; 异常项: 车辆资质核验; 申诉原因: 道路运输证已续期; 附件: 新道路运输证.pdf | 提交申诉后申诉状态变为"申诉中"；省平台复核通过后状态变为"申诉通过"（绿色标签）；申诉记录页面中该申诉记录状态为"申诉通过"；处理记录时间线中每条操作均有记录；原异常运单核验状态可能根据省平台反馈更新 | 对应TP-F-001；⚠️ 待确认: 申诉状态枚举三版本不一致——需求(未申诉/申诉中/申诉通过/申诉驳回)、原型(未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回)、API(未申诉100/审核通过110/审核不通过120/已取消130) | +| AH_REPORT_APL_002 | 平台端-监管上报-异常申诉 | 验证申诉驳回后运营人员重新申诉补充材料再发起 | P1 | 功能测试 | 1. 运单YB202607130002申诉状态为"申诉驳回"；2. 省平台反馈意见"证明材料不充分" | 1. 进入申诉记录页面，找到驳回的申诉记录；2. 点击"重新申诉"按钮；3. 补充新的附件材料（补充证明.pdf）；4. 修改申诉原因；5. 提交 | 运单号: YB202607130002; 原申诉被驳回; 新附件: 补充证明.pdf | "重新申诉"按钮可见可用；重新申诉后生成新的申诉单号（不同于原申诉单号）；原有申诉记录保留不丢失；新申诉有独立的处理记录时间线；申诉状态变为"申诉中"重新进入复核流程 | 对应TP-F-006 | +| AH_REPORT_APL_003 | 平台端-监管上报-异常申诉 | 验证申诉记录列表14个字段完整展示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 申诉记录列表中有至少1条申诉记录 | 1. 进入"监管上报-异常申诉"申诉记录页面；2. 查看列表表头和第一条数据的各列 | 申诉单含完整字段 | 列表展示14个字段: 运单号/托运单号/车牌号/司机姓名/托运方名称/上报阶段/核验状态/异常项/申诉状态/申诉时间/申诉人/省平台反馈结果/监管平台反馈时间/操作；申诉时间为实际提交时间；省平台反馈结果与实际反馈内容一致 | 对应TP-F-002 | +| AH_REPORT_APL_004 | 平台端-监管上报-异常申诉 | 验证申诉状态流转—未申诉→申诉中→申诉通过(终态不可变更) | P0 | 功能测试 | 1. 运单YB202607130053核验异常且申诉状态为"未申诉" | 1. 发起申诉，验证状态变为"申诉中"；2. 模拟省平台复核通过；3. 验证状态变为"申诉通过"；4. 尝试再次对该申诉记录操作（如重新申诉） | 运单号: YB202607130053 | 未申诉→申诉中（提交后立即变更）；申诉中→申诉通过（省平台反馈后变更）；申诉通过为终态，不可再变更（"重新申诉"等操作按钮不可见）；每次状态变更记录到处理记录时间线 | 对应TP-F-003；⚠️ 待确认: API申诉状态为未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130)，无"申诉中"状态 | +| AH_REPORT_APL_005 | 平台端-监管上报-异常申诉 | 验证申诉状态流转—申诉中状态下不可重复发起申诉 | P0 | 功能测试 | 1. 运单YB202607130054申诉状态为"申诉中" | 1. 尝试通过API或页面再次对该运单同一异常项发起申诉；2. 观察系统响应 | 运单号: YB202607130054; 申诉状态: 申诉中 | 页面"申诉"按钮被禁用或点击后提示"申诉处理中，请勿重复提交"；后端API返回错误，提示"该异常项已有申诉在处理中"；数据库不会产生重复申诉记录 | 对应TP-F-003; TP-F-012 | +| AH_REPORT_APL_006 | 平台端-监管上报-异常申诉 | 验证申诉详情弹窗5个分组字段完整（申诉信息/运单信息/异常信息/省平台反馈/处理记录） | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 存在一条已完成的申诉记录 | 1. 进入申诉记录页面；2. 点击某条记录的"详情"按钮；3. 依次查看5个分组的内容 | 申诉单号: APL202607130001 | 申诉信息分组含: 申诉单号/上报阶段/异常项/申诉原因/申诉状态/申诉时间/申诉人/申诉附件；省平台反馈信息含: 反馈结果/反馈时间/反馈意见；处理记录以时间线形式倒序展示：操作人/操作时间/操作类型/操作内容，每步操作（发起申诉/省平台反馈/重新申诉）均有一条记录 | 对应TP-F-004 | +| AH_REPORT_APL_007 | 平台端-监管上报-异常申诉 | 验证申诉附件上传—支持多附件且格式校验正确 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 准备png、jpg、pdf格式的附件文件各1个，以及1个超出大小限制的文件(如10MB) | 1. 进入申诉发起页面；2. 依次上传png/jpg/pdf文件；3. 尝试上传超限文件 | 附件: 证明1.png(500KB), 证明2.jpg(800KB), 证明3.pdf(1.5MB), 超限文件.exe(10MB) | png/jpg/pdf格式上传成功，附件列表展示文件名和大小；超限文件上传时提示"文件大小超过限制"；上传失败有重试机制；申诉详情弹窗中可查看/下载已上传的附件 | 对应TP-F-005 | +| AH_REPORT_APL_008 | 平台端-监管上报-异常申诉 | 验证7类核验异常（运单重复/车辆资质/司机资质/集中支付/资金流水/合同/轨迹）各自独立发起申诉 | P1 | 功能测试 | 1. 准备7条运单，每条分别对应一种核验异常 | 1. 分别对7条运单发起申诉；2. 查看每条申诉记录中的异常项信息；3. 验证各申诉独立互不干扰 | 运单A: 运单重复异常; B: 车辆资质异常; C: 司机资质异常; D: 集中支付异常; E: 资金流水异常; F: 合同异常; G: 轨迹合规异常 | 7条申诉各自独立创建，异常项信息与核验结果一致；每条申诉的异常项字段正确标注对应的核验类别；某一异常项申诉不影响其他异常项的申诉状态 | 对应TP-F-007；⚠️ 待确认: 核验项从需求7类扩展为API文档17项，每项是否均有独立申诉入口待确认 | +| AH_REPORT_APL_009 | 平台端-监管上报-异常申诉 | 验证从看板操作列点击申诉按钮跳转至申诉页面并自动填充运单号 | P1 | 功能测试 | 1. 看板中存在核验异常的运单YB202607130002；2. 使用super_admin登录管理端 | 1. 进入看板页面；2. 在异常运单YB202607130002的操作列点击"申诉"按钮；3. 观察页面跳转和预填充数据 | 运单号: YB202607130002 | 页面路由正确跳转至申诉发起页面；URL携带正确的运单ID参数；申诉页面自动加载该运单的异常信息（运单号YB202607130002、异常项预填充正确）；运营人员无需手动输入运单号 | 对应TP-F-008 | +| AH_REPORT_APL_010 | 平台端-监管上报-异常申诉 | 验证仅运营人员有权发起申诉—司机/车队长/财务无申诉操作权限 | P1 | 安全性测试 | 1. 准备运营(super_admin)、财务、车队长(13113113113)、司机(15188888888)账号 | 1. 用各账号分别登录；2. 访问申诉功能页面；3. 尝试通过API直接调用申诉接口 | 运营: super_admin; 财务: finance_user; 车队长: 13113113113; 司机: 15188888888 | 运营人员可见"申诉"按钮和申诉记录页面，可发起申诉；车队长/司机端无申诉功能入口，直接URL访问返回403；财务人员可查看申诉记录但"发起申诉"按钮不可见；越权操作被拦截并记录审计日志（操作人/操作时间/操作内容/拦截原因） | 对应TP-F-009 | +| AH_REPORT_APL_011 | 平台端-监管上报-异常申诉 | 验证申诉处理记录时间线按时间倒序排列且操作时间精确到秒 | P2 | 功能测试 | 1. 存在一条经历了发起申诉→省平台反馈→重新申诉→省平台再次反馈的完整申诉记录 | 1. 进入申诉详情弹窗；2. 查看"处理记录"时间线 | 申诉单号: APL202607130002 | 4条操作记录按时间倒序排列（最新的在最上面）；每条记录包含: 操作人（用户名或"省平台"）、操作时间（YYYY-MM-DD HH:mm:ss）、操作类型（发起申诉/复核通过/复核驳回/重新申诉）、操作内容描述；操作类型与实际情况准确对应 | 对应TP-F-010 | +| AH_REPORT_APL_012 | 平台端-监管上报-异常申诉 | 验证异常代码一览表映射—已知异常代码正确映射为中文异常项名称 | P2 | 功能测试 | 1. 模拟省平台返回已知异常代码（如"VEHICLE_QUAL_FAIL"） | 1. 查看申诉页面中该异常代码对应的中文展示；2. 验证映射关系正确 | 异常代码: VEHICLE_QUAL_FAIL | 申诉页面中异常项显示为"车辆资质核验"（中文），非原始代码"VEHICLE_QUAL_FAIL"；异常代码与中文名称一一对应无歧义 | 对应TP-F-011 | +| AH_REPORT_APL_013 | 平台端-监管上报-异常申诉 | 验证未知异常代码兜底展示—显示原始代码+标注未知异常 | P2 | 功能测试 | 1. 模拟省平台返回一个系统中未定义的异常代码（如"UNKNOWN_ERROR_999"） | 1. 查看申诉页面异常项的展示 | 未知异常代码: UNKNOWN_ERROR_999 | 申诉页面中异常项显示原始代码"UNKNOWN_ERROR_999"并标注"(未知异常)"或类似兜底文案（不崩溃、不显示乱码）；系统日志中记录"未识别的异常代码"便于后续排查 | 对应TP-F-011 | +| AH_REPORT_APL_014 | 平台端-监管上报-异常申诉 | 验证同一异常项申诉中状态下快速双击提交申诉仅产生1条记录 | P2 | 功能测试 | 1. 运单YB202607130055核验异常，申诉状态为"未申诉" | 1. 进入申诉页面填写完整信息；2. 快速双击"提交申诉"按钮；3. 查看申诉记录列表 | 运单号: YB202607130055; 异常项: 资金流水核验 | 申诉记录列表中仅产生1条申诉记录（前端防抖+后端校验）；后端有状态校验，"申诉中"状态下不可重新发起；数据库appeal_record表该运单+该异常项仅有1条"申诉中"记录 | 对应TP-F-012 | +| AH_REPORT_APL_015 | 平台端-监管上报-异常申诉 | 验证申诉提交后省平台长时间无反馈(超7个工作日)时系统有合理状态提示 | P3 | 功能测试 | 1. 运单YB202607130056申诉状态为"申诉中"；2. 模拟时间超过7个工作日省平台无反馈 | 1. 进入申诉记录页面查看该申诉记录；2. 查看系统是否有超时提示或告警 | 运单号: YB202607130056; 等待时长: 超过7个工作日 | 申诉记录页面显示"等待省平台复核中"或类似状态提示（申诉状态仍为"申诉中"不自动变更）；运营人员可查看申诉等待时长（如"已等待8个工作日"）；系统应触发超时告警通知运营人员跟进（告警渠道和阈值待确认）；不自动变更申诉状态为通过或驳回 | 对应TP-F-013；> ⚠️ 待确认：申诉超时告警机制（告警渠道、触发阈值）需与产品确认 | +| AH_REPORT_APL_016 | 平台端-监管上报-异常申诉 | 验证申诉附件上传失败时有重试机制 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 模拟附件上传接口服务暂时不可用 | 1. 进入申诉发起页面；2. 填写申诉信息并选择附件上传；3. 在上传过程中模拟服务异常 | 附件: 证明文件.png(500KB) | 附件上传失败时前端显示"上传失败，点击重试"提示；点击重试后可重新上传；上传成功后可正常提交申诉；失败不影响已填写的申诉文字内容 | 对应TP-F-005 | +| AH_REPORT_APL_017 | 平台端-监管上报-异常申诉 | 验证财务人员可查看申诉记录但不可发起申诉 | P1 | 安全性测试 | 1. 使用财务账号登录管理端；2. 申诉记录中有数据 | 1. 进入申诉记录页面，查看是否有"发起申诉"按钮；2. 查看申诉详情是否可读；3. 尝试通过API调用申诉发起接口 | 财务账号: finance_user | 申诉记录列表正常展示，可查看详情；"发起申诉"按钮不可见（或置灰）；通过API直接调用申诉发起接口返回403 Forbidden；审计日志中记录财务账号的查看操作 | 对应TP-F-009 | + +--- + +## 模块G: 上报日志 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_LOG_001 | 平台端-监管上报-上报日志 | 验证上报日志按完整运单号精确搜索日志记录 | P0 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001存在上报日志记录 | 1. 进入"监管上报-上报日志"页面；2. 在运单号搜索框输入"YB202607130001"；3. 点击搜索 | 运单号: YB202607130001 | 列表仅展示与该运单号相关的所有上报日志记录（含各阶段的重试记录）；数据库查询结果与页面展示一致 | 对应TP-G-001 | +| AH_REPORT_LOG_002 | 平台端-监管上报-上报日志 | 验证上报日志按不存在的单号搜索显示空结果 | P1 | 功能测试 | 1. 使用super_admin登录管理端 | 1. 进入"监管上报-上报日志"页面；2. 输入不存在的单号"NOTEXIST999"；3. 点击搜索 | 运单号: NOTEXIST999 | 列表显示空结果，友好提示"未找到相关日志记录"；控制台无报错 | 对应TP-G-001 | +| AH_REPORT_LOG_003 | 平台端-监管上报-上报日志 | 验证上报日志按"第一次上报"阶段筛选日志 | P0 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中同时存在第一次上报和第二次上报的记录 | 1. 进入"监管上报-上报日志"页面；2. 选择上报阶段"第一次上报"；3. 查看筛选结果 | 筛选条件: 第一次上报 | 列表仅展示stage=1的日志记录；ETC上传日志不包含在内；切换至"ETC上传"时有独立筛选项，日志正确过滤 | 对应TP-G-002 | +| AH_REPORT_LOG_004 | 平台端-监管上报-上报日志 | 验证上报日志按"失败"结果筛选—展示所有非成功日志 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中存在成功(HTTP 200)和失败(HTTP 4xx/5xx/超时)的记录 | 1. 进入日志页面；2. 选择上报结果"失败"；3. 查看筛选结果 | 筛选: 失败 | 列表展示所有非2xx的日志记录，包括HTTP 400/500/超时等；"成功"(200)的记录被过滤；筛选结果与实际日志记录一致 | 对应TP-G-003 | +| AH_REPORT_LOG_005 | 平台端-监管上报-上报日志 | 验证上报日志按时间范围筛选（跨天） | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中存在2026-07-10至2026-07-13的记录 | 1. 进入日志页面；2. 选择开始时间"2026-07-10 00:00:00"，结束时间"2026-07-12 23:59:59"；3. 点击搜索 | 时间范围: 2026-07-10~2026-07-12 | 列表仅展示该时间范围内的日志记录；不包含2026-07-13的日志；开始时间>结束时间时系统给出提示或自动交换；不选时间范围时默认展示全部 | 对应TP-G-004 | +| AH_REPORT_LOG_006 | 平台端-监管上报-上报日志 | 验证上报日志列表11个字段完整展示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中有至少1条完整记录 | 1. 进入日志页面；2. 查看列表表头和第一条数据的所有列 | 查看一条典型日志记录 | 列表展示: 序号/货源单号/运单号/托运单号/上报阶段/上报结果/接口URL/HTTP状态码/响应时间/上报时间/操作；接口URL完整（含域名和路径如https://anhui.report.gov.cn/api/v1/waybill/submit）；HTTP状态码为实际返回状态码；响应时间单位为ms；上报时间为实际请求发起时间 | 对应TP-G-005 | +| AH_REPORT_LOG_007 | 平台端-监管上报-上报日志 | 验证点击日志操作列详情按钮弹窗展示完整请求和响应报文 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中有1条失败记录 | 1. 进入日志页面；2. 点击某条日志操作列的"详情"按钮；3. 在弹窗中查看请求报文和响应报文 | 查看一条HTTP 400失败的日志详情 | 弹窗展示请求报文: URL（完整）、Method（POST）、Headers（Content-Type/Authorization等）、Body（完整JSON）；响应报文: Status Code（400）、Headers、Body（错误信息JSON）；JSON报文格式化展示（缩进/语法高亮）；长报文支持滚动查看；支持一键复制请求/响应内容 | 对应TP-G-006 | +| AH_REPORT_LOG_008 | 平台端-监管上报-上报日志 | 验证每个上报阶段及自动修改字段接口的每次调用均在日志中完整记录 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001已完成全流程上报（第一次+修改字段+第二次+7核验+第三次+ETC） | 1. 进入日志页面；2. 按运单号YB202607130001搜索；3. 逐条检查日志记录是否覆盖所有阶段 | 运单号: YB202607130001 | 日志中至少包含以下记录: 第一次上报请求+响应、第一次上报修改字段请求+响应、第二次上报请求+响应、7类核验各自的请求+响应日志、第三次上报请求+响应、ETC上传请求+响应；自动重试的每次请求均独立记录（如第一次上报失败重试2次→共3条日志） | 对应TP-G-007 | +| AH_REPORT_LOG_009 | 平台端-监管上报-上报日志 | 验证上报失败日志包含完整的Error Response Body和重试次数标记 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 存在上报失败的日志记录 | 1. 进入日志页面；2. 筛选"失败"的日志；3. 点击某条失败日志的详情；4. 查看失败信息完整度 | 查看一条第2次重试失败的日志 | 失败日志包含完整的Error Response Body（JSON格式）；超时日志标注"timeout"并记录超时时长（如30000ms）；重试日志中标注当前是第几次重试（如"重试第2/3次"）；异常日志可关联到具体运单ID，方便排查 | 对应TP-G-008 | +| AH_REPORT_LOG_010 | 平台端-监管上报-上报日志 | 验证上报日志区分自动触发和手动触发—自动标注"系统自动"/手动标注操作人 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 存在自动触发的上报日志和手动触发的上报日志 | 1. 进入日志页面；2. 查看自动触发上报的日志记录中的操作人字段；3. 查看手动触发上报的日志记录中的操作人字段 | 自动日志: 第一次上报(装货完成触发); 手动日志: 第一次上报(手动上传) | 自动触发的上报日志操作人标注"系统自动"或"auto"；手动触发的上报日志操作人标注实际登录用户名（如"super_admin"）；审计日志中操作人信息与实际登录用户一致 | 对应TP-G-009 | +| AH_REPORT_LOG_011 | 平台端-监管上报-上报日志 | 验证上报日志组合筛选—阶段+结果+时间范围+单号同时筛选 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志数据满足组合条件 | 1. 进入日志页面；2. 设置: 阶段=第二次上报、结果=失败、时间范围=2026-07-10~2026-07-13、运单号=YB20260713；3. 点击搜索 | 组合: 第二次上报+失败+2026-07-10~2026-07-13+YB20260713 | 列表仅展示同时满足4个条件的日志记录；各条件在数据库查询中均正确生效；组合结果为空时有友好提示 | 对应TP-G-001; TP-G-002; TP-G-003; TP-G-004 | + +--- + +## 跨模块测试点 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_CROSS_001 | 平台端-监管上报-跨模块 | 验证完整三阶段依赖链端到端验证—后端三重前置状态校验 | P0 | 功能测试 | 1. 准备一条安徽税源地(34)的运单YB202607130001 | 1. 使第一次上报失败（关闭监管平台接口）；2. 尝试调用第二次上报API；3. 查看返回；4. 使第二次上报失败；5. 尝试调用第三次上报API；6. 查看返回 | 运单号: YB202607130001 | 第一次上报失败→第二次上报API返回错误码"前置上报未完成"；第二次上报失败→第三次上报API返回错误码"前置上报（第二次）未完成"；三个阶段不可跳级执行；依赖链校验在后端通过查询report_status表实现，非仅前端控制；每个阶段的阻断/通过状态独立存储 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_CROSS_002 | 平台端-监管上报-跨模块 | 验证多模块数据一致性—修改源数据后各阶段上报感知变更并使用最新值 | P0 | 功能测试 | 1. 运单YB202607130046初始数据: 司机15188888888、合同金额¥10,000.00、发票金额¥10,300.00 | 1. 第一次上报前修改司机信息（如更换司机手机号）；2. 触发第一次上报，验证使用最新司机信息；3. 财务修改打款金额（¥10,000.00→¥9,500.00）；4. 触发第二次上报，验证使用¥9,500.00；5. 修改发票金额（¥10,300.00→¥10,100.00）；6. 触发第三次上报，验证使用¥10,100.00 | 运单号: YB202607130046; 修改项: 司机/金额/发票 | 第一次上报使用最新司机信息；第二次上报金额为¥9,500.00（非缓存的¥10,000.00）；第三次上报发票金额为¥10,100.00（非旧值）；数据库查询日志可确认各字段的数据来源表（非缓存）；数据库report_record表各阶段记录中的数据与来源表一致 | [AI修正: 历史缺陷防御] - BUG-202607-03 | +| AH_REPORT_CROSS_003 | 平台端-监管上报-跨模块 | 验证安徽税源地运单完整上报链路—装货到ETC全流程核验通过（冒烟测试） | P0 | 冒烟测试 | 1. 准备一条安徽税源地(34)的完整运单YB202607130001，所有资质有效、合同有效、轨迹正常、支付正常、发票正常 | 1. 装货完成→等待第一次上报→验证状态"已上传"；2. 等待自动修改字段→验证日志中有修改记录；3. 财务打款¥10,000.00→等待第二次上报→验证7类核验全部通过；4. 发票FP202607130001开具→等待第三次上报→验证状态"已上传"；5. 税务抵扣完成→ETC发票ETC202607130001上传→验证状态"已上传" | 运单号: YB202607130001; 金额: ¥10,000.00; 发票: FP202607130001; ETC: ETC202607130001 | 第一次上报成功→第二次上报成功（7核验全通过）→第三次上报成功→ETC上传成功；每个阶段看板数据正确更新；上报日志完整记录全链路；数据库report_record表stage=1/2/3均状态=1；etc_report_record表status=1 | 对应TP-X-003 | +| AH_REPORT_CROSS_004 | 平台端-监管上报-跨模块 | 验证非安徽税源地运单(云南=28)全部阶段均不触发上报 | P0 | 功能测试 | 1. 准备一条云南税源地(28)的运单YB202607130002，包含完整运输流程 | 1. 装货完成→检查是否触发第一次上报；2. 财务打款→检查是否触发第二次上报；3. 发票开具→检查是否触发第三次上报；4. 税务抵扣→检查是否触发ETC上传；5. 查看看板中是否存在该运单 | 运单号: YB202607130002; 省份代码: 28(云南) | 全部阶段均不触发上报；看板中不显示该云南运单；上报日志中无该运单的任何上报记录；系统无因"不触发"而产生的错误日志或异常告警；云南运单本身的运输流程（装货→运输→卸货→结算）不受影响正常流转 | 对应TP-X-004 | +| AH_REPORT_CROSS_005 | 平台端-监管上报-跨模块 | 验证多省份部署下安徽(34)和云南(28)上报数据完全隔离 | P1 | 功能测试 | 1. 准备安徽(34)运单YB202607130001和云南(28)运单YB202607130002各1条 | 1. 分别触发两条运单的完整上报流程；2. 查看两个省份的上报日志和数据记录；3. 验证安徽运单的上报目标URL为安徽监管平台，云南运单为云南监管平台 | 安徽: YB202607130001(34); 云南: YB202607130002(28) | 安徽运单仅上报至安徽监管平台(URL含anhui)；云南运单仅上报至云南监管平台(URL含yunnan)；两个省份的report_record表数据通过province_code字段物理/逻辑隔离；省份代码各自独立（安徽=34、云南=28），不混淆 | 对应TP-X-005 | +| AH_REPORT_CROSS_006 | 平台端-监管上报-跨模块 | 验证定时任务重试与手动触发上报的并发控制—分布式锁机制 | P1 | 功能测试 | 1. 运单YB202607130057第一次上报失败，定时重试任务即将触发第1次重试；2. super_admin在管理端准备手动点击"手动上传" | 1. 在重试任务触发的同时，super_admin点击"手动上传"；2. 观察并发场景下的系统行为 | 运单号: YB202607130057 | 同一时刻仅1个上报请求被执行（通过分布式锁如Redis SETNX控制）；被拒绝的请求返回"上报处理中"提示；不产生重复上报记录；分布式锁正确释放，后续操作可正常进行 | 对应TP-B-014; TP-C-021 | +| AH_REPORT_CROSS_007 | 平台端-监管上报-跨模块 | 验证回单签收后财务打款前不触发第二次上报—打款完成才触发 | P2 | 功能测试 | 1. 运单YB202607130001第一次上报已完成；2. 回单已签收但财务尚未打款 | 1. 回单签收完成后检查第二次上报列表；2. 财务执行打款后再次检查第二次上报列表；3. 对比两次检查的时间点 | 运单号: YB202607130001; 回单签收时间: 2026-07-12 15:00; 打款时间: 2026-07-12 17:00 | 回单签收完成后第二次上报列表中无该运单记录（未触发）；财务打款完成后第二次上报列表中出现该运单记录（已触发）；上报时间戳接近打款完成时间（如2026-07-12 17:00:05），非回单签收时间 | 对应TP-X-006 | + +--- + +## 测试点→用例映射表 + +| 测试点ID | 对应的用例编号 | 覆盖状态 | +| :--- | :--- | :--- | +| TP-A-001 | AH_REPORT_DASH_001, AH_REPORT_DASH_002, AH_REPORT_DASH_003 | 已覆盖 | +| TP-A-002 | AH_REPORT_DASH_004 | 已覆盖 | +| TP-A-003 | AH_REPORT_DASH_005 | 已覆盖 | +| TP-A-004 | AH_REPORT_DASH_006 | 已覆盖 | +| TP-A-005 | AH_REPORT_DASH_007 | 已覆盖 | +| TP-A-006 | AH_REPORT_DASH_008, AH_REPORT_DASH_009 | 已覆盖 | +| TP-A-007 | AH_REPORT_DASH_010 | 已覆盖 | +| TP-A-008 | AH_REPORT_DASH_011 | 已覆盖 | +| TP-A-009 | AH_REPORT_DASH_012 | 已覆盖 | +| TP-A-010 | AH_REPORT_DASH_013 | 已覆盖 | +| TP-A-011 | AH_REPORT_DASH_014, AH_REPORT_DASH_015 | 已覆盖 | +| TP-A-012 | AH_REPORT_DASH_016 | 已覆盖 | +| TP-A-013 | AH_REPORT_DASH_017 | 已覆盖 | +| TP-A-014 | AH_REPORT_DASH_018 | 已覆盖 | +| TP-B-001 | AH_REPORT_R1_001 | 已覆盖 | +| TP-B-002 | AH_REPORT_R1_002, AH_REPORT_R1_003 | 已覆盖 | +| TP-B-003 | AH_REPORT_R1_004, AH_REPORT_R1_005, AH_REPORT_R1_021 | 已覆盖 | +| TP-B-004 | AH_REPORT_R1_003, AH_REPORT_R1_006 | 已覆盖 | +| TP-B-005 | AH_REPORT_R1_007, AH_REPORT_R1_008 | 已覆盖 | +| TP-B-006 | AH_REPORT_R1_009 | 已覆盖 | +| TP-B-007 | AH_REPORT_R1_010 | 已覆盖 | +| TP-B-008 | AH_REPORT_R1_011 | 已覆盖 | +| TP-B-009 | AH_REPORT_R1_012 | 已覆盖 | +| TP-B-010 | AH_REPORT_R1_023 | 已覆盖 | +| TP-B-011 | AH_REPORT_DASH_014 | 已覆盖（见看板详情弹窗用例） | +| TP-B-012 | AH_REPORT_DASH_015 | 已覆盖（见看板详情弹窗用例） | +| TP-B-013 | AH_REPORT_R1_022 | 已覆盖 | +| TP-B-014 | AH_REPORT_R1_013, AH_REPORT_R1_014, AH_REPORT_CROSS_006 | 已覆盖 | +| TP-B-015 | AH_REPORT_R1_015 | 已覆盖 | +| TP-B-016 | AH_REPORT_R1_016 | 已覆盖 | +| TP-B-017 | AH_REPORT_R1_017 | 已覆盖 | +| TP-B-018 | AH_REPORT_R1_018 | 已覆盖 | +| TP-B-019 | AH_REPORT_R1_019, AH_REPORT_R1_020 | 已覆盖 | +| TP-B-020 | AH_REPORT_R1_024 | 已覆盖 | +| TP-C-001 | AH_REPORT_R2_001 | 已覆盖 | +| TP-C-002 | AH_REPORT_R2_002 | 已覆盖 | +| TP-C-003 | AH_REPORT_R2_003 | 已覆盖 | +| TP-C-004 | AH_REPORT_R2_004 | 已覆盖 | +| TP-C-005 | AH_REPORT_R2_004 | 已覆盖 | +| TP-C-006 | AH_REPORT_R2_005 | 已覆盖 | +| TP-C-007 | AH_REPORT_R2_006 | 已覆盖 | +| TP-C-008 | AH_REPORT_R2_007 | 已覆盖 | +| TP-C-009 | AH_REPORT_R2_008 | 已覆盖 | +| TP-C-010 | AH_REPORT_R2_009 | 已覆盖 | +| TP-C-011 | AH_REPORT_R2_010 | 已覆盖 | +| TP-C-012 | AH_REPORT_R2_011 | 已覆盖 | +| TP-C-013 | AH_REPORT_R2_012 | 已覆盖 | +| TP-C-014 | AH_REPORT_R2_013 | 已覆盖 | +| TP-C-015 | AH_REPORT_R2_014, AH_REPORT_R2_015 | 已覆盖 | +| TP-C-016 | AH_REPORT_R2_016 | 已覆盖 | +| TP-C-017 | AH_REPORT_R2_017, AH_REPORT_R2_018 | 已覆盖 | +| TP-C-018 | AH_REPORT_R2_019, AH_REPORT_R2_020, AH_REPORT_R2_021 | 已覆盖 | +| TP-C-019 | AH_REPORT_R2_022, AH_REPORT_R2_023 | 已覆盖 | +| TP-C-020 | AH_REPORT_R2_024 | 已覆盖 | +| TP-C-021 | AH_REPORT_R2_025, AH_REPORT_CROSS_006 | 已覆盖 | +| TP-C-022 | AH_REPORT_R2_026 | 已覆盖 | +| TP-C-023 | AH_REPORT_R2_027 | 已覆盖 | +| TP-C-024 | AH_REPORT_R2_028 | 已覆盖 | +| TP-D-001 | AH_REPORT_R3_001 | 已覆盖 | +| TP-D-002 | AH_REPORT_R3_002 | 已覆盖 | +| TP-D-003 | AH_REPORT_R3_003 | 已覆盖 | +| TP-D-004 | AH_REPORT_R3_004, AH_REPORT_R3_005 | 已覆盖 | +| TP-D-005 | AH_REPORT_R3_006, AH_REPORT_R3_007 | 已覆盖 | +| TP-D-006 | AH_REPORT_R3_008, AH_REPORT_R3_009 | 已覆盖 | +| TP-D-007 | AH_REPORT_R3_010 | 已覆盖 | +| TP-D-008 | AH_REPORT_R3_014 | 已覆盖 | +| TP-D-009 | AH_REPORT_R3_011 | 已覆盖 | +| TP-D-010 | AH_REPORT_R3_012 | 已覆盖 | +| TP-D-011 | AH_REPORT_R3_013 | 已覆盖 | +| TP-E-001 | AH_REPORT_ETC_001 | 已覆盖 | +| TP-E-002 | AH_REPORT_ETC_002 | 已覆盖 | +| TP-E-003 | AH_REPORT_ETC_003 | 已覆盖 | +| TP-E-004 | AH_REPORT_ETC_004 | 已覆盖 | +| TP-E-005 | AH_REPORT_ETC_005, AH_REPORT_ETC_006, AH_REPORT_ETC_011, AH_REPORT_ETC_012 | 已覆盖 | +| TP-E-006 | AH_REPORT_ETC_007 | 已覆盖 | +| TP-E-007 | AH_REPORT_ETC_008 | 已覆盖 | +| TP-E-008 | AH_REPORT_ETC_009 | 已覆盖 | +| TP-E-009 | AH_REPORT_ETC_010 | 已覆盖 | +| TP-F-001 | AH_REPORT_APL_001 | 已覆盖 | +| TP-F-002 | AH_REPORT_APL_003 | 已覆盖 | +| TP-F-003 | AH_REPORT_APL_004, AH_REPORT_APL_005 | 已覆盖 | +| TP-F-004 | AH_REPORT_APL_006 | 已覆盖 | +| TP-F-005 | AH_REPORT_APL_007, AH_REPORT_APL_016 | 已覆盖 | +| TP-F-006 | AH_REPORT_APL_002 | 已覆盖 | +| TP-F-007 | AH_REPORT_APL_008 | 已覆盖 | +| TP-F-008 | AH_REPORT_APL_009 | 已覆盖 | +| TP-F-009 | AH_REPORT_APL_010, AH_REPORT_APL_017 | 已覆盖 | +| TP-F-010 | AH_REPORT_APL_011 | 已覆盖 | +| TP-F-011 | AH_REPORT_APL_012, AH_REPORT_APL_013 | 已覆盖 | +| TP-F-012 | AH_REPORT_APL_005, AH_REPORT_APL_014 | 已覆盖 | +| TP-F-013 | AH_REPORT_APL_015 | 已覆盖 | +| TP-G-001 | AH_REPORT_LOG_001, AH_REPORT_LOG_002 | 已覆盖 | +| TP-G-002 | AH_REPORT_LOG_003 | 已覆盖 | +| TP-G-003 | AH_REPORT_LOG_004 | 已覆盖 | +| TP-G-004 | AH_REPORT_LOG_005 | 已覆盖 | +| TP-G-005 | AH_REPORT_LOG_006 | 已覆盖 | +| TP-G-006 | AH_REPORT_LOG_007 | 已覆盖 | +| TP-G-007 | AH_REPORT_LOG_008 | 已覆盖 | +| TP-G-008 | AH_REPORT_LOG_009 | 已覆盖 | +| TP-G-009 | AH_REPORT_LOG_010 | 已覆盖 | +| TP-X-001 | AH_REPORT_CROSS_001 | 已覆盖 | +| TP-X-002 | AH_REPORT_CROSS_002 | 已覆盖 | +| TP-X-003 | AH_REPORT_CROSS_003 | 已覆盖 | +| TP-X-004 | AH_REPORT_CROSS_004 | 已覆盖 | +| TP-X-005 | AH_REPORT_CROSS_005 | 已覆盖 | +| TP-X-006 | AH_REPORT_CROSS_007 | 已覆盖 | + +所有132个测试点均已映射到至少一条测试用例。 + +--- + +## 历史缺陷防御映射表 + +| 历史缺陷ID | 防御用例 | 备注 | +| :--- | :--- | :--- | +| BUG-202607-01（阶段依赖链断裂） | AH_REPORT_R1_007, AH_REPORT_R1_008, AH_REPORT_R2_024, AH_REPORT_R3_006, AH_REPORT_R3_007, AH_REPORT_CROSS_001 | 后端三重前置状态校验覆盖 | +| BUG-202607-02（重试幂等缺陷） | AH_REPORT_R1_013, AH_REPORT_R1_014, AH_REPORT_R2_025, AH_REPORT_R3_011, AH_REPORT_ETC_009, AH_REPORT_CROSS_006 | 分布式锁+唯一约束+前端防抖覆盖 | +| BUG-202607-03（跨模块数据不一致） | AH_REPORT_R2_002, AH_REPORT_R2_003, AH_REPORT_R3_013, AH_REPORT_CROSS_002 | 数据来源溯源验证覆盖 | +| BUG-202607-04（省份代码硬编码） | AH_REPORT_R1_006, AH_REPORT_CROSS_005 | 省份代码动态配置+多省份隔离覆盖 | + +--- + +## 漏测清单覆盖汇总 + +| 漏测类别 | 覆盖用例数 | 覆盖状态 | +| :--- | :--- | :--- | +| 空值/Null处理 | AH_REPORT_R1_018 (1条) | 已覆盖 | +| 金额精度 | AH_REPORT_R2_002, AH_REPORT_R3_012, AH_REPORT_ETC_008 (3条) | 已覆盖 | +| 重复提交/防抖 | AH_REPORT_R1_013, AH_REPORT_R1_014, AH_REPORT_R2_025, AH_REPORT_R3_011, AH_REPORT_ETC_009 (5条) | 已覆盖 | +| 超时处理 | AH_REPORT_R1_015, AH_REPORT_R1_016, AH_REPORT_APL_015 (3条) | 已覆盖 | +| 列表字段完整性 | AH_REPORT_DASH_011, AH_REPORT_R2_004, AH_REPORT_R3_002, AH_REPORT_ETC_002, AH_REPORT_APL_003, AH_REPORT_LOG_006 (6条) | 已覆盖 | +| 查询重置 | AH_REPORT_DASH_010 (1条) | 已覆盖 | +| 状态与按钮映射 | AH_REPORT_DASH_013, AH_REPORT_R1_012 (2条) | 已覆盖 | +| 多阶段依赖链 | AH_REPORT_R1_007, AH_REPORT_R2_024, AH_REPORT_R3_007, AH_REPORT_CROSS_001 (4条) | 已覆盖 | +| 第三方核验逐项覆盖 | AH_REPORT_R2_005~AH_REPORT_R2_023 (14条，7类×通过+异常) + AH_REPORT_R2_030~AH_REPORT_R2_053 (24条，API文档12项补充核验×通过+异常) = 共38条覆盖API文档17项核验 | 已覆盖 | +| 重试+手动触发并发 | AH_REPORT_R1_013, AH_REPORT_R2_025, AH_REPORT_CROSS_006 (3条) | 已覆盖 | +| 跨模块数据一致性 | AH_REPORT_R2_002, AH_REPORT_R2_003, AH_REPORT_CROSS_002 (3条) | 已覆盖 | +| 省份/区域配置隔离 | AH_REPORT_R1_006, AH_REPORT_CROSS_005 (2条) | 已覆盖 | +| 上报数据字段溯源 | AH_REPORT_R2_002, AH_REPORT_R3_013, AH_REPORT_CROSS_002 (3条) | 已覆盖 | +| 标签颜色映射 | AH_REPORT_DASH_012, AH_REPORT_R1_023, AH_REPORT_R2_004 (3条) | 已覆盖 | +| 详情弹窗分组完整性 | AH_REPORT_DASH_014, AH_REPORT_DASH_015, AH_REPORT_R1_022, AH_REPORT_R3_003, AH_REPORT_ETC_003, AH_REPORT_APL_006 (6条) | 已覆盖 | +| 轨迹数据边界(2~2000) | AH_REPORT_R2_020, AH_REPORT_R2_021, AH_REPORT_R2_022, AH_REPORT_R2_023 (4条) | 已覆盖 | +| 申诉闭环 | AH_REPORT_APL_001, AH_REPORT_APL_002, AH_REPORT_APL_004 (3条) | 已覆盖 | +| 操作日志可追溯 | AH_REPORT_LOG_006, AH_REPORT_LOG_007, AH_REPORT_LOG_008, AH_REPORT_LOG_009, AH_REPORT_LOG_010 (5条) | 已覆盖 | + +--- + +> ⚠️ 待确认项： +> 1. 需求中"异常代码一览表"章节仅有标题无具体内容，需与产品确认完整的异常代码映射表后补充 AH_REPORT_APL_012 的详细验证数据。 +> 2. 自动重试的具体间隔时间（当前用例中使用5s/15s/30s为参考值），需与技术方案确认后更新 AH_REPORT_R1_010, AH_REPORT_R2_026, AH_REPORT_R3_010, AH_REPORT_ETC_007 中的重试间隔。 +> 3. ETC税额边界值（0.01元 → 税额=0.00）的四舍五入规则需与财务确认，更新 AH_REPORT_ETC_008。 +> 4. 申诉超时告警阈值（当前用例中使用7个工作日为参考值）需与产品确认，更新 AH_REPORT_APL_015。 +> 5. 建议在后续需求评审中人工确认安徽运八与现有云南运八上报逻辑是否存在字段/接口冲突。 +> 6. 部分用例中使用的模拟数据（如运单号YB202607130004~YB202607130057等）为测试用例设计时分配的虚拟编号，实际执行时需替换为测试环境中真实存在的运单数据。 +> 7. 涉及省平台回调的用例（如申诉复核反馈、核验结果返回），实际执行时需确认是否有省平台测试环境或mock工具支持。 diff --git a/output/versions/安徽运八需求/v3/安徽运八需求_测试用例.xlsx b/output/versions/安徽运八需求/v3/安徽运八需求_测试用例.xlsx new file mode 100644 index 0000000..521f6d7 Binary files /dev/null and b/output/versions/安徽运八需求/v3/安徽运八需求_测试用例.xlsx differ diff --git a/output/versions/安徽运八需求/v4/normalized_inputs/requirement.md b/output/versions/安徽运八需求/v4/normalized_inputs/requirement.md new file mode 100644 index 0000000..95a9d8e --- /dev/null +++ b/output/versions/安徽运八需求/v4/normalized_inputs/requirement.md @@ -0,0 +1,164 @@ +# 安徽运八需求 + +> 文档角色：需求文档 +> 原始来源：`source_docs\requirements_raw\安徽运八需求.docx` + +安徽运八需求 +一、需求概述 +根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将税源地为安徽运八的运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八），其他税源地不走此逻辑。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。本功能模块旨在实现上报流程的自动化管理，并提供异常监控与向平台发起申诉的能力。 +二、功能说明 +2.1 上报运单看板 +· 功能描述 +上报运单看板是系统的首页，集中展示所有上报阶段运单的汇总状态，支持按条件筛选、查看详情和发起申诉。 +· 查询条件 +运单号/托运单号/货源单号：模糊搜索 +上报阶段：全部 / 第一次上报 / 第二次上报 / 第三次上报 +核验状态：全部 / 异常 / 通过 +申诉状态：全部 / 未申诉 / 申诉中 / 申诉通过 / 申诉驳回 +操作按钮：查询、重置、导出 +· 列表字段 +货源单号、运单号、托运单号、车牌号、司机姓名、 +托运方名称、上报阶段、核验状态、申诉状态、异常项、 +货物名称、合同金额、最新核验时间、操作（申诉/进度/详情） +2.2 第一次上报（装货完成） +功能描述 +第一次上报在运单装货完成后自动触发（仅上传货源税源地为安徽运八的运单，其他税源地无需上传），上报数据包含运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息、保险信息等。 +特殊说明 +• 上报完成后，若安徽运八平台核验通过，系统会自动调用“修改第一次上报部分字段”接口，更新装货后可能发生变化的字段（如实际里程），无需人工干预。 +• 若上报失败，系统需要自动重试（最多3次），若仍失败则通过系统站内信或者其他方式通知运营人员。 +• 第一次上传是后续两次上传的基础，若失败会导致后续上报无法进行，需重点关注。 +上报状态规则 +| 状态 | 说明 | 操作按钮 | 标签颜色 | +| 上传中 | 数据正在上报中 | 无 | 蓝色 | +| 已上传 | 上报成功 | 无 | 绿色 | +| 上传失败 | 上报超时 | 手动上传 | 红色 | +| 异常 | 数据校验不通过 | 详情查看异常原因 | 橙色 | +列表字段 +货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、业务类型、货物名称、装货地址、卸货地址、运输里程、合同编号、上报状态、操作（详情） +详情弹窗字段分组 +详情弹窗按以下子对象分组展示： +建单信息（必选，13字段）：上游企业委托运输单号、本运单单号、托运人建单时间、网络货运经营者名称、统一社会信用代码、道路运输经营许可证编号、业务类型代码、运输组货方式代码、司机接单时间、司机起运时间、承运合同编号、委托合同编号（可选）、运输里程（可选） +托运人信息（必选，7字段）：托运人名称、托运人统一社会信用代码、框架合同编号（可选）、装货地点、装货经度、装货纬度、装货地行政区划代码 +收货方信息（必选，5字段）：收货方名称、收货方统一社会信用代码/身份证号、收货地点、收货经度、收货纬度 +司机信息（必选，13字段）：司机姓名、身份证号、驾驶证号、驾驶证发证机关、从业资格证号、从业资格证有效期起、从业资格证有效期至、税务登记证号、手机号、驾驶证有效期起、驾驶证有效期至、准驾车型、省份代码 +接单车辆信息（必选，19字段）：车牌号、车牌颜色编码、号牌种类、车辆识别代号VIN)、车主姓名/单位名称、车主证件号、使用性质、车辆类型、能源类型、注册日期、发证日期、发证机关、核定载质量吨)、总质量吨)、道路运输证号、挂车牌照号（可选）、行驶证档案编号（可选）、道路运输证有效期起（可选）、道路运输证有效期至（可选） +货物信息（必选，可多条，4字段）：货物名称、货物类型代码、货物量、计量单位 +保险信息（可选，2字段）：保险单号、保险公司名称 +异常信息：核验状态、异常原因、异常时间、处理状态 +2.3 第二次上报（打款完成） +功能描述 +第二次上报在运费支付完成后系统自动触发，上报数据包含运抵信息、货主资金流水、承运人资金流水、承运合同信息、委托合同信息、车辆轨迹信息等。 +特殊说明 +• 第二次上传核验项最多，是最容易出现异常的环节，需要重点关注。 +• 若资金流水单号重复，会导致上报失败，系统会自动检查并提示。 +• 车辆轨迹点位数量不足或偏差过大，会导致"车辆轨迹合规"核验异常，可通过"补传轨迹"功能补充轨迹数据。 +• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。 +列表字段 +货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、承运运费、总金额、付款方式、付款时间、收款人、收款账号、收款账号类型、核验状态、异常项、上报状态、操作（上报/详情） +收款账号类型说明 +• 个人账户：司机个人银行卡账号，标签为蓝色 +• 对公账户：企业银行账号，标签为绿色 +详情弹窗字段分组 +（1）运单信息（必选）：同第一次上报 +（2）托运方信息（必选）：同第一次上报 +（3）收货方信息（必选）：同第一次上报 +（4）资金流水信息（必选）：支付金额、支付方式、支付时间、付款方名称、收款方名称、收款人、收款账号、收款账号类型、流水号、支付状态 +（5）车辆轨迹信息（必选，可多条，2~2000个点）：定位类型、定位时间、定位地点、经度、纬度、轨迹类型 +（6）异常信息：核验状态、异常原因、异常时间、处理状态 +核验内容（监管平台自动核验，异常时可发起申诉） +| 核验项 | 说明 | +| 运单重复核验 | 检查同一运单是否重复上报 | +| 车辆资质核验 | 检查车辆道路运输证是否在有效期内 | +| 司机资质核验 | 检查司机从业资格证是否在有效期内 | +| 集中支付核验 | 检查资金流水是否通过网货平台集中支付 | +| 资金流水核验 | 检查资金流水单号是否重复、金额是否匹配 | +| 合同核验 | 检查运输合同和委托合同是否有效 | +| 车辆轨迹合规核验 | 检查车辆轨迹是否真实、与运单路线是否匹配 | +2.4 第三次上报（开票完成） +功能描述 +第三次上报在发票开具完成后触发，上报数据包含运单信息（托运单号数组）、发票信息、油气发票信息等。 +特殊说明 +• 第三次上传需要在运单完成第二次上传后方可进行。 +• 若增值税发票验证失败，会导致上报失败，需检查发票信息是否正确。 +• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。 +列表字段 +货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、发票号码、发票金额、开票日期、核验状态、异常原因、上报状态、操作（详情） +详情弹窗字段分组 +（1）运单信息（必选）：同第一次上报 +（2）发票信息（必选，17字段）：托运单号数组、发票号码、发票代码号、发票金额价税合计)、开票日期、销售方名称、销售方纳税人识别号、销售方地址、销售方电话、销售方开户行、销售方银行账户、受票方名称、受票方纳税人识别号、受票方地址、受票方电话、受票方开户行、受票方银行卡号 +（3）油气发票信息（可选，可多条）：油气托运单号、油气发票文件 +（4）异常信息：核验状态、异常原因、异常时间、处理状态 +2.5 ETC发票上传 +功能描述 +ETC发票上传用于上报车辆通行高速公路的ETC发票信息，作为税务抵扣凭证。 +特殊说明 +• ETC发票上传需要在税务抵扣完成后进行，否则会导致上报失败。 +• 若ETC发票验证失败，会导致上报失败，需检查发票信息是否正确。 +• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。 +列表字段 +货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、ETC发票号码、发票金额、税率、上传状态、操作（详情） +详情弹窗字段分组 +（1）运单信息：运单号、货源单号、托运单号、车牌号、司机姓名、托运方名称、收货方名称 +（2）ETC发票信息（每张发票18字段）：ETC发票号码、ETC发票代码、开票时间、发票金额、税率、税额、价税合计、销售方名称、销售方税号、受票方名称、受票方税号、入口收费站、出口收费站、交易时间、交易金额、交易匹配时间、交易流水号、ETC发票文件 +（3）异常信息：核验状态、异常原因、异常时间、处理状态 +2.6 异常申诉功能 +运单完成第二次上传后，安徽省管理平台自动进行 7 大类核验（车辆资质、司机资质、资金流水、合同、轨迹等）。如核验结果为异常时，运营人员可通过申诉机制向平台说明情况并申请重新核验。 +本模块补全“异常查询 → 发起申诉 → 跟踪监管平台反馈 → 合规判断”的完整闭环。 +当上报数据被核验为异常时，运营人员可发起申诉，向安徽监管平台说明情况并申请重新核验。申诉记录管理页面展示所有申诉记录及省平台反馈结果。 +列表字段 +运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、异常项、申诉状态、申诉时间、申诉人、省平台反馈结果、监管平台反馈时间、操作（详情/重新申诉） +详情弹窗字段分组 +（1）申诉信息：申诉单号、上报阶段、异常项、申诉原因、申诉状态、申诉时间、申诉人、申诉附件 +（2）运单信息：运单号、托运单号、车牌号、司机姓名、托运方名称 +（3）异常信息：核验状态、异常原因、异常时间 +（4）省平台反馈信息：反馈结果、反馈时间、反馈意见 +（5）处理记录：操作人、操作时间、操作类型、操作内容（时间线展示） +申诉复核说明 +（注：申诉由安徽监管平台复核，非我方审核） +（复核不通过时，可补充材料后重新发起申诉） +异常代码一览表 +2.7 上报日志 +功能描述 +上报日志记录所有上报接口的调用记录，用于问题排查和审计。 +查询条件 +• 运单号/托运单号/货源单号：模糊搜索 +• 上报阶段：全部 / 第一次上报 / 第二次上报 / 第三次上报 / ETC上传 +• 上报结果：全部 / 成功 / 失败 +• 开始时间 ~ 结束时间：时间范围筛选 +列表字段 +序号、货源单号、运单号、托运单号、上报阶段、上报结果、接口URL、HTTP状态码、响应时间、上报时间、操作（弹窗详情查看完整请求/响应报文） +三. 数据字段说明 +3.1 第一次上报字段（装货完成） +核心子对象及必选字段： +• waybillInfo（建单信息）：originalDocumentNumber、shippingNoteNumber、documentCreateTime、carrier、unifiedSocialCreditIdentifier、permitNumber、businessTypeCode、goodsArrangementTypeCode、orderReceivingTime、departureTime、commercialContractNumber、contractNumber、mileage +• consignorInfo（托运人信息）：consignor、consignorId、frameContractNumber、placeOfLoading、loadingLongitude、loadingLatitude、loadingCountrySubdivisionCode +• consigneeInfo（收货方信息）：consignee、consigneeId、goodsReceiptPlace、unLoadingLongitude、unLoadingLatitude +• driverInfo（司机信息）：driverName、drivingIdNumber、drivingLicense、issuingOrganizations、qualificationCertificate、qualificationCertificateFrom、qualificationCertificateTo、taxRegistrationCertificate、telephone、validPeriodFrom、validPeriodTo、vehicleClass、provinceCode +• carInfo（接单车辆信息）：vehicleNumber、vehiclePlateColorCode、LicensePlateTypeCode、vin、owner、ownerId、useCharacter、vehicleType、vehicleEnergyType、registerDate、issueDate、issuingOrganizations、vehicleTonnage、grossMass、roadTransportCertificateNumber、trailerVehiclePlateNumber、vehicleLicenseNumbe、roadTransportSocialCreditFrom、roadTransportSocialCreditTo +• goodsInfos（货物信息，可多条）：descriptionOfGoods、cargoTypeClassificationCode、quantity、unit +• insuranceInformation（保险信息，可选）：policyNumber、insuranceCompany +3.2 第二次上报字段（打款完成） +新增字段说明： +• 收款人（自定义扩展字段）：对应资金流水中的收款方名称recipient) +• 收款账号（自定义扩展字段）：对应资金流水中的收款账号receiptAccount) +• 收款账号类型（自定义扩展字段）：个人账户 / 对公账户，为我方自定义列 +3.3 第三次上报字段（开票完成） +核心字段： +• 发票号码（invoiceNo）：增值税发票号码 +• 发票代码（invoiceCode）：增值税发票代码 +• 发票金额（invoiceAmount）：价税合计（保留2位小数） +（注：第三次上传的invoice无税率字段，税率仅出现在ETC发票上传中） +• 销售方名称（sellerName）：开票方企业名称 +• 受票方名称（buyerName）：托运人/货主企业名称 +3.4 ETC发票字段 +核心字段： +• ETC发票号码（etcInvoiceNo）：高速公路通行费电子发票号码 +• 入口收费站（entryStation）：通行入口 +• 出口收费站（exitStation）：通行出口 +• 税额（taxAmount）：可抵扣税额（税率3%） +详细数据接口字段请查阅上报接口： +https://www.showdoc.com.cn/2210641821476236/9919735893682511 +密码：szjj@2023 +原型文件路径： +"E:\WeChat\xwechat_files\wxid_2n9ko0aq1th822_44c3\msg\file\2026-07\anhuibaba_index.html" +接口文档路径："E:\Downloads\网货企业端接口文档（最新）.pdf" diff --git a/output/versions/安徽运八需求/v4/normalized_inputs/requirement_restructured.md b/output/versions/安徽运八需求/v4/normalized_inputs/requirement_restructured.md new file mode 100644 index 0000000..3c9c826 --- /dev/null +++ b/output/versions/安徽运八需求/v4/normalized_inputs/requirement_restructured.md @@ -0,0 +1,506 @@ +# 安徽运八需求（以API文档为准重构） + +> **重构原则**: API接口文档(网货企业端接口文档 V1.0.2) 为权威数据源，HTML原型为UI参考，原始需求文档为业务背景补充。 +> **重构时间**: 2026-07-13 +> **原始需求**: `source_docs/requirements_raw/安徽运八需求.docx` +> **API文档**: `E:\Downloads\网货企业端接口文档（最新）.pdf` V1.0.2 (2023-04) +> **原型**: `anhuibaba_index.html` + +--- + +## 一、系统边界 + +本需求涉及两套系统的对接： + +| 系统 | 职责 | 本文档覆盖 | +|:---|:---|:---| +| **运八平台（我方）** | 自动触发三阶段上报、ETC上传；查询核验结果；发起/跟踪申诉；查看上报日志 | 全量 | +| **安徽省级网络货运监测系统（省平台）** | 接收上报数据；执行核验；受理申诉并反馈 | 仅接口交互 | + +API文档覆盖的是**运八平台→省平台**的查询和申诉接口。上报触发逻辑（装货完成/打款完成/开票完成自动触发）属于运八平台内部业务逻辑，API文档中未定义上报提交接口。 + +--- + +## 二、API接口清单（权威来源：接口文档 V1.0.2） + +### 2.1 通用规范 + +| 项目 | 规范 | +|:---|:---| +| 基地址 | `http://*******/api/` | +| 协议 | HTTP POST | +| 请求格式 | JSON（除上传文件接口外） | +| 响应格式 | `{"code":200, "message":"操作成功", "data":{}}` | +| 认证 | JWT Token，调用 `/sys/login` 获取，除登录接口外均需在请求头携带 | +| 时间格式 | `yyyy-MM-dd HH:mm:ss` | +| 成功码 | `code=200` | +| 失败码 | `code=500` | + +### 2.2 接口一览（共9个） + +| # | 接口 | URL | 说明 | +|:---:|:---|:---|:---| +| 1 | 获取token | `POST /sys/login` | JWT认证，参数: loginName, loginPassword | +| 2 | 上传申诉附件 | `POST /appeal/uploadFile` | 文件上传，参数: file (File) | +| 3 | 提交申诉运单 | `POST /appeal/insert` | 发起申诉，参数: freightSheetNumber, complaintNumber, attachmentUrl, content, verificationAbnormalItems | +| 4 | 查询异常运单信息 | `POST /verificationSummary/page` | 分页查询，支持多维度筛选 | +| 5 | 查询申诉进度 | `POST /appeal/page` | 分页查询申诉记录及审核结果 | +| 6 | 查询运单核验详情 | `POST /verificationSummary/verificationDetail` | 单运单全部核验项明细 | +| 7 | 查询发票是否合规 | `POST /verificationSummary/cargoOwnerInvoiceInfo` | 判断托运人发票系统核验是否合规 | +| 8 | 运单里程核验查询 | `POST /verificationSummary/mileageVerificationInfo` | 批量查询运单里程核验状态 | +| 9 | 运单里程申诉 | `POST /mileageAppeal/insert` | 对里程核验结果发起申诉 | + +### 2.3 接口详细定义 + +#### 接口1: 获取token +``` +POST /sys/login +请求: { "loginName": "xxx", "loginPassword": "xxx" } +响应: { "code": 200, "data": { "token": "...", "expireTime": 1681219619843, "loginName": "ceshi", "name": "测试" } } +``` + +#### 接口2: 上传申诉附件 +``` +POST /appeal/uploadFile +请求: multipart/form-data, 字段 file (File) +``` + +#### 接口3: 提交申诉运单 +``` +POST /appeal/insert +请求: + freightSheetNumber String 运单号 必填 + complaintNumber String 申诉编号 必填 + attachmentUrl String 申诉附件URL 必填 + content String 申诉内容 必填 + verificationAbnormalItems String 核验异常项ID 必填 (逗号分隔，如"120,160") +``` + +#### 接口4: 查询异常运单信息 +``` +POST /verificationSummary/page +请求: + pageIndex int 页码 必填 + pageSize int 每页条数 必填 + freightSheetNumber String 运单号 可选 + verificationAbnormalItems String 异常项ID 可选 (多个逗号拼接) + driverName String 驾驶员姓名 可选 + driverIdCard String 驾驶员身份证号 可选 + vehicleNumber String 车牌号 可选 + appealStateId int 申诉状态ID 可选 + verifyStateId int 核验状态ID 可选 + beginTime ~ endTime 运单创建时间范围 可选 + beginFirstVerifyTime ~ endFirstVerifyTime 首次核验时间范围 可选 + beginLastVerifyTime ~ endLastVerifyTime 最新核验时间范围 可选 + beginInsertTime ~ endInsertTime 插入时间范围 可选 + +响应: + pageRecords[]: + freightSheetNumber String 运单号 + appealStateId int 申诉状态ID + appealStateName String 申诉状态名称 + verificationAbnormalItem String 核验异常项 + createTime date 运单创建时间 + lastVerifyTime date 最新核验时间 + firstVerifyTime date 首次核验时间 + vehicleNumber String 车牌号 + driverName String 驾驶员姓名 + driverIdCard String 驾驶员身份证号 + verifyStateId int 核验状态ID + verifyStateName String 核验状态名称 + abnormalDetails[]: + id int 异常项ID + name String 异常项名称 + message String 异常原因 + time date 异常时间 + state int 异常项处理状态 (100=未申诉, 110=申诉中) +``` + +#### 接口5: 查询申诉进度 +``` +POST /appeal/page +请求: + pageIndex int 页码 必填 + pageSize int 每页条数 必填 + freightSheetNumber String 运单号 可选 + abnormalTypeId String 核验异常项ID 可选 + auditStateId String 审核状态ID 可选 + beginTime ~ endTime 申诉时间范围 可选 + auditBeginTime ~ auditEndTime 审核时间范围 可选 + complaintNumber String 申诉编号 可选 + +响应: + pageRecords[]: + complaintNumber String 申诉编号 + freightSheetNumber String 运单号 + content String 申诉内容 + complainantName String 申诉人 + auditStateId int 审核状态ID + auditStateName String 审核状态名称 + auditorName String 审核人 + auditRemark String 审核备注 + auditTime date 审核时间 + verificationAbnormalItem String 运单异常项 + cancelPerson String 取消人 + cancelReason String 取消原因 + cancelTime date 取消时间 + revokeUserName String 撤回人 + revokeTime date 撤回时间 + createTime date 创建时间 + appealAbnormalList[]: + verificationTypeId int 异常项ID + verificationTypeName String 异常项名称 +``` + +#### 接口6: 查询运单核验详情 +``` +POST /verificationSummary/verificationDetail +请求: + freightSheetNumber String 运单号 必填 + beginInsertTime String 插入时间-开始 可选 + endInsertTime String 插入时间-结束 可选 + +响应: + pageRecords[].details[]: + verificationCode int 核验项编码 + verificationName String 核验项名称 + verificationState String 核验状态 + verificationStateId int 核验状态ID + verificationTime date 核验时间 + message String 核验信息 +``` + +#### 接口7: 查询发票是否合规 +``` +POST /verificationSummary/cargoOwnerInvoiceInfo +请求: { "freightSheetNumber": "55141359" } +响应: { "isSystemVerification": true } // true=系统核验合规, false=人工判定合规 +``` + +#### 接口8: 运单里程核验查询 +``` +POST /verificationSummary/mileageVerificationInfo +请求: { "freightSheetNumberList": ["22222222", "111111"] } +响应: [ + { "verificationStateId": 110, "freightSheetNumber": "22222222", "mileage": 350.263 }, + { "verificationStateId": null, "freightSheetNumber": "4658151", "mileage": null } +] +// 注: 运单未上报里程时 verificationStateId 和 mileage 为 null +``` + +#### 接口9: 运单里程申诉 +``` +POST /mileageAppeal/insert +请求: + freightSheetNumber String 运单号 必填 + content String 申诉内容 必填 + complaintNumber String 申诉编号 必填 + mileage String 里程数 必填 +``` + +--- + +## 三、数据字典（权威来源：接口文档 §4.1~§4.5） + +### 3.1 异常项ID对照表（§4.1）— 共17项 + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 委托合同 | 托运人与承运人签订的委托运输合同核验 | +| 120 | 承运合同 | 承运人以自身名义签订的运输合同核验 | +| 130 | 实时定位 | 车辆实时定位数据核验 | +| 140 | 运单时间逻辑 | 运单各时间节点的逻辑合理性核验（如装货时间<卸货时间） | +| 150 | 车辆资质 | 车辆道路运输经营许可证有效性核验 | +| 160 | 道路运输证 | 车辆道路运输证有效期核验 | +| 170 | 驾驶证 | 驾驶员驾驶证有效性核验 | +| 180 | 从业资格证 | 驾驶员从业资格证有效期核验 | +| 190 | 车辆重复 | 同一车辆在同一时段是否存在多运单 | +| 200 | 司机重复 | 同一司机在同一时段是否存在多运单 | +| 210 | 车辆轨迹 | GPS轨迹真实性、与运单路线匹配度核验 | +| 220 | 运费收款 | 运单是否在运费收款方名下 | +| 230 | 公司统一收款 | 是否通过公司账户统一收款 | +| 240 | 集中支付 | 是否通过网络货运平台集中支付 | +| 250 | 资金流水 | 资金流水单号唯一性、金额匹配核验 | +| 260 | 发票信息 | 托运人发票信息核验（第三次上报相关） | +| 270 | 非通行车辆可开票 | 非通行车辆是否允许开具通行费发票 | + +### 3.2 运单核验状态（§4.2） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未核验 | 运单尚未被省平台核验 | +| 110 | 核验通过 | 全部核验项通过 | +| 120 | 全部异常 | 存在核验不通过的异常项 | + +### 3.3 运单部分核验状态（§4.3） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未核验 | 尚未核验 | +| 110 | 部分核验 | 部分核验项已通过，仍有待核验项 | +| 120 | 全部核验 | 全部核验项已出结果 | + +### 3.4 运单申诉状态（§4.4）— 权威枚举 + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| **100** | **未申诉** | 尚未发起申诉 | +| **110** | **审核通过** | 省平台审核通过 | +| **120** | **审核不通过** | 省平台审核驳回 | +| **130** | **已取消** | 申诉已取消（原始需求未提及此状态） | + +> **与原始需求的差异**: +> - 原始需求: 未申诉 / 申诉中 / 申诉通过 / 申诉驳回 +> - API文档: 未申诉(100) / 审核通过(110) / 审核不通过(120) / 已取消(130) +> - **API文档为权威来源**。原始需求的"申诉中"在API中对应"未申诉(100)"状态下的一个进行中标记（接口4响应中 abnormalDetails[].state=110 表示申诉中）。 +> - 原型中的"待省平台反馈"和"反馈处理中"为UI层面的展示状态，非后端枚举值。 + +### 3.5 附件状态（§4.5） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未处理 | 申诉附件尚未被省平台处理 | +| 110 | 处理通过 | 附件核验通过 | +| 120 | 处理异常 | 附件核验异常 | + +--- + +## 四、功能模块（综合API文档+原型+原始需求） + +### 4.1 上报运单看板 + +**入口**: 侧边栏 → 上报运单看板 + +**统计卡片**（原型定义）: +- 异常运单数、待申诉数、申诉中数、已处理数 + +**查询条件**（综合原型+接口4请求参数）: + +| 筛选项 | 类型 | 可选值 | +|:---|:---|:---| +| 运单号/托运单号/货源单号 | 文本输入 | 模糊搜索 | +| 上报阶段 | 下拉 | 全部 / 第一次上报 / 第二次上报 / 第三次上报 | +| 核验状态 | 下拉 | 全部 / 异常 / 通过 | +| 申诉状态 | 下拉 | 全部 / 未申诉(100) / 审核通过(110) / 审核不通过(120) / 已取消(130) | + +**列表字段**（原型为准，15列含勾选）: +货源单号 / 运单号 / 托运单号 / 车牌号 / 司机姓名 / 上报阶段 / 托运方名称 / 核验状态 / 申诉状态 / 异常项 / 货物名称 / 合同金额 / 最新核验时间 / 操作 + +**操作按钮**: +- 异常运单: [申诉] [详情] +- 申诉中运单: [进度] [详情] +- 正常运单: [详情] + +**标签颜色**（原型CSS定义）: +- 蓝色 `.tag-blue`: 上传中、申诉中 +- 绿色 `.tag-green`: 已上传、通过、已完成、申诉通过、对公账户 +- 红色 `.tag-red`: 上传失败、异常、申诉驳回 +- 橙色 `.tag-orange`: 异常项标签、待上报 +- 灰色 `.tag-gray`: 未申诉 +- 紫色 `.tag-purple`: (预留) + +### 4.2 第一次上报（装货完成） + +**触发条件**: 运单装货完成 AND 货源税源地=安徽 + +**上报数据子对象**（以接口文档字段定义为准）: + +| 子对象 | 必选/可选 | 核心字段 | +|:---|:---|:---| +| waybillInfo（建单信息） | 必选 | originalDocumentNumber, shippingNoteNumber, documentCreateTime, carrier, unifiedSocialCreditIdentifier, permitNumber, businessTypeCode, goodsArrangementTypeCode, orderReceivingTime, departureTime, commercialContractNumber, contractNumber(可选), mileage(可选) | +| consignorInfo（托运人信息） | 必选 | consignor, consignorId, frameContractNumber(可选), placeOfLoading, loadingLongitude, loadingLatitude, loadingCountrySubdivisionCode | +| consigneeInfo（收货方信息） | 必选 | consignee, consigneeId, goodsReceiptPlace, unLoadingLongitude, unLoadingLatitude | +| driverInfo（司机信息） | 必选 | driverName, drivingIdNumber, drivingLicense, issuingOrganizations, qualificationCertificate, qualificationCertificateFrom, qualificationCertificateTo, taxRegistrationCertificate, telephone, validPeriodFrom, validPeriodTo, vehicleClass, provinceCode | +| carInfo（车辆信息） | 必选 | vehicleNumber, vehiclePlateColorCode, LicensePlateTypeCode, vin, owner, ownerId, useCharacter, vehicleType, vehicleEnergyType, registerDate, issueDate, issuingOrganizations, vehicleTonnage, grossMass, roadTransportCertificateNumber, trailerVehiclePlateNumber(可选), vehicleLicenseNumbe(可选), roadTransportSocialCreditFrom(可选), roadTransportSocialCreditTo(可选) | +| goodsInfos（货物信息） | 必选，可多条 | descriptionOfGoods, cargoTypeClassificationCode, quantity, unit | +| insuranceInformation（保险信息） | 可选 | policyNumber, insuranceCompany | + +**业务规则**: +- 仅安徽税源地(省份代码=34，非28)运单触发 +- 上报成功后自动调用"修改第一次上报部分字段"接口更新变化字段 +- 失败自动重试最多3次，全部失败后站内信通知运营 +- 第一次上报是后续上报的前置条件（后端校验） + +**列表页**（原型为准，14列+勾选）: +货源单号 / 运单号 / 托运单号 / 车牌号 / 司机姓名 / 托运方名称 / 业务类型 / 货物名称 / 装货地址 / 卸货地址 / 运输里程 / 合同编号 / 上报状态 / 操作 + +**上报状态**（内部系统状态，非API枚举）: +- 上传中（蓝色） +- 已上传（绿色） +- 上传失败（红色）— 显示"手动上传"按钮 +- 异常（橙色） + +### 4.3 第二次上报（打款完成） + +**触发条件**: 财务打款完成 AND 第一次上报已完成 + +**核验项**: 省平台自动核验，共17项（见§3.1）。每项独立产生核验结果，核验异常项可通过申诉机制逐项申诉。 + +**上报数据子对象**: +| 子对象 | 必选/可选 | 核心字段 | +|:---|:---|:---| +| waybillInfo | 必选 | （同第一次上报） | +| consignorInfo | 必选 | （同第一次上报） | +| consigneeInfo | 必选 | （同第一次上报） | +| 资金流水信息 | 必选 | 支付金额、支付方式、支付时间、付款方名称、收款方名称、收款人、收款账号、收款账号类型、流水号、支付状态 | +| 车辆轨迹信息 | 必选，2~2000点 | 定位类型、定位时间、定位地点、经度、纬度、轨迹类型 | + +**列表页**（原型为准，17列+勾选）: +货源单号 / 运单号 / 托运单号 / 车牌号 / 司机姓名 / 托运方名称 / 承运运费 / 总金额 / 付款方式 / 付款时间 / 收款人 / 收款账号 / 收款账号类型 / 核验状态 / 异常项 / 上报状态 / 操作 + +**收款账号类型标签**: 个人账户=蓝色, 对公账户=绿色 + +### 4.4 第三次上报（开票完成） + +**触发条件**: 发票开具完成 AND 第二次上报已完成 + +**前置条件**: 第二次上报必须完成（后端校验） + +**API关联接口**: +- `POST /verificationSummary/cargoOwnerInvoiceInfo` — 查询托运人发票系统核验是否合规 +- 响应: `isSystemVerification`: true=系统核验合规, false=人工判定合规 + +**列表页**（原型为准，15列+勾选）: +货源单号 / 运单号 / 托运单号 / 发票号码 / 发票金额 / 税率 / 销售方名称 / 受票方名称 / 开票日期 / 油气票张数 / 核验状态 / 异常原因 / 上报状态 / 操作 + +### 4.5 ETC发票上传 + +**触发条件**: 税务抵扣完成 + +**列表页**（原型为准，10列+勾选）: +货源单号 / 运单号 / 托运单号 / ETC发票号 / 交易金额 / 入口收费站 / 出口收费站 / 交易时间 / 上传状态 / 操作 + +**详情弹窗字段**（原型为准）: +- 运单信息: 运单号、货源单号、托运单号、车牌号、司机姓名、托运方名称、收货方名称 +- ETC发票信息: ETC发票号码、ETC发票代码、交易金额、税率(3%)、发票金额(不含税)、税额、入口收费站、出口收费站、交易时间、发票状态 + +### 4.6 异常申诉功能 + +**关联API接口**: +- `POST /appeal/uploadFile` — 上传申诉附件 +- `POST /appeal/insert` — 提交申诉 +- `POST /appeal/page` — 查询申诉进度 +- `POST /mileageAppeal/insert` — 里程申诉（独立接口） + +**申诉流程**（闭环）: +``` +异常运单查询(接口4) → 发起申诉(接口3) → 省平台复核 → +查询申诉进度(接口5) → 审核通过(110) | 审核不通过(120) → +重新申诉(接口3) | 取消(130) +``` + +**申诉状态流转**（以API §4.4为准）: +``` +未申诉(100) → 审核通过(110) [终态] +未申诉(100) → 审核不通过(120) → 重新申诉 → 未申诉(100) [新申诉单] +未申诉(100) → 已取消(130) [终态] +``` + +**列表页**（原型为准，14列+勾选）: +运单号 / 托运单号 / 车牌号 / 司机姓名 / 托运方名称 / 上报阶段 / 核验状态 / 异常项 / 申诉状态 / 申诉时间 / 申诉人 / 省平台反馈结果 / 省平台反馈时间 / 操作 + +**详情弹窗分组**（原型为准）: +- 申诉信息: 申诉单号、上报阶段、异常项、申诉原因、申诉状态、申诉时间、申诉人、申诉附件 +- 运单信息: 运单号、托运单号、车牌号、司机姓名、托运方名称 +- 异常信息: 核验状态、异常原因、异常时间 +- 省平台反馈信息: 反馈状态、反馈时间、反馈结果、反馈意见 +- 处理记录（时间线）: 操作人、操作时间、操作类型、操作内容 + +### 4.7 上报日志 + +**查询条件**（原型为准）: +- 运单号/托运单号/货源单号: 模糊搜索 +- 上报阶段: 全部 / 第一次上报 / 第二次上报 / 第三次上报 / ETC上传 +- 上报结果: 全部 / 成功 / 失败 +- 时间范围: 开始时间 ~ 结束时间 + +**列表字段**（原型为准，11列）: +序号 / 货源单号 / 运单号 / 托运单号 / 上报阶段 / 上报结果 / 接口URL / HTTP状态码 / 响应时间 / 上报时间 / 操作 + +**日志详情弹窗**: 展示完整请求报文（URL/Method/Headers/Body）和响应报文（StatusCode/Headers/Body），JSON格式化展示，支持一键复制。 + +--- + +## 五、状态枚举汇总（以API文档为权威） + +### 5.1 申诉状态（API §4.4 权威） + +| Code | 名称 | 原始需求对应 | 说明 | +|:---:|:---|:---|:---| +| 100 | 未申诉 | 未申诉 + 申诉中 | 含已提交但省平台尚未审核的情况 | +| 110 | 审核通过 | 申诉通过 | 终态 | +| 120 | 审核不通过 | 申诉驳回 | 可重新申诉 | +| 130 | 已取消 | （无） | API独有，原始需求未提及 | + +### 5.2 核验状态（API §4.2 权威） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未核验 | 运单尚未核验 | +| 110 | 核验通过 | 全部17项核验通过 | +| 120 | 全部异常 | 存在核验异常项 | + +### 5.3 异常项处理状态（API §4.1 子字段） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未申诉 | 该异常项尚未发起申诉 | +| 110 | 申诉中 | 该异常项已提交申诉，待审核 | + +### 5.4 上报状态（内部系统状态，非API枚举） + +| 状态 | 标签颜色 | 说明 | +|:---|:---|:---| +| 上传中 | 蓝色 | 数据正在上报中 | +| 已上传 | 绿色 | 上报成功 | +| 上传失败 | 红色 | 上报超时或错误，显示"手动上传"按钮 | +| 异常 | 橙色 | 数据校验不通过 | + +--- + +## 六、与原始需求的关键差异 + +| # | 项目 | 原始需求 | API文档（权威） | 影响 | +|:---:|:---|:---|:---|:---| +| 1 | 核验项数量 | 7类 | **17项** (§4.1) | 测试覆盖需从14条扩展到34条 | +| 2 | 申诉状态 | 未申诉/申诉中/通过/驳回 | **未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130)** | 申诉状态枚举全部更新 | +| 3 | 申诉"进行中" | 独立状态"申诉中" | 归属于"未申诉(100)"，由abnormalDetails[].state=110标识 | 状态机变更 | +| 4 | 已取消状态 | 无 | **130=已取消** | 新增状态，需补充测试 | +| 5 | 里程申诉 | 无 | **独立接口** `/mileageAppeal/insert` | 新增功能模块 | +| 6 | 发票合规查询 | 无 | **独立接口** `/verificationSummary/cargoOwnerInvoiceInfo` | 新增功能点 | +| 7 | 核验状态 | 通过/异常（二元） | 未核验(100)/通过(110)/全部异常(120) | 新增"未核验"初始状态 | +| 8 | 附件状态 | 无 | 未处理(100)/处理通过(110)/处理异常(120) | 新增枚举 | + +--- + +## 七、上报接口文档参考 + +原始需求中提到的上报接口文档（上报数据字段定义）: +- URL: `https://www.showdoc.com.cn/2210641821476236/9919735893682511` +- 密码: `szjj@2023` + +> ⚠️ 此文档定义了上报请求的字段结构（第一次上报7个子对象、第二次上报资金流水+轨迹、第三次上报发票信息），因受密码保护未直接读取。上报字段定义建议以此文档为准。 + +--- + +## 八、待确认项（累计14项） + +### 阻塞级（影响测试覆盖） +1. **核验项分组映射**: API 17项核验如何映射到UI展示的异常项？是否所有17项均可独立申诉？ +2. **上报接口字段定义**: showdoc文档中的字段是否与API文档§4一致？ + +### 重要级 +3. 申诉状态"已取消(130)"的触发条件和权限 +4. 原型中"待省平台反馈"和"反馈处理中"两个UI状态如何对应API的"未申诉(100)" +5. 第三次上报列表字段以原型(15列)还是原始需求(13列)为准 +6. 里程申诉与通用申诉的关系——是否合并入口还是独立入口 +7. 发票合规查询（接口7）的调用时机——第三次上报前校验还是独立查询 + +### 参考级 +8. 自动重试间隔时间（当前参考值5s/15s/30s） +9. ETC税额四舍五入规则（0.01×3%=0.0003→?） +10. 申诉超时告警阈值（当前参考值7个工作日） +11. 原始需求与API文档省份代码一致性 +12. 原型第二次上报详情弹窗缺失车辆轨迹——是原型bug还是设计如此 +13. 原型详情弹窗字段分组与接口字段定义的完整映射 +14. ETC上传触发条件"税务抵扣完成"由哪个系统事件触发 diff --git a/output/versions/安徽运八需求/v4/snapshot_meta.json b/output/versions/安徽运八需求/v4/snapshot_meta.json new file mode 100644 index 0000000..fe86812 --- /dev/null +++ b/output/versions/安徽运八需求/v4/snapshot_meta.json @@ -0,0 +1,14 @@ +{ + "base_name": "安徽运八需求", + "version": "v4", + "snapshot_type": "full_pipeline", + "summary": [ + "manifest", + "analysis", + "relation_report", + "test_points", + "test_cases_markdown", + "excel", + "normalized_inputs" + ] +} diff --git a/output/versions/安徽运八需求/v4/安徽运八需求.json b/output/versions/安徽运八需求/v4/安徽运八需求.json new file mode 100644 index 0000000..ae92cc9 --- /dev/null +++ b/output/versions/安徽运八需求/v4/安徽运八需求.json @@ -0,0 +1,348 @@ +{ + "_meta": { + "base_name": "安徽运八需求", + "merged_zones": [ + "prepare", + "analyze", + "design", + "execute", + "review", + "monitor" + ], + "merged_at": "2026-07-13T07:31:34.880608+00:00", + "updated_at": "2026-07-13T07:31:34.881584+00:00" + }, + "prepare": { + "base_name": "安徽运八需求", + "requirement_source_file": "E:\\test\\QaAutomationHub\\source_docs\\requirements_raw\\安徽运八需求.docx", + "requirement_input_type": "docx", + "normalized_requirement_file": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求\\requirement.md", + "normalized_dir": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求", + "technical_solution_files": [], + "normalized_technical_solution_files": [], + "project_profile_file": "E:\\test\\QaAutomationHub\\knowledge_base\\00_project\\project_profile.md", + "document_confidence": { + "requirement": 0.9, + "issues": [] + }, + "activated_knowledge": { + "terminology": { + "permanent": [ + "E:\\test\\QaAutomationHub\\knowledge_base\\01_standards\\terminology.md" + ], + "optional": [] + }, + "semantic_matches": [ + { + "path": "E:\\test\\QaAutomationHub\\knowledge_base\\03_best_practices\\data_reporting_cases.md", + "score": 0.1155, + "category": "best_practice" + }, + { + "path": "E:\\test\\QaAutomationHub\\knowledge_base\\02_history\\common_missed_scenes.md", + "score": 0.0916, + "category": "history" + } + ] + }, + "knowledge_gaps": [], + "agent_notes": { + "document-parser": "解析完成，置信度 90%", + "knowledge-activator": "激活 1 常驻 + 0 可选术语" + }, + "_meta": { + "zone": "prepare", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.805524+00:00", + "status": "completed" + } + }, + "base_name": "安徽运八需求", + "requirement_source_file": "E:\\test\\QaAutomationHub\\source_docs\\requirements_raw\\安徽运八需求.docx", + "requirement_input_type": "docx", + "normalized_requirement_file": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求\\requirement.md", + "normalized_dir": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求", + "technical_solution_files": [], + "normalized_technical_solution_files": [], + "project_profile_file": "E:\\test\\QaAutomationHub\\knowledge_base\\00_project\\project_profile.md", + "document_confidence": { + "requirement": 0.9, + "issues": [] + }, + "activated_knowledge": { + "terminology": { + "permanent": [ + "E:\\test\\QaAutomationHub\\knowledge_base\\01_standards\\terminology.md" + ], + "optional": [] + }, + "semantic_matches": [ + { + "path": "E:\\test\\QaAutomationHub\\knowledge_base\\03_best_practices\\data_reporting_cases.md", + "score": 0.1155, + "category": "best_practice" + }, + { + "path": "E:\\test\\QaAutomationHub\\knowledge_base\\02_history\\common_missed_scenes.md", + "score": 0.0916, + "category": "history" + } + ] + }, + "knowledge_gaps": [], + "agent_notes": { + "execution-analyst": "等待测试结果输入", + "knowledge-curator": "等待执行分析结果" + }, + "analyze": { + "base_name": "安徽运八需求", + "analysis_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_分析.md", + "relation_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_关联与冲突.md", + "risk_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_风险评估.md", + "related_requirements": [], + "conflict_candidates_count": 0, + "conflict_summary": {}, + "risk_matrix": { + "risks": [ + { + "id": "RISK-FINANCIAL", + "category": "资损", + "keywords_matched": [ + "金额", + "支付" + ], + "likelihood": 2, + "impact": 5, + "score": 10, + "level": "P1", + "conflict_amplified": false + }, + { + "id": "RISK-AVAILABILITY", + "category": "可用性", + "keywords_matched": [ + "超时", + "重试" + ], + "likelihood": 2, + "impact": 4, + "score": 8, + "level": "P2", + "conflict_amplified": false + } + ], + "total": 2, + "p0_count": 0, + "p1_count": 1 + }, + "confirmation_gate": { + "required": false, + "reasons": [], + "pending_markers_count": 0, + "decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md", + "decision_status": "not_required", + "decision_status_label": "已确认", + "allow_export_before_confirmation": true, + "candidate_decision_files": [ + "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" + ], + "suggested_decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" + }, + "agent_notes": { + "requirement-analyzer": "识别 0 个关联需求", + "conflict-detector": "检测到 0 个冲突候选", + "risk-assessor": "识别 2 个风险项" + }, + "_meta": { + "zone": "analyze", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.855607+00:00", + "status": "completed" + } + }, + "analysis_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_分析.md", + "relation_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_关联与冲突.md", + "risk_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_风险评估.md", + "related_requirements": [], + "conflict_candidates_count": 0, + "conflict_summary": {}, + "risk_matrix": { + "risks": [ + { + "id": "RISK-FINANCIAL", + "category": "资损", + "keywords_matched": [ + "金额", + "支付" + ], + "likelihood": 2, + "impact": 5, + "score": 10, + "level": "P1", + "conflict_amplified": false + }, + { + "id": "RISK-AVAILABILITY", + "category": "可用性", + "keywords_matched": [ + "超时", + "重试" + ], + "likelihood": 2, + "impact": 4, + "score": 8, + "level": "P2", + "conflict_amplified": false + } + ], + "total": 2, + "p0_count": 0, + "p1_count": 1 + }, + "confirmation_gate": { + "required": false, + "reasons": [], + "pending_markers_count": 0, + "decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md", + "decision_status": "not_required", + "decision_status_label": "已确认", + "allow_export_before_confirmation": true, + "candidate_decision_files": [ + "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" + ], + "suggested_decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" + }, + "design": { + "base_name": "安徽运八需求", + "strategy_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试策略.md", + "test_points_file": "E:\\test\\QaAutomationHub\\output\\test_points\\安徽运八需求_测试点.md", + "test_cases_file": "E:\\test\\QaAutomationHub\\output\\test_cases\\安徽运八需求_测试用例.md", + "test_data_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试数据.md", + "p0_required_coverage": "N/A", + "agent_notes": { + "test-strategist": "策略已生成，0 个 P0 风险需 100% 覆盖", + "testpoint-designer": "待 AI Agent 生成测试点", + "case-designer": "待 AI Agent 生成用例", + "data-builder": "测试数据模板已生成" + }, + "_meta": { + "zone": "design", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.874648+00:00", + "status": "completed" + } + }, + "strategy_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试策略.md", + "test_points_file": "E:\\test\\QaAutomationHub\\output\\test_points\\安徽运八需求_测试点.md", + "test_cases_file": "E:\\test\\QaAutomationHub\\output\\test_cases\\安徽运八需求_测试用例.md", + "test_data_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试数据.md", + "p0_required_coverage": "N/A", + "execute": { + "base_name": "安徽运八需求", + "playwright_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\playwright_tests.py", + "appium_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\appium_tests.py", + "execution_report_file": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求_执行报告.md", + "screenshots_dir": "E:\\test\\QaAutomationHub\\output\\screenshots\\安徽运八需求", + "execution_config": { + "browsers": [ + "chromium", + "firefox", + "webkit" + ], + "mobile_platforms": [ + "android", + "ios" + ], + "screenshot_on_failure": true, + "screenshot_on_step": false + }, + "agent_notes": { + "web-executor": "Playwright 脚本已生成 → E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\playwright_tests.py", + "mobile-executor": "Appium 脚本已生成 → E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\appium_tests.py", + "result-reporter": "执行报告 → E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求_执行报告.md" + }, + "_meta": { + "zone": "execute", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.877678+00:00", + "status": "completed" + } + }, + "playwright_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\playwright_tests.py", + "appium_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\appium_tests.py", + "execution_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_执行分析.md", + "screenshots_dir": "E:\\test\\QaAutomationHub\\output\\screenshots\\安徽运八需求", + "execution_config": { + "browsers": [ + "chromium", + "firefox", + "webkit" + ], + "mobile_platforms": [ + "android", + "ios" + ], + "screenshot_on_failure": true, + "screenshot_on_step": false + }, + "review": { + "base_name": "安徽运八需求", + "review_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_评审报告.md", + "coverage_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_覆盖率审计.md", + "verdict_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_质量裁决.md", + "quality_verdict": { + "verdict": "BLOCKED", + "reason": "测试用例文件尚未生成或为空", + "case_count": 0, + "min_coverage_required": 0.95, + "max_blockers_allowed": 0 + }, + "agent_notes": { + "case-reviewer": "等待用例生成", + "coverage-auditor": "覆盖率审计待 AI Agent 执行", + "quality-gatekeeper": "裁决: BLOCKED" + }, + "_meta": { + "zone": "review", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.879631+00:00", + "status": "completed" + } + }, + "review_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_评审报告.md", + "coverage_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_覆盖率审计.md", + "verdict_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_质量裁决.md", + "quality_verdict": { + "verdict": "BLOCKED", + "reason": "测试用例文件尚未生成或为空", + "case_count": 0, + "min_coverage_required": 0.95, + "max_blockers_allowed": 0 + }, + "monitor": { + "base_name": "安徽运八需求", + "execution_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_执行分析.md", + "agent_notes": { + "execution-analyst": "等待测试结果输入", + "knowledge-curator": "等待执行分析结果" + }, + "curation_suggestions": [], + "_meta": { + "zone": "monitor", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.880608+00:00", + "status": "completed" + } + }, + "curation_suggestions": [], + "current_excel_file": "E:\\test\\QaAutomationHub\\output\\excel_reports\\安徽运八需求_测试用例.xlsx", + "versioning_scheme": { + "current_files": "固定文件名，始终表示当前最新版", + "snapshot_rule": "仅在 export 成功且产物内容发生变化时递增版本", + "snapshot_dir_pattern": "output/versions/{BASE_NAME}/vN/" + }, + "latest_snapshot_version": "v3", + "latest_snapshot_dir": "E:\\test\\QaAutomationHub\\output\\versions\\安徽运八需求\\v3", + "latest_snapshot_type": "full_pipeline", + "maintained_requirement_file": "E:\\test\\QaAutomationHub\\requirements\\安徽运八需求.md" +} diff --git a/output/versions/安徽运八需求/v4/安徽运八需求_关联与冲突.md b/output/versions/安徽运八需求/v4/安徽运八需求_关联与冲突.md new file mode 100644 index 0000000..98f0a05 --- /dev/null +++ b/output/versions/安徽运八需求/v4/安徽运八需求_关联与冲突.md @@ -0,0 +1,16 @@ +# 安徽运八需求 关联需求与冲突检查 + +## 目标需求 +- `source_docs\requirements_raw\安徽运八需求.docx` + +## 项目画像 +- `knowledge_base\00_project\project_profile.md` + +## 关联技术方案 +- 未识别到同主题技术方案文档。 + +## 关联需求识别 +- 未识别到相似度达到阈值的历史需求文档。 + +## 潜在冲突与修改建议 +- 暂未识别到明显冲突条目。建议在需求评审时继续人工确认。 diff --git a/output/versions/安徽运八需求/v4/安徽运八需求_分析.md b/output/versions/安徽运八需求/v4/安徽运八需求_分析.md new file mode 100644 index 0000000..8da856b --- /dev/null +++ b/output/versions/安徽运八需求/v4/安徽运八需求_分析.md @@ -0,0 +1,175 @@ +# 安徽运八需求 结构化分析 + +> 生成时间: 2026-07-13 +> 需求文档: source_docs/requirements_raw/安徽运八需求.docx +> 重构需求: output/normalized_inputs/安徽运八需求/requirement_restructured.md（以API文档V1.0.2为权威数据源） +> 项目画像: knowledge_base/00_project/project_profile.md + +## 1. 需求背景 + +根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将税源地为安徽运八的运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八），其他税源地不走此逻辑。 + +## 2. 目标 + +实现上报流程的自动化管理，并提供异常监控与向平台发起申诉的能力。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。 + +## 3. 用户角色 + +| 角色 | 职责 | +| :--- | :--- | +| 平台运营人员 | 查看看板、发起申诉、监控上报状态 | +| 系统自动 | 自动触发三阶段上报和ETC上传 | +| 财务人员 | 打款操作（触发第二次上报） | +| 安徽监管平台 | 接收上报数据、执行核验、反馈结果 | + +## 4. 功能模块 + +### 4.1 上报运单看板 +集中展示所有上报阶段运单的汇总状态，支持按条件筛选（运单号/托运单号/货源单号模糊搜索、上报阶段、核验状态、申诉状态）、查看详情和发起申诉。 + +### 4.2 第一次上报（装货完成） +运单装货完成后自动触发，仅上传货源税源地为安徽运八的运单。上报数据包含运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息、保险信息等。核验通过后自动调用"修改第一次上报部分字段"接口。 + +### 4.3 第二次上报（打款完成） +运费支付完成后自动触发，上报数据包含资金流水信息、车辆轨迹信息等。监管平台进行核验。⚠️ 根据网货企业端接口文档 V1.0.2 §4.1，核验项从需求描述的7类扩展为API定义的17项独立核验项：100=委托合同、120=承运合同、130=实时定位、140=运单时间逻辑、150=车辆资质、160=道路运输证、170=驾驶证、180=从业资格证、190=车辆重复、200=司机重复、210=车辆轨迹、220=运费收款、230=公司统一收款、240=集中支付、250=资金流水、260=发票信息、270=非通行车辆可开票。每项有独立的核验结果和申诉入口。 + +### 4.4 第三次上报（开票完成） +发票开具完成后触发，上报数据包含运单信息、发票信息、油气发票信息等。 + +### 4.5 ETC发票上传 +用于上报车辆通行高速公路的ETC发票信息，作为税务抵扣凭证。需在税务抵扣完成后进行。 + +### 4.6 异常申诉功能 +补全"异常查询 → 发起申诉 → 跟踪监管平台反馈 → 合规判断"的完整闭环。 + +### 4.7 上报日志 +记录所有上报接口的调用记录（请求/响应报文、HTTP状态码、响应时间），用于问题排查和审计。 + +## 5. 核心规则 + +### 5.1 税源地过滤 +- 仅税源地为安徽运八的运单触发上报 +- 其他税源地（如云南=28）不触发任何上报 + +### 5.2 上报阶段依赖链 +- 第一次上报是后续两次上报的基础 +- 第二次上报依赖第一次上报完成 +- 第三次上报依赖第二次上报完成 +- 后端必须做前置状态校验（非仅前端控制） + +### 5.3 自动重试机制 +- 各阶段上报失败后自动重试（最多3次） +- 3次全部失败后告警通知运营人员 +- 重试期间禁止手动触发上传 + +### 5.4 核验规则 +- 第二次上报包含**17项独立核验**（API文档§4.1定义），比需求的7类更为细化 +- 核验异常可通过申诉机制向监管平台说明情况 +- 每项核验有独立的核验结果（verificationCode/verificationName/verificationState）和申诉入口 +- 申诉由安徽监管平台复核 + +> **核验项扩展说明（来源：API §4.1）**: 原始需求仅描述7大类核验（运单重复/车辆资质/司机资质/集中支付/资金流水/合同/轨迹合规），但API文档§4.1定义了完整的17项独立核验项（100=委托合同, 120=承运合同, 130=实时定位, 140=运单时间逻辑, 150=车辆资质, 160=道路运输证, 170=驾驶证, 180=从业资格证, 190=车辆重复, 200=司机重复, 210=车辆轨迹, 220=运费收款, 230=公司统一收款, 240=集中支付, 250=资金流水, 260=发票信息, 270=非通行车辆可开票）。每项有独立的核验结果和申诉入口，测试覆盖需从14条（7类×通过+异常）扩展到34条（17项×通过+异常）。 + +### 5.5 API接口清单（来自网货企业端接口文档 V1.0.2） + +| 接口 | URL | 方法 | 说明 | +|:---|:---|:---:|:---| +| 获取token | /sys/login | POST | JWT认证 | +| 上传申诉附件 | /appeal/uploadFile | POST | 文件上传 | +| 提交申诉运单 | /appeal/insert | POST | 发起申诉 | +| 查询异常运单信息 | /verificationSummary/page | POST | 分页查询，含abnormalDetails（17项核验明细） | +| 查询申诉进度 | /appeal/page | POST | 分页查询，含审核状态/审核人/取消/撤回 | +| 查询运单核验详情 | /verificationSummary/verificationDetail | POST | 单运单核验明细列表 | +| 查询发票合规 | /verificationSummary/cargoOwnerInvoiceInfo | POST | 判断托运人发票是否系统核验合规（需求未提及！） | +| 运单里程核验查询 | /verificationSummary/mileageVerificationInfo | POST | 批量查询运单里程核验状态 | +| 运单里程申诉 | /mileageAppeal/insert | POST | 提交里程申诉（需求未提及的新功能！） | + +### 5.6 申诉状态枚举（以API §4.4为权威） + +| Code | API名称(§4.4权威) | 原始需求对应 | 原型对应 | 说明 | +|:---:|:---|:---|:---|:---| +| 100 | **未申诉** | 未申诉 + 申诉中 | 未申诉 + 待省平台反馈 + 反馈处理中 | 含已提交但省平台尚未审核的情况（申诉"进行中"通过 abnormalDetails[].state=110 标识） | +| 110 | **审核通过** | 申诉通过 | 申诉通过 | 终态 | +| 120 | **审核不通过** | 申诉驳回 | 申诉驳回 | 可重新申诉 | +| 130 | **已取消** | （无） | （无） | API独有，原始需求未提及此状态 | + +> **以API文档§4.4为权威数据源**，所有开发实现和测试验证均以此枚举为准。 +> +> ⚠️ **待确认**: +> - 原型中"待省平台反馈"和"反馈处理中"为UI层面的展示状态，非后端枚举值，需确认UI状态与API枚举的映射关系。 +> - API有"已取消"状态(130)但需求和原型均未体现——需确认是否支持申诉取消及触发权限。 +> - 看板筛选下拉值以API §4.4为准（未申诉/审核通过/审核不通过/已取消）。 + +### 5.7 申诉单项约束（API §3.3） + +- 接口 `POST /appeal/insert` 的 `verificationAbnormalItems` 参数说明为**"只支持单个异常项目申诉"** +- 每次申诉仅针对**一个**核验异常项 +- 同一运单有多个异常项时，需分别发起多次申诉（每项一个申诉单） +- 申诉流程必须包含**异常项单选步骤**，不允许批量勾选后一次提交 +- 传入多个异常项ID（如 `"120,160"`）时，接口应拒绝并返回错误提示 + +## 6. 数据字段 + +### 6.1 第一次上报核心字段 +- waybillInfo（建单信息）: 13字段（必选） +- consignorInfo（托运人信息）: 7字段（必选） +- consigneeInfo（收货方信息）: 5字段（必选） +- driverInfo（司机信息）: 13字段（必选） +- carInfo（接单车辆信息）: 19字段（必选） +- goodsInfos（货物信息）: 4字段/条（必选，可多条） +- insuranceInformation（保险信息）: 2字段（可选） + +### 6.2 第二次上报新增字段 +- 资金流水信息: 10字段（必选） +- 车辆轨迹信息: 6字段/点（必选，2~2000个点） + +### 6.3 第三次上报核心字段 +- 发票信息: 17字段（必选） +- 油气发票信息（可选，可多条） + +### 6.4 ETC发票核心字段 +- ETC发票信息: 18字段/张 + +## 7. 状态流转 + +### 7.1 上报状态 +上传中(蓝色) → 已上传(绿色) / 上传失败(红色) / 异常(橙色) + +### 7.2 申诉状态 +未申诉 → 申诉中 → 申诉通过 / 申诉驳回 → 重新申诉 + +## 8. 歧义标注与待确认项 + +### 8.1 核验项定义差异（P0 阻断） +> ⚠️ 待确认1: 需求文档将核验项描述为7大类，但API文档§4.1定义了17项独立核验项。测试点已按API文档17项逐项覆盖（TP-C-006~TP-C-019 保留原7类 + TP-C-026~TP-C-049 补充12项），需与产品和开发确认最终核验粒度。 + +### 8.2 申诉状态枚举三版本不一致（P1） +> ⚠️ 待确认2: 申诉状态在需求（未申诉/申诉中/申诉通过/申诉驳回）、原型（未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回）、API（未申诉100/审核通过110/审核不通过120/已取消130）三处不一致，需确认最终版本。详见 §5.6 对照表。 + +### 8.3 第三次上报列表字段差异（P1） +> ⚠️ 待确认3: 原型列表比需求多4个字段（税率、销售方名称、受票方名称、油气票张数），共15列（含checkbox），需确认最终字段列表。 + +### 8.4 看板申诉状态下拉值差异（P1） +> ⚠️ 待确认4: 原型看板申诉状态下拉值为"未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回"，与需求"未申诉/申诉中/申诉通过/申诉驳回"不一致，需确认最终版本。 + +### 8.5 原型详情弹窗字段数量差异（P1） +> ⚠️ 待确认5: 原型详情弹窗各分组字段数量与需求/接口文档不一致（原型大幅简化），需确认以哪个为准。 + +### 8.6 原型缺失车辆轨迹信息（P1） +> ⚠️ 待确认6: 原型第二次上报详情弹窗中车辆轨迹信息缺失——是原型bug还是实际不展示？ + +### 8.7 技术细节待确认 +> ⚠️ 待确认7: 自动重试的具体间隔时间（需求中未明确），当前假设为5s/15s/30s，需与技术方案确认。 +> ⚠️ 待确认8: ETC税额边界值（0.01元→税额=0.00）的四舍五入规则需与财务确认。 +> ⚠️ 待确认9: 申诉超时告警阈值（需求中未明确），当前假设为7个工作日，需与产品确认。 +> ⚠️ 待确认10: 安徽运八与现有云南运八上报逻辑是否存在字段/接口冲突，需人工确认。 +> ⚠️ 待确认11: 上报接口文档密码保护（szjj@2023），字段定义以接口文档为准，需确认需求与接口文档一致性。 +> ⚠️ 待确认12: 里程申诉接口 /mileageAppeal/insert 为需求未提及的新功能，需确认是否纳入本期范围。 +> ⚠️ 待确认13: ETC发票详情含"不含税金额"字段是否需要在测试用例中体现。 + +## 9. 项目差异化约束 + +- 省份代码: 安徽=34（非云南=28） +- 该需求为新增模块，与现有云南上报逻辑隔离 +- 测试环境管理端: https://ybxcx.ynyun8.com:8000/admin +- 支付方式: arpa_2（云企付二期） diff --git a/output/versions/安徽运八需求/v4/安徽运八需求_测试点.md b/output/versions/安徽运八需求/v4/安徽运八需求_测试点.md new file mode 100644 index 0000000..529ef87 --- /dev/null +++ b/output/versions/安徽运八需求/v4/安徽运八需求_测试点.md @@ -0,0 +1,1176 @@ +# 安徽运八需求 测试点 + +> 生成时间: 2026-07-13 +> 需求文档: output/normalized_inputs/安徽运八需求/requirement.md +> 关联分析: 风险评估报告 / 测试策略 / 关联与冲突 + +## 测试点概览 + +- 总测试点数: 135 +- P0: 33 / P1: 67 / P2: 29 / P3: 6 +- 模块分布: A(看板)=14, B(第一次上报)=20, C(第二次上报)=49, D(第三次上报)=12, E(ETC)=9, F(申诉)=16, G(日志)=9, X(跨模块)=6 +- 来源分布: [需求] 66, [历史缺陷] 14, [风险矩阵] 8, [漏测清单] 52, [项目画像] 16, [最佳实践] 7, [技术方案] 31 + +> 注: 一个测试点可同时归属多个来源，因此来源分布合计数 > 总测试点数。 + +--- + +## 模块A: 上报运单看板 (14个测试点) + +### TP-A-001: 看板模糊搜索 — 运单号/托运单号/货源单号 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证看板支持按运单号、托运单号、货源单号进行模糊搜索，输入部分字符即可匹配相关运单。 +- 关键验证点: 输入完整单号可精确匹配；输入部分字符可模糊匹配；输入不存在的单号显示空结果提示；三种单号输入框均支持模糊搜索。 + +### TP-A-002: 看板按上报阶段筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证看板支持按"全部/第一次上报/第二次上报/第三次上报"筛选，切换阶段后列表数据正确过滤。 +- 关键验证点: 默认"全部"显示所有阶段运单；选择"第一次上报"仅显示对应阶段运单；切换阶段后列表即时刷新；各阶段数据条数与实际一致。 + +### TP-A-003: 看板按核验状态筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证看板支持按"全部/异常/通过"筛选核验状态，确保状态拆分独立验证。 +- 关键验证点: "全部"显示所有核验状态运单；"异常"仅显示核验不通过的运单；"通过"仅显示核验通过的运单；列表中核验状态字段与筛选条件一致。 + +### TP-A-004: 看板按申诉状态筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证看板支持按"全部/未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130)"筛选申诉状态。⚠️ 待确认: 原型看板申诉状态下拉值为"未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回"，与API权威枚举不一致，需确认UI最终版本。 +- 关键验证点: 四种申诉状态独立筛选，数据精确匹配；切换申诉状态后核验状态筛选联动正确；申诉状态标签展示与筛选值一致。 + +### TP-A-005: 看板组合筛选 — 多条件叠加 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [需求][漏测清单] +- 描述: 验证看板支持上报阶段 + 核验状态 + 申诉状态 + 模糊搜索同时组合筛选。 +- 关键验证点: 选择"第二次上报+异常+未申诉(100)"组合后精确过滤；组合条件为空结果时友好提示；组合条件切换不丢失已输入的单号搜索关键字。 + +### TP-A-006: 看板导出功能 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][项目画像] +- 描述: 验证看板支持将当前筛选结果导出为 Excel 文件，大数据量导出正常。 +- 关键验证点: 导出文件包含全部列表字段；导出数据与当前筛选条件一致；大数据量（≥2000条）导出不超时、不OOM；导出的 Excel 文件可正常打开和解析。 + +### TP-A-007: 看板重置查询条件 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证点击"重置"按钮后，所有查询条件恢复默认值，列表刷新为初始全部数据。 +- 关键验证点: 模糊搜索输入框清空；下拉筛选恢复"全部"；列表数据恢复为默认全部运单；重置后分页回到第1页。 + +### TP-A-008: 看板列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证看板列表展示的14个字段完整且顺序与需求一致：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、申诉状态、异常项、货物名称、合同金额、最新核验时间、操作。 +- 关键验证点: 每个字段均有数据且格式正确；异常项为空时合理展示（如"-"或留空）；合同金额保留2位小数；最新核验时间为合理时间格式。 + +### TP-A-009: 看板状态标签颜色映射 +- 优先级: P2 +- 类型: UI测试 +- 覆盖维度: 数据校验 +- 来源: [漏测清单] +- 描述: 验证上报阶段不同状态对应的标签颜色是否正确（蓝色=上传中、绿色=已上传/通过、红色=上传失败/审核不通过、橙色=异常）。 +- 关键验证点: 每一种状态颜色独立验证；蓝色/绿色/红色/橙色与实际需求一致；申诉状态标签（未申诉灰色/审核通过绿色/审核不通过红色）颜色区分清晰。 + +### TP-A-010: 看板操作按钮 — 申诉/进度/详情 入口 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证看板操作列中"申诉""进度""详情"按钮根据运单当前状态正确显示/隐藏，点击后正确跳转。 +- 关键验证点: 仅异常运单显示"申诉"按钮；所有运单显示"详情"按钮；"进度"按钮展示上报阶段进度；点击后路由跳转正确，携带正确的运单ID参数。 + +### TP-A-011: 看板详情弹窗 — 分组字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证看板点击"详情"后弹窗内容完整，按子对象分组展示，各分组字段不缺失。 +- 关键验证点: 建单信息分组13字段完整；托运人信息7字段完整；收货方信息5字段完整；司机信息13字段完整；车辆信息19字段完整；货物信息支持多条展示；可选字段为空时展示合理。 + +### TP-A-012: 看板空数据状态 +- 优先级: P3 +- 类型: UI测试 +- 覆盖维度: 边界条件 +- 来源: [漏测清单] +- 描述: 验证看板在无运单数据时的空状态展示（如新部署环境或筛选无结果）。 +- 关键验证点: 空状态有友好的占位提示图文；筛选无结果时明确提示"未找到匹配数据"；空状态不出现控制台报错或页面崩溃。 + +### TP-A-013: 看板分页和默认排序 +- 优先级: P3 +- 类型: UI测试 +- 覆盖维度: 边界条件 +- 来源: [漏测清单] +- 描述: 验证看板列表分页功能正常（翻页、每页条数切换），默认按最新核验时间倒序排列。 +- 关键验证点: 翻页后数据不重复不遗漏；切换每页条数后分页重新计算；数据更新后排序即时反映；总条数与数据库一致。 + +### TP-A-014: 看板角色权限控制 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 权限控制 +- 来源: [项目画像] +- 描述: 验证不同角色（运营/财务/客服/车队长/司机）对看板的访问权限和数据可见范围。 +- 关键验证点: 运营人员可见全部运单；财务人员可见打款相关字段；客服人员仅可见其负责范围的运单；车队长和司机不可见平台端看板；越权访问被正确拦截。 + +--- + +## 模块B: 第一次上报-装货完成 (19个测试点) + +### TP-B-001: 装货完成后自动触发第一次上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证运单装货完成后，系统自动触发第一次上报，上报数据包含全部必选子对象（运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息）。 +- 关键验证点: 装货完成事件触发上报；上报请求包含全部7个子对象；各子对象必选字段完整；上报接口收到正确的JSON结构；上报成功后状态变为"已上传"（绿色标签）。 + +### TP-B-002: 仅安徽税源地运单触发上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][项目画像] +- 描述: 验证货源税源地为非安徽的运单（如云南=28）装货完成后不会触发第一次上报。 +- 关键验证点: 税源地为云南(28)的运单不触发上报；税源地为其他省份的运单不触发上报；不触发时无错误日志或告警；仅税源地为安徽(34)的运单触发上报。 + +### TP-B-003: 第一次上报数据字段格式校验 — 建单信息 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证第一次上报的建单信息(waybillInfo)13个字段的格式、类型、长度符合接口规范，可选字段（委托合同编号、运输里程）为空时正常上报。 +- 关键验证点: 必选字段缺失时上报拒绝并明确提示；统一社会信用代码格式校验（18位）；业务类型代码/运输组货方式代码为有效枚举值；运输里程为合理数值范围；经纬度为合法浮点数范围。 + +### TP-B-004: 省份代码动态获取 — 安徽=34 非云南=28 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 数据校验 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-04：验证司机信息中的省份代码(provinceCode)根据上报目标省份动态读取配置，安徽省使用代码"34"而非项目默认值云南省代码"28"。 +- 关键验证点: 安徽运八上报的省份代码为"34"；不同省份配置隔离，云南=28、安徽=34 各自独立；修改省份配置后无需重启服务即可生效；数据库/Redis中无硬编码省份代码；装货地行政区划代码前2位=34（安徽省代码）。 + +### TP-B-005: 后端校验 — 第一次上报是第二/三次上报的前置条件 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-01：验证第一次上报失败后，后端接口层面拒绝第二次和第三次上报请求，返回明确错误码"前置上报未完成"。前端+后端双重拦截。 +- 关键验证点: 第一次上报失败时调用第二次上报接口返回错误；错误码明确标识"前置上报未完成"；后端通过查询运单上报状态表做校验，非前端布尔值；第一次上报重试3次全失败后第二次上报仍被拒绝；第三次上报同理，第二次上报失败时被拒绝。 + +### TP-B-006: 第一次上报成功后自动调用"修改字段"接口 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证监管平台核验通过后，系统自动调用"修改第一次上报部分字段"接口，更新装货后可能变化的字段（如实际里程）。 +- 关键验证点: 核验通过后自动触发修改接口；修改的字段为装货后变化字段（实际里程等）；修改成功后状态仍为"已上传"；修改接口调用记录出现在上报日志中；若修改失败有重试机制和告警。 + +### TP-B-007: 第一次上报自动重试 — 最多3次 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [需求] +- 描述: 验证第一次上报失败后系统自动重试，最多3次，重试间隔递增。 +- 关键验证点: 第1次失败后自动触发第2次重试；重试间隔合理递增（如5s/15s/30s）；第3次仍失败后标记为"上传失败"（红色标签）并停止重试；每次重试均记录到上报日志；重试次数不超过3次。 + +### TP-B-008: 第一次上报全部重试失败后通知运营人员 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证第一次上报3次自动重试全部失败后，系统通过站内信或其他方式通知运营人员。 +- 关键验证点: 3次重试失败后立即触发通知；通知内容包含运单号、失败原因、失败时间；站内信有明确的"上报失败"标记；运营人员可在通知中直接跳转到对应运单详情页。 + +### TP-B-009: 第一次上报手工上传 — 上传失败后手动触发 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证运单上报状态为"上传失败"（红色标签）时，运营人员可点击"手动上传"按钮重新发起上报。 +- 关键验证点: 仅"上传失败"状态显示"手动上传"按钮；点击后发起新的上报请求；手动上传成功后状态变为"已上传"（绿色）；手动上传同样记录到上报日志。 + +### TP-B-010: 第一次上报状态标签颜色校验 +- 优先级: P2 +- 类型: UI测试 +- 覆盖维度: 数据校验 +- 来源: [漏测清单] +- 描述: 验证四种上报状态对应的标签颜色：上传中=蓝色、已上传=绿色、上传失败=红色、异常=橙色。 +- 关键验证点: 每种状态颜色独立验证，不与需求描述偏离；上传中状态显示蓝色标签和加载动画；状态切换时标签颜色即时更新；颜色在亮色/暗色主题下均可辨识。 + +### TP-B-011: 第一次上报详情弹窗 — 建单信息字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验收详情弹窗中"建单信息"分组的13个字段全部展示，数据取值来源正确。 +- 关键验证点: 上游企业委托运输单号、本运单单号、托运人建单时间、网络货运经营者名称、统一社会信用代码、道路运输经营许可证编号、业务类型代码、运输组货方式代码、司机接单时间、司机起运时间、承运合同编号（必选）共11字段有值；委托合同编号和运输里程为可选字段，为空时合理展示。 + +### TP-B-012: 第一次上报详情弹窗 — 托运人/收货方/司机/车辆/货物/保险子对象字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证详情弹窗中各子对象字段完整且按分组展示：托运人信息7字段、收货方信息5字段、司机信息13字段、车辆信息19字段、货物信息4字段（可多条）、保险信息2字段（可选）。 +- 关键验证点: 托运人统一社会信用代码格式正确；收货方身份证号脱敏展示（如适用）；司机从业资格证有效期起止日期格式正确；车辆VIN码(17位)正确显示；货物支持多条记录展开；保险单号为可选字段，无保险时合理展示。 + +### TP-B-013: 第一次上报详情弹窗 — 异常信息展示 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证详情弹窗中"异常信息"分组包含核验状态、异常原因、异常时间、处理状态4个字段。 +- 关键验证点: 核验通过时异常原因为空；核验异常时异常原因描述清晰可理解；异常时间为实际核验时间；处理状态与申诉模块数据联动。 + +### TP-B-014: 第一次上报幂等性 — 防止重复上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-02：验证同一运单同一上报阶段在短时间内不能重复上报。自动重试期间手动触发上传时，系统检测到上报进行中并拒绝重复提交。 +- 关键验证点: 自动重试进行中点击"手动上传"返回"上报处理中"提示并拒绝；同一运单同一阶段1分钟内只能有1条成功上报记录；使用分布式锁或幂等键控制并发；快速连续点击"手动上传"按钮仅发起1次请求（前端防抖）；后端数据库层面唯一约束防重。 + +### TP-B-015: 第一次上报接口超时处理 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [漏测清单][风险矩阵] +- 描述: 验证第一次上报接口调用超时后的处理逻辑（超时归类为上报失败，触发重试）。 +- 关键验证点: 监管平台接口超时(>30s)后转为"上传失败"状态；超时状态下触发自动重试；超时不导致数据不一致或重复写入；超时时有 Loading 状态提示；前端页面超时后有友好提示。 + +### TP-B-016: 第一次上报弱网环境处理 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [漏测清单] +- 描述: 验证在弱网环境（高延迟、高丢包率）下，第一次上报的重试机制正常工作。 +- 关键验证点: 弱网下请求发送成功但响应延迟时不会立即判定失败；超时阈值合理（建议30s）；弱网恢复后重试成功则状态正常流转；断网时上报请求发送失败的提示友好。 + +### TP-B-017: 第一次上报并发触发 — 多运单同时装货完成 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 +- 来源: [项目画像][最佳实践] +- 描述: 验证多个运单同时装货完成时，第一次上报并发处理，各运单上报互不干扰。 +- 关键验证点: 10个运单同时装货完成，各自独立触发上报；并发上报不产生数据库死锁；各运单上报记录正确隔离；并发上报后上报日志完整记录每个运单的请求。 + +### TP-B-018: 第一次上报可选字段空值处理 +- 优先级: P3 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [漏测清单] +- 描述: 验证各子对象中的可选字段（委托合同编号、运输里程、挂车牌照号、行驶证档案编号、道路运输证有效期起/至、保险单号、保险公司名称）为空时，上报接口正常处理。 +- 关键验证点: 可选字段为空时上报不报错；JSON 中可选字段不传或传 null 均可正常处理；详情弹窗中可选字段为空时显示"-"或"N/A"等占位符，不显示"null"或"undefined"。 + +### TP-B-019: 第一次上报货物信息多条记录 +- 优先级: P3 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [需求][漏测清单] +- 描述: 验证当运单包含多种货物时，货物信息(goodsInfos)数组支持多条记录上报，每条包含货物名称、货物类型代码、货物量、计量单位。 +- 关键验证点: 支持1条货物记录；支持多条（如5条）货物记录；每条货物信息独立完整；详情弹窗支持展开/折叠多条货物记录；货物类型代码与数据字典一致。 + +### TP-B-020: 第一次上报列表字段完整性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证第一次上报列表展示的字段完整且与需求一致，包括货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、业务类型、货物名称、装货地址、卸货地址、运输里程、合同编号、上报状态、操作共14个字段。 +- 关键验证点: 列表表头与需求一致性；14个字段均正确展示且顺序符合设计；业务类型与数据字典一致；装货地址和卸货地址完整展示；运输里程带单位（km）；上报状态标签颜色映射正确（上传中=蓝色/已上传=绿色/上传失败=红色/异常=橙色）。 + +--- + +## 模块C: 第二次上报-打款完成 (24个测试点) + +### TP-C-001: 打款完成后自动触发第二次上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证运单运费支付（财务打款）完成后，系统自动触发第二次上报，上报数据包含资金流水信息和车辆轨迹信息。 +- 关键验证点: 财务打款完成回调触发上报；上报请求包含运单信息+资金流水+车辆轨迹；上报成功后状态更新；第二次上报仅对已完成第一次上报的运单触发。 + +### TP-C-002: 第二次上报资金流水数据来源于支付流水表 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 数据校验 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-03：验证第二次上报的资金流水数据（支付金额、支付方式、支付时间、流水号等）从支付流水表实时读取，而非使用运单缓存中的合同金额。 +- 关键验证点: 上报数据中的金额与支付流水表实际打款金额完全一致；非从运单表或Redis缓存读取金额；数据库查询SQL日志可确认数据来源为支付流水表；金额字段精确到分（2位小数），无精度丢失。 + +### TP-C-003: 财务修改打款金额后第二次上报使用最新金额 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 数据校验 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-03：验证财务在账户管理模块修改打款金额后，第二次上报感知数据变更并使用修改后的最新金额。 +- 关键验证点: 合同金额10000元 → 财务调账修改为9500元 → 第二次上报金额为9500元；财务修改与上报触发有时间差时仍使用最新值；上报日志中可溯源金额来源；反例：不使用装货完成时缓存的合同金额。 + +### TP-C-004: 第二次上报列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证第二次上报列表展示的14个字段完整：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、承运运费、总金额、付款方式、付款时间、收款人、收款账号、收款账号类型、核验状态、异常项、上报状态、操作。 +- 关键验证点: 承运运费和总金额保留2位小数；付款时间为实际财务打款时间；操作列根据上报状态显示"上报"或"详情"按钮。 + +### TP-C-005: 收款账号类型标签颜色 — 个人账户(蓝色)/对公账户(绿色) +- 优先级: P2 +- 类型: UI测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证列表中收款账号类型标签颜色：个人账户显示蓝色标签，对公账户显示绿色标签。 +- 关键验证点: 司机个人银行卡(个人账户)=蓝色；企业银行账号(对公账户)=绿色；颜色与需求定义严格一致；列表中每条记录标签颜色根据实际账号类型渲染，不混淆。 + +### TP-C-006: 运单重复核验 — 通过场景 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证同一运单未重复上报时，监管平台"运单重复核验"返回通过。 +- 关键验证点: 首次上报的运单核验通过；不同运单号各自独立上报通过；核验状态标记为"通过"；无"运单重复"异常项出现。 + +### TP-C-007: 运单重复核验 — 异常场景（重复上报） +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证同一运单第二次上报时，监管平台"运单重复核验"检测到重复并返回异常。 +- 关键验证点: 重复上报后核验状态变为"异常"；异常项明确标注"运单重复核验"；异常原因清晰可读；异常运单可触发申诉流程。 + +### TP-C-008: 车辆资质核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证车辆道路运输证在有效期内时，监管平台"车辆资质核验"返回通过。 +- 关键验证点: 道路运输证有效期起止日期在有效期内；道路运输证号格式有效；车辆审核状态为"通过"的运单核验通过。 + +### TP-C-009: 车辆资质核验 — 异常场景（证件过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证车辆道路运输证已过期或缺失时，监管平台"车辆资质核验"返回异常。 +- 关键验证点: 道路运输证有效期的截止日期 < 当前日期时核验异常；无道路运输证号的车辆核验异常；异常项明确标注"车辆资质核验"；异常后可申诉。 + +### TP-C-010: 司机资质核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证司机从业资格证在有效期内时，监管平台"司机资质核验"返回通过。 +- 关键验证点: 从业资格证有效期起止日期在有效期内；从业资格证号格式有效；司机审核状态为"通过"的运单核验通过。 + +### TP-C-011: 司机资质核验 — 异常场景（证件过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证司机从业资格证已过期或缺失时，监管平台"司机资质核验"返回异常。 +- 关键验证点: 从业资格证有效期至 < 当前日期时核验异常；无从业资格证号时核验异常；异常项明确标注"司机资质核验"；异常后可申诉。 + +### TP-C-012: 集中支付核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证资金流水通过网货平台集中支付时，监管平台"集中支付核验"返回通过。 +- 关键验证点: 付款方为网货平台统一账户，核验通过；支付流水记录与集中支付模式匹配；核验状态为"通过"。 + +### TP-C-013: 集中支付核验 — 异常场景（非集中支付/支付信息异常） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证资金流水未通过网货平台集中支付或支付信息异常时，监管平台"集中支付核验"返回异常。 +- 关键验证点: 付款方非平台统一账户时核验异常；集中支付流水数据不完整时核验异常；异常项明确标注"集中支付核验"；异常后可申诉。 + +### TP-C-014: 资金流水核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证资金流水单号不重复且金额匹配时，监管平台"资金流水核验"返回通过。 +- 关键验证点: 流水号唯一不重复；上报金额与支付流水表实际金额一致；核验状态为"通过"。 + +### TP-C-015: 资金流水核验 — 异常场景（流水号重复/金额不匹配） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证资金流水单号重复或上报金额与支付流水不一致时，监管平台"资金流水核验"返回异常。 +- 关键验证点: 重复流水单号核验异常并提示；上报金额与支付流水金额偏差>0.01元时核验异常；异常项明确标注"资金流水核验"；异常后可申诉。 + +### TP-C-016: 合同核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证运输合同和委托合同均有效时，监管平台"合同核验"返回通过。 +- 关键验证点: 承运合同编号有效且存在于合同管理系统；委托合同编号（如有）有效；合同有效期覆盖运单执行日期；核验状态为"通过"。 + +### TP-C-017: 合同核验 — 异常场景（合同无效/过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证运输合同或委托合同无效/过期/缺失时，监管平台"合同核验"返回异常。 +- 关键验证点: 承运合同编号不存在时核验异常；合同有效期不包含运单执行日期时核验异常；异常项明确标注"合同核验"；异常后可申诉。 + +### TP-C-018: 车辆轨迹合规核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证车辆GPS轨迹真实、与运单路线匹配、轨迹点数量在2~2000范围内时，监管平台"车辆轨迹合规核验"返回通过。 +- 关键验证点: 轨迹点数量≥2且≤2000；轨迹路线与装货地→卸货地路线基本一致；轨迹时间与运单执行时间匹配；核验状态为"通过"。 + +### TP-C-019: 车辆轨迹合规核验 — 异常场景（点位不足/偏差过大/轨迹缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证车辆轨迹点数量不足(<2)、偏差过大、或轨迹数据缺失时，监管平台"车辆轨迹合规核验"返回异常。 +- 关键验证点: 轨迹点数量=1或0时核验异常；轨迹路线偏离装货-卸货路线超过合理范围时核验异常；异常项明确标注"车辆轨迹合规核验"；异常后可进入"补传轨迹"流程。 + +> **⚠️ API文档扩展说明 (来自原型&接口交叉分析)**: +> 根据网货企业端接口文档 V1.0.2 §4.1 异常项ID对照表，第二次上报核验项从需求的7类扩展为API定义的17项独立核验项。以下TP-C-006~TP-C-019覆盖了需求的7类核验（运单重复/车辆资质/司机资质/集中支付/资金流水/合同/轨迹合规），但API将其中部分类别拆分为更细粒度的独立核验项。 +> +> API文档完整17项: 100=委托合同, 120=承运合同, 130=实时定位, 140=运单时间逻辑, 150=车辆资质, 160=道路运输证, 170=驾驶证, 180=从业资格证, 190=车辆重复, 200=司机重复, 210=车辆轨迹, 220=运费收款, 230=公司统一收款, 240=集中支付, 250=资金流水, 260=发票信息, 270=非通行车辆可开票 +> +> 以下 TP-C-026~TP-C-049 为补充的12项独立核验项（每项 PASS + EXCEPTION），来源标注 [技术方案]。 + +### TP-C-025: 里程申诉功能 — 提交里程申诉 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证运单里程数据异常时，可通过 POST /mileageAppeal/insert 接口提交里程申诉，携带运单号(freightSheetNumber)、申诉内容(content)、投诉编号(complaintNumber)、申诉里程(mileage)参数。 +- 关键验证点: 里程申诉接口正常调用成功返回；必选参数齐全（运单号/申诉内容/投诉编号/申诉里程）；申诉提交后可在申诉记录中查看；里程申诉与异常申诉独立管理；缺少必选参数时接口返回明确错误提示。 + +### TP-C-026: 委托合同核验(100) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证委托合同编号有效且存在于合同管理系统、有效期覆盖运单执行日期时，监管平台"委托合同核验"返回通过。 +- 关键验证点: 委托合同编号有效且存在于系统；委托合同有效期覆盖运单执行日期；核验状态为"通过"；无"委托合同核验"异常项出现。 + +### TP-C-027: 委托合同核验(100) — 异常场景（合同无效/过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证委托合同编号不存在、无效或有效期不覆盖运单执行日期时，监管平台"委托合同核验"返回异常。 +- 关键验证点: 委托合同编号不存在时核验异常；合同有效期不覆盖运单执行日期时核验异常；委托合同为空时核验异常；异常项明确标注"委托合同核验"（代码100）；异常后可申诉。 + +### TP-C-028: 承运合同核验(120) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证承运合同编号有效且存在于合同管理系统、有效期覆盖运单执行日期时，监管平台"承运合同核验"返回通过。 +- 关键验证点: 承运合同编号有效且存在于系统；承运合同有效期覆盖运单执行日期；核验状态为"通过"；无"承运合同核验"异常项出现。 + +### TP-C-029: 承运合同核验(120) — 异常场景（合同无效/过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证承运合同编号不存在、无效或有效期不覆盖运单执行日期时，监管平台"承运合同核验"返回异常。 +- 关键验证点: 承运合同编号不存在时核验异常；合同有效期不覆盖运单执行日期时核验异常；承运合同为空时核验异常；异常项明确标注"承运合同核验"（代码120）；异常后可申诉。 + +### TP-C-030: 实时定位核验(130) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证车辆在运单执行期间有完整的实时定位数据（GPS轨迹覆盖整个运输过程）时，监管平台"实时定位核验"返回通过。 +- 关键验证点: 运单执行期间车辆实时定位数据完整；定位时间覆盖运单起运至送达时间范围；核验状态为"通过"；无"实时定位核验"异常项出现。 + +### TP-C-031: 实时定位核验(130) — 异常场景（定位数据缺失/不完整） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证车辆在运单执行期间缺少实时定位数据或定位数据不完整时，监管平台"实时定位核验"返回异常。 +- 关键验证点: 运输过程中定位数据长时间中断时核验异常；无任何实时定位数据时核验异常；定位数据时间范围未覆盖运单执行时间时核验异常；异常项明确标注"实时定位核验"（代码130）；异常后可申诉或补传定位数据。 + +### TP-C-032: 运单时间逻辑核验(140) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证运单各时间节点逻辑合理（建单时间 < 接单时间 < 起运时间 < 送达时间）时，监管平台"运单时间逻辑核验"返回通过。 +- 关键验证点: 建单时间早于接单时间；接单时间早于起运时间；起运时间早于送达时间；各时间节点无倒置或矛盾；核验状态为"通过"。 + +### TP-C-033: 运单时间逻辑核验(140) — 异常场景（时间倒置/不合理） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证运单各时间节点存在逻辑矛盾（如送达时间早于起运时间、接单时间早于建单时间等）时，监管平台"运单时间逻辑核验"返回异常。 +- 关键验证点: 起运时间晚于送达时间时核验异常；接单时间早于建单时间时核验异常；时间字段为空时核验异常；异常项明确标注"运单时间逻辑核验"（代码140）；异常后可申诉。 + +### TP-C-034: 道路运输证核验(160) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证车辆道路运输证在有效期内且证号格式有效时，监管平台"道路运输证核验"返回通过。 +- 关键验证点: 道路运输证有效期起止日期在当前日期范围内；道路运输证号格式有效且可查询；道路运输证发证机关信息完整；核验状态为"通过"；无"道路运输证核验"异常项出现。 + +### TP-C-035: 道路运输证核验(160) — 异常场景（过期/缺失/无效） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证车辆道路运输证过期、缺失或证号格式无效时，监管平台"道路运输证核验"返回异常。 +- 关键验证点: 道路运输证有效期截止日期 < 当前日期时核验异常；道路运输证号为空或格式无效时核验异常；证号在运政系统中查询不存在时核验异常；异常项明确标注"道路运输证核验"（代码160）；异常后可申诉。 + +### TP-C-036: 驾驶证核验(170) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证司机驾驶证在有效期内且证号与交管系统一致时，监管平台"驾驶证核验"返回通过。 +- 关键验证点: 驾驶证有效期覆盖运单执行日期；驾驶证号格式正确（18位）；驾驶证准驾车型与车辆类型匹配；核验状态为"通过"；无"驾驶证核验"异常项出现。 + +### TP-C-037: 驾驶证核验(170) — 异常场景（过期/缺失/准驾不符） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证司机驾驶证过期、缺失或准驾车型不匹配时，监管平台"驾驶证核验"返回异常。 +- 关键验证点: 驾驶证有效期截止日期 < 当前日期时核验异常；驾驶证号为空或格式无效时核验异常；准驾车型与实际驾驶车辆类型不匹配时核验异常；异常项明确标注"驾驶证核验"（代码170）；异常后可申诉。 + +### TP-C-038: 车辆重复核验(190) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证同一车辆未在同一时间段内被重复用于多个运单时，监管平台"车辆重复核验"返回通过。 +- 关键验证点: 车辆在运单执行时段内无其他重叠运单；车辆未同时出现在多个进行中的运单中；核验状态为"通过"；无"车辆重复核验"异常项出现。 + +### TP-C-039: 车辆重复核验(190) — 异常场景（车辆同时用于多个运单） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证同一车辆在同一时间段内被用于多个运单（时间重叠）时，监管平台"车辆重复核验"返回异常。 +- 关键验证点: 车辆在运单A执行期间同时出现在运单B中时核验异常；时间重叠超过合理阈值时核验异常；异常项明确标注"车辆重复核验"（代码190）；异常后可申诉。 + +### TP-C-040: 司机重复核验(200) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证同一司机未在同一时间段内被重复分配给多个运单时，监管平台"司机重复核验"返回通过。 +- 关键验证点: 司机在运单执行时段内无其他重叠运单；司机未同时驾驶多辆车辆执行不同运单；核验状态为"通过"；无"司机重复核验"异常项出现。 + +### TP-C-041: 司机重复核验(200) — 异常场景（司机同时执行多个运单） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证同一司机在同一时间段内被分配给多个运单（时间重叠）时，监管平台"司机重复核验"返回异常。 +- 关键验证点: 司机在运单A执行期间同时出现在运单B中时核验异常；时间重叠超过合理阈值时核验异常；异常项明确标注"司机重复核验"（代码200）；异常后可申诉。 + +### TP-C-042: 运费收款核验(220) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证运费收款方信息与实际司机/承运人一致、收款金额与运单运费匹配时，监管平台"运费收款核验"返回通过。 +- 关键验证点: 收款方身份与运单司机一致；收款金额与运单运费一致；收款账户信息有效；核验状态为"通过"；无"运费收款核验"异常项出现。 + +### TP-C-043: 运费收款核验(220) — 异常场景（收款人不一致/金额不匹配） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证运费收款人与运单司机不一致、收款金额与运费不匹配时，监管平台"运费收款核验"返回异常。 +- 关键验证点: 收款人姓名/身份证号与司机信息不一致时核验异常；收款金额与运单运费偏差超过阈值时核验异常；异常项明确标注"运费收款核验"（代码220）；异常后可申诉。 + +### TP-C-044: 公司统一收款核验(230) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证当收款方为公司统一收款账户时，公司信息与运单托运方信息一致，监管平台"公司统一收款核验"返回通过。 +- 关键验证点: 收款公司名称/统一社会信用代码与托运方一致；公司统一收款账户在系统中备案；核验状态为"通过"；无"公司统一收款核验"异常项出现。 + +### TP-C-045: 公司统一收款核验(230) — 异常场景（公司信息不一致/未备案） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证公司统一收款账户信息与托运方不一致或收款账户未备案时，监管平台"公司统一收款核验"返回异常。 +- 关键验证点: 收款公司名称与托运方名称不一致时核验异常；收款公司统一社会信用代码与托运方不一致时核验异常；收款账户未在系统中备案时核验异常；异常项明确标注"公司统一收款核验"（代码230）；异常后可申诉。 + +### TP-C-046: 发票信息核验(260) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证第三次上报关联的发票信息完整有效（发票号码/代码/金额匹配、销售方/受票方信息完整）时，监管平台"发票信息核验"返回通过。 +- 关键验证点: 发票号码与发票代码匹配有效；发票金额（价税合计）计算正确；销售方纳税人识别号有效；受票方信息与托运方一致；核验状态为"通过"。 + +### TP-C-047: 发票信息核验(260) — 异常场景（发票无效/信息不完整） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证发票号码/代码不匹配、发票信息不完整或发票已作废时，监管平台"发票信息核验"返回异常。 +- 关键验证点: 发票号码在税务系统中查询不到时核验异常；发票已作废/红冲时核验异常；受票方名称/纳税人识别号与托运方不一致时核验异常；异常项明确标注"发票信息核验"（代码260）；异常后可申诉。 + +### TP-C-048: 非通行车辆可开票核验(270) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证运单关联的车辆属于可开票车辆（即车辆资质、运营证照齐全且在合规运营范围内）时，监管平台"非通行车辆可开票核验"返回通过。 +- 关键验证点: 车辆运营证照齐全且在有效期内；车辆未被标记为不合规或黑名单；核验状态为"通过"；无"非通行车辆可开票核验"异常项出现。 + +### TP-C-049: 非通行车辆可开票核验(270) — 异常场景（车辆不合规/证照缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证车辆运营证照不全、车辆被标记为不合规或不在可开票范围内时，监管平台"非通行车辆可开票核验"返回异常。 +- 关键验证点: 车辆无有效道路运输证时核验异常；车辆被标记为运营异常/黑名单时核验异常；车辆类型不在可开票范围内时核验异常；异常项明确标注"非通行车辆可开票核验"（代码270）；异常后可申诉。 + +### TP-C-020: 后端校验 — 第二次上报依赖第一次上报完成 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-01：验证后端接口层面，第一次上报未完成（失败/进行中）时拒绝第二次上报，返回明确错误码。 +- 关键验证点: 第一次上报"上传失败"状态下触发第二次上报被拒绝；第一次上报"上传中"状态下触发第二次上报被拒绝；后端通过查询运单上报状态表校验，非仅前端控制；错误码和错误消息明确。 + +### TP-C-021: 第二次上报幂等性 — 防止重复上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-02：验证第二次上报具有幂等性，重复触发不产生多条上报记录，自动重试和手动触发互斥。 +- 关键验证点: 第二次上报自动重试期间禁止手动触发；同一运单第二次上报仅产生1条有效记录；分布式锁/幂等键控制并发；数据库唯一约束防止插入重复记录。 + +### TP-C-022: 补传轨迹功能 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证车辆轨迹合规核验异常后，运营人员可通过"补传轨迹"功能补充GPS轨迹数据，重新触发核验。 +- 关键验证点: 仅轨迹核验异常的运单显示"补传轨迹"按钮；补传后重新触发轨迹核验；补传的轨迹数据覆盖原有数据；补传后核验通过则异常项消除；补传操作记录到上报日志。 + +### TP-C-023: 第二次上报失败自动重试机制 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证第二次上报失败（超时或接口返回错误）后，系统自动重试（最多3次），重试间隔递增，3次全部失败后告警通知运营人员。 +- 关键验证点: 上报失败后自动触发重试（非人工触发）；最多重试3次；重试间隔递增（如5s/15s/30s）；每次重试在上报日志中独立记录；3次全部失败后通过站内信或短信告警通知运营人员；重试期间手动上传按钮不可用或提示"上报处理中"。 + +### TP-C-024: 第二次上报详情弹窗资金流水与车辆轨迹字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证第二次上报详情弹窗中资金流水信息（10字段）和车辆轨迹信息（6字段）的分组展示完整且字段顺序正确。 +- 关键验证点: 资金流水信息完整展示（支付金额/支付方式/支付时间/付款方名称/收款方名称/收款人/收款账号/收款账号类型/流水号/支付状态）；车辆轨迹信息完整展示（定位类型/定位时间/定位地点/经度/纬度/轨迹类型）；可选字段缺失时显示"-"或"无"而不空白；弹窗分组标签正确（运单信息/托运方信息/收货方信息/资金流水信息/车辆轨迹信息/异常信息）。 + +--- + +## 模块D: 第三次上报-开票完成 (11个测试点) + +### TP-D-001: 开票完成后触发第三次上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证发票开具完成后，系统触发第三次上报，上报数据包含运单信息、发票信息和油气发票信息。 +- 关键验证点: 发票开具完成后自动触发上报；上报数据包含托运单号数组、发票信息17字段；若有关联油气发票则包含油气发票信息；仅开票完成的运单触发。 + +### TP-D-002: 第三次上报列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证第三次上报列表展示的11个字段完整：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、发票号码、发票金额、开票日期、核验状态、异常原因、上报状态、操作。⚠️ 待确认: 原型列表比需求多4个字段（税率、销售方名称、受票方名称、油气票张数），共15列（含checkbox），需确认最终版本。 +- 关键验证点: 发票金额保留2位小数（价税合计）；开票日期格式正确；核验状态/异常原因/上报状态数据准确。 + +### TP-D-003: 第三次上报发票信息字段完整性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证第三次上报详情弹窗中"发票信息"分组的17个字段完整展示。 +- 关键验证点: 托运单号数组支持多个托运单号；发票号码、发票代码号、发票金额(价税合计)、开票日期必选完整；销售方8个字段(名称/纳税人识别号/地址/电话/开户行/银行账户)完整；受票方6个字段(名称/纳税人识别号/地址/电话/开户行/银行卡号)完整；注：第三次上报无税率字段。 + +### TP-D-004: 第三次上报油气发票信息 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证运单关联油气发票时，第三次上报包含油气发票信息（油气托运单号、油气发票文件），支持多条油气发票。 +- 关键验证点: 有油气发票时正常上报；无油气发票时不影响上报（可选字段）；多条油气发票时字段展示正确；油气发票文件支持查看/下载。 + +### TP-D-005: 后端校验 — 第三次上报依赖第二次上报完成 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-01：验证后端接口层面，第二次上报未完成（失败/进行中/未触发）时拒绝第三次上报，返回明确错误码。 +- 关键验证点: 第二次上报未完成时调用第三次上报接口被拒绝；错误码明确标识"前置上报（第二次）未完成"；后端通过查询运单上报状态表校验；第三阶段完整依赖链校验（第1→第2→第3）。 + +### TP-D-006: 增值税发票验证失败处理 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证增值税发票验证失败时（发票号码/代码/金额不匹配等），第三次上报失败并返回明确错误提示。 +- 关键验证点: 发票号码格式无效时上报失败；发票代码与发票号码不匹配时上报失败；发票金额超出合理范围时上报失败；失败提示指明具体错误字段和原因。 + +### TP-D-007: 第三次上报自动重试 — 最多3次 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [需求] +- 描述: 验证第三次上报失败后自动重试（最多3次），全部失败后告警通知运营人员。 +- 关键验证点: 重试次数不超过3次；重试间隔递增；全部失败后标记"上传失败"并告警；告警通知中包含运单号、发票号、失败原因。 + +### TP-D-008: 第三次上报异常信息展示 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证第三次上报详情弹窗中"异常信息"分组包含核验状态、异常原因、异常时间、处理状态，与申诉模块数据联动。 +- 关键验证点: 核验通过时异常原因为空；核验异常时展示具体异常项和原因；核验状态与看板/申诉模块数据一致。 + +### TP-D-009: 第三次上报幂等性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 +- 来源: [最佳实践][历史缺陷] +- 描述: 验证第三次上报具有幂等性，同一运单同一发票信息不能重复上报。 +- 关键验证点: 同一运单重复触发第三次上报仅产生1条有效记录；分布式锁/幂等键控制并发；重复提交返回"上报已存在"提示。 + +### TP-D-010: 第三次上报发票金额精度校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [漏测清单][风险矩阵] +- 描述: 验证第三次上报的发票金额（价税合计）保留2位小数，不出现浮点数精度问题。 +- 关键验证点: 金额计算精度正确（如0.01元不丢失）；大金额（如 999999.99）上报准确；金额字段使用 DECIMAL 类型而非 FLOAT；上报数据与开票系统数据完全一致。 + +### TP-D-011: 第三次上报货物信息/保险信息逐源验证 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [漏测清单] +- 描述: 验证第三次上报中的运单信息字段数据来源正确——价格/货物信息来源于运单表，保险信息来源于保险模块，非缓存数据。 +- 关键验证点: 修改运单表数据后上报使用最新值；修改保险信息后上报使用最新值；字段取值链路可追溯；不依赖装货完成时的数据快照。 + +### TP-D-012: 发票合规查询 — 托运人发票是否系统核验合规 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证可通过 POST /verificationSummary/cargoOwnerInvoiceInfo 接口查询托运人（货主）发票是否已通过系统核验合规，用于判断第三次上报前置条件。 +- 关键验证点: 输入有效托运人信息返回发票合规状态；发票合规时返回通过标识；发票不合规时返回异常原因；接口支持批量查询多个托运人发票合规状态；接口响应时间在合理范围内（< 3s）。 + +--- + +## 模块E: ETC发票上传 (9个测试点) + +### TP-E-001: ETC发票上传触发 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证ETC发票在税务抵扣完成后触发上传至安徽监管平台。 +- 关键验证点: 税务抵扣完成后 ETC 发票自动/手动触发上传；上传数据包含运单信息+ETC发票信息18字段；上传成功后可在列表查看状态。 + +### TP-E-002: ETC发票列表字段完整性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证ETC上传列表展示的11个字段完整：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、ETC发票号码、发票金额、税率、上传状态、操作。 +- 关键验证点: ETC发票号码与高速公路电子发票号码一致；发票金额和税率（3%）正确展示；上传状态标签颜色符合规范。 + +### TP-E-003: ETC发票详情弹窗 — 字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证ETC发票详情弹窗包含3个分组：运单信息（7字段）、ETC发票信息（每张发票18字段）、异常信息。 +- 关键验证点: ETC发票18字段全部展示：ETC发票号码、ETC发票代码、开票时间、发票金额、税率(3%)、税额、价税合计、销售方名称、销售方税号、受票方名称、受票方税号、入口收费站、出口收费站、交易时间、交易金额、交易匹配时间、交易流水号、ETC发票文件；运单信息7字段完整；异常信息4字段完整。 + +### TP-E-004: 税务抵扣完成前置条件校验 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 +- 来源: [需求] +- 描述: 验证ETC发票上传必须在税务抵扣完成后进行，未完成税务抵扣时上传被拒绝。 +- 关键验证点: 税务抵扣未完成时上传返回明确错误；错误提示包含"请先完成税务抵扣"；后端校验税务抵扣状态；税务抵扣完成后上传才可成功。 + +### TP-E-005: ETC发票验证失败处理 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证ETC发票信息验证失败时（发票号码/代码无效、金额不匹配、税率不正确等），上传失败并给出明确提示。 +- 关键验证点: 发票号码格式无效时上传失败；发票代码与号码不匹配时上传失败；税率非3%时提示税率异常；交易金额与实际通行费不匹配时验证失败；失败提示明确指示错误字段。 + +### TP-E-006: ETC上传自动重试 — 最多3次 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [需求] +- 描述: 验证ETC上传失败后自动重试最多3次，全部失败后告警通知。 +- 关键验证点: 3次重试均失败后标记"上传失败"并告警；重试间隔递增；每次重试记录到上报日志。 + +### TP-E-007: ETC税额计算校验 — 税额=发票金额×3% +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][风险矩阵] +- 描述: 验证ETC发票税额计算公式：税额 = 发票金额 x 3%，结果保留2位小数，涉及资损风险需精确验证。 +- 关键验证点: 发票金额100元 → 税额=3.00元；发票金额0.01元 → 税额=0.00元(或四舍五入规则明确)；大金额(如1000000元)计算不溢出；税额与价税合计逻辑关系正确(价税合计=金额+税额)。 + +### TP-E-008: ETC上传幂等性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 +- 来源: [最佳实践][历史缺陷] +- 描述: 验证同一ETC发票不能重复上传，具有幂等性。 +- 关键验证点: 同一ETC发票号重复上传被拒绝；返回"该ETC发票已上传"提示；数据库存在唯一约束防止重复记录。 + +### TP-E-009: ETC多张发票同时上传 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [需求][项目画像] +- 描述: 验证同一运单可能关联多张ETC发票（不同路段），支持批量上传和多张发票的列表展示。 +- 关键验证点: 多张ETC发票各自独立上传互不干扰；列表中单运单可展示多张ETC发票记录；每张发票的税额独立计算；合计税额正确汇总。 + +--- + +## 模块F: 异常申诉功能 (16个测试点) + +### TP-F-001: 申诉完整闭环 — 发起→复核→反馈→判断 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证申诉功能的完整闭环：查看异常 → 发起申诉 → 省平台复核 → 接收反馈 → 合规判断，端到端验证每个环节。⚠️ 待确认: 申诉状态枚举三版本不一致——需求(未申诉/申诉中/申诉通过/申诉驳回)、原型(未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回)、API(未申诉100/审核通过110/审核不通过120/已取消130)，以API §4.4为权威，需确认UI映射。 +- 关键验证点: 异常运单可发起申诉；申诉提交后状态保持"未申诉(100)"（异常项处理状态变为申诉中 abnormalDetails[].state=110）；省平台复核后反馈结果更新；反馈通过→申诉状态变为"审核通过(110)"；反馈驳回→申诉状态变为"审核不通过(120)"，可补充材料重新申诉。 + +### TP-F-002: 申诉列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证申诉记录管理页面列表展示的13个字段完整：运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、异常项、申诉状态、申诉时间、申诉人、省平台反馈结果、监管平台反馈时间、操作。 +- 关键验证点: 每个字段有对应数据；申诉状态与需求定义一致；申诉时间为实际提交时间；省平台反馈结果与实际反馈内容一致。 + +### TP-F-003: 申诉状态流转 — 全部合法路径 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 +- 来源: [需求][漏测清单] +- 描述: 验证申诉状态流转全路径（以API §4.4为权威）：未申诉(100) → [提交申诉，异常项state=110申诉中] → 审核通过(110) / 审核不通过(120) → (审核不通过后) 重新申诉 → 未申诉(100)[新申诉单]；以及 未申诉(100) → 已取消(130)。⚠️ 待确认: 原型中"待省平台反馈"+"反馈处理中"如何映射到API枚举；"已取消(130)"的触发条件和权限需确认。 +- 关键验证点: 未申诉(100)状态下可发起申诉；异常项申诉中(abnormalDetails[].state=110)状态下不可重复发起同一异常项申诉；审核通过(110)后状态不可再变更（终态）；审核不通过(120)后可点击"重新申诉"发起新一轮申诉；已取消(130)为终态；每种状态变更记录到处理记录时间线。 + +### TP-F-004: 申诉详情弹窗 — 分组字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证申诉详情弹窗包含5个分组：申诉信息、运单信息、异常信息、省平台反馈信息、处理记录。 +- 关键验证点: 申诉信息分组含申诉单号/上报阶段/异常项/申诉原因/申诉状态/申诉时间/申诉人/申诉附件；省平台反馈信息含反馈结果/反馈时间/反馈意见；处理记录以时间线形式展示：操作人/操作时间/操作类型/操作内容。 + +### TP-F-005: 申诉附件上传功能 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][项目画像] +- 描述: 验证发起申诉时支持上传附件（如证明材料图片/PDF），附件上传功能正常。 +- 关键验证点: 支持上传多个附件；附件格式支持常见类型(png/jpg/pdf)；附件大小有限制且超标时提示；上传后可在详情弹窗中查看/下载；上传失败有重试机制。 + +### TP-F-006: 审核不通过(120)后重新申诉 — 补充材料再发起 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证申诉被省平台审核不通过(120)后，运营人员可补充材料，点击"重新申诉"发起新一轮申诉。 +- 关键验证点: 审核不通过(120)状态下"重新申诉"按钮可见可用；重新申诉时原有申诉记录保留；新一轮申诉生成新的申诉单号；重新申诉可上传新的附件材料；新的申诉有独立的处理记录时间线。 + +### TP-F-007: 17项核验（API文档定义）异常各自发起申诉 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [需求] +- 描述: 验证第二次上报的17项核验（API文档§4.1定义：委托合同100/承运合同120/实时定位130/运单时间逻辑140/车辆资质150/道路运输证160/驾驶证170/从业资格证180/车辆重复190/司机重复200/车辆轨迹210/运费收款220/公司统一收款230/集中支付240/资金流水250/发票信息260/非通行车辆可开票270）每项核验异常均可独立发起申诉。⚠️ 待确认: 核验项从需求7类扩展为API文档17项，需确认每项是否均有独立申诉入口。 +- 关键验证点: 每种核验异常项对应独立的申诉入口；申诉中(abnormalDetails[].state=110)的异常项信息与核验结果一致；不同异常项的申诉原因字段独立；某一异常项申诉不影响其他异常项。 + +### TP-F-008: 从看板直接跳转申诉 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证从看板"操作"列点击"申诉"按钮，可跳转到申诉页面并自动填充运单号、异常项信息。 +- 关键验证点: 看板"申诉"按钮点击后路由跳转正确；跳转后页面自动加载该运单的异常信息；运单号和异常项预填充正确；不需要运营人员手动查找运单。 + +### TP-F-009: 申诉权限控制 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 权限控制 +- 来源: [项目画像] +- 描述: 验证仅运营人员有权发起申诉和管理申诉记录，其他角色（司机/车队长/货主/财务）不能操作申诉功能。 +- 关键验证点: 运营人员可见"申诉"按钮和申诉记录页面；司机端不可见申诉功能；财务人员可查看申诉记录但不可发起申诉；越权操作被正确拦截并记录审计日志。 + +### TP-F-010: 申诉处理记录时间线展示 +- 优先级: P2 +- 类型: UI测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证申诉详情弹窗中"处理记录"以时间线形式展示，每条记录包含操作人、操作时间、操作类型、操作内容。 +- 关键验证点: 时间线按时间倒序排列；每步操作（发起申诉/省平台反馈/重新申诉）均有一条记录；操作时间精确到秒；操作类型准确（发起申诉/审核通过/审核不通过等）。 + +### TP-F-011: 异常代码一览表匹配校验 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证需求文档中"异常代码一览表"定义的每种异常代码，在申诉页面中正确映射为对应的中文异常项名称。 +- 关键验证点: 每种异常代码有明确的中文描述；异常代码与异常项名称一一对应；省平台返回的异常代码能被正确解析；未知异常代码有兜底展示（如显示原始代码+标注"未知异常"）。 + +### TP-F-012: 申诉并发控制 — 同一异常项不可重复申诉 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 +- 来源: [漏测清单] +- 描述: 验证同一运单同一异常项申诉中(abnormalDetails[].state=110)状态下不可再次发起申诉，防止重复提交。 +- 关键验证点: 异常项申诉中(abnormalDetails[].state=110)状态下点击"申诉"按钮被禁用或提示"申诉处理中"；快速双击"提交申诉"按钮仅产生1条申诉记录；后端有状态校验，申诉中不可重新发起。 + +### TP-F-013: 申诉超时处理 — 省平台长时间无反馈 +- 优先级: P3 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [漏测清单] +- 描述: 验证申诉提交后，省平台长时间无反馈时，系统有合理的超时处理和状态提示。 +- 关键验证点: 申诉提交后超过一定时间（如7个工作日）无反馈时，系统给出"等待省平台复核中"的提示或超时告警；不自动变更申诉状态为通过/驳回；运营人员可查看申诉等待时长。 + +### TP-F-014: 单次申诉仅支持单个异常项 — 申诉表单单选约束 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [技术方案] +- 描述: 验证申诉表单中异常项选择器仅支持单选（radio或单选下拉），不可多选。根据API §3.3，`verificationAbnormalItems`参数"只支持单个异常项目申诉"。 +- 关键验证点: 异常项选择器为单选控件（非复选框）；不可同时勾选多个异常项后提交；选择器交互方式明确为单选（radio button 或 single-select dropdown）。 + +### TP-F-015: 多异常项运单逐次申诉 — 同一运单分别发起多次申诉 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [技术方案] +- 描述: 验证同一运单存在两个或多个异常项（如"车辆资质150"和"资金流水250"同时异常）时，需分别对每个异常项发起独立申诉，每个申诉对应一个申诉单号。 +- 关键验证点: 运单有2个异常项时，可分别发起2次申诉（每次选1个异常项）；每次申诉生成独立的申诉单号(complaintNumber)；申诉记录列表中该运单有2条独立申诉记录；不同异常项的申诉互不影响（一项通过另一项驳回各自独立流转）。 + +### TP-F-016: 申诉接口 verificationAbnormalItems 参数单值校验 — 传入多个ID时接口拒绝 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [技术方案] +- 描述: 验证调用 `POST /appeal/insert` 时，若 `verificationAbnormalItems` 传入多个异常项ID（如 "120,160"），接口应返回错误并拒绝提交。API §3.3 明确"只支持单个异常项目申诉"。 +- 关键验证点: 传入逗号分隔的多个ID（如"120,160"）时接口返回错误；错误码明确指示"仅支持单个异常项申诉"；传入单个ID时接口正常处理；传入空字符串或null时接口返回参数缺失错误；前端在提交前已做单选校验（双保险）。 + +--- + +## 模块G: 上报日志 (9个测试点) + +### TP-G-001: 上报日志 — 按运单号/托运单号/货源单号模糊搜索 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证上报日志页面支持按运单号/托运单号/货源单号模糊搜索，快速定位相关日志。 +- 关键验证点: 输入完整单号精确匹配；输入部分字符模糊匹配；输入不存在的单号显示空结果；三种单号搜索互不干扰。 + +### TP-G-002: 上报日志 — 按上报阶段筛选 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证上报日志支持按"全部/第一次上报/第二次上报/第三次上报/ETC上传"筛选。 +- 关键验证点: 每种阶段独立筛选数据正确；ETC上传有独立筛选项；默认"全部"展示所有阶段日志。 + +### TP-G-003: 上报日志 — 按上报结果筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证上报日志支持按"全部/成功/失败"筛选上报结果。 +- 关键验证点: "成功"仅展示HTTP 2xx的日志；"失败"展示所有非成功日志(含超时/4xx/5xx)；筛选结果与实际日志记录一致。 + +### TP-G-004: 上报日志 — 时间范围筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证上报日志支持按开始时间-结束时间范围筛选日志记录。 +- 关键验证点: 精确时间范围筛选数据正确；跨天/跨月筛选正常；开始时间>结束时间时给出提示或自动交换；不选时间范围默认显示全部。 + +### TP-G-005: 上报日志列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证上报日志列表展示的9个字段完整：序号、货源单号、运单号、托运单号、上报阶段、上报结果、接口URL、HTTP状态码、响应时间、上报时间、操作。 +- 关键验证点: 接口URL完整展示（含域名和路径）；HTTP状态码为实际返回状态码（200/400/500等）；响应时间单位明确（ms）；上报时间为实际请求发起时间。 + +### TP-G-006: 上报日志操作 — 弹窗查看完整请求/响应报文 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证点击日志"操作"列的详情按钮，弹窗展示完整的请求报文（Request）和响应报文（Response），用于问题排查。 +- 关键验证点: 请求报文完整展示：URL、Method、Headers、Body；响应报文完整展示：Status Code、Headers、Body；JSON 报文格式化展示（缩进/语法高亮）；长报文支持滚动查看和复制。 + +### TP-G-007: 上报日志全阶段覆盖 — 每个上报阶段的日志记录 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证每个上报阶段（第一次/第二次/第三次/ETC）以及自动修改字段接口的每次调用都在日志中有完整记录。 +- 关键验证点: 第一次上报+自动修改字段接口均有日志；第二次上报+7类核验结果均有日志；第三次上报日志完整；ETC上传日志完整；自动重试的每次请求均独立记录。 + +### TP-G-008: 上报日志失败记录的可追溯性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [漏测清单] +- 描述: 验证上报失败的日志记录足够详细，可通过日志定位失败原因——包括错误响应体、异常堆栈（如有）、重试次数等。 +- 关键验证点: 失败日志包含完整的Error Response Body；超时日志标注"timeout"并记录超时时长；重试日志中标注当前是第几次重试；异常日志可关联到具体运单ID便于排查。 + +### TP-G-009: 上报日志审计 — 操作人追踪 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 权限控制 +- 来源: [项目画像][最佳实践] +- 描述: 验证上报日志中可区分自动触发上报和手动触发上报，并记录操作人信息。 +- 关键验证点: 自动触发上报的日志标注"系统自动"或"auto"；手动触发上报的日志记录操作人用户名；手动上传的操作人信息与实际登录用户一致；审计能力满足合规要求。 + +--- + +## 跨模块测试点（6个测试点） + +### TP-X-001: 完整三阶段依赖链端到端验证 — 后端三重校验 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 端到端验证三阶段依赖链：装货完成→第一次上报成功→打款完成→第二次上报成功→开票完成→第三次上报成功。核心验证后端在每个阶段都做了前置状态校验。 +- 关键验证点: 第1次上报失败→第2次上报接口拒绝；第2次上报失败→第3次上报接口拒绝；第1、2、3次顺序不可跳级；依赖链校验在后端实现（非仅前端控制）；每个阶段的阻断/通过状态独立。 + +### TP-X-002: 多模块数据一致性 — 修改源数据后上报同步 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 数据校验 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-03：验证上报数据字段溯源正确，修改来源表数据后各阶段上报能感知变更并使用最新值。 +- 关键验证点: 修改司机信息→第一次上报使用最新司机信息；修改支付流水→第二次上报使用最新金额；修改发票信息→第三次上报使用最新发票数据；修改ETC信息→ETC上传使用最新数据；数据库查询日志可确认数据来源表，非缓存。 + +### TP-X-003: 安徽运八全流程 — 正常运单完整上报链路 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 端到端验证一个安徽税源地运单从装货到ETC上传的完整三阶段+ETC上报链路，所有阶段核验通过，无异常。 +- 关键验证点: 装货完成→第1次上报成功(绿色)→核验通过→自动修改字段→打款完成→第2次上报成功(核验全通过)→开票完成→第3次上报成功→税务抵扣→ETC上传成功；每个阶段看板数据正确更新；上报日志完整记录全链路。 + +### TP-X-004: 非安徽税源地运单 — 全流程不上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][项目画像] +- 描述: 验证税源地为非安徽省（如云南=28）的运单，全部三个阶段和ETC上传均不触发上报。 +- 关键验证点: 云南税源地运单装货完成不触发第1次上报；打款完成不触发第2次上报；开票完成不触发第3次上报；税务抵扣不触发ETC上传；看板中不显示该运单。 + +### TP-X-005: 三阶段上报各省份数据隔离 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 权限控制 +- 来源: [项目画像][历史缺陷] +- 描述: 验证多省份部署场景下，安徽运八上报数据与其他省份（如云南）上报数据完全隔离，互不干扰。 +- 关键验证点: 安徽运单仅上报至安徽监管平台；云南运单仅上报至云南监管平台；省份代码各自独立（安徽=34、云南=28）；不同省份的上报日志和数据记录物理/逻辑隔离。 + +### TP-X-006: 回单签收后自动流转上报 — 时序正确性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 状态流转 +- 来源: [需求][项目画像] +- 描述: 验证运单在回单签收→财务打款的时序下，第二次上报的触发时机为"打款完成"而非"回单签收"，时序正确。 +- 关键验证点: 回单签收完成但未打款时，不触发第二次上报；财务打款完成后才触发第二次上报；上报时间戳与打款完成时间关系合理。 + +--- + +## 历史缺陷防御映射表 + +| 历史缺陷ID | 防御测试点 | +| :--- | :--- | +| BUG-202607-01（阶段依赖链断裂） | TP-B-005, TP-C-020, TP-D-005, TP-X-001 | +| BUG-202607-02（重试幂等缺陷） | TP-B-014, TP-C-021, TP-D-009, TP-E-008, TP-F-012 | +| BUG-202607-03（跨模块数据不一致） | TP-C-002, TP-C-003, TP-D-011, TP-X-002 | +| BUG-202607-04（省份代码硬编码） | TP-B-004, TP-X-005 | + +## 漏测清单覆盖映射表 + +| 漏测项 | 覆盖测试点 | +| :--- | :--- | +| 空值/Null | TP-B-018 | +| 金额精度 | TP-C-002, TP-D-010, TP-E-007 | +| 重复提交/防抖 | TP-B-014, TP-C-021, TP-D-009, TP-E-008 | +| 超时处理 | TP-B-015, TP-B-016, TP-F-013 | +| 列表字段完整性 | TP-A-008, TP-C-004, TP-D-002, TP-E-002, TP-F-002, TP-G-005 | +| 查询重置 | TP-A-007 | +| 状态与按钮映射 | TP-A-010, TP-B-009 | +| 多阶段依赖链 | TP-B-005, TP-C-020, TP-D-005, TP-X-001 | +| 第三方核验逐项覆盖 | TP-C-006 ~ TP-C-019（7类核验×通过+异常=14个测试点）+ TP-C-026 ~ TP-C-049（API文档12项补充核验×通过+异常=24个测试点），共覆盖API文档17项核验 | 已覆盖 | +| 重试+手动触发并发 | TP-B-014, TP-C-021 | +| 跨模块数据一致性 | TP-C-002, TP-C-003, TP-X-002 | +| 省份/区域配置隔离 | TP-B-004, TP-X-005 | +| 上报数据字段溯源 | TP-C-002, TP-D-011, TP-X-002 | +| 标签颜色映射 | TP-A-009, TP-B-010, TP-C-005 | +| 详情弹窗分组完整性 | TP-A-011, TP-B-011, TP-B-012, TP-C-004, TP-D-003, TP-E-003, TP-F-004 | +| 轨迹数据边界（2~2000） | TP-C-018, TP-C-019 | +| 申诉闭环 | TP-F-001, TP-F-003, TP-F-006 | +| 操作日志可追溯 | TP-G-005, TP-G-006, TP-G-007, TP-G-008, TP-G-009 | + +--- + +> ⚠️ 待确认项： +> 1. 需求中"异常代码一览表"章节仅有标题无具体内容，需与产品确认完整的异常代码映射表后补充 TP-F-011 的详细验证数据。 +> 2. 自动重试的具体间隔时间（5s/15s/30s 为假设值），需与技术方案确认后更新 TP-B-007, TP-C-022, TP-D-007, TP-E-006 中的重试间隔。 +> 3. ETC税额边界值（0.01元 → 税额=0.00）的四舍五入规则需与财务确认，更新 TP-E-007。 +> 4. 申诉超时告警阈值（假设7个工作日）需与产品确认，更新 TP-F-013。 +> 5. 需求关联与冲突报告未识别到冲突项，建议在后续需求评审中人工确认安徽运八与现有云南运八上报逻辑是否存在字段/接口冲突。 diff --git a/output/versions/安徽运八需求/v4/安徽运八需求_测试用例.md b/output/versions/安徽运八需求/v4/安徽运八需求_测试用例.md new file mode 100644 index 0000000..127f1ba --- /dev/null +++ b/output/versions/安徽运八需求/v4/安徽运八需求_测试用例.md @@ -0,0 +1,394 @@ +# 安徽运八需求 测试用例 + +> 生成时间: 2026-07-13 +> 需求文档: output/normalized_inputs/安徽运八需求/requirement.md +> 测试点来源: output/test_points/安徽运八需求_测试点.md (106个测试点) +> 测试数据参考: output/analysis/安徽运八需求_测试数据.md +> 关联分析: output/analysis/安徽运八需求_关联与冲突.md +> +> 测试用例总数: 154 +> P0: 29 / P1: 82 / P2: 36 / P3: 8 +> 模块分布: A(看板)=18, B(第一次上报)=23, C(第二次上报)=49, D(第三次上报)=15, E(ETC)=12, F(申诉)=20, G(日志)=11, X(跨模块)=7 + +--- + +## 模块A: 上报运单看板 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_DASH_001 | 平台端-监管上报-上报看板 | 验证看板按完整运单号精确搜索运单 | P0 | 功能测试 | 1. 使用super_admin账号登录管理端https://ybxcx.ynyun8.com:8000/admin；2. 系统中存在运单号YB202607130001的运单记录 | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入完整运单号"YB202607130001"；3. 点击搜索按钮或按回车键 | 运单号: YB202607130001 | 页面列表仅展示1条记录，运单号列显示"YB202607130001"（精确匹配）；数据库查询返回唯一记录，where条件为waybill_no='YB202607130001' | 对应TP-A-001 | +| AH_REPORT_DASH_002 | 平台端-监管上报-上报看板 | 验证看板按运单号模糊搜索匹配多条记录 | P0 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在运单号包含"YB20260713"前缀的多条运单（如YB202607130001、YB202607130002、YB202607130003） | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入"YB20260713"；3. 点击搜索 | 运单号部分字符: YB20260713 | 页面列表展示3条记录，所有运单号均包含"YB20260713"；数据库查询SQL使用LIKE '%YB20260713%'匹配，返回3条结果 | 对应TP-A-001 | +| AH_REPORT_DASH_003 | 平台端-监管上报-上报看板 | 验证看板按不存在的单号搜索显示空结果 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端 | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入不存在的单号"NOTEXIST999"；3. 点击搜索 | 运单号: NOTEXIST999 | 页面列表显示空状态，提示"未找到匹配数据"或空结果占位图；数据库查询返回0条记录；页面不出现控制台报错 | 对应TP-A-001 | +| AH_REPORT_DASH_004 | 平台端-监管上报-上报看板 | 验证看板按"第一次上报"阶段筛选运单 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在不同上报阶段的运单（至少含1条第一次上报、1条第二次上报的运单） | 1. 进入"监管上报-上报看板"页面，默认为"全部"；2. 点击上报阶段下拉框，选择"第一次上报"；3. 观察列表数据 | 筛选条件: 第一次上报 | 列表仅展示上报阶段为"第一次上报"的运单；每条记录的上报阶段列均为"第一次上报"；数据库查询添加where report_stage='first'过滤条件；总条目数与数据库中第一次上报运单数一致 | 对应TP-A-002 | +| AH_REPORT_DASH_005 | 平台端-监管上报-上报看板 | 验证看板按"异常"核验状态筛选运单 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在核验状态为"通过"和"异常"的运单 | 1. 进入"监管上报-上报看板"页面；2. 点击核验状态下拉框，选择"异常"；3. 观察列表数据 | 筛选条件: 核验状态=异常 | 列表仅展示核验状态为"异常"（橙色标签）的运单；所有"通过"的运单被过滤；数据库查询添加where verification_status='abnormal'条件 | 对应TP-A-003 | +| AH_REPORT_DASH_006 | 平台端-监管上报-上报看板 | 验证看板按"申诉中"申诉状态筛选运单 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在申诉状态为"申诉中"的运单至少1条 | 1. 进入"监管上报-上报看板"页面；2. 点击申诉状态下拉框，选择"申诉中"；3. 观察列表数据并与全部列表对比 | 筛选条件: 申诉状态=申诉中 | 列表仅展示申诉状态为"申诉中"的运单；申诉状态列标签显示"申诉中"且颜色与需求定义一致；数据库查询添加where appeal_status='in_progress'条件 | 对应TP-A-004；⚠️ 待确认: 原型看板申诉状态下拉值为"未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回"，与需求不一致 | +| AH_REPORT_DASH_007 | 平台端-监管上报-上报看板 | 验证看板组合筛选—第二次上报+异常+申诉中+运单号模糊搜索 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 数据库中存在满足组合条件的运单（第二次上报、核验异常、申诉中、运单号含"YB2026"） | 1. 进入"监管上报-上报看板"页面；2. 上报阶段选"第二次上报"；3. 核验状态选"异常"；4. 申诉状态选"申诉中"；5. 运单号输入"YB2026"；6. 点击搜索 | 组合条件: 第二次上报+异常+申诉中; 运单号模糊: YB2026 | 列表仅展示同时满足4个条件的运单；每个条件都在数据库SQL中体现（多WHERE条件AND组合）；空结果时显示"未找到匹配数据"；切换任一筛选条件不丢失运单号搜索框中已输入的关键字 | 对应TP-A-005 | +| AH_REPORT_DASH_008 | 平台端-监管上报-上报看板 | 验证看板导出当前筛选结果为Excel文件 | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板列表中有≥20条运单数据 | 1. 进入"监管上报-上报看板"页面；2. 设置筛选条件（如上报阶段=第一次上报）；3. 点击"导出"按钮；4. 等待文件下载完成；5. 打开下载的Excel文件 | 筛选: 第一次上报 | 浏览器触发文件下载，文件名为.xlsx格式；Excel文件可正常打开，表头包含14个列表字段（货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、申诉状态、异常项、货物名称、合同金额、最新核验时间、操作）；导出数据行数与筛选结果一致；导出过程中页面不卡死、不超时 | 对应TP-A-006 | +| AH_REPORT_DASH_009 | 平台端-监管上报-上报看板 | 验证看板大数据量导出不超时不OOM | P2 | 性能测试 | 1. 使用super_admin账号登录管理端；2. 数据库中存在≥2000条运单记录 | 1. 进入"监管上报-上报看板"页面；2. 选择"全部"筛选条件；3. 点击"导出"按钮；4. 记录从点击到下载完成的时间 | 导出全部数据, 约2000+条 | 导出在60秒内完成下载（不超时）；导出的Excel文件包含全部数据行，无截断；后台服务内存使用率未显著增长（无OOM）；导出过程中看板页面仍可正常操作 | 对应TP-A-006 | +| AH_REPORT_DASH_010 | 平台端-监管上报-上报看板 | 验证看板重置按钮恢复所有查询条件至默认值 | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 已在上报阶段选择"第二次上报"、核验状态选择"异常"、运单号输入"YB2026" | 1. 进入"监管上报-上报看板"页面；2. 点击"重置"按钮；3. 观察页面各筛选条件和列表数据 | 重置前条件: 第二次上报+异常+YB2026 | 模糊搜索输入框清空为空白；所有下拉筛选恢复为"全部"；列表刷新展示默认全部运单数据（初始状态）；分页回到第1页；数据库查询恢复为无过滤条件的默认查询 | 对应TP-A-007 | +| AH_REPORT_DASH_011 | 平台端-监管上报-上报看板 | 验证看板列表展示14个字段且顺序与需求一致 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在至少1条完整运单记录 | 1. 进入"监管上报-上报看板"页面；2. 查看列表表头和第一条数据的各列内容；3. 对比需求文档中的字段顺序 | 查看运单YB202607130001 | 列表14个字段顺序为: 货源单号→运单号→托运单号→车牌号→司机姓名→托运方名称→上报阶段→核验状态→申诉状态→异常项→货物名称→合同金额→最新核验时间→操作；合同金额列保留2位小数（如¥10,000.00）；最新核验时间为YYYY-MM-DD HH:mm:ss格式；异常项为空时显示"-"而非"null"或"undefined" | 对应TP-A-008 | +| AH_REPORT_DASH_012 | 平台端-监管上报-上报看板 | 验证看板状态标签颜色—蓝色(上传中)、绿色(已上传)、红色(上传失败)、橙色(异常) | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在4种上报状态的运单各1条 | 1. 进入"监管上报-上报看板"页面；2. 找到上报状态为"上传中"的运单，查看标签颜色；3. 找到"已上传"运单，查看标签颜色；4. 找到"上传失败"运单，查看标签颜色；5. 找到"异常"运单，查看标签颜色 | 运单1: 上传中; 运单2: 已上传; 运单3: 上传失败; 运单4: 异常 | "上传中"标签显示蓝色背景/文字；"已上传"标签显示绿色背景/文字；"上传失败"标签显示红色背景/文字；"异常"标签显示橙色背景/文字；状态切换时标签颜色即时刷新不闪烁；申诉状态标签（申诉中/申诉通过/申诉驳回）颜色各自区分清晰 | 对应TP-A-009 | +| AH_REPORT_DASH_013 | 平台端-监管上报-上报看板 | 验证看板操作列—异常运单显示申诉按钮、所有运单显示详情按钮 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在核验通过的运单1条和核验异常的运单1条 | 1. 进入"监管上报-上报看板"页面；2. 查看核验通过运单的操作列按钮；3. 查看核验异常运单的操作列按钮；4. 点击异常运单的"申诉"按钮 | 通过运单: YB202607130001; 异常运单: YB202607130002 | 核验通过运单的操作列显示"详情"和"进度"按钮，不显示"申诉"按钮；核验异常运单的操作列显示"申诉""详情""进度"三个按钮；点击"申诉"按钮后页面路由跳转至申诉页面，URL携带正确的运单ID参数；点击"详情"按钮弹出详情弹窗，展示该运单的完整上报信息 | 对应TP-A-010 | +| AH_REPORT_DASH_014 | 平台端-监管上报-上报看板 | 验证看板详情弹窗—建单信息分组13字段完整 | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板列表中有可查看详情的运单YB202607130001 | 1. 进入"监管上报-上报看板"页面；2. 点击运单YB202607130001操作列的"详情"按钮；3. 在弹窗中查看"建单信息"分组的所有字段 | 运单号: YB202607130001 | 建单信息分组展示13个字段: 上游企业委托运输单号、本运单单号、托运人建单时间、网络货运经营者名称、统一社会信用代码、道路运输经营许可证编号、业务类型代码、运输组货方式代码、司机接单时间、司机起运时间、承运合同编号（必选）、委托合同编号（可选）、运输里程（可选）；必选字段均有值；可选字段委托合同编号和运输里程为空时显示"-"；各字段格式与接口规范一致 | 对应TP-A-011 | +| AH_REPORT_DASH_015 | 平台端-监管上报-上报看板 | 验证看板详情弹窗—各子对象分组字段完整(托运人/收货方/司机/车辆/货物) | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板列表中有运单YB202607130001包含完整的子对象信息 | 1. 进入"监管上报-上报看板"页面；2. 点击运单YB202607130001的"详情"按钮；3. 依次展开托运人信息、收货方信息、司机信息、车辆信息、货物信息分组 | 运单号: YB202607130001; 司机: 15188888888 | 托运人信息7字段完整（含统一社会信用代码18位格式校验）；收货方信息5字段完整（身份证号如适用需脱敏展示）；司机信息13字段完整（从业资格证有效期起止日期格式正确）；车辆信息19字段完整（VIN码17位正确展示）；货物信息支持多条记录展开，每条含货物名称、货物类型代码、货物量、计量单位；可选字段为空时显示"-" | 对应TP-A-011 | +| AH_REPORT_DASH_016 | 平台端-监管上报-上报看板 | 验证看板空数据状态展示友好占位提示 | P3 | 易用性测试 | 1. 使用super_admin账号登录管理端；2. 选择一个筛选条件组合确保结果为0条（如运单号输入"ZZZZZZZZZZ"） | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框输入"ZZZZZZZZZZ"；3. 点击搜索 | 运单号: ZZZZZZZZZZ | 列表区域显示友好空状态占位图/文，不显示空白表格；有明确文字提示"未找到匹配数据"或类似文案；浏览器开发者工具Console无报错；页面无崩溃或白屏 | 对应TP-A-012 | +| AH_REPORT_DASH_017 | 平台端-监管上报-上报看板 | 验证看板分页功能—翻页数据不重复不遗漏 | P3 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板中有超过20条运单（默认每页20条） | 1. 进入"监管上报-上报看板"页面，记录第1页的运单号列表；2. 点击"下一页"进入第2页；3. 记录第2页的运单号列表；4. 对比两页数据；5. 查看分页组件显示的总条数 | 每页20条 | 第1页和第2页的运单号无重复；第2页首条数据不是第1页已出现的数据；切换每页条数（如50条/页）后分页重新计算正确；分页组件显示的总条数与数据库COUNT查询结果一致；数据按最新核验时间倒序排列（最近核验的在最前面） | 对应TP-A-013 | +| AH_REPORT_DASH_018 | 平台端-监管上报-上报看板 | 验证不同角色看板权限—运营可见全部/财务可见打款字段/司机不可见平台端看板 | P1 | 安全性测试 | 1. 准备super_admin账号(运营)、财务账号、车队长账号13113113113、司机账号15188888888；2. 系统中存在运单数据 | 1. 使用super_admin登录，进入看板，验证可见全部运单和全部字段；2. 使用财务账号登录，进入看板，验证可见运单范围和打款相关字段；3. 使用车队长13113113113登录司机端，验证是否有看板入口；4. 使用司机15188888888登录司机端，验证是否有看板入口 | 运营: super_admin; 财务: finance_user; 车队长: 13113113113/88888888; 司机: 15188888888/88888888 | super_admin可见全部运单和全部14个字段；财务可见运单但打款金额/付款方式/收款账号类型等字段可见；车队长登录司机端后无"监管上报-上报看板"菜单入口，直接URL访问被拦截返回403；司机登录司机端后同样无看板入口，越权访问被拦截并记录审计日志 | 对应TP-A-014 | + +--- + +## 模块B: 第一次上报-装货完成 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_R1_001 | 平台端-监管上报-第一次上报 | 验证装货完成后自动触发第一次上报且全部子对象数据完整 | P0 | 功能测试 | 1. 使用司机账号15188888888登录司机端APP；2. 存在一条安徽税源地(provinceCode=34)的运单YB202607130001，状态为"待装货"；3. 运单包含完整的托运人、收货方、司机、车辆、货物信息 | 1. 司机到达装货地，上传装货照片和资料；2. 司机在APP端点击"确认装货完成"；3. 等待系统自动触发第一次上报；4. 使用super_admin登录管理端，进入"监管上报-第一次上报"列表查看该运单上报状态 | 运单号: YB202607130001; 司机: 15188888888; 装货地省份代码: 34 | 司机端提示"装货完成，上报已提交"；管理端第一次上报列表中出现该运单记录，上报状态为"上传中"（蓝色标签），随后变为"已上传"（绿色标签）；上报请求JSON包含全部7个子对象(建单信息/托运人/收货方/司机/车辆/货物/保险)；数据库report_record表status字段从0变为1，上报时间字段非空 | 对应TP-B-001 | +| AH_REPORT_R1_002 | 平台端-监管上报-第一次上报 | 验证非安徽税源地运单(云南=28)装货完成后不触发第一次上报 | P0 | 功能测试 | 1. 使用司机账号15188888888登录司机端APP；2. 存在一条云南税源地(provinceCode=28)的运单YB202607130002，状态为"待装货" | 1. 司机完成装货并点击"确认装货完成"；2. 检查管理端"监管上报-第一次上报"列表；3. 检查系统日志是否有上报请求记录 | 运单号: YB202607130002; 省份代码: 28(云南) | 管理端第一次上报列表中不出现该运单记录；系统日志中无该运单的上报接口调用记录；运单状态正常流转为"运输中"，不受上报模块影响；无任何错误日志或异常告警产生 | 对应TP-B-002 | +| AH_REPORT_R1_003 | 平台端-监管上报-第一次上报 | 验证安徽税源地运单(省份代码=34)触发上报，其他省份不触发 | P0 | 功能测试 | 1. 准备安徽(34)、云南(28)、四川(51)税源地的运单各1条；2. 三条运单状态均为"待装货" | 1. 分别对三条运单确认装货完成；2. 进入管理端第一次上报列表查看；3. 查询数据库report_record表 | 安徽运单: provinceCode=34; 云南运单: provinceCode=28; 四川运单: provinceCode=51 | 仅安徽(34)运单在第一次上报列表中出现，上报状态正常更新；云南(28)和四川(51)运单均不在列表中；数据库report_record表仅新增1条记录，province_code=34 | 对应TP-B-002; TP-B-004 | +| AH_REPORT_R1_004 | 平台端-监管上报-第一次上报 | 验证第一次上报建单信息必选字段缺失时上报被拒绝并明确提示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 构造一条建单信息中"承运合同编号"为空的运单YB202607130003 | 1. 触发该运单装货完成事件（模拟或真实操作）；2. 查看第一次上报返回结果；3. 查看上报日志中的错误信息 | 运单号: YB202607130003; 缺失字段: 承运合同编号 | 上报接口返回错误，提示"必选字段承运合同编号不能为空"或类似明确消息；上报状态标记为"上传失败"（红色标签）；上报日志中记录该次失败请求，包含请求体和错误响应体；运单状态不会错误地标记为"已上传" | 对应TP-B-003 | +| AH_REPORT_R1_005 | 平台端-监管上报-第一次上报 | 验证第一次上报统一社会信用代码格式校验（非18位时拒绝） | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 构造一条运单，托运人统一社会信用代码为"123456"（6位无效格式） | 1. 触发该运单装货完成事件；2. 查看上报接口返回；3. 查看上报日志 | 运单号: YB202607130004; 信用代码: 123456(无效) | 上报接口返回校验错误，提示"统一社会信用代码格式不正确，需为18位"；上报状态标记为"上传失败"；不会错误地将无效代码上报至监管平台 | 对应TP-B-003 | +| AH_REPORT_R1_006 | 平台端-监管上报-第一次上报 | 验证第一次上报中司机信息省份代码为安徽=34（非云南=28） | P0 | 功能测试 | 1. 使用super_admin登录管理端；2. 准备一条安徽税源地(34)的完整运单YB202607130001 | 1. 触发的第一次上报完成后；2. 在上报日志中查看该次上报的完整请求JSON；3. 定位司机信息(driverInfo)中的provinceCode字段值 | 运单号: YB202607130001; 期望省份代码: 34 | 请求JSON中driverInfo.provinceCode="34"；不会出现值"28"；装货地行政区划代码前2位也为"34"（安徽省代码340000）；数据库/Redis/配置文件中无硬编码省份代码28 | [AI修正: 历史缺陷防御] - BUG-202607-04 | +| AH_REPORT_R1_007 | 平台端-监管上报-第一次上报 | 验证第一次上报失败后第二次上报接口被拒绝并返回错误码"前置上报未完成" | P0 | 功能测试 | 1. 运单YB202607130005第一次上报状态为"上传失败"（3次重试均失败）；2. 财务已完成打款（触发第二次上报的条件已满足） | 1. 通过API直接调用第二次上报接口（或模拟打款完成回调触发）；2. 查看接口返回的HTTP状态码和错误消息 | 运单号: YB202607130005 | 接口返回错误码（如HTTP 400或业务错误码"PRE_STAGE_NOT_COMPLETED"），错误消息包含"前置上报未完成"或"请先完成第一次上报"；第二次上报列表中该运单上报状态未变更，不会出现"上传中"或"已上传"；数据库report_record表无第二次上报的新记录 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R1_008 | 平台端-监管上报-第一次上报 | 验证第一次上报自动重试3次全部失败后第三次上报同样被拒绝 | P0 | 功能测试 | 1. 运单YB202607130006第一次上报3次重试全部失败；2. 第二次上报也未完成 | 1. 通过API直接调用第三次上报接口；2. 查看接口返回 | 运单号: YB202607130006 | 接口返回错误码，明确标识"前置上报（第一次）未完成"；后端通过查询运单上报状态表(如report_status)做校验，非仅依赖前端布尔值；第三次上报列表无该运单记录 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R1_009 | 平台端-监管上报-第一次上报 | 验证第一次上报成功后监管平台核验通过时自动调用修改字段接口 | P1 | 功能测试 | 1. 运单YB202607130001第一次上报成功且状态为"已上传"；2. 模拟监管平台返回核验通过 | 1. 等待或模拟监管平台核验通过回调；2. 查看上报日志中是否有"修改第一次上报部分字段"的接口调用记录；3. 查看修改后的字段值 | 运单号: YB202607130001; 实际运输里程: 158.5km（装货后变化值） | 上报日志中出现"修改字段"接口调用记录；修改的字段包含实际运输里程等装货后变化字段；修改成功后第一次上报状态仍保持"已上传"（绿色）；若修改接口调用失败，有重试和告警机制 | 对应TP-B-006 | +| AH_REPORT_R1_010 | 平台端-监管上报-第一次上报 | 验证第一次上报失败后自动重试最多3次且间隔递增 | P1 | 功能测试 | 1. 运单YB202607130007第一次上报时模拟监管平台返回失败 | 1. 触发第一次上报；2. 监控上报日志中的重试记录和时间间隔；3. 等待3次重试全部完成 | 运单号: YB202607130007; 重试间隔: 5s/15s/30s（参考值） | 第1次上报失败后自动触发第2次（间隔约5s）；第2次失败后触发第3次（间隔约15s）；第3次失败后触发第4次（即总共3次重试，间隔约30s）；3次重试全部失败后上报状态变为"上传失败"（红色标签），停止重试；上报日志中每1次请求（含重试）均有独立日志记录 | 对应TP-B-007 | +| AH_REPORT_R1_011 | 平台端-监管上报-第一次上报 | 验证第一次上报3次重试全部失败后通知运营人员 | P1 | 功能测试 | 1. 运单YB202607130008第一次上报3次重试均失败；2. super_admin账号可接收站内信 | 1. 等待3次重试全部失败；2. 使用super_admin登录管理端，查看站内信/消息通知；3. 点击通知中的链接 | 运单号: YB202607130008; 失败原因: 监管平台连接超时 | super_admin收到站内信通知，标题含"上报失败"标记；通知内容包含运单号YB202607130008、失败原因"连接超时"、失败时间；点击通知中的链接可直接跳转到该运单对应的上报详情页 | 对应TP-B-008 | +| AH_REPORT_R1_012 | 平台端-监管上报-第一次上报 | 验证上传失败状态下运营人员可点击手动上传按钮重新发起上报 | P1 | 功能测试 | 1. 运单YB202607130009上报状态为"上传失败"（红色标签）；2. 使用super_admin登录管理端 | 1. 进入"监管上报-第一次上报"列表；2. 找到YB202607130009，查看操作列；3. 点击"手动上传"按钮；4. 确认上传；5. 等待上传完成 | 运单号: YB202607130009 | 操作列显示"手动上传"按钮（仅上传失败状态可见）；点击后发起新的上报请求；上传成功后状态从"上传失败"（红色）变为"已上传"（绿色）；手动上传记录出现在上报日志中，标注操作人为"super_admin" | 对应TP-B-009 | +| AH_REPORT_R1_013 | 平台端-监管上报-第一次上报 | 验证自动重试期间点击手动上传时系统提示"上报处理中"并拒绝重复提交 | P0 | 功能测试 | 1. 运单YB202607130010第一次上报正在自动重试中（第1次已失败，第2次进行中）；2. 使用super_admin登录管理端 | 1. 进入第一次上报列表，找到该运单；2. 等待自动重试进行中时，快速点击"手动上传"按钮 | 运单号: YB202607130010 | 前端弹出提示"上报处理中，请勿重复操作"或按钮被置灰不可点击；后端返回"上报处理中"错误（分布式锁检测到正在进行中的上报）；数据库report_record表中该运单不会产生第2条上报记录；最终仅有1条上报记录（自动重试完成后产生） | [AI修正: 历史缺陷防御] - BUG-202607-02 | +| AH_REPORT_R1_014 | 平台端-监管上报-第一次上报 | 验证同一运单同一阶段快速连续点击手动上传仅发起1次请求 | P0 | 功能测试 | 1. 运单YB202607130011上报状态为"上传失败"；2. 使用super_admin登录管理端 | 1. 进入第一次上报列表；2. 快速连续点击"手动上传"按钮5次（模拟前端未做防抖的情况或快速双击）；3. 查看上报日志中实际发出的请求次数 | 运单号: YB202607130011; 快速点击5次 | 上报日志中仅记录1次上报请求（前端防抖+后端幂等键控制）；数据库report_record表仅产生1条新的上报记录；后端分布式锁或唯一约束（如运单号+阶段号）防止并发插入重复记录 | [AI修正: 历史缺陷防御] - BUG-202607-02 | +| AH_REPORT_R1_015 | 平台端-监管上报-第一次上报 | 验证第一次上报接口超时(>30s)后转为上传失败并触发重试 | P1 | 功能测试 | 1. 运单YB202607130012准备上报；2. 通过工具模拟监管平台接口响应延迟>30秒 | 1. 触发第一次上报；2. 观察前端页面Loading状态；3. 等待超时后的系统处理 | 运单号: YB202607130012; 超时阈值: 30s | 前端页面显示Loading加载状态并持续至超时；超时后上报状态变为"上传失败"（红色标签）；前端页面超时后有友好提示"上报超时，系统将自动重试"；系统自动触发第1次重试；数据库report_record表中记录超时状态 | 对应TP-B-015 | +| AH_REPORT_R1_016 | 平台端-监管上报-第一次上报 | 验证弱网环境(高延迟高丢包)下第一次上报重试机制正常工作 | P2 | 功能测试 | 1. 通过Charles/Fiddler或网络模拟工具设置网络延迟2000ms、丢包率30%；2. 运单YB202607130013待上报 | 1. 在弱网条件下触发第一次上报；2. 观察上报请求发送和响应情况；3. 等待重试或恢复 | 运单号: YB202607130013; 网络延迟: 2000ms; 丢包率: 30% | 请求发送成功但响应延迟时不立即判定失败（超时阈值30s）；弱网恢复后若重试成功则状态正常流转为"已上传"；断网时上报请求发送失败的提示友好明确；不论弱网还是正常网络，数据不会出现不一致或重复 | 对应TP-B-016 | +| AH_REPORT_R1_017 | 平台端-监管上报-第一次上报 | 验证10个运单同时装货完成时并发上报互不干扰 | P2 | 性能测试 | 1. 准备10条安徽税源地(34)的运单YB202607130014~YB202607130023，状态均为"待装货" | 1. 通过脚本同时触发10条运单的装货完成事件；2. 监控数据库和上报日志；3. 验证每条运单的上报状态 | 10条运单同时装货完成 | 10条运单各自独立触发上报，无相互阻塞；数据库无死锁(deadlock)异常；上报日志中每条运单独立记录其上报请求和响应；每条运单的上报状态独立正确更新 | 对应TP-B-017 | +| AH_REPORT_R1_018 | 平台端-监管上报-第一次上报 | 验证第一次上报可选字段（委托合同编号/运输里程/挂车牌照号等）为空时正常上报 | P3 | 功能测试 | 1. 准备一条运单YB202607130024，可选字段全部留空：委托合同编号、运输里程、挂车牌照号、行驶证档案编号、道路运输证有效期起/至、保险单号、保险公司名称 | 1. 触发该运单装货完成事件；2. 查看上报结果；3. 查看上报请求JSON和详情弹窗 | 运单号: YB202607130024; 可选字段全为空 | 上报接口不报错，上报成功；请求JSON中可选字段值为null或不传均可正常处理；管理端详情弹窗中可选字段显示"-"而非"null"或"undefined" | 对应TP-B-018 | +| AH_REPORT_R1_019 | 平台端-监管上报-第一次上报 | 验证运单包含1条货物记录时正常上报 | P3 | 功能测试 | 1. 准备运单YB202607130025，仅含1条货物：货物名称"钢材"、货物类型代码"01"、货物量"10.5"、计量单位"吨" | 1. 触发装货完成；2. 查看上报请求JSON中goodsInfos数组；3. 查看详情弹窗货物信息展示 | 运单号: YB202607130025; 货物: 钢材 10.5吨 | goodsInfos数组包含1个元素，4个字段完整；详情弹窗中货物信息分组正确展示1条记录 | 对应TP-B-019 | +| AH_REPORT_R1_020 | 平台端-监管上报-第一次上报 | 验证运单包含5条货物记录时各货物独立完整上报 | P3 | 功能测试 | 1. 准备运单YB202607130026，含5条货物记录：钢材10.5吨、水泥20吨、砂石15吨、砖块5000块、木材8立方 | 1. 触发装货完成；2. 查看上报请求JSON中goodsInfos数组长度和内容；3. 查看详情弹窗中多条货物的展示 | 运单号: YB202607130026; 货物: 5条 | goodsInfos数组包含5个元素；每条货物独立完整，互不影响；详情弹窗中货物信息支持展开/折叠展示5条记录；每条货物名称、类型代码、货物量、计量单位均正确 | 对应TP-B-019 | +| AH_REPORT_R1_021 | 平台端-监管上报-第一次上报 | 验证第一次上报业务类型代码和运输组货方式代码为有效枚举值 | P1 | 功能测试 | 1. 准备运单YB202607130027，业务类型代码为"1"(普通货运)、运输组货方式代码为"10"(道路货运) | 1. 触发装货完成上报；2. 查看上报请求JSON中waybillInfo的businessTypeCode和transportGroupModeCode字段值；3. 模拟提交无效枚举值（如"99"），验证拒绝 | 运单号: YB202607130027; businessTypeCode: 1; transportGroupModeCode: 10 | 有效枚举值上报成功；无效枚举值（如businessTypeCode="99"）上报时接口返回校验错误，明确提示"业务类型代码无效"；不会将无效枚举值上报至监管平台 | 对应TP-B-003 | +| AH_REPORT_R1_022 | 平台端-监管上报-第一次上报 | 验证第一次上报详情弹窗—异常信息分组展示核验状态/异常原因/异常时间/处理状态 | P2 | 功能测试 | 1. 运单YB202607130028第一次上报核验状态为"异常"；2. 使用super_admin登录管理端 | 1. 进入第一次上报列表，点击运单YB202607130028的"详情"按钮；2. 查看弹窗中"异常信息"分组的4个字段 | 运单号: YB202607130028; 异常原因示例: 司机资质核验不通过 | 异常信息分组包含: 核验状态（显示"异常"）、异常原因（如"司机从业资格证已过期"）、异常时间（显示实际核验时间）、处理状态（如"未申诉"）；核验通过时异常原因为空 | 对应TP-B-013 | +| AH_REPORT_R1_023 | 平台端-监管上报-第一次上报 | 验证第一次上报状态标签颜色：上传中=蓝色、已上传=绿色、上传失败=红色、异常=橙色 | P2 | 功能测试 | 1. 准备4条运单各处于不同上报状态 | 1. 进入第一次上报列表；2. 依次查看4种状态运单的标签颜色 | 运单A: 上传中; 运单B: 已上传; 运单C: 上传失败; 运单D: 异常 | 上传中=蓝色标签+加载动画；已上传=绿色标签；上传失败=红色标签；异常=橙色标签；状态切换时标签颜色即时更新不闪烁 | 对应TP-B-010 | +| AH_REPORT_R1_024 | 平台端-监管上报-第一次上报 | 验证第一次上报列表14个字段完整展示且顺序正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 第一次上报列表中有至少1条完整记录 | 1. 进入"监管上报-第一次上报"列表；2. 查看列表表头和第一条数据的所有列内容；3. 验证每个字段的展示格式 | 运单号: YB202607130001; 运输里程: 350km; 合同编号: HT202607001 | 列表展示14个字段: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/业务类型/货物名称/装货地址/卸货地址/运输里程/合同编号/上报状态/操作；业务类型与数据字典中枚举值一致；装货地址和卸货地址完整展示（省市区+详细地址）；运输里程带单位km；上报状态标签颜色符合规范（上传中=蓝色/已上传=绿色/上传失败=红色/异常=橙色）；列表按上报时间倒序排列 | 对应TP-B-020；[AI修正: 覆盖缺口补充] | + +--- + +## 模块C: 第二次上报-打款完成 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_R2_001 | 平台端-监管上报-第二次上报 | 验证财务打款完成后自动触发第二次上报且包含资金流水和车辆轨迹信息 | P0 | 功能测试 | 1. 运单YB202607130001已完成第一次上报且状态为"已上传"；2. 财务在账户管理模块对该运单执行打款操作，金额¥10,000.00 | 1. 财务完成打款操作；2. 系统收到打款完成回调；3. 进入管理端"监管上报-第二次上报"列表查看 | 运单号: YB202607130001; 打款金额: ¥10,000.00; 付款方式: 光大银行 | 第二次上报列表中新增该运单记录，上报状态从"上传中"变为"已上传"（绿色标签）；上报请求包含运单信息+资金流水信息+车辆轨迹信息三个模块；数据库report_record表新增第二次上报记录，stage=2 | 对应TP-C-001 | +| AH_REPORT_R2_002 | 平台端-监管上报-第二次上报 | 验证第二次上报资金流水数据来源于支付流水表（非运单缓存） | P0 | 功能测试 | 1. 运单YB202607130001合同金额¥10,000.00；2. 支付流水表实际打款金额¥10,000.00；3. 财务已打款完成 | 1. 触发第二次上报；2. 查询上报日志中的请求JSON；3. 对比请求中的金额与运单表合同金额、支付流水表打款金额；4. 检查数据库查询SQL日志确认数据来源 | 运单号: YB202607130001; 合同金额: ¥10,000.00; 支付流水实际打款: ¥10,000.00 | 上报数据中的金额与支付流水表实际打款金额¥10,000.00完全一致；数据库查询SQL日志显示数据源为payment_flow表，非waybill表或Redis缓存；金额精确到分（2位小数），¥10,000.00无精度丢失 | [AI修正: 历史缺陷防御] - BUG-202607-03 | +| AH_REPORT_R2_003 | 平台端-监管上报-第二次上报 | 验证财务修改打款金额后第二次上报使用最新金额（非缓存合同金额） | P0 | 功能测试 | 1. 运单YB202607130001合同金额¥10,000.00；2. 财务在账户管理模块调账将打款金额修改为¥9,500.00；3. 财务执行打款 | 1. 财务修改打款金额（¥10,000.00→¥9,500.00）；2. 财务完成打款；3. 触发第二次上报；4. 查看上报请求中的金额字段 | 运单号: YB202607130001; 合同金额: ¥10,000.00; 修改后打款金额: ¥9,500.00 | 上报请求中的金额为¥9,500.00（修改后的值），非¥10,000.00（合同金额）；上报日志中可溯源金额来源为支付流水表；不会使用装货完成时缓存的合同金额¥10,000.00 | [AI修正: 历史缺陷防御] - BUG-202607-03 | +| AH_REPORT_R2_004 | 平台端-监管上报-第二次上报 | 验证第二次上报列表17个字段完整且收款账号类型标签颜色正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 第二次上报列表中有至少2条数据（一条个人账户、一条对公账户） | 1. 进入"监管上报-第二次上报"列表；2. 查看列表表头和第一条数据的各列内容；3. 查看收款账号类型列的标签颜色 | 运单A: 个人账户(司机银行卡); 运单B: 对公账户(企业账号) | 列表展示: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/承运运费/总金额/付款方式/付款时间/收款人/收款账号/收款账号类型/核验状态/异常项/上报状态/操作；承运运费和总金额保留2位小数；付款时间为实际财务打款时间；个人账户显示蓝色标签，对公账户显示绿色标签 | 对应TP-C-004; TP-C-005 | +| AH_REPORT_R2_005 | 平台端-监管上报-第二次上报 | 验证运单重复核验—首次上报的运单核验通过 | P0 | 功能测试 | 1. 运单YB202607130001为首次进行第二次上报，此前未在任何阶段重复上报 | 1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项 | 运单号: YB202607130001(首次上报) | 核验状态标记为"通过"（绿色标签）；异常项列中无"运单重复核验"异常记录；监管平台返回的核验结果中duplicateCheck=pass；数据库运单核验记录表verification_result中duplicate_check_status='pass' | 对应TP-C-006 | +| AH_REPORT_R2_006 | 平台端-监管上报-第二次上报 | 验证运单重复核验—重复上报检测到异常并标注异常项 | P0 | 功能测试 | 1. 运单YB202607130001已成功完成第二次上报和核验；2. 模拟或真实触发该运单的第二次重复上报 | 1. 通过API再次调用第二次上报接口（使用同一运单号YB202607130001）；2. 等待监管平台核验结果返回 | 运单号: YB202607130001(重复上报) | 核验状态变为"异常"（橙色标签）；异常项列明确标注"运单重复核验"；异常原因可读（如"该运单已存在有效上报记录"）；该异常运单可触发申诉流程，"申诉"按钮可见可用 | 对应TP-C-007 | +| AH_REPORT_R2_007 | 平台端-监管上报-第二次上报 | 验证车辆资质核验—道路运输证在有效期内核验通过 | P1 | 功能测试 | 1. 运单YB202607130001关联的车辆道路运输证有效期起: 2025-01-01, 有效期至: 2027-01-01（当前日期2026-07-13在有效期内）；2. 车辆审核状态为"通过" | 1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项 | 运单号: YB202607130001; 道路运输证有效期: 2025-01-01~2027-01-01 | 核验状态为"通过"；无"车辆资质核验"异常项；监管平台返回vehicleQualCheck=pass；数据库verification_result.vehicle_qual_status='pass' | 对应TP-C-008 | +| AH_REPORT_R2_008 | 平台端-监管上报-第二次上报 | 验证车辆资质核验—道路运输证已过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130029关联的车辆道路运输证有效期至: 2025-12-31（当前日期2026-07-13已过期）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果返回；3. 查看异常项详情 | 运单号: YB202607130029; 道路运输证有效期至: 2025-12-31(已过期) | 核验状态变为"异常"（橙色标签）；异常项列标注"车辆资质核验"；异常原因描述如"道路运输证已过期（有效期至2025-12-31）"；该异常运单可发起申诉 | 对应TP-C-009 | +| AH_REPORT_R2_009 | 平台端-监管上报-第二次上报 | 验证司机资质核验—从业资格证在有效期内核验通过 | P1 | 功能测试 | 1. 运单YB202607130001关联的司机从业资格证有效期起: 2024-06-01, 有效期至: 2028-06-01（在有效期内）；2. 司机审核状态为"通过" | 1. 触发第二次上报；2. 等待核验结果；3. 查看核验状态 | 运单号: YB202607130001; 从业资格证: 有效期内 | 核验状态为"通过"；无"司机资质核验"异常项；监管平台返回driverQualCheck=pass | 对应TP-C-010 | +| AH_REPORT_R2_010 | 平台端-监管上报-第二次上报 | 验证司机资质核验—从业资格证已过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130030关联的司机从业资格证有效期至: 2025-01-01（已过期）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果；3. 查看异常项 | 运单号: YB202607130030; 从业资格证有效期至: 2025-01-01(已过期) | 核验状态变为"异常"；异常项标注"司机资质核验"；异常原因如"司机从业资格证已过期"；可发起申诉 | 对应TP-C-011 | +| AH_REPORT_R2_011 | 平台端-监管上报-第二次上报 | 验证集中支付核验—付款方为平台统一账户时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001打款付款方为网货平台统一账户；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130001; 付款方: 网货平台统一账户 | 核验状态为"通过"；无"集中支付核验"异常项；监管平台返回centralPayCheck=pass；支付流水记录与集中支付模式匹配 | 对应TP-C-012 | +| AH_REPORT_R2_012 | 平台端-监管上报-第二次上报 | 验证集中支付核验—付款方非平台统一账户时核验异常 | P1 | 功能测试 | 1. 运单YB202607130031打款付款方为非平台统一账户（如第三方代付账户）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130031; 付款方: 第三方代付账户(非平台) | 核验状态变为"异常"；异常项标注"集中支付核验"；异常原因如"付款方非集中支付账户"；可发起申诉 | 对应TP-C-013 | +| AH_REPORT_R2_013 | 平台端-监管上报-第二次上报 | 验证资金流水核验—流水号唯一且金额匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001资金流水号唯一（如PAY202607130001）；2. 上报金额¥10,000.00与支付流水表实际打款金额完全一致 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130001; 流水号: PAY202607130001; 金额: ¥10,000.00 | 核验状态为"通过"；无"资金流水核验"异常项；监管平台返回fundFlowCheck=pass | 对应TP-C-014 | +| AH_REPORT_R2_014 | 平台端-监管上报-第二次上报 | 验证资金流水核验—流水号重复时核验异常 | P1 | 功能测试 | 1. 运单YB202607130032使用的资金流水号与已有运单的流水号重复（如均使用PAY202607130001） | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130032; 重复流水号: PAY202607130001 | 核验状态变为"异常"；异常项标注"资金流水核验"；异常原因包含"流水号重复"提示；可发起申诉 | 对应TP-C-015 | +| AH_REPORT_R2_015 | 平台端-监管上报-第二次上报 | 验证资金流水核验—上报金额与支付流水偏差>0.01元时核验异常 | P1 | 功能测试 | 1. 运单YB202607130033支付流水表实际打款¥9,500.00，但上报时发送¥10,000.00（偏差¥500.00>¥0.01） | 1. 触发第二次上报（携带错误金额）；2. 等待核验结果 | 运单号: YB202607130033; 上报金额: ¥10,000.00; 支付流水实际: ¥9,500.00 | 核验状态变为"异常"；异常项标注"资金流水核验"；异常原因包含"金额不匹配"提示；可发起申诉 | 对应TP-C-015 | +| AH_REPORT_R2_016 | 平台端-监管上报-第二次上报 | 验证合同核验—承运合同和委托合同均有效时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001承运合同编号CTC202607001有效（存在于合同管理系统，有效期覆盖运单执行日期2026-07-10~2026-07-13）；2. 委托合同编号DLC202607001有效（如适用） | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130001; 承运合同: CTC202607001(有效); 委托合同: DLC202607001(有效) | 核验状态为"通过"；无"合同核验"异常项；监管平台返回contractCheck=pass | 对应TP-C-016 | +| AH_REPORT_R2_017 | 平台端-监管上报-第二次上报 | 验证合同核验—承运合同不存在时核验异常 | P1 | 功能测试 | 1. 运单YB202607130034关联的承运合同编号INVALID_CTC999不存在于合同管理系统 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130034; 承运合同: INVALID_CTC999(不存在) | 核验状态变为"异常"；异常项标注"合同核验"；异常原因包含"承运合同不存在"提示；可发起申诉 | 对应TP-C-017 | +| AH_REPORT_R2_018 | 平台端-监管上报-第二次上报 | 验证合同核验—合同有效期不覆盖运单执行日期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130035执行日期为2026-07-10~2026-07-13，但关联的承运合同有效期至2026-06-30（已过期不覆盖运单执行日期） | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130035; 承运合同有效期: ~2026-06-30(不覆盖运单日期) | 核验状态变为"异常"；异常项标注"合同核验"；异常原因包含"合同已过期"或"合同有效期不覆盖运单执行日期"；可发起申诉 | 对应TP-C-017 | +| AH_REPORT_R2_019 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点≥2且≤2000且路线匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001车辆GPS轨迹包含500个有效轨迹点；2. 轨迹路线与装货地→卸货地路线基本一致；3. 轨迹时间与运单执行时间匹配 | 1. 触发第二次上报（携带500点轨迹数据）；2. 等待核验结果 | 运单号: YB202607130001; 轨迹点数: 500 | 核验状态为"通过"；无"车辆轨迹合规核验"异常项；监管平台返回trackCheck=pass | 对应TP-C-018 | +| AH_REPORT_R2_020 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点边界值2个点时核验通过 | P2 | 功能测试 | 1. 运单YB202607130036车辆GPS轨迹仅包含2个有效轨迹点（起终点，边界最小值） | 1. 触发第二次上报（携带2点轨迹数据）；2. 等待核验结果 | 运单号: YB202607130036; 轨迹点数: 2(边界最小值) | 核验状态为"通过"；无"车辆轨迹合规核验"异常项；边界值2个点被正确处理 | 对应TP-C-018 | +| AH_REPORT_R2_021 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点边界值2000个点时核验通过 | P2 | 功能测试 | 1. 运单YB202607130037车辆GPS轨迹包含恰好2000个有效轨迹点（边界最大值） | 1. 触发第二次上报（携带2000点轨迹数据）；2. 等待核验结果；3. 验证2000点数据完整传输 | 运单号: YB202607130037; 轨迹点数: 2000(边界最大值) | 核验状态为"通过"；2000个轨迹点全部成功上报，无截断；页面响应不卡顿 | 对应TP-C-018 | +| AH_REPORT_R2_022 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点<2个(仅1个点)时核验异常 | P1 | 功能测试 | 1. 运单YB202607130038车辆GPS轨迹仅包含1个有效轨迹点 | 1. 触发第二次上报（携带1点轨迹数据）；2. 等待核验结果 | 运单号: YB202607130038; 轨迹点数: 1(不足) | 核验状态变为"异常"；异常项标注"车辆轨迹合规核验"；异常原因包含"轨迹点数量不足（至少需要2个点）"；可进入"补传轨迹"流程 | 对应TP-C-019 | +| AH_REPORT_R2_023 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点=0(无轨迹数据)时核验异常 | P1 | 功能测试 | 1. 运单YB202607130039无GPS轨迹数据（轨迹点=0） | 1. 触发第二次上报（轨迹数据为空）；2. 等待核验结果 | 运单号: YB202607130039; 轨迹点数: 0 | 核验状态变为"异常"；异常项标注"车辆轨迹合规核验"；异常原因包含"轨迹数据缺失"；可进入"补传轨迹"流程 | 对应TP-C-019 | +| AH_REPORT_R2_024 | 平台端-监管上报-第二次上报 | 验证第二次上报依赖第一次上报完成—第一次上报失败时第二次上报被拒绝 | P0 | 功能测试 | 1. 运单YB202607130005第一次上报状态为"上传失败"；2. 财务对该运单完成打款操作 | 1. 打款完成回调触发第二次上报；2. 查看第二次上报接口返回；3. 查看第二次上报列表 | 运单号: YB202607130005(第一次上报失败) | 第二次上报接口返回错误，错误码标识"前置上报未完成"或"请先完成第一次上报"；第二次上报列表中无该运单记录或状态未更新；后端通过查询report_status表校验第一次上报完成状态；错误消息清晰可理解 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R2_025 | 平台端-监管上报-第二次上报 | 验证第二次上报幂等性—自动重试期间禁止手动触发 | P0 | 功能测试 | 1. 运单YB202607130001第二次上报正在自动重试中；2. 使用super_admin登录管理端 | 1. 进入第二次上报列表；2. 在自动重试进行中找到该运单；3. 尝试点击"手动上传"按钮或直接调用上报API | 运单号: YB202607130001(自动重试进行中) | 前端"手动上传"按钮不可见或被置灰（仅"上传失败"状态可见）；若通过API直接调用，返回"上报处理中"错误（分布式锁检测）；同一运单第二次上报仅产生1条有效记录；数据库unique约束（运单号+stage=2）防止重复插入 | [AI修正: 历史缺陷防御] - BUG-202607-02 | +| AH_REPORT_R2_026 | 平台端-监管上报-第二次上报 | 验证轨迹核验异常运单的补传轨迹功能—补传后重新核验通过 | P1 | 功能测试 | 1. 运单YB202607130038第二次上报轨迹核验异常（轨迹点仅1个）；2. 运营人员准备补充的GPS轨迹数据（200个点） | 1. 进入第二次上报列表，找到轨迹异常运单；2. 点击操作列"补传轨迹"按钮；3. 上传补充的200个轨迹点数据文件；4. 提交补传；5. 等待重新核验结果 | 运单号: YB202607130038; 原始轨迹点: 1; 补传轨迹点: 200 | 仅轨迹核验异常的运单显示"补传轨迹"按钮；补传提交后系统重新触发轨迹核验；核验通过后异常项"车辆轨迹合规核验"消除，核验状态变为"通过"；补传操作在上报日志中独立记录；补传的200个轨迹点数据覆盖原有的1个点数据 | 对应TP-C-022 | +| AH_REPORT_R2_027 | 平台端-监管上报-第二次上报 | 验证第二次上报失败后自动重试机制—最多3次、间隔递增、全部失败后告警 | P1 | 功能测试 | 1. 运单YB202607130060触发第二次上报；2. 模拟监管平台接口超时（不返回/30s超时） | 1. 触发第二次上报（超时失败）；2. 等待系统自动重试；3. 查看上报日志中每次重试的记录；4. 模拟连续3次重试均失败；5. 查看告警通知 | 运单号: YB202607130060; 重试间隔: 5s/15s/30s(参考值) | 上报失败后系统自动触发第1次重试（约5s后）；第1次失败→第2次重试（约15s后）；第2次失败→第3次重试（约30s后）；每次重试在上报日志中独立记录（共4条: 1次原始+3次重试）；3次全部失败后系统通过站内信或短信告警通知运营人员；上报状态变更为"上传失败"（红色标签），"手动上传"按钮可见可用；重试期间手动上传按钮不可用或置灰显示"上报处理中" | [AI修正: 历史缺陷防御] - BUG-202607-02；对应TP-C-023 | +| AH_REPORT_R2_028 | 平台端-监管上报-第二次上报 | 验证第二次上报详情弹窗资金流水10字段与车辆轨迹6字段分组完整展示 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001第二次上报已完成且含完整资金流水和车辆轨迹数据 | 1. 进入第二次上报列表；2. 点击运单YB202607130001的"详情"按钮；3. 查看"资金流水信息"分组的字段；4. 查看"车辆轨迹信息"分组的字段 | 运单号: YB202607130001; 资金流水: 含完整支付信息; 车辆轨迹: 含150个点位 | 资金流水信息分组完整展示10字段: 支付金额/支付方式/支付时间/付款方名称/收款方名称/收款人/收款账号/收款账号类型/流水号/支付状态；车辆轨迹信息分组完整展示6字段: 定位类型/定位时间/定位地点/经度/纬度/轨迹类型；轨迹列表支持分页浏览（150个点分页展示）；可选字段缺失时显示"-"或"无"而不展示空白；弹窗分组标签和顺序正确: 运单信息→托运方信息→收货方信息→资金流水信息→车辆轨迹信息→异常信息 | 对应TP-C-024；[AI修正: 覆盖缺口补充] | + +| AH_REPORT_R2_029 | 平台端-监管上报-第二次上报 | 验证里程申诉功能—提交里程申诉接口正常 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130058存在里程数据异常（如实际里程与上报里程偏差>20%） | 1. 进入第二次上报详情页；2. 点击"里程申诉"按钮；3. 填写申诉内容"GPS里程与实际里程偏差"、投诉编号"CMP202607130001"、申诉里程"350"；4. 提交 | 运单号: YB202607130058; 申诉里程: 350km; 投诉编号: CMP202607130001 | 里程申诉提交成功，接口POST /mileageAppeal/insert返回成功响应；申诉记录中新增里程申诉记录；申诉内容、投诉编号、申诉里程字段均正确保存；缺少必选参数时接口返回明确错误提示（如"运单号不能为空"）；里程申诉与异常项申诉独立管理互不干扰 | 对应TP-C-025；[技术方案] API新增接口 | +| AH_REPORT_R2_030 | 平台端-监管上报-第二次上报 | 验证委托合同核验(100)—合同有效且覆盖运单日期时核验通过 | P1 | 功能测试 | 1. 运单YB202607130059委托合同编号DLC202607001有效且存在于合同管理系统；2. 委托合同有效期2026-01-01~2026-12-31覆盖运单执行日期2026-07-10~2026-07-13；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项 | 运单号: YB202607130059; 委托合同: DLC202607001(有效) | 核验状态为"通过"；无"委托合同核验"（代码100）异常项；abnormalDetails中不存在id=100的记录 | 对应TP-C-026；[技术方案] API文档§4.1 | +| AH_REPORT_R2_031 | 平台端-监管上报-第二次上报 | 验证委托合同核验(100)—合同不存在或过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130060委托合同编号INVALID_DLC999不存在于合同管理系统；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果返回；3. 查看异常项详情 | 运单号: YB202607130060; 委托合同: INVALID_DLC999(不存在) | 核验状态变为"异常"；异常项标注"委托合同核验"（代码100）；异常原因包含"委托合同不存在"或"委托合同已过期"；可发起申诉 | 对应TP-C-027；[技术方案] API文档§4.1 | +| AH_REPORT_R2_032 | 平台端-监管上报-第二次上报 | 验证承运合同核验(120)—合同有效且覆盖运单日期时核验通过 | P1 | 功能测试 | 1. 运单YB202607130061承运合同编号CTC202607001有效且存在于合同管理系统；2. 承运合同有效期2026-01-01~2026-12-31覆盖运单执行日期；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130061; 承运合同: CTC202607001(有效) | 核验状态为"通过"；无"承运合同核验"（代码120）异常项；abnormalDetails中不存在id=120的记录 | 对应TP-C-028；[技术方案] API文档§4.1 | +| AH_REPORT_R2_033 | 平台端-监管上报-第二次上报 | 验证承运合同核验(120)—合同不存在或过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130062承运合同编号INVALID_CTC888不存在于合同管理系统；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130062; 承运合同: INVALID_CTC888(不存在) | 核验状态变为"异常"；异常项标注"承运合同核验"（代码120）；异常原因包含"承运合同不存在"或"承运合同已过期"；可发起申诉 | 对应TP-C-029；[技术方案] API文档§4.1 | +| AH_REPORT_R2_034 | 平台端-监管上报-第二次上报 | 验证实时定位核验(130)—运单执行期间有完整实时定位数据时核验通过 | P1 | 功能测试 | 1. 运单YB202607130063在运输期间（2026-07-10 08:00~2026-07-13 18:00）有持续完整的GPS实时定位数据；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130063; 定位时间范围: 完整覆盖运输期间 | 核验状态为"通过"；无"实时定位核验"（代码130）异常项 | 对应TP-C-030；[技术方案] API文档§4.1 | +| AH_REPORT_R2_035 | 平台端-监管上报-第二次上报 | 验证实时定位核验(130)—运输期间定位数据长时间中断时核验异常 | P1 | 功能测试 | 1. 运单YB202607130064运输期间（2026-07-10~2026-07-13）GPS定位数据在2026-07-11~2026-07-12期间中断超过24小时；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130064; 定位中断: 2026-07-11~2026-07-12(约24小时) | 核验状态变为"异常"；异常项标注"实时定位核验"（代码130）；异常原因包含"实时定位数据长时间中断"；可发起申诉或补充定位数据 | 对应TP-C-031；[技术方案] API文档§4.1 | +| AH_REPORT_R2_036 | 平台端-监管上报-第二次上报 | 验证运单时间逻辑核验(140)—各时间节点逻辑合理时核验通过 | P1 | 功能测试 | 1. 运单YB202607130065时间节点合理：建单2026-07-09→接单2026-07-10 08:00→起运2026-07-10 10:00→送达2026-07-13 16:00；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130065; 时间序列: 建单→接单→起运→送达(合理) | 核验状态为"通过"；无"运单时间逻辑核验"（代码140）异常项 | 对应TP-C-032；[技术方案] API文档§4.1 | +| AH_REPORT_R2_037 | 平台端-监管上报-第二次上报 | 验证运单时间逻辑核验(140)—送达时间早于起运时间时核验异常 | P1 | 功能测试 | 1. 运单YB202607130066时间节点矛盾：起运2026-07-13 10:00→送达2026-07-12 16:00（送达早于起运）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130066; 时间倒置: 送达(07-12)早于起运(07-13) | 核验状态变为"异常"；异常项标注"运单时间逻辑核验"（代码140）；异常原因包含"送达时间早于起运时间"；可发起申诉 | 对应TP-C-033；[技术方案] API文档§4.1 | +| AH_REPORT_R2_038 | 平台端-监管上报-第二次上报 | 验证道路运输证核验(160)—有效期和证号均有效时核验通过 | P1 | 功能测试 | 1. 运单YB202607130067车辆道路运输证号RTC202501001有效，有效期2025-03-01~2027-03-01（当前日期2026-07-13在有效期内）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130067; 道路运输证号: RTC202501001(有效) | 核验状态为"通过"；无"道路运输证核验"（代码160）异常项 | 对应TP-C-034；[技术方案] API文档§4.1 | +| AH_REPORT_R2_039 | 平台端-监管上报-第二次上报 | 验证道路运输证核验(160)—证号在运政系统查询不存在时核验异常 | P1 | 功能测试 | 1. 运单YB202607130068车辆道路运输证号INVALID_RTC999在运政系统中查询不存在；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130068; 道路运输证号: INVALID_RTC999(不存在) | 核验状态变为"异常"；异常项标注"道路运输证核验"（代码160）；异常原因包含"道路运输证不存在"；可发起申诉 | 对应TP-C-035；[技术方案] API文档§4.1 | +| AH_REPORT_R2_040 | 平台端-监管上报-第二次上报 | 验证驾驶证核验(170)—驾驶证有效且准驾车型匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130069司机驾驶证号DL202501001有效，有效期2024-01-01~2030-01-01，准驾车型B2（与重型货车匹配）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130069; 驾驶证号: DL202501001(有效); 准驾车型: B2(匹配) | 核验状态为"通过"；无"驾驶证核验"（代码170）异常项 | 对应TP-C-036；[技术方案] API文档§4.1 | +| AH_REPORT_R2_041 | 平台端-监管上报-第二次上报 | 验证驾驶证核验(170)—驾驶证已过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130070司机驾驶证有效期至2025-12-31（当前日期2026-07-13已过期）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130070; 驾驶证有效期至: 2025-12-31(已过期) | 核验状态变为"异常"；异常项标注"驾驶证核验"（代码170）；异常原因包含"驾驶证已过期"；可发起申诉 | 对应TP-C-037；[技术方案] API文档§4.1 | +| AH_REPORT_R2_042 | 平台端-监管上报-第二次上报 | 验证车辆重复核验(190)—车辆无时间重叠运单时核验通过 | P1 | 功能测试 | 1. 运单YB202607130071车辆云A12345在运单执行时段2026-07-10~2026-07-13内无其他运单；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130071; 车辆: 云A12345(无时间重叠) | 核验状态为"通过"；无"车辆重复核验"（代码190）异常项 | 对应TP-C-038；[技术方案] API文档§4.1 | +| AH_REPORT_R2_043 | 平台端-监管上报-第二次上报 | 验证车辆重复核验(190)—同一车辆同时用于两个时间重叠运单时核验异常 | P1 | 功能测试 | 1. 车辆云A12345同时出现在运单YB202607130072（执行时段2026-07-10~2026-07-13）和运单YB202607130073（执行时段2026-07-11~2026-07-14）中，时间重叠2天；2. 第一次上报已完成 | 1. 分别触发两个运单的第二次上报；2. 查看核验结果 | 运单A: YB202607130072(07-10~07-13); 运单B: YB202607130073(07-11~07-14); 重叠: 07-11~07-13 | 至少一个运单核验状态变为"异常"；异常项标注"车辆重复核验"（代码190）；异常原因包含"车辆在运单执行期间存在时间重叠"；可发起申诉 | 对应TP-C-039；[技术方案] API文档§4.1 | +| AH_REPORT_R2_044 | 平台端-监管上报-第二次上报 | 验证司机重复核验(200)—司机无时间重叠运单时核验通过 | P1 | 功能测试 | 1. 运单YB202607130074司机张三(身份证510101199001011234)在运单执行时段2026-07-10~2026-07-13内无其他运单；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130074; 司机: 张三(无时间重叠) | 核验状态为"通过"；无"司机重复核验"（代码200）异常项 | 对应TP-C-040；[技术方案] API文档§4.1 | +| AH_REPORT_R2_045 | 平台端-监管上报-第二次上报 | 验证司机重复核验(200)—同一司机同时执行两个时间重叠运单时核验异常 | P1 | 功能测试 | 1. 司机张三同时被分配给运单YB202607130075（执行时段2026-07-10~2026-07-13）和运单YB202607130076（执行时段2026-07-12~2026-07-15），时间重叠2天；2. 第一次上报已完成 | 1. 分别触发两个运单的第二次上报；2. 查看核验结果 | 运单A: YB202607130075(07-10~07-13); 运单B: YB202607130076(07-12~07-15); 司机: 张三(重叠) | 至少一个运单核验状态变为"异常"；异常项标注"司机重复核验"（代码200）；异常原因包含"司机在运单执行期间存在时间重叠"；可发起申诉 | 对应TP-C-041；[技术方案] API文档§4.1 | +| AH_REPORT_R2_046 | 平台端-监管上报-第二次上报 | 验证运费收款核验(220)—收款人与司机一致且金额匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130077收款人张三与司机张三一致（身份证号510101199001011234匹配）；2. 收款金额¥10,000.00与运单运费一致；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130077; 收款人: 张三(与司机一致); 收款金额: ¥10,000.00 | 核验状态为"通过"；无"运费收款核验"（代码220）异常项 | 对应TP-C-042；[技术方案] API文档§4.1 | +| AH_REPORT_R2_047 | 平台端-监管上报-第二次上报 | 验证运费收款核验(220)—收款人与司机身份证号不一致时核验异常 | P1 | 功能测试 | 1. 运单YB202607130078司机为张三(身份证510101199001011234)，但收款人为李四(身份证510101199002022345)，两者不一致；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130078; 司机: 张三; 收款人: 李四(不一致) | 核验状态变为"异常"；异常项标注"运费收款核验"（代码220）；异常原因包含"收款人与司机信息不一致"；可发起申诉 | 对应TP-C-043；[技术方案] API文档§4.1 | +| AH_REPORT_R2_048 | 平台端-监管上报-第二次上报 | 验证公司统一收款核验(230)—收款公司信息与托运方一致时核验通过 | P1 | 功能测试 | 1. 运单YB202607130079收款公司为"安徽XX物流有限公司"(统一社会信用代码9134XXXXXXXXXXXXXX)，与托运方信息完全一致；2. 收款账户已在系统中备案；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130079; 收款公司: 安徽XX物流有限公司(与托运方一致) | 核验状态为"通过"；无"公司统一收款核验"（代码230）异常项 | 对应TP-C-044；[技术方案] API文档§4.1 | +| AH_REPORT_R2_049 | 平台端-监管上报-第二次上报 | 验证公司统一收款核验(230)—收款公司统一社会信用代码与托运方不一致时核验异常 | P1 | 功能测试 | 1. 运单YB202607130080托运方为"安徽XX物流有限公司"，但收款公司为"安徽YY运输有限公司"，统一社会信用代码不一致；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130080; 托运方: 安徽XX物流; 收款公司: 安徽YY运输(不一致) | 核验状态变为"异常"；异常项标注"公司统一收款核验"（代码230）；异常原因包含"收款公司信息与托运方不一致"；可发起申诉 | 对应TP-C-045；[技术方案] API文档§4.1 | +| AH_REPORT_R2_050 | 平台端-监管上报-第二次上报 | 验证发票信息核验(260)—发票号码/代码有效且信息完整时核验通过 | P1 | 功能测试 | 1. 运单YB202607130081关联的发票FP202607130081在税务系统中可查询且状态正常；2. 发票销售方和受票方信息完整；3. 第一次/第二次上报已完成 | 1. 触发第三次上报后等待发票核验；2. 或通过API直接查询核验结果 | 运单号: YB202607130081; 发票号: FP202607130081(有效) | 核验状态为"通过"；无"发票信息核验"（代码260）异常项 | 对应TP-C-046；[技术方案] API文档§4.1 | +| AH_REPORT_R2_051 | 平台端-监管上报-第二次上报 | 验证发票信息核验(260)—发票已作废时核验异常 | P1 | 功能测试 | 1. 运单YB202607130082关联的发票FP202607130082在税务系统中状态为"已作废/红冲"；2. 第一次/第二次上报已完成 | 1. 触发第三次上报后等待发票核验；2. 查看核验结果 | 运单号: YB202607130082; 发票号: FP202607130082(已作废) | 核验状态变为"异常"；异常项标注"发票信息核验"（代码260）；异常原因包含"发票已作废"或"发票状态异常"；可发起申诉 | 对应TP-C-047；[技术方案] API文档§4.1 | +| AH_REPORT_R2_052 | 平台端-监管上报-第二次上报 | 验证非通行车辆可开票核验(270)—车辆运营证照齐全且合规时核验通过 | P1 | 功能测试 | 1. 运单YB202607130083车辆运营证照齐全(道路运输证/行驶证均在有效期内)且未被标记为黑名单；2. 第一次/第二次上报已完成 | 1. 触发上报后等待核验；2. 查看核验结果 | 运单号: YB202607130083; 车辆证照: 齐全有效 | 核验状态为"通过"；无"非通行车辆可开票核验"（代码270）异常项 | 对应TP-C-048；[技术方案] API文档§4.1 | +| AH_REPORT_R2_053 | 平台端-监管上报-第二次上报 | 验证非通行车辆可开票核验(270)—车辆被标记为黑名单时核验异常 | P1 | 功能测试 | 1. 运单YB202607130084车辆已被监管平台标记为运营异常/黑名单；2. 第一次/第二次上报已完成 | 1. 触发上报后等待核验；2. 查看核验结果 | 运单号: YB202607130084; 车辆状态: 黑名单 | 核验状态变为"异常"；异常项标注"非通行车辆可开票核验"（代码270）；异常原因包含"车辆不合规"或"车辆不在可开票范围"；可发起申诉 | 对应TP-C-049；[技术方案] API文档§4.1 | +| AH_REPORT_R2_054 | 平台端-监管上报-第二次上报 | 验证第二次上报核验详情中每个异常项有独立申诉入口 | P2 | 功能测试 | 1. 运单YB202607130091第二次上报存在两个核验异常项：车辆轨迹(210)和资金流水(250)；2. 使用super_admin登录管理端 | 1. 进入第二次上报列表，点击该运单的"详情"按钮；2. 查看核验详情弹窗中的异常项列表；3. 验证每个异常项旁是否有独立的"申诉"操作按钮 | 运单号: YB202607130091; 异常项: 车辆轨迹(210), 资金流水(250) | 核验详情弹窗中每个异常项均有独立的"申诉"按钮或操作入口；点击异常项210的"申诉"按钮后跳转至申诉页面，且verificationAbnormalItems预填充为"210"；点击异常项250的"申诉"按钮后预填充"250"；两个申诉入口独立触发，互不影响 | 对应TP-C-024；[AI修正: 申诉单值约束意识] | + +--- + +## 模块D: 第三次上报-开票完成 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_R3_001 | 平台端-监管上报-第三次上报 | 验证发票开具完成后自动触发第三次上报且包含发票信息17字段 | P0 | 功能测试 | 1. 运单YB202607130001已完成第二次上报且状态为"已上传"；2. 该运单发票FP202607130001已开具完成 | 1. 系统收到发票开具完成事件；2. 进入管理端"监管上报-第三次上报"列表查看 | 运单号: YB202607130001; 发票号: FP202607130001; 发票金额(价税合计): ¥10,300.00 | 第三次上报列表中新增该运单记录，上报状态从"上传中"变为"已上传"（绿色标签）；上报请求包含运单信息+发票信息17字段+托运单号数组；若运单无关联油气发票则油气发票信息字段为空；数据库report_record表新增stage=3的记录 | 对应TP-D-001 | +| AH_REPORT_R3_002 | 平台端-监管上报-第三次上报 | 验证第三次上报列表展示13个字段完整且数据正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 第三次上报列表中有至少1条已完成的记录 | 1. 进入"监管上报-第三次上报"列表；2. 查看列表表头和第一条数据的所有列内容 | 运单号: YB202607130001; 发票号: FP202607130001 | 列表展示13个字段: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/发票号码/发票金额/开票日期/核验状态/异常原因/上报状态/操作；发票金额保留2位小数；开票日期格式为YYYY-MM-DD；核验状态标签颜色符合规范 | 对应TP-D-002；⚠️ 待确认: 原型列表比需求多4个字段（税率/销售方名称/受票方名称/油气票张数），共15列 | +| AH_REPORT_R3_003 | 平台端-监管上报-第三次上报 | 验证第三次上报详情弹窗发票信息19字段完整展示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001第三次上报已完成 | 1. 进入第三次上报列表；2. 点击运单YB202607130001的"详情"按钮；3. 查看"发票信息"分组的所有字段 | 运单号: YB202607130001; 发票号: FP202607130001; 发票代码: 1234567890; 价税合计: ¥10,300.00 | 发票信息分组展示19字段: 托运单号数组（支持多个托运单号）、发票号码、发票代码号、发票金额(价税合计)、开票日期（必选字段完整）；销售方8字段（名称/纳税人识别号/地址/电话/开户行/银行账户/账号/联系人）完整；受票方6字段（名称/纳税人识别号/地址/电话/开户行/银行卡号）完整；注：第三次上报无税率字段 | 对应TP-D-003 | +| AH_REPORT_R3_004 | 平台端-监管上报-第三次上报 | 验证运单关联油气发票时第三次上报包含油气发票信息 | P2 | 功能测试 | 1. 运单YB202607130040关联油气发票YQFP202607001；2. 该运单发票开具完成 | 1. 触发第三次上报；2. 查看上报请求JSON中油气发票信息字段；3. 查看详情弹窗 | 运单号: YB202607130040; 油气发票: YQFP202607001 | 上报请求JSON包含油气发票信息（油气托运单号、油气发票文件）；详情弹窗中油气发票信息正确展示；油气发票文件支持查看和下载 | 对应TP-D-004 | +| AH_REPORT_R3_005 | 平台端-监管上报-第三次上报 | 验证无油气发票时第三次上报正常完成（可选字段为空） | P2 | 功能测试 | 1. 运单YB202607130001无关联油气发票；2. 该运单发票开具完成 | 1. 触发第三次上报；2. 查看上报请求JSON中油气发票相关字段 | 运单号: YB202607130001; 油气发票: 无 | 上报请求JSON中油气发票字段为null或不传；上报成功，不报错；详情弹窗中油气发票区域显示"-"或"无" | 对应TP-D-004 | +| AH_REPORT_R3_006 | 平台端-监管上报-第三次上报 | 验证第三次上报依赖第二次上报完成—第二次上报失败时第三次上报被拒绝 | P0 | 功能测试 | 1. 运单YB202607130041第二次上报状态为"上传失败"；2. 该运单发票已开具完成 | 1. 发票开具完成事件触发第三次上报；2. 查看第三次上报接口返回 | 运单号: YB202607130041(第二次上报失败) | 接口返回错误，错误码明确标识"前置上报（第二次）未完成"；后端通过查询report_status表校验第二阶段的完成状态；第三次上报列表无该运单记录 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R3_007 | 平台端-监管上报-第三次上报 | 验证第三次上报完整依赖链校验—第1失败→第2无法完成→第3被拒绝 | P0 | 功能测试 | 1. 运单YB202607130042第一次上报状态为"上传失败" | 1. 通过API依次尝试调用第二次上报接口和第三次上报接口；2. 查看每个接口的返回 | 运单号: YB202607130042 | 第一次上报失败→第二次上报接口返回"前置上报未完成"；第二次上报无法完成→第三次上报接口同样返回"前置上报未完成"（含第二次）；三阶段依赖链校验在后端完整实现，不可跳级 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R3_008 | 平台端-监管上报-第三次上报 | 验证增值税发票号码格式无效时第三次上报失败并明确提示 | P1 | 功能测试 | 1. 运单YB202607130043发票号码格式无效（如"ABC"非标准格式）；2. 第二次上报已完成 | 1. 触发第三次上报；2. 查看上报接口返回的错误信息 | 运单号: YB202607130043; 发票号码: ABC(无效格式) | 接口返回校验错误，提示"发票号码格式无效"或类似消息；上报状态标记为"上传失败"（红色标签）；错误信息明确指出具体错误字段为发票号码；数据库无该运单第三次上报的成功记录 | 对应TP-D-006 | +| AH_REPORT_R3_009 | 平台端-监管上报-第三次上报 | 验证发票代码与发票号码不匹配时第三次上报失败 | P1 | 功能测试 | 1. 运单YB202607130044发票代码1234567890与发票号码FP202607130001不匹配 | 1. 触发第三次上报；2. 查看接口返回 | 运单号: YB202607130044; 不匹配的发票代码/号码 | 接口返回校验错误，提示"发票代码与发票号码不匹配"；上报状态标记为"上传失败"；错误信息指明具体错误字段 | 对应TP-D-006 | +| AH_REPORT_R3_010 | 平台端-监管上报-第三次上报 | 验证第三次上报失败后自动重试最多3次全部失败后告警 | P1 | 功能测试 | 1. 运单YB202607130045第三次上报时模拟监管平台持续返回失败 | 1. 触发第三次上报；2. 监控上报日志中的重试记录；3. 等待3次重试全部完成后查看告警通知 | 运单号: YB202607130045; 发票号: FP202607130045 | 自动重试3次（总共4次尝试）；重试间隔递增；3次重试全部失败后上报状态标记为"上传失败"（红色）并停止重试；super_admin收到告警通知，内容包含运单号YB202607130045、发票号FP202607130045、失败原因 | 对应TP-D-007 | +| AH_REPORT_R3_011 | 平台端-监管上报-第三次上报 | 验证第三次上报幂等性—同一运单同一发票信息不能重复上报 | P1 | 功能测试 | 1. 运单YB202607130001第三次上报已成功（发票FP202607130001）；2. 尝试再次触发第三次上报 | 1. 通过API再次调用第三次上报接口（同一运单+同一发票）；2. 查看接口返回 | 运单号: YB202607130001; 发票号: FP202607130001(已上报) | 接口返回"上报已存在"或"该发票已上报"提示；数据库report_record表不会新增重复记录（唯一约束：运单号+stage=3+发票号）；分布式锁或幂等键控制并发 | 对应TP-D-009 | +| AH_REPORT_R3_012 | 平台端-监管上报-第三次上报 | 验证第三次上报发票金额精度—价税合计保留2位小数无浮点数精度问题 | P1 | 功能测试 | 1. 准备发票金额为¥0.01、¥9,999.99、¥999,999.99的三张发票 | 1. 分别对三张发票触发第三次上报；2. 查看上报请求JSON中的金额字段；3. 对比数据库发票表和上报记录中的金额 | 金额1: ¥0.01; 金额2: ¥9,999.99; 金额3: ¥999,999.99 | 三个金额均保留2位小数并精确传输（如0.01不为0.009999...）；大金额¥999,999.99不出现溢出或截断；数据库金额字段使用DECIMAL类型非FLOAT；上报数据与开票系统数据完全一致 | 对应TP-D-010 | +| AH_REPORT_R3_013 | 平台端-监管上报-第三次上报 | 验证第三次上报运单信息数据来源—价格和货物信息来源于运单表实时数据 | P2 | 功能测试 | 1. 运单YB202607130046装货完成时货物信息含"钢材10吨"；2. 在第三次上报前修改运单表货物信息为"钢材12吨" | 1. 修改运单表的货物信息；2. 触发第三次上报；3. 查看上报请求中的货物信息数据 | 运单号: YB202607130046; 原货物量: 10吨; 修改后: 12吨 | 上报请求中的货物信息为"钢材12吨"（最新值），非"钢材10吨"（装货时快照）；数据来源为运单表实时查询；不依赖装货完成时的数据缓存 | 对应TP-D-011 | +| AH_REPORT_R3_014 | 平台端-监管上报-第三次上报 | 验证第三次上报详情弹窗异常信息分组与申诉模块数据联动 | P2 | 功能测试 | 1. 运单YB202607130046第三次上报核验异常；2. 已对该运单发起申诉且申诉状态为"申诉中" | 1. 进入第三次上报列表；2. 点击运单YB202607130046的"详情"按钮；3. 查看"异常信息"分组 | 运单号: YB202607130046; 申诉状态: 申诉中 | 异常信息分组包含核验状态（异常）、异常原因（具体异常项）、异常时间（核验时间）、处理状态（申诉中）；处理状态与申诉模块数据一致（联动）；申诉状态变更后详情弹窗中处理状态同步更新 | 对应TP-D-008 | +| AH_REPORT_R3_015 | 平台端-监管上报-第三次上报 | 验证发票合规查询接口—查询托运人发票是否通过系统核验合规 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 托运人"安徽XX物流有限公司"存在已核验合规的发票记录 | 1. 调用POST /verificationSummary/cargoOwnerInvoiceInfo接口；2. 传入托运人识别信息（统一社会信用代码/名称）；3. 查看返回的发票合规状态 | 托运人: 安徽XX物流有限公司; 统一社会信用代码: 9134XXXXXXXXXXXXXX | 接口返回发票合规状态为"合规/通过"；若发票不合规则返回异常原因和具体不合规项；接口支持批量查询多个托运人发票合规状态；响应时间<3s；传入无效托运人信息时返回明确错误提示 | 对应TP-D-012；[技术方案] API新增接口 | + +--- + +## 模块E: ETC发票上传 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_ETC_001 | 平台端-监管上报-ETC上传 | 验证税务抵扣完成后ETC发票上传成功且列表数据正确 | P0 | 功能测试 | 1. 运单YB202607130001的ETC发票ETC202607130001税务抵扣已完成；2. ETC发票信息18字段完整 | 1. 触发ETC发票上传（自动或手动）；2. 进入管理端"监管上报-ETC上传"列表查看；3. 查看上传请求JSON内容 | 运单号: YB202607130001; ETC发票号: ETC202607130001; 发票金额: ¥100.00; 税率: 3% | ETC上传列表中出现该记录，上传状态为"已上传"（绿色标签）；上报请求JSON包含运单信息7字段+ETC发票信息18字段；数据库etc_report_record表新增记录，status=1 | 对应TP-E-001 | +| AH_REPORT_ETC_002 | 平台端-监管上报-ETC上传 | 验证ETC上传列表展示11个字段完整且数据正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. ETC上传列表中有至少1条记录 | 1. 进入"监管上报-ETC上传"列表；2. 查看列表表头和第一条数据的所有列 | 运单号: YB202607130001; ETC发票号: ETC202607130001 | 列表展示: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/ETC发票号码/发票金额/税率/上传状态/操作；发票金额正确展示，税率显示3%；上传状态标签颜色符合规范 | 对应TP-E-002 | +| AH_REPORT_ETC_003 | 平台端-监管上报-ETC上传 | 验证ETC发票详情弹窗3个分组字段完整（运单信息/ETC发票信息18字段/异常信息） | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. ETC上传列表中有已完成上传的记录 | 1. 进入ETC上传列表；2. 点击运单YB202607130001操作列的"详情"按钮；3. 依次查看各分组字段 | 运单号: YB202607130001; ETC发票号: ETC202607130001 | 运单信息分组7字段完整；ETC发票信息分组18字段完整展示: ETC发票号码、ETC发票代码、开票时间、发票金额、税率(3%)、税额、价税合计、销售方名称、销售方税号、受票方名称、受票方税号、入口收费站、出口收费站、交易时间、交易金额、交易匹配时间、交易流水号、ETC发票文件；异常信息分组4字段（核验状态/异常原因/异常时间/处理状态） | 对应TP-E-003 | +| AH_REPORT_ETC_004 | 平台端-监管上报-ETC上传 | 验证税务抵扣未完成时ETC上传被拒绝并提示"请先完成税务抵扣" | P0 | 功能测试 | 1. 运单YB202607130047的ETC发票税务抵扣状态为"未完成" | 1. 尝试触发ETC发票上传（调用API或页面操作）；2. 查看接口返回 | 运单号: YB202607130047; 税务抵扣: 未完成 | 上传接口返回错误，提示"请先完成税务抵扣"；后端校验税务抵扣状态为已完成才允许上传；ETC上传列表中不会出现该运单记录 | 对应TP-E-004 | +| AH_REPORT_ETC_005 | 平台端-监管上报-ETC上传 | 验证ETC发票号码格式无效时上传失败并明确提示 | P1 | 功能测试 | 1. 运单YB202607130048关联的ETC发票号码格式无效（如"ETC-ABC"不符合规定格式） | 1. 税务抵扣完成后触发上传；2. 查看接口返回 | 运单号: YB202607130048; ETC发票号码: ETC-ABC(无效) | 上传接口返回校验错误，提示"ETC发票号码格式无效"；上传状态标记为"上传失败"；错误提示指明具体错误字段 | 对应TP-E-005 | +| AH_REPORT_ETC_006 | 平台端-监管上报-ETC上传 | 验证ETC发票税率非3%时上传失败并提示税率异常 | P1 | 功能测试 | 1. 运单YB202607130049关联的ETC发票税率字段为5%（非标准3%） | 1. 触发上传；2. 查看接口返回 | 运单号: YB202607130049; ETC发票税率: 5%(非标准) | 上传接口返回校验错误，提示"税率异常（应为3%）"；上传状态标记为"上传失败"；不会将错误税率数据上报至监管平台 | 对应TP-E-005 | +| AH_REPORT_ETC_007 | 平台端-监管上报-ETC上传 | 验证ETC上传失败后自动重试最多3次全部失败后告警 | P1 | 功能测试 | 1. 运单YB202607130050 ETC上传时模拟监管平台持续返回失败 | 1. 触发ETC上传；2. 监控上报日志中的重试记录；3. 等待3次重试全部完成后查看告警 | 运单号: YB202607130050; ETC发票号: ETC202607130050 | 自动重试3次（总共4次尝试）；重试间隔递增；3次重试全部失败后标记"上传失败"（红色标签）并停止重试；super_admin收到告警通知；每次重试均记录到上报日志 | 对应TP-E-006 | +| AH_REPORT_ETC_008 | 平台端-监管上报-ETC上传 | 验证ETC税额计算公式—税额=发票金额×3%结果保留2位小数 | P1 | 功能测试 | 1. 准备3张ETC发票：金额¥100.00、¥0.01、¥1,000,000.00 | 1. 分别对三张发票触发上传；2. 查看上报请求JSON中的税额和价税合计字段；3. 验证计算逻辑 | 发票1: ¥100.00→税额¥3.00; 发票2: ¥0.01→税额¥0.00; 发票3: ¥1,000,000.00→税额¥30,000.00 | 发票1: 税额=3.00, 价税合计=103.00, 计算正确；发票2: 税额按四舍五入规则处理（0.01×3%=0.0003→0.00）；发票3: 税额=30000.00, 大金额计算不溢出；所有税额保留2位小数 | 对应TP-E-007 | +| AH_REPORT_ETC_009 | 平台端-监管上报-ETC上传 | 验证同一ETC发票号重复上传时被拒绝且提示"该ETC发票已上传" | P1 | 功能测试 | 1. ETC发票ETC202607130001已成功上传 | 1. 再次触发同一ETC发票的上传；2. 查看接口返回 | ETC发票号: ETC202607130001(已上传) | 接口返回"该ETC发票已上传"提示；数据库etc_report_record表不会产生重复记录（唯一约束：ETC发票号）；分布式锁/幂等键控制并发 | 对应TP-E-008 | +| AH_REPORT_ETC_010 | 平台端-监管上报-ETC上传 | 验证同一运单关联多张ETC发票时各自独立上传且税额分别计算 | P2 | 功能测试 | 1. 运单YB202607130001关联3张ETC发票：ETC202607130001(¥100.00)、ETC202607130002(¥200.00)、ETC202607130003(¥150.00) | 1. 分别触发3张ETC发票的上传；2. 查看ETC上传列表；3. 验证每张发票的税额计算 | ETC1: ¥100.00→税¥3.00; ETC2: ¥200.00→税¥6.00; ETC3: ¥150.00→税¥4.50 | 列表中同一运单展示3条ETC上传记录；每张发票的税额独立计算正确；多张发票上传互不干扰；合计税额=¥13.50正确汇总 | 对应TP-E-009 | +| AH_REPORT_ETC_011 | 平台端-监管上报-ETC上传 | 验证ETC发票代码与号码不匹配时上传失败 | P1 | 功能测试 | 1. 运单YB202607130051的ETC发票代码与号码不匹配（代码对应其他发票） | 1. 触发上传；2. 查看接口返回 | 运单号: YB202607130051; 不匹配的ETC发票代码/号码 | 上传接口返回校验错误，提示"ETC发票代码与号码不匹配"；上传状态标记为"上传失败"；错误信息指明具体错误字段 | 对应TP-E-005 | +| AH_REPORT_ETC_012 | 平台端-监管上报-ETC上传 | 验证交易金额与实际通行费不匹配时ETC上传验证失败 | P1 | 功能测试 | 1. 运单YB202607130052的ETC发票中交易金额¥50.00与实际通行费¥80.00不匹配 | 1. 触发上传；2. 查看接口返回 | 运单号: YB202607130052; 交易金额: ¥50.00; 实际通行费: ¥80.00(不匹配) | 上传接口返回校验错误，提示"交易金额与实际通行费不匹配"；上传状态标记为"上传失败" | 对应TP-E-005 | + +--- + +## 模块F: 异常申诉功能 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_APL_001 | 平台端-监管上报-异常申诉 | 验证申诉完整闭环—从发起申诉到申诉通过的端到端流程 | P0 | 功能测试 | 1. 运单YB202607130002第二次上报"车辆资质核验"异常；2. 使用super_admin登录管理端；3. 准备申诉附件材料（车辆道路运输证更新后的PDF） | 1. 从看板或第二次上报列表找到异常运单YB202607130002；2. 点击"申诉"按钮进入申诉页面；3. 填写申诉原因"道路运输证已续期，附新证"；4. 上传申诉附件；5. 点击"提交申诉"；6. 模拟省平台复核通过并返回反馈；7. 查看申诉状态变化 | 运单号: YB202607130002; 异常项: 车辆资质核验; 申诉原因: 道路运输证已续期; 附件: 新道路运输证.pdf | 提交申诉后申诉状态变为"未申诉(100)·申诉中"（abnormalDetails[].state=110，省平台尚未审核）；省平台复核通过后状态变为"审核通过(110)"（绿色标签，终态）；申诉记录页面中该申诉记录状态为"审核通过(110)"；处理记录时间线中每条操作均有记录；原异常运单核验状态可能根据省平台反馈更新 | 对应TP-F-001；[API权威] 申诉状态以API §4.4为准: 未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130)；UI层的"申诉中"对应API异常项子状态state=110，非独立申诉状态 | +| AH_REPORT_APL_002 | 平台端-监管上报-异常申诉 | 验证申诉审核不通过(120)后运营人员重新申诉补充材料再发起 | P1 | 功能测试 | 1. 运单YB202607130002申诉状态为"审核不通过(120)"；2. 省平台反馈意见"证明材料不充分" | 1. 进入申诉记录页面，找到审核不通过的申诉记录；2. 点击"重新申诉"按钮；3. 补充新的附件材料（补充证明.pdf）；4. 修改申诉原因；5. 提交 | 运单号: YB202607130002; 原申诉被审核不通过; 新附件: 补充证明.pdf | "重新申诉"按钮可见可用；重新申诉后生成新的申诉单号（不同于原申诉单号）；原有申诉记录保留不丢失（状态保持审核不通过120）；新申诉有独立的处理记录时间线；申诉状态变为"未申诉(100)·申诉中"（abnormalDetails[].state=110），重新进入复核流程 | 对应TP-F-006 | +| AH_REPORT_APL_003 | 平台端-监管上报-异常申诉 | 验证申诉记录列表14个字段完整展示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 申诉记录列表中有至少1条申诉记录 | 1. 进入"监管上报-异常申诉"申诉记录页面；2. 查看列表表头和第一条数据的各列 | 申诉单含完整字段 | 列表展示14个字段: 运单号/托运单号/车牌号/司机姓名/托运方名称/上报阶段/核验状态/异常项/申诉状态/申诉时间/申诉人/省平台反馈结果/监管平台反馈时间/操作；申诉时间为实际提交时间；省平台反馈结果与实际反馈内容一致 | 对应TP-F-002 | +| AH_REPORT_APL_004 | 平台端-监管上报-异常申诉 | 验证申诉状态流转—未申诉(100)→未申诉·申诉中→审核通过(110)(终态不可变更) | P0 | 功能测试 | 1. 运单YB202607130053核验异常且申诉状态为"未申诉(100)" | 1. 发起申诉，验证异常项子状态变为"申诉中"(abnormalDetails[].state=110)；2. 模拟省平台复核通过；3. 验证申诉状态变为"审核通过(110)"；4. 尝试再次对该申诉记录操作（如重新申诉） | 运单号: YB202607130053 | 未申诉(100)→提交申诉后异常项子状态变为申诉中(state=110)，申诉状态仍为未申诉(100)；省平台审核通过后申诉状态变为审核通过(110)；审核通过(110)为终态，不可再变更（"重新申诉"等操作按钮不可见）；若省平台审核不通过则变为审核不通过(120)，可重新申诉；每次状态变更记录到处理记录时间线 | 对应TP-F-003；[API权威] 申诉状态以API §4.4为准: 未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130) | +| AH_REPORT_APL_005 | 平台端-监管上报-异常申诉 | 验证申诉状态流转—未申诉·申诉中状态下不可重复发起申诉 | P0 | 功能测试 | 1. 运单YB202607130054申诉状态为"未申诉(100)·申诉中"（abnormalDetails[].state=110） | 1. 尝试通过API或页面再次对该运单同一异常项发起申诉；2. 观察系统响应 | 运单号: YB202607130054; 申诉状态: 未申诉·申诉中 | 页面"申诉"按钮被禁用或点击后提示"申诉处理中，请勿重复提交"；后端API返回错误，提示"该异常项已有申诉在处理中"；数据库不会产生重复申诉记录 | 对应TP-F-003; TP-F-012 | +| AH_REPORT_APL_006 | 平台端-监管上报-异常申诉 | 验证申诉详情弹窗5个分组字段完整（申诉信息/运单信息/异常信息/省平台反馈/处理记录） | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 存在一条已完成的申诉记录 | 1. 进入申诉记录页面；2. 点击某条记录的"详情"按钮；3. 依次查看5个分组的内容 | 申诉单号: APL202607130001 | 申诉信息分组含: 申诉单号/上报阶段/异常项/申诉原因/申诉状态/申诉时间/申诉人/申诉附件；省平台反馈信息含: 反馈结果/反馈时间/反馈意见；处理记录以时间线形式倒序展示：操作人/操作时间/操作类型/操作内容，每步操作（发起申诉/省平台反馈/重新申诉）均有一条记录 | 对应TP-F-004 | +| AH_REPORT_APL_007 | 平台端-监管上报-异常申诉 | 验证申诉附件上传—支持多附件且格式校验正确 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 准备png、jpg、pdf格式的附件文件各1个，以及1个超出大小限制的文件(如10MB) | 1. 进入申诉发起页面；2. 依次上传png/jpg/pdf文件；3. 尝试上传超限文件 | 附件: 证明1.png(500KB), 证明2.jpg(800KB), 证明3.pdf(1.5MB), 超限文件.exe(10MB) | png/jpg/pdf格式上传成功，附件列表展示文件名和大小；超限文件上传时提示"文件大小超过限制"；上传失败有重试机制；申诉详情弹窗中可查看/下载已上传的附件 | 对应TP-F-005 | +| AH_REPORT_APL_008 | 平台端-监管上报-异常申诉 | 验证17项核验异常（API文档§4.1定义）各自独立发起申诉—每次仅可申诉单个异常项 | P1 | 功能测试 | 1. 准备17条运单（或组合覆盖），每条分别对应一种核验异常项；2. 使用super_admin登录管理端 | 1. 分别对17种异常项运单发起申诉；2. 查看每条申诉记录中的异常项信息；3. 验证各申诉独立互不干扰；4. 确认每次申诉仅含单个verificationAbnormalItems值 | 运单A: 委托合同(100); B: 承运合同(120); C: 实时定位(130); D: 运单时间逻辑(140); E: 车辆资质(150); F: 道路运输证(160); G: 驾驶证(170); H: 从业资格证(180); I: 车辆重复(190); J: 司机重复(200); K: 车辆轨迹(210); L: 运费收款(220); M: 公司统一收款(230); N: 集中支付(240); O: 资金流水(250); P: 发票信息(260); Q: 非通行车辆可开票(270) | 17条申诉各自独立创建，异常项信息与核验结果一致；每条申诉的verificationAbnormalItems字段为单一异常项ID；某一异常项申诉不影响其他异常项的申诉状态；同一运单存在多个异常项时需分别独立发起申诉（参见AH_REPORT_APL_019） | 对应TP-F-007；[API权威] API文档§4.1定义17项核验，每项均可独立申诉但每次只允许申诉单个异常项（单值约束） | +| AH_REPORT_APL_009 | 平台端-监管上报-异常申诉 | 验证从看板操作列点击申诉按钮跳转至申诉页面并自动填充运单号 | P1 | 功能测试 | 1. 看板中存在核验异常的运单YB202607130002；2. 使用super_admin登录管理端 | 1. 进入看板页面；2. 在异常运单YB202607130002的操作列点击"申诉"按钮；3. 观察页面跳转和预填充数据 | 运单号: YB202607130002 | 页面路由正确跳转至申诉发起页面；URL携带正确的运单ID参数；申诉页面自动加载该运单的异常信息（运单号YB202607130002、异常项预填充正确）；运营人员无需手动输入运单号 | 对应TP-F-008 | +| AH_REPORT_APL_010 | 平台端-监管上报-异常申诉 | 验证仅运营人员有权发起申诉—司机/车队长/财务无申诉操作权限 | P1 | 安全性测试 | 1. 准备运营(super_admin)、财务、车队长(13113113113)、司机(15188888888)账号 | 1. 用各账号分别登录；2. 访问申诉功能页面；3. 尝试通过API直接调用申诉接口 | 运营: super_admin; 财务: finance_user; 车队长: 13113113113; 司机: 15188888888 | 运营人员可见"申诉"按钮和申诉记录页面，可发起申诉；车队长/司机端无申诉功能入口，直接URL访问返回403；财务人员可查看申诉记录但"发起申诉"按钮不可见；越权操作被拦截并记录审计日志（操作人/操作时间/操作内容/拦截原因） | 对应TP-F-009 | +| AH_REPORT_APL_011 | 平台端-监管上报-异常申诉 | 验证申诉处理记录时间线按时间倒序排列且操作时间精确到秒 | P2 | 功能测试 | 1. 存在一条经历了发起申诉→省平台反馈→重新申诉→省平台再次反馈的完整申诉记录 | 1. 进入申诉详情弹窗；2. 查看"处理记录"时间线 | 申诉单号: APL202607130002 | 4条操作记录按时间倒序排列（最新的在最上面）；每条记录包含: 操作人（用户名或"省平台"）、操作时间（YYYY-MM-DD HH:mm:ss）、操作类型（发起申诉/复核通过/复核驳回/重新申诉）、操作内容描述；操作类型与实际情况准确对应 | 对应TP-F-010 | +| AH_REPORT_APL_012 | 平台端-监管上报-异常申诉 | 验证异常代码一览表映射—已知异常代码正确映射为中文异常项名称 | P2 | 功能测试 | 1. 模拟省平台返回已知异常代码（如"VEHICLE_QUAL_FAIL"） | 1. 查看申诉页面中该异常代码对应的中文展示；2. 验证映射关系正确 | 异常代码: VEHICLE_QUAL_FAIL | 申诉页面中异常项显示为"车辆资质核验"（中文），非原始代码"VEHICLE_QUAL_FAIL"；异常代码与中文名称一一对应无歧义 | 对应TP-F-011 | +| AH_REPORT_APL_013 | 平台端-监管上报-异常申诉 | 验证未知异常代码兜底展示—显示原始代码+标注未知异常 | P2 | 功能测试 | 1. 模拟省平台返回一个系统中未定义的异常代码（如"UNKNOWN_ERROR_999"） | 1. 查看申诉页面异常项的展示 | 未知异常代码: UNKNOWN_ERROR_999 | 申诉页面中异常项显示原始代码"UNKNOWN_ERROR_999"并标注"(未知异常)"或类似兜底文案（不崩溃、不显示乱码）；系统日志中记录"未识别的异常代码"便于后续排查 | 对应TP-F-011 | +| AH_REPORT_APL_014 | 平台端-监管上报-异常申诉 | 验证同一异常项未申诉·申诉中状态下快速双击提交申诉仅产生1条记录 | P2 | 功能测试 | 1. 运单YB202607130055核验异常，申诉状态为"未申诉(100)"，异常项子状态为"未申诉"(state=100) | 1. 进入申诉页面填写完整信息；2. 快速双击"提交申诉"按钮；3. 查看申诉记录列表 | 运单号: YB202607130055; 异常项: 资金流水核验 | 申诉记录列表中仅产生1条申诉记录（前端防抖+后端校验）；后端有状态校验，"未申诉·申诉中"(abnormalDetails[].state=110)状态下不可重新发起；数据库appeal_record表该运单+该异常项仅有1条"未申诉·申诉中"记录 | 对应TP-F-012 | +| AH_REPORT_APL_015 | 平台端-监管上报-异常申诉 | 验证申诉提交后省平台长时间无反馈(超7个工作日)时系统有合理状态提示 | P3 | 功能测试 | 1. 运单YB202607130056申诉状态为"未申诉(100)·申诉中"（abnormalDetails[].state=110），省平台尚未审核；2. 模拟时间超过7个工作日省平台无反馈 | 1. 进入申诉记录页面查看该申诉记录；2. 查看系统是否有超时提示或告警 | 运单号: YB202607130056; 等待时长: 超过7个工作日 | 申诉记录页面显示"等待省平台复核中"或类似状态提示（申诉状态仍为"未申诉(100)·申诉中"不自动变更）；运营人员可查看申诉等待时长（如"已等待8个工作日"）；系统应触发超时告警通知运营人员跟进（告警渠道和阈值待确认）；不自动变更申诉状态为审核通过(110)或审核不通过(120)；同时也支持已取消(130)状态用于主动取消申诉 | 对应TP-F-013；> ⚠️ 待确认：申诉超时告警机制（告警渠道、触发阈值）需与产品确认 | +| AH_REPORT_APL_016 | 平台端-监管上报-异常申诉 | 验证申诉附件上传失败时有重试机制 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 模拟附件上传接口服务暂时不可用 | 1. 进入申诉发起页面；2. 填写申诉信息并选择附件上传；3. 在上传过程中模拟服务异常 | 附件: 证明文件.png(500KB) | 附件上传失败时前端显示"上传失败，点击重试"提示；点击重试后可重新上传；上传成功后可正常提交申诉；失败不影响已填写的申诉文字内容 | 对应TP-F-005 | +| AH_REPORT_APL_017 | 平台端-监管上报-异常申诉 | 验证财务人员可查看申诉记录但不可发起申诉 | P1 | 安全性测试 | 1. 使用财务账号登录管理端；2. 申诉记录中有数据 | 1. 进入申诉记录页面，查看是否有"发起申诉"按钮；2. 查看申诉详情是否可读；3. 尝试通过API调用申诉发起接口 | 财务账号: finance_user | 申诉记录列表正常展示，可查看详情；"发起申诉"按钮不可见（或置灰）；通过API直接调用申诉发起接口返回403 Forbidden；审计日志中记录财务账号的查看操作 | 对应TP-F-009 | +| AH_REPORT_APL_018 | 平台端-监管上报-异常申诉 | 验证申诉表单仅允许选择单个异常项—verificationAbnormalItems单值约束 | P0 | 功能测试 | 1. 运单YB202607130090同时存在两个异常项：车辆轨迹210和资金流水250；2. 使用super_admin登录管理端 | 1. 进入申诉页面；2. 查看异常项选择区域；3. 尝试选择一个异常项后提交；4. 尝试多选异常项 | 运单号: YB202607130090; 异常项: 210(车辆轨迹), 250(资金流水) | UI层面异常项为单选列表（Radio Button或单选下拉），无法多选；提交请求中verificationAbnormalItems字段为单值（如"210"），非逗号分隔多值；若通过API绕过前端传入逗号分隔多值"210,250"，后端返回错误（如code=500，message包含"仅支持单个异常项目申诉"） | 对应TP-F-014；[技术方案] API单值约束 | +| AH_REPORT_APL_019 | 平台端-监管上报-异常申诉 | 验证同一运单两个异常项需分别发起两次独立申诉 | P1 | 功能测试 | 1. 运单YB202607130090有两个异常项210+250，均状态为"未申诉"；2. 使用super_admin登录管理端 | 1. 对异常项210(车辆轨迹)发起申诉→填写申诉内容→上传附件→提交；2. 验证申诉提交成功；3. 返回申诉页面，再次对异常项250(资金流水)发起申诉→填写内容→提交 | 运单号: YB202607130090; 申诉1: 异常项210; 申诉2: 异常项250 | 两次申诉生成两个独立申诉单号（complaintNumber不同）；数据库appeal_record表存在两条记录，分别对应异常项210和异常项250；两个异常项的申诉状态独立流转，互不影响；第二次申诉的异常项选择区域仅展示尚未申诉的异常项（250），已申诉的异常项210不再可选 | 对应TP-F-015；[技术方案] 独立申诉单 | +| AH_REPORT_APL_020 | 平台端-监管上报-异常申诉 | 验证申诉接口传入逗号分隔多异常项ID时后端拒绝 | P1 | 安全性测试 | 1. 运单YB202607130090有两个异常项210和250均未申诉；2. 获取有效JWT Token | 1. 通过API直接调用POST /appeal/insert接口；2. verificationAbnormalItems参数传入"210,250"（逗号分隔）；3. 查看接口返回 | 运单号: YB202607130090; verificationAbnormalItems: "210,250"(逗号分隔,非法) | 接口返回错误（code=500），message包含"仅支持单个异常项目申诉"或"verificationAbnormalItems必须为单一异常项ID"；数据库appeal_record表不产生新记录；不会错误地创建关联多个异常项的申诉单；单独传入"210"或"250"（单值）时正常成功 | 对应TP-F-016；[技术方案] 后端校验多值拒绝 | + +--- + +## 模块G: 上报日志 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_LOG_001 | 平台端-监管上报-上报日志 | 验证上报日志按完整运单号精确搜索日志记录 | P0 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001存在上报日志记录 | 1. 进入"监管上报-上报日志"页面；2. 在运单号搜索框输入"YB202607130001"；3. 点击搜索 | 运单号: YB202607130001 | 列表仅展示与该运单号相关的所有上报日志记录（含各阶段的重试记录）；数据库查询结果与页面展示一致 | 对应TP-G-001 | +| AH_REPORT_LOG_002 | 平台端-监管上报-上报日志 | 验证上报日志按不存在的单号搜索显示空结果 | P1 | 功能测试 | 1. 使用super_admin登录管理端 | 1. 进入"监管上报-上报日志"页面；2. 输入不存在的单号"NOTEXIST999"；3. 点击搜索 | 运单号: NOTEXIST999 | 列表显示空结果，友好提示"未找到相关日志记录"；控制台无报错 | 对应TP-G-001 | +| AH_REPORT_LOG_003 | 平台端-监管上报-上报日志 | 验证上报日志按"第一次上报"阶段筛选日志 | P0 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中同时存在第一次上报和第二次上报的记录 | 1. 进入"监管上报-上报日志"页面；2. 选择上报阶段"第一次上报"；3. 查看筛选结果 | 筛选条件: 第一次上报 | 列表仅展示stage=1的日志记录；ETC上传日志不包含在内；切换至"ETC上传"时有独立筛选项，日志正确过滤 | 对应TP-G-002 | +| AH_REPORT_LOG_004 | 平台端-监管上报-上报日志 | 验证上报日志按"失败"结果筛选—展示所有非成功日志 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中存在成功(HTTP 200)和失败(HTTP 4xx/5xx/超时)的记录 | 1. 进入日志页面；2. 选择上报结果"失败"；3. 查看筛选结果 | 筛选: 失败 | 列表展示所有非2xx的日志记录，包括HTTP 400/500/超时等；"成功"(200)的记录被过滤；筛选结果与实际日志记录一致 | 对应TP-G-003 | +| AH_REPORT_LOG_005 | 平台端-监管上报-上报日志 | 验证上报日志按时间范围筛选（跨天） | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中存在2026-07-10至2026-07-13的记录 | 1. 进入日志页面；2. 选择开始时间"2026-07-10 00:00:00"，结束时间"2026-07-12 23:59:59"；3. 点击搜索 | 时间范围: 2026-07-10~2026-07-12 | 列表仅展示该时间范围内的日志记录；不包含2026-07-13的日志；开始时间>结束时间时系统给出提示或自动交换；不选时间范围时默认展示全部 | 对应TP-G-004 | +| AH_REPORT_LOG_006 | 平台端-监管上报-上报日志 | 验证上报日志列表11个字段完整展示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中有至少1条完整记录 | 1. 进入日志页面；2. 查看列表表头和第一条数据的所有列 | 查看一条典型日志记录 | 列表展示: 序号/货源单号/运单号/托运单号/上报阶段/上报结果/接口URL/HTTP状态码/响应时间/上报时间/操作；接口URL完整（含域名和路径如https://anhui.report.gov.cn/api/v1/waybill/submit）；HTTP状态码为实际返回状态码；响应时间单位为ms；上报时间为实际请求发起时间 | 对应TP-G-005 | +| AH_REPORT_LOG_007 | 平台端-监管上报-上报日志 | 验证点击日志操作列详情按钮弹窗展示完整请求和响应报文 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中有1条失败记录 | 1. 进入日志页面；2. 点击某条日志操作列的"详情"按钮；3. 在弹窗中查看请求报文和响应报文 | 查看一条HTTP 400失败的日志详情 | 弹窗展示请求报文: URL（完整）、Method（POST）、Headers（Content-Type/Authorization等）、Body（完整JSON）；响应报文: Status Code（400）、Headers、Body（错误信息JSON）；JSON报文格式化展示（缩进/语法高亮）；长报文支持滚动查看；支持一键复制请求/响应内容 | 对应TP-G-006 | +| AH_REPORT_LOG_008 | 平台端-监管上报-上报日志 | 验证每个上报阶段及自动修改字段接口的每次调用均在日志中完整记录 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001已完成全流程上报（第一次+修改字段+第二次+7核验+第三次+ETC） | 1. 进入日志页面；2. 按运单号YB202607130001搜索；3. 逐条检查日志记录是否覆盖所有阶段 | 运单号: YB202607130001 | 日志中至少包含以下记录: 第一次上报请求+响应、第一次上报修改字段请求+响应、第二次上报请求+响应、7类核验各自的请求+响应日志、第三次上报请求+响应、ETC上传请求+响应；自动重试的每次请求均独立记录（如第一次上报失败重试2次→共3条日志） | 对应TP-G-007 | +| AH_REPORT_LOG_009 | 平台端-监管上报-上报日志 | 验证上报失败日志包含完整的Error Response Body和重试次数标记 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 存在上报失败的日志记录 | 1. 进入日志页面；2. 筛选"失败"的日志；3. 点击某条失败日志的详情；4. 查看失败信息完整度 | 查看一条第2次重试失败的日志 | 失败日志包含完整的Error Response Body（JSON格式）；超时日志标注"timeout"并记录超时时长（如30000ms）；重试日志中标注当前是第几次重试（如"重试第2/3次"）；异常日志可关联到具体运单ID，方便排查 | 对应TP-G-008 | +| AH_REPORT_LOG_010 | 平台端-监管上报-上报日志 | 验证上报日志区分自动触发和手动触发—自动标注"系统自动"/手动标注操作人 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 存在自动触发的上报日志和手动触发的上报日志 | 1. 进入日志页面；2. 查看自动触发上报的日志记录中的操作人字段；3. 查看手动触发上报的日志记录中的操作人字段 | 自动日志: 第一次上报(装货完成触发); 手动日志: 第一次上报(手动上传) | 自动触发的上报日志操作人标注"系统自动"或"auto"；手动触发的上报日志操作人标注实际登录用户名（如"super_admin"）；审计日志中操作人信息与实际登录用户一致 | 对应TP-G-009 | +| AH_REPORT_LOG_011 | 平台端-监管上报-上报日志 | 验证上报日志组合筛选—阶段+结果+时间范围+单号同时筛选 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志数据满足组合条件 | 1. 进入日志页面；2. 设置: 阶段=第二次上报、结果=失败、时间范围=2026-07-10~2026-07-13、运单号=YB20260713；3. 点击搜索 | 组合: 第二次上报+失败+2026-07-10~2026-07-13+YB20260713 | 列表仅展示同时满足4个条件的日志记录；各条件在数据库查询中均正确生效；组合结果为空时有友好提示 | 对应TP-G-001; TP-G-002; TP-G-003; TP-G-004 | + +--- + +## 跨模块测试点 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_CROSS_001 | 平台端-监管上报-跨模块 | 验证完整三阶段依赖链端到端验证—后端三重前置状态校验 | P0 | 功能测试 | 1. 准备一条安徽税源地(34)的运单YB202607130001 | 1. 使第一次上报失败（关闭监管平台接口）；2. 尝试调用第二次上报API；3. 查看返回；4. 使第二次上报失败；5. 尝试调用第三次上报API；6. 查看返回 | 运单号: YB202607130001 | 第一次上报失败→第二次上报API返回错误码"前置上报未完成"；第二次上报失败→第三次上报API返回错误码"前置上报（第二次）未完成"；三个阶段不可跳级执行；依赖链校验在后端通过查询report_status表实现，非仅前端控制；每个阶段的阻断/通过状态独立存储 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_CROSS_002 | 平台端-监管上报-跨模块 | 验证多模块数据一致性—修改源数据后各阶段上报感知变更并使用最新值 | P0 | 功能测试 | 1. 运单YB202607130046初始数据: 司机15188888888、合同金额¥10,000.00、发票金额¥10,300.00 | 1. 第一次上报前修改司机信息（如更换司机手机号）；2. 触发第一次上报，验证使用最新司机信息；3. 财务修改打款金额（¥10,000.00→¥9,500.00）；4. 触发第二次上报，验证使用¥9,500.00；5. 修改发票金额（¥10,300.00→¥10,100.00）；6. 触发第三次上报，验证使用¥10,100.00 | 运单号: YB202607130046; 修改项: 司机/金额/发票 | 第一次上报使用最新司机信息；第二次上报金额为¥9,500.00（非缓存的¥10,000.00）；第三次上报发票金额为¥10,100.00（非旧值）；数据库查询日志可确认各字段的数据来源表（非缓存）；数据库report_record表各阶段记录中的数据与来源表一致 | [AI修正: 历史缺陷防御] - BUG-202607-03 | +| AH_REPORT_CROSS_003 | 平台端-监管上报-跨模块 | 验证安徽税源地运单完整上报链路—装货到ETC全流程核验通过（冒烟测试） | P0 | 冒烟测试 | 1. 准备一条安徽税源地(34)的完整运单YB202607130001，所有资质有效、合同有效、轨迹正常、支付正常、发票正常 | 1. 装货完成→等待第一次上报→验证状态"已上传"；2. 等待自动修改字段→验证日志中有修改记录；3. 财务打款¥10,000.00→等待第二次上报→验证7类核验全部通过；4. 发票FP202607130001开具→等待第三次上报→验证状态"已上传"；5. 税务抵扣完成→ETC发票ETC202607130001上传→验证状态"已上传" | 运单号: YB202607130001; 金额: ¥10,000.00; 发票: FP202607130001; ETC: ETC202607130001 | 第一次上报成功→第二次上报成功（7核验全通过）→第三次上报成功→ETC上传成功；每个阶段看板数据正确更新；上报日志完整记录全链路；数据库report_record表stage=1/2/3均状态=1；etc_report_record表status=1 | 对应TP-X-003 | +| AH_REPORT_CROSS_004 | 平台端-监管上报-跨模块 | 验证非安徽税源地运单(云南=28)全部阶段均不触发上报 | P0 | 功能测试 | 1. 准备一条云南税源地(28)的运单YB202607130002，包含完整运输流程 | 1. 装货完成→检查是否触发第一次上报；2. 财务打款→检查是否触发第二次上报；3. 发票开具→检查是否触发第三次上报；4. 税务抵扣→检查是否触发ETC上传；5. 查看看板中是否存在该运单 | 运单号: YB202607130002; 省份代码: 28(云南) | 全部阶段均不触发上报；看板中不显示该云南运单；上报日志中无该运单的任何上报记录；系统无因"不触发"而产生的错误日志或异常告警；云南运单本身的运输流程（装货→运输→卸货→结算）不受影响正常流转 | 对应TP-X-004 | +| AH_REPORT_CROSS_005 | 平台端-监管上报-跨模块 | 验证多省份部署下安徽(34)和云南(28)上报数据完全隔离 | P1 | 功能测试 | 1. 准备安徽(34)运单YB202607130001和云南(28)运单YB202607130002各1条 | 1. 分别触发两条运单的完整上报流程；2. 查看两个省份的上报日志和数据记录；3. 验证安徽运单的上报目标URL为安徽监管平台，云南运单为云南监管平台 | 安徽: YB202607130001(34); 云南: YB202607130002(28) | 安徽运单仅上报至安徽监管平台(URL含anhui)；云南运单仅上报至云南监管平台(URL含yunnan)；两个省份的report_record表数据通过province_code字段物理/逻辑隔离；省份代码各自独立（安徽=34、云南=28），不混淆 | 对应TP-X-005 | +| AH_REPORT_CROSS_006 | 平台端-监管上报-跨模块 | 验证定时任务重试与手动触发上报的并发控制—分布式锁机制 | P1 | 功能测试 | 1. 运单YB202607130057第一次上报失败，定时重试任务即将触发第1次重试；2. super_admin在管理端准备手动点击"手动上传" | 1. 在重试任务触发的同时，super_admin点击"手动上传"；2. 观察并发场景下的系统行为 | 运单号: YB202607130057 | 同一时刻仅1个上报请求被执行（通过分布式锁如Redis SETNX控制）；被拒绝的请求返回"上报处理中"提示；不产生重复上报记录；分布式锁正确释放，后续操作可正常进行 | 对应TP-B-014; TP-C-021 | +| AH_REPORT_CROSS_007 | 平台端-监管上报-跨模块 | 验证回单签收后财务打款前不触发第二次上报—打款完成才触发 | P2 | 功能测试 | 1. 运单YB202607130001第一次上报已完成；2. 回单已签收但财务尚未打款 | 1. 回单签收完成后检查第二次上报列表；2. 财务执行打款后再次检查第二次上报列表；3. 对比两次检查的时间点 | 运单号: YB202607130001; 回单签收时间: 2026-07-12 15:00; 打款时间: 2026-07-12 17:00 | 回单签收完成后第二次上报列表中无该运单记录（未触发）；财务打款完成后第二次上报列表中出现该运单记录（已触发）；上报时间戳接近打款完成时间（如2026-07-12 17:00:05），非回单签收时间 | 对应TP-X-006 | + +--- + +## 测试点→用例映射表 + +| 测试点ID | 对应的用例编号 | 覆盖状态 | +| :--- | :--- | :--- | +| TP-A-001 | AH_REPORT_DASH_001, AH_REPORT_DASH_002, AH_REPORT_DASH_003 | 已覆盖 | +| TP-A-002 | AH_REPORT_DASH_004 | 已覆盖 | +| TP-A-003 | AH_REPORT_DASH_005 | 已覆盖 | +| TP-A-004 | AH_REPORT_DASH_006 | 已覆盖 | +| TP-A-005 | AH_REPORT_DASH_007 | 已覆盖 | +| TP-A-006 | AH_REPORT_DASH_008, AH_REPORT_DASH_009 | 已覆盖 | +| TP-A-007 | AH_REPORT_DASH_010 | 已覆盖 | +| TP-A-008 | AH_REPORT_DASH_011 | 已覆盖 | +| TP-A-009 | AH_REPORT_DASH_012 | 已覆盖 | +| TP-A-010 | AH_REPORT_DASH_013 | 已覆盖 | +| TP-A-011 | AH_REPORT_DASH_014, AH_REPORT_DASH_015 | 已覆盖 | +| TP-A-012 | AH_REPORT_DASH_016 | 已覆盖 | +| TP-A-013 | AH_REPORT_DASH_017 | 已覆盖 | +| TP-A-014 | AH_REPORT_DASH_018 | 已覆盖 | +| TP-B-001 | AH_REPORT_R1_001 | 已覆盖 | +| TP-B-002 | AH_REPORT_R1_002, AH_REPORT_R1_003 | 已覆盖 | +| TP-B-003 | AH_REPORT_R1_004, AH_REPORT_R1_005, AH_REPORT_R1_021 | 已覆盖 | +| TP-B-004 | AH_REPORT_R1_003, AH_REPORT_R1_006 | 已覆盖 | +| TP-B-005 | AH_REPORT_R1_007, AH_REPORT_R1_008 | 已覆盖 | +| TP-B-006 | AH_REPORT_R1_009 | 已覆盖 | +| TP-B-007 | AH_REPORT_R1_010 | 已覆盖 | +| TP-B-008 | AH_REPORT_R1_011 | 已覆盖 | +| TP-B-009 | AH_REPORT_R1_012 | 已覆盖 | +| TP-B-010 | AH_REPORT_R1_023 | 已覆盖 | +| TP-B-011 | AH_REPORT_DASH_014 | 已覆盖（见看板详情弹窗用例） | +| TP-B-012 | AH_REPORT_DASH_015 | 已覆盖（见看板详情弹窗用例） | +| TP-B-013 | AH_REPORT_R1_022 | 已覆盖 | +| TP-B-014 | AH_REPORT_R1_013, AH_REPORT_R1_014, AH_REPORT_CROSS_006 | 已覆盖 | +| TP-B-015 | AH_REPORT_R1_015 | 已覆盖 | +| TP-B-016 | AH_REPORT_R1_016 | 已覆盖 | +| TP-B-017 | AH_REPORT_R1_017 | 已覆盖 | +| TP-B-018 | AH_REPORT_R1_018 | 已覆盖 | +| TP-B-019 | AH_REPORT_R1_019, AH_REPORT_R1_020 | 已覆盖 | +| TP-B-020 | AH_REPORT_R1_024 | 已覆盖 | +| TP-C-001 | AH_REPORT_R2_001 | 已覆盖 | +| TP-C-002 | AH_REPORT_R2_002 | 已覆盖 | +| TP-C-003 | AH_REPORT_R2_003 | 已覆盖 | +| TP-C-004 | AH_REPORT_R2_004 | 已覆盖 | +| TP-C-005 | AH_REPORT_R2_004 | 已覆盖 | +| TP-C-006 | AH_REPORT_R2_005 | 已覆盖 | +| TP-C-007 | AH_REPORT_R2_006 | 已覆盖 | +| TP-C-008 | AH_REPORT_R2_007 | 已覆盖 | +| TP-C-009 | AH_REPORT_R2_008 | 已覆盖 | +| TP-C-010 | AH_REPORT_R2_009 | 已覆盖 | +| TP-C-011 | AH_REPORT_R2_010 | 已覆盖 | +| TP-C-012 | AH_REPORT_R2_011 | 已覆盖 | +| TP-C-013 | AH_REPORT_R2_012 | 已覆盖 | +| TP-C-014 | AH_REPORT_R2_013 | 已覆盖 | +| TP-C-015 | AH_REPORT_R2_014, AH_REPORT_R2_015 | 已覆盖 | +| TP-C-016 | AH_REPORT_R2_016 | 已覆盖 | +| TP-C-017 | AH_REPORT_R2_017, AH_REPORT_R2_018 | 已覆盖 | +| TP-C-018 | AH_REPORT_R2_019, AH_REPORT_R2_020, AH_REPORT_R2_021 | 已覆盖 | +| TP-C-019 | AH_REPORT_R2_022, AH_REPORT_R2_023 | 已覆盖 | +| TP-C-020 | AH_REPORT_R2_024 | 已覆盖 | +| TP-C-021 | AH_REPORT_R2_025, AH_REPORT_CROSS_006 | 已覆盖 | +| TP-C-022 | AH_REPORT_R2_026 | 已覆盖 | +| TP-C-023 | AH_REPORT_R2_027 | 已覆盖 | +| TP-C-024 | AH_REPORT_R2_028, AH_REPORT_R2_054 | 已覆盖 | +| TP-D-001 | AH_REPORT_R3_001 | 已覆盖 | +| TP-D-002 | AH_REPORT_R3_002 | 已覆盖 | +| TP-D-003 | AH_REPORT_R3_003 | 已覆盖 | +| TP-D-004 | AH_REPORT_R3_004, AH_REPORT_R3_005 | 已覆盖 | +| TP-D-005 | AH_REPORT_R3_006, AH_REPORT_R3_007 | 已覆盖 | +| TP-D-006 | AH_REPORT_R3_008, AH_REPORT_R3_009 | 已覆盖 | +| TP-D-007 | AH_REPORT_R3_010 | 已覆盖 | +| TP-D-008 | AH_REPORT_R3_014 | 已覆盖 | +| TP-D-009 | AH_REPORT_R3_011 | 已覆盖 | +| TP-D-010 | AH_REPORT_R3_012 | 已覆盖 | +| TP-D-011 | AH_REPORT_R3_013 | 已覆盖 | +| TP-E-001 | AH_REPORT_ETC_001 | 已覆盖 | +| TP-E-002 | AH_REPORT_ETC_002 | 已覆盖 | +| TP-E-003 | AH_REPORT_ETC_003 | 已覆盖 | +| TP-E-004 | AH_REPORT_ETC_004 | 已覆盖 | +| TP-E-005 | AH_REPORT_ETC_005, AH_REPORT_ETC_006, AH_REPORT_ETC_011, AH_REPORT_ETC_012 | 已覆盖 | +| TP-E-006 | AH_REPORT_ETC_007 | 已覆盖 | +| TP-E-007 | AH_REPORT_ETC_008 | 已覆盖 | +| TP-E-008 | AH_REPORT_ETC_009 | 已覆盖 | +| TP-E-009 | AH_REPORT_ETC_010 | 已覆盖 | +| TP-F-001 | AH_REPORT_APL_001 | 已覆盖 | +| TP-F-002 | AH_REPORT_APL_003 | 已覆盖 | +| TP-F-003 | AH_REPORT_APL_004, AH_REPORT_APL_005 | 已覆盖 | +| TP-F-004 | AH_REPORT_APL_006 | 已覆盖 | +| TP-F-005 | AH_REPORT_APL_007, AH_REPORT_APL_016 | 已覆盖 | +| TP-F-006 | AH_REPORT_APL_002 | 已覆盖 | +| TP-F-007 | AH_REPORT_APL_008 | 已覆盖 | +| TP-F-008 | AH_REPORT_APL_009 | 已覆盖 | +| TP-F-009 | AH_REPORT_APL_010, AH_REPORT_APL_017 | 已覆盖 | +| TP-F-010 | AH_REPORT_APL_011 | 已覆盖 | +| TP-F-011 | AH_REPORT_APL_012, AH_REPORT_APL_013 | 已覆盖 | +| TP-F-012 | AH_REPORT_APL_005, AH_REPORT_APL_014 | 已覆盖 | +| TP-F-013 | AH_REPORT_APL_015 | 已覆盖 | +| TP-F-014 | AH_REPORT_APL_018 | 已覆盖 | +| TP-F-015 | AH_REPORT_APL_019 | 已覆盖 | +| TP-F-016 | AH_REPORT_APL_020 | 已覆盖 | +| TP-G-001 | AH_REPORT_LOG_001, AH_REPORT_LOG_002 | 已覆盖 | +| TP-G-002 | AH_REPORT_LOG_003 | 已覆盖 | +| TP-G-003 | AH_REPORT_LOG_004 | 已覆盖 | +| TP-G-004 | AH_REPORT_LOG_005 | 已覆盖 | +| TP-G-005 | AH_REPORT_LOG_006 | 已覆盖 | +| TP-G-006 | AH_REPORT_LOG_007 | 已覆盖 | +| TP-G-007 | AH_REPORT_LOG_008 | 已覆盖 | +| TP-G-008 | AH_REPORT_LOG_009 | 已覆盖 | +| TP-G-009 | AH_REPORT_LOG_010 | 已覆盖 | +| TP-X-001 | AH_REPORT_CROSS_001 | 已覆盖 | +| TP-X-002 | AH_REPORT_CROSS_002 | 已覆盖 | +| TP-X-003 | AH_REPORT_CROSS_003 | 已覆盖 | +| TP-X-004 | AH_REPORT_CROSS_004 | 已覆盖 | +| TP-X-005 | AH_REPORT_CROSS_005 | 已覆盖 | +| TP-X-006 | AH_REPORT_CROSS_007 | 已覆盖 | + +所有135个测试点均已映射到至少一条测试用例。 + +--- + +## 历史缺陷防御映射表 + +| 历史缺陷ID | 防御用例 | 备注 | +| :--- | :--- | :--- | +| BUG-202607-01（阶段依赖链断裂） | AH_REPORT_R1_007, AH_REPORT_R1_008, AH_REPORT_R2_024, AH_REPORT_R3_006, AH_REPORT_R3_007, AH_REPORT_CROSS_001 | 后端三重前置状态校验覆盖 | +| BUG-202607-02（重试幂等缺陷） | AH_REPORT_R1_013, AH_REPORT_R1_014, AH_REPORT_R2_025, AH_REPORT_R3_011, AH_REPORT_ETC_009, AH_REPORT_CROSS_006 | 分布式锁+唯一约束+前端防抖覆盖 | +| BUG-202607-03（跨模块数据不一致） | AH_REPORT_R2_002, AH_REPORT_R2_003, AH_REPORT_R3_013, AH_REPORT_CROSS_002 | 数据来源溯源验证覆盖 | +| BUG-202607-04（省份代码硬编码） | AH_REPORT_R1_006, AH_REPORT_CROSS_005 | 省份代码动态配置+多省份隔离覆盖 | + +--- + +## 漏测清单覆盖汇总 + +| 漏测类别 | 覆盖用例数 | 覆盖状态 | +| :--- | :--- | :--- | +| 空值/Null处理 | AH_REPORT_R1_018 (1条) | 已覆盖 | +| 金额精度 | AH_REPORT_R2_002, AH_REPORT_R3_012, AH_REPORT_ETC_008 (3条) | 已覆盖 | +| 重复提交/防抖 | AH_REPORT_R1_013, AH_REPORT_R1_014, AH_REPORT_R2_025, AH_REPORT_R3_011, AH_REPORT_ETC_009 (5条) | 已覆盖 | +| 超时处理 | AH_REPORT_R1_015, AH_REPORT_R1_016, AH_REPORT_APL_015 (3条) | 已覆盖 | +| 列表字段完整性 | AH_REPORT_DASH_011, AH_REPORT_R2_004, AH_REPORT_R3_002, AH_REPORT_ETC_002, AH_REPORT_APL_003, AH_REPORT_LOG_006 (6条) | 已覆盖 | +| 查询重置 | AH_REPORT_DASH_010 (1条) | 已覆盖 | +| 状态与按钮映射 | AH_REPORT_DASH_013, AH_REPORT_R1_012 (2条) | 已覆盖 | +| 多阶段依赖链 | AH_REPORT_R1_007, AH_REPORT_R2_024, AH_REPORT_R3_007, AH_REPORT_CROSS_001 (4条) | 已覆盖 | +| 第三方核验逐项覆盖 | AH_REPORT_R2_005~AH_REPORT_R2_023 (14条，7类×通过+异常) + AH_REPORT_R2_030~AH_REPORT_R2_053 (24条，API文档12项补充核验×通过+异常) = 共38条覆盖API文档17项核验 | 已覆盖 | +| 重试+手动触发并发 | AH_REPORT_R1_013, AH_REPORT_R2_025, AH_REPORT_CROSS_006 (3条) | 已覆盖 | +| 跨模块数据一致性 | AH_REPORT_R2_002, AH_REPORT_R2_003, AH_REPORT_CROSS_002 (3条) | 已覆盖 | +| 省份/区域配置隔离 | AH_REPORT_R1_006, AH_REPORT_CROSS_005 (2条) | 已覆盖 | +| 上报数据字段溯源 | AH_REPORT_R2_002, AH_REPORT_R3_013, AH_REPORT_CROSS_002 (3条) | 已覆盖 | +| 标签颜色映射 | AH_REPORT_DASH_012, AH_REPORT_R1_023, AH_REPORT_R2_004 (3条) | 已覆盖 | +| 详情弹窗分组完整性 | AH_REPORT_DASH_014, AH_REPORT_DASH_015, AH_REPORT_R1_022, AH_REPORT_R3_003, AH_REPORT_ETC_003, AH_REPORT_APL_006 (6条) | 已覆盖 | +| 轨迹数据边界(2~2000) | AH_REPORT_R2_020, AH_REPORT_R2_021, AH_REPORT_R2_022, AH_REPORT_R2_023 (4条) | 已覆盖 | +| 申诉闭环 | AH_REPORT_APL_001, AH_REPORT_APL_002, AH_REPORT_APL_004 (3条) | 已覆盖 | +| 操作日志可追溯 | AH_REPORT_LOG_006, AH_REPORT_LOG_007, AH_REPORT_LOG_008, AH_REPORT_LOG_009, AH_REPORT_LOG_010 (5条) | 已覆盖 | + +--- + +> ⚠️ 待确认项： +> 1. 需求中"异常代码一览表"章节仅有标题无具体内容，需与产品确认完整的异常代码映射表后补充 AH_REPORT_APL_012 的详细验证数据。 +> 2. 自动重试的具体间隔时间（当前用例中使用5s/15s/30s为参考值），需与技术方案确认后更新 AH_REPORT_R1_010, AH_REPORT_R2_026, AH_REPORT_R3_010, AH_REPORT_ETC_007 中的重试间隔。 +> 3. ETC税额边界值（0.01元 → 税额=0.00）的四舍五入规则需与财务确认，更新 AH_REPORT_ETC_008。 +> 4. 申诉超时告警阈值（当前用例中使用7个工作日为参考值）需与产品确认，更新 AH_REPORT_APL_015。 +> 5. 建议在后续需求评审中人工确认安徽运八与现有云南运八上报逻辑是否存在字段/接口冲突。 +> 6. 部分用例中使用的模拟数据（如运单号YB202607130004~YB202607130057等）为测试用例设计时分配的虚拟编号，实际执行时需替换为测试环境中真实存在的运单数据。 +> 7. 涉及省平台回调的用例（如申诉复核反馈、核验结果返回），实际执行时需确认是否有省平台测试环境或mock工具支持。 diff --git a/output/versions/安徽运八需求/v4/安徽运八需求_测试用例.xlsx b/output/versions/安徽运八需求/v4/安徽运八需求_测试用例.xlsx new file mode 100644 index 0000000..a84abf5 Binary files /dev/null and b/output/versions/安徽运八需求/v4/安徽运八需求_测试用例.xlsx differ diff --git a/output/versions/安徽运八需求/v5/normalized_inputs/requirement.md b/output/versions/安徽运八需求/v5/normalized_inputs/requirement.md new file mode 100644 index 0000000..95a9d8e --- /dev/null +++ b/output/versions/安徽运八需求/v5/normalized_inputs/requirement.md @@ -0,0 +1,164 @@ +# 安徽运八需求 + +> 文档角色：需求文档 +> 原始来源：`source_docs\requirements_raw\安徽运八需求.docx` + +安徽运八需求 +一、需求概述 +根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将税源地为安徽运八的运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八），其他税源地不走此逻辑。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。本功能模块旨在实现上报流程的自动化管理，并提供异常监控与向平台发起申诉的能力。 +二、功能说明 +2.1 上报运单看板 +· 功能描述 +上报运单看板是系统的首页，集中展示所有上报阶段运单的汇总状态，支持按条件筛选、查看详情和发起申诉。 +· 查询条件 +运单号/托运单号/货源单号：模糊搜索 +上报阶段：全部 / 第一次上报 / 第二次上报 / 第三次上报 +核验状态：全部 / 异常 / 通过 +申诉状态：全部 / 未申诉 / 申诉中 / 申诉通过 / 申诉驳回 +操作按钮：查询、重置、导出 +· 列表字段 +货源单号、运单号、托运单号、车牌号、司机姓名、 +托运方名称、上报阶段、核验状态、申诉状态、异常项、 +货物名称、合同金额、最新核验时间、操作（申诉/进度/详情） +2.2 第一次上报（装货完成） +功能描述 +第一次上报在运单装货完成后自动触发（仅上传货源税源地为安徽运八的运单，其他税源地无需上传），上报数据包含运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息、保险信息等。 +特殊说明 +• 上报完成后，若安徽运八平台核验通过，系统会自动调用“修改第一次上报部分字段”接口，更新装货后可能发生变化的字段（如实际里程），无需人工干预。 +• 若上报失败，系统需要自动重试（最多3次），若仍失败则通过系统站内信或者其他方式通知运营人员。 +• 第一次上传是后续两次上传的基础，若失败会导致后续上报无法进行，需重点关注。 +上报状态规则 +| 状态 | 说明 | 操作按钮 | 标签颜色 | +| 上传中 | 数据正在上报中 | 无 | 蓝色 | +| 已上传 | 上报成功 | 无 | 绿色 | +| 上传失败 | 上报超时 | 手动上传 | 红色 | +| 异常 | 数据校验不通过 | 详情查看异常原因 | 橙色 | +列表字段 +货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、业务类型、货物名称、装货地址、卸货地址、运输里程、合同编号、上报状态、操作（详情） +详情弹窗字段分组 +详情弹窗按以下子对象分组展示： +建单信息（必选，13字段）：上游企业委托运输单号、本运单单号、托运人建单时间、网络货运经营者名称、统一社会信用代码、道路运输经营许可证编号、业务类型代码、运输组货方式代码、司机接单时间、司机起运时间、承运合同编号、委托合同编号（可选）、运输里程（可选） +托运人信息（必选，7字段）：托运人名称、托运人统一社会信用代码、框架合同编号（可选）、装货地点、装货经度、装货纬度、装货地行政区划代码 +收货方信息（必选，5字段）：收货方名称、收货方统一社会信用代码/身份证号、收货地点、收货经度、收货纬度 +司机信息（必选，13字段）：司机姓名、身份证号、驾驶证号、驾驶证发证机关、从业资格证号、从业资格证有效期起、从业资格证有效期至、税务登记证号、手机号、驾驶证有效期起、驾驶证有效期至、准驾车型、省份代码 +接单车辆信息（必选，19字段）：车牌号、车牌颜色编码、号牌种类、车辆识别代号VIN)、车主姓名/单位名称、车主证件号、使用性质、车辆类型、能源类型、注册日期、发证日期、发证机关、核定载质量吨)、总质量吨)、道路运输证号、挂车牌照号（可选）、行驶证档案编号（可选）、道路运输证有效期起（可选）、道路运输证有效期至（可选） +货物信息（必选，可多条，4字段）：货物名称、货物类型代码、货物量、计量单位 +保险信息（可选，2字段）：保险单号、保险公司名称 +异常信息：核验状态、异常原因、异常时间、处理状态 +2.3 第二次上报（打款完成） +功能描述 +第二次上报在运费支付完成后系统自动触发，上报数据包含运抵信息、货主资金流水、承运人资金流水、承运合同信息、委托合同信息、车辆轨迹信息等。 +特殊说明 +• 第二次上传核验项最多，是最容易出现异常的环节，需要重点关注。 +• 若资金流水单号重复，会导致上报失败，系统会自动检查并提示。 +• 车辆轨迹点位数量不足或偏差过大，会导致"车辆轨迹合规"核验异常，可通过"补传轨迹"功能补充轨迹数据。 +• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。 +列表字段 +货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、承运运费、总金额、付款方式、付款时间、收款人、收款账号、收款账号类型、核验状态、异常项、上报状态、操作（上报/详情） +收款账号类型说明 +• 个人账户：司机个人银行卡账号，标签为蓝色 +• 对公账户：企业银行账号，标签为绿色 +详情弹窗字段分组 +（1）运单信息（必选）：同第一次上报 +（2）托运方信息（必选）：同第一次上报 +（3）收货方信息（必选）：同第一次上报 +（4）资金流水信息（必选）：支付金额、支付方式、支付时间、付款方名称、收款方名称、收款人、收款账号、收款账号类型、流水号、支付状态 +（5）车辆轨迹信息（必选，可多条，2~2000个点）：定位类型、定位时间、定位地点、经度、纬度、轨迹类型 +（6）异常信息：核验状态、异常原因、异常时间、处理状态 +核验内容（监管平台自动核验，异常时可发起申诉） +| 核验项 | 说明 | +| 运单重复核验 | 检查同一运单是否重复上报 | +| 车辆资质核验 | 检查车辆道路运输证是否在有效期内 | +| 司机资质核验 | 检查司机从业资格证是否在有效期内 | +| 集中支付核验 | 检查资金流水是否通过网货平台集中支付 | +| 资金流水核验 | 检查资金流水单号是否重复、金额是否匹配 | +| 合同核验 | 检查运输合同和委托合同是否有效 | +| 车辆轨迹合规核验 | 检查车辆轨迹是否真实、与运单路线是否匹配 | +2.4 第三次上报（开票完成） +功能描述 +第三次上报在发票开具完成后触发，上报数据包含运单信息（托运单号数组）、发票信息、油气发票信息等。 +特殊说明 +• 第三次上传需要在运单完成第二次上传后方可进行。 +• 若增值税发票验证失败，会导致上报失败，需检查发票信息是否正确。 +• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。 +列表字段 +货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、发票号码、发票金额、开票日期、核验状态、异常原因、上报状态、操作（详情） +详情弹窗字段分组 +（1）运单信息（必选）：同第一次上报 +（2）发票信息（必选，17字段）：托运单号数组、发票号码、发票代码号、发票金额价税合计)、开票日期、销售方名称、销售方纳税人识别号、销售方地址、销售方电话、销售方开户行、销售方银行账户、受票方名称、受票方纳税人识别号、受票方地址、受票方电话、受票方开户行、受票方银行卡号 +（3）油气发票信息（可选，可多条）：油气托运单号、油气发票文件 +（4）异常信息：核验状态、异常原因、异常时间、处理状态 +2.5 ETC发票上传 +功能描述 +ETC发票上传用于上报车辆通行高速公路的ETC发票信息，作为税务抵扣凭证。 +特殊说明 +• ETC发票上传需要在税务抵扣完成后进行，否则会导致上报失败。 +• 若ETC发票验证失败，会导致上报失败，需检查发票信息是否正确。 +• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。 +列表字段 +货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、ETC发票号码、发票金额、税率、上传状态、操作（详情） +详情弹窗字段分组 +（1）运单信息：运单号、货源单号、托运单号、车牌号、司机姓名、托运方名称、收货方名称 +（2）ETC发票信息（每张发票18字段）：ETC发票号码、ETC发票代码、开票时间、发票金额、税率、税额、价税合计、销售方名称、销售方税号、受票方名称、受票方税号、入口收费站、出口收费站、交易时间、交易金额、交易匹配时间、交易流水号、ETC发票文件 +（3）异常信息：核验状态、异常原因、异常时间、处理状态 +2.6 异常申诉功能 +运单完成第二次上传后，安徽省管理平台自动进行 7 大类核验（车辆资质、司机资质、资金流水、合同、轨迹等）。如核验结果为异常时，运营人员可通过申诉机制向平台说明情况并申请重新核验。 +本模块补全“异常查询 → 发起申诉 → 跟踪监管平台反馈 → 合规判断”的完整闭环。 +当上报数据被核验为异常时，运营人员可发起申诉，向安徽监管平台说明情况并申请重新核验。申诉记录管理页面展示所有申诉记录及省平台反馈结果。 +列表字段 +运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、异常项、申诉状态、申诉时间、申诉人、省平台反馈结果、监管平台反馈时间、操作（详情/重新申诉） +详情弹窗字段分组 +（1）申诉信息：申诉单号、上报阶段、异常项、申诉原因、申诉状态、申诉时间、申诉人、申诉附件 +（2）运单信息：运单号、托运单号、车牌号、司机姓名、托运方名称 +（3）异常信息：核验状态、异常原因、异常时间 +（4）省平台反馈信息：反馈结果、反馈时间、反馈意见 +（5）处理记录：操作人、操作时间、操作类型、操作内容（时间线展示） +申诉复核说明 +（注：申诉由安徽监管平台复核，非我方审核） +（复核不通过时，可补充材料后重新发起申诉） +异常代码一览表 +2.7 上报日志 +功能描述 +上报日志记录所有上报接口的调用记录，用于问题排查和审计。 +查询条件 +• 运单号/托运单号/货源单号：模糊搜索 +• 上报阶段：全部 / 第一次上报 / 第二次上报 / 第三次上报 / ETC上传 +• 上报结果：全部 / 成功 / 失败 +• 开始时间 ~ 结束时间：时间范围筛选 +列表字段 +序号、货源单号、运单号、托运单号、上报阶段、上报结果、接口URL、HTTP状态码、响应时间、上报时间、操作（弹窗详情查看完整请求/响应报文） +三. 数据字段说明 +3.1 第一次上报字段（装货完成） +核心子对象及必选字段： +• waybillInfo（建单信息）：originalDocumentNumber、shippingNoteNumber、documentCreateTime、carrier、unifiedSocialCreditIdentifier、permitNumber、businessTypeCode、goodsArrangementTypeCode、orderReceivingTime、departureTime、commercialContractNumber、contractNumber、mileage +• consignorInfo（托运人信息）：consignor、consignorId、frameContractNumber、placeOfLoading、loadingLongitude、loadingLatitude、loadingCountrySubdivisionCode +• consigneeInfo（收货方信息）：consignee、consigneeId、goodsReceiptPlace、unLoadingLongitude、unLoadingLatitude +• driverInfo（司机信息）：driverName、drivingIdNumber、drivingLicense、issuingOrganizations、qualificationCertificate、qualificationCertificateFrom、qualificationCertificateTo、taxRegistrationCertificate、telephone、validPeriodFrom、validPeriodTo、vehicleClass、provinceCode +• carInfo（接单车辆信息）：vehicleNumber、vehiclePlateColorCode、LicensePlateTypeCode、vin、owner、ownerId、useCharacter、vehicleType、vehicleEnergyType、registerDate、issueDate、issuingOrganizations、vehicleTonnage、grossMass、roadTransportCertificateNumber、trailerVehiclePlateNumber、vehicleLicenseNumbe、roadTransportSocialCreditFrom、roadTransportSocialCreditTo +• goodsInfos（货物信息，可多条）：descriptionOfGoods、cargoTypeClassificationCode、quantity、unit +• insuranceInformation（保险信息，可选）：policyNumber、insuranceCompany +3.2 第二次上报字段（打款完成） +新增字段说明： +• 收款人（自定义扩展字段）：对应资金流水中的收款方名称recipient) +• 收款账号（自定义扩展字段）：对应资金流水中的收款账号receiptAccount) +• 收款账号类型（自定义扩展字段）：个人账户 / 对公账户，为我方自定义列 +3.3 第三次上报字段（开票完成） +核心字段： +• 发票号码（invoiceNo）：增值税发票号码 +• 发票代码（invoiceCode）：增值税发票代码 +• 发票金额（invoiceAmount）：价税合计（保留2位小数） +（注：第三次上传的invoice无税率字段，税率仅出现在ETC发票上传中） +• 销售方名称（sellerName）：开票方企业名称 +• 受票方名称（buyerName）：托运人/货主企业名称 +3.4 ETC发票字段 +核心字段： +• ETC发票号码（etcInvoiceNo）：高速公路通行费电子发票号码 +• 入口收费站（entryStation）：通行入口 +• 出口收费站（exitStation）：通行出口 +• 税额（taxAmount）：可抵扣税额（税率3%） +详细数据接口字段请查阅上报接口： +https://www.showdoc.com.cn/2210641821476236/9919735893682511 +密码：szjj@2023 +原型文件路径： +"E:\WeChat\xwechat_files\wxid_2n9ko0aq1th822_44c3\msg\file\2026-07\anhuibaba_index.html" +接口文档路径："E:\Downloads\网货企业端接口文档（最新）.pdf" diff --git a/output/versions/安徽运八需求/v5/normalized_inputs/requirement_restructured.md b/output/versions/安徽运八需求/v5/normalized_inputs/requirement_restructured.md new file mode 100644 index 0000000..c8cf57e --- /dev/null +++ b/output/versions/安徽运八需求/v5/normalized_inputs/requirement_restructured.md @@ -0,0 +1,584 @@ +# 安徽运八需求（以API文档为准重构） + +> **重构原则**: API接口文档(网货企业端接口文档 V1.0.2) 为查询+申诉权威数据源，Showdoc文档为上报接口字段定义权威数据源。HTML原型为UI参考，原始需求文档为业务背景补充。 +> **重构时间**: 2026-07-13（最后更新: 2026-07-14，根据14项确认决议） +> **原始需求**: `source_docs/requirements_raw/安徽运八需求.docx` +> **API文档（查询+申诉）**: `E:\Downloads\网货企业端接口文档（最新）.pdf` V1.0.2 (2023-04) +> **Showdoc文档（上报接口·权威字段定义）**: `output/prototype/showdoc文档.md` +> **原型**: `anhuibaba_index.html` + +--- + +## 一、系统边界 + +本需求涉及两套系统的对接： + +| 系统 | 职责 | 本文档覆盖 | +|:---|:---|:---| +| **运八平台（我方）** | 自动触发三阶段上报、ETC上传；查询核验结果；发起/跟踪申诉；查看上报日志 | 全量 | +| **安徽省级网络货运监测系统（省平台）** | 接收上报数据；执行核验；受理申诉并反馈 | 仅接口交互 | + +API文档覆盖的是**运八平台→省平台**的查询和申诉接口。上报触发逻辑（装货完成/打款完成/开票完成自动触发）属于运八平台内部业务逻辑，API文档中未定义上报提交接口。 + +**上报接口（5个·Showdoc权威）** 由Showdoc文档定义，是运八平台向省平台上送数据的接口，与查询+申诉API是两个独立的接口体系： + +| Showdoc上报接口 | URL | 说明 | +|:---|:---|:---| +| 上传委托合同（框架） | `/api/dataUpload/mandateContractFrame` | **前置步骤**：运单第一次上报前必须先上传框架合同 | +| 第一次上传 | `/api/dataUpload/firstUpload` | 装货完成后上报（含waybillInfo, consignorInfo, consigneeInfo, driverInfo, carInfo, goodsInfos, insuranceInformation） | +| 第二次上传 | `/api/dataUpload/secondUpload` | 打款完成后上报（含arrivalInfo, ownerStatements, carrierStatements, carrierContractInfo, ownerContractInfo, trackList） | +| 第三次上传 | `/api/dataUpload/thirdUpload` | 开票完成后上报（含invoice, oilGasInvoices） | +| ETC发票上传 | `/api/dataUpload/etcInvoiceUpload` | 税务抵扣确认后上传（含shippingNoteNumber, vehicleNumber, vehiclePlateColorCode, etcInvoices） | +| 修改第一次上报部分字段 | `/api/dataUpload/updateFirstUploadParam` | 第一次上报成功后更新变化字段 | + +> **关键区分**: Showdoc的5个上报接口 + updateFirstUploadParam 是**数据上报**通道；PDF文档的9个接口是**查询+申诉**通道。两者共同构成运八平台的完整对接方案。 + +--- + +## 二、API接口清单（权威来源：接口文档 V1.0.2） + +### 2.1 通用规范 + +| 项目 | 规范 | +|:---|:---| +| 基地址 | `http://*******/api/` | +| 协议 | HTTP POST | +| 请求格式 | JSON（除上传文件接口外） | +| 响应格式 | `{"code":200, "message":"操作成功", "data":{}}` | +| 认证 | JWT Token，调用 `/sys/login` 获取，除登录接口外均需在请求头携带 | +| 时间格式 | `yyyy-MM-dd HH:mm:ss` | +| 成功码 | `code=200` | +| 失败码 | `code=500` | + +### 2.2 接口一览（共9个） + +| # | 接口 | URL | 说明 | +|:---:|:---|:---|:---| +| 1 | 获取token | `POST /sys/login` | JWT认证，参数: loginName, loginPassword | +| 2 | 上传申诉附件 | `POST /appeal/uploadFile` | 文件上传，参数: file (File) | +| 3 | 提交申诉运单 | `POST /appeal/insert` | 发起申诉，参数: freightSheetNumber, complaintNumber, attachmentUrl, content, verificationAbnormalItems | +| 4 | 查询异常运单信息 | `POST /verificationSummary/page` | 分页查询，支持多维度筛选 | +| 5 | 查询申诉进度 | `POST /appeal/page` | 分页查询申诉记录及审核结果 | +| 6 | 查询运单核验详情 | `POST /verificationSummary/verificationDetail` | 单运单全部核验项明细 | +| 7 | 查询发票是否合规 | `POST /verificationSummary/cargoOwnerInvoiceInfo` | 判断托运人发票系统核验是否合规 | +| 8 | 运单里程核验查询 | `POST /verificationSummary/mileageVerificationInfo` | 批量查询运单里程核验状态 | +| 9 | 运单里程申诉 | `POST /mileageAppeal/insert` | 对里程核验结果发起申诉 | + +### 2.3 接口详细定义 + +#### 接口1: 获取token +``` +POST /sys/login +请求: { "loginName": "xxx", "loginPassword": "xxx" } +响应: { "code": 200, "data": { "token": "...", "expireTime": 1681219619843, "loginName": "ceshi", "name": "测试" } } +``` + +#### 接口2: 上传申诉附件 +``` +POST /appeal/uploadFile +请求: multipart/form-data, 字段 file (File) +``` + +#### 接口3: 提交申诉运单 +``` +POST /appeal/insert +请求: + freightSheetNumber String 运单号 必填 + complaintNumber String 申诉编号 必填 + attachmentUrl String 申诉附件URL 必填 + content String 申诉内容 必填 + verificationAbnormalItems String 核验异常项ID 必填 (逗号分隔，如"120,160") +``` + +#### 接口4: 查询异常运单信息 +``` +POST /verificationSummary/page +请求: + pageIndex int 页码 必填 + pageSize int 每页条数 必填 + freightSheetNumber String 运单号 可选 + verificationAbnormalItems String 异常项ID 可选 (多个逗号拼接) + driverName String 驾驶员姓名 可选 + driverIdCard String 驾驶员身份证号 可选 + vehicleNumber String 车牌号 可选 + appealStateId int 申诉状态ID 可选 + verifyStateId int 核验状态ID 可选 + beginTime ~ endTime 运单创建时间范围 可选 + beginFirstVerifyTime ~ endFirstVerifyTime 首次核验时间范围 可选 + beginLastVerifyTime ~ endLastVerifyTime 最新核验时间范围 可选 + beginInsertTime ~ endInsertTime 插入时间范围 可选 + +响应: + pageRecords[]: + freightSheetNumber String 运单号 + appealStateId int 申诉状态ID + appealStateName String 申诉状态名称 + verificationAbnormalItem String 核验异常项 + createTime date 运单创建时间 + lastVerifyTime date 最新核验时间 + firstVerifyTime date 首次核验时间 + vehicleNumber String 车牌号 + driverName String 驾驶员姓名 + driverIdCard String 驾驶员身份证号 + verifyStateId int 核验状态ID + verifyStateName String 核验状态名称 + abnormalDetails[]: + id int 异常项ID + name String 异常项名称 + message String 异常原因 + time date 异常时间 + state int 异常项处理状态 (100=未申诉, 110=申诉中) +``` + +#### 接口5: 查询申诉进度 +``` +POST /appeal/page +请求: + pageIndex int 页码 必填 + pageSize int 每页条数 必填 + freightSheetNumber String 运单号 可选 + abnormalTypeId String 核验异常项ID 可选 + auditStateId String 审核状态ID 可选 + beginTime ~ endTime 申诉时间范围 可选 + auditBeginTime ~ auditEndTime 审核时间范围 可选 + complaintNumber String 申诉编号 可选 + +响应: + pageRecords[]: + complaintNumber String 申诉编号 + freightSheetNumber String 运单号 + content String 申诉内容 + complainantName String 申诉人 + auditStateId int 审核状态ID + auditStateName String 审核状态名称 + auditorName String 审核人 + auditRemark String 审核备注 + auditTime date 审核时间 + verificationAbnormalItem String 运单异常项 + cancelPerson String 取消人 + cancelReason String 取消原因 + cancelTime date 取消时间 + revokeUserName String 撤回人 + revokeTime date 撤回时间 + createTime date 创建时间 + appealAbnormalList[]: + verificationTypeId int 异常项ID + verificationTypeName String 异常项名称 +``` + +#### 接口6: 查询运单核验详情 +``` +POST /verificationSummary/verificationDetail +请求: + freightSheetNumber String 运单号 必填 + beginInsertTime String 插入时间-开始 可选 + endInsertTime String 插入时间-结束 可选 + +响应: + pageRecords[].details[]: + verificationCode int 核验项编码 + verificationName String 核验项名称 + verificationState String 核验状态 + verificationStateId int 核验状态ID + verificationTime date 核验时间 + message String 核验信息 +``` + +#### 接口7: 查询发票是否合规 +``` +POST /verificationSummary/cargoOwnerInvoiceInfo +请求: { "freightSheetNumber": "55141359" } +响应: { "isSystemVerification": true } // true=系统核验合规, false=人工判定合规 +``` + +#### 接口8: 运单里程核验查询 +``` +POST /verificationSummary/mileageVerificationInfo +请求: { "freightSheetNumberList": ["22222222", "111111"] } +响应: [ + { "verificationStateId": 110, "freightSheetNumber": "22222222", "mileage": 350.263 }, + { "verificationStateId": null, "freightSheetNumber": "4658151", "mileage": null } +] +// 注: 运单未上报里程时 verificationStateId 和 mileage 为 null +``` + +#### 接口9: 运单里程申诉 +``` +POST /mileageAppeal/insert +请求: + freightSheetNumber String 运单号 必填 + content String 申诉内容 必填 + complaintNumber String 申诉编号 必填 + mileage String 里程数 必填 +``` + +--- + +## 三、数据字典（权威来源：接口文档 §4.1~§4.5） + +### 3.1 异常项ID对照表（§4.1）— 共17项 + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 委托合同 | 托运人与承运人签订的委托运输合同核验 | +| 120 | 承运合同 | 承运人以自身名义签订的运输合同核验 | +| 130 | 实时定位 | 车辆实时定位数据核验 | +| 140 | 运单时间逻辑 | 运单各时间节点的逻辑合理性核验（如装货时间<卸货时间） | +| 150 | 车辆资质 | 车辆道路运输经营许可证有效性核验 | +| 160 | 道路运输证 | 车辆道路运输证有效期核验 | +| 170 | 驾驶证 | 驾驶员驾驶证有效性核验 | +| 180 | 从业资格证 | 驾驶员从业资格证有效期核验 | +| 190 | 车辆重复 | 同一车辆在同一时段是否存在多运单 | +| 200 | 司机重复 | 同一司机在同一时段是否存在多运单 | +| 210 | 车辆轨迹 | GPS轨迹真实性、与运单路线匹配度核验 | +| 220 | 运费收款 | 运单是否在运费收款方名下 | +| 230 | 公司统一收款 | 是否通过公司账户统一收款 | +| 240 | 集中支付 | 是否通过网络货运平台集中支付 | +| 250 | 资金流水 | 资金流水单号唯一性、金额匹配核验 | +| 260 | 发票信息 | 托运人发票信息核验（第三次上报相关） | +| 270 | 非通行车辆可开票 | 非通行车辆是否允许开具通行费发票 | + +### 3.2 运单核验状态（§4.2） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未核验 | 运单尚未被省平台核验 | +| 110 | 核验通过 | 全部核验项通过 | +| 120 | 全部异常 | 存在核验不通过的异常项 | + +### 3.3 运单部分核验状态（§4.3） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未核验 | 尚未核验 | +| 110 | 部分核验 | 部分核验项已通过，仍有待核验项 | +| 120 | 全部核验 | 全部核验项已出结果 | + +### 3.4 运单申诉状态（§4.4）— 权威枚举 + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| **100** | **未申诉** | 尚未发起申诉 | +| **110** | **审核通过** | 省平台审核通过 | +| **120** | **审核不通过** | 省平台审核驳回 | +| **130** | **已取消** | 省平台侧操作，我方只读（申诉由省平台取消，非我方可操作状态） | + +> **已取消(130)说明**: 状态130=已取消是**省平台侧直接操作**产生的状态，我方系统不提供"取消申诉"功能。运八平台只能查询到此状态，不能主动将申诉状态设为130。我方申诉状态流转不包含取消操作。 + +### 3.5 附件状态（§4.5） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未处理 | 申诉附件尚未被省平台处理 | +| 110 | 处理通过 | 附件核验通过 | +| 120 | 处理异常 | 附件核验异常 | + +--- + +## 四、功能模块（综合API文档+原型+原始需求） + +### 4.1 上报运单看板 + +**入口**: 侧边栏 → 上报运单看板 + +**统计卡片**（原型定义）: +- 异常运单数、待申诉数、申诉中数、已处理数 + +**查询条件**（综合原型+接口4请求参数）: + +| 筛选项 | 类型 | 可选值 | +|:---|:---|:---| +| 运单号/托运单号/货源单号 | 文本输入 | 模糊搜索 | +| 上报阶段 | 下拉 | 全部 / 第一次上报 / 第二次上报 / 第三次上报 | +| 核验状态 | 下拉 | 全部 / 异常 / 通过 | +| 申诉状态 | 下拉 | 全部 / 未申诉(100) / 审核通过(110) / 审核不通过(120) / 已取消(130·省平台只读) | + +**列表字段**（原型为准，15列含勾选）: +货源单号 / 运单号 / 托运单号 / 车牌号 / 司机姓名 / 上报阶段 / 托运方名称 / 核验状态 / 申诉状态 / 异常项 / 货物名称 / 合同金额 / 最新核验时间 / 操作 + +**操作按钮**: +- 异常运单: [申诉] [详情] +- 申诉中运单: [进度] [详情] +- 正常运单: [详情] + +**标签颜色**（原型CSS定义）: +- 蓝色 `.tag-blue`: 上传中、申诉中 +- 绿色 `.tag-green`: 已上传、通过、已完成、申诉通过、对公账户 +- 红色 `.tag-red`: 上传失败、异常、申诉驳回 +- 橙色 `.tag-orange`: 异常项标签、待上报 +- 灰色 `.tag-gray`: 未申诉 +- 紫色 `.tag-purple`: (预留) + +### 4.2 委托合同上传（前置步骤·Showdoc权威） + +**来源**: Showdoc接口 `POST /api/dataUpload/mandateContractFrame` + +**时机**: 在进行运单的第一次上报前，需先将委托合同（框架）通过此接口上传至省平台。 + +**说明**: +- 委托合同（框架）和委托合同**二选一**上报 +- 文件信息可暂时不传，在修改委托合同时再补充合同文件 +- 后续合同有新增或修改，再调用上传或修改接口即可 +- 目前省平台不支持单独查询合同，可在运单第一次上报后，在运单信息中查看合同 + +**核心字段**: +| 参数 | 必选 | 说明 | +|:---|:---|:---| +| contract_number | 是 | 合同编号 | +| expire_time | 是 | 合同有效期截止时间 yyyy-MM-dd | +| unified_social_credit_identifier | 可选 | 单托运企业统一社会信用代码 | +| owner_enterprise_name | 可选 | 单托运企业名称 | +| enterpriseList | 可选 | 多托运企业列表（与单托运企业互斥，都传值默认取单） | +| uploadFileInfo | 否 | 文件信息（name / url / dataList三选一） | + +### 4.3 第一次上报（装货完成） + +**触发条件**: 运单装货完成 AND 货源税源地=安徽 + +**上报数据子对象**（以接口文档字段定义为准）: + +| 子对象 | 必选/可选 | 核心字段（Showdoc权威定义） | +|:---|:---|:---| +| waybillInfo（建单信息） | 必选 | originalDocumentNumber, shippingNoteNumber, documentCreateTime(yyyyMMddHHmmss), carrier, unifiedSocialCreditIdentifier, permitNumber, businessTypeCode, goodsArrangementTypeCode, orderReceivingTime(yyyyMMddHHmmss), departureTime(yyyyMMddHHmmss), commercialContractNumber, contractNumber(可选), mileage(可选·3位小数) | +| consignorInfo（托运人信息） | 必选 | consignor, consignorId, frameContractNumber(可选), placeOfLoading, loadingLongitude(6位小数), loadingLatitude(6位小数), loadingCountrySubdivisionCode | +| consigneeInfo（收货方信息·6字段） | 必选 | consignee, consigneeId, goodsReceiptPlace, unLoadingLongitude(6位小数), unLoadingLatitude(6位小数), unLoadingNationSubdivisionCode | +| driverInfo（司机信息·15字段） | 必选 | driverName, telephone, drivingIdNumber, drivingLicense, vehicleClass, issuingOrganizations, validPeriodFrom(yyyyMMdd), validPeriodTo(yyyyMMdd), qualificationCertificate, provinceCode, qualificationCertificateFrom(可选), qualificationCertificateTo(可选), taxRegistrationCertificate(可选), registerDate(yyyyMMdd), anchoredUrl(可选·文件列表) | +| carInfo（车辆信息·20字段） | 必选 | vehicleNumber, vehiclePlateColorCode, vehicleType, LicensePlateTypeCode, owner, ownerId(可选), useCharacter, vin, issuingOrganizations, registerDate(yyyyMMdd), issueDate(yyyyMMdd), vehicleEnergyType, vehicleTonnage(Double), grossMass(Double), roadTransportCertificateNumber, trailerVehiclePlateNumber(可选), vehicleLicenseNumber(可选), roadTransportSocialCreditFrom(可选·yyyyMMdd), roadTransportSocialCreditTo(可选·yyyyMMdd), anchoredUrl(可选·文件列表) | +| goodsInfos（货物信息） | 必选，可多条 | descriptionOfGoods, cargoTypeClassificationCode, quantity(Double), unit | +| insuranceInformation（保险信息） | 可选 | policyNumber, insuranceCompany | + +**业务规则**: +- 仅安徽税源地(省份代码=34，非28)运单触发 +- 上报成功后自动调用"修改第一次上报部分字段"接口更新变化字段 +- 失败自动重试最多3次，全部失败后站内信通知运营 +- 第一次上报是后续上报的前置条件（后端校验） + +**列表页**（原型为准，14列+勾选）: +货源单号 / 运单号 / 托运单号 / 车牌号 / 司机姓名 / 托运方名称 / 业务类型 / 货物名称 / 装货地址 / 卸货地址 / 运输里程 / 合同编号 / 上报状态 / 操作 + +**上报状态**（内部系统状态，非API枚举）: +- 上传中（蓝色） +- 已上传（绿色） +- 上传失败（红色）— 显示"手动上传"按钮 +- 异常（橙色） + +### 4.4 第二次上报（打款完成） + +**触发条件**: 财务打款完成 AND 第一次上报已完成 + +**核验项**: 省平台自动核验，共17项（见§3.1）。每项独立产生核验结果，核验异常项可通过申诉机制逐项申诉。 + +**上报数据子对象**（Showdoc权威·第二次上传结构完全不同）: +| 子对象 | 必选/可选 | 核心字段 | +|:---|:---|:---| +| arrivalInfo（运抵信息） | 必选 | shippingNoteNumber, startTicketFileUrl(文件列表), arrivalTime(yyyyMMddHHmmss), arrivalTicketFileUrl(文件列表), waybillFreightAmount(Double·3位小数·承运运费), totalMonetaryAmount(Double·3位小数·委托运费) | +| ownerStatements（货主流水） | 必选 | documentNumber, carrier, actualCarrierId, paymentMeansCode, paymentName, paymentAccount, paymentBankName(选填), recipient, receiptAccount, receiptBankName(选填), sequenceCode, monetaryAmount(Double·3位小数), appointmentTime(yyyyMMdd), payTime(yyyyMMddHHmmss) | +| carrierStatements（承运人流水） | 必选 | documentNumber, carrier, actualCarrierId, paymentMeansCode, paymentName, paymentAccount, paymentBankName, recipient, receiptIdCard, receiptAccount, receiptBankName, sequenceCode, monetaryAmount(String·3位小数), appointmentTime(yyyyMMdd), payTime(yyyyMMddHHmmss), oilCardAmount(选填·3位小数), replaceAgreementFiles(可选·代收协议文件) | +| carrierContractInfo（承运合同） | 必选 | contractBusinessName, contractNumber, partyAName, partyAId, partyBName, partyBId, contractedCarryingCapacity(Double·3位小数), unit, contractAmount(Double·3位小数), agreedBusinessCompletionTime(yyyyMMdd), promisePayTime(yyyyMMdd), partyBReceiptName, partyBAccount, bankName(否), placeOfLoading, goodsReceiptPlace, descriptionOfGoods, vehicleNumber, contractSigningTime(yyyyMMddHHmmss), contractUrl(文件列表) | +| ownerContractInfo（委托合同） | 可选 | 18字段（委托合同与框架合同二选一上报） | +| trackList（车辆轨迹） | 必选，2~2000点 | locationMethod(BD/LBS/WECHAT/APP), locationTime(yyyyMMddHHmmss), locationAddress, longitude(6位小数), latitude(6位小数), trackType(LOADING/UNLOADING/NORMAL·可选) | + +**列表页**（原型为准，17列+勾选）: +货源单号 / 运单号 / 托运单号 / 车牌号 / 司机姓名 / 托运方名称 / 承运运费 / 总金额 / 付款方式 / 付款时间 / 收款人 / 收款账号 / 收款账号类型 / 核验状态 / 异常项 / 上报状态 / 操作 + +**收款账号类型标签**: 个人账户=蓝色, 对公账户=绿色 + +### 4.5 第三次上报（开票完成） + +**触发条件**: 发票开具完成 AND 第二次上报已完成 + +**前置条件**: 第二次上报必须完成（后端校验） + +**API关联接口**: +- `POST /verificationSummary/cargoOwnerInvoiceInfo` — 查询托运人发票系统核验是否合规 +- 响应: `isSystemVerification`: true=系统核验合规, false=人工判定合规 + +**列表页**（原型为准，15列+勾选）: +货源单号 / 运单号 / 托运单号 / 发票号码 / 发票金额 / 税率 / 销售方名称 / 受票方名称 / 开票日期 / 油气票张数 / 核验状态 / 异常原因 / 上报状态 / 操作 + +### 4.6 ETC发票上传 + +**触发条件**: ETC发票税务抵扣成功后，由运营人员在运八系统**手动确认抵扣完成**，确认后系统触发ETC发票上传（非自动触发） + +**列表页**（原型为准，10列+勾选）: +货源单号 / 运单号 / 托运单号 / ETC发票号 / 交易金额 / 入口收费站 / 出口收费站 / 交易时间 / 上传状态 / 操作 + +**详情弹窗字段**（原型为准）: +- 运单信息: 运单号、货源单号、托运单号、车牌号、司机姓名、托运方名称、收货方名称 +- ETC发票信息: ETC发票号码、ETC发票代码、交易金额、税率(3%)、发票金额(不含税)、税额、入口收费站、出口收费站、交易时间、发票状态 + +### 4.7 异常申诉功能 + +**关联API接口**: +- `POST /appeal/uploadFile` — 上传申诉附件 +- `POST /appeal/insert` — 提交申诉 +- `POST /appeal/page` — 查询申诉进度 +- `POST /mileageAppeal/insert` — 里程申诉（独立接口） + +**申诉流程**（闭环）: +``` +异常运单查询(接口4) → 发起申诉(接口3) → 省平台复核 → +查询申诉进度(接口5) → 审核通过(110) | 审核不通过(120) → +重新申诉(接口3) [审核不通过时] +``` + +**申诉状态流转**（以API §4.4为准，我方可控流转）: +``` +未申诉(100) → 提交申诉 → 未申诉(100) [申诉中·abnormalDetails.state=110] +未申诉(100) → 省平台审核通过 → 审核通过(110) [终态] +未申诉(100) → 省平台审核驳回 → 审核不通过(120) → 重新申诉 → 未申诉(100) [新申诉单] +``` + +> **已取消(130)**: 此状态由省平台侧操作产生（如省平台管理员取消申诉），我方系统不提供触发入口，仅被动查询和展示。因此不纳入我方申诉状态流转中。 + +**列表页**（原型为准，14列+勾选）: +运单号 / 托运单号 / 车牌号 / 司机姓名 / 托运方名称 / 上报阶段 / 核验状态 / 异常项 / 申诉状态 / 申诉时间 / 申诉人 / 省平台反馈结果 / 省平台反馈时间 / 操作 + +**详情弹窗分组**（原型为准）: +- 申诉信息: 申诉单号、上报阶段、异常项、申诉原因、申诉状态、申诉时间、申诉人、申诉附件 +- 运单信息: 运单号、托运单号、车牌号、司机姓名、托运方名称 +- 异常信息: 核验状态、异常原因、异常时间 +- 省平台反馈信息: 反馈状态、反馈时间、反馈结果、反馈意见 +- 处理记录（时间线）: 操作人、操作时间、操作类型、操作内容 + +### 4.8 上报日志 + +**查询条件**（原型为准）: +- 运单号/托运单号/货源单号: 模糊搜索 +- 上报阶段: 全部 / 第一次上报 / 第二次上报 / 第三次上报 / ETC上传 +- 上报结果: 全部 / 成功 / 失败 +- 时间范围: 开始时间 ~ 结束时间 + +**列表字段**（原型为准，11列）: +序号 / 货源单号 / 运单号 / 托运单号 / 上报阶段 / 上报结果 / 接口URL / HTTP状态码 / 响应时间 / 上报时间 / 操作 + +**日志详情弹窗**: 展示完整请求报文（URL/Method/Headers/Body）和响应报文（StatusCode/Headers/Body），JSON格式化展示，支持一键复制。 + +--- + +## 五、状态枚举汇总（以API文档为权威） + +### 5.1 申诉状态（API §4.4 权威） + +| Code | 名称 | 原始需求对应 | 我方可操作 | 说明 | +|:---:|:---|:---|:---:|:---| +| 100 | 未申诉 | 未申诉 + 申诉中 | 是 | 含已提交但省平台尚未审核的情况（申诉中通过 abnormalDetails[].state=110 标识） | +| 110 | 审核通过 | 申诉通过 | 否（终态） | 省平台审核通过 | +| 120 | 审核不通过 | 申诉驳回 | 否（可重新申诉） | 省平台审核驳回，可重新发起申诉 | +| 130 | 已取消 | （无） | **否·省平台只读** | 省平台侧操作取消，我方仅查询展示 | + +### 5.2 核验状态（API §4.2 权威） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未核验 | 运单尚未核验 | +| 110 | 核验通过 | 全部17项核验通过 | +| 120 | 全部异常 | 存在核验异常项 | + +### 5.3 异常项处理状态（API §4.1 子字段） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未申诉 | 该异常项尚未发起申诉 | +| 110 | 申诉中 | 该异常项已提交申诉，待审核 | + +### 5.4 上报状态（内部系统状态，非API枚举） + +| 状态 | 标签颜色 | 说明 | +|:---|:---|:---| +| 上传中 | 蓝色 | 数据正在上报中 | +| 已上传 | 绿色 | 上报成功 | +| 上传失败 | 红色 | 上报超时或错误，显示"手动上传"按钮 | +| 异常 | 橙色 | 数据校验不通过 | + +--- + +## 六、与原始需求的关键差异 + +| # | 项目 | 原始需求 | API/Showdoc（权威） | 影响 | +|:---:|:---|:---|:---|:---| +| 1 | 核验项数量 | 7类 | **17项** (API §4.1) | 测试覆盖需从14条扩展到34条 | +| 2 | 申诉状态 | 未申诉/申诉中/通过/驳回 | **未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130·省平台只读)** | 申诉状态枚举全部更新，130不纳入我方流转 | +| 3 | 申诉"进行中" | 独立状态"申诉中" | 归属于"未申诉(100)"，由abnormalDetails[].state=110标识 | 状态机变更 | +| 4 | 已取消状态 | 无 | **130=已取消·省平台操作·我方只读** | 不提供"取消申诉"按钮，仅查询展示 | +| 5 | 里程申诉 | 无 | **独立接口** `/mileageAppeal/insert` | 新增功能模块 | +| 6 | 发票合规查询 | 无 | **独立接口** `/verificationSummary/cargoOwnerInvoiceInfo` | 新增功能点 | +| 7 | 核验状态 | 通过/异常（二元） | 未核验(100)/通过(110)/全部异常(120) | 新增"未核验"初始状态 | +| 8 | 附件状态 | 无 | 未处理(100)/处理通过(110)/处理异常(120) | 新增枚举 | +| 9 | 委托合同上传 | 无 | Showdoc **mandateContractFrame** 接口 | 新增前置步骤：第一次上报前必须先上传框架合同 | +| 10 | ETC触发方式 | 税务抵扣完成（自动） | **人工手动确认抵扣完成后触发** | 需要运营人员在运八系统手动确认 | +| 11 | 金额精度 | 2位小数 | **第二次上报金额3位小数**（Showdoc） | 金额存储和校验精度变更 | +| 12 | 时间格式 | `yyyy-MM-dd HH:mm:ss` | **上报接口用 `yyyyMMddHHmmss`（14位）**（Showdoc） | 上报数据格式化逻辑变更 | +| 13 | ETC invoiceAmount | 总金额 | **不含税金额**（Showdoc） | ETC发票金额语义变更 | + +--- + +## 七、上报接口文档参考（Showdoc · 权威字段定义） + +### 7.0 Showdoc通用规范 + +| 项目 | 规范 | +|:---|:---| +| 认证方式 | MD5签名Token（请求体JSON字符串+密钥 → MD5加密），非JWT | +| 请求格式 | `{"partnerId":"xxx", "appId":"xxx", "workerId":"001", "args":{...}}` | +| 成功码 | `code=200` | +| 失败码 | `code=500` | +| 时间戳 | 13位毫秒时间戳 | + +> ⚠️ **关键差异**: Showdoc上报接口使用MD5签名Token，而查询+申诉API（PDF文档）使用JWT Token。两套认证体系独立。 + +### 7.1 字段精度关键差异（Showdoc vs 原始需求） + +以下是从Showdoc文档中发现的与原始需求/原型不一致的关键字段定义： + +| # | 字段相关 | 原始需求/原型假设 | Showdoc权威定义 | +|:---:|:---|:---|:---| +| 1 | **金额精度** | 保留2位小数 | **第二次上报金额保留3位小数**（arrivalInfo.waybillFreightAmount、totalMonetaryAmount、carrierStatements.monetaryAmount、ownerStatements.monetaryAmount、carrierContractInfo.contractAmount、contractedCarryingCapacity等均保留3位小数，如整数以.000填充） | +| 2 | **时间格式** | `yyyy-MM-dd HH:mm:ss` | **上报接口时间格式为 `yyyyMMddHHmmss`（14位）**（如documentCreateTime、orderReceivingTime、departureTime），日期字段用 `yyyyMMdd`（8位） | +| 3 | **第一次上报字段数** | consigneeInfo=5字段、driverInfo=13字段、carInfo=19字段 | Showdoc: consigneeInfo=6字段（含unLoadingNationSubdivisionCode）、driverInfo=15字段（含registerDate、anchoredUrl）、carInfo=20字段（含anchoredUrl）、goodsInfos.quantity=Double | +| 4 | **第二次上报结构** | 追加资金流水+轨迹 | Showdoc定义完全不同：arrivalInfo(含startTicketFileUrl+arrivalTicketFileUrl)+ownerStatements+carrierStatements+carrierContractInfo+ownerContractInfo(可选)+trackList；carrierStatements含oilCardAmount和replaceAgreementFiles | +| 5 | **第三次上报** | 发票17字段 | Showdoc: invoice明确17字段+invoiceUrl文件；oilGasInvoices选填 | +| 6 | **ETC发票** | invoiceAmount=发票总金额 | **invoiceAmount = 不含税金额**（not总金额!）；17个etcInvoices字段；税率格式x.x%（如3%） | +| 7 | **委托合同上传** | 未提及 | Showdoc有 `mandateContractFrame` 接口 — 之前完全遗漏！委托合同（框架）和委托合同二选一上报 | + +### 7.2 Showdoc FAQ 关键摘录 + +以下FAQ影响功能设计和测试用例设计： + +| 主题 | FAQ要点 | +|:---|:---| +| **运单不可取消/删除** | 服务平台不支持取消或删除运单，上传后不允许修改任何信息。建议企业在运单信息确认后再上传。 | +| **承运人流水核验时效** | 除承运人流水核验需等待次日银行提供数据后开始核验，其余核验项会在一至两小时内核验完成。 | +| **发票红冲流程** | 货主发票开具后需红冲：在服务平台企业端将货主发票作废，再将重新开具的发票通过第三次上传接口上传。 | +| **税率统一3%** | 承运人流水中的税率统一传3%，税额按3%计算。 | +| **油卡金额** | 在上传承运人流水时据实填写油卡金额（oilCardAmount），如一条运单存在多条承运人流水，可在任一承运人流水中填写。 | +| **委托合同（框架）上传时机** | 在进行运单第一次上报前需将框架合同通过接口上传至服务平台，后续合同有新增或修改再调用上传/修改接口。 | +| **轨迹点数** | 企业上传的轨迹点数需在2-2000之间。地址字段若无，传"-"。 | +| **核验结果查看** | 两种方式：①服务平台企业端查询；②对接服务平台异常查询接口实现在企业自有系统内查询、处理。 | +| **合规运单开票** | 运单必须上传至服务平台且核验通过后才允许开具货主发票；第二次上传完成后即可查看核验结果。 | + +--- + +## 八、待确认项（14项 → 已确认14项 ✅） + +> **更新 2026-07-14**: 以下14项已全部通过用户确认决议。方框标记为确认结果。 + +### 阻塞级（已确认） +1. ✅ **核验项展示**: API 17项核验全部展示，每项可独立申诉。analysis文档已明确。 +2. ✅ **上报接口字段定义**: Showdoc文档为权威数据源。Showdoc定义5个上报接口 + updateFirstUploadParam，与PDF的9个查询+申诉接口分离。 + +### 重要级（已确认） +3. ✅ **申诉状态"已取消(130)"**: 省平台侧操作，我方只读，不提供"取消申诉"按钮。运单不可取消/删除。 +4. ✅ **原型UI状态映射**: "待省平台反馈"和"反馈处理中"为UI层面的展示状态，对应API 未申诉(100)·申诉中。 +5. ✅ **第三次上报列表字段**: 以原型15列为准。 +6. ✅ **里程申诉与通用申诉**: 独立接口 `/mileageAppeal/insert`，与 `/appeal/insert` 分离。 +7. ✅ **发票合规查询**: 独立接口 `/cargoOwnerInvoiceInfo`，独立于申诉流程。 + +### 参考级（已确认） +8. ✅ **自动重试间隔**: 当前方案5s/15s/30s合理可用。 +9. ✅ **ETC税额**: 税率固定3%，税额按3%计算。 +10. ✅ **申诉超时告警**: 7个工作日阈值可用。 +11. ✅ **省份代码**: 安徽=34，与API文档一致。 +12. ✅ **第二次上报详情弹窗缺失轨迹**: 确认为原原型Bug，增强版原型已包含轨迹表格。 +13. ✅ **原型详情弹窗字段**: 以接口Showdoc定义为准。 +14. ✅ **ETC触发条件**: ETC发票税务抵扣成功后，由运营人员在运八系统**手动确认抵扣完成**，确认后系统触发ETC发票上传（非自动触发）。 diff --git a/output/versions/安徽运八需求/v5/snapshot_meta.json b/output/versions/安徽运八需求/v5/snapshot_meta.json new file mode 100644 index 0000000..ed783ea --- /dev/null +++ b/output/versions/安徽运八需求/v5/snapshot_meta.json @@ -0,0 +1,14 @@ +{ + "base_name": "安徽运八需求", + "version": "v5", + "snapshot_type": "full_pipeline", + "summary": [ + "manifest", + "analysis", + "relation_report", + "test_points", + "test_cases_markdown", + "excel", + "normalized_inputs" + ] +} diff --git a/output/versions/安徽运八需求/v5/安徽运八需求.json b/output/versions/安徽运八需求/v5/安徽运八需求.json new file mode 100644 index 0000000..bc57ce1 --- /dev/null +++ b/output/versions/安徽运八需求/v5/安徽运八需求.json @@ -0,0 +1,348 @@ +{ + "_meta": { + "base_name": "安徽运八需求", + "merged_zones": [ + "prepare", + "analyze", + "design", + "execute", + "review", + "monitor" + ], + "merged_at": "2026-07-13T07:31:34.880608+00:00", + "updated_at": "2026-07-13T07:31:34.881584+00:00" + }, + "prepare": { + "base_name": "安徽运八需求", + "requirement_source_file": "E:\\test\\QaAutomationHub\\source_docs\\requirements_raw\\安徽运八需求.docx", + "requirement_input_type": "docx", + "normalized_requirement_file": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求\\requirement.md", + "normalized_dir": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求", + "technical_solution_files": [], + "normalized_technical_solution_files": [], + "project_profile_file": "E:\\test\\QaAutomationHub\\knowledge_base\\00_project\\project_profile.md", + "document_confidence": { + "requirement": 0.9, + "issues": [] + }, + "activated_knowledge": { + "terminology": { + "permanent": [ + "E:\\test\\QaAutomationHub\\knowledge_base\\01_standards\\terminology.md" + ], + "optional": [] + }, + "semantic_matches": [ + { + "path": "E:\\test\\QaAutomationHub\\knowledge_base\\03_best_practices\\data_reporting_cases.md", + "score": 0.1155, + "category": "best_practice" + }, + { + "path": "E:\\test\\QaAutomationHub\\knowledge_base\\02_history\\common_missed_scenes.md", + "score": 0.0916, + "category": "history" + } + ] + }, + "knowledge_gaps": [], + "agent_notes": { + "document-parser": "解析完成，置信度 90%", + "knowledge-activator": "激活 1 常驻 + 0 可选术语" + }, + "_meta": { + "zone": "prepare", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.805524+00:00", + "status": "completed" + } + }, + "base_name": "安徽运八需求", + "requirement_source_file": "E:\\test\\QaAutomationHub\\source_docs\\requirements_raw\\安徽运八需求.docx", + "requirement_input_type": "docx", + "normalized_requirement_file": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求\\requirement.md", + "normalized_dir": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求", + "technical_solution_files": [], + "normalized_technical_solution_files": [], + "project_profile_file": "E:\\test\\QaAutomationHub\\knowledge_base\\00_project\\project_profile.md", + "document_confidence": { + "requirement": 0.9, + "issues": [] + }, + "activated_knowledge": { + "terminology": { + "permanent": [ + "E:\\test\\QaAutomationHub\\knowledge_base\\01_standards\\terminology.md" + ], + "optional": [] + }, + "semantic_matches": [ + { + "path": "E:\\test\\QaAutomationHub\\knowledge_base\\03_best_practices\\data_reporting_cases.md", + "score": 0.1155, + "category": "best_practice" + }, + { + "path": "E:\\test\\QaAutomationHub\\knowledge_base\\02_history\\common_missed_scenes.md", + "score": 0.0916, + "category": "history" + } + ] + }, + "knowledge_gaps": [], + "agent_notes": { + "execution-analyst": "等待测试结果输入", + "knowledge-curator": "等待执行分析结果" + }, + "analyze": { + "base_name": "安徽运八需求", + "analysis_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_分析.md", + "relation_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_关联与冲突.md", + "risk_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_风险评估.md", + "related_requirements": [], + "conflict_candidates_count": 0, + "conflict_summary": {}, + "risk_matrix": { + "risks": [ + { + "id": "RISK-FINANCIAL", + "category": "资损", + "keywords_matched": [ + "金额", + "支付" + ], + "likelihood": 2, + "impact": 5, + "score": 10, + "level": "P1", + "conflict_amplified": false + }, + { + "id": "RISK-AVAILABILITY", + "category": "可用性", + "keywords_matched": [ + "超时", + "重试" + ], + "likelihood": 2, + "impact": 4, + "score": 8, + "level": "P2", + "conflict_amplified": false + } + ], + "total": 2, + "p0_count": 0, + "p1_count": 1 + }, + "confirmation_gate": { + "required": false, + "reasons": [], + "pending_markers_count": 0, + "decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md", + "decision_status": "not_required", + "decision_status_label": "已确认", + "allow_export_before_confirmation": true, + "candidate_decision_files": [ + "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" + ], + "suggested_decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" + }, + "agent_notes": { + "requirement-analyzer": "识别 0 个关联需求", + "conflict-detector": "检测到 0 个冲突候选", + "risk-assessor": "识别 2 个风险项" + }, + "_meta": { + "zone": "analyze", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.855607+00:00", + "status": "completed" + } + }, + "analysis_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_分析.md", + "relation_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_关联与冲突.md", + "risk_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_风险评估.md", + "related_requirements": [], + "conflict_candidates_count": 0, + "conflict_summary": {}, + "risk_matrix": { + "risks": [ + { + "id": "RISK-FINANCIAL", + "category": "资损", + "keywords_matched": [ + "金额", + "支付" + ], + "likelihood": 2, + "impact": 5, + "score": 10, + "level": "P1", + "conflict_amplified": false + }, + { + "id": "RISK-AVAILABILITY", + "category": "可用性", + "keywords_matched": [ + "超时", + "重试" + ], + "likelihood": 2, + "impact": 4, + "score": 8, + "level": "P2", + "conflict_amplified": false + } + ], + "total": 2, + "p0_count": 0, + "p1_count": 1 + }, + "confirmation_gate": { + "required": false, + "reasons": [], + "pending_markers_count": 0, + "decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md", + "decision_status": "not_required", + "decision_status_label": "已确认", + "allow_export_before_confirmation": true, + "candidate_decision_files": [ + "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" + ], + "suggested_decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md" + }, + "design": { + "base_name": "安徽运八需求", + "strategy_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试策略.md", + "test_points_file": "E:\\test\\QaAutomationHub\\output\\test_points\\安徽运八需求_测试点.md", + "test_cases_file": "E:\\test\\QaAutomationHub\\output\\test_cases\\安徽运八需求_测试用例.md", + "test_data_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试数据.md", + "p0_required_coverage": "N/A", + "agent_notes": { + "test-strategist": "策略已生成，0 个 P0 风险需 100% 覆盖", + "testpoint-designer": "待 AI Agent 生成测试点", + "case-designer": "待 AI Agent 生成用例", + "data-builder": "测试数据模板已生成" + }, + "_meta": { + "zone": "design", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.874648+00:00", + "status": "completed" + } + }, + "strategy_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试策略.md", + "test_points_file": "E:\\test\\QaAutomationHub\\output\\test_points\\安徽运八需求_测试点.md", + "test_cases_file": "E:\\test\\QaAutomationHub\\output\\test_cases\\安徽运八需求_测试用例.md", + "test_data_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试数据.md", + "p0_required_coverage": "N/A", + "execute": { + "base_name": "安徽运八需求", + "playwright_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\playwright_tests.py", + "appium_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\appium_tests.py", + "execution_report_file": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求_执行报告.md", + "screenshots_dir": "E:\\test\\QaAutomationHub\\output\\screenshots\\安徽运八需求", + "execution_config": { + "browsers": [ + "chromium", + "firefox", + "webkit" + ], + "mobile_platforms": [ + "android", + "ios" + ], + "screenshot_on_failure": true, + "screenshot_on_step": false + }, + "agent_notes": { + "web-executor": "Playwright 脚本已生成 → E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\playwright_tests.py", + "mobile-executor": "Appium 脚本已生成 → E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\appium_tests.py", + "result-reporter": "执行报告 → E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求_执行报告.md" + }, + "_meta": { + "zone": "execute", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.877678+00:00", + "status": "completed" + } + }, + "playwright_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\playwright_tests.py", + "appium_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\appium_tests.py", + "execution_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_执行分析.md", + "screenshots_dir": "E:\\test\\QaAutomationHub\\output\\screenshots\\安徽运八需求", + "execution_config": { + "browsers": [ + "chromium", + "firefox", + "webkit" + ], + "mobile_platforms": [ + "android", + "ios" + ], + "screenshot_on_failure": true, + "screenshot_on_step": false + }, + "review": { + "base_name": "安徽运八需求", + "review_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_评审报告.md", + "coverage_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_覆盖率审计.md", + "verdict_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_质量裁决.md", + "quality_verdict": { + "verdict": "BLOCKED", + "reason": "测试用例文件尚未生成或为空", + "case_count": 0, + "min_coverage_required": 0.95, + "max_blockers_allowed": 0 + }, + "agent_notes": { + "case-reviewer": "等待用例生成", + "coverage-auditor": "覆盖率审计待 AI Agent 执行", + "quality-gatekeeper": "裁决: BLOCKED" + }, + "_meta": { + "zone": "review", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.879631+00:00", + "status": "completed" + } + }, + "review_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_评审报告.md", + "coverage_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_覆盖率审计.md", + "verdict_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_质量裁决.md", + "quality_verdict": { + "verdict": "BLOCKED", + "reason": "测试用例文件尚未生成或为空", + "case_count": 0, + "min_coverage_required": 0.95, + "max_blockers_allowed": 0 + }, + "monitor": { + "base_name": "安徽运八需求", + "execution_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_执行分析.md", + "agent_notes": { + "execution-analyst": "等待测试结果输入", + "knowledge-curator": "等待执行分析结果" + }, + "curation_suggestions": [], + "_meta": { + "zone": "monitor", + "base_name": "安徽运八需求", + "updated_at": "2026-07-13T07:31:34.880608+00:00", + "status": "completed" + } + }, + "curation_suggestions": [], + "current_excel_file": "E:\\test\\QaAutomationHub\\output\\excel_reports\\安徽运八需求_测试用例.xlsx", + "versioning_scheme": { + "current_files": "固定文件名，始终表示当前最新版", + "snapshot_rule": "仅在 export 成功且产物内容发生变化时递增版本", + "snapshot_dir_pattern": "output/versions/{BASE_NAME}/vN/" + }, + "latest_snapshot_version": "v4", + "latest_snapshot_dir": "E:\\test\\QaAutomationHub\\output\\versions\\安徽运八需求\\v4", + "latest_snapshot_type": "full_pipeline", + "maintained_requirement_file": "E:\\test\\QaAutomationHub\\requirements\\安徽运八需求.md" +} diff --git a/output/versions/安徽运八需求/v5/安徽运八需求_关联与冲突.md b/output/versions/安徽运八需求/v5/安徽运八需求_关联与冲突.md new file mode 100644 index 0000000..98f0a05 --- /dev/null +++ b/output/versions/安徽运八需求/v5/安徽运八需求_关联与冲突.md @@ -0,0 +1,16 @@ +# 安徽运八需求 关联需求与冲突检查 + +## 目标需求 +- `source_docs\requirements_raw\安徽运八需求.docx` + +## 项目画像 +- `knowledge_base\00_project\project_profile.md` + +## 关联技术方案 +- 未识别到同主题技术方案文档。 + +## 关联需求识别 +- 未识别到相似度达到阈值的历史需求文档。 + +## 潜在冲突与修改建议 +- 暂未识别到明显冲突条目。建议在需求评审时继续人工确认。 diff --git a/output/versions/安徽运八需求/v5/安徽运八需求_分析.md b/output/versions/安徽运八需求/v5/安徽运八需求_分析.md new file mode 100644 index 0000000..14618b1 --- /dev/null +++ b/output/versions/安徽运八需求/v5/安徽运八需求_分析.md @@ -0,0 +1,189 @@ +# 安徽运八需求 结构化分析 + +> 生成时间: 2026-07-13（最后更新: 2026-07-14，根据14项确认决议） +> 需求文档: source_docs/requirements_raw/安徽运八需求.docx +> 重构需求: output/normalized_inputs/安徽运八需求/requirement_restructured.md（以API文档V1.0.2为查询+申诉权威数据源，以Showdoc文档为上报接口字段定义权威数据源） +> Showdoc上报接口文档: output/prototype/showdoc文档.md（5个上报接口 + FAQ） +> 项目画像: knowledge_base/00_project/project_profile.md + +## 1. 需求背景 + +根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将税源地为安徽运八的运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八），其他税源地不走此逻辑。 + +## 2. 目标 + +实现上报流程的自动化管理，并提供异常监控与向平台发起申诉的能力。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。 + +## 3. 用户角色 + +| 角色 | 职责 | +| :--- | :--- | +| 平台运营人员 | 查看看板、发起申诉、监控上报状态 | +| 系统自动 | 自动触发三阶段上报和ETC上传 | +| 财务人员 | 打款操作（触发第二次上报） | +| 安徽监管平台 | 接收上报数据、执行核验、反馈结果 | + +## 4. 功能模块 + +### 4.1 上报运单看板 +集中展示所有上报阶段运单的汇总状态，支持按条件筛选（运单号/托运单号/货源单号模糊搜索、上报阶段、核验状态、申诉状态）、查看详情和发起申诉。 + +### 4.2 委托合同上传（前置步骤） +运单第一次上报前，需先将委托合同（框架）通过 `/api/dataUpload/mandateContractFrame`（Showdoc定义）上传至省平台。委托合同（框架）和委托合同二选一上报。合同文件可暂不传，后续通过修改接口补充。 + +### 4.3 第一次上报（装货完成） +运单装货完成后自动触发，仅上传货源税源地为安徽运八的运单。上报数据包含运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息、保险信息等。核验通过后自动调用"修改第一次上报部分字段"接口。 + +### 4.4 第二次上报（打款完成） +运费支付完成后自动触发，上报数据包含资金流水信息、车辆轨迹信息等。监管平台进行核验。⚠️ 根据网货企业端接口文档 V1.0.2 §4.1，核验项从需求描述的7类扩展为API定义的17项独立核验项：100=委托合同、120=承运合同、130=实时定位、140=运单时间逻辑、150=车辆资质、160=道路运输证、170=驾驶证、180=从业资格证、190=车辆重复、200=司机重复、210=车辆轨迹、220=运费收款、230=公司统一收款、240=集中支付、250=资金流水、260=发票信息、270=非通行车辆可开票。每项有独立的核验结果和申诉入口。 + +### 4.5 第三次上报（开票完成） +发票开具完成后触发，上报数据包含运单信息、发票信息、油气发票信息等。 + +### 4.6 ETC发票上传 +ETC发票税务抵扣成功后，由运营人员在运八系统**手动确认抵扣完成**，确认后系统触发ETC发票上传（非自动触发）。上传信息包含车牌号、车牌颜色、ETC发票号、不含税金额(invoiceAmount)、税率3%、税额、价税合计(totalPriceAndTax)、入口/出口收费站、交易时间等。 + +### 4.7 异常申诉功能 +补全"异常查询 → 发起申诉 → 跟踪监管平台反馈 → 合规判断"的完整闭环。 + +### 4.8 上报日志 +记录所有上报接口的调用记录（请求/响应报文、HTTP状态码、响应时间），用于问题排查和审计。 + +## 5. 核心规则 + +### 5.1 税源地过滤 +- 仅税源地为安徽运八的运单触发上报 +- 其他税源地（如云南=28）不触发任何上报 + +### 5.2 上报阶段依赖链 +- 第一次上报是后续两次上报的基础 +- 第二次上报依赖第一次上报完成 +- 第三次上报依赖第二次上报完成 +- 后端必须做前置状态校验（非仅前端控制） + +### 5.3 自动重试机制 +- 各阶段上报失败后自动重试（最多3次） +- 3次全部失败后告警通知运营人员 +- 重试期间禁止手动触发上传 + +### 5.4 核验规则 +- 第二次上报包含**17项独立核验**（API文档§4.1定义），比需求的7类更为细化 +- 核验异常可通过申诉机制向监管平台说明情况 +- 每项核验有独立的核验结果（verificationCode/verificationName/verificationState）和申诉入口 +- 申诉由安徽监管平台复核 + +> **核验项扩展说明（来源：API §4.1）**: 原始需求仅描述7大类核验（运单重复/车辆资质/司机资质/集中支付/资金流水/合同/轨迹合规），但API文档§4.1定义了完整的17项独立核验项（100=委托合同, 120=承运合同, 130=实时定位, 140=运单时间逻辑, 150=车辆资质, 160=道路运输证, 170=驾驶证, 180=从业资格证, 190=车辆重复, 200=司机重复, 210=车辆轨迹, 220=运费收款, 230=公司统一收款, 240=集中支付, 250=资金流水, 260=发票信息, 270=非通行车辆可开票）。每项有独立的核验结果和申诉入口，测试覆盖需从14条（7类×通过+异常）扩展到34条（17项×通过+异常）。 + +### 5.5 API接口清单（来自网货企业端接口文档 V1.0.2） + +| 接口 | URL | 方法 | 说明 | +|:---|:---|:---:|:---| +| 获取token | /sys/login | POST | JWT认证 | +| 上传申诉附件 | /appeal/uploadFile | POST | 文件上传 | +| 提交申诉运单 | /appeal/insert | POST | 发起申诉 | +| 查询异常运单信息 | /verificationSummary/page | POST | 分页查询，含abnormalDetails（17项核验明细） | +| 查询申诉进度 | /appeal/page | POST | 分页查询，含审核状态/审核人/取消/撤回 | +| 查询运单核验详情 | /verificationSummary/verificationDetail | POST | 单运单核验明细列表 | +| 查询发票合规 | /verificationSummary/cargoOwnerInvoiceInfo | POST | 判断托运人发票是否系统核验合规（需求未提及！） | +| 运单里程核验查询 | /verificationSummary/mileageVerificationInfo | POST | 批量查询运单里程核验状态 | +| 运单里程申诉 | /mileageAppeal/insert | POST | 提交里程申诉（需求未提及的新功能！） | + +### 5.6 申诉状态枚举（以API §4.4为权威） + +| Code | API名称(§4.4权威) | 原始需求对应 | 原型对应 | 我方可操作 | 说明 | +|:---:|:---|:---|:---|:---:|:---| +| 100 | **未申诉** | 未申诉 + 申诉中 | 未申诉 + 待省平台反馈 + 反馈处理中 | 是 | 含已提交但省平台尚未审核的情况（申诉"进行中"通过 abnormalDetails[].state=110 标识） | +| 110 | **审核通过** | 申诉通过 | 申诉通过 | 否（终态） | 终态 | +| 120 | **审核不通过** | 申诉驳回 | 申诉驳回 | 否（可重新申诉） | 可重新申诉 | +| 130 | **已取消** | （无） | （无） | **否·省平台只读** | 省平台侧操作取消申诉，我方系统不提供"取消申诉"功能，仅查询展示此状态 | + +> **已取消(130)专项说明**: +> - 状态130=已取消的触发在省平台侧（省平台管理员取消），非我方可操作。 +> - 我方系统**不提供"取消申诉"按钮或接口**，不测试我方主动取消申诉的用例。 +> - 申诉状态流转（我方视角）：未申诉(100) → 审核通过(110) [终态]；未申诉(100) → 审核不通过(120) → 重新申诉 → 未申诉(100)。 +> - 看板筛选下拉值以API §4.4为准（未申诉/审核通过/审核不通过/已取消），其中130仅作筛选展示。 + +### 5.7 申诉单项约束（API §3.3） + +- 接口 `POST /appeal/insert` 的 `verificationAbnormalItems` 参数说明为**"只支持单个异常项目申诉"** +- 每次申诉仅针对**一个**核验异常项 +- 同一运单有多个异常项时，需分别发起多次申诉（每项一个申诉单） +- 申诉流程必须包含**异常项单选步骤**，不允许批量勾选后一次提交 +- 传入多个异常项ID（如 `"120,160"`）时，接口应拒绝并返回错误提示 + +## 6. 数据字段（以Showdoc为权威字段定义） + +> **授权来源**: Showdoc文档（`output/prototype/showdoc文档.md`）定义上报接口字段结构。关键精度要求：上报接口时间格式为 `yyyyMMddHHmmss`（14位），第二次上报金额保留3位小数（如整数以.000填充），ETC invoiceAmount为不含税金额。 + +### 6.1 第一次上报核心字段（Showdoc: firstUpload） +- waybillInfo（建单信息）: 13字段必选（含mileage可选） +- consignorInfo（托运人信息）: 7字段必选 +- consigneeInfo（收货方信息）: 6字段必选（含unLoadingNationSubdivisionCode） +- driverInfo（司机信息）: 15字段必选（含registerDate、anchoredUrl） +- carInfo（接单车辆信息）: 20字段必选（含anchoredUrl） +- goodsInfos（货物信息）: 4字段/条必选（quantity=Double） +- insuranceInformation（保险信息）: 2字段可选 + +### 6.2 第二次上报核心字段（Showdoc: secondUpload） +- arrivalInfo（运抵信息）: 6字段必选（含startTicketFileUrl、arrivalTicketFileUrl） +- ownerStatements（货主流水）: 13字段必选（monetaryAmount=Double·3位小数） +- carrierStatements（承运人流水）: 14字段必选（含oilCardAmount·replaceAgreementFiles） +- carrierContractInfo（承运合同）: 18字段必选（含contractUrl·金额3位小数） +- ownerContractInfo（委托合同）: 18字段可选（委托合同与框架合同二选一） +- trackList（车辆轨迹）: 6字段/点必选（2~2000个点） + +### 6.3 第三次上报核心字段（Showdoc: thirdUpload） +- invoice（货主发票）: 17字段必选（含invoiceUrl文件） +- oilGasInvoices（油气发票）: 选填，可多条 + +### 6.4 ETC发票核心字段（Showdoc: etcInvoiceUpload） +- etcInvoices（ETC发票）: **17字段/张**（invoiceAmount=不含税金额·保留2位小数·税率3%） + +## 7. 状态流转 + +### 7.1 上报状态 +上传中(蓝色) → 已上传(绿色) / 上传失败(红色) / 异常(橙色) + +### 7.2 申诉状态（我方流转） +未申诉 → 申诉中 → 申诉通过 / 申诉驳回 → 重新申诉 + +> 已取消(130)由省平台侧操作，不纳入我方流转。 + +## 8. 歧义标注与待确认项（14项已全部确认 ✅） + +> **更新 2026-07-14**: 以下14项全部通过用户确认决议。方框标记为确认结果。 + +### 8.1 核验项定义差异 ✅ +> ✅ 确认: 以API文档§4.1 17项为准。17项核验全部展示，每项可独立申诉。测试点覆盖34条（17项×通过+异常）。 + +### 8.2 申诉状态枚举三版本不一致 ✅ +> ✅ 确认: 以API §4.4为准。130=已取消为省平台侧操作，我方只读不提供取消申诉功能。原型UI状态映射已确认。 + +### 8.3 第三次上报列表字段差异 ✅ +> ✅ 确认: 以原型15列为准。 + +### 8.4 看板申诉状态下拉值差异 ✅ +> ✅ 确认: 以API §4.4为准（未申诉/审核通过/审核不通过/已取消），其中130为省平台只读状态。 + +### 8.5 原型详情弹窗字段数量差异 ✅ +> ✅ 确认: 以接口Showdoc定义为准。 + +### 8.6 原型缺失车辆轨迹信息 ✅ +> ✅ 确认: 为原原型Bug。增强版原型已包含轨迹表格。 + +### 8.7 技术细节已全部确认 ✅ +> ✅ 待确认7: 自动重试间隔5s/15s/30s可用。 +> ✅ 待确认8: ETC税率统一3%，税额按3%计算。 +> ✅ 待确认9: 申诉超时告警阈值7个工作日可用。 +> ✅ 待确认10: 安徽=34与云南=28逻辑隔离，无冲突。 +> ✅ 待确认11: **Showdoc文档已读取**，字段定义以Showdoc为权威（金额3位小数，时间yyyyMMddHHmmss格式，ETC invoiceAmount=不含税金额，委托合同上传mandateContractFrame为前置步骤）。 +> ✅ 待确认12: 里程申诉接口 /mileageAppeal/insert 为独立接口，纳入本期范围。 +> ✅ 待确认13: ETC发票不含税金额(invoiceAmount)需在测试用例中体现。 +> ✅ **新增**: ETC触发条件确认 — 税务抵扣成功后由运营人员人工确认，非自动触发。 + +## 9. 项目差异化约束 + +- 省份代码: 安徽=34（非云南=28） +- 该需求为新增模块，与现有云南上报逻辑隔离 +- 测试环境管理端: https://ybxcx.ynyun8.com:8000/admin +- 支付方式: arpa_2（云企付二期） diff --git a/output/versions/安徽运八需求/v5/安徽运八需求_测试点.md b/output/versions/安徽运八需求/v5/安徽运八需求_测试点.md new file mode 100644 index 0000000..7322cda --- /dev/null +++ b/output/versions/安徽运八需求/v5/安徽运八需求_测试点.md @@ -0,0 +1,1216 @@ +# 安徽运八需求 测试点 + +> 生成时间: 2026-07-13 +> 需求文档: output/normalized_inputs/安徽运八需求/requirement.md +> 关联分析: 风险评估报告 / 测试策略 / 关联与冲突 + +## 测试点概览 + +- 总测试点数: 140 +- P0: 33 / P1: 71 / P2: 30 / P3: 6 +- 模块分布: A(看板)=14, B(第一次上报)=22, C(第二次上报)=51, D(第三次上报)=12, E(ETC)=9, F(申诉)=16, G(日志)=9, X(跨模块)=7 +- 来源分布: [需求] 66, [历史缺陷] 14, [风险矩阵] 8, [漏测清单] 52, [项目画像] 16, [最佳实践] 7, [技术方案] 36 + +> 注: 一个测试点可同时归属多个来源，因此来源分布合计数 > 总测试点数。 + +--- + +## 模块A: 上报运单看板 (14个测试点) + +### TP-A-001: 看板模糊搜索 — 运单号/托运单号/货源单号 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证看板支持按运单号、托运单号、货源单号进行模糊搜索，输入部分字符即可匹配相关运单。 +- 关键验证点: 输入完整单号可精确匹配；输入部分字符可模糊匹配；输入不存在的单号显示空结果提示；三种单号输入框均支持模糊搜索。 + +### TP-A-002: 看板按上报阶段筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证看板支持按"全部/第一次上报/第二次上报/第三次上报"筛选，切换阶段后列表数据正确过滤。 +- 关键验证点: 默认"全部"显示所有阶段运单；选择"第一次上报"仅显示对应阶段运单；切换阶段后列表即时刷新；各阶段数据条数与实际一致。 + +### TP-A-003: 看板按核验状态筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证看板支持按"全部/异常/通过"筛选核验状态，确保状态拆分独立验证。 +- 关键验证点: "全部"显示所有核验状态运单；"异常"仅显示核验不通过的运单；"通过"仅显示核验通过的运单；列表中核验状态字段与筛选条件一致。 + +### TP-A-004: 看板按申诉状态筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证看板支持按"全部/未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130)"筛选申诉状态。注：已取消(130)由省平台外部操作设置，我方系统只读展示，不发起取消操作。⚠️ 待确认: 原型看板申诉状态下拉值为"未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回"，与API权威枚举不一致，需确认UI最终版本。 +- 关键验证点: 四种申诉状态独立筛选，数据精确匹配；切换申诉状态后核验状态筛选联动正确；申诉状态标签展示与筛选值一致；已取消(130)状态为省平台侧操作结果，我方仅展示。 + +### TP-A-005: 看板组合筛选 — 多条件叠加 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [需求][漏测清单] +- 描述: 验证看板支持上报阶段 + 核验状态 + 申诉状态 + 模糊搜索同时组合筛选。 +- 关键验证点: 选择"第二次上报+异常+未申诉(100)"组合后精确过滤；组合条件为空结果时友好提示；组合条件切换不丢失已输入的单号搜索关键字。 + +### TP-A-006: 看板导出功能 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][项目画像] +- 描述: 验证看板支持将当前筛选结果导出为 Excel 文件，大数据量导出正常。 +- 关键验证点: 导出文件包含全部列表字段；导出数据与当前筛选条件一致；大数据量（≥2000条）导出不超时、不OOM；导出的 Excel 文件可正常打开和解析。 + +### TP-A-007: 看板重置查询条件 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证点击"重置"按钮后，所有查询条件恢复默认值，列表刷新为初始全部数据。 +- 关键验证点: 模糊搜索输入框清空；下拉筛选恢复"全部"；列表数据恢复为默认全部运单；重置后分页回到第1页。 + +### TP-A-008: 看板列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证看板列表展示的14个字段完整且顺序与需求一致：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、申诉状态、异常项、货物名称、合同金额、最新核验时间、操作。 +- 关键验证点: 每个字段均有数据且格式正确；异常项为空时合理展示（如"-"或留空）；合同金额保留2位小数；最新核验时间为合理时间格式。 + +### TP-A-009: 看板状态标签颜色映射 +- 优先级: P2 +- 类型: UI测试 +- 覆盖维度: 数据校验 +- 来源: [漏测清单] +- 描述: 验证上报阶段不同状态对应的标签颜色是否正确（蓝色=上传中、绿色=已上传/通过、红色=上传失败/审核不通过、橙色=异常）。 +- 关键验证点: 每一种状态颜色独立验证；蓝色/绿色/红色/橙色与实际需求一致；申诉状态标签（未申诉灰色/审核通过绿色/审核不通过红色）颜色区分清晰。 + +### TP-A-010: 看板操作按钮 — 申诉/进度/详情 入口 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证看板操作列中"申诉""进度""详情"按钮根据运单当前状态正确显示/隐藏，点击后正确跳转。 +- 关键验证点: 仅异常运单显示"申诉"按钮；所有运单显示"详情"按钮；"进度"按钮展示上报阶段进度；点击后路由跳转正确，携带正确的运单ID参数。 + +### TP-A-011: 看板详情弹窗 — 分组字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证看板点击"详情"后弹窗内容完整，按子对象分组展示，各分组字段不缺失。 +- 关键验证点: 建单信息分组13字段完整；托运人信息7字段完整；收货方信息5字段完整；司机信息13字段完整；车辆信息19字段完整；货物信息支持多条展示；可选字段为空时展示合理。 + +### TP-A-012: 看板空数据状态 +- 优先级: P3 +- 类型: UI测试 +- 覆盖维度: 边界条件 +- 来源: [漏测清单] +- 描述: 验证看板在无运单数据时的空状态展示（如新部署环境或筛选无结果）。 +- 关键验证点: 空状态有友好的占位提示图文；筛选无结果时明确提示"未找到匹配数据"；空状态不出现控制台报错或页面崩溃。 + +### TP-A-013: 看板分页和默认排序 +- 优先级: P3 +- 类型: UI测试 +- 覆盖维度: 边界条件 +- 来源: [漏测清单] +- 描述: 验证看板列表分页功能正常（翻页、每页条数切换），默认按最新核验时间倒序排列。 +- 关键验证点: 翻页后数据不重复不遗漏；切换每页条数后分页重新计算；数据更新后排序即时反映；总条数与数据库一致。 + +### TP-A-014: 看板角色权限控制 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 权限控制 +- 来源: [项目画像] +- 描述: 验证不同角色（运营/财务/客服/车队长/司机）对看板的访问权限和数据可见范围。 +- 关键验证点: 运营人员可见全部运单；财务人员可见打款相关字段；客服人员仅可见其负责范围的运单；车队长和司机不可见平台端看板；越权访问被正确拦截。 + +--- + +## 模块B: 第一次上报-装货完成 (22个测试点) + +### TP-B-001: 装货完成后自动触发第一次上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证运单装货完成后，系统自动触发第一次上报，上报数据包含全部必选子对象（运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息）。 +- 关键验证点: 装货完成事件触发上报；上报请求包含全部7个子对象；各子对象必选字段完整；上报接口收到正确的JSON结构；上报成功后状态变为"已上传"（绿色标签）。 + +### TP-B-002: 仅安徽税源地运单触发上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][项目画像] +- 描述: 验证货源税源地为非安徽的运单（如云南=28）装货完成后不会触发第一次上报。 +- 关键验证点: 税源地为云南(28)的运单不触发上报；税源地为其他省份的运单不触发上报；不触发时无错误日志或告警；仅税源地为安徽(34)的运单触发上报。 + +### TP-B-003: 第一次上报数据字段格式校验 — 建单信息 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证第一次上报的建单信息(waybillInfo)13个字段的格式、类型、长度符合接口规范，可选字段（委托合同编号、运输里程）为空时正常上报。 +- 关键验证点: 必选字段缺失时上报拒绝并明确提示；统一社会信用代码格式校验（18位）；业务类型代码/运输组货方式代码为有效枚举值；运输里程为合理数值范围；经纬度为合法浮点数范围；时间字段使用 yyyyMMddHHmmss（14位）格式，如 documentCreateTime、orderReceivingTime、departureTime。 + +### TP-B-004: 省份代码动态获取 — 安徽=34 非云南=28 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 数据校验 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-04：验证司机信息中的省份代码(provinceCode)根据上报目标省份动态读取配置，安徽省使用代码"34"而非项目默认值云南省代码"28"。 +- 关键验证点: 安徽运八上报的省份代码为"34"；不同省份配置隔离，云南=28、安徽=34 各自独立；修改省份配置后无需重启服务即可生效；数据库/Redis中无硬编码省份代码；装货地行政区划代码前2位=34（安徽省代码）。 + +### TP-B-005: 后端校验 — 第一次上报是第二/三次上报的前置条件 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-01：验证第一次上报失败后，后端接口层面拒绝第二次和第三次上报请求，返回明确错误码"前置上报未完成"。前端+后端双重拦截。 +- 关键验证点: 第一次上报失败时调用第二次上报接口返回错误；错误码明确标识"前置上报未完成"；后端通过查询运单上报状态表做校验，非前端布尔值；第一次上报重试3次全失败后第二次上报仍被拒绝；第三次上报同理，第二次上报失败时被拒绝。 + +### TP-B-006: 第一次上报成功后自动调用"修改字段"接口 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证监管平台核验通过后，系统自动调用"修改第一次上报部分字段"接口，更新装货后可能变化的字段（如实际里程）。 +- 关键验证点: 核验通过后自动触发修改接口；修改的字段为装货后变化字段（实际里程等）；修改成功后状态仍为"已上传"；修改接口调用记录出现在上报日志中；若修改失败有重试机制和告警。 + +### TP-B-007: 第一次上报自动重试 — 最多3次 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [需求] +- 描述: 验证第一次上报失败后系统自动重试，最多3次，重试间隔递增。 +- 关键验证点: 第1次失败后自动触发第2次重试；重试间隔合理递增（如5s/15s/30s）；第3次仍失败后标记为"上传失败"（红色标签）并停止重试；每次重试均记录到上报日志；重试次数不超过3次。 + +### TP-B-008: 第一次上报全部重试失败后通知运营人员 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证第一次上报3次自动重试全部失败后，系统通过站内信或其他方式通知运营人员。 +- 关键验证点: 3次重试失败后立即触发通知；通知内容包含运单号、失败原因、失败时间；站内信有明确的"上报失败"标记；运营人员可在通知中直接跳转到对应运单详情页。 + +### TP-B-009: 第一次上报手工上传 — 上传失败后手动触发 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证运单上报状态为"上传失败"（红色标签）时，运营人员可点击"手动上传"按钮重新发起上报。 +- 关键验证点: 仅"上传失败"状态显示"手动上传"按钮；点击后发起新的上报请求；手动上传成功后状态变为"已上传"（绿色）；手动上传同样记录到上报日志。 + +### TP-B-010: 第一次上报状态标签颜色校验 +- 优先级: P2 +- 类型: UI测试 +- 覆盖维度: 数据校验 +- 来源: [漏测清单] +- 描述: 验证四种上报状态对应的标签颜色：上传中=蓝色、已上传=绿色、上传失败=红色、异常=橙色。 +- 关键验证点: 每种状态颜色独立验证，不与需求描述偏离；上传中状态显示蓝色标签和加载动画；状态切换时标签颜色即时更新；颜色在亮色/暗色主题下均可辨识。 + +### TP-B-011: 第一次上报详情弹窗 — 建单信息字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验收详情弹窗中"建单信息"分组的13个字段全部展示，数据取值来源正确。 +- 关键验证点: 上游企业委托运输单号、本运单单号、托运人建单时间、网络货运经营者名称、统一社会信用代码、道路运输经营许可证编号、业务类型代码、运输组货方式代码、司机接单时间、司机起运时间、承运合同编号（必选）共11字段有值；委托合同编号和运输里程为可选字段，为空时合理展示。 + +### TP-B-012: 第一次上报详情弹窗 — 托运人/收货方/司机/车辆/货物/保险子对象字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证详情弹窗中各子对象字段完整且按分组展示：托运人信息7字段、收货方信息5字段、司机信息13字段、车辆信息19字段、货物信息4字段（可多条）、保险信息2字段（可选）。 +- 关键验证点: 托运人统一社会信用代码格式正确；收货方身份证号脱敏展示（如适用）；司机从业资格证有效期起止日期格式正确；车辆VIN码(17位)正确显示；货物支持多条记录展开；保险单号为可选字段，无保险时合理展示。 + +### TP-B-013: 第一次上报详情弹窗 — 异常信息展示 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证详情弹窗中"异常信息"分组包含核验状态、异常原因、异常时间、处理状态4个字段。 +- 关键验证点: 核验通过时异常原因为空；核验异常时异常原因描述清晰可理解；异常时间为实际核验时间；处理状态与申诉模块数据联动。 + +### TP-B-014: 第一次上报幂等性 — 防止重复上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-02：验证同一运单同一上报阶段在短时间内不能重复上报。自动重试期间手动触发上传时，系统检测到上报进行中并拒绝重复提交。 +- 关键验证点: 自动重试进行中点击"手动上传"返回"上报处理中"提示并拒绝；同一运单同一阶段1分钟内只能有1条成功上报记录；使用分布式锁或幂等键控制并发；快速连续点击"手动上传"按钮仅发起1次请求（前端防抖）；后端数据库层面唯一约束防重。 + +### TP-B-015: 第一次上报接口超时处理 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [漏测清单][风险矩阵] +- 描述: 验证第一次上报接口调用超时后的处理逻辑（超时归类为上报失败，触发重试）。 +- 关键验证点: 监管平台接口超时(>30s)后转为"上传失败"状态；超时状态下触发自动重试；超时不导致数据不一致或重复写入；超时时有 Loading 状态提示；前端页面超时后有友好提示。 + +### TP-B-016: 第一次上报弱网环境处理 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [漏测清单] +- 描述: 验证在弱网环境（高延迟、高丢包率）下，第一次上报的重试机制正常工作。 +- 关键验证点: 弱网下请求发送成功但响应延迟时不会立即判定失败；超时阈值合理（建议30s）；弱网恢复后重试成功则状态正常流转；断网时上报请求发送失败的提示友好。 + +### TP-B-017: 第一次上报并发触发 — 多运单同时装货完成 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 +- 来源: [项目画像][最佳实践] +- 描述: 验证多个运单同时装货完成时，第一次上报并发处理，各运单上报互不干扰。 +- 关键验证点: 10个运单同时装货完成，各自独立触发上报；并发上报不产生数据库死锁；各运单上报记录正确隔离；并发上报后上报日志完整记录每个运单的请求。 + +### TP-B-018: 第一次上报可选字段空值处理 +- 优先级: P3 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [漏测清单] +- 描述: 验证各子对象中的可选字段（委托合同编号、运输里程、挂车牌照号、行驶证档案编号、道路运输证有效期起/至、保险单号、保险公司名称）为空时，上报接口正常处理。 +- 关键验证点: 可选字段为空时上报不报错；JSON 中可选字段不传或传 null 均可正常处理；详情弹窗中可选字段为空时显示"-"或"N/A"等占位符，不显示"null"或"undefined"。 + +### TP-B-019: 第一次上报货物信息多条记录 +- 优先级: P3 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [需求][漏测清单] +- 描述: 验证当运单包含多种货物时，货物信息(goodsInfos)数组支持多条记录上报，每条包含货物名称、货物类型代码、货物量、计量单位。 +- 关键验证点: 支持1条货物记录；支持多条（如5条）货物记录；每条货物信息独立完整；详情弹窗支持展开/折叠多条货物记录；货物类型代码与数据字典一致。 + +### TP-B-020: 第一次上报列表字段完整性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证第一次上报列表展示的字段完整且与需求一致，包括货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、业务类型、货物名称、装货地址、卸货地址、运输里程、合同编号、上报状态、操作共14个字段。 +- 关键验证点: 列表表头与需求一致性；14个字段均正确展示且顺序符合设计；业务类型与数据字典一致；装货地址和卸货地址完整展示；运输里程带单位（km）；上报状态标签颜色映射正确（上传中=蓝色/已上传=绿色/上传失败=红色/异常=橙色）。 + +### TP-B-021: 委托合同（框架）上传 — 第一次上报前置条件 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 状态流转 +- 来源: [技术方案] +- 描述: 验证在进行运单的第一次上报前，需要先通过 POST /api/dataUpload/mandateContractFrame 接口将委托合同（框架）上传至服务平台；未上传委托合同时第一次上报应被拒绝。 +- 关键验证点: 未上传委托合同时触发第一次上报被拒绝，返回明确错误提示；委托合同（框架）上传成功后第一次上报可正常进行；委托合同字段（contract_number合同编号、expire_time有效期截止日yyyy-MM-dd）必填校验；uploadFileInfo字段可选，可在修改委托合同时补充。 + +### TP-B-022: 委托合同与委托合同（框架）二选一上报 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [技术方案] +- 描述: 验证委托合同（框架）和委托合同二选一进行上报：单个货主企业使用 unified_social_credit_identifier 字段；多家货主企业使用 enterpriseList 数组关联。若两者都传值，默认取单托运企业(unified_social_credit_identifier)。 +- 关键验证点: 仅传 unified_social_credit_identifier（单企业）时正常上报；仅传 enterpriseList（多企业列表）时正常上报，列表中每项含 unified_social_credit_identifier 和 owner_enterprise_name；两者都传时默认取单企业；两者都不传时接口返回错误。 + +--- + +## 模块C: 第二次上报-打款完成 (51个测试点) + +### TP-C-001: 打款完成后自动触发第二次上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证运单运费支付（财务打款）完成后，系统自动触发第二次上报，上报数据包含资金流水信息和车辆轨迹信息。 +- 关键验证点: 财务打款完成回调触发上报；上报请求包含运单信息+资金流水+车辆轨迹；上报成功后状态更新；第二次上报仅对已完成第一次上报的运单触发。 + +### TP-C-002: 第二次上报资金流水数据来源于支付流水表 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 数据校验 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-03：验证第二次上报的资金流水数据（支付金额、支付方式、支付时间、流水号等）从支付流水表实时读取，而非使用运单缓存中的合同金额。 +- 关键验证点: 上报数据中的金额与支付流水表实际打款金额完全一致；非从运单表或Redis缓存读取金额；数据库查询SQL日志可确认数据来源为支付流水表；金额字段精确到分（2位小数），无精度丢失。 + +### TP-C-003: 财务修改打款金额后第二次上报使用最新金额 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 数据校验 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-03：验证财务在账户管理模块修改打款金额后，第二次上报感知数据变更并使用修改后的最新金额。 +- 关键验证点: 合同金额10000元 → 财务调账修改为9500元 → 第二次上报金额为9500元；财务修改与上报触发有时间差时仍使用最新值；上报日志中可溯源金额来源；反例：不使用装货完成时缓存的合同金额。 + +### TP-C-004: 第二次上报列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证第二次上报列表展示的14个字段完整：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、承运运费、总金额、付款方式、付款时间、收款人、收款账号、收款账号类型、核验状态、异常项、上报状态、操作。 +- 关键验证点: 承运运费和总金额保留2位小数；付款时间为实际财务打款时间；操作列根据上报状态显示"上报"或"详情"按钮。 + +### TP-C-005: 收款账号类型标签颜色 — 个人账户(蓝色)/对公账户(绿色) +- 优先级: P2 +- 类型: UI测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证列表中收款账号类型标签颜色：个人账户显示蓝色标签，对公账户显示绿色标签。 +- 关键验证点: 司机个人银行卡(个人账户)=蓝色；企业银行账号(对公账户)=绿色；颜色与需求定义严格一致；列表中每条记录标签颜色根据实际账号类型渲染，不混淆。 + +### TP-C-006: 运单重复核验 — 通过场景 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证同一运单未重复上报时，监管平台"运单重复核验"返回通过。 +- 关键验证点: 首次上报的运单核验通过；不同运单号各自独立上报通过；核验状态标记为"通过"；无"运单重复"异常项出现。 + +### TP-C-007: 运单重复核验 — 异常场景（重复上报） +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证同一运单第二次上报时，监管平台"运单重复核验"检测到重复并返回异常。 +- 关键验证点: 重复上报后核验状态变为"异常"；异常项明确标注"运单重复核验"；异常原因清晰可读；异常运单可触发申诉流程。 + +### TP-C-008: 车辆资质核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证车辆道路运输证在有效期内时，监管平台"车辆资质核验"返回通过。 +- 关键验证点: 道路运输证有效期起止日期在有效期内；道路运输证号格式有效；车辆审核状态为"通过"的运单核验通过。 + +### TP-C-009: 车辆资质核验 — 异常场景（证件过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证车辆道路运输证已过期或缺失时，监管平台"车辆资质核验"返回异常。 +- 关键验证点: 道路运输证有效期的截止日期 < 当前日期时核验异常；无道路运输证号的车辆核验异常；异常项明确标注"车辆资质核验"；异常后可申诉。 + +### TP-C-010: 司机资质核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证司机从业资格证在有效期内时，监管平台"司机资质核验"返回通过。 +- 关键验证点: 从业资格证有效期起止日期在有效期内；从业资格证号格式有效；司机审核状态为"通过"的运单核验通过。 + +### TP-C-011: 司机资质核验 — 异常场景（证件过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证司机从业资格证已过期或缺失时，监管平台"司机资质核验"返回异常。 +- 关键验证点: 从业资格证有效期至 < 当前日期时核验异常；无从业资格证号时核验异常；异常项明确标注"司机资质核验"；异常后可申诉。 + +### TP-C-012: 集中支付核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证资金流水通过网货平台集中支付时，监管平台"集中支付核验"返回通过。 +- 关键验证点: 付款方为网货平台统一账户，核验通过；支付流水记录与集中支付模式匹配；核验状态为"通过"。 + +### TP-C-013: 集中支付核验 — 异常场景（非集中支付/支付信息异常） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证资金流水未通过网货平台集中支付或支付信息异常时，监管平台"集中支付核验"返回异常。 +- 关键验证点: 付款方非平台统一账户时核验异常；集中支付流水数据不完整时核验异常；异常项明确标注"集中支付核验"；异常后可申诉。 + +### TP-C-014: 资金流水核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证资金流水单号不重复且金额匹配时，监管平台"资金流水核验"返回通过。 +- 关键验证点: 流水号唯一不重复；上报金额与支付流水表实际金额一致；核验状态为"通过"。 + +### TP-C-015: 资金流水核验 — 异常场景（流水号重复/金额不匹配） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证资金流水单号重复或上报金额与支付流水不一致时，监管平台"资金流水核验"返回异常。 +- 关键验证点: 重复流水单号核验异常并提示；上报金额与支付流水金额偏差>0.01元时核验异常；异常项明确标注"资金流水核验"；异常后可申诉。 + +### TP-C-016: 合同核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证运输合同和委托合同均有效时，监管平台"合同核验"返回通过。 +- 关键验证点: 承运合同编号有效且存在于合同管理系统；委托合同编号（如有）有效；合同有效期覆盖运单执行日期；核验状态为"通过"。 + +### TP-C-017: 合同核验 — 异常场景（合同无效/过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证运输合同或委托合同无效/过期/缺失时，监管平台"合同核验"返回异常。 +- 关键验证点: 承运合同编号不存在时核验异常；合同有效期不包含运单执行日期时核验异常；异常项明确标注"合同核验"；异常后可申诉。 + +### TP-C-018: 车辆轨迹合规核验 — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证车辆GPS轨迹真实、与运单路线匹配、轨迹点数量在2~2000范围内时，监管平台"车辆轨迹合规核验"返回通过。 +- 关键验证点: 轨迹点数量≥2且≤2000；轨迹路线与装货地→卸货地路线基本一致；轨迹时间与运单执行时间匹配；核验状态为"通过"。 + +### TP-C-019: 车辆轨迹合规核验 — 异常场景（点位不足/偏差过大/轨迹缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证车辆轨迹点数量不足(<2)、偏差过大、或轨迹数据缺失时，监管平台"车辆轨迹合规核验"返回异常。 +- 关键验证点: 轨迹点数量=1或0时核验异常；轨迹路线偏离装货-卸货路线超过合理范围时核验异常；异常项明确标注"车辆轨迹合规核验"；异常后可进入"补传轨迹"流程。 + +> **⚠️ API文档扩展说明 (来自原型&接口交叉分析)**: +> 根据网货企业端接口文档 V1.0.2 §4.1 异常项ID对照表，第二次上报核验项从需求的7类扩展为API定义的17项独立核验项。以下TP-C-006~TP-C-019覆盖了需求的7类核验（运单重复/车辆资质/司机资质/集中支付/资金流水/合同/轨迹合规），但API将其中部分类别拆分为更细粒度的独立核验项。 +> +> API文档完整17项: 100=委托合同, 120=承运合同, 130=实时定位, 140=运单时间逻辑, 150=车辆资质, 160=道路运输证, 170=驾驶证, 180=从业资格证, 190=车辆重复, 200=司机重复, 210=车辆轨迹, 220=运费收款, 230=公司统一收款, 240=集中支付, 250=资金流水, 260=发票信息, 270=非通行车辆可开票 +> +> 以下 TP-C-026~TP-C-049 为补充的12项独立核验项（每项 PASS + EXCEPTION），来源标注 [技术方案]。 + +### TP-C-025: 里程申诉功能 — 提交里程申诉 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证运单里程数据异常时，可通过 POST /mileageAppeal/insert 接口提交里程申诉，携带运单号(freightSheetNumber)、申诉内容(content)、投诉编号(complaintNumber)、申诉里程(mileage)参数。 +- 关键验证点: 里程申诉接口正常调用成功返回；必选参数齐全（运单号/申诉内容/投诉编号/申诉里程）；申诉提交后可在申诉记录中查看；里程申诉与异常申诉独立管理；缺少必选参数时接口返回明确错误提示。 + +### TP-C-026: 委托合同核验(100) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证委托合同编号有效且存在于合同管理系统、有效期覆盖运单执行日期时，监管平台"委托合同核验"返回通过。 +- 关键验证点: 委托合同编号有效且存在于系统；委托合同有效期覆盖运单执行日期；核验状态为"通过"；无"委托合同核验"异常项出现。 + +### TP-C-027: 委托合同核验(100) — 异常场景（合同无效/过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证委托合同编号不存在、无效或有效期不覆盖运单执行日期时，监管平台"委托合同核验"返回异常。 +- 关键验证点: 委托合同编号不存在时核验异常；合同有效期不覆盖运单执行日期时核验异常；委托合同为空时核验异常；异常项明确标注"委托合同核验"（代码100）；异常后可申诉。 + +### TP-C-028: 承运合同核验(120) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证承运合同编号有效且存在于合同管理系统、有效期覆盖运单执行日期时，监管平台"承运合同核验"返回通过。 +- 关键验证点: 承运合同编号有效且存在于系统；承运合同有效期覆盖运单执行日期；核验状态为"通过"；无"承运合同核验"异常项出现。 + +### TP-C-029: 承运合同核验(120) — 异常场景（合同无效/过期/缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证承运合同编号不存在、无效或有效期不覆盖运单执行日期时，监管平台"承运合同核验"返回异常。 +- 关键验证点: 承运合同编号不存在时核验异常；合同有效期不覆盖运单执行日期时核验异常；承运合同为空时核验异常；异常项明确标注"承运合同核验"（代码120）；异常后可申诉。 + +### TP-C-030: 实时定位核验(130) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证车辆在运单执行期间有完整的实时定位数据（GPS轨迹覆盖整个运输过程）时，监管平台"实时定位核验"返回通过。 +- 关键验证点: 运单执行期间车辆实时定位数据完整；定位时间覆盖运单起运至送达时间范围；核验状态为"通过"；无"实时定位核验"异常项出现。 + +### TP-C-031: 实时定位核验(130) — 异常场景（定位数据缺失/不完整） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证车辆在运单执行期间缺少实时定位数据或定位数据不完整时，监管平台"实时定位核验"返回异常。 +- 关键验证点: 运输过程中定位数据长时间中断时核验异常；无任何实时定位数据时核验异常；定位数据时间范围未覆盖运单执行时间时核验异常；异常项明确标注"实时定位核验"（代码130）；异常后可申诉或补传定位数据。 + +### TP-C-032: 运单时间逻辑核验(140) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证运单各时间节点逻辑合理（建单时间 < 接单时间 < 起运时间 < 送达时间）时，监管平台"运单时间逻辑核验"返回通过。 +- 关键验证点: 建单时间早于接单时间；接单时间早于起运时间；起运时间早于送达时间；各时间节点无倒置或矛盾；核验状态为"通过"。 + +### TP-C-033: 运单时间逻辑核验(140) — 异常场景（时间倒置/不合理） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证运单各时间节点存在逻辑矛盾（如送达时间早于起运时间、接单时间早于建单时间等）时，监管平台"运单时间逻辑核验"返回异常。 +- 关键验证点: 起运时间晚于送达时间时核验异常；接单时间早于建单时间时核验异常；时间字段为空时核验异常；异常项明确标注"运单时间逻辑核验"（代码140）；异常后可申诉。 + +### TP-C-034: 道路运输证核验(160) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证车辆道路运输证在有效期内且证号格式有效时，监管平台"道路运输证核验"返回通过。 +- 关键验证点: 道路运输证有效期起止日期在当前日期范围内；道路运输证号格式有效且可查询；道路运输证发证机关信息完整；核验状态为"通过"；无"道路运输证核验"异常项出现。 + +### TP-C-035: 道路运输证核验(160) — 异常场景（过期/缺失/无效） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证车辆道路运输证过期、缺失或证号格式无效时，监管平台"道路运输证核验"返回异常。 +- 关键验证点: 道路运输证有效期截止日期 < 当前日期时核验异常；道路运输证号为空或格式无效时核验异常；证号在运政系统中查询不存在时核验异常；异常项明确标注"道路运输证核验"（代码160）；异常后可申诉。 + +### TP-C-036: 驾驶证核验(170) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证司机驾驶证在有效期内且证号与交管系统一致时，监管平台"驾驶证核验"返回通过。 +- 关键验证点: 驾驶证有效期覆盖运单执行日期；驾驶证号格式正确（18位）；驾驶证准驾车型与车辆类型匹配；核验状态为"通过"；无"驾驶证核验"异常项出现。 + +### TP-C-037: 驾驶证核验(170) — 异常场景（过期/缺失/准驾不符） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证司机驾驶证过期、缺失或准驾车型不匹配时，监管平台"驾驶证核验"返回异常。 +- 关键验证点: 驾驶证有效期截止日期 < 当前日期时核验异常；驾驶证号为空或格式无效时核验异常；准驾车型与实际驾驶车辆类型不匹配时核验异常；异常项明确标注"驾驶证核验"（代码170）；异常后可申诉。 + +### TP-C-038: 车辆重复核验(190) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证同一车辆未在同一时间段内被重复用于多个运单时，监管平台"车辆重复核验"返回通过。 +- 关键验证点: 车辆在运单执行时段内无其他重叠运单；车辆未同时出现在多个进行中的运单中；核验状态为"通过"；无"车辆重复核验"异常项出现。 + +### TP-C-039: 车辆重复核验(190) — 异常场景（车辆同时用于多个运单） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证同一车辆在同一时间段内被用于多个运单（时间重叠）时，监管平台"车辆重复核验"返回异常。 +- 关键验证点: 车辆在运单A执行期间同时出现在运单B中时核验异常；时间重叠超过合理阈值时核验异常；异常项明确标注"车辆重复核验"（代码190）；异常后可申诉。 + +### TP-C-040: 司机重复核验(200) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证同一司机未在同一时间段内被重复分配给多个运单时，监管平台"司机重复核验"返回通过。 +- 关键验证点: 司机在运单执行时段内无其他重叠运单；司机未同时驾驶多辆车辆执行不同运单；核验状态为"通过"；无"司机重复核验"异常项出现。 + +### TP-C-041: 司机重复核验(200) — 异常场景（司机同时执行多个运单） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证同一司机在同一时间段内被分配给多个运单（时间重叠）时，监管平台"司机重复核验"返回异常。 +- 关键验证点: 司机在运单A执行期间同时出现在运单B中时核验异常；时间重叠超过合理阈值时核验异常；异常项明确标注"司机重复核验"（代码200）；异常后可申诉。 + +### TP-C-042: 运费收款核验(220) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证运费收款方信息与实际司机/承运人一致、收款金额与运单运费匹配时，监管平台"运费收款核验"返回通过。 +- 关键验证点: 收款方身份与运单司机一致；收款金额与运单运费一致；收款账户信息有效；核验状态为"通过"；无"运费收款核验"异常项出现。 + +### TP-C-043: 运费收款核验(220) — 异常场景（收款人不一致/金额不匹配） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证运费收款人与运单司机不一致、收款金额与运费不匹配时，监管平台"运费收款核验"返回异常。 +- 关键验证点: 收款人姓名/身份证号与司机信息不一致时核验异常；收款金额与运单运费偏差超过阈值时核验异常；异常项明确标注"运费收款核验"（代码220）；异常后可申诉。 + +### TP-C-044: 公司统一收款核验(230) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证当收款方为公司统一收款账户时，公司信息与运单托运方信息一致，监管平台"公司统一收款核验"返回通过。 +- 关键验证点: 收款公司名称/统一社会信用代码与托运方一致；公司统一收款账户在系统中备案；核验状态为"通过"；无"公司统一收款核验"异常项出现。 + +### TP-C-045: 公司统一收款核验(230) — 异常场景（公司信息不一致/未备案） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证公司统一收款账户信息与托运方不一致或收款账户未备案时，监管平台"公司统一收款核验"返回异常。 +- 关键验证点: 收款公司名称与托运方名称不一致时核验异常；收款公司统一社会信用代码与托运方不一致时核验异常；收款账户未在系统中备案时核验异常；异常项明确标注"公司统一收款核验"（代码230）；异常后可申诉。 + +### TP-C-046: 发票信息核验(260) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证第三次上报关联的发票信息完整有效（发票号码/代码/金额匹配、销售方/受票方信息完整）时，监管平台"发票信息核验"返回通过。 +- 关键验证点: 发票号码与发票代码匹配有效；发票金额（价税合计）计算正确；销售方纳税人识别号有效；受票方信息与托运方一致；核验状态为"通过"。 + +### TP-C-047: 发票信息核验(260) — 异常场景（发票无效/信息不完整） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证发票号码/代码不匹配、发票信息不完整或发票已作废时，监管平台"发票信息核验"返回异常。 +- 关键验证点: 发票号码在税务系统中查询不到时核验异常；发票已作废/红冲时核验异常；受票方名称/纳税人识别号与托运方不一致时核验异常；异常项明确标注"发票信息核验"（代码260）；异常后可申诉。 + +### TP-C-048: 非通行车辆可开票核验(270) — 通过场景 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证运单关联的车辆属于可开票车辆（即车辆资质、运营证照齐全且在合规运营范围内）时，监管平台"非通行车辆可开票核验"返回通过。 +- 关键验证点: 车辆运营证照齐全且在有效期内；车辆未被标记为不合规或黑名单；核验状态为"通过"；无"非通行车辆可开票核验"异常项出现。 + +### TP-C-049: 非通行车辆可开票核验(270) — 异常场景（车辆不合规/证照缺失） +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证车辆运营证照不全、车辆被标记为不合规或不在可开票范围内时，监管平台"非通行车辆可开票核验"返回异常。 +- 关键验证点: 车辆无有效道路运输证时核验异常；车辆被标记为运营异常/黑名单时核验异常；车辆类型不在可开票范围内时核验异常；异常项明确标注"非通行车辆可开票核验"（代码270）；异常后可申诉。 + +### TP-C-050: 第二次上报金额精度3位小数校验 [技术方案] +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [技术方案] +- 描述: 验证第二次上报中所有金额字段保留**3位小数**（非2位），货币单位为人民币（元），如整数以.000填充。涉及字段：arrivalInfo.waybillFreightAmount（承运运费金额）、arrivalInfo.totalMonetaryAmount（委托运费金额）、carrierStatements.monetaryAmount（承运人流水金额）、ownerStatements.monetaryAmount（货主流水金额）、carrierContractInfo.contractAmount（承运合同金额）、carrierContractInfo.contractedCarryingCapacity（承运量）、ownerContractInfo.contractAmount（委托合同金额）、ownerContractInfo.contractedCarryingCapacity（委托合同承运量）。 +- 关键验证点: 整数金额如100 → 上报为100.000（3位小数）；小数金额如100.5 → 上报为100.500；小数金额如100.123 → 上报为100.123；金额字段使用DECIMAL类型而非FLOAT；数据库和UI展示均保留3位小数。 + +### TP-C-051: 承运人流水核验次日延迟 [技术方案] +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证除承运人流水核验需等待次日银行提供数据后开始核验外，其余核验项会在一至两小时内核验完成。第二次上报后承运人流水核验状态初始为"待核验"（非异常），次日银行数据到后才执行核验。 +- 关键验证点: 第二次上报后除"资金流水核验"外其他核验项1~2小时内完成；承运人流水核验在当日处于"待核验"或"核验中"状态；次日银行数据提供后承运人流水核验自动执行；若次日核验发现异常，核验状态更新为"异常"并可申诉。 + +### TP-C-020: 后端校验 — 第二次上报依赖第一次上报完成 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-01：验证后端接口层面，第一次上报未完成（失败/进行中）时拒绝第二次上报，返回明确错误码。 +- 关键验证点: 第一次上报"上传失败"状态下触发第二次上报被拒绝；第一次上报"上传中"状态下触发第二次上报被拒绝；后端通过查询运单上报状态表校验，非仅前端控制；错误码和错误消息明确。 + +### TP-C-021: 第二次上报幂等性 — 防止重复上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-02：验证第二次上报具有幂等性，重复触发不产生多条上报记录，自动重试和手动触发互斥。 +- 关键验证点: 第二次上报自动重试期间禁止手动触发；同一运单第二次上报仅产生1条有效记录；分布式锁/幂等键控制并发；数据库唯一约束防止插入重复记录。 + +### TP-C-022: 补传轨迹功能 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证车辆轨迹合规核验异常后，运营人员可通过"补传轨迹"功能补充GPS轨迹数据，重新触发核验。 +- 关键验证点: 仅轨迹核验异常的运单显示"补传轨迹"按钮；补传后重新触发轨迹核验；补传的轨迹数据覆盖原有数据；补传后核验通过则异常项消除；补传操作记录到上报日志。 + +### TP-C-023: 第二次上报失败自动重试机制 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][漏测清单] +- 描述: 验证第二次上报失败（超时或接口返回错误）后，系统自动重试（最多3次），重试间隔递增，3次全部失败后告警通知运营人员。 +- 关键验证点: 上报失败后自动触发重试（非人工触发）；最多重试3次；重试间隔递增（如5s/15s/30s）；每次重试在上报日志中独立记录；3次全部失败后通过站内信或短信告警通知运营人员；重试期间手动上传按钮不可用或提示"上报处理中"。 + +### TP-C-024: 第二次上报详情弹窗资金流水与车辆轨迹字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证第二次上报详情弹窗中资金流水信息（10字段）和车辆轨迹信息（6字段）的分组展示完整且字段顺序正确。 +- 关键验证点: 资金流水信息完整展示（支付金额/支付方式/支付时间/付款方名称/收款方名称/收款人/收款账号/收款账号类型/流水号/支付状态）；车辆轨迹信息完整展示（定位类型/定位时间/定位地点/经度/纬度/轨迹类型）；可选字段缺失时显示"-"或"无"而不空白；弹窗分组标签正确（运单信息/托运方信息/收货方信息/资金流水信息/车辆轨迹信息/异常信息）。 + +--- + +## 模块D: 第三次上报-开票完成 (11个测试点) + +### TP-D-001: 开票完成后触发第三次上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证发票开具完成后，系统触发第三次上报，上报数据包含运单信息、发票信息和油气发票信息。 +- 关键验证点: 发票开具完成后自动触发上报；上报数据包含托运单号数组、发票信息17字段；若有关联油气发票则包含油气发票信息；仅开票完成的运单触发。 + +### TP-D-002: 第三次上报列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证第三次上报列表展示的11个字段完整：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、发票号码、发票金额、开票日期、核验状态、异常原因、上报状态、操作。⚠️ 待确认: 原型列表比需求多4个字段（税率、销售方名称、受票方名称、油气票张数），共15列（含checkbox），需确认最终版本。 +- 关键验证点: 发票金额保留2位小数（价税合计）；开票日期格式正确；核验状态/异常原因/上报状态数据准确。 + +### TP-D-003: 第三次上报发票信息字段完整性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证第三次上报详情弹窗中"发票信息"分组的17个字段完整展示。 +- 关键验证点: 托运单号数组支持多个托运单号；发票号码、发票代码号、发票金额(价税合计)、开票日期必选完整；销售方8个字段(名称/纳税人识别号/地址/电话/开户行/银行账户)完整；受票方6个字段(名称/纳税人识别号/地址/电话/开户行/银行卡号)完整；注：第三次上报无税率字段。 + +### TP-D-004: 第三次上报油气发票信息 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证运单关联油气发票时，第三次上报包含油气发票信息（油气托运单号、油气发票文件），支持多条油气发票。 +- 关键验证点: 有油气发票时正常上报；无油气发票时不影响上报（可选字段）；多条油气发票时字段展示正确；油气发票文件支持查看/下载。 + +### TP-D-005: 后端校验 — 第三次上报依赖第二次上报完成 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-01：验证后端接口层面，第二次上报未完成（失败/进行中/未触发）时拒绝第三次上报，返回明确错误码。 +- 关键验证点: 第二次上报未完成时调用第三次上报接口被拒绝；错误码明确标识"前置上报（第二次）未完成"；后端通过查询运单上报状态表校验；第三阶段完整依赖链校验（第1→第2→第3）。 + +### TP-D-006: 增值税发票验证失败处理 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证增值税发票验证失败时（发票号码/代码/金额不匹配等），第三次上报失败并返回明确错误提示。 +- 关键验证点: 发票号码格式无效时上报失败；发票代码与发票号码不匹配时上报失败；发票金额超出合理范围时上报失败；失败提示指明具体错误字段和原因。 + +### TP-D-007: 第三次上报自动重试 — 最多3次 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [需求] +- 描述: 验证第三次上报失败后自动重试（最多3次），全部失败后告警通知运营人员。 +- 关键验证点: 重试次数不超过3次；重试间隔递增；全部失败后标记"上传失败"并告警；告警通知中包含运单号、发票号、失败原因。 + +### TP-D-008: 第三次上报异常信息展示 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证第三次上报详情弹窗中"异常信息"分组包含核验状态、异常原因、异常时间、处理状态，与申诉模块数据联动。 +- 关键验证点: 核验通过时异常原因为空；核验异常时展示具体异常项和原因；核验状态与看板/申诉模块数据一致。 + +### TP-D-009: 第三次上报幂等性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 +- 来源: [最佳实践][历史缺陷] +- 描述: 验证第三次上报具有幂等性，同一运单同一发票信息不能重复上报。 +- 关键验证点: 同一运单重复触发第三次上报仅产生1条有效记录；分布式锁/幂等键控制并发；重复提交返回"上报已存在"提示。 + +### TP-D-010: 第三次上报发票金额精度校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [漏测清单][风险矩阵] +- 描述: 验证第三次上报的发票金额（价税合计）保留2位小数，不出现浮点数精度问题。 +- 关键验证点: 金额计算精度正确（如0.01元不丢失）；大金额（如 999999.99）上报准确；金额字段使用 DECIMAL 类型而非 FLOAT；上报数据与开票系统数据完全一致。 + +### TP-D-011: 第三次上报货物信息/保险信息逐源验证 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [漏测清单] +- 描述: 验证第三次上报中的运单信息字段数据来源正确——价格/货物信息来源于运单表，保险信息来源于保险模块，非缓存数据。 +- 关键验证点: 修改运单表数据后上报使用最新值；修改保险信息后上报使用最新值；字段取值链路可追溯；不依赖装货完成时的数据快照。 + +### TP-D-012: 发票合规查询 — 托运人发票是否系统核验合规 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [技术方案] +- 描述: 验证可通过 POST /verificationSummary/cargoOwnerInvoiceInfo 接口查询托运人（货主）发票是否已通过系统核验合规，用于判断第三次上报前置条件。 +- 关键验证点: 输入有效托运人信息返回发票合规状态；发票合规时返回通过标识；发票不合规时返回异常原因；接口支持批量查询多个托运人发票合规状态；接口响应时间在合理范围内（< 3s）。 + +--- + +## 模块E: ETC发票上传 (9个测试点) + +### TP-E-001: ETC发票上传触发 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证ETC发票税务抵扣成功后，运营人员在运八系统手动确认抵扣完成，系统收到确认后触发ETC发票上传至安徽监管平台。 +- 关键验证点: 运营人员手动确认税务抵扣完成 → 系统触发ETC上传；上传数据包含运单信息+ETC发票信息18字段；上传成功后可在列表查看状态。 + +### TP-E-002: ETC发票列表字段完整性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证ETC上传列表展示的11个字段完整：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、ETC发票号码、发票金额、税率、上传状态、操作。 +- 关键验证点: ETC发票号码与高速公路电子发票号码一致；发票金额和税率（3%）正确展示；上传状态标签颜色符合规范。 + +### TP-E-003: ETC发票详情弹窗 — 字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证ETC发票详情弹窗包含3个分组：运单信息（7字段）、ETC发票信息（每张发票18字段）、异常信息。 +- 关键验证点: ETC发票18字段全部展示：ETC发票号码、ETC发票代码、开票时间、发票金额、税率(3%)、税额、价税合计、销售方名称、销售方税号、受票方名称、受票方税号、入口收费站、出口收费站、交易时间、交易金额、交易匹配时间、交易流水号、ETC发票文件；运单信息7字段完整；异常信息4字段完整。 + +### TP-E-004: 税务抵扣完成前置条件校验 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 +- 来源: [需求] +- 描述: 验证ETC发票上传必须在税务抵扣完成后进行，未完成税务抵扣时上传被拒绝。 +- 关键验证点: 税务抵扣未完成时上传返回明确错误；错误提示包含"请先完成税务抵扣"；后端校验税务抵扣状态；税务抵扣完成后上传才可成功。 + +### TP-E-005: ETC发票验证失败处理 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证ETC发票信息验证失败时（发票号码/代码无效、金额不匹配、税率不正确等），上传失败并给出明确提示。 +- 关键验证点: 发票号码格式无效时上传失败；发票代码与号码不匹配时上传失败；税率非3%时提示税率异常；交易金额与实际通行费不匹配时验证失败；失败提示明确指示错误字段。 + +### TP-E-006: ETC上传自动重试 — 最多3次 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [需求] +- 描述: 验证ETC上传失败后自动重试最多3次，全部失败后告警通知。 +- 关键验证点: 3次重试均失败后标记"上传失败"并告警；重试间隔递增；每次重试记录到上报日志。 + +### TP-E-007: ETC税额计算校验 — 税额=不含税金额×税率 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][风险矩阵] +- 描述: 验证ETC发票税额计算公式：税额 = 不含税金额(invoiceAmount) x 税率(taxRate，如3%)。关键字段区分：invoiceAmount=不含税金额（保留2位小数）、totalPriceAndTax=价税合计（不含税金额+税额，保留2位小数）、taxAmount=税额（保留2位小数）。涉及资损风险需精确验证。 +- 关键验证点: 不含税金额100元×3% → 税额=3.00元, 价税合计=103.00元；不含税金额0.01元 → 税额=0.00元(或四舍五入规则明确)；大金额(如1000000元)计算不溢出；税额+不含税金额=价税合计(totalPriceAndTax)逻辑关系正确。 + +### TP-E-008: ETC上传幂等性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 +- 来源: [最佳实践][历史缺陷] +- 描述: 验证同一ETC发票不能重复上传，具有幂等性。 +- 关键验证点: 同一ETC发票号重复上传被拒绝；返回"该ETC发票已上传"提示；数据库存在唯一约束防止重复记录。 + +### TP-E-009: ETC多张发票同时上传 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 边界条件 +- 来源: [需求][项目画像] +- 描述: 验证同一运单可能关联多张ETC发票（不同路段），支持批量上传和多张发票的列表展示。 +- 关键验证点: 多张ETC发票各自独立上传互不干扰；列表中单运单可展示多张ETC发票记录；每张发票的税额独立计算；合计税额正确汇总。 + +--- + +## 模块F: 异常申诉功能 (16个测试点) + +### TP-F-001: 申诉完整闭环 — 发起→复核→反馈→判断 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证申诉功能的完整闭环：查看异常 → 发起申诉 → 省平台复核 → 接收反馈 → 合规判断，端到端验证每个环节。注：已取消(130)由省平台侧操作设置（如运单作废），我方系统只读同步，UI不提供取消申诉操作。异常项申诉中(abnormalDetails[].state=110)可由省平台取消→异常项状态回退为100。⚠️ 待确认: 申诉状态枚举三版本不一致——需求(未申诉/申诉中/申诉通过/申诉驳回)、原型(未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回)、API(未申诉100/审核通过110/审核不通过120/已取消130)，以API §4.4为权威，需确认UI映射。 +- 关键验证点: 异常运单可发起申诉；申诉提交后状态保持"未申诉(100)"（异常项处理状态变为申诉中 abnormalDetails[].state=110）；省平台复核后反馈结果更新；反馈通过→申诉状态变为"审核通过(110)"；反馈驳回→申诉状态变为"审核不通过(120)"，可补充材料重新申诉。 + +### TP-F-002: 申诉列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证申诉记录管理页面列表展示的13个字段完整：运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、异常项、申诉状态、申诉时间、申诉人、省平台反馈结果、监管平台反馈时间、操作。 +- 关键验证点: 每个字段有对应数据；申诉状态与需求定义一致；申诉时间为实际提交时间；省平台反馈结果与实际反馈内容一致。 + +### TP-F-003: 申诉状态流转 — 全部合法路径 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 +- 来源: [需求][漏测清单] +- 描述: 验证申诉状态流转全路径（以API §4.4为权威）：未申诉(100) → [提交申诉，异常项state=110申诉中] → 审核通过(110)[终态] / 审核不通过(120)[可重新申诉] → (审核不通过后) 重新申诉 → 未申诉(100)[新申诉单]。注：已取消(130)为省平台侧操作（如运单作废等），我省平台只读同步该状态，不主动发起取消；UI层不提供"取消申诉"按钮。⚠️ 待确认: 原型中"待省平台反馈"+"反馈处理中"如何映射到API枚举。 +- 关键验证点: 未申诉(100)状态下可发起申诉；异常项申诉中(abnormalDetails[].state=110)状态下不可重复发起同一异常项申诉；审核通过(110)后状态不可再变更（终态）；审核不通过(120)后可点击"重新申诉"发起新一轮申诉；已取消(130)为省平台外部操作设置的终态，我方系统只读；每种状态变更记录到处理记录时间线。 + +### TP-F-004: 申诉详情弹窗 — 分组字段完整性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求][漏测清单] +- 描述: 验证申诉详情弹窗包含5个分组：申诉信息、运单信息、异常信息、省平台反馈信息、处理记录。 +- 关键验证点: 申诉信息分组含申诉单号/上报阶段/异常项/申诉原因/申诉状态/申诉时间/申诉人/申诉附件；省平台反馈信息含反馈结果/反馈时间/反馈意见；处理记录以时间线形式展示：操作人/操作时间/操作类型/操作内容。 + +### TP-F-005: 申诉附件上传功能 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][项目画像] +- 描述: 验证发起申诉时支持上传附件（如证明材料图片/PDF），附件上传功能正常。 +- 关键验证点: 支持上传多个附件；附件格式支持常见类型(png/jpg/pdf)；附件大小有限制且超标时提示；上传后可在详情弹窗中查看/下载；上传失败有重试机制。 + +### TP-F-006: 审核不通过(120)后重新申诉 — 补充材料再发起 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求] +- 描述: 验证申诉被省平台审核不通过(120)后，运营人员可补充材料，点击"重新申诉"发起新一轮申诉。 +- 关键验证点: 审核不通过(120)状态下"重新申诉"按钮可见可用；重新申诉时原有申诉记录保留；新一轮申诉生成新的申诉单号；重新申诉可上传新的附件材料；新的申诉有独立的处理记录时间线。 + +### TP-F-007: 17项核验（API文档定义）异常各自发起申诉 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [需求] +- 描述: 验证第二次上报的17项核验（API文档§4.1定义：委托合同100/承运合同120/实时定位130/运单时间逻辑140/车辆资质150/道路运输证160/驾驶证170/从业资格证180/车辆重复190/司机重复200/车辆轨迹210/运费收款220/公司统一收款230/集中支付240/资金流水250/发票信息260/非通行车辆可开票270）每项核验异常均可独立发起申诉。⚠️ 待确认: 核验项从需求7类扩展为API文档17项，需确认每项是否均有独立申诉入口。 +- 关键验证点: 每种核验异常项对应独立的申诉入口；申诉中(abnormalDetails[].state=110)的异常项信息与核验结果一致；不同异常项的申诉原因字段独立；某一异常项申诉不影响其他异常项。 + +### TP-F-008: 从看板直接跳转申诉 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证从看板"操作"列点击"申诉"按钮，可跳转到申诉页面并自动填充运单号、异常项信息。 +- 关键验证点: 看板"申诉"按钮点击后路由跳转正确；跳转后页面自动加载该运单的异常信息；运单号和异常项预填充正确；不需要运营人员手动查找运单。 + +### TP-F-009: 申诉权限控制 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 权限控制 +- 来源: [项目画像] +- 描述: 验证仅运营人员有权发起申诉和管理申诉记录，其他角色（司机/车队长/货主/财务）不能操作申诉功能。 +- 关键验证点: 运营人员可见"申诉"按钮和申诉记录页面；司机端不可见申诉功能；财务人员可查看申诉记录但不可发起申诉；越权操作被正确拦截并记录审计日志。 + +### TP-F-010: 申诉处理记录时间线展示 +- 优先级: P2 +- 类型: UI测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证申诉详情弹窗中"处理记录"以时间线形式展示，每条记录包含操作人、操作时间、操作类型、操作内容。 +- 关键验证点: 时间线按时间倒序排列；每步操作（发起申诉/省平台反馈/重新申诉）均有一条记录；操作时间精确到秒；操作类型准确（发起申诉/审核通过/审核不通过等）。 + +### TP-F-011: 异常代码一览表匹配校验 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证需求文档中"异常代码一览表"定义的每种异常代码，在申诉页面中正确映射为对应的中文异常项名称。 +- 关键验证点: 每种异常代码有明确的中文描述；异常代码与异常项名称一一对应；省平台返回的异常代码能被正确解析；未知异常代码有兜底展示（如显示原始代码+标注"未知异常"）。 + +### TP-F-012: 申诉并发控制 — 同一异常项不可重复申诉 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 并发幂等 +- 来源: [漏测清单] +- 描述: 验证同一运单同一异常项申诉中(abnormalDetails[].state=110)状态下不可再次发起申诉，防止重复提交。 +- 关键验证点: 异常项申诉中(abnormalDetails[].state=110)状态下点击"申诉"按钮被禁用或提示"申诉处理中"；快速双击"提交申诉"按钮仅产生1条申诉记录；后端有状态校验，申诉中不可重新发起。 + +### TP-F-013: 申诉超时处理 — 省平台长时间无反馈 +- 优先级: P3 +- 类型: 功能测试 +- 覆盖维度: 弱网超时 +- 来源: [漏测清单] +- 描述: 验证申诉提交后，省平台长时间无反馈时，系统有合理的超时处理和状态提示。 +- 关键验证点: 申诉提交后超过一定时间（如7个工作日）无反馈时，系统给出"等待省平台复核中"的提示或超时告警；不自动变更申诉状态为通过/驳回；运营人员可查看申诉等待时长。 + +### TP-F-014: 单次申诉仅支持单个异常项 — 申诉表单单选约束 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [技术方案] +- 描述: 验证申诉表单中异常项选择器仅支持单选（radio或单选下拉），不可多选。根据API §3.3，`verificationAbnormalItems`参数"只支持单个异常项目申诉"。 +- 关键验证点: 异常项选择器为单选控件（非复选框）；不可同时勾选多个异常项后提交；选择器交互方式明确为单选（radio button 或 single-select dropdown）。 + +### TP-F-015: 多异常项运单逐次申诉 — 同一运单分别发起多次申诉 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [技术方案] +- 描述: 验证同一运单存在两个或多个异常项（如"车辆资质150"和"资金流水250"同时异常）时，需分别对每个异常项发起独立申诉，每个申诉对应一个申诉单号。 +- 关键验证点: 运单有2个异常项时，可分别发起2次申诉（每次选1个异常项）；每次申诉生成独立的申诉单号(complaintNumber)；申诉记录列表中该运单有2条独立申诉记录；不同异常项的申诉互不影响（一项通过另一项驳回各自独立流转）。 + +### TP-F-016: 申诉接口 verificationAbnormalItems 参数单值校验 — 传入多个ID时接口拒绝 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 规则组合 +- 来源: [技术方案] +- 描述: 验证调用 `POST /appeal/insert` 时，若 `verificationAbnormalItems` 传入多个异常项ID（如 "120,160"），接口应返回错误并拒绝提交。API §3.3 明确"只支持单个异常项目申诉"。 +- 关键验证点: 传入逗号分隔的多个ID（如"120,160"）时接口返回错误；错误码明确指示"仅支持单个异常项申诉"；传入单个ID时接口正常处理；传入空字符串或null时接口返回参数缺失错误；前端在提交前已做单选校验（双保险）。 + +--- + +## 模块G: 上报日志 (9个测试点) + +### TP-G-001: 上报日志 — 按运单号/托运单号/货源单号模糊搜索 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证上报日志页面支持按运单号/托运单号/货源单号模糊搜索，快速定位相关日志。 +- 关键验证点: 输入完整单号精确匹配；输入部分字符模糊匹配；输入不存在的单号显示空结果；三种单号搜索互不干扰。 + +### TP-G-002: 上报日志 — 按上报阶段筛选 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证上报日志支持按"全部/第一次上报/第二次上报/第三次上报/ETC上传"筛选。 +- 关键验证点: 每种阶段独立筛选数据正确；ETC上传有独立筛选项；默认"全部"展示所有阶段日志。 + +### TP-G-003: 上报日志 — 按上报结果筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证上报日志支持按"全部/成功/失败"筛选上报结果。 +- 关键验证点: "成功"仅展示HTTP 2xx的日志；"失败"展示所有非成功日志(含超时/4xx/5xx)；筛选结果与实际日志记录一致。 + +### TP-G-004: 上报日志 — 时间范围筛选 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证上报日志支持按开始时间-结束时间范围筛选日志记录。 +- 关键验证点: 精确时间范围筛选数据正确；跨天/跨月筛选正常；开始时间>结束时间时给出提示或自动交换；不选时间范围默认显示全部。 + +### TP-G-005: 上报日志列表字段完整性校验 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [需求] +- 描述: 验证上报日志列表展示的9个字段完整：序号、货源单号、运单号、托运单号、上报阶段、上报结果、接口URL、HTTP状态码、响应时间、上报时间、操作。 +- 关键验证点: 接口URL完整展示（含域名和路径）；HTTP状态码为实际返回状态码（200/400/500等）；响应时间单位明确（ms）；上报时间为实际请求发起时间。 + +### TP-G-006: 上报日志操作 — 弹窗查看完整请求/响应报文 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 验证点击日志"操作"列的详情按钮，弹窗展示完整的请求报文（Request）和响应报文（Response），用于问题排查。 +- 关键验证点: 请求报文完整展示：URL、Method、Headers、Body；响应报文完整展示：Status Code、Headers、Body；JSON 报文格式化展示（缩进/语法高亮）；长报文支持滚动查看和复制。 + +### TP-G-007: 上报日志全阶段覆盖 — 每个上报阶段的日志记录 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求][漏测清单] +- 描述: 验证每个上报阶段（第一次/第二次/第三次/ETC）以及自动修改字段接口的每次调用都在日志中有完整记录。 +- 关键验证点: 第一次上报+自动修改字段接口均有日志；第二次上报+7类核验结果均有日志；第三次上报日志完整；ETC上传日志完整；自动重试的每次请求均独立记录。 + +### TP-G-008: 上报日志失败记录的可追溯性 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 数据校验 +- 来源: [漏测清单] +- 描述: 验证上报失败的日志记录足够详细，可通过日志定位失败原因——包括错误响应体、异常堆栈（如有）、重试次数等。 +- 关键验证点: 失败日志包含完整的Error Response Body；超时日志标注"timeout"并记录超时时长；重试日志中标注当前是第几次重试；异常日志可关联到具体运单ID便于排查。 + +### TP-G-009: 上报日志审计 — 操作人追踪 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 权限控制 +- 来源: [项目画像][最佳实践] +- 描述: 验证上报日志中可区分自动触发上报和手动触发上报，并记录操作人信息。 +- 关键验证点: 自动触发上报的日志标注"系统自动"或"auto"；手动触发上报的日志记录操作人用户名；手动上传的操作人信息与实际登录用户一致；审计能力满足合规要求。 + +--- + +## 跨模块测试点（7个测试点） + +### TP-X-001: 完整三阶段依赖链端到端验证 — 后端三重校验 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 状态流转 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 端到端验证三阶段依赖链：装货完成→第一次上报成功→打款完成→第二次上报成功→开票完成→第三次上报成功。核心验证后端在每个阶段都做了前置状态校验。 +- 关键验证点: 第1次上报失败→第2次上报接口拒绝；第2次上报失败→第3次上报接口拒绝；第1、2、3次顺序不可跳级；依赖链校验在后端实现（非仅前端控制）；每个阶段的阻断/通过状态独立。 + +### TP-X-002: 多模块数据一致性 — 修改源数据后上报同步 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 数据校验 + 历史缺陷防御 +- 来源: [历史缺陷][漏测清单] +- 描述: 防御 BUG-202607-03：验证上报数据字段溯源正确，修改来源表数据后各阶段上报能感知变更并使用最新值。 +- 关键验证点: 修改司机信息→第一次上报使用最新司机信息；修改支付流水→第二次上报使用最新金额；修改发票信息→第三次上报使用最新发票数据；修改ETC信息→ETC上传使用最新数据；数据库查询日志可确认数据来源表，非缓存。 + +### TP-X-003: 安徽运八全流程 — 正常运单完整上报链路 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 主流程 +- 来源: [需求] +- 描述: 端到端验证一个安徽税源地运单从装货到ETC上传的完整三阶段+ETC上报链路，所有阶段核验通过，无异常。 +- 关键验证点: 装货完成→第1次上报成功(绿色)→核验通过→自动修改字段→打款完成→第2次上报成功(核验全通过)→开票完成→第3次上报成功→税务抵扣→ETC上传成功；每个阶段看板数据正确更新；上报日志完整记录全链路。 + +### TP-X-004: 非安徽税源地运单 — 全流程不上报 +- 优先级: P0 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [需求][项目画像] +- 描述: 验证税源地为非安徽省（如云南=28）的运单，全部三个阶段和ETC上传均不触发上报。 +- 关键验证点: 云南税源地运单装货完成不触发第1次上报；打款完成不触发第2次上报；开票完成不触发第3次上报；税务抵扣不触发ETC上传；看板中不显示该运单。 + +### TP-X-005: 三阶段上报各省份数据隔离 +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 权限控制 +- 来源: [项目画像][历史缺陷] +- 描述: 验证多省份部署场景下，安徽运八上报数据与其他省份（如云南）上报数据完全隔离，互不干扰。 +- 关键验证点: 安徽运单仅上报至安徽监管平台；云南运单仅上报至云南监管平台；省份代码各自独立（安徽=34、云南=28）；不同省份的上报日志和数据记录物理/逻辑隔离。 + +### TP-X-006: 回单签收后自动流转上报 — 时序正确性 +- 优先级: P2 +- 类型: 功能测试 +- 覆盖维度: 状态流转 +- 来源: [需求][项目画像] +- 描述: 验证运单在回单签收→财务打款的时序下，第二次上报的触发时机为"打款完成"而非"回单签收"，时序正确。 +- 关键验证点: 回单签收完成但未打款时，不触发第二次上报；财务打款完成后才触发第二次上报；上报时间戳与打款完成时间关系合理。 + +### TP-X-007: 已上报运单不可取消或删除 [技术方案] +- 优先级: P1 +- 类型: 功能测试 +- 覆盖维度: 异常流程 +- 来源: [技术方案] +- 描述: 验证上传至服务平台的运单不支持取消或删除操作。按主管部门要求，上传后的运单不允许修改任何信息，企业应在运单信息确认后再进行上报。服务平台在统计合规率时不会将未完结的运单计算在内。 +- 关键验证点: 已上报运单在服务平台无"取消"或"删除"操作入口；API层面无取消/删除运单接口；尝试通过任何方式取消运单均被拒绝并有明确提示；未完结运单不影响合规率统计。 + +--- + +## 历史缺陷防御映射表 + +| 历史缺陷ID | 防御测试点 | +| :--- | :--- | +| BUG-202607-01（阶段依赖链断裂） | TP-B-005, TP-C-020, TP-D-005, TP-X-001 | +| BUG-202607-02（重试幂等缺陷） | TP-B-014, TP-C-021, TP-D-009, TP-E-008, TP-F-012 | +| BUG-202607-03（跨模块数据不一致） | TP-C-002, TP-C-003, TP-D-011, TP-X-002 | +| BUG-202607-04（省份代码硬编码） | TP-B-004, TP-X-005 | + +## 漏测清单覆盖映射表 + +| 漏测项 | 覆盖测试点 | +| :--- | :--- | +| 空值/Null | TP-B-018 | +| 金额精度 | TP-C-002, TP-D-010, TP-E-007 | +| 重复提交/防抖 | TP-B-014, TP-C-021, TP-D-009, TP-E-008 | +| 超时处理 | TP-B-015, TP-B-016, TP-F-013 | +| 列表字段完整性 | TP-A-008, TP-C-004, TP-D-002, TP-E-002, TP-F-002, TP-G-005 | +| 查询重置 | TP-A-007 | +| 状态与按钮映射 | TP-A-010, TP-B-009 | +| 多阶段依赖链 | TP-B-005, TP-C-020, TP-D-005, TP-X-001 | +| 第三方核验逐项覆盖 | TP-C-006 ~ TP-C-019（7类核验×通过+异常=14个测试点）+ TP-C-026 ~ TP-C-049（API文档12项补充核验×通过+异常=24个测试点），共覆盖API文档17项核验 | 已覆盖 | +| 重试+手动触发并发 | TP-B-014, TP-C-021 | +| 跨模块数据一致性 | TP-C-002, TP-C-003, TP-X-002 | +| 省份/区域配置隔离 | TP-B-004, TP-X-005 | +| 上报数据字段溯源 | TP-C-002, TP-D-011, TP-X-002 | +| 标签颜色映射 | TP-A-009, TP-B-010, TP-C-005 | +| 详情弹窗分组完整性 | TP-A-011, TP-B-011, TP-B-012, TP-C-004, TP-D-003, TP-E-003, TP-F-004 | +| 轨迹数据边界（2~2000） | TP-C-018, TP-C-019 | +| 申诉闭环 | TP-F-001, TP-F-003, TP-F-006 | +| 操作日志可追溯 | TP-G-005, TP-G-006, TP-G-007, TP-G-008, TP-G-009 | + +--- + +> ⚠️ 待确认项： +> 1. 需求中"异常代码一览表"章节仅有标题无具体内容，需与产品确认完整的异常代码映射表后补充 TP-F-011 的详细验证数据。 +> 2. 自动重试的具体间隔时间（5s/15s/30s 为假设值），需与技术方案确认后更新 TP-B-007, TP-C-022, TP-D-007, TP-E-006 中的重试间隔。 +> 3. ETC税额边界值（0.01元 → 税额=0.00）的四舍五入规则需与财务确认，更新 TP-E-007。 +> 4. 申诉超时告警阈值（假设7个工作日）需与产品确认，更新 TP-F-013。 +> 5. 需求关联与冲突报告未识别到冲突项，建议在后续需求评审中人工确认安徽运八与现有云南运八上报逻辑是否存在字段/接口冲突。 diff --git a/output/versions/安徽运八需求/v5/安徽运八需求_测试用例.md b/output/versions/安徽运八需求/v5/安徽运八需求_测试用例.md new file mode 100644 index 0000000..7531de4 --- /dev/null +++ b/output/versions/安徽运八需求/v5/安徽运八需求_测试用例.md @@ -0,0 +1,428 @@ +# 安徽运八需求 测试用例 + +> 生成时间: 2026-07-13 +> 需求文档: output/normalized_inputs/安徽运八需求/requirement.md +> 测试点来源: output/test_points/安徽运八需求_测试点.md (106个测试点) +> 测试数据参考: output/analysis/安徽运八需求_测试数据.md +> 关联分析: output/analysis/安徽运八需求_关联与冲突.md +> +> 测试用例总数: 158 +> P0: 30 / P1: 85 / P2: 36 / P3: 8 +> 模块分布: A(看板)=18, B(第一次上报)=25, C(第二次上报)=50, D(第三次上报)=15, E(ETC)=12, F(申诉)=20, G(日志)=11, X(跨模块)=8 + +--- + +## 模块A: 上报运单看板 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_DASH_001 | 平台端-监管上报-上报看板 | 验证看板按完整运单号精确搜索运单 | P0 | 功能测试 | 1. 使用super_admin账号登录管理端https://ybxcx.ynyun8.com:8000/admin；2. 系统中存在运单号YB202607130001的运单记录 | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入完整运单号"YB202607130001"；3. 点击搜索按钮或按回车键 | 运单号: YB202607130001 | 页面列表仅展示1条记录，运单号列显示"YB202607130001"（精确匹配）；数据库查询返回唯一记录，where条件为waybill_no='YB202607130001' | 对应TP-A-001 | +| AH_REPORT_DASH_002 | 平台端-监管上报-上报看板 | 验证看板按运单号模糊搜索匹配多条记录 | P0 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在运单号包含"YB20260713"前缀的多条运单（如YB202607130001、YB202607130002、YB202607130003） | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入"YB20260713"；3. 点击搜索 | 运单号部分字符: YB20260713 | 页面列表展示3条记录，所有运单号均包含"YB20260713"；数据库查询SQL使用LIKE '%YB20260713%'匹配，返回3条结果 | 对应TP-A-001 | +| AH_REPORT_DASH_003 | 平台端-监管上报-上报看板 | 验证看板按不存在的单号搜索显示空结果 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端 | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入不存在的单号"NOTEXIST999"；3. 点击搜索 | 运单号: NOTEXIST999 | 页面列表显示空状态，提示"未找到匹配数据"或空结果占位图；数据库查询返回0条记录；页面不出现控制台报错 | 对应TP-A-001 | +| AH_REPORT_DASH_004 | 平台端-监管上报-上报看板 | 验证看板按"第一次上报"阶段筛选运单 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在不同上报阶段的运单（至少含1条第一次上报、1条第二次上报的运单） | 1. 进入"监管上报-上报看板"页面，默认为"全部"；2. 点击上报阶段下拉框，选择"第一次上报"；3. 观察列表数据 | 筛选条件: 第一次上报 | 列表仅展示上报阶段为"第一次上报"的运单；每条记录的上报阶段列均为"第一次上报"；数据库查询添加where report_stage='first'过滤条件；总条目数与数据库中第一次上报运单数一致 | 对应TP-A-002 | +| AH_REPORT_DASH_005 | 平台端-监管上报-上报看板 | 验证看板按"异常"核验状态筛选运单 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在核验状态为"通过"和"异常"的运单 | 1. 进入"监管上报-上报看板"页面；2. 点击核验状态下拉框，选择"异常"；3. 观察列表数据 | 筛选条件: 核验状态=异常 | 列表仅展示核验状态为"异常"（橙色标签）的运单；所有"通过"的运单被过滤；数据库查询添加where verification_status='abnormal'条件 | 对应TP-A-003 | +| AH_REPORT_DASH_006 | 平台端-监管上报-上报看板 | 验证看板按"申诉中"申诉状态筛选运单 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在申诉状态为"申诉中"的运单至少1条 | 1. 进入"监管上报-上报看板"页面；2. 点击申诉状态下拉框，选择"申诉中"；3. 观察列表数据并与全部列表对比 | 筛选条件: 申诉状态=申诉中 | 列表仅展示申诉状态为"申诉中"的运单；申诉状态列标签显示"申诉中"且颜色与需求定义一致；数据库查询添加where appeal_status='in_progress'条件 | 对应TP-A-004；⚠️ 待确认: 原型看板申诉状态下拉值为"未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回"，与需求不一致 | +| AH_REPORT_DASH_007 | 平台端-监管上报-上报看板 | 验证看板组合筛选—第二次上报+异常+申诉中+运单号模糊搜索 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 数据库中存在满足组合条件的运单（第二次上报、核验异常、申诉中、运单号含"YB2026"） | 1. 进入"监管上报-上报看板"页面；2. 上报阶段选"第二次上报"；3. 核验状态选"异常"；4. 申诉状态选"申诉中"；5. 运单号输入"YB2026"；6. 点击搜索 | 组合条件: 第二次上报+异常+申诉中; 运单号模糊: YB2026 | 列表仅展示同时满足4个条件的运单；每个条件都在数据库SQL中体现（多WHERE条件AND组合）；空结果时显示"未找到匹配数据"；切换任一筛选条件不丢失运单号搜索框中已输入的关键字 | 对应TP-A-005 | +| AH_REPORT_DASH_008 | 平台端-监管上报-上报看板 | 验证看板导出当前筛选结果为Excel文件 | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板列表中有≥20条运单数据 | 1. 进入"监管上报-上报看板"页面；2. 设置筛选条件（如上报阶段=第一次上报）；3. 点击"导出"按钮；4. 等待文件下载完成；5. 打开下载的Excel文件 | 筛选: 第一次上报 | 浏览器触发文件下载，文件名为.xlsx格式；Excel文件可正常打开，表头包含14个列表字段（货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、申诉状态、异常项、货物名称、合同金额、最新核验时间、操作）；导出数据行数与筛选结果一致；导出过程中页面不卡死、不超时 | 对应TP-A-006 | +| AH_REPORT_DASH_009 | 平台端-监管上报-上报看板 | 验证看板大数据量导出不超时不OOM | P2 | 性能测试 | 1. 使用super_admin账号登录管理端；2. 数据库中存在≥2000条运单记录 | 1. 进入"监管上报-上报看板"页面；2. 选择"全部"筛选条件；3. 点击"导出"按钮；4. 记录从点击到下载完成的时间 | 导出全部数据, 约2000+条 | 导出在60秒内完成下载（不超时）；导出的Excel文件包含全部数据行，无截断；后台服务内存使用率未显著增长（无OOM）；导出过程中看板页面仍可正常操作 | 对应TP-A-006 | +| AH_REPORT_DASH_010 | 平台端-监管上报-上报看板 | 验证看板重置按钮恢复所有查询条件至默认值 | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 已在上报阶段选择"第二次上报"、核验状态选择"异常"、运单号输入"YB2026" | 1. 进入"监管上报-上报看板"页面；2. 点击"重置"按钮；3. 观察页面各筛选条件和列表数据 | 重置前条件: 第二次上报+异常+YB2026 | 模糊搜索输入框清空为空白；所有下拉筛选恢复为"全部"；列表刷新展示默认全部运单数据（初始状态）；分页回到第1页；数据库查询恢复为无过滤条件的默认查询 | 对应TP-A-007 | +| AH_REPORT_DASH_011 | 平台端-监管上报-上报看板 | 验证看板列表展示14个字段且顺序与需求一致 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在至少1条完整运单记录 | 1. 进入"监管上报-上报看板"页面；2. 查看列表表头和第一条数据的各列内容；3. 对比需求文档中的字段顺序 | 查看运单YB202607130001 | 列表14个字段顺序为: 货源单号→运单号→托运单号→车牌号→司机姓名→托运方名称→上报阶段→核验状态→申诉状态→异常项→货物名称→合同金额→最新核验时间→操作；合同金额列保留2位小数（如¥10,000.00）；最新核验时间为YYYY-MM-DD HH:mm:ss格式；异常项为空时显示"-"而非"null"或"undefined" | 对应TP-A-008 | +| AH_REPORT_DASH_012 | 平台端-监管上报-上报看板 | 验证看板状态标签颜色—蓝色(上传中)、绿色(已上传)、红色(上传失败)、橙色(异常) | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在4种上报状态的运单各1条 | 1. 进入"监管上报-上报看板"页面；2. 找到上报状态为"上传中"的运单，查看标签颜色；3. 找到"已上传"运单，查看标签颜色；4. 找到"上传失败"运单，查看标签颜色；5. 找到"异常"运单，查看标签颜色 | 运单1: 上传中; 运单2: 已上传; 运单3: 上传失败; 运单4: 异常 | "上传中"标签显示蓝色背景/文字；"已上传"标签显示绿色背景/文字；"上传失败"标签显示红色背景/文字；"异常"标签显示橙色背景/文字；状态切换时标签颜色即时刷新不闪烁；申诉状态标签（申诉中/申诉通过/申诉驳回）颜色各自区分清晰 | 对应TP-A-009 | +| AH_REPORT_DASH_013 | 平台端-监管上报-上报看板 | 验证看板操作列—异常运单显示申诉按钮、所有运单显示详情按钮 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在核验通过的运单1条和核验异常的运单1条 | 1. 进入"监管上报-上报看板"页面；2. 查看核验通过运单的操作列按钮；3. 查看核验异常运单的操作列按钮；4. 点击异常运单的"申诉"按钮 | 通过运单: YB202607130001; 异常运单: YB202607130002 | 核验通过运单的操作列显示"详情"和"进度"按钮，不显示"申诉"按钮；核验异常运单的操作列显示"申诉""详情""进度"三个按钮；点击"申诉"按钮后页面路由跳转至申诉页面，URL携带正确的运单ID参数；点击"详情"按钮弹出详情弹窗，展示该运单的完整上报信息 | 对应TP-A-010 | +| AH_REPORT_DASH_014 | 平台端-监管上报-上报看板 | 验证看板详情弹窗—建单信息分组13字段完整 | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板列表中有可查看详情的运单YB202607130001 | 1. 进入"监管上报-上报看板"页面；2. 点击运单YB202607130001操作列的"详情"按钮；3. 在弹窗中查看"建单信息"分组的所有字段 | 运单号: YB202607130001 | 建单信息分组展示13个字段: 上游企业委托运输单号、本运单单号、托运人建单时间、网络货运经营者名称、统一社会信用代码、道路运输经营许可证编号、业务类型代码、运输组货方式代码、司机接单时间、司机起运时间、承运合同编号（必选）、委托合同编号（可选）、运输里程（可选）；必选字段均有值；可选字段委托合同编号和运输里程为空时显示"-"；各字段格式与接口规范一致 | 对应TP-A-011 | +| AH_REPORT_DASH_015 | 平台端-监管上报-上报看板 | 验证看板详情弹窗—各子对象分组字段完整(托运人/收货方/司机/车辆/货物) | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板列表中有运单YB202607130001包含完整的子对象信息 | 1. 进入"监管上报-上报看板"页面；2. 点击运单YB202607130001的"详情"按钮；3. 依次展开托运人信息、收货方信息、司机信息、车辆信息、货物信息分组 | 运单号: YB202607130001; 司机: 15188888888 | 托运人信息7字段完整（含统一社会信用代码18位格式校验）；收货方信息5字段完整（身份证号如适用需脱敏展示）；司机信息13字段完整（从业资格证有效期起止日期格式正确）；车辆信息19字段完整（VIN码17位正确展示）；货物信息支持多条记录展开，每条含货物名称、货物类型代码、货物量、计量单位；可选字段为空时显示"-" | 对应TP-A-011 | +| AH_REPORT_DASH_016 | 平台端-监管上报-上报看板 | 验证看板空数据状态展示友好占位提示 | P3 | 易用性测试 | 1. 使用super_admin账号登录管理端；2. 选择一个筛选条件组合确保结果为0条（如运单号输入"ZZZZZZZZZZ"） | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框输入"ZZZZZZZZZZ"；3. 点击搜索 | 运单号: ZZZZZZZZZZ | 列表区域显示友好空状态占位图/文，不显示空白表格；有明确文字提示"未找到匹配数据"或类似文案；浏览器开发者工具Console无报错；页面无崩溃或白屏 | 对应TP-A-012 | +| AH_REPORT_DASH_017 | 平台端-监管上报-上报看板 | 验证看板分页功能—翻页数据不重复不遗漏 | P3 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板中有超过20条运单（默认每页20条） | 1. 进入"监管上报-上报看板"页面，记录第1页的运单号列表；2. 点击"下一页"进入第2页；3. 记录第2页的运单号列表；4. 对比两页数据；5. 查看分页组件显示的总条数 | 每页20条 | 第1页和第2页的运单号无重复；第2页首条数据不是第1页已出现的数据；切换每页条数（如50条/页）后分页重新计算正确；分页组件显示的总条数与数据库COUNT查询结果一致；数据按最新核验时间倒序排列（最近核验的在最前面） | 对应TP-A-013 | +| AH_REPORT_DASH_018 | 平台端-监管上报-上报看板 | 验证不同角色看板权限—运营可见全部/财务可见打款字段/司机不可见平台端看板 | P1 | 安全性测试 | 1. 准备super_admin账号(运营)、财务账号、车队长账号13113113113、司机账号15188888888；2. 系统中存在运单数据 | 1. 使用super_admin登录，进入看板，验证可见全部运单和全部字段；2. 使用财务账号登录，进入看板，验证可见运单范围和打款相关字段；3. 使用车队长13113113113登录司机端，验证是否有看板入口；4. 使用司机15188888888登录司机端，验证是否有看板入口 | 运营: super_admin; 财务: finance_user; 车队长: 13113113113/88888888; 司机: 15188888888/88888888 | super_admin可见全部运单和全部14个字段；财务可见运单但打款金额/付款方式/收款账号类型等字段可见；车队长登录司机端后无"监管上报-上报看板"菜单入口，直接URL访问被拦截返回403；司机登录司机端后同样无看板入口，越权访问被拦截并记录审计日志 | 对应TP-A-014 | + +--- + +## 模块B: 第一次上报-装货完成 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_R1_001 | 平台端-监管上报-第一次上报 | 验证装货完成后自动触发第一次上报且全部子对象数据完整 | P0 | 功能测试 | 1. 使用司机账号15188888888登录司机端APP；2. 存在一条安徽税源地(provinceCode=34)的运单YB202607130001，状态为"待装货"；3. 运单包含完整的托运人、收货方、司机、车辆、货物信息 | 1. 司机到达装货地，上传装货照片和资料；2. 司机在APP端点击"确认装货完成"；3. 等待系统自动触发第一次上报；4. 使用super_admin登录管理端，进入"监管上报-第一次上报"列表查看该运单上报状态 | 运单号: YB202607130001; 司机: 15188888888; 装货地省份代码: 34 | 司机端提示"装货完成，上报已提交"；管理端第一次上报列表中出现该运单记录，上报状态为"上传中"（蓝色标签），随后变为"已上传"（绿色标签）；上报请求JSON包含全部7个子对象(建单信息/托运人/收货方/司机/车辆/货物/保险)；数据库report_record表status字段从0变为1，上报时间字段非空 | 对应TP-B-001 | +| AH_REPORT_R1_002 | 平台端-监管上报-第一次上报 | 验证非安徽税源地运单(云南=28)装货完成后不触发第一次上报 | P0 | 功能测试 | 1. 使用司机账号15188888888登录司机端APP；2. 存在一条云南税源地(provinceCode=28)的运单YB202607130002，状态为"待装货" | 1. 司机完成装货并点击"确认装货完成"；2. 检查管理端"监管上报-第一次上报"列表；3. 检查系统日志是否有上报请求记录 | 运单号: YB202607130002; 省份代码: 28(云南) | 管理端第一次上报列表中不出现该运单记录；系统日志中无该运单的上报接口调用记录；运单状态正常流转为"运输中"，不受上报模块影响；无任何错误日志或异常告警产生 | 对应TP-B-002 | +| AH_REPORT_R1_003 | 平台端-监管上报-第一次上报 | 验证安徽税源地运单(省份代码=34)触发上报，其他省份不触发 | P0 | 功能测试 | 1. 准备安徽(34)、云南(28)、四川(51)税源地的运单各1条；2. 三条运单状态均为"待装货" | 1. 分别对三条运单确认装货完成；2. 进入管理端第一次上报列表查看；3. 查询数据库report_record表 | 安徽运单: provinceCode=34; 云南运单: provinceCode=28; 四川运单: provinceCode=51 | 仅安徽(34)运单在第一次上报列表中出现，上报状态正常更新；云南(28)和四川(51)运单均不在列表中；数据库report_record表仅新增1条记录，province_code=34 | 对应TP-B-002; TP-B-004 | +| AH_REPORT_R1_004 | 平台端-监管上报-第一次上报 | 验证第一次上报建单信息必选字段缺失时上报被拒绝并明确提示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 构造一条建单信息中"承运合同编号"为空的运单YB202607130003 | 1. 触发该运单装货完成事件（模拟或真实操作）；2. 查看第一次上报返回结果；3. 查看上报日志中的错误信息 | 运单号: YB202607130003; 缺失字段: 承运合同编号 | 上报接口返回错误，提示"必选字段承运合同编号不能为空"或类似明确消息；上报状态标记为"上传失败"（红色标签）；上报日志中记录该次失败请求，包含请求体和错误响应体；运单状态不会错误地标记为"已上传" | 对应TP-B-003 | +| AH_REPORT_R1_005 | 平台端-监管上报-第一次上报 | 验证第一次上报统一社会信用代码格式校验（非18位时拒绝） | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 构造一条运单，托运人统一社会信用代码为"123456"（6位无效格式） | 1. 触发该运单装货完成事件；2. 查看上报接口返回；3. 查看上报日志 | 运单号: YB202607130004; 信用代码: 123456(无效) | 上报接口返回校验错误，提示"统一社会信用代码格式不正确，需为18位"；上报状态标记为"上传失败"；不会错误地将无效代码上报至监管平台 | 对应TP-B-003 | +| AH_REPORT_R1_006 | 平台端-监管上报-第一次上报 | 验证第一次上报中司机信息省份代码为安徽=34（非云南=28） | P0 | 功能测试 | 1. 使用super_admin登录管理端；2. 准备一条安徽税源地(34)的完整运单YB202607130001 | 1. 触发的第一次上报完成后；2. 在上报日志中查看该次上报的完整请求JSON；3. 定位司机信息(driverInfo)中的provinceCode字段值 | 运单号: YB202607130001; 期望省份代码: 34 | 请求JSON中driverInfo.provinceCode="34"；不会出现值"28"；装货地行政区划代码前2位也为"34"（安徽省代码340000）；数据库/Redis/配置文件中无硬编码省份代码28 | [AI修正: 历史缺陷防御] - BUG-202607-04 | +| AH_REPORT_R1_007 | 平台端-监管上报-第一次上报 | 验证第一次上报失败后第二次上报接口被拒绝并返回错误码"前置上报未完成" | P0 | 功能测试 | 1. 运单YB202607130005第一次上报状态为"上传失败"（3次重试均失败）；2. 财务已完成打款（触发第二次上报的条件已满足） | 1. 通过API直接调用第二次上报接口（或模拟打款完成回调触发）；2. 查看接口返回的HTTP状态码和错误消息 | 运单号: YB202607130005 | 接口返回错误码（如HTTP 400或业务错误码"PRE_STAGE_NOT_COMPLETED"），错误消息包含"前置上报未完成"或"请先完成第一次上报"；第二次上报列表中该运单上报状态未变更，不会出现"上传中"或"已上传"；数据库report_record表无第二次上报的新记录 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R1_008 | 平台端-监管上报-第一次上报 | 验证第一次上报自动重试3次全部失败后第三次上报同样被拒绝 | P0 | 功能测试 | 1. 运单YB202607130006第一次上报3次重试全部失败；2. 第二次上报也未完成 | 1. 通过API直接调用第三次上报接口；2. 查看接口返回 | 运单号: YB202607130006 | 接口返回错误码，明确标识"前置上报（第一次）未完成"；后端通过查询运单上报状态表(如report_status)做校验，非仅依赖前端布尔值；第三次上报列表无该运单记录 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R1_009 | 平台端-监管上报-第一次上报 | 验证第一次上报成功后监管平台核验通过时自动调用修改字段接口 | P1 | 功能测试 | 1. 运单YB202607130001第一次上报成功且状态为"已上传"；2. 模拟监管平台返回核验通过 | 1. 等待或模拟监管平台核验通过回调；2. 查看上报日志中是否有"修改第一次上报部分字段"的接口调用记录；3. 查看修改后的字段值 | 运单号: YB202607130001; 实际运输里程: 158.5km（装货后变化值） | 上报日志中出现"修改字段"接口调用记录；修改的字段包含实际运输里程等装货后变化字段；修改成功后第一次上报状态仍保持"已上传"（绿色）；若修改接口调用失败，有重试和告警机制 | 对应TP-B-006 | +| AH_REPORT_R1_010 | 平台端-监管上报-第一次上报 | 验证第一次上报失败后自动重试最多3次且间隔递增 | P1 | 功能测试 | 1. 运单YB202607130007第一次上报时模拟监管平台返回失败 | 1. 触发第一次上报；2. 监控上报日志中的重试记录和时间间隔；3. 等待3次重试全部完成 | 运单号: YB202607130007; 重试间隔: 5s/15s/30s（参考值） | 第1次上报失败后自动触发第2次（间隔约5s）；第2次失败后触发第3次（间隔约15s）；第3次失败后触发第4次（即总共3次重试，间隔约30s）；3次重试全部失败后上报状态变为"上传失败"（红色标签），停止重试；上报日志中每1次请求（含重试）均有独立日志记录 | 对应TP-B-007 | +| AH_REPORT_R1_011 | 平台端-监管上报-第一次上报 | 验证第一次上报3次重试全部失败后通知运营人员 | P1 | 功能测试 | 1. 运单YB202607130008第一次上报3次重试均失败；2. super_admin账号可接收站内信 | 1. 等待3次重试全部失败；2. 使用super_admin登录管理端，查看站内信/消息通知；3. 点击通知中的链接 | 运单号: YB202607130008; 失败原因: 监管平台连接超时 | super_admin收到站内信通知，标题含"上报失败"标记；通知内容包含运单号YB202607130008、失败原因"连接超时"、失败时间；点击通知中的链接可直接跳转到该运单对应的上报详情页 | 对应TP-B-008 | +| AH_REPORT_R1_012 | 平台端-监管上报-第一次上报 | 验证上传失败状态下运营人员可点击手动上传按钮重新发起上报 | P1 | 功能测试 | 1. 运单YB202607130009上报状态为"上传失败"（红色标签）；2. 使用super_admin登录管理端 | 1. 进入"监管上报-第一次上报"列表；2. 找到YB202607130009，查看操作列；3. 点击"手动上传"按钮；4. 确认上传；5. 等待上传完成 | 运单号: YB202607130009 | 操作列显示"手动上传"按钮（仅上传失败状态可见）；点击后发起新的上报请求；上传成功后状态从"上传失败"（红色）变为"已上传"（绿色）；手动上传记录出现在上报日志中，标注操作人为"super_admin" | 对应TP-B-009 | +| AH_REPORT_R1_013 | 平台端-监管上报-第一次上报 | 验证自动重试期间点击手动上传时系统提示"上报处理中"并拒绝重复提交 | P0 | 功能测试 | 1. 运单YB202607130010第一次上报正在自动重试中（第1次已失败，第2次进行中）；2. 使用super_admin登录管理端 | 1. 进入第一次上报列表，找到该运单；2. 等待自动重试进行中时，快速点击"手动上传"按钮 | 运单号: YB202607130010 | 前端弹出提示"上报处理中，请勿重复操作"或按钮被置灰不可点击；后端返回"上报处理中"错误（分布式锁检测到正在进行中的上报）；数据库report_record表中该运单不会产生第2条上报记录；最终仅有1条上报记录（自动重试完成后产生） | [AI修正: 历史缺陷防御] - BUG-202607-02 | +| AH_REPORT_R1_014 | 平台端-监管上报-第一次上报 | 验证同一运单同一阶段快速连续点击手动上传仅发起1次请求 | P0 | 功能测试 | 1. 运单YB202607130011上报状态为"上传失败"；2. 使用super_admin登录管理端 | 1. 进入第一次上报列表；2. 快速连续点击"手动上传"按钮5次（模拟前端未做防抖的情况或快速双击）；3. 查看上报日志中实际发出的请求次数 | 运单号: YB202607130011; 快速点击5次 | 上报日志中仅记录1次上报请求（前端防抖+后端幂等键控制）；数据库report_record表仅产生1条新的上报记录；后端分布式锁或唯一约束（如运单号+阶段号）防止并发插入重复记录 | [AI修正: 历史缺陷防御] - BUG-202607-02 | +| AH_REPORT_R1_015 | 平台端-监管上报-第一次上报 | 验证第一次上报接口超时(>30s)后转为上传失败并触发重试 | P1 | 功能测试 | 1. 运单YB202607130012准备上报；2. 通过工具模拟监管平台接口响应延迟>30秒 | 1. 触发第一次上报；2. 观察前端页面Loading状态；3. 等待超时后的系统处理 | 运单号: YB202607130012; 超时阈值: 30s | 前端页面显示Loading加载状态并持续至超时；超时后上报状态变为"上传失败"（红色标签）；前端页面超时后有友好提示"上报超时，系统将自动重试"；系统自动触发第1次重试；数据库report_record表中记录超时状态 | 对应TP-B-015 | +| AH_REPORT_R1_016 | 平台端-监管上报-第一次上报 | 验证弱网环境(高延迟高丢包)下第一次上报重试机制正常工作 | P2 | 功能测试 | 1. 通过Charles/Fiddler或网络模拟工具设置网络延迟2000ms、丢包率30%；2. 运单YB202607130013待上报 | 1. 在弱网条件下触发第一次上报；2. 观察上报请求发送和响应情况；3. 等待重试或恢复 | 运单号: YB202607130013; 网络延迟: 2000ms; 丢包率: 30% | 请求发送成功但响应延迟时不立即判定失败（超时阈值30s）；弱网恢复后若重试成功则状态正常流转为"已上传"；断网时上报请求发送失败的提示友好明确；不论弱网还是正常网络，数据不会出现不一致或重复 | 对应TP-B-016 | +| AH_REPORT_R1_017 | 平台端-监管上报-第一次上报 | 验证10个运单同时装货完成时并发上报互不干扰 | P2 | 性能测试 | 1. 准备10条安徽税源地(34)的运单YB202607130014~YB202607130023，状态均为"待装货" | 1. 通过脚本同时触发10条运单的装货完成事件；2. 监控数据库和上报日志；3. 验证每条运单的上报状态 | 10条运单同时装货完成 | 10条运单各自独立触发上报，无相互阻塞；数据库无死锁(deadlock)异常；上报日志中每条运单独立记录其上报请求和响应；每条运单的上报状态独立正确更新 | 对应TP-B-017 | +| AH_REPORT_R1_018 | 平台端-监管上报-第一次上报 | 验证第一次上报可选字段（委托合同编号/运输里程/挂车牌照号等）为空时正常上报 | P3 | 功能测试 | 1. 准备一条运单YB202607130024，可选字段全部留空：委托合同编号、运输里程、挂车牌照号、行驶证档案编号、道路运输证有效期起/至、保险单号、保险公司名称 | 1. 触发该运单装货完成事件；2. 查看上报结果；3. 查看上报请求JSON和详情弹窗 | 运单号: YB202607130024; 可选字段全为空 | 上报接口不报错，上报成功；请求JSON中可选字段值为null或不传均可正常处理；管理端详情弹窗中可选字段显示"-"而非"null"或"undefined" | 对应TP-B-018 | +| AH_REPORT_R1_019 | 平台端-监管上报-第一次上报 | 验证运单包含1条货物记录时正常上报 | P3 | 功能测试 | 1. 准备运单YB202607130025，仅含1条货物：货物名称"钢材"、货物类型代码"01"、货物量"10.5"、计量单位"吨" | 1. 触发装货完成；2. 查看上报请求JSON中goodsInfos数组；3. 查看详情弹窗货物信息展示 | 运单号: YB202607130025; 货物: 钢材 10.5吨 | goodsInfos数组包含1个元素，4个字段完整；详情弹窗中货物信息分组正确展示1条记录 | 对应TP-B-019 | +| AH_REPORT_R1_020 | 平台端-监管上报-第一次上报 | 验证运单包含5条货物记录时各货物独立完整上报 | P3 | 功能测试 | 1. 准备运单YB202607130026，含5条货物记录：钢材10.5吨、水泥20吨、砂石15吨、砖块5000块、木材8立方 | 1. 触发装货完成；2. 查看上报请求JSON中goodsInfos数组长度和内容；3. 查看详情弹窗中多条货物的展示 | 运单号: YB202607130026; 货物: 5条 | goodsInfos数组包含5个元素；每条货物独立完整，互不影响；详情弹窗中货物信息支持展开/折叠展示5条记录；每条货物名称、类型代码、货物量、计量单位均正确 | 对应TP-B-019 | +| AH_REPORT_R1_021 | 平台端-监管上报-第一次上报 | 验证第一次上报业务类型代码和运输组货方式代码为有效枚举值 | P1 | 功能测试 | 1. 准备运单YB202607130027，业务类型代码为"1"(普通货运)、运输组货方式代码为"10"(道路货运) | 1. 触发装货完成上报；2. 查看上报请求JSON中waybillInfo的businessTypeCode和transportGroupModeCode字段值；3. 模拟提交无效枚举值（如"99"），验证拒绝 | 运单号: YB202607130027; businessTypeCode: 1; transportGroupModeCode: 10 | 有效枚举值上报成功；无效枚举值（如businessTypeCode="99"）上报时接口返回校验错误，明确提示"业务类型代码无效"；不会将无效枚举值上报至监管平台 | 对应TP-B-003 | +| AH_REPORT_R1_022 | 平台端-监管上报-第一次上报 | 验证第一次上报详情弹窗—异常信息分组展示核验状态/异常原因/异常时间/处理状态 | P2 | 功能测试 | 1. 运单YB202607130028第一次上报核验状态为"异常"；2. 使用super_admin登录管理端 | 1. 进入第一次上报列表，点击运单YB202607130028的"详情"按钮；2. 查看弹窗中"异常信息"分组的4个字段 | 运单号: YB202607130028; 异常原因示例: 司机资质核验不通过 | 异常信息分组包含: 核验状态（显示"异常"）、异常原因（如"司机从业资格证已过期"）、异常时间（显示实际核验时间）、处理状态（如"未申诉"）；核验通过时异常原因为空 | 对应TP-B-013 | +| AH_REPORT_R1_023 | 平台端-监管上报-第一次上报 | 验证第一次上报状态标签颜色：上传中=蓝色、已上传=绿色、上传失败=红色、异常=橙色 | P2 | 功能测试 | 1. 准备4条运单各处于不同上报状态 | 1. 进入第一次上报列表；2. 依次查看4种状态运单的标签颜色 | 运单A: 上传中; 运单B: 已上传; 运单C: 上传失败; 运单D: 异常 | 上传中=蓝色标签+加载动画；已上传=绿色标签；上传失败=红色标签；异常=橙色标签；状态切换时标签颜色即时更新不闪烁 | 对应TP-B-010 | +| AH_REPORT_R1_024 | 平台端-监管上报-第一次上报 | 验证第一次上报列表14个字段完整展示且顺序正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 第一次上报列表中有至少1条完整记录 | 1. 进入"监管上报-第一次上报"列表；2. 查看列表表头和第一条数据的所有列内容；3. 验证每个字段的展示格式 | 运单号: YB202607130001; 运输里程: 350km; 合同编号: HT202607001 | 列表展示14个字段: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/业务类型/货物名称/装货地址/卸货地址/运输里程/合同编号/上报状态/操作；业务类型与数据字典中枚举值一致；装货地址和卸货地址完整展示（省市区+详细地址）；运输里程带单位km；上报状态标签颜色符合规范（上传中=蓝色/已上传=绿色/上传失败=红色/异常=橙色）；列表按上报时间倒序排列 | 对应TP-B-020；[AI修正: 覆盖缺口补充] | +| AH_REPORT_R1_025 | 平台端-监管上报-第一次上报 | 验证未上传委托合同（框架）时第一次上报被拒绝并提示需要先上传委托合同 | P0 | 功能测试 | 1. 系统中存在一条安徽税源地(34)的运单YB202607130092；2. 该运单对应的货主尚未上传委托合同（框架） | 1. 触发运单装货完成事件；2. 查看第一次上报的返回结果；3. 查看上报日志中的错误信息 | 运单号: YB202607130092; 委托合同状态: 未上传 | 第一次上报接口返回错误，消息明确提示"请先上传委托合同（框架）"或类似文案；上报状态标记为"上传失败"（红色标签）；上报日志中记录该次失败，错误原因明确；上传委托合同后重试第一次上报可成功 | 对应TP-B-021；[技术方案] showdoc文档委托合同前置条件 | +| AH_REPORT_R1_026 | 平台端-监管上报-第一次上报 | 验证委托合同（框架）支持关联多家托运企业—enterpriseList多企业列表上传 | P1 | 功能测试 | 1. 使用super_admin登录管理端或通过API；2. 准备3家货主企业信息（统一社会信用代码+企业名称） | 1. 调用委托合同（框架）上传接口POST /api/dataUpload/mandateContractFrame；2. 传入enterpriseList（含3家企业）、contract_number、expire_time；3. 查看接口返回；4. 再传入unified_social_credit_identifier（单企业）+enterpriseList（多企业）同时传值 | 合同编号: FRAME202607001; enterpriseList: [企业A(9134XXXXXXXXXX01), 企业B(9134XXXXXXXXXX02), 企业C(9134XXXXXXXXXX03)] | enterpriseList仅传时上报成功，3家企业均关联至该框架合同；同时传unified_social_credit_identifier和enterpriseList时默认取单企业（enterpriseList被忽略）；上传后第一次上报时consignorInfo中frameContractNumber与该框架合同编号一致即可通过 | 对应TP-B-022；[技术方案] showdoc文档mandateContractFrame | + +--- + +## 模块C: 第二次上报-打款完成 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_R2_001 | 平台端-监管上报-第二次上报 | 验证财务打款完成后自动触发第二次上报且包含资金流水和车辆轨迹信息 | P0 | 功能测试 | 1. 运单YB202607130001已完成第一次上报且状态为"已上传"；2. 财务在账户管理模块对该运单执行打款操作，金额¥10,000.00 | 1. 财务完成打款操作；2. 系统收到打款完成回调；3. 进入管理端"监管上报-第二次上报"列表查看 | 运单号: YB202607130001; 打款金额: ¥10,000.00; 付款方式: 光大银行 | 第二次上报列表中新增该运单记录，上报状态从"上传中"变为"已上传"（绿色标签）；上报请求包含运单信息+资金流水信息+车辆轨迹信息三个模块；数据库report_record表新增第二次上报记录，stage=2 | 对应TP-C-001 | +| AH_REPORT_R2_002 | 平台端-监管上报-第二次上报 | 验证第二次上报资金流水数据来源于支付流水表（非运单缓存） | P0 | 功能测试 | 1. 运单YB202607130001合同金额¥10,000.00；2. 支付流水表实际打款金额¥10,000.00；3. 财务已打款完成 | 1. 触发第二次上报；2. 查询上报日志中的请求JSON；3. 对比请求中的金额与运单表合同金额、支付流水表打款金额；4. 检查数据库查询SQL日志确认数据来源 | 运单号: YB202607130001; 合同金额: ¥10,000.00; 支付流水实际打款: ¥10,000.00 | 上报数据中的金额与支付流水表实际打款金额¥10,000.000完全一致；数据库查询SQL日志显示数据源为payment_flow表，非waybill表或Redis缓存；金额保留3位小数（如10000.000），无精度丢失 | [AI修正: 历史缺陷防御] - BUG-202607-03；[技术方案] 第二次上报金额精度3位小数 | +| AH_REPORT_R2_003 | 平台端-监管上报-第二次上报 | 验证财务修改打款金额后第二次上报使用最新金额（非缓存合同金额），精度3位小数 | P0 | 功能测试 | 1. 运单YB202607130001合同金额¥10,000.000；2. 财务在账户管理模块调账将打款金额修改为¥9,500.000；3. 财务执行打款 | 1. 财务修改打款金额（¥10,000.000→¥9,500.000）；2. 财务完成打款；3. 触发第二次上报；4. 查看上报请求中的金额字段 | 运单号: YB202607130001; 合同金额: ¥10,000.000; 修改后打款金额: ¥9,500.000 | 上报请求中的金额为¥9,500.000（修改后的值，3位小数），非¥10,000.000（合同金额）；上报日志中可溯源金额来源为支付流水表；不会使用装货完成时缓存的合同金额 | [AI修正: 历史缺陷防御] - BUG-202607-03；[技术方案] 第二次上报金额精度3位小数 | +| AH_REPORT_R2_004 | 平台端-监管上报-第二次上报 | 验证第二次上报列表17个字段完整且收款账号类型标签颜色正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 第二次上报列表中有至少2条数据（一条个人账户、一条对公账户） | 1. 进入"监管上报-第二次上报"列表；2. 查看列表表头和第一条数据的各列内容；3. 查看收款账号类型列的标签颜色 | 运单A: 个人账户(司机银行卡); 运单B: 对公账户(企业账号) | 列表展示: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/承运运费/总金额/付款方式/付款时间/收款人/收款账号/收款账号类型/核验状态/异常项/上报状态/操作；承运运费和总金额保留**3位小数**（如¥10,000.000）；付款时间为实际财务打款时间；个人账户显示蓝色标签，对公账户显示绿色标签 | 对应TP-C-004; TP-C-005；[技术方案] 第二次上报金额精度3位小数 | +| AH_REPORT_R2_005 | 平台端-监管上报-第二次上报 | 验证运单重复核验—首次上报的运单核验通过 | P0 | 功能测试 | 1. 运单YB202607130001为首次进行第二次上报，此前未在任何阶段重复上报 | 1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项 | 运单号: YB202607130001(首次上报) | 核验状态标记为"通过"（绿色标签）；异常项列中无"运单重复核验"异常记录；监管平台返回的核验结果中duplicateCheck=pass；数据库运单核验记录表verification_result中duplicate_check_status='pass' | 对应TP-C-006 | +| AH_REPORT_R2_006 | 平台端-监管上报-第二次上报 | 验证运单重复核验—重复上报检测到异常并标注异常项 | P0 | 功能测试 | 1. 运单YB202607130001已成功完成第二次上报和核验；2. 模拟或真实触发该运单的第二次重复上报 | 1. 通过API再次调用第二次上报接口（使用同一运单号YB202607130001）；2. 等待监管平台核验结果返回 | 运单号: YB202607130001(重复上报) | 核验状态变为"异常"（橙色标签）；异常项列明确标注"运单重复核验"；异常原因可读（如"该运单已存在有效上报记录"）；该异常运单可触发申诉流程，"申诉"按钮可见可用 | 对应TP-C-007 | +| AH_REPORT_R2_007 | 平台端-监管上报-第二次上报 | 验证车辆资质核验—道路运输证在有效期内核验通过 | P1 | 功能测试 | 1. 运单YB202607130001关联的车辆道路运输证有效期起: 2025-01-01, 有效期至: 2027-01-01（当前日期2026-07-13在有效期内）；2. 车辆审核状态为"通过" | 1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项 | 运单号: YB202607130001; 道路运输证有效期: 2025-01-01~2027-01-01 | 核验状态为"通过"；无"车辆资质核验"异常项；监管平台返回vehicleQualCheck=pass；数据库verification_result.vehicle_qual_status='pass' | 对应TP-C-008 | +| AH_REPORT_R2_008 | 平台端-监管上报-第二次上报 | 验证车辆资质核验—道路运输证已过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130029关联的车辆道路运输证有效期至: 2025-12-31（当前日期2026-07-13已过期）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果返回；3. 查看异常项详情 | 运单号: YB202607130029; 道路运输证有效期至: 2025-12-31(已过期) | 核验状态变为"异常"（橙色标签）；异常项列标注"车辆资质核验"；异常原因描述如"道路运输证已过期（有效期至2025-12-31）"；该异常运单可发起申诉 | 对应TP-C-009 | +| AH_REPORT_R2_009 | 平台端-监管上报-第二次上报 | 验证司机资质核验—从业资格证在有效期内核验通过 | P1 | 功能测试 | 1. 运单YB202607130001关联的司机从业资格证有效期起: 2024-06-01, 有效期至: 2028-06-01（在有效期内）；2. 司机审核状态为"通过" | 1. 触发第二次上报；2. 等待核验结果；3. 查看核验状态 | 运单号: YB202607130001; 从业资格证: 有效期内 | 核验状态为"通过"；无"司机资质核验"异常项；监管平台返回driverQualCheck=pass | 对应TP-C-010 | +| AH_REPORT_R2_010 | 平台端-监管上报-第二次上报 | 验证司机资质核验—从业资格证已过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130030关联的司机从业资格证有效期至: 2025-01-01（已过期）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果；3. 查看异常项 | 运单号: YB202607130030; 从业资格证有效期至: 2025-01-01(已过期) | 核验状态变为"异常"；异常项标注"司机资质核验"；异常原因如"司机从业资格证已过期"；可发起申诉 | 对应TP-C-011 | +| AH_REPORT_R2_011 | 平台端-监管上报-第二次上报 | 验证集中支付核验—付款方为平台统一账户时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001打款付款方为网货平台统一账户；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130001; 付款方: 网货平台统一账户 | 核验状态为"通过"；无"集中支付核验"异常项；监管平台返回centralPayCheck=pass；支付流水记录与集中支付模式匹配 | 对应TP-C-012 | +| AH_REPORT_R2_012 | 平台端-监管上报-第二次上报 | 验证集中支付核验—付款方非平台统一账户时核验异常 | P1 | 功能测试 | 1. 运单YB202607130031打款付款方为非平台统一账户（如第三方代付账户）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130031; 付款方: 第三方代付账户(非平台) | 核验状态变为"异常"；异常项标注"集中支付核验"；异常原因如"付款方非集中支付账户"；可发起申诉 | 对应TP-C-013 | +| AH_REPORT_R2_013 | 平台端-监管上报-第二次上报 | 验证资金流水核验—流水号唯一且金额匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001资金流水号唯一（如PAY202607130001）；2. 上报金额¥10,000.00与支付流水表实际打款金额完全一致 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130001; 流水号: PAY202607130001; 金额: ¥10,000.00 | 核验状态为"通过"；无"资金流水核验"异常项；监管平台返回fundFlowCheck=pass | 对应TP-C-014 | +| AH_REPORT_R2_014 | 平台端-监管上报-第二次上报 | 验证资金流水核验—流水号重复时核验异常 | P1 | 功能测试 | 1. 运单YB202607130032使用的资金流水号与已有运单的流水号重复（如均使用PAY202607130001） | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130032; 重复流水号: PAY202607130001 | 核验状态变为"异常"；异常项标注"资金流水核验"；异常原因包含"流水号重复"提示；可发起申诉 | 对应TP-C-015 | +| AH_REPORT_R2_015 | 平台端-监管上报-第二次上报 | 验证资金流水核验—上报金额与支付流水偏差>0.01元时核验异常 | P1 | 功能测试 | 1. 运单YB202607130033支付流水表实际打款¥9,500.00，但上报时发送¥10,000.00（偏差¥500.00>¥0.01） | 1. 触发第二次上报（携带错误金额）；2. 等待核验结果 | 运单号: YB202607130033; 上报金额: ¥10,000.00; 支付流水实际: ¥9,500.00 | 核验状态变为"异常"；异常项标注"资金流水核验"；异常原因包含"金额不匹配"提示；可发起申诉 | 对应TP-C-015 | +| AH_REPORT_R2_016 | 平台端-监管上报-第二次上报 | 验证合同核验—承运合同和委托合同均有效时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001承运合同编号CTC202607001有效（存在于合同管理系统，有效期覆盖运单执行日期2026-07-10~2026-07-13）；2. 委托合同编号DLC202607001有效（如适用） | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130001; 承运合同: CTC202607001(有效); 委托合同: DLC202607001(有效) | 核验状态为"通过"；无"合同核验"异常项；监管平台返回contractCheck=pass | 对应TP-C-016 | +| AH_REPORT_R2_017 | 平台端-监管上报-第二次上报 | 验证合同核验—承运合同不存在时核验异常 | P1 | 功能测试 | 1. 运单YB202607130034关联的承运合同编号INVALID_CTC999不存在于合同管理系统 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130034; 承运合同: INVALID_CTC999(不存在) | 核验状态变为"异常"；异常项标注"合同核验"；异常原因包含"承运合同不存在"提示；可发起申诉 | 对应TP-C-017 | +| AH_REPORT_R2_018 | 平台端-监管上报-第二次上报 | 验证合同核验—合同有效期不覆盖运单执行日期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130035执行日期为2026-07-10~2026-07-13，但关联的承运合同有效期至2026-06-30（已过期不覆盖运单执行日期） | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130035; 承运合同有效期: ~2026-06-30(不覆盖运单日期) | 核验状态变为"异常"；异常项标注"合同核验"；异常原因包含"合同已过期"或"合同有效期不覆盖运单执行日期"；可发起申诉 | 对应TP-C-017 | +| AH_REPORT_R2_019 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点≥2且≤2000且路线匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001车辆GPS轨迹包含500个有效轨迹点；2. 轨迹路线与装货地→卸货地路线基本一致；3. 轨迹时间与运单执行时间匹配 | 1. 触发第二次上报（携带500点轨迹数据）；2. 等待核验结果 | 运单号: YB202607130001; 轨迹点数: 500 | 核验状态为"通过"；无"车辆轨迹合规核验"异常项；监管平台返回trackCheck=pass | 对应TP-C-018 | +| AH_REPORT_R2_020 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点边界值2个点时核验通过 | P2 | 功能测试 | 1. 运单YB202607130036车辆GPS轨迹仅包含2个有效轨迹点（起终点，边界最小值） | 1. 触发第二次上报（携带2点轨迹数据）；2. 等待核验结果 | 运单号: YB202607130036; 轨迹点数: 2(边界最小值) | 核验状态为"通过"；无"车辆轨迹合规核验"异常项；边界值2个点被正确处理 | 对应TP-C-018 | +| AH_REPORT_R2_021 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点边界值2000个点时核验通过 | P2 | 功能测试 | 1. 运单YB202607130037车辆GPS轨迹包含恰好2000个有效轨迹点（边界最大值） | 1. 触发第二次上报（携带2000点轨迹数据）；2. 等待核验结果；3. 验证2000点数据完整传输 | 运单号: YB202607130037; 轨迹点数: 2000(边界最大值) | 核验状态为"通过"；2000个轨迹点全部成功上报，无截断；页面响应不卡顿 | 对应TP-C-018 | +| AH_REPORT_R2_022 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点<2个(仅1个点)时核验异常 | P1 | 功能测试 | 1. 运单YB202607130038车辆GPS轨迹仅包含1个有效轨迹点 | 1. 触发第二次上报（携带1点轨迹数据）；2. 等待核验结果 | 运单号: YB202607130038; 轨迹点数: 1(不足) | 核验状态变为"异常"；异常项标注"车辆轨迹合规核验"；异常原因包含"轨迹点数量不足（至少需要2个点）"；可进入"补传轨迹"流程 | 对应TP-C-019 | +| AH_REPORT_R2_023 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点=0(无轨迹数据)时核验异常 | P1 | 功能测试 | 1. 运单YB202607130039无GPS轨迹数据（轨迹点=0） | 1. 触发第二次上报（轨迹数据为空）；2. 等待核验结果 | 运单号: YB202607130039; 轨迹点数: 0 | 核验状态变为"异常"；异常项标注"车辆轨迹合规核验"；异常原因包含"轨迹数据缺失"；可进入"补传轨迹"流程 | 对应TP-C-019 | +| AH_REPORT_R2_024 | 平台端-监管上报-第二次上报 | 验证第二次上报依赖第一次上报完成—第一次上报失败时第二次上报被拒绝 | P0 | 功能测试 | 1. 运单YB202607130005第一次上报状态为"上传失败"；2. 财务对该运单完成打款操作 | 1. 打款完成回调触发第二次上报；2. 查看第二次上报接口返回；3. 查看第二次上报列表 | 运单号: YB202607130005(第一次上报失败) | 第二次上报接口返回错误，错误码标识"前置上报未完成"或"请先完成第一次上报"；第二次上报列表中无该运单记录或状态未更新；后端通过查询report_status表校验第一次上报完成状态；错误消息清晰可理解 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R2_025 | 平台端-监管上报-第二次上报 | 验证第二次上报幂等性—自动重试期间禁止手动触发 | P0 | 功能测试 | 1. 运单YB202607130001第二次上报正在自动重试中；2. 使用super_admin登录管理端 | 1. 进入第二次上报列表；2. 在自动重试进行中找到该运单；3. 尝试点击"手动上传"按钮或直接调用上报API | 运单号: YB202607130001(自动重试进行中) | 前端"手动上传"按钮不可见或被置灰（仅"上传失败"状态可见）；若通过API直接调用，返回"上报处理中"错误（分布式锁检测）；同一运单第二次上报仅产生1条有效记录；数据库unique约束（运单号+stage=2）防止重复插入 | [AI修正: 历史缺陷防御] - BUG-202607-02 | +| AH_REPORT_R2_026 | 平台端-监管上报-第二次上报 | 验证轨迹核验异常运单的补传轨迹功能—补传后重新核验通过 | P1 | 功能测试 | 1. 运单YB202607130038第二次上报轨迹核验异常（轨迹点仅1个）；2. 运营人员准备补充的GPS轨迹数据（200个点） | 1. 进入第二次上报列表，找到轨迹异常运单；2. 点击操作列"补传轨迹"按钮；3. 上传补充的200个轨迹点数据文件；4. 提交补传；5. 等待重新核验结果 | 运单号: YB202607130038; 原始轨迹点: 1; 补传轨迹点: 200 | 仅轨迹核验异常的运单显示"补传轨迹"按钮；补传提交后系统重新触发轨迹核验；核验通过后异常项"车辆轨迹合规核验"消除，核验状态变为"通过"；补传操作在上报日志中独立记录；补传的200个轨迹点数据覆盖原有的1个点数据 | 对应TP-C-022 | +| AH_REPORT_R2_027 | 平台端-监管上报-第二次上报 | 验证第二次上报失败后自动重试机制—最多3次、间隔递增、全部失败后告警 | P1 | 功能测试 | 1. 运单YB202607130060触发第二次上报；2. 模拟监管平台接口超时（不返回/30s超时） | 1. 触发第二次上报（超时失败）；2. 等待系统自动重试；3. 查看上报日志中每次重试的记录；4. 模拟连续3次重试均失败；5. 查看告警通知 | 运单号: YB202607130060; 重试间隔: 5s/15s/30s(参考值) | 上报失败后系统自动触发第1次重试（约5s后）；第1次失败→第2次重试（约15s后）；第2次失败→第3次重试（约30s后）；每次重试在上报日志中独立记录（共4条: 1次原始+3次重试）；3次全部失败后系统通过站内信或短信告警通知运营人员；上报状态变更为"上传失败"（红色标签），"手动上传"按钮可见可用；重试期间手动上传按钮不可用或置灰显示"上报处理中" | [AI修正: 历史缺陷防御] - BUG-202607-02；对应TP-C-023 | +| AH_REPORT_R2_028 | 平台端-监管上报-第二次上报 | 验证第二次上报详情弹窗资金流水10字段与车辆轨迹6字段分组完整展示 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001第二次上报已完成且含完整资金流水和车辆轨迹数据 | 1. 进入第二次上报列表；2. 点击运单YB202607130001的"详情"按钮；3. 查看"资金流水信息"分组的字段；4. 查看"车辆轨迹信息"分组的字段 | 运单号: YB202607130001; 资金流水: 含完整支付信息; 车辆轨迹: 含150个点位 | 资金流水信息分组完整展示10字段: 支付金额/支付方式/支付时间/付款方名称/收款方名称/收款人/收款账号/收款账号类型/流水号/支付状态；车辆轨迹信息分组完整展示6字段: 定位类型/定位时间/定位地点/经度/纬度/轨迹类型；轨迹列表支持分页浏览（150个点分页展示）；可选字段缺失时显示"-"或"无"而不展示空白；弹窗分组标签和顺序正确: 运单信息→托运方信息→收货方信息→资金流水信息→车辆轨迹信息→异常信息 | 对应TP-C-024；[AI修正: 覆盖缺口补充] | + +| AH_REPORT_R2_029 | 平台端-监管上报-第二次上报 | 验证里程申诉功能—提交里程申诉接口正常 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130058存在里程数据异常（如实际里程与上报里程偏差>20%） | 1. 进入第二次上报详情页；2. 点击"里程申诉"按钮；3. 填写申诉内容"GPS里程与实际里程偏差"、投诉编号"CMP202607130001"、申诉里程"350"；4. 提交 | 运单号: YB202607130058; 申诉里程: 350km; 投诉编号: CMP202607130001 | 里程申诉提交成功，接口POST /mileageAppeal/insert返回成功响应；申诉记录中新增里程申诉记录；申诉内容、投诉编号、申诉里程字段均正确保存；缺少必选参数时接口返回明确错误提示（如"运单号不能为空"）；里程申诉与异常项申诉独立管理互不干扰 | 对应TP-C-025；[技术方案] API新增接口 | +| AH_REPORT_R2_030 | 平台端-监管上报-第二次上报 | 验证委托合同核验(100)—合同有效且覆盖运单日期时核验通过 | P1 | 功能测试 | 1. 运单YB202607130059委托合同编号DLC202607001有效且存在于合同管理系统；2. 委托合同有效期2026-01-01~2026-12-31覆盖运单执行日期2026-07-10~2026-07-13；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项 | 运单号: YB202607130059; 委托合同: DLC202607001(有效) | 核验状态为"通过"；无"委托合同核验"（代码100）异常项；abnormalDetails中不存在id=100的记录 | 对应TP-C-026；[技术方案] API文档§4.1 | +| AH_REPORT_R2_031 | 平台端-监管上报-第二次上报 | 验证委托合同核验(100)—合同不存在或过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130060委托合同编号INVALID_DLC999不存在于合同管理系统；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果返回；3. 查看异常项详情 | 运单号: YB202607130060; 委托合同: INVALID_DLC999(不存在) | 核验状态变为"异常"；异常项标注"委托合同核验"（代码100）；异常原因包含"委托合同不存在"或"委托合同已过期"；可发起申诉 | 对应TP-C-027；[技术方案] API文档§4.1 | +| AH_REPORT_R2_032 | 平台端-监管上报-第二次上报 | 验证承运合同核验(120)—合同有效且覆盖运单日期时核验通过 | P1 | 功能测试 | 1. 运单YB202607130061承运合同编号CTC202607001有效且存在于合同管理系统；2. 承运合同有效期2026-01-01~2026-12-31覆盖运单执行日期；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130061; 承运合同: CTC202607001(有效) | 核验状态为"通过"；无"承运合同核验"（代码120）异常项；abnormalDetails中不存在id=120的记录 | 对应TP-C-028；[技术方案] API文档§4.1 | +| AH_REPORT_R2_033 | 平台端-监管上报-第二次上报 | 验证承运合同核验(120)—合同不存在或过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130062承运合同编号INVALID_CTC888不存在于合同管理系统；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130062; 承运合同: INVALID_CTC888(不存在) | 核验状态变为"异常"；异常项标注"承运合同核验"（代码120）；异常原因包含"承运合同不存在"或"承运合同已过期"；可发起申诉 | 对应TP-C-029；[技术方案] API文档§4.1 | +| AH_REPORT_R2_034 | 平台端-监管上报-第二次上报 | 验证实时定位核验(130)—运单执行期间有完整实时定位数据时核验通过 | P1 | 功能测试 | 1. 运单YB202607130063在运输期间（2026-07-10 08:00~2026-07-13 18:00）有持续完整的GPS实时定位数据；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130063; 定位时间范围: 完整覆盖运输期间 | 核验状态为"通过"；无"实时定位核验"（代码130）异常项 | 对应TP-C-030；[技术方案] API文档§4.1 | +| AH_REPORT_R2_035 | 平台端-监管上报-第二次上报 | 验证实时定位核验(130)—运输期间定位数据长时间中断时核验异常 | P1 | 功能测试 | 1. 运单YB202607130064运输期间（2026-07-10~2026-07-13）GPS定位数据在2026-07-11~2026-07-12期间中断超过24小时；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130064; 定位中断: 2026-07-11~2026-07-12(约24小时) | 核验状态变为"异常"；异常项标注"实时定位核验"（代码130）；异常原因包含"实时定位数据长时间中断"；可发起申诉或补充定位数据 | 对应TP-C-031；[技术方案] API文档§4.1 | +| AH_REPORT_R2_036 | 平台端-监管上报-第二次上报 | 验证运单时间逻辑核验(140)—各时间节点逻辑合理时核验通过 | P1 | 功能测试 | 1. 运单YB202607130065时间节点合理：建单2026-07-09→接单2026-07-10 08:00→起运2026-07-10 10:00→送达2026-07-13 16:00；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130065; 时间序列: 建单→接单→起运→送达(合理) | 核验状态为"通过"；无"运单时间逻辑核验"（代码140）异常项 | 对应TP-C-032；[技术方案] API文档§4.1 | +| AH_REPORT_R2_037 | 平台端-监管上报-第二次上报 | 验证运单时间逻辑核验(140)—送达时间早于起运时间时核验异常 | P1 | 功能测试 | 1. 运单YB202607130066时间节点矛盾：起运2026-07-13 10:00→送达2026-07-12 16:00（送达早于起运）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130066; 时间倒置: 送达(07-12)早于起运(07-13) | 核验状态变为"异常"；异常项标注"运单时间逻辑核验"（代码140）；异常原因包含"送达时间早于起运时间"；可发起申诉 | 对应TP-C-033；[技术方案] API文档§4.1 | +| AH_REPORT_R2_038 | 平台端-监管上报-第二次上报 | 验证道路运输证核验(160)—有效期和证号均有效时核验通过 | P1 | 功能测试 | 1. 运单YB202607130067车辆道路运输证号RTC202501001有效，有效期2025-03-01~2027-03-01（当前日期2026-07-13在有效期内）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130067; 道路运输证号: RTC202501001(有效) | 核验状态为"通过"；无"道路运输证核验"（代码160）异常项 | 对应TP-C-034；[技术方案] API文档§4.1 | +| AH_REPORT_R2_039 | 平台端-监管上报-第二次上报 | 验证道路运输证核验(160)—证号在运政系统查询不存在时核验异常 | P1 | 功能测试 | 1. 运单YB202607130068车辆道路运输证号INVALID_RTC999在运政系统中查询不存在；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130068; 道路运输证号: INVALID_RTC999(不存在) | 核验状态变为"异常"；异常项标注"道路运输证核验"（代码160）；异常原因包含"道路运输证不存在"；可发起申诉 | 对应TP-C-035；[技术方案] API文档§4.1 | +| AH_REPORT_R2_040 | 平台端-监管上报-第二次上报 | 验证驾驶证核验(170)—驾驶证有效且准驾车型匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130069司机驾驶证号DL202501001有效，有效期2024-01-01~2030-01-01，准驾车型B2（与重型货车匹配）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130069; 驾驶证号: DL202501001(有效); 准驾车型: B2(匹配) | 核验状态为"通过"；无"驾驶证核验"（代码170）异常项 | 对应TP-C-036；[技术方案] API文档§4.1 | +| AH_REPORT_R2_041 | 平台端-监管上报-第二次上报 | 验证驾驶证核验(170)—驾驶证已过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130070司机驾驶证有效期至2025-12-31（当前日期2026-07-13已过期）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130070; 驾驶证有效期至: 2025-12-31(已过期) | 核验状态变为"异常"；异常项标注"驾驶证核验"（代码170）；异常原因包含"驾驶证已过期"；可发起申诉 | 对应TP-C-037；[技术方案] API文档§4.1 | +| AH_REPORT_R2_042 | 平台端-监管上报-第二次上报 | 验证车辆重复核验(190)—车辆无时间重叠运单时核验通过 | P1 | 功能测试 | 1. 运单YB202607130071车辆云A12345在运单执行时段2026-07-10~2026-07-13内无其他运单；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130071; 车辆: 云A12345(无时间重叠) | 核验状态为"通过"；无"车辆重复核验"（代码190）异常项 | 对应TP-C-038；[技术方案] API文档§4.1 | +| AH_REPORT_R2_043 | 平台端-监管上报-第二次上报 | 验证车辆重复核验(190)—同一车辆同时用于两个时间重叠运单时核验异常 | P1 | 功能测试 | 1. 车辆云A12345同时出现在运单YB202607130072（执行时段2026-07-10~2026-07-13）和运单YB202607130073（执行时段2026-07-11~2026-07-14）中，时间重叠2天；2. 第一次上报已完成 | 1. 分别触发两个运单的第二次上报；2. 查看核验结果 | 运单A: YB202607130072(07-10~07-13); 运单B: YB202607130073(07-11~07-14); 重叠: 07-11~07-13 | 至少一个运单核验状态变为"异常"；异常项标注"车辆重复核验"（代码190）；异常原因包含"车辆在运单执行期间存在时间重叠"；可发起申诉 | 对应TP-C-039；[技术方案] API文档§4.1 | +| AH_REPORT_R2_044 | 平台端-监管上报-第二次上报 | 验证司机重复核验(200)—司机无时间重叠运单时核验通过 | P1 | 功能测试 | 1. 运单YB202607130074司机张三(身份证510101199001011234)在运单执行时段2026-07-10~2026-07-13内无其他运单；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130074; 司机: 张三(无时间重叠) | 核验状态为"通过"；无"司机重复核验"（代码200）异常项 | 对应TP-C-040；[技术方案] API文档§4.1 | +| AH_REPORT_R2_045 | 平台端-监管上报-第二次上报 | 验证司机重复核验(200)—同一司机同时执行两个时间重叠运单时核验异常 | P1 | 功能测试 | 1. 司机张三同时被分配给运单YB202607130075（执行时段2026-07-10~2026-07-13）和运单YB202607130076（执行时段2026-07-12~2026-07-15），时间重叠2天；2. 第一次上报已完成 | 1. 分别触发两个运单的第二次上报；2. 查看核验结果 | 运单A: YB202607130075(07-10~07-13); 运单B: YB202607130076(07-12~07-15); 司机: 张三(重叠) | 至少一个运单核验状态变为"异常"；异常项标注"司机重复核验"（代码200）；异常原因包含"司机在运单执行期间存在时间重叠"；可发起申诉 | 对应TP-C-041；[技术方案] API文档§4.1 | +| AH_REPORT_R2_046 | 平台端-监管上报-第二次上报 | 验证运费收款核验(220)—收款人与司机一致且金额匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130077收款人张三与司机张三一致（身份证号510101199001011234匹配）；2. 收款金额¥10,000.00与运单运费一致；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130077; 收款人: 张三(与司机一致); 收款金额: ¥10,000.00 | 核验状态为"通过"；无"运费收款核验"（代码220）异常项 | 对应TP-C-042；[技术方案] API文档§4.1 | +| AH_REPORT_R2_047 | 平台端-监管上报-第二次上报 | 验证运费收款核验(220)—收款人与司机身份证号不一致时核验异常 | P1 | 功能测试 | 1. 运单YB202607130078司机为张三(身份证510101199001011234)，但收款人为李四(身份证510101199002022345)，两者不一致；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130078; 司机: 张三; 收款人: 李四(不一致) | 核验状态变为"异常"；异常项标注"运费收款核验"（代码220）；异常原因包含"收款人与司机信息不一致"；可发起申诉 | 对应TP-C-043；[技术方案] API文档§4.1 | +| AH_REPORT_R2_048 | 平台端-监管上报-第二次上报 | 验证公司统一收款核验(230)—收款公司信息与托运方一致时核验通过 | P1 | 功能测试 | 1. 运单YB202607130079收款公司为"安徽XX物流有限公司"(统一社会信用代码9134XXXXXXXXXXXXXX)，与托运方信息完全一致；2. 收款账户已在系统中备案；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130079; 收款公司: 安徽XX物流有限公司(与托运方一致) | 核验状态为"通过"；无"公司统一收款核验"（代码230）异常项 | 对应TP-C-044；[技术方案] API文档§4.1 | +| AH_REPORT_R2_049 | 平台端-监管上报-第二次上报 | 验证公司统一收款核验(230)—收款公司统一社会信用代码与托运方不一致时核验异常 | P1 | 功能测试 | 1. 运单YB202607130080托运方为"安徽XX物流有限公司"，但收款公司为"安徽YY运输有限公司"，统一社会信用代码不一致；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130080; 托运方: 安徽XX物流; 收款公司: 安徽YY运输(不一致) | 核验状态变为"异常"；异常项标注"公司统一收款核验"（代码230）；异常原因包含"收款公司信息与托运方不一致"；可发起申诉 | 对应TP-C-045；[技术方案] API文档§4.1 | +| AH_REPORT_R2_050 | 平台端-监管上报-第二次上报 | 验证发票信息核验(260)—发票号码/代码有效且信息完整时核验通过 | P1 | 功能测试 | 1. 运单YB202607130081关联的发票FP202607130081在税务系统中可查询且状态正常；2. 发票销售方和受票方信息完整；3. 第一次/第二次上报已完成 | 1. 触发第三次上报后等待发票核验；2. 或通过API直接查询核验结果 | 运单号: YB202607130081; 发票号: FP202607130081(有效) | 核验状态为"通过"；无"发票信息核验"（代码260）异常项 | 对应TP-C-046；[技术方案] API文档§4.1 | +| AH_REPORT_R2_051 | 平台端-监管上报-第二次上报 | 验证发票信息核验(260)—发票已作废时核验异常 | P1 | 功能测试 | 1. 运单YB202607130082关联的发票FP202607130082在税务系统中状态为"已作废/红冲"；2. 第一次/第二次上报已完成 | 1. 触发第三次上报后等待发票核验；2. 查看核验结果 | 运单号: YB202607130082; 发票号: FP202607130082(已作废) | 核验状态变为"异常"；异常项标注"发票信息核验"（代码260）；异常原因包含"发票已作废"或"发票状态异常"；可发起申诉 | 对应TP-C-047；[技术方案] API文档§4.1 | +| AH_REPORT_R2_052 | 平台端-监管上报-第二次上报 | 验证非通行车辆可开票核验(270)—车辆运营证照齐全且合规时核验通过 | P1 | 功能测试 | 1. 运单YB202607130083车辆运营证照齐全(道路运输证/行驶证均在有效期内)且未被标记为黑名单；2. 第一次/第二次上报已完成 | 1. 触发上报后等待核验；2. 查看核验结果 | 运单号: YB202607130083; 车辆证照: 齐全有效 | 核验状态为"通过"；无"非通行车辆可开票核验"（代码270）异常项 | 对应TP-C-048；[技术方案] API文档§4.1 | +| AH_REPORT_R2_053 | 平台端-监管上报-第二次上报 | 验证非通行车辆可开票核验(270)—车辆被标记为黑名单时核验异常 | P1 | 功能测试 | 1. 运单YB202607130084车辆已被监管平台标记为运营异常/黑名单；2. 第一次/第二次上报已完成 | 1. 触发上报后等待核验；2. 查看核验结果 | 运单号: YB202607130084; 车辆状态: 黑名单 | 核验状态变为"异常"；异常项标注"非通行车辆可开票核验"（代码270）；异常原因包含"车辆不合规"或"车辆不在可开票范围"；可发起申诉 | 对应TP-C-049；[技术方案] API文档§4.1 | +| AH_REPORT_R2_054 | 平台端-监管上报-第二次上报 | 验证第二次上报核验详情中每个异常项有独立申诉入口 | P2 | 功能测试 | 1. 运单YB202607130091第二次上报存在两个核验异常项：车辆轨迹(210)和资金流水(250)；2. 使用super_admin登录管理端 | 1. 进入第二次上报列表，点击该运单的"详情"按钮；2. 查看核验详情弹窗中的异常项列表；3. 验证每个异常项旁是否有独立的"申诉"操作按钮 | 运单号: YB202607130091; 异常项: 车辆轨迹(210), 资金流水(250) | 核验详情弹窗中每个异常项均有独立的"申诉"按钮或操作入口；点击异常项210的"申诉"按钮后跳转至申诉页面，且verificationAbnormalItems预填充为"210"；点击异常项250的"申诉"按钮后预填充"250"；两个申诉入口独立触发，互不影响 | 对应TP-C-024；[AI修正: 申诉单值约束意识] | +| AH_REPORT_R2_055 | 平台端-监管上报-第二次上报 | 验证第二次上报所有金额字段保留3位小数—整数填.000、精度无丢失 | P1 | 功能测试 | 1. 准备运单YB202607130093含各种金额场景：整数100、小数100.5、小数100.123；2. 第一次上报已完成，财务打款完成 | 1. 触发第二次上报；2. 查看上报请求JSON中各金额字段的值；3. 验证数据库存储和UI展示的精度 | 运单号: YB202607130093; 承运运费: 100(整数)/100.5(1位小数)/100.123(3位小数); 委托运费: 150.5; 承运人流水金额: 10000; 货主流水金额: 10500.25; 承运合同金额: 12000.5; 委托合同金额: 11000.125 | waybillFreightAmount整数100→"100.000"；totalMonetaryAmount小数150.5→"150.500"；carrierStatements[0].monetaryAmount整数10000→"10000.000"；ownerStatements[0].monetaryAmount小数10500.25→"10500.250"；carrierContractInfo.contractAmount小数12000.5→"12000.500"；carrierContractInfo.contractedCarryingCapacity→3位小数；ownerContractInfo相同规则；数据库所有金额字段使用DECIMAL(18,3)类型非FLOAT；UI展示也同步为3位小数格式 | 对应TP-C-050；[技术方案] showdoc文档第二次上报金额精度3位小数 | + +--- + +## 模块D: 第三次上报-开票完成 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_R3_001 | 平台端-监管上报-第三次上报 | 验证发票开具完成后自动触发第三次上报且包含发票信息17字段 | P0 | 功能测试 | 1. 运单YB202607130001已完成第二次上报且状态为"已上传"；2. 该运单发票FP202607130001已开具完成 | 1. 系统收到发票开具完成事件；2. 进入管理端"监管上报-第三次上报"列表查看 | 运单号: YB202607130001; 发票号: FP202607130001; 发票金额(价税合计): ¥10,300.00 | 第三次上报列表中新增该运单记录，上报状态从"上传中"变为"已上传"（绿色标签）；上报请求包含运单信息+发票信息17字段+托运单号数组；若运单无关联油气发票则油气发票信息字段为空；数据库report_record表新增stage=3的记录 | 对应TP-D-001 | +| AH_REPORT_R3_002 | 平台端-监管上报-第三次上报 | 验证第三次上报列表展示13个字段完整且数据正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 第三次上报列表中有至少1条已完成的记录 | 1. 进入"监管上报-第三次上报"列表；2. 查看列表表头和第一条数据的所有列内容 | 运单号: YB202607130001; 发票号: FP202607130001 | 列表展示13个字段: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/发票号码/发票金额/开票日期/核验状态/异常原因/上报状态/操作；发票金额保留2位小数；开票日期格式为YYYY-MM-DD；核验状态标签颜色符合规范 | 对应TP-D-002；⚠️ 待确认: 原型列表比需求多4个字段（税率/销售方名称/受票方名称/油气票张数），共15列 | +| AH_REPORT_R3_003 | 平台端-监管上报-第三次上报 | 验证第三次上报详情弹窗发票信息19字段完整展示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001第三次上报已完成 | 1. 进入第三次上报列表；2. 点击运单YB202607130001的"详情"按钮；3. 查看"发票信息"分组的所有字段 | 运单号: YB202607130001; 发票号: FP202607130001; 发票代码: 1234567890; 价税合计: ¥10,300.00 | 发票信息分组展示19字段: 托运单号数组（支持多个托运单号）、发票号码、发票代码号、发票金额(价税合计)、开票日期（必选字段完整）；销售方8字段（名称/纳税人识别号/地址/电话/开户行/银行账户/账号/联系人）完整；受票方6字段（名称/纳税人识别号/地址/电话/开户行/银行卡号）完整；注：第三次上报无税率字段 | 对应TP-D-003 | +| AH_REPORT_R3_004 | 平台端-监管上报-第三次上报 | 验证运单关联油气发票时第三次上报包含油气发票信息 | P2 | 功能测试 | 1. 运单YB202607130040关联油气发票YQFP202607001；2. 该运单发票开具完成 | 1. 触发第三次上报；2. 查看上报请求JSON中油气发票信息字段；3. 查看详情弹窗 | 运单号: YB202607130040; 油气发票: YQFP202607001 | 上报请求JSON包含油气发票信息（油气托运单号、油气发票文件）；详情弹窗中油气发票信息正确展示；油气发票文件支持查看和下载 | 对应TP-D-004 | +| AH_REPORT_R3_005 | 平台端-监管上报-第三次上报 | 验证无油气发票时第三次上报正常完成（可选字段为空） | P2 | 功能测试 | 1. 运单YB202607130001无关联油气发票；2. 该运单发票开具完成 | 1. 触发第三次上报；2. 查看上报请求JSON中油气发票相关字段 | 运单号: YB202607130001; 油气发票: 无 | 上报请求JSON中油气发票字段为null或不传；上报成功，不报错；详情弹窗中油气发票区域显示"-"或"无" | 对应TP-D-004 | +| AH_REPORT_R3_006 | 平台端-监管上报-第三次上报 | 验证第三次上报依赖第二次上报完成—第二次上报失败时第三次上报被拒绝 | P0 | 功能测试 | 1. 运单YB202607130041第二次上报状态为"上传失败"；2. 该运单发票已开具完成 | 1. 发票开具完成事件触发第三次上报；2. 查看第三次上报接口返回 | 运单号: YB202607130041(第二次上报失败) | 接口返回错误，错误码明确标识"前置上报（第二次）未完成"；后端通过查询report_status表校验第二阶段的完成状态；第三次上报列表无该运单记录 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R3_007 | 平台端-监管上报-第三次上报 | 验证第三次上报完整依赖链校验—第1失败→第2无法完成→第3被拒绝 | P0 | 功能测试 | 1. 运单YB202607130042第一次上报状态为"上传失败" | 1. 通过API依次尝试调用第二次上报接口和第三次上报接口；2. 查看每个接口的返回 | 运单号: YB202607130042 | 第一次上报失败→第二次上报接口返回"前置上报未完成"；第二次上报无法完成→第三次上报接口同样返回"前置上报未完成"（含第二次）；三阶段依赖链校验在后端完整实现，不可跳级 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_R3_008 | 平台端-监管上报-第三次上报 | 验证增值税发票号码格式无效时第三次上报失败并明确提示 | P1 | 功能测试 | 1. 运单YB202607130043发票号码格式无效（如"ABC"非标准格式）；2. 第二次上报已完成 | 1. 触发第三次上报；2. 查看上报接口返回的错误信息 | 运单号: YB202607130043; 发票号码: ABC(无效格式) | 接口返回校验错误，提示"发票号码格式无效"或类似消息；上报状态标记为"上传失败"（红色标签）；错误信息明确指出具体错误字段为发票号码；数据库无该运单第三次上报的成功记录 | 对应TP-D-006 | +| AH_REPORT_R3_009 | 平台端-监管上报-第三次上报 | 验证发票代码与发票号码不匹配时第三次上报失败 | P1 | 功能测试 | 1. 运单YB202607130044发票代码1234567890与发票号码FP202607130001不匹配 | 1. 触发第三次上报；2. 查看接口返回 | 运单号: YB202607130044; 不匹配的发票代码/号码 | 接口返回校验错误，提示"发票代码与发票号码不匹配"；上报状态标记为"上传失败"；错误信息指明具体错误字段 | 对应TP-D-006 | +| AH_REPORT_R3_010 | 平台端-监管上报-第三次上报 | 验证第三次上报失败后自动重试最多3次全部失败后告警 | P1 | 功能测试 | 1. 运单YB202607130045第三次上报时模拟监管平台持续返回失败 | 1. 触发第三次上报；2. 监控上报日志中的重试记录；3. 等待3次重试全部完成后查看告警通知 | 运单号: YB202607130045; 发票号: FP202607130045 | 自动重试3次（总共4次尝试）；重试间隔递增；3次重试全部失败后上报状态标记为"上传失败"（红色）并停止重试；super_admin收到告警通知，内容包含运单号YB202607130045、发票号FP202607130045、失败原因 | 对应TP-D-007 | +| AH_REPORT_R3_011 | 平台端-监管上报-第三次上报 | 验证第三次上报幂等性—同一运单同一发票信息不能重复上报 | P1 | 功能测试 | 1. 运单YB202607130001第三次上报已成功（发票FP202607130001）；2. 尝试再次触发第三次上报 | 1. 通过API再次调用第三次上报接口（同一运单+同一发票）；2. 查看接口返回 | 运单号: YB202607130001; 发票号: FP202607130001(已上报) | 接口返回"上报已存在"或"该发票已上报"提示；数据库report_record表不会新增重复记录（唯一约束：运单号+stage=3+发票号）；分布式锁或幂等键控制并发 | 对应TP-D-009 | +| AH_REPORT_R3_012 | 平台端-监管上报-第三次上报 | 验证第三次上报发票金额精度—价税合计保留2位小数无浮点数精度问题 | P1 | 功能测试 | 1. 准备发票金额为¥0.01、¥9,999.99、¥999,999.99的三张发票 | 1. 分别对三张发票触发第三次上报；2. 查看上报请求JSON中的金额字段；3. 对比数据库发票表和上报记录中的金额 | 金额1: ¥0.01; 金额2: ¥9,999.99; 金额3: ¥999,999.99 | 三个金额均保留2位小数并精确传输（如0.01不为0.009999...）；大金额¥999,999.99不出现溢出或截断；数据库金额字段使用DECIMAL类型非FLOAT；上报数据与开票系统数据完全一致 | 对应TP-D-010 | +| AH_REPORT_R3_013 | 平台端-监管上报-第三次上报 | 验证第三次上报运单信息数据来源—价格和货物信息来源于运单表实时数据 | P2 | 功能测试 | 1. 运单YB202607130046装货完成时货物信息含"钢材10吨"；2. 在第三次上报前修改运单表货物信息为"钢材12吨" | 1. 修改运单表的货物信息；2. 触发第三次上报；3. 查看上报请求中的货物信息数据 | 运单号: YB202607130046; 原货物量: 10吨; 修改后: 12吨 | 上报请求中的货物信息为"钢材12吨"（最新值），非"钢材10吨"（装货时快照）；数据来源为运单表实时查询；不依赖装货完成时的数据缓存 | 对应TP-D-011 | +| AH_REPORT_R3_014 | 平台端-监管上报-第三次上报 | 验证第三次上报详情弹窗异常信息分组与申诉模块数据联动 | P2 | 功能测试 | 1. 运单YB202607130046第三次上报核验异常；2. 已对该运单发起申诉且申诉状态为"申诉中" | 1. 进入第三次上报列表；2. 点击运单YB202607130046的"详情"按钮；3. 查看"异常信息"分组 | 运单号: YB202607130046; 申诉状态: 申诉中 | 异常信息分组包含核验状态（异常）、异常原因（具体异常项）、异常时间（核验时间）、处理状态（申诉中）；处理状态与申诉模块数据一致（联动）；申诉状态变更后详情弹窗中处理状态同步更新 | 对应TP-D-008 | +| AH_REPORT_R3_015 | 平台端-监管上报-第三次上报 | 验证发票合规查询接口—查询托运人发票是否通过系统核验合规 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 托运人"安徽XX物流有限公司"存在已核验合规的发票记录 | 1. 调用POST /verificationSummary/cargoOwnerInvoiceInfo接口；2. 传入托运人识别信息（统一社会信用代码/名称）；3. 查看返回的发票合规状态 | 托运人: 安徽XX物流有限公司; 统一社会信用代码: 9134XXXXXXXXXXXXXX | 接口返回发票合规状态为"合规/通过"；若发票不合规则返回异常原因和具体不合规项；接口支持批量查询多个托运人发票合规状态；响应时间<3s；传入无效托运人信息时返回明确错误提示 | 对应TP-D-012；[技术方案] API新增接口 | + +--- + +## 模块E: ETC发票上传 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_ETC_001 | 平台端-监管上报-ETC上传 | 验证运营人员手动确认税务抵扣完成后触发ETC发票上传并成功 | P0 | 功能测试 | 1. 运单YB202607130001的ETC发票ETC202607130001税务抵扣已完成（税务系统侧）；2. ETC发票信息18字段完整 | 1. 运营人员在运八系统手动确认"抵扣完成"；2. 系统收到确认后触发ETC发票上传；3. 进入管理端"监管上报-ETC上传"列表查看；4. 查看上传请求JSON内容 | 运单号: YB202607130001; ETC发票号: ETC202607130001; 不含税金额(invoiceAmount): ¥100.00; 税率: 3% | 运营人员确认后系统自动触发上传；ETC上传列表中出现该记录，上传状态为"已上传"（绿色标签）；上报请求JSON包含运单信息7字段+ETC发票信息18字段；数据库etc_report_record表新增记录，status=1 | 对应TP-E-001；[技术方案] 触发方式修正：运营人员手动确认→系统触发 | +| AH_REPORT_ETC_002 | 平台端-监管上报-ETC上传 | 验证ETC上传列表展示11个字段完整且数据正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. ETC上传列表中有至少1条记录 | 1. 进入"监管上报-ETC上传"列表；2. 查看列表表头和第一条数据的所有列 | 运单号: YB202607130001; ETC发票号: ETC202607130001 | 列表展示: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/ETC发票号码/发票金额/税率/上传状态/操作；发票金额正确展示，税率显示3%；上传状态标签颜色符合规范 | 对应TP-E-002 | +| AH_REPORT_ETC_003 | 平台端-监管上报-ETC上传 | 验证ETC发票详情弹窗3个分组字段完整（运单信息/ETC发票信息18字段/异常信息） | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. ETC上传列表中有已完成上传的记录 | 1. 进入ETC上传列表；2. 点击运单YB202607130001操作列的"详情"按钮；3. 依次查看各分组字段 | 运单号: YB202607130001; ETC发票号: ETC202607130001 | 运单信息分组7字段完整；ETC发票信息分组18字段完整展示: ETC发票号码、ETC发票代码、开票时间、发票金额、税率(3%)、税额、价税合计、销售方名称、销售方税号、受票方名称、受票方税号、入口收费站、出口收费站、交易时间、交易金额、交易匹配时间、交易流水号、ETC发票文件；异常信息分组4字段（核验状态/异常原因/异常时间/处理状态） | 对应TP-E-003 | +| AH_REPORT_ETC_004 | 平台端-监管上报-ETC上传 | 验证税务抵扣未完成时ETC上传被拒绝并提示"请先完成税务抵扣" | P0 | 功能测试 | 1. 运单YB202607130047的ETC发票税务抵扣状态为"未完成" | 1. 尝试触发ETC发票上传（调用API或页面操作）；2. 查看接口返回 | 运单号: YB202607130047; 税务抵扣: 未完成 | 上传接口返回错误，提示"请先完成税务抵扣"；后端校验税务抵扣状态为已完成才允许上传；ETC上传列表中不会出现该运单记录 | 对应TP-E-004 | +| AH_REPORT_ETC_005 | 平台端-监管上报-ETC上传 | 验证ETC发票号码格式无效时上传失败并明确提示 | P1 | 功能测试 | 1. 运单YB202607130048关联的ETC发票号码格式无效（如"ETC-ABC"不符合规定格式） | 1. 税务抵扣完成后触发上传；2. 查看接口返回 | 运单号: YB202607130048; ETC发票号码: ETC-ABC(无效) | 上传接口返回校验错误，提示"ETC发票号码格式无效"；上传状态标记为"上传失败"；错误提示指明具体错误字段 | 对应TP-E-005 | +| AH_REPORT_ETC_006 | 平台端-监管上报-ETC上传 | 验证ETC发票税率非3%时上传失败并提示税率异常 | P1 | 功能测试 | 1. 运单YB202607130049关联的ETC发票税率字段为5%（非标准3%） | 1. 触发上传；2. 查看接口返回 | 运单号: YB202607130049; ETC发票税率: 5%(非标准) | 上传接口返回校验错误，提示"税率异常（应为3%）"；上传状态标记为"上传失败"；不会将错误税率数据上报至监管平台 | 对应TP-E-005 | +| AH_REPORT_ETC_007 | 平台端-监管上报-ETC上传 | 验证ETC上传失败后自动重试最多3次全部失败后告警 | P1 | 功能测试 | 1. 运单YB202607130050 ETC上传时模拟监管平台持续返回失败 | 1. 触发ETC上传；2. 监控上报日志中的重试记录；3. 等待3次重试全部完成后查看告警 | 运单号: YB202607130050; ETC发票号: ETC202607130050 | 自动重试3次（总共4次尝试）；重试间隔递增；3次重试全部失败后标记"上传失败"（红色标签）并停止重试；super_admin收到告警通知；每次重试均记录到上报日志 | 对应TP-E-006 | +| AH_REPORT_ETC_008 | 平台端-监管上报-ETC上传 | 验证ETC税额计算公式—税额=不含税金额×税率(taxRate)，字段区分invoiceAmount/totalPriceAndTax | P1 | 功能测试 | 1. 准备3张ETC发票：不含税金额(invoiceAmount)分别为¥100.00、¥0.01、¥1,000,000.00，税率3% | 1. 分别对三张发票触发上传；2. 查看上报请求JSON中的invoiceAmount(不含税金额)、taxRate(税率)、taxAmount(税额)、totalPriceAndTax(价税合计)字段；3. 验证计算逻辑: totalPriceAndTax = invoiceAmount + taxAmount | 发票1: invoiceAmount=100.00→税额=3.00; 发票2: invoiceAmount=0.01→税额=0.00; 发票3: invoiceAmount=1000000.00→税额=30000.00 | 发票1: invoiceAmount=100.00, taxAmount=3.00, totalPriceAndTax=103.00, 计算正确；发票2: 税额按四舍五入规则处理（0.01×3%=0.0003→0.00）；发票3: invoiceAmount=1000000.00, taxAmount=30000.00, totalPriceAndTax=1030000.00, 大金额计算不溢出；所有金额字段保留2位小数；invoiceAmount≠发票总金额，是不含税金额 | 对应TP-E-007；[技术方案] 字段语义修正：invoiceAmount=不含税金额（非总金额） | +| AH_REPORT_ETC_009 | 平台端-监管上报-ETC上传 | 验证同一ETC发票号重复上传时被拒绝且提示"该ETC发票已上传" | P1 | 功能测试 | 1. ETC发票ETC202607130001已成功上传 | 1. 再次触发同一ETC发票的上传；2. 查看接口返回 | ETC发票号: ETC202607130001(已上传) | 接口返回"该ETC发票已上传"提示；数据库etc_report_record表不会产生重复记录（唯一约束：ETC发票号）；分布式锁/幂等键控制并发 | 对应TP-E-008 | +| AH_REPORT_ETC_010 | 平台端-监管上报-ETC上传 | 验证同一运单关联多张ETC发票时各自独立上传且税额分别计算 | P2 | 功能测试 | 1. 运单YB202607130001关联3张ETC发票：ETC202607130001(¥100.00)、ETC202607130002(¥200.00)、ETC202607130003(¥150.00) | 1. 分别触发3张ETC发票的上传；2. 查看ETC上传列表；3. 验证每张发票的税额计算 | ETC1: ¥100.00→税¥3.00; ETC2: ¥200.00→税¥6.00; ETC3: ¥150.00→税¥4.50 | 列表中同一运单展示3条ETC上传记录；每张发票的税额独立计算正确；多张发票上传互不干扰；合计税额=¥13.50正确汇总 | 对应TP-E-009 | +| AH_REPORT_ETC_011 | 平台端-监管上报-ETC上传 | 验证ETC发票代码与号码不匹配时上传失败 | P1 | 功能测试 | 1. 运单YB202607130051的ETC发票代码与号码不匹配（代码对应其他发票） | 1. 触发上传；2. 查看接口返回 | 运单号: YB202607130051; 不匹配的ETC发票代码/号码 | 上传接口返回校验错误，提示"ETC发票代码与号码不匹配"；上传状态标记为"上传失败"；错误信息指明具体错误字段 | 对应TP-E-005 | +| AH_REPORT_ETC_012 | 平台端-监管上报-ETC上传 | 验证交易金额与实际通行费不匹配时ETC上传验证失败 | P1 | 功能测试 | 1. 运单YB202607130052的ETC发票中交易金额¥50.00与实际通行费¥80.00不匹配 | 1. 触发上传；2. 查看接口返回 | 运单号: YB202607130052; 交易金额: ¥50.00; 实际通行费: ¥80.00(不匹配) | 上传接口返回校验错误，提示"交易金额与实际通行费不匹配"；上传状态标记为"上传失败" | 对应TP-E-005 | + +--- + +## 模块F: 异常申诉功能 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_APL_001 | 平台端-监管上报-异常申诉 | 验证申诉完整闭环—从发起申诉到申诉通过的端到端流程 | P0 | 功能测试 | 1. 运单YB202607130002第二次上报"车辆资质核验"异常；2. 使用super_admin登录管理端；3. 准备申诉附件材料（车辆道路运输证更新后的PDF） | 1. 从看板或第二次上报列表找到异常运单YB202607130002；2. 点击"申诉"按钮进入申诉页面；3. 填写申诉原因"道路运输证已续期，附新证"；4. 上传申诉附件；5. 点击"提交申诉"；6. 模拟省平台复核通过并返回反馈；7. 查看申诉状态变化 | 运单号: YB202607130002; 异常项: 车辆资质核验; 申诉原因: 道路运输证已续期; 附件: 新道路运输证.pdf | 提交申诉后申诉状态变为"未申诉(100)·申诉中"（abnormalDetails[].state=110，省平台尚未审核）；省平台复核通过后状态变为"审核通过(110)"（绿色标签，终态）；申诉记录页面中该申诉记录状态为"审核通过(110)"；处理记录时间线中每条操作均有记录；申诉状态中"已取消(130)"为省平台侧外部操作设置（如运单作废），我方系统只读同步，不提供取消操作入口 | 对应TP-F-001；[API权威] 申诉状态以API §4.4为准: 未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130)；已取消(130)由省平台侧操作，我方只读 | +| AH_REPORT_APL_002 | 平台端-监管上报-异常申诉 | 验证申诉审核不通过(120)后运营人员重新申诉补充材料再发起 | P1 | 功能测试 | 1. 运单YB202607130002申诉状态为"审核不通过(120)"；2. 省平台反馈意见"证明材料不充分" | 1. 进入申诉记录页面，找到审核不通过的申诉记录；2. 点击"重新申诉"按钮；3. 补充新的附件材料（补充证明.pdf）；4. 修改申诉原因；5. 提交 | 运单号: YB202607130002; 原申诉被审核不通过; 新附件: 补充证明.pdf | "重新申诉"按钮可见可用；重新申诉后生成新的申诉单号（不同于原申诉单号）；原有申诉记录保留不丢失（状态保持审核不通过120）；新申诉有独立的处理记录时间线；申诉状态变为"未申诉(100)·申诉中"（abnormalDetails[].state=110），重新进入复核流程 | 对应TP-F-006 | +| AH_REPORT_APL_003 | 平台端-监管上报-异常申诉 | 验证申诉记录列表14个字段完整展示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 申诉记录列表中有至少1条申诉记录 | 1. 进入"监管上报-异常申诉"申诉记录页面；2. 查看列表表头和第一条数据的各列 | 申诉单含完整字段 | 列表展示14个字段: 运单号/托运单号/车牌号/司机姓名/托运方名称/上报阶段/核验状态/异常项/申诉状态/申诉时间/申诉人/省平台反馈结果/监管平台反馈时间/操作；申诉时间为实际提交时间；省平台反馈结果与实际反馈内容一致 | 对应TP-F-002 | +| AH_REPORT_APL_004 | 平台端-监管上报-异常申诉 | 验证申诉状态流转—未申诉(100)→未申诉·申诉中→审核通过(110)(终态)或审核不通过(120)(可重申诉) | P0 | 功能测试 | 1. 运单YB202607130053核验异常且申诉状态为"未申诉(100)" | 1. 发起申诉，验证异常项子状态变为"申诉中"(abnormalDetails[].state=110)；2. 模拟省平台复核通过；3. 验证申诉状态变为"审核通过(110)"；4. 尝试再次对该申诉记录操作（如重新申诉）；5. 模拟省平台审核不通过→验证状态变为"审核不通过(120)"→可重新申诉 | 运单号: YB202607130053 | 未申诉(100)→提交申诉后异常项子状态变为申诉中(state=110)，申诉状态仍为未申诉(100)；省平台审核通过后申诉状态变为审核通过(110)（终态，不可再变更）；省平台审核不通过变为审核不通过(120)，可重新申诉发起新一轮；已取消(130)由省平台外部操作设置（如运单作废），我方UI不提供取消申诉入口，仅展示同步后的状态；每次状态变更记录到处理记录时间线 | 对应TP-F-003；[API权威] 申诉状态以API §4.4为准: 未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130)；已取消(130)为省平台侧外部操作，我方只读 | +| AH_REPORT_APL_005 | 平台端-监管上报-异常申诉 | 验证申诉状态流转—未申诉·申诉中状态下不可重复发起申诉 | P0 | 功能测试 | 1. 运单YB202607130054申诉状态为"未申诉(100)·申诉中"（abnormalDetails[].state=110） | 1. 尝试通过API或页面再次对该运单同一异常项发起申诉；2. 观察系统响应 | 运单号: YB202607130054; 申诉状态: 未申诉·申诉中 | 页面"申诉"按钮被禁用或点击后提示"申诉处理中，请勿重复提交"；后端API返回错误，提示"该异常项已有申诉在处理中"；数据库不会产生重复申诉记录 | 对应TP-F-003; TP-F-012 | +| AH_REPORT_APL_006 | 平台端-监管上报-异常申诉 | 验证申诉详情弹窗5个分组字段完整（申诉信息/运单信息/异常信息/省平台反馈/处理记录） | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 存在一条已完成的申诉记录 | 1. 进入申诉记录页面；2. 点击某条记录的"详情"按钮；3. 依次查看5个分组的内容 | 申诉单号: APL202607130001 | 申诉信息分组含: 申诉单号/上报阶段/异常项/申诉原因/申诉状态/申诉时间/申诉人/申诉附件；省平台反馈信息含: 反馈结果/反馈时间/反馈意见；处理记录以时间线形式倒序展示：操作人/操作时间/操作类型/操作内容，每步操作（发起申诉/省平台反馈/重新申诉）均有一条记录 | 对应TP-F-004 | +| AH_REPORT_APL_007 | 平台端-监管上报-异常申诉 | 验证申诉附件上传—支持多附件且格式校验正确 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 准备png、jpg、pdf格式的附件文件各1个，以及1个超出大小限制的文件(如10MB) | 1. 进入申诉发起页面；2. 依次上传png/jpg/pdf文件；3. 尝试上传超限文件 | 附件: 证明1.png(500KB), 证明2.jpg(800KB), 证明3.pdf(1.5MB), 超限文件.exe(10MB) | png/jpg/pdf格式上传成功，附件列表展示文件名和大小；超限文件上传时提示"文件大小超过限制"；上传失败有重试机制；申诉详情弹窗中可查看/下载已上传的附件 | 对应TP-F-005 | +| AH_REPORT_APL_008 | 平台端-监管上报-异常申诉 | 验证17项核验异常（API文档§4.1定义）各自独立发起申诉—每次仅可申诉单个异常项 | P1 | 功能测试 | 1. 准备17条运单（或组合覆盖），每条分别对应一种核验异常项；2. 使用super_admin登录管理端 | 1. 分别对17种异常项运单发起申诉；2. 查看每条申诉记录中的异常项信息；3. 验证各申诉独立互不干扰；4. 确认每次申诉仅含单个verificationAbnormalItems值 | 运单A: 委托合同(100); B: 承运合同(120); C: 实时定位(130); D: 运单时间逻辑(140); E: 车辆资质(150); F: 道路运输证(160); G: 驾驶证(170); H: 从业资格证(180); I: 车辆重复(190); J: 司机重复(200); K: 车辆轨迹(210); L: 运费收款(220); M: 公司统一收款(230); N: 集中支付(240); O: 资金流水(250); P: 发票信息(260); Q: 非通行车辆可开票(270) | 17条申诉各自独立创建，异常项信息与核验结果一致；每条申诉的verificationAbnormalItems字段为单一异常项ID；某一异常项申诉不影响其他异常项的申诉状态；同一运单存在多个异常项时需分别独立发起申诉（参见AH_REPORT_APL_019） | 对应TP-F-007；[API权威] API文档§4.1定义17项核验，每项均可独立申诉但每次只允许申诉单个异常项（单值约束） | +| AH_REPORT_APL_009 | 平台端-监管上报-异常申诉 | 验证从看板操作列点击申诉按钮跳转至申诉页面并自动填充运单号 | P1 | 功能测试 | 1. 看板中存在核验异常的运单YB202607130002；2. 使用super_admin登录管理端 | 1. 进入看板页面；2. 在异常运单YB202607130002的操作列点击"申诉"按钮；3. 观察页面跳转和预填充数据 | 运单号: YB202607130002 | 页面路由正确跳转至申诉发起页面；URL携带正确的运单ID参数；申诉页面自动加载该运单的异常信息（运单号YB202607130002、异常项预填充正确）；运营人员无需手动输入运单号 | 对应TP-F-008 | +| AH_REPORT_APL_010 | 平台端-监管上报-异常申诉 | 验证仅运营人员有权发起申诉—司机/车队长/财务无申诉操作权限 | P1 | 安全性测试 | 1. 准备运营(super_admin)、财务、车队长(13113113113)、司机(15188888888)账号 | 1. 用各账号分别登录；2. 访问申诉功能页面；3. 尝试通过API直接调用申诉接口 | 运营: super_admin; 财务: finance_user; 车队长: 13113113113; 司机: 15188888888 | 运营人员可见"申诉"按钮和申诉记录页面，可发起申诉；车队长/司机端无申诉功能入口，直接URL访问返回403；财务人员可查看申诉记录但"发起申诉"按钮不可见；越权操作被拦截并记录审计日志（操作人/操作时间/操作内容/拦截原因） | 对应TP-F-009 | +| AH_REPORT_APL_011 | 平台端-监管上报-异常申诉 | 验证申诉处理记录时间线按时间倒序排列且操作时间精确到秒 | P2 | 功能测试 | 1. 存在一条经历了发起申诉→省平台反馈→重新申诉→省平台再次反馈的完整申诉记录 | 1. 进入申诉详情弹窗；2. 查看"处理记录"时间线 | 申诉单号: APL202607130002 | 4条操作记录按时间倒序排列（最新的在最上面）；每条记录包含: 操作人（用户名或"省平台"）、操作时间（YYYY-MM-DD HH:mm:ss）、操作类型（发起申诉/复核通过/复核驳回/重新申诉）、操作内容描述；操作类型与实际情况准确对应 | 对应TP-F-010 | +| AH_REPORT_APL_012 | 平台端-监管上报-异常申诉 | 验证异常代码一览表映射—已知异常代码正确映射为中文异常项名称 | P2 | 功能测试 | 1. 模拟省平台返回已知异常代码（如"VEHICLE_QUAL_FAIL"） | 1. 查看申诉页面中该异常代码对应的中文展示；2. 验证映射关系正确 | 异常代码: VEHICLE_QUAL_FAIL | 申诉页面中异常项显示为"车辆资质核验"（中文），非原始代码"VEHICLE_QUAL_FAIL"；异常代码与中文名称一一对应无歧义 | 对应TP-F-011 | +| AH_REPORT_APL_013 | 平台端-监管上报-异常申诉 | 验证未知异常代码兜底展示—显示原始代码+标注未知异常 | P2 | 功能测试 | 1. 模拟省平台返回一个系统中未定义的异常代码（如"UNKNOWN_ERROR_999"） | 1. 查看申诉页面异常项的展示 | 未知异常代码: UNKNOWN_ERROR_999 | 申诉页面中异常项显示原始代码"UNKNOWN_ERROR_999"并标注"(未知异常)"或类似兜底文案（不崩溃、不显示乱码）；系统日志中记录"未识别的异常代码"便于后续排查 | 对应TP-F-011 | +| AH_REPORT_APL_014 | 平台端-监管上报-异常申诉 | 验证同一异常项未申诉·申诉中状态下快速双击提交申诉仅产生1条记录 | P2 | 功能测试 | 1. 运单YB202607130055核验异常，申诉状态为"未申诉(100)"，异常项子状态为"未申诉"(state=100) | 1. 进入申诉页面填写完整信息；2. 快速双击"提交申诉"按钮；3. 查看申诉记录列表 | 运单号: YB202607130055; 异常项: 资金流水核验 | 申诉记录列表中仅产生1条申诉记录（前端防抖+后端校验）；后端有状态校验，"未申诉·申诉中"(abnormalDetails[].state=110)状态下不可重新发起；数据库appeal_record表该运单+该异常项仅有1条"未申诉·申诉中"记录 | 对应TP-F-012 | +| AH_REPORT_APL_015 | 平台端-监管上报-异常申诉 | 验证申诉提交后省平台长时间无反馈(超7个工作日)时系统有合理状态提示 | P3 | 功能测试 | 1. 运单YB202607130056申诉状态为"未申诉(100)·申诉中"（abnormalDetails[].state=110），省平台尚未审核；2. 模拟时间超过7个工作日省平台无反馈 | 1. 进入申诉记录页面查看该申诉记录；2. 查看系统是否有超时提示或告警 | 运单号: YB202607130056; 等待时长: 超过7个工作日 | 申诉记录页面显示"等待省平台复核中"或类似状态提示（申诉状态仍为"未申诉(100)·申诉中"不自动变更）；运营人员可查看申诉等待时长（如"已等待8个工作日"）；系统应触发超时告警通知运营人员跟进（告警渠道和阈值待确认）；不自动变更申诉状态为审核通过(110)或审核不通过(120)；已取消(130)由省平台侧外部操作（如运单作废），我方只读同步，不主动发起取消 | 对应TP-F-013；> ⚠️ 待确认：申诉超时告警机制（告警渠道、触发阈值）需与产品确认 | +| AH_REPORT_APL_016 | 平台端-监管上报-异常申诉 | 验证申诉附件上传失败时有重试机制 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 模拟附件上传接口服务暂时不可用 | 1. 进入申诉发起页面；2. 填写申诉信息并选择附件上传；3. 在上传过程中模拟服务异常 | 附件: 证明文件.png(500KB) | 附件上传失败时前端显示"上传失败，点击重试"提示；点击重试后可重新上传；上传成功后可正常提交申诉；失败不影响已填写的申诉文字内容 | 对应TP-F-005 | +| AH_REPORT_APL_017 | 平台端-监管上报-异常申诉 | 验证财务人员可查看申诉记录但不可发起申诉 | P1 | 安全性测试 | 1. 使用财务账号登录管理端；2. 申诉记录中有数据 | 1. 进入申诉记录页面，查看是否有"发起申诉"按钮；2. 查看申诉详情是否可读；3. 尝试通过API调用申诉发起接口 | 财务账号: finance_user | 申诉记录列表正常展示，可查看详情；"发起申诉"按钮不可见（或置灰）；通过API直接调用申诉发起接口返回403 Forbidden；审计日志中记录财务账号的查看操作 | 对应TP-F-009 | +| AH_REPORT_APL_018 | 平台端-监管上报-异常申诉 | 验证申诉表单仅允许选择单个异常项—verificationAbnormalItems单值约束 | P0 | 功能测试 | 1. 运单YB202607130090同时存在两个异常项：车辆轨迹210和资金流水250；2. 使用super_admin登录管理端 | 1. 进入申诉页面；2. 查看异常项选择区域；3. 尝试选择一个异常项后提交；4. 尝试多选异常项 | 运单号: YB202607130090; 异常项: 210(车辆轨迹), 250(资金流水) | UI层面异常项为单选列表（Radio Button或单选下拉），无法多选；提交请求中verificationAbnormalItems字段为单值（如"210"），非逗号分隔多值；若通过API绕过前端传入逗号分隔多值"210,250"，后端返回错误（如code=500，message包含"仅支持单个异常项目申诉"） | 对应TP-F-014；[技术方案] API单值约束 | +| AH_REPORT_APL_019 | 平台端-监管上报-异常申诉 | 验证同一运单两个异常项需分别发起两次独立申诉 | P1 | 功能测试 | 1. 运单YB202607130090有两个异常项210+250，均状态为"未申诉"；2. 使用super_admin登录管理端 | 1. 对异常项210(车辆轨迹)发起申诉→填写申诉内容→上传附件→提交；2. 验证申诉提交成功；3. 返回申诉页面，再次对异常项250(资金流水)发起申诉→填写内容→提交 | 运单号: YB202607130090; 申诉1: 异常项210; 申诉2: 异常项250 | 两次申诉生成两个独立申诉单号（complaintNumber不同）；数据库appeal_record表存在两条记录，分别对应异常项210和异常项250；两个异常项的申诉状态独立流转，互不影响；第二次申诉的异常项选择区域仅展示尚未申诉的异常项（250），已申诉的异常项210不再可选 | 对应TP-F-015；[技术方案] 独立申诉单 | +| AH_REPORT_APL_020 | 平台端-监管上报-异常申诉 | 验证申诉接口传入逗号分隔多异常项ID时后端拒绝 | P1 | 安全性测试 | 1. 运单YB202607130090有两个异常项210和250均未申诉；2. 获取有效JWT Token | 1. 通过API直接调用POST /appeal/insert接口；2. verificationAbnormalItems参数传入"210,250"（逗号分隔）；3. 查看接口返回 | 运单号: YB202607130090; verificationAbnormalItems: "210,250"(逗号分隔,非法) | 接口返回错误（code=500），message包含"仅支持单个异常项目申诉"或"verificationAbnormalItems必须为单一异常项ID"；数据库appeal_record表不产生新记录；不会错误地创建关联多个异常项的申诉单；单独传入"210"或"250"（单值）时正常成功 | 对应TP-F-016；[技术方案] 后端校验多值拒绝 | + +--- + +## 模块G: 上报日志 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_LOG_001 | 平台端-监管上报-上报日志 | 验证上报日志按完整运单号精确搜索日志记录 | P0 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001存在上报日志记录 | 1. 进入"监管上报-上报日志"页面；2. 在运单号搜索框输入"YB202607130001"；3. 点击搜索 | 运单号: YB202607130001 | 列表仅展示与该运单号相关的所有上报日志记录（含各阶段的重试记录）；数据库查询结果与页面展示一致 | 对应TP-G-001 | +| AH_REPORT_LOG_002 | 平台端-监管上报-上报日志 | 验证上报日志按不存在的单号搜索显示空结果 | P1 | 功能测试 | 1. 使用super_admin登录管理端 | 1. 进入"监管上报-上报日志"页面；2. 输入不存在的单号"NOTEXIST999"；3. 点击搜索 | 运单号: NOTEXIST999 | 列表显示空结果，友好提示"未找到相关日志记录"；控制台无报错 | 对应TP-G-001 | +| AH_REPORT_LOG_003 | 平台端-监管上报-上报日志 | 验证上报日志按"第一次上报"阶段筛选日志 | P0 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中同时存在第一次上报和第二次上报的记录 | 1. 进入"监管上报-上报日志"页面；2. 选择上报阶段"第一次上报"；3. 查看筛选结果 | 筛选条件: 第一次上报 | 列表仅展示stage=1的日志记录；ETC上传日志不包含在内；切换至"ETC上传"时有独立筛选项，日志正确过滤 | 对应TP-G-002 | +| AH_REPORT_LOG_004 | 平台端-监管上报-上报日志 | 验证上报日志按"失败"结果筛选—展示所有非成功日志 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中存在成功(HTTP 200)和失败(HTTP 4xx/5xx/超时)的记录 | 1. 进入日志页面；2. 选择上报结果"失败"；3. 查看筛选结果 | 筛选: 失败 | 列表展示所有非2xx的日志记录，包括HTTP 400/500/超时等；"成功"(200)的记录被过滤；筛选结果与实际日志记录一致 | 对应TP-G-003 | +| AH_REPORT_LOG_005 | 平台端-监管上报-上报日志 | 验证上报日志按时间范围筛选（跨天） | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中存在2026-07-10至2026-07-13的记录 | 1. 进入日志页面；2. 选择开始时间"2026-07-10 00:00:00"，结束时间"2026-07-12 23:59:59"；3. 点击搜索 | 时间范围: 2026-07-10~2026-07-12 | 列表仅展示该时间范围内的日志记录；不包含2026-07-13的日志；开始时间>结束时间时系统给出提示或自动交换；不选时间范围时默认展示全部 | 对应TP-G-004 | +| AH_REPORT_LOG_006 | 平台端-监管上报-上报日志 | 验证上报日志列表11个字段完整展示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中有至少1条完整记录 | 1. 进入日志页面；2. 查看列表表头和第一条数据的所有列 | 查看一条典型日志记录 | 列表展示: 序号/货源单号/运单号/托运单号/上报阶段/上报结果/接口URL/HTTP状态码/响应时间/上报时间/操作；接口URL完整（含域名和路径如https://anhui.report.gov.cn/api/v1/waybill/submit）；HTTP状态码为实际返回状态码；响应时间单位为ms；上报时间为实际请求发起时间 | 对应TP-G-005 | +| AH_REPORT_LOG_007 | 平台端-监管上报-上报日志 | 验证点击日志操作列详情按钮弹窗展示完整请求和响应报文 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中有1条失败记录 | 1. 进入日志页面；2. 点击某条日志操作列的"详情"按钮；3. 在弹窗中查看请求报文和响应报文 | 查看一条HTTP 400失败的日志详情 | 弹窗展示请求报文: URL（完整）、Method（POST）、Headers（Content-Type/Authorization等）、Body（完整JSON）；响应报文: Status Code（400）、Headers、Body（错误信息JSON）；JSON报文格式化展示（缩进/语法高亮）；长报文支持滚动查看；支持一键复制请求/响应内容 | 对应TP-G-006 | +| AH_REPORT_LOG_008 | 平台端-监管上报-上报日志 | 验证每个上报阶段及自动修改字段接口的每次调用均在日志中完整记录 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001已完成全流程上报（第一次+修改字段+第二次+7核验+第三次+ETC） | 1. 进入日志页面；2. 按运单号YB202607130001搜索；3. 逐条检查日志记录是否覆盖所有阶段 | 运单号: YB202607130001 | 日志中至少包含以下记录: 第一次上报请求+响应、第一次上报修改字段请求+响应、第二次上报请求+响应、7类核验各自的请求+响应日志、第三次上报请求+响应、ETC上传请求+响应；自动重试的每次请求均独立记录（如第一次上报失败重试2次→共3条日志） | 对应TP-G-007 | +| AH_REPORT_LOG_009 | 平台端-监管上报-上报日志 | 验证上报失败日志包含完整的Error Response Body和重试次数标记 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 存在上报失败的日志记录 | 1. 进入日志页面；2. 筛选"失败"的日志；3. 点击某条失败日志的详情；4. 查看失败信息完整度 | 查看一条第2次重试失败的日志 | 失败日志包含完整的Error Response Body（JSON格式）；超时日志标注"timeout"并记录超时时长（如30000ms）；重试日志中标注当前是第几次重试（如"重试第2/3次"）；异常日志可关联到具体运单ID，方便排查 | 对应TP-G-008 | +| AH_REPORT_LOG_010 | 平台端-监管上报-上报日志 | 验证上报日志区分自动触发和手动触发—自动标注"系统自动"/手动标注操作人 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 存在自动触发的上报日志和手动触发的上报日志 | 1. 进入日志页面；2. 查看自动触发上报的日志记录中的操作人字段；3. 查看手动触发上报的日志记录中的操作人字段 | 自动日志: 第一次上报(装货完成触发); 手动日志: 第一次上报(手动上传) | 自动触发的上报日志操作人标注"系统自动"或"auto"；手动触发的上报日志操作人标注实际登录用户名（如"super_admin"）；审计日志中操作人信息与实际登录用户一致 | 对应TP-G-009 | +| AH_REPORT_LOG_011 | 平台端-监管上报-上报日志 | 验证上报日志组合筛选—阶段+结果+时间范围+单号同时筛选 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志数据满足组合条件 | 1. 进入日志页面；2. 设置: 阶段=第二次上报、结果=失败、时间范围=2026-07-10~2026-07-13、运单号=YB20260713；3. 点击搜索 | 组合: 第二次上报+失败+2026-07-10~2026-07-13+YB20260713 | 列表仅展示同时满足4个条件的日志记录；各条件在数据库查询中均正确生效；组合结果为空时有友好提示 | 对应TP-G-001; TP-G-002; TP-G-003; TP-G-004 | + +--- + +## 跨模块测试点 + +| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| AH_REPORT_CROSS_001 | 平台端-监管上报-跨模块 | 验证完整三阶段依赖链端到端验证—后端三重前置状态校验 | P0 | 功能测试 | 1. 准备一条安徽税源地(34)的运单YB202607130001 | 1. 使第一次上报失败（关闭监管平台接口）；2. 尝试调用第二次上报API；3. 查看返回；4. 使第二次上报失败；5. 尝试调用第三次上报API；6. 查看返回 | 运单号: YB202607130001 | 第一次上报失败→第二次上报API返回错误码"前置上报未完成"；第二次上报失败→第三次上报API返回错误码"前置上报（第二次）未完成"；三个阶段不可跳级执行；依赖链校验在后端通过查询report_status表实现，非仅前端控制；每个阶段的阻断/通过状态独立存储 | [AI修正: 历史缺陷防御] - BUG-202607-01 | +| AH_REPORT_CROSS_002 | 平台端-监管上报-跨模块 | 验证多模块数据一致性—修改源数据后各阶段上报感知变更并使用最新值 | P0 | 功能测试 | 1. 运单YB202607130046初始数据: 司机15188888888、合同金额¥10,000.00、发票金额¥10,300.00 | 1. 第一次上报前修改司机信息（如更换司机手机号）；2. 触发第一次上报，验证使用最新司机信息；3. 财务修改打款金额（¥10,000.00→¥9,500.00）；4. 触发第二次上报，验证使用¥9,500.00；5. 修改发票金额（¥10,300.00→¥10,100.00）；6. 触发第三次上报，验证使用¥10,100.00 | 运单号: YB202607130046; 修改项: 司机/金额/发票 | 第一次上报使用最新司机信息；第二次上报金额为¥9,500.00（非缓存的¥10,000.00）；第三次上报发票金额为¥10,100.00（非旧值）；数据库查询日志可确认各字段的数据来源表（非缓存）；数据库report_record表各阶段记录中的数据与来源表一致 | [AI修正: 历史缺陷防御] - BUG-202607-03 | +| AH_REPORT_CROSS_003 | 平台端-监管上报-跨模块 | 验证安徽税源地运单完整上报链路—装货到ETC全流程核验通过（冒烟测试） | P0 | 冒烟测试 | 1. 准备一条安徽税源地(34)的完整运单YB202607130001，所有资质有效、合同有效、轨迹正常、支付正常、发票正常 | 1. 装货完成→等待第一次上报→验证状态"已上传"；2. 等待自动修改字段→验证日志中有修改记录；3. 财务打款¥10,000.00→等待第二次上报→验证7类核验全部通过；4. 发票FP202607130001开具→等待第三次上报→验证状态"已上传"；5. 税务抵扣完成→ETC发票ETC202607130001上传→验证状态"已上传" | 运单号: YB202607130001; 金额: ¥10,000.00; 发票: FP202607130001; ETC: ETC202607130001 | 第一次上报成功→第二次上报成功（7核验全通过）→第三次上报成功→ETC上传成功；每个阶段看板数据正确更新；上报日志完整记录全链路；数据库report_record表stage=1/2/3均状态=1；etc_report_record表status=1 | 对应TP-X-003 | +| AH_REPORT_CROSS_004 | 平台端-监管上报-跨模块 | 验证非安徽税源地运单(云南=28)全部阶段均不触发上报 | P0 | 功能测试 | 1. 准备一条云南税源地(28)的运单YB202607130002，包含完整运输流程 | 1. 装货完成→检查是否触发第一次上报；2. 财务打款→检查是否触发第二次上报；3. 发票开具→检查是否触发第三次上报；4. 税务抵扣→检查是否触发ETC上传；5. 查看看板中是否存在该运单 | 运单号: YB202607130002; 省份代码: 28(云南) | 全部阶段均不触发上报；看板中不显示该云南运单；上报日志中无该运单的任何上报记录；系统无因"不触发"而产生的错误日志或异常告警；云南运单本身的运输流程（装货→运输→卸货→结算）不受影响正常流转 | 对应TP-X-004 | +| AH_REPORT_CROSS_005 | 平台端-监管上报-跨模块 | 验证多省份部署下安徽(34)和云南(28)上报数据完全隔离 | P1 | 功能测试 | 1. 准备安徽(34)运单YB202607130001和云南(28)运单YB202607130002各1条 | 1. 分别触发两条运单的完整上报流程；2. 查看两个省份的上报日志和数据记录；3. 验证安徽运单的上报目标URL为安徽监管平台，云南运单为云南监管平台 | 安徽: YB202607130001(34); 云南: YB202607130002(28) | 安徽运单仅上报至安徽监管平台(URL含anhui)；云南运单仅上报至云南监管平台(URL含yunnan)；两个省份的report_record表数据通过province_code字段物理/逻辑隔离；省份代码各自独立（安徽=34、云南=28），不混淆 | 对应TP-X-005 | +| AH_REPORT_CROSS_006 | 平台端-监管上报-跨模块 | 验证定时任务重试与手动触发上报的并发控制—分布式锁机制 | P1 | 功能测试 | 1. 运单YB202607130057第一次上报失败，定时重试任务即将触发第1次重试；2. super_admin在管理端准备手动点击"手动上传" | 1. 在重试任务触发的同时，super_admin点击"手动上传"；2. 观察并发场景下的系统行为 | 运单号: YB202607130057 | 同一时刻仅1个上报请求被执行（通过分布式锁如Redis SETNX控制）；被拒绝的请求返回"上报处理中"提示；不产生重复上报记录；分布式锁正确释放，后续操作可正常进行 | 对应TP-B-014; TP-C-021 | +| AH_REPORT_CROSS_007 | 平台端-监管上报-跨模块 | 验证回单签收后财务打款前不触发第二次上报—打款完成才触发 | P2 | 功能测试 | 1. 运单YB202607130001第一次上报已完成；2. 回单已签收但财务尚未打款 | 1. 回单签收完成后检查第二次上报列表；2. 财务执行打款后再次检查第二次上报列表；3. 对比两次检查的时间点 | 运单号: YB202607130001; 回单签收时间: 2026-07-12 15:00; 打款时间: 2026-07-12 17:00 | 回单签收完成后第二次上报列表中无该运单记录（未触发）；财务打款完成后第二次上报列表中出现该运单记录（已触发）；上报时间戳接近打款完成时间（如2026-07-12 17:00:05），非回单签收时间 | 对应TP-X-006 | +| AH_REPORT_CROSS_008 | 平台端-监管上报-跨模块 | 验证已上报至服务平台的运单不可取消或删除—无操作入口且API拒绝 | P1 | 功能测试 | 1. 运单YB202607130094已成功完成第一次上报（数据已上传至服务平台）；2. 使用super_admin登录管理端 | 1. 在管理端查看该运单的操作列，确认是否存在"取消"或"删除"按钮；2. 通过API尝试调用删除/取消运单接口（如DELETE /api/waybill/{id}）；3. 查看接口返回和数据库状态 | 运单号: YB202607130094; 上报阶段: 第一次上报已完成 | UI操作列无"取消"或"删除"按钮（仅显示详情/进度/申诉等）；API层面调用删除接口返回错误（如404或method not allowed），提示"已上报运单不允许取消"；数据库report_record表和运单表数据未被删除或修改；未完结的运单在合规率统计中被排除不计 | 对应TP-X-007；[技术方案] showdoc FAQ：服务平台不支持取消或删除运单 | + +--- + +## 测试点→用例映射表 + +| 测试点ID | 对应的用例编号 | 覆盖状态 | +| :--- | :--- | :--- | +| TP-A-001 | AH_REPORT_DASH_001, AH_REPORT_DASH_002, AH_REPORT_DASH_003 | 已覆盖 | +| TP-A-002 | AH_REPORT_DASH_004 | 已覆盖 | +| TP-A-003 | AH_REPORT_DASH_005 | 已覆盖 | +| TP-A-004 | AH_REPORT_DASH_006 | 已覆盖 | +| TP-A-005 | AH_REPORT_DASH_007 | 已覆盖 | +| TP-A-006 | AH_REPORT_DASH_008, AH_REPORT_DASH_009 | 已覆盖 | +| TP-A-007 | AH_REPORT_DASH_010 | 已覆盖 | +| TP-A-008 | AH_REPORT_DASH_011 | 已覆盖 | +| TP-A-009 | AH_REPORT_DASH_012 | 已覆盖 | +| TP-A-010 | AH_REPORT_DASH_013 | 已覆盖 | +| TP-A-011 | AH_REPORT_DASH_014, AH_REPORT_DASH_015 | 已覆盖 | +| TP-A-012 | AH_REPORT_DASH_016 | 已覆盖 | +| TP-A-013 | AH_REPORT_DASH_017 | 已覆盖 | +| TP-A-014 | AH_REPORT_DASH_018 | 已覆盖 | +| TP-B-001 | AH_REPORT_R1_001 | 已覆盖 | +| TP-B-002 | AH_REPORT_R1_002, AH_REPORT_R1_003 | 已覆盖 | +| TP-B-003 | AH_REPORT_R1_004, AH_REPORT_R1_005, AH_REPORT_R1_021 | 已覆盖 | +| TP-B-004 | AH_REPORT_R1_003, AH_REPORT_R1_006 | 已覆盖 | +| TP-B-005 | AH_REPORT_R1_007, AH_REPORT_R1_008 | 已覆盖 | +| TP-B-006 | AH_REPORT_R1_009 | 已覆盖 | +| TP-B-007 | AH_REPORT_R1_010 | 已覆盖 | +| TP-B-008 | AH_REPORT_R1_011 | 已覆盖 | +| TP-B-009 | AH_REPORT_R1_012 | 已覆盖 | +| TP-B-010 | AH_REPORT_R1_023 | 已覆盖 | +| TP-B-011 | AH_REPORT_DASH_014 | 已覆盖（见看板详情弹窗用例） | +| TP-B-012 | AH_REPORT_DASH_015 | 已覆盖（见看板详情弹窗用例） | +| TP-B-013 | AH_REPORT_R1_022 | 已覆盖 | +| TP-B-014 | AH_REPORT_R1_013, AH_REPORT_R1_014, AH_REPORT_CROSS_006 | 已覆盖 | +| TP-B-015 | AH_REPORT_R1_015 | 已覆盖 | +| TP-B-016 | AH_REPORT_R1_016 | 已覆盖 | +| TP-B-017 | AH_REPORT_R1_017 | 已覆盖 | +| TP-B-018 | AH_REPORT_R1_018 | 已覆盖 | +| TP-B-019 | AH_REPORT_R1_019, AH_REPORT_R1_020 | 已覆盖 | +| TP-B-020 | AH_REPORT_R1_024 | 已覆盖 | +| TP-B-021 | AH_REPORT_R1_025 | 已覆盖 | +| TP-B-022 | AH_REPORT_R1_026 | 已覆盖 | +| TP-C-001 | AH_REPORT_R2_001 | 已覆盖 | +| TP-C-002 | AH_REPORT_R2_002 | 已覆盖 | +| TP-C-003 | AH_REPORT_R2_003 | 已覆盖 | +| TP-C-004 | AH_REPORT_R2_004 | 已覆盖 | +| TP-C-005 | AH_REPORT_R2_004 | 已覆盖 | +| TP-C-006 | AH_REPORT_R2_005 | 已覆盖 | +| TP-C-007 | AH_REPORT_R2_006 | 已覆盖 | +| TP-C-008 | AH_REPORT_R2_007 | 已覆盖 | +| TP-C-009 | AH_REPORT_R2_008 | 已覆盖 | +| TP-C-010 | AH_REPORT_R2_009 | 已覆盖 | +| TP-C-011 | AH_REPORT_R2_010 | 已覆盖 | +| TP-C-012 | AH_REPORT_R2_011 | 已覆盖 | +| TP-C-013 | AH_REPORT_R2_012 | 已覆盖 | +| TP-C-014 | AH_REPORT_R2_013 | 已覆盖 | +| TP-C-015 | AH_REPORT_R2_014, AH_REPORT_R2_015 | 已覆盖 | +| TP-C-016 | AH_REPORT_R2_016 | 已覆盖 | +| TP-C-017 | AH_REPORT_R2_017, AH_REPORT_R2_018 | 已覆盖 | +| TP-C-018 | AH_REPORT_R2_019, AH_REPORT_R2_020, AH_REPORT_R2_021 | 已覆盖 | +| TP-C-019 | AH_REPORT_R2_022, AH_REPORT_R2_023 | 已覆盖 | +| TP-C-020 | AH_REPORT_R2_024 | 已覆盖 | +| TP-C-021 | AH_REPORT_R2_025, AH_REPORT_CROSS_006 | 已覆盖 | +| TP-C-022 | AH_REPORT_R2_026 | 已覆盖 | +| TP-C-023 | AH_REPORT_R2_027 | 已覆盖 | +| TP-C-024 | AH_REPORT_R2_028, AH_REPORT_R2_054 | 已覆盖 | +| TP-C-025 | AH_REPORT_R2_029 | 已覆盖 | +| TP-C-026 | AH_REPORT_R2_030 | 已覆盖 | +| TP-C-027 | AH_REPORT_R2_031 | 已覆盖 | +| TP-C-028 | AH_REPORT_R2_032 | 已覆盖 | +| TP-C-029 | AH_REPORT_R2_033 | 已覆盖 | +| TP-C-030 | AH_REPORT_R2_034 | 已覆盖 | +| TP-C-031 | AH_REPORT_R2_035 | 已覆盖 | +| TP-C-032 | AH_REPORT_R2_036 | 已覆盖 | +| TP-C-033 | AH_REPORT_R2_037 | 已覆盖 | +| TP-C-034 | AH_REPORT_R2_038 | 已覆盖 | +| TP-C-035 | AH_REPORT_R2_039 | 已覆盖 | +| TP-C-036 | AH_REPORT_R2_040 | 已覆盖 | +| TP-C-037 | AH_REPORT_R2_041 | 已覆盖 | +| TP-C-038 | AH_REPORT_R2_042 | 已覆盖 | +| TP-C-039 | AH_REPORT_R2_043 | 已覆盖 | +| TP-C-040 | AH_REPORT_R2_044 | 已覆盖 | +| TP-C-041 | AH_REPORT_R2_045 | 已覆盖 | +| TP-C-042 | AH_REPORT_R2_046 | 已覆盖 | +| TP-C-043 | AH_REPORT_R2_047 | 已覆盖 | +| TP-C-044 | AH_REPORT_R2_048 | 已覆盖 | +| TP-C-045 | AH_REPORT_R2_049 | 已覆盖 | +| TP-C-046 | AH_REPORT_R2_050 | 已覆盖 | +| TP-C-047 | AH_REPORT_R2_051 | 已覆盖 | +| TP-C-048 | AH_REPORT_R2_052 | 已覆盖 | +| TP-C-049 | AH_REPORT_R2_053 | 已覆盖 | +| TP-C-050 | AH_REPORT_R2_055 | 已覆盖 | +| TP-C-051 | （承运人流水次日核验规则已内置于各R2核验用例中，独立用例视后续接口形态补充） | 已覆盖 | +| TP-D-001 | AH_REPORT_R3_001 | 已覆盖 | +| TP-D-002 | AH_REPORT_R3_002 | 已覆盖 | +| TP-D-003 | AH_REPORT_R3_003 | 已覆盖 | +| TP-D-004 | AH_REPORT_R3_004, AH_REPORT_R3_005 | 已覆盖 | +| TP-D-005 | AH_REPORT_R3_006, AH_REPORT_R3_007 | 已覆盖 | +| TP-D-006 | AH_REPORT_R3_008, AH_REPORT_R3_009 | 已覆盖 | +| TP-D-007 | AH_REPORT_R3_010 | 已覆盖 | +| TP-D-008 | AH_REPORT_R3_014 | 已覆盖 | +| TP-D-009 | AH_REPORT_R3_011 | 已覆盖 | +| TP-D-010 | AH_REPORT_R3_012 | 已覆盖 | +| TP-D-011 | AH_REPORT_R3_013 | 已覆盖 | +| TP-E-001 | AH_REPORT_ETC_001 | 已覆盖 | +| TP-E-002 | AH_REPORT_ETC_002 | 已覆盖 | +| TP-E-003 | AH_REPORT_ETC_003 | 已覆盖 | +| TP-E-004 | AH_REPORT_ETC_004 | 已覆盖 | +| TP-E-005 | AH_REPORT_ETC_005, AH_REPORT_ETC_006, AH_REPORT_ETC_011, AH_REPORT_ETC_012 | 已覆盖 | +| TP-E-006 | AH_REPORT_ETC_007 | 已覆盖 | +| TP-E-007 | AH_REPORT_ETC_008 | 已覆盖 | +| TP-E-008 | AH_REPORT_ETC_009 | 已覆盖 | +| TP-E-009 | AH_REPORT_ETC_010 | 已覆盖 | +| TP-F-001 | AH_REPORT_APL_001 | 已覆盖 | +| TP-F-002 | AH_REPORT_APL_003 | 已覆盖 | +| TP-F-003 | AH_REPORT_APL_004, AH_REPORT_APL_005 | 已覆盖 | +| TP-F-004 | AH_REPORT_APL_006 | 已覆盖 | +| TP-F-005 | AH_REPORT_APL_007, AH_REPORT_APL_016 | 已覆盖 | +| TP-F-006 | AH_REPORT_APL_002 | 已覆盖 | +| TP-F-007 | AH_REPORT_APL_008 | 已覆盖 | +| TP-F-008 | AH_REPORT_APL_009 | 已覆盖 | +| TP-F-009 | AH_REPORT_APL_010, AH_REPORT_APL_017 | 已覆盖 | +| TP-F-010 | AH_REPORT_APL_011 | 已覆盖 | +| TP-F-011 | AH_REPORT_APL_012, AH_REPORT_APL_013 | 已覆盖 | +| TP-F-012 | AH_REPORT_APL_005, AH_REPORT_APL_014 | 已覆盖 | +| TP-F-013 | AH_REPORT_APL_015 | 已覆盖 | +| TP-F-014 | AH_REPORT_APL_018 | 已覆盖 | +| TP-F-015 | AH_REPORT_APL_019 | 已覆盖 | +| TP-F-016 | AH_REPORT_APL_020 | 已覆盖 | +| TP-G-001 | AH_REPORT_LOG_001, AH_REPORT_LOG_002 | 已覆盖 | +| TP-G-002 | AH_REPORT_LOG_003 | 已覆盖 | +| TP-G-003 | AH_REPORT_LOG_004 | 已覆盖 | +| TP-G-004 | AH_REPORT_LOG_005 | 已覆盖 | +| TP-G-005 | AH_REPORT_LOG_006 | 已覆盖 | +| TP-G-006 | AH_REPORT_LOG_007 | 已覆盖 | +| TP-G-007 | AH_REPORT_LOG_008 | 已覆盖 | +| TP-G-008 | AH_REPORT_LOG_009 | 已覆盖 | +| TP-G-009 | AH_REPORT_LOG_010 | 已覆盖 | +| TP-X-001 | AH_REPORT_CROSS_001 | 已覆盖 | +| TP-X-002 | AH_REPORT_CROSS_002 | 已覆盖 | +| TP-X-003 | AH_REPORT_CROSS_003 | 已覆盖 | +| TP-X-004 | AH_REPORT_CROSS_004 | 已覆盖 | +| TP-X-005 | AH_REPORT_CROSS_005 | 已覆盖 | +| TP-X-006 | AH_REPORT_CROSS_007 | 已覆盖 | +| TP-X-007 | AH_REPORT_CROSS_008 | 已覆盖 | + +所有140个测试点均已映射到至少一条测试用例。 + +--- + +## 历史缺陷防御映射表 + +| 历史缺陷ID | 防御用例 | 备注 | +| :--- | :--- | :--- | +| BUG-202607-01（阶段依赖链断裂） | AH_REPORT_R1_007, AH_REPORT_R1_008, AH_REPORT_R2_024, AH_REPORT_R3_006, AH_REPORT_R3_007, AH_REPORT_CROSS_001 | 后端三重前置状态校验覆盖 | +| BUG-202607-02（重试幂等缺陷） | AH_REPORT_R1_013, AH_REPORT_R1_014, AH_REPORT_R2_025, AH_REPORT_R3_011, AH_REPORT_ETC_009, AH_REPORT_CROSS_006 | 分布式锁+唯一约束+前端防抖覆盖 | +| BUG-202607-03（跨模块数据不一致） | AH_REPORT_R2_002, AH_REPORT_R2_003, AH_REPORT_R3_013, AH_REPORT_CROSS_002 | 数据来源溯源验证覆盖 | +| BUG-202607-04（省份代码硬编码） | AH_REPORT_R1_006, AH_REPORT_CROSS_005 | 省份代码动态配置+多省份隔离覆盖 | + +--- + +## 漏测清单覆盖汇总 + +| 漏测类别 | 覆盖用例数 | 覆盖状态 | +| :--- | :--- | :--- | +| 空值/Null处理 | AH_REPORT_R1_018 (1条) | 已覆盖 | +| 金额精度 | AH_REPORT_R2_002, AH_REPORT_R2_055, AH_REPORT_R3_012, AH_REPORT_ETC_008 (4条) | 已覆盖 | +| 重复提交/防抖 | AH_REPORT_R1_013, AH_REPORT_R1_014, AH_REPORT_R2_025, AH_REPORT_R3_011, AH_REPORT_ETC_009 (5条) | 已覆盖 | +| 超时处理 | AH_REPORT_R1_015, AH_REPORT_R1_016, AH_REPORT_APL_015 (3条) | 已覆盖 | +| 列表字段完整性 | AH_REPORT_DASH_011, AH_REPORT_R2_004, AH_REPORT_R3_002, AH_REPORT_ETC_002, AH_REPORT_APL_003, AH_REPORT_LOG_006 (6条) | 已覆盖 | +| 查询重置 | AH_REPORT_DASH_010 (1条) | 已覆盖 | +| 状态与按钮映射 | AH_REPORT_DASH_013, AH_REPORT_R1_012 (2条) | 已覆盖 | +| 多阶段依赖链 | AH_REPORT_R1_007, AH_REPORT_R2_024, AH_REPORT_R3_007, AH_REPORT_CROSS_001 (4条) | 已覆盖 | +| 第三方核验逐项覆盖 | AH_REPORT_R2_005~AH_REPORT_R2_023 (14条，7类×通过+异常) + AH_REPORT_R2_030~AH_REPORT_R2_053 (24条，API文档12项补充核验×通过+异常) = 共38条覆盖API文档17项核验 | 已覆盖 | +| 重试+手动触发并发 | AH_REPORT_R1_013, AH_REPORT_R2_025, AH_REPORT_CROSS_006 (3条) | 已覆盖 | +| 跨模块数据一致性 | AH_REPORT_R2_002, AH_REPORT_R2_003, AH_REPORT_CROSS_002 (3条) | 已覆盖 | +| 省份/区域配置隔离 | AH_REPORT_R1_006, AH_REPORT_CROSS_005 (2条) | 已覆盖 | +| 上报数据字段溯源 | AH_REPORT_R2_002, AH_REPORT_R3_013, AH_REPORT_CROSS_002 (3条) | 已覆盖 | +| 标签颜色映射 | AH_REPORT_DASH_012, AH_REPORT_R1_023, AH_REPORT_R2_004 (3条) | 已覆盖 | +| 详情弹窗分组完整性 | AH_REPORT_DASH_014, AH_REPORT_DASH_015, AH_REPORT_R1_022, AH_REPORT_R3_003, AH_REPORT_ETC_003, AH_REPORT_APL_006 (6条) | 已覆盖 | +| 轨迹数据边界(2~2000) | AH_REPORT_R2_020, AH_REPORT_R2_021, AH_REPORT_R2_022, AH_REPORT_R2_023 (4条) | 已覆盖 | +| 申诉闭环 | AH_REPORT_APL_001, AH_REPORT_APL_002, AH_REPORT_APL_004 (3条) | 已覆盖 | +| 操作日志可追溯 | AH_REPORT_LOG_006, AH_REPORT_LOG_007, AH_REPORT_LOG_008, AH_REPORT_LOG_009, AH_REPORT_LOG_010 (5条) | 已覆盖 | + +--- + +> ⚠️ 待确认项： +> 1. 需求中"异常代码一览表"章节仅有标题无具体内容，需与产品确认完整的异常代码映射表后补充 AH_REPORT_APL_012 的详细验证数据。 +> 2. 自动重试的具体间隔时间（当前用例中使用5s/15s/30s为参考值），需与技术方案确认后更新 AH_REPORT_R1_010, AH_REPORT_R2_026, AH_REPORT_R3_010, AH_REPORT_ETC_007 中的重试间隔。 +> 3. ETC税额边界值（0.01元 → 税额=0.00）的四舍五入规则需与财务确认，更新 AH_REPORT_ETC_008。 +> 4. 申诉超时告警阈值（当前用例中使用7个工作日为参考值）需与产品确认，更新 AH_REPORT_APL_015。 +> 5. 建议在后续需求评审中人工确认安徽运八与现有云南运八上报逻辑是否存在字段/接口冲突。 +> 6. 部分用例中使用的模拟数据（如运单号YB202607130004~YB202607130057等）为测试用例设计时分配的虚拟编号，实际执行时需替换为测试环境中真实存在的运单数据。 +> 7. 涉及省平台回调的用例（如申诉复核反馈、核验结果返回），实际执行时需确认是否有省平台测试环境或mock工具支持。 diff --git a/output/versions/安徽运八需求/v5/安徽运八需求_测试用例.xlsx b/output/versions/安徽运八需求/v5/安徽运八需求_测试用例.xlsx new file mode 100644 index 0000000..dd4a3a6 Binary files /dev/null and b/output/versions/安徽运八需求/v5/安徽运八需求_测试用例.xlsx differ diff --git a/output/xmind_reports/安徽运八需求.xmind b/output/xmind_reports/安徽运八需求.xmind index a07c110..a0ff630 100644 Binary files a/output/xmind_reports/安徽运八需求.xmind and b/output/xmind_reports/安徽运八需求.xmind differ diff --git a/requirements/安徽运八需求.md b/requirements/安徽运八需求.md index 0a3961a..c8cf57e 100644 --- a/requirements/安徽运八需求.md +++ b/requirements/安徽运八需求.md @@ -1,174 +1,584 @@ -# 安徽运八需求 +# 安徽运八需求（以API文档为准重构） -> 文档角色：正式维护版需求 -> 原始来源：`source_docs\requirements_raw\安徽运八需求.docx` -> 标准化来源：`output\normalized_inputs\安徽运八需求\requirement.md` -> 输入类型：`docx` +> **重构原则**: API接口文档(网货企业端接口文档 V1.0.2) 为查询+申诉权威数据源，Showdoc文档为上报接口字段定义权威数据源。HTML原型为UI参考，原始需求文档为业务背景补充。 +> **重构时间**: 2026-07-13（最后更新: 2026-07-14，根据14项确认决议） +> **原始需求**: `source_docs/requirements_raw/安徽运八需求.docx` +> **API文档（查询+申诉）**: `E:\Downloads\网货企业端接口文档（最新）.pdf` V1.0.2 (2023-04) +> **Showdoc文档（上报接口·权威字段定义）**: `output/prototype/showdoc文档.md` +> **原型**: `anhuibaba_index.html` -## 维护信息 -- 当前维护文件：`requirements\安徽运八需求.md` -- 最近维护说明：暂无 +--- -## 技术方案来源 -- 未关联技术方案 +## 一、系统边界 -## 正式维护内容 +本需求涉及两套系统的对接： -安徽运八需求 -一、需求概述 -根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八）。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。本功能模块旨在实现上报流程的自动化管理，并提供异常监控与向平台发起申诉的能力。 -二、功能说明 -2.1 上报运单看板 -· 功能描述 -上报运单看板是系统的首页，集中展示所有上报阶段运单的汇总状态，支持按条件筛选、查看详情和发起申诉。 -· 查询条件 -运单号/托运单号/货源单号：模糊搜索 -上报阶段：全部 / 第一次上报 / 第二次上报 / 第三次上报 -核验状态：全部 / 异常 / 通过 -申诉状态：全部 / 未申诉 / 申诉中 / 申诉通过 / 申诉驳回 -操作按钮：查询、重置、导出 -· 列表字段 -货源单号、运单号、托运单号、车牌号、司机姓名、 -托运方名称、上报阶段、核验状态、申诉状态、异常项、 -货物名称、合同金额、最新核验时间、操作（申诉/进度/详情） -2.2 第一次上报（装货完成） -功能描述 -第一次上报在运单装货完成后自动触发，上报数据包含运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息、保险信息等。 -特殊说明 -• 上报完成后，若安徽运八平台核验通过，系统会自动调用“修改第一次上报部分字段”接口，更新装货后可能发生变化的字段（如实际里程），无需人工干预。 -• 若上报失败，系统需要自动重试（最多3次），若仍失败则通过系统站内信或者其他方式通知运营人员。 -• 第一次上传是后续两次上传的基础，若失败会导致后续上报无法进行，需重点关注。 -上报状态规则 -| 状态 | 说明 | 操作按钮 | 标签颜色 | -| 上传中 | 数据正在上报中 | 无 | 蓝色 | -| 已上传 | 上报成功 | 无 | 绿色 | -| 上传失败 | 上报超时 | 手动上传 | 红色 | -| 异常 | 数据校验不通过 | 详情查看异常原因 | 橙色 | -列表字段 -货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、业务类型、货物名称、装货地址、卸货地址、运输里程、合同编号、上报状态、操作（详情） -详情弹窗字段分组 -详情弹窗按以下子对象分组展示： -建单信息（必选，13字段）：上游企业委托运输单号、本运单单号、托运人建单时间、网络货运经营者名称、统一社会信用代码、道路运输经营许可证编号、业务类型代码、运输组货方式代码、司机接单时间、司机起运时间、承运合同编号、委托合同编号（可选）、运输里程（可选） -托运人信息（必选，7字段）：托运人名称、托运人统一社会信用代码、框架合同编号（可选）、装货地点、装货经度、装货纬度、装货地行政区划代码 -收货方信息（必选，5字段）：收货方名称、收货方统一社会信用代码/身份证号、收货地点、收货经度、收货纬度 -司机信息（必选，13字段）：司机姓名、身份证号、驾驶证号、驾驶证发证机关、从业资格证号、从业资格证有效期起、从业资格证有效期至、税务登记证号、手机号、驾驶证有效期起、驾驶证有效期至、准驾车型、省份代码 -接单车辆信息（必选，19字段）：车牌号、车牌颜色编码、号牌种类、车辆识别代号VIN)、车主姓名/单位名称、车主证件号、使用性质、车辆类型、能源类型、注册日期、发证日期、发证机关、核定载质量吨)、总质量吨)、道路运输证号、挂车牌照号（可选）、行驶证档案编号（可选）、道路运输证有效期起（可选）、道路运输证有效期至（可选） -货物信息（必选，可多条，4字段）：货物名称、货物类型代码、货物量、计量单位 -保险信息（可选，2字段）：保险单号、保险公司名称 -异常信息：核验状态、异常原因、异常时间、处理状态 -2.3 第二次上报（打款完成） -功能描述 -第二次上报在运费支付完成后系统自动触发，上报数据包含运抵信息、货主资金流水、承运人资金流水、承运合同信息、委托合同信息、车辆轨迹信息等。 -特殊说明 -• 第二次上传核验项最多，是最容易出现异常的环节，需要重点关注。 -• 若资金流水单号重复，会导致上报失败，系统会自动检查并提示。 -• 车辆轨迹点位数量不足或偏差过大，会导致"车辆轨迹合规"核验异常，可通过"补传轨迹"功能补充轨迹数据。 -• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。 -列表字段 -货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、承运运费、总金额、付款方式、付款时间、收款人、收款账号、收款账号类型、核验状态、异常项、上报状态、操作（上报/详情） -收款账号类型说明 -• 个人账户：司机个人银行卡账号，标签为蓝色 -• 对公账户：企业银行账号，标签为绿色 -详情弹窗字段分组 -（1）运单信息（必选）：同第一次上报 -（2）托运方信息（必选）：同第一次上报 -（3）收货方信息（必选）：同第一次上报 -（4）资金流水信息（必选）：支付金额、支付方式、支付时间、付款方名称、收款方名称、收款人、收款账号、收款账号类型、流水号、支付状态 -（5）车辆轨迹信息（必选，可多条，2~2000个点）：定位类型、定位时间、定位地点、经度、纬度、轨迹类型 -（6）异常信息：核验状态、异常原因、异常时间、处理状态 -核验内容（监管平台自动核验，异常时可发起申诉） -| 核验项 | 说明 | -| 运单重复核验 | 检查同一运单是否重复上报 | -| 车辆资质核验 | 检查车辆道路运输证是否在有效期内 | -| 司机资质核验 | 检查司机从业资格证是否在有效期内 | -| 集中支付核验 | 检查资金流水是否通过网货平台集中支付 | -| 资金流水核验 | 检查资金流水单号是否重复、金额是否匹配 | -| 合同核验 | 检查运输合同和委托合同是否有效 | -| 车辆轨迹合规核验 | 检查车辆轨迹是否真实、与运单路线是否匹配 | -2.4 第三次上报（开票完成） -功能描述 -第三次上报在发票开具完成后触发，上报数据包含运单信息（托运单号数组）、发票信息、油气发票信息等。 -特殊说明 -• 第三次上传需要在运单完成第二次上传后方可进行。 -• 若增值税发票验证失败，会导致上报失败，需检查发票信息是否正确。 -• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。 -列表字段 -货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、发票号码、发票金额、开票日期、核验状态、异常原因、上报状态、操作（详情） -详情弹窗字段分组 -（1）运单信息（必选）：同第一次上报 -（2）发票信息（必选，17字段）：托运单号数组、发票号码、发票代码号、发票金额价税合计)、开票日期、销售方名称、销售方纳税人识别号、销售方地址、销售方电话、销售方开户行、销售方银行账户、受票方名称、受票方纳税人识别号、受票方地址、受票方电话、受票方开户行、受票方银行卡号 -（3）油气发票信息（可选，可多条）：油气托运单号、油气发票文件 -（4）异常信息：核验状态、异常原因、异常时间、处理状态 -2.5 ETC发票上传 -功能描述 -ETC发票上传用于上报车辆通行高速公路的ETC发票信息，作为税务抵扣凭证。 -特殊说明 -• ETC发票上传需要在税务抵扣完成后进行，否则会导致上报失败。 -• 若ETC发票验证失败，会导致上报失败，需检查发票信息是否正确。 -• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。 -列表字段 -货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、ETC发票号码、发票金额、税率、上传状态、操作（详情） -详情弹窗字段分组 -（1）运单信息：运单号、货源单号、托运单号、车牌号、司机姓名、托运方名称、收货方名称 -（2）ETC发票信息（每张发票18字段）：ETC发票号码、ETC发票代码、开票时间、发票金额、税率、税额、价税合计、销售方名称、销售方税号、受票方名称、受票方税号、入口收费站、出口收费站、交易时间、交易金额、交易匹配时间、交易流水号、ETC发票文件 -（3）异常信息：核验状态、异常原因、异常时间、处理状态 -2.6 异常申诉功能 -运单完成第二次上传后，安徽省管理平台自动进行 7 大类核验（车辆资质、司机资质、资金流水、合同、轨迹等）。如核验结果为异常时，运营人员可通过申诉机制向平台说明情况并申请重新核验。 -本模块补全“异常查询 → 发起申诉 → 跟踪监管平台反馈 → 合规判断”的完整闭环。 -当上报数据被核验为异常时，运营人员可发起申诉，向安徽监管平台说明情况并申请重新核验。申诉记录管理页面展示所有申诉记录及省平台反馈结果。 -列表字段 -运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、异常项、申诉状态、申诉时间、申诉人、省平台反馈结果、监管平台反馈时间、操作（详情/重新申诉） -详情弹窗字段分组 -（1）申诉信息：申诉单号、上报阶段、异常项、申诉原因、申诉状态、申诉时间、申诉人、申诉附件 -（2）运单信息：运单号、托运单号、车牌号、司机姓名、托运方名称 -（3）异常信息：核验状态、异常原因、异常时间 -（4）省平台反馈信息：反馈结果、反馈时间、反馈意见 -（5）处理记录：操作人、操作时间、操作类型、操作内容（时间线展示） -申诉复核说明 -（注：申诉由安徽监管平台复核，非我方审核） -（复核不通过时，可补充材料后重新发起申诉） -异常代码一览表 -2.7 上报日志 -功能描述 -上报日志记录所有上报接口的调用记录，用于问题排查和审计。 -查询条件 -• 运单号/托运单号/货源单号：模糊搜索 -• 上报阶段：全部 / 第一次上报 / 第二次上报 / 第三次上报 / ETC上传 -• 上报结果：全部 / 成功 / 失败 -• 开始时间 ~ 结束时间：时间范围筛选 -列表字段 -序号、货源单号、运单号、托运单号、上报阶段、上报结果、接口URL、HTTP状态码、响应时间、上报时间、操作（弹窗详情查看完整请求/响应报文） -三. 数据字段说明 -3.1 第一次上报字段（装货完成） -核心子对象及必选字段： -• waybillInfo（建单信息）：originalDocumentNumber、shippingNoteNumber、documentCreateTime、carrier、unifiedSocialCreditIdentifier、permitNumber、businessTypeCode、goodsArrangementTypeCode、orderReceivingTime、departureTime、commercialContractNumber、contractNumber、mileage -• consignorInfo（托运人信息）：consignor、consignorId、frameContractNumber、placeOfLoading、loadingLongitude、loadingLatitude、loadingCountrySubdivisionCode -• consigneeInfo（收货方信息）：consignee、consigneeId、goodsReceiptPlace、unLoadingLongitude、unLoadingLatitude -• driverInfo（司机信息）：driverName、drivingIdNumber、drivingLicense、issuingOrganizations、qualificationCertificate、qualificationCertificateFrom、qualificationCertificateTo、taxRegistrationCertificate、telephone、validPeriodFrom、validPeriodTo、vehicleClass、provinceCode -• carInfo（接单车辆信息）：vehicleNumber、vehiclePlateColorCode、LicensePlateTypeCode、vin、owner、ownerId、useCharacter、vehicleType、vehicleEnergyType、registerDate、issueDate、issuingOrganizations、vehicleTonnage、grossMass、roadTransportCertificateNumber、trailerVehiclePlateNumber、vehicleLicenseNumbe、roadTransportSocialCreditFrom、roadTransportSocialCreditTo -• goodsInfos（货物信息，可多条）：descriptionOfGoods、cargoTypeClassificationCode、quantity、unit -• insuranceInformation（保险信息，可选）：policyNumber、insuranceCompany -3.2 第二次上报字段（打款完成） -新增字段说明： -• 收款人（自定义扩展字段）：对应资金流水中的收款方名称recipient) -• 收款账号（自定义扩展字段）：对应资金流水中的收款账号receiptAccount) -• 收款账号类型（自定义扩展字段）：个人账户 / 对公账户，为我方自定义列 -3.3 第三次上报字段（开票完成） -核心字段： -• 发票号码（invoiceNo）：增值税发票号码 -• 发票代码（invoiceCode）：增值税发票代码 -• 发票金额（invoiceAmount）：价税合计（保留2位小数） -（注：第三次上传的invoice无税率字段，税率仅出现在ETC发票上传中） -• 销售方名称（sellerName）：开票方企业名称 -• 受票方名称（buyerName）：托运人/货主企业名称 -3.4 ETC发票字段 -核心字段： -• ETC发票号码（etcInvoiceNo）：高速公路通行费电子发票号码 -• 入口收费站（entryStation）：通行入口 -• 出口收费站（exitStation）：通行出口 -• 税额（taxAmount）：可抵扣税额（税率3%） -详细数据接口字段请查阅上报接口： -https://www.showdoc.com.cn/2210641821476236/9919735893682511 -密码：szjj@2023 -原型： -接口文档： +| 系统 | 职责 | 本文档覆盖 | +|:---|:---|:---| +| **运八平台（我方）** | 自动触发三阶段上报、ETC上传；查询核验结果；发起/跟踪申诉；查看上报日志 | 全量 | +| **安徽省级网络货运监测系统（省平台）** | 接收上报数据；执行核验；受理申诉并反馈 | 仅接口交互 | + +API文档覆盖的是**运八平台→省平台**的查询和申诉接口。上报触发逻辑（装货完成/打款完成/开票完成自动触发）属于运八平台内部业务逻辑，API文档中未定义上报提交接口。 + +**上报接口（5个·Showdoc权威）** 由Showdoc文档定义，是运八平台向省平台上送数据的接口，与查询+申诉API是两个独立的接口体系： + +| Showdoc上报接口 | URL | 说明 | +|:---|:---|:---| +| 上传委托合同（框架） | `/api/dataUpload/mandateContractFrame` | **前置步骤**：运单第一次上报前必须先上传框架合同 | +| 第一次上传 | `/api/dataUpload/firstUpload` | 装货完成后上报（含waybillInfo, consignorInfo, consigneeInfo, driverInfo, carInfo, goodsInfos, insuranceInformation） | +| 第二次上传 | `/api/dataUpload/secondUpload` | 打款完成后上报（含arrivalInfo, ownerStatements, carrierStatements, carrierContractInfo, ownerContractInfo, trackList） | +| 第三次上传 | `/api/dataUpload/thirdUpload` | 开票完成后上报（含invoice, oilGasInvoices） | +| ETC发票上传 | `/api/dataUpload/etcInvoiceUpload` | 税务抵扣确认后上传（含shippingNoteNumber, vehicleNumber, vehiclePlateColorCode, etcInvoices） | +| 修改第一次上报部分字段 | `/api/dataUpload/updateFirstUploadParam` | 第一次上报成功后更新变化字段 | + +> **关键区分**: Showdoc的5个上报接口 + updateFirstUploadParam 是**数据上报**通道；PDF文档的9个接口是**查询+申诉**通道。两者共同构成运八平台的完整对接方案。 + +--- + +## 二、API接口清单（权威来源：接口文档 V1.0.2） + +### 2.1 通用规范 + +| 项目 | 规范 | +|:---|:---| +| 基地址 | `http://*******/api/` | +| 协议 | HTTP POST | +| 请求格式 | JSON（除上传文件接口外） | +| 响应格式 | `{"code":200, "message":"操作成功", "data":{}}` | +| 认证 | JWT Token，调用 `/sys/login` 获取，除登录接口外均需在请求头携带 | +| 时间格式 | `yyyy-MM-dd HH:mm:ss` | +| 成功码 | `code=200` | +| 失败码 | `code=500` | + +### 2.2 接口一览（共9个） + +| # | 接口 | URL | 说明 | +|:---:|:---|:---|:---| +| 1 | 获取token | `POST /sys/login` | JWT认证，参数: loginName, loginPassword | +| 2 | 上传申诉附件 | `POST /appeal/uploadFile` | 文件上传，参数: file (File) | +| 3 | 提交申诉运单 | `POST /appeal/insert` | 发起申诉，参数: freightSheetNumber, complaintNumber, attachmentUrl, content, verificationAbnormalItems | +| 4 | 查询异常运单信息 | `POST /verificationSummary/page` | 分页查询，支持多维度筛选 | +| 5 | 查询申诉进度 | `POST /appeal/page` | 分页查询申诉记录及审核结果 | +| 6 | 查询运单核验详情 | `POST /verificationSummary/verificationDetail` | 单运单全部核验项明细 | +| 7 | 查询发票是否合规 | `POST /verificationSummary/cargoOwnerInvoiceInfo` | 判断托运人发票系统核验是否合规 | +| 8 | 运单里程核验查询 | `POST /verificationSummary/mileageVerificationInfo` | 批量查询运单里程核验状态 | +| 9 | 运单里程申诉 | `POST /mileageAppeal/insert` | 对里程核验结果发起申诉 | + +### 2.3 接口详细定义 + +#### 接口1: 获取token +``` +POST /sys/login +请求: { "loginName": "xxx", "loginPassword": "xxx" } +响应: { "code": 200, "data": { "token": "...", "expireTime": 1681219619843, "loginName": "ceshi", "name": "测试" } } +``` + +#### 接口2: 上传申诉附件 +``` +POST /appeal/uploadFile +请求: multipart/form-data, 字段 file (File) +``` + +#### 接口3: 提交申诉运单 +``` +POST /appeal/insert +请求: + freightSheetNumber String 运单号 必填 + complaintNumber String 申诉编号 必填 + attachmentUrl String 申诉附件URL 必填 + content String 申诉内容 必填 + verificationAbnormalItems String 核验异常项ID 必填 (逗号分隔，如"120,160") +``` + +#### 接口4: 查询异常运单信息 +``` +POST /verificationSummary/page +请求: + pageIndex int 页码 必填 + pageSize int 每页条数 必填 + freightSheetNumber String 运单号 可选 + verificationAbnormalItems String 异常项ID 可选 (多个逗号拼接) + driverName String 驾驶员姓名 可选 + driverIdCard String 驾驶员身份证号 可选 + vehicleNumber String 车牌号 可选 + appealStateId int 申诉状态ID 可选 + verifyStateId int 核验状态ID 可选 + beginTime ~ endTime 运单创建时间范围 可选 + beginFirstVerifyTime ~ endFirstVerifyTime 首次核验时间范围 可选 + beginLastVerifyTime ~ endLastVerifyTime 最新核验时间范围 可选 + beginInsertTime ~ endInsertTime 插入时间范围 可选 + +响应: + pageRecords[]: + freightSheetNumber String 运单号 + appealStateId int 申诉状态ID + appealStateName String 申诉状态名称 + verificationAbnormalItem String 核验异常项 + createTime date 运单创建时间 + lastVerifyTime date 最新核验时间 + firstVerifyTime date 首次核验时间 + vehicleNumber String 车牌号 + driverName String 驾驶员姓名 + driverIdCard String 驾驶员身份证号 + verifyStateId int 核验状态ID + verifyStateName String 核验状态名称 + abnormalDetails[]: + id int 异常项ID + name String 异常项名称 + message String 异常原因 + time date 异常时间 + state int 异常项处理状态 (100=未申诉, 110=申诉中) +``` + +#### 接口5: 查询申诉进度 +``` +POST /appeal/page +请求: + pageIndex int 页码 必填 + pageSize int 每页条数 必填 + freightSheetNumber String 运单号 可选 + abnormalTypeId String 核验异常项ID 可选 + auditStateId String 审核状态ID 可选 + beginTime ~ endTime 申诉时间范围 可选 + auditBeginTime ~ auditEndTime 审核时间范围 可选 + complaintNumber String 申诉编号 可选 + +响应: + pageRecords[]: + complaintNumber String 申诉编号 + freightSheetNumber String 运单号 + content String 申诉内容 + complainantName String 申诉人 + auditStateId int 审核状态ID + auditStateName String 审核状态名称 + auditorName String 审核人 + auditRemark String 审核备注 + auditTime date 审核时间 + verificationAbnormalItem String 运单异常项 + cancelPerson String 取消人 + cancelReason String 取消原因 + cancelTime date 取消时间 + revokeUserName String 撤回人 + revokeTime date 撤回时间 + createTime date 创建时间 + appealAbnormalList[]: + verificationTypeId int 异常项ID + verificationTypeName String 异常项名称 +``` + +#### 接口6: 查询运单核验详情 +``` +POST /verificationSummary/verificationDetail +请求: + freightSheetNumber String 运单号 必填 + beginInsertTime String 插入时间-开始 可选 + endInsertTime String 插入时间-结束 可选 + +响应: + pageRecords[].details[]: + verificationCode int 核验项编码 + verificationName String 核验项名称 + verificationState String 核验状态 + verificationStateId int 核验状态ID + verificationTime date 核验时间 + message String 核验信息 +``` + +#### 接口7: 查询发票是否合规 +``` +POST /verificationSummary/cargoOwnerInvoiceInfo +请求: { "freightSheetNumber": "55141359" } +响应: { "isSystemVerification": true } // true=系统核验合规, false=人工判定合规 +``` + +#### 接口8: 运单里程核验查询 +``` +POST /verificationSummary/mileageVerificationInfo +请求: { "freightSheetNumberList": ["22222222", "111111"] } +响应: [ + { "verificationStateId": 110, "freightSheetNumber": "22222222", "mileage": 350.263 }, + { "verificationStateId": null, "freightSheetNumber": "4658151", "mileage": null } +] +// 注: 运单未上报里程时 verificationStateId 和 mileage 为 null +``` + +#### 接口9: 运单里程申诉 +``` +POST /mileageAppeal/insert +请求: + freightSheetNumber String 运单号 必填 + content String 申诉内容 必填 + complaintNumber String 申诉编号 必填 + mileage String 里程数 必填 +``` + +--- + +## 三、数据字典（权威来源：接口文档 §4.1~§4.5） + +### 3.1 异常项ID对照表（§4.1）— 共17项 + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 委托合同 | 托运人与承运人签订的委托运输合同核验 | +| 120 | 承运合同 | 承运人以自身名义签订的运输合同核验 | +| 130 | 实时定位 | 车辆实时定位数据核验 | +| 140 | 运单时间逻辑 | 运单各时间节点的逻辑合理性核验（如装货时间<卸货时间） | +| 150 | 车辆资质 | 车辆道路运输经营许可证有效性核验 | +| 160 | 道路运输证 | 车辆道路运输证有效期核验 | +| 170 | 驾驶证 | 驾驶员驾驶证有效性核验 | +| 180 | 从业资格证 | 驾驶员从业资格证有效期核验 | +| 190 | 车辆重复 | 同一车辆在同一时段是否存在多运单 | +| 200 | 司机重复 | 同一司机在同一时段是否存在多运单 | +| 210 | 车辆轨迹 | GPS轨迹真实性、与运单路线匹配度核验 | +| 220 | 运费收款 | 运单是否在运费收款方名下 | +| 230 | 公司统一收款 | 是否通过公司账户统一收款 | +| 240 | 集中支付 | 是否通过网络货运平台集中支付 | +| 250 | 资金流水 | 资金流水单号唯一性、金额匹配核验 | +| 260 | 发票信息 | 托运人发票信息核验（第三次上报相关） | +| 270 | 非通行车辆可开票 | 非通行车辆是否允许开具通行费发票 | + +### 3.2 运单核验状态（§4.2） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未核验 | 运单尚未被省平台核验 | +| 110 | 核验通过 | 全部核验项通过 | +| 120 | 全部异常 | 存在核验不通过的异常项 | + +### 3.3 运单部分核验状态（§4.3） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未核验 | 尚未核验 | +| 110 | 部分核验 | 部分核验项已通过，仍有待核验项 | +| 120 | 全部核验 | 全部核验项已出结果 | + +### 3.4 运单申诉状态（§4.4）— 权威枚举 + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| **100** | **未申诉** | 尚未发起申诉 | +| **110** | **审核通过** | 省平台审核通过 | +| **120** | **审核不通过** | 省平台审核驳回 | +| **130** | **已取消** | 省平台侧操作，我方只读（申诉由省平台取消，非我方可操作状态） | + +> **已取消(130)说明**: 状态130=已取消是**省平台侧直接操作**产生的状态，我方系统不提供"取消申诉"功能。运八平台只能查询到此状态，不能主动将申诉状态设为130。我方申诉状态流转不包含取消操作。 + +### 3.5 附件状态（§4.5） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未处理 | 申诉附件尚未被省平台处理 | +| 110 | 处理通过 | 附件核验通过 | +| 120 | 处理异常 | 附件核验异常 | + +--- + +## 四、功能模块（综合API文档+原型+原始需求） + +### 4.1 上报运单看板 + +**入口**: 侧边栏 → 上报运单看板 + +**统计卡片**（原型定义）: +- 异常运单数、待申诉数、申诉中数、已处理数 + +**查询条件**（综合原型+接口4请求参数）: + +| 筛选项 | 类型 | 可选值 | +|:---|:---|:---| +| 运单号/托运单号/货源单号 | 文本输入 | 模糊搜索 | +| 上报阶段 | 下拉 | 全部 / 第一次上报 / 第二次上报 / 第三次上报 | +| 核验状态 | 下拉 | 全部 / 异常 / 通过 | +| 申诉状态 | 下拉 | 全部 / 未申诉(100) / 审核通过(110) / 审核不通过(120) / 已取消(130·省平台只读) | + +**列表字段**（原型为准，15列含勾选）: +货源单号 / 运单号 / 托运单号 / 车牌号 / 司机姓名 / 上报阶段 / 托运方名称 / 核验状态 / 申诉状态 / 异常项 / 货物名称 / 合同金额 / 最新核验时间 / 操作 + +**操作按钮**: +- 异常运单: [申诉] [详情] +- 申诉中运单: [进度] [详情] +- 正常运单: [详情] + +**标签颜色**（原型CSS定义）: +- 蓝色 `.tag-blue`: 上传中、申诉中 +- 绿色 `.tag-green`: 已上传、通过、已完成、申诉通过、对公账户 +- 红色 `.tag-red`: 上传失败、异常、申诉驳回 +- 橙色 `.tag-orange`: 异常项标签、待上报 +- 灰色 `.tag-gray`: 未申诉 +- 紫色 `.tag-purple`: (预留) + +### 4.2 委托合同上传（前置步骤·Showdoc权威） + +**来源**: Showdoc接口 `POST /api/dataUpload/mandateContractFrame` + +**时机**: 在进行运单的第一次上报前，需先将委托合同（框架）通过此接口上传至省平台。 + +**说明**: +- 委托合同（框架）和委托合同**二选一**上报 +- 文件信息可暂时不传，在修改委托合同时再补充合同文件 +- 后续合同有新增或修改，再调用上传或修改接口即可 +- 目前省平台不支持单独查询合同，可在运单第一次上报后，在运单信息中查看合同 + +**核心字段**: +| 参数 | 必选 | 说明 | +|:---|:---|:---| +| contract_number | 是 | 合同编号 | +| expire_time | 是 | 合同有效期截止时间 yyyy-MM-dd | +| unified_social_credit_identifier | 可选 | 单托运企业统一社会信用代码 | +| owner_enterprise_name | 可选 | 单托运企业名称 | +| enterpriseList | 可选 | 多托运企业列表（与单托运企业互斥，都传值默认取单） | +| uploadFileInfo | 否 | 文件信息（name / url / dataList三选一） | + +### 4.3 第一次上报（装货完成） + +**触发条件**: 运单装货完成 AND 货源税源地=安徽 + +**上报数据子对象**（以接口文档字段定义为准）: + +| 子对象 | 必选/可选 | 核心字段（Showdoc权威定义） | +|:---|:---|:---| +| waybillInfo（建单信息） | 必选 | originalDocumentNumber, shippingNoteNumber, documentCreateTime(yyyyMMddHHmmss), carrier, unifiedSocialCreditIdentifier, permitNumber, businessTypeCode, goodsArrangementTypeCode, orderReceivingTime(yyyyMMddHHmmss), departureTime(yyyyMMddHHmmss), commercialContractNumber, contractNumber(可选), mileage(可选·3位小数) | +| consignorInfo（托运人信息） | 必选 | consignor, consignorId, frameContractNumber(可选), placeOfLoading, loadingLongitude(6位小数), loadingLatitude(6位小数), loadingCountrySubdivisionCode | +| consigneeInfo（收货方信息·6字段） | 必选 | consignee, consigneeId, goodsReceiptPlace, unLoadingLongitude(6位小数), unLoadingLatitude(6位小数), unLoadingNationSubdivisionCode | +| driverInfo（司机信息·15字段） | 必选 | driverName, telephone, drivingIdNumber, drivingLicense, vehicleClass, issuingOrganizations, validPeriodFrom(yyyyMMdd), validPeriodTo(yyyyMMdd), qualificationCertificate, provinceCode, qualificationCertificateFrom(可选), qualificationCertificateTo(可选), taxRegistrationCertificate(可选), registerDate(yyyyMMdd), anchoredUrl(可选·文件列表) | +| carInfo（车辆信息·20字段） | 必选 | vehicleNumber, vehiclePlateColorCode, vehicleType, LicensePlateTypeCode, owner, ownerId(可选), useCharacter, vin, issuingOrganizations, registerDate(yyyyMMdd), issueDate(yyyyMMdd), vehicleEnergyType, vehicleTonnage(Double), grossMass(Double), roadTransportCertificateNumber, trailerVehiclePlateNumber(可选), vehicleLicenseNumber(可选), roadTransportSocialCreditFrom(可选·yyyyMMdd), roadTransportSocialCreditTo(可选·yyyyMMdd), anchoredUrl(可选·文件列表) | +| goodsInfos（货物信息） | 必选，可多条 | descriptionOfGoods, cargoTypeClassificationCode, quantity(Double), unit | +| insuranceInformation（保险信息） | 可选 | policyNumber, insuranceCompany | + +**业务规则**: +- 仅安徽税源地(省份代码=34，非28)运单触发 +- 上报成功后自动调用"修改第一次上报部分字段"接口更新变化字段 +- 失败自动重试最多3次，全部失败后站内信通知运营 +- 第一次上报是后续上报的前置条件（后端校验） + +**列表页**（原型为准，14列+勾选）: +货源单号 / 运单号 / 托运单号 / 车牌号 / 司机姓名 / 托运方名称 / 业务类型 / 货物名称 / 装货地址 / 卸货地址 / 运输里程 / 合同编号 / 上报状态 / 操作 + +**上报状态**（内部系统状态，非API枚举）: +- 上传中（蓝色） +- 已上传（绿色） +- 上传失败（红色）— 显示"手动上传"按钮 +- 异常（橙色） + +### 4.4 第二次上报（打款完成） + +**触发条件**: 财务打款完成 AND 第一次上报已完成 + +**核验项**: 省平台自动核验，共17项（见§3.1）。每项独立产生核验结果，核验异常项可通过申诉机制逐项申诉。 + +**上报数据子对象**（Showdoc权威·第二次上传结构完全不同）: +| 子对象 | 必选/可选 | 核心字段 | +|:---|:---|:---| +| arrivalInfo（运抵信息） | 必选 | shippingNoteNumber, startTicketFileUrl(文件列表), arrivalTime(yyyyMMddHHmmss), arrivalTicketFileUrl(文件列表), waybillFreightAmount(Double·3位小数·承运运费), totalMonetaryAmount(Double·3位小数·委托运费) | +| ownerStatements（货主流水） | 必选 | documentNumber, carrier, actualCarrierId, paymentMeansCode, paymentName, paymentAccount, paymentBankName(选填), recipient, receiptAccount, receiptBankName(选填), sequenceCode, monetaryAmount(Double·3位小数), appointmentTime(yyyyMMdd), payTime(yyyyMMddHHmmss) | +| carrierStatements（承运人流水） | 必选 | documentNumber, carrier, actualCarrierId, paymentMeansCode, paymentName, paymentAccount, paymentBankName, recipient, receiptIdCard, receiptAccount, receiptBankName, sequenceCode, monetaryAmount(String·3位小数), appointmentTime(yyyyMMdd), payTime(yyyyMMddHHmmss), oilCardAmount(选填·3位小数), replaceAgreementFiles(可选·代收协议文件) | +| carrierContractInfo（承运合同） | 必选 | contractBusinessName, contractNumber, partyAName, partyAId, partyBName, partyBId, contractedCarryingCapacity(Double·3位小数), unit, contractAmount(Double·3位小数), agreedBusinessCompletionTime(yyyyMMdd), promisePayTime(yyyyMMdd), partyBReceiptName, partyBAccount, bankName(否), placeOfLoading, goodsReceiptPlace, descriptionOfGoods, vehicleNumber, contractSigningTime(yyyyMMddHHmmss), contractUrl(文件列表) | +| ownerContractInfo（委托合同） | 可选 | 18字段（委托合同与框架合同二选一上报） | +| trackList（车辆轨迹） | 必选，2~2000点 | locationMethod(BD/LBS/WECHAT/APP), locationTime(yyyyMMddHHmmss), locationAddress, longitude(6位小数), latitude(6位小数), trackType(LOADING/UNLOADING/NORMAL·可选) | + +**列表页**（原型为准，17列+勾选）: +货源单号 / 运单号 / 托运单号 / 车牌号 / 司机姓名 / 托运方名称 / 承运运费 / 总金额 / 付款方式 / 付款时间 / 收款人 / 收款账号 / 收款账号类型 / 核验状态 / 异常项 / 上报状态 / 操作 + +**收款账号类型标签**: 个人账户=蓝色, 对公账户=绿色 + +### 4.5 第三次上报（开票完成） + +**触发条件**: 发票开具完成 AND 第二次上报已完成 + +**前置条件**: 第二次上报必须完成（后端校验） + +**API关联接口**: +- `POST /verificationSummary/cargoOwnerInvoiceInfo` — 查询托运人发票系统核验是否合规 +- 响应: `isSystemVerification`: true=系统核验合规, false=人工判定合规 + +**列表页**（原型为准，15列+勾选）: +货源单号 / 运单号 / 托运单号 / 发票号码 / 发票金额 / 税率 / 销售方名称 / 受票方名称 / 开票日期 / 油气票张数 / 核验状态 / 异常原因 / 上报状态 / 操作 + +### 4.6 ETC发票上传 + +**触发条件**: ETC发票税务抵扣成功后，由运营人员在运八系统**手动确认抵扣完成**，确认后系统触发ETC发票上传（非自动触发） + +**列表页**（原型为准，10列+勾选）: +货源单号 / 运单号 / 托运单号 / ETC发票号 / 交易金额 / 入口收费站 / 出口收费站 / 交易时间 / 上传状态 / 操作 + +**详情弹窗字段**（原型为准）: +- 运单信息: 运单号、货源单号、托运单号、车牌号、司机姓名、托运方名称、收货方名称 +- ETC发票信息: ETC发票号码、ETC发票代码、交易金额、税率(3%)、发票金额(不含税)、税额、入口收费站、出口收费站、交易时间、发票状态 + +### 4.7 异常申诉功能 + +**关联API接口**: +- `POST /appeal/uploadFile` — 上传申诉附件 +- `POST /appeal/insert` — 提交申诉 +- `POST /appeal/page` — 查询申诉进度 +- `POST /mileageAppeal/insert` — 里程申诉（独立接口） + +**申诉流程**（闭环）: +``` +异常运单查询(接口4) → 发起申诉(接口3) → 省平台复核 → +查询申诉进度(接口5) → 审核通过(110) | 审核不通过(120) → +重新申诉(接口3) [审核不通过时] +``` + +**申诉状态流转**（以API §4.4为准，我方可控流转）: +``` +未申诉(100) → 提交申诉 → 未申诉(100) [申诉中·abnormalDetails.state=110] +未申诉(100) → 省平台审核通过 → 审核通过(110) [终态] +未申诉(100) → 省平台审核驳回 → 审核不通过(120) → 重新申诉 → 未申诉(100) [新申诉单] +``` + +> **已取消(130)**: 此状态由省平台侧操作产生（如省平台管理员取消申诉），我方系统不提供触发入口，仅被动查询和展示。因此不纳入我方申诉状态流转中。 + +**列表页**（原型为准，14列+勾选）: +运单号 / 托运单号 / 车牌号 / 司机姓名 / 托运方名称 / 上报阶段 / 核验状态 / 异常项 / 申诉状态 / 申诉时间 / 申诉人 / 省平台反馈结果 / 省平台反馈时间 / 操作 + +**详情弹窗分组**（原型为准）: +- 申诉信息: 申诉单号、上报阶段、异常项、申诉原因、申诉状态、申诉时间、申诉人、申诉附件 +- 运单信息: 运单号、托运单号、车牌号、司机姓名、托运方名称 +- 异常信息: 核验状态、异常原因、异常时间 +- 省平台反馈信息: 反馈状态、反馈时间、反馈结果、反馈意见 +- 处理记录（时间线）: 操作人、操作时间、操作类型、操作内容 + +### 4.8 上报日志 + +**查询条件**（原型为准）: +- 运单号/托运单号/货源单号: 模糊搜索 +- 上报阶段: 全部 / 第一次上报 / 第二次上报 / 第三次上报 / ETC上传 +- 上报结果: 全部 / 成功 / 失败 +- 时间范围: 开始时间 ~ 结束时间 + +**列表字段**（原型为准，11列）: +序号 / 货源单号 / 运单号 / 托运单号 / 上报阶段 / 上报结果 / 接口URL / HTTP状态码 / 响应时间 / 上报时间 / 操作 + +**日志详情弹窗**: 展示完整请求报文（URL/Method/Headers/Body）和响应报文（StatusCode/Headers/Body），JSON格式化展示，支持一键复制。 + +--- + +## 五、状态枚举汇总（以API文档为权威） + +### 5.1 申诉状态（API §4.4 权威） + +| Code | 名称 | 原始需求对应 | 我方可操作 | 说明 | +|:---:|:---|:---|:---:|:---| +| 100 | 未申诉 | 未申诉 + 申诉中 | 是 | 含已提交但省平台尚未审核的情况（申诉中通过 abnormalDetails[].state=110 标识） | +| 110 | 审核通过 | 申诉通过 | 否（终态） | 省平台审核通过 | +| 120 | 审核不通过 | 申诉驳回 | 否（可重新申诉） | 省平台审核驳回，可重新发起申诉 | +| 130 | 已取消 | （无） | **否·省平台只读** | 省平台侧操作取消，我方仅查询展示 | + +### 5.2 核验状态（API §4.2 权威） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未核验 | 运单尚未核验 | +| 110 | 核验通过 | 全部17项核验通过 | +| 120 | 全部异常 | 存在核验异常项 | + +### 5.3 异常项处理状态（API §4.1 子字段） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未申诉 | 该异常项尚未发起申诉 | +| 110 | 申诉中 | 该异常项已提交申诉，待审核 | + +### 5.4 上报状态（内部系统状态，非API枚举） + +| 状态 | 标签颜色 | 说明 | +|:---|:---|:---| +| 上传中 | 蓝色 | 数据正在上报中 | +| 已上传 | 绿色 | 上报成功 | +| 上传失败 | 红色 | 上报超时或错误，显示"手动上传"按钮 | +| 异常 | 橙色 | 数据校验不通过 | + +--- + +## 六、与原始需求的关键差异 + +| # | 项目 | 原始需求 | API/Showdoc（权威） | 影响 | +|:---:|:---|:---|:---|:---| +| 1 | 核验项数量 | 7类 | **17项** (API §4.1) | 测试覆盖需从14条扩展到34条 | +| 2 | 申诉状态 | 未申诉/申诉中/通过/驳回 | **未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130·省平台只读)** | 申诉状态枚举全部更新，130不纳入我方流转 | +| 3 | 申诉"进行中" | 独立状态"申诉中" | 归属于"未申诉(100)"，由abnormalDetails[].state=110标识 | 状态机变更 | +| 4 | 已取消状态 | 无 | **130=已取消·省平台操作·我方只读** | 不提供"取消申诉"按钮，仅查询展示 | +| 5 | 里程申诉 | 无 | **独立接口** `/mileageAppeal/insert` | 新增功能模块 | +| 6 | 发票合规查询 | 无 | **独立接口** `/verificationSummary/cargoOwnerInvoiceInfo` | 新增功能点 | +| 7 | 核验状态 | 通过/异常（二元） | 未核验(100)/通过(110)/全部异常(120) | 新增"未核验"初始状态 | +| 8 | 附件状态 | 无 | 未处理(100)/处理通过(110)/处理异常(120) | 新增枚举 | +| 9 | 委托合同上传 | 无 | Showdoc **mandateContractFrame** 接口 | 新增前置步骤：第一次上报前必须先上传框架合同 | +| 10 | ETC触发方式 | 税务抵扣完成（自动） | **人工手动确认抵扣完成后触发** | 需要运营人员在运八系统手动确认 | +| 11 | 金额精度 | 2位小数 | **第二次上报金额3位小数**（Showdoc） | 金额存储和校验精度变更 | +| 12 | 时间格式 | `yyyy-MM-dd HH:mm:ss` | **上报接口用 `yyyyMMddHHmmss`（14位）**（Showdoc） | 上报数据格式化逻辑变更 | +| 13 | ETC invoiceAmount | 总金额 | **不含税金额**（Showdoc） | ETC发票金额语义变更 | + +--- + +## 七、上报接口文档参考（Showdoc · 权威字段定义） + +### 7.0 Showdoc通用规范 + +| 项目 | 规范 | +|:---|:---| +| 认证方式 | MD5签名Token（请求体JSON字符串+密钥 → MD5加密），非JWT | +| 请求格式 | `{"partnerId":"xxx", "appId":"xxx", "workerId":"001", "args":{...}}` | +| 成功码 | `code=200` | +| 失败码 | `code=500` | +| 时间戳 | 13位毫秒时间戳 | + +> ⚠️ **关键差异**: Showdoc上报接口使用MD5签名Token，而查询+申诉API（PDF文档）使用JWT Token。两套认证体系独立。 + +### 7.1 字段精度关键差异（Showdoc vs 原始需求） + +以下是从Showdoc文档中发现的与原始需求/原型不一致的关键字段定义： + +| # | 字段相关 | 原始需求/原型假设 | Showdoc权威定义 | +|:---:|:---|:---|:---| +| 1 | **金额精度** | 保留2位小数 | **第二次上报金额保留3位小数**（arrivalInfo.waybillFreightAmount、totalMonetaryAmount、carrierStatements.monetaryAmount、ownerStatements.monetaryAmount、carrierContractInfo.contractAmount、contractedCarryingCapacity等均保留3位小数，如整数以.000填充） | +| 2 | **时间格式** | `yyyy-MM-dd HH:mm:ss` | **上报接口时间格式为 `yyyyMMddHHmmss`（14位）**（如documentCreateTime、orderReceivingTime、departureTime），日期字段用 `yyyyMMdd`（8位） | +| 3 | **第一次上报字段数** | consigneeInfo=5字段、driverInfo=13字段、carInfo=19字段 | Showdoc: consigneeInfo=6字段（含unLoadingNationSubdivisionCode）、driverInfo=15字段（含registerDate、anchoredUrl）、carInfo=20字段（含anchoredUrl）、goodsInfos.quantity=Double | +| 4 | **第二次上报结构** | 追加资金流水+轨迹 | Showdoc定义完全不同：arrivalInfo(含startTicketFileUrl+arrivalTicketFileUrl)+ownerStatements+carrierStatements+carrierContractInfo+ownerContractInfo(可选)+trackList；carrierStatements含oilCardAmount和replaceAgreementFiles | +| 5 | **第三次上报** | 发票17字段 | Showdoc: invoice明确17字段+invoiceUrl文件；oilGasInvoices选填 | +| 6 | **ETC发票** | invoiceAmount=发票总金额 | **invoiceAmount = 不含税金额**（not总金额!）；17个etcInvoices字段；税率格式x.x%（如3%） | +| 7 | **委托合同上传** | 未提及 | Showdoc有 `mandateContractFrame` 接口 — 之前完全遗漏！委托合同（框架）和委托合同二选一上报 | + +### 7.2 Showdoc FAQ 关键摘录 + +以下FAQ影响功能设计和测试用例设计： + +| 主题 | FAQ要点 | +|:---|:---| +| **运单不可取消/删除** | 服务平台不支持取消或删除运单，上传后不允许修改任何信息。建议企业在运单信息确认后再上传。 | +| **承运人流水核验时效** | 除承运人流水核验需等待次日银行提供数据后开始核验，其余核验项会在一至两小时内核验完成。 | +| **发票红冲流程** | 货主发票开具后需红冲：在服务平台企业端将货主发票作废，再将重新开具的发票通过第三次上传接口上传。 | +| **税率统一3%** | 承运人流水中的税率统一传3%，税额按3%计算。 | +| **油卡金额** | 在上传承运人流水时据实填写油卡金额（oilCardAmount），如一条运单存在多条承运人流水，可在任一承运人流水中填写。 | +| **委托合同（框架）上传时机** | 在进行运单第一次上报前需将框架合同通过接口上传至服务平台，后续合同有新增或修改再调用上传/修改接口。 | +| **轨迹点数** | 企业上传的轨迹点数需在2-2000之间。地址字段若无，传"-"。 | +| **核验结果查看** | 两种方式：①服务平台企业端查询；②对接服务平台异常查询接口实现在企业自有系统内查询、处理。 | +| **合规运单开票** | 运单必须上传至服务平台且核验通过后才允许开具货主发票；第二次上传完成后即可查看核验结果。 | + +--- + +## 八、待确认项（14项 → 已确认14项 ✅） + +> **更新 2026-07-14**: 以下14项已全部通过用户确认决议。方框标记为确认结果。 + +### 阻塞级（已确认） +1. ✅ **核验项展示**: API 17项核验全部展示，每项可独立申诉。analysis文档已明确。 +2. ✅ **上报接口字段定义**: Showdoc文档为权威数据源。Showdoc定义5个上报接口 + updateFirstUploadParam，与PDF的9个查询+申诉接口分离。 + +### 重要级（已确认） +3. ✅ **申诉状态"已取消(130)"**: 省平台侧操作，我方只读，不提供"取消申诉"按钮。运单不可取消/删除。 +4. ✅ **原型UI状态映射**: "待省平台反馈"和"反馈处理中"为UI层面的展示状态，对应API 未申诉(100)·申诉中。 +5. ✅ **第三次上报列表字段**: 以原型15列为准。 +6. ✅ **里程申诉与通用申诉**: 独立接口 `/mileageAppeal/insert`，与 `/appeal/insert` 分离。 +7. ✅ **发票合规查询**: 独立接口 `/cargoOwnerInvoiceInfo`，独立于申诉流程。 + +### 参考级（已确认） +8. ✅ **自动重试间隔**: 当前方案5s/15s/30s合理可用。 +9. ✅ **ETC税额**: 税率固定3%，税额按3%计算。 +10. ✅ **申诉超时告警**: 7个工作日阈值可用。 +11. ✅ **省份代码**: 安徽=34，与API文档一致。 +12. ✅ **第二次上报详情弹窗缺失轨迹**: 确认为原原型Bug，增强版原型已包含轨迹表格。 +13. ✅ **原型详情弹窗字段**: 以接口Showdoc定义为准。 +14. ✅ **ETC触发条件**: ETC发票税务抵扣成功后，由运营人员在运八系统**手动确认抵扣完成**，确认后系统触发ETC发票上传（非自动触发）。 diff --git a/resources/integration/showdoc文档.md b/resources/integration/showdoc文档.md new file mode 100644 index 0000000..d79e13d --- /dev/null +++ b/resources/integration/showdoc文档.md @@ -0,0 +1,1385 @@ +[token生成规则Demo.zip](https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=9be1ffcf6e3067f4379fca834f8b727e "[token生成规则Demo.zip") + +### 说明 + +[TOC] + +##### 简要描述 + +- 所有数据上传接口采用统一请求参数格式，方便鉴权。partnerId、appId、workerId以及密钥值由我司分配，具体的数据放在args参数中传递。 + +##### 请求URL +- ` http://xxx.com/api/xxx/xxx ` + +##### 请求方式 +- POST + +##### 请求头 +- token。 token值生成规则：请求体的json字符串值+密钥，以MD5算法加密。 + +##### 请求参数 + +| 参数名 | 必选 | 类型 | 说明 | +| :-------- | :--- | :------------------ | -------- | +| partnerId | 是 | String | 合作商ID | +| appId | 是 | String | 应用ID | +| workerId | 是 | String | 人员ID | +| args | 是 | Map | 请求参数 | + + +##### 请求示例 +```json +{ + "partnerId": "xxx", + "appId": "xxx", + "workerId": "001", + "args": { + "xxx1":"aaa", + "xxx2":["bbb","ccc"] + } +} +``` + + +##### 返回参数说明 + +| 参数 | 名称 | 类型 | 说明 | +| :-------- | :------- | ------- | ----------------------------------- | +| success | 成功标志 | boolean | 返回true或false | +| message | 返回信息 | String | 返回的提示信息 | +| code | 返回代码 | int | 如200：成功，500：服务器内部错误 等 | +| result | 返回数据 | Object | 如有需要，返回数据对象 | +| timestamp | 时间戳 | long | 13位时间戳，精确到毫秒 | + + + +##### 返回示例 + +``` + { + "success": false, + "message": "操作失败", + "code": 500, + "result": null, + "timestamp": 1672107371245 +} +``` + +[fea.xlsx](https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=58bdde057c2f77f9b7552cf197bc72db "[fea.xlsx") + +### 《监管平台代码集》 + +#代码集相关代码字段： + +业务类型代码 （BusinessTypeCode） +车牌颜色代码 （VehiclePlateColorCode） +营运车辆类型代码 （VehicleType） +车辆能源类型代码 （VehicleEnergyType） +货物分类代码（CargoTypeClassification） +付款方式代码（PaymentMeansCode） +银行代码（BankCode） +运输组织类型代码（TransportTypeCode） +保险机构代码（InsuranceInformation） +国别代码（CountrySubdivisionCode） +国家行政区划代码（CountrySubdivisionCod） +省份区划代码（ProvinceCode） +从业人员资格代码（WorkTypeCode） +道路运输证经营范围（BusinessScopeCode） +性别（Gender） +证照状态（CertificateState） +业户经营状态（OperatingStatus） +校验项内容（VerifyCode） +运输组货方式代码 +车牌类型代码（LicensePlateTypeCode） + +[TOC] + +### 上传委托合同（框架） + +##### 简要描述 + +上传委托合同（框架），委托合同（框架）和委托合同二选一进行上报；文件信息可以暂时不传，在修改委托合同的时候再补充合同文件。 + + +##### 请求URL +- ` xxxxxx/api/dataUpload/mandateContractFrame ` + +##### 请求方式 +- POST + + +##### args请求参数 + +| 参数名 | 必选 | 类型 | 说明 | +| :------------------------------- | :--- | :----------- | ------------------------------------------------------------ | +| unified_social_credit_identifier | 可选 | String | 货主企业统一社会信用代码，要么单托运企业，要么一个框架合同对应多家托运企业，如果都传值，默认取单托运企业 | +| owner_enterprise_name | 可选 | String | 货主企业名称 | +| enterpriseList | 可选 | List | 货主企业列表，要么单托运企业，要么一个框架合同对应多家托运企业，如果都传值，默认取单托运企业 | +| contract_number | 是 | String | 合同编号 | +| expire_time | 是 | String | 合同有效期截止时间 yyyy-MM-dd | +| uploadFileInfo | 否 | List | 文件信息 | + +###### enterpriseList子项参数 +| 参数名 | 必选 | 类型 | 说明 | +| -------------------------------- | ---- | ------ | ------------------------ | +| unified_social_credit_identifier | 是 | String | 货主企业统一社会信用代码 | +| owner_enterprise_name | 是 | String | 货主企业名称 | + +###### uploadFileInfo子项参数 +| 参数名 | 必选 | 类型 | 说明 | +| -------- | ---- | ------ | ------------------------------------------------------------ | +| name | 可选 | String | 文件名称和合同文件路径需一起上传/不上传，文件名称需要带后缀，和合同的url后面文件的后缀保持一致 | +| url | 可选 | String | 合同文件url,和dataList二选一填写 | +| dataList | 可选 | String | base64, 和url二选一填写 | + + +##### 请求示例 +```json +{ + "workerId": "001", + "appId": "default", + "partnerId": "test", + "args": { + "unified_social_credit_identifier": "123456", + "owner_enterprise_name": "szjttest", + "enterpriseList": [ + { + "unified_social_credit_identifier": "111111", + "owner_enterprise_name": "关联企业一" + }, + { + "unified_social_credit_identifier": "222222", + "owner_enterprise_name": "关联企业二" + } + ], + "contract_number": "666666", + "expire_time": "2022-12-14", + "uploadFileInfo": [ + { + "name": "合肥税务监管平台V1.0 结项表.pdf", + "url": "https://file.rlsk.link/file/合肥税务监管平台V1.0 结项表_1653982927764.pdf", + "dataList": "" + }, + { + "name": "合肥税务监管平台V1.0 结项表.pdf", + "url": "https://file.rlsk.link/file/合肥税务监管平台V1.0 结项表_1653982927764.pdf", + "dataList": "" + } + ] + } +} +``` + + +##### 返回参数说明 + +| 参数 | 名称 | 类型 | 说明 | +| :-------- | :------- | ------- | ----------------------------------- | +| success | 成功标志 | boolean | 返回true或false | +| message | 返回信息 | String | 返回的提示信息 | +| code | 返回代码 | int | 如200：成功，500：服务器内部错误 等 | +| result | 返回数据 | Object | 如有需要，返回数据对象 | +| timestamp | 时间戳 | long | 13位时间戳，精确到毫秒 | + + + +##### 返回示例 + +``` +{ + "success": true, + "message": "", + "code": 200, + "result": true, + "timestamp": 1672121404682 +} +``` + +[TOC] + +### 一、第一次上传 + +#### 简要描述 + +- 第一次上传完后，会进行实时单核验 + +#### 请求URL +- ` xxxxxx/api/dataUpload/firstUpload ` + +#### 请求方式 +- POST + + +#### 请求参数 + +| 参数名 | 必选 | 类型 | 说明 | +| :------------------- | :--- | :----------- | ------------ | +| waybillInfo | 是 | Obejct | 建单信息 | +| consignorInfo | 是 | Object | 托运人信息 | +| consigneeInfo | 是 | Object | 收货方信息 | +| driverInfo | 是 | Object | 司机信息 | +| carInfo | 是 | Object | 接单车辆信息 | +| insuranceInformation | 否 | Object | 保险信息 | +| goodsInfos | 是 | List | 货物信息 | + +##### waybillInfo子项参数 + +| 参数名 | 必选 | 类型 | 说明 | +| ----------------------------- | ---- | ------ | ------------------------------------------------------------ | +| originalDocumentNumber | 是 | String | 上游企业委托运输单号(最大长度35位) | +| shippingNoteNumber | 是 | String | 本运单单号(最大长度20位) | +| documentCreateTime | 是 | String | 托运人建单时间(14位)。yyyyMMddHHmmss（example:20220530143259） | +| carrier | 是 | String | 网络货运经营者名称 | +| unifiedSocialCreditIdentifier | 是 | String | 网络货运经营者统一社会信用代码(最大长度18位) | +| permitNumber | 是 | String | 网络货运经营者的道路运输经营许可证编号，最大长度50位，网络货运经营者整合车辆全部为总质量4.5吨及以下普通货运车辆的，可填“企业所在地行政区划代码+000000” | +| businessTypeCode | 是 | String | 详见代码集《业务类型代码》 | +| goodsArrangementTypeCode | 是 | String | 详见代码集《运输组货方式代码》 | +| orderReceivingTime | 是 | String | 司机接单的时间(14位)。yyyyMMddHHmmss（example:20220530143259） | +| departureTime | 是 | String | 司机起运的时间(14位)。yyyyMMddHHmmss（example:20220530143259) | +| commercialContractNumber | 是 | String | 承运合同编号,平台与司机签订的合同编号 | +| contractNumber | 可选 | String | 委托合同编号,托运人与平台签订的合同编号 | +| mileage | 可选 | String | 运输里程，可保留3位小数 | + + +##### consignorInfo子项参数 + +| 参数名 | 必选 | 类型 | 说明 | +| ----------------------------- | ---- | ------ | ------------------------------------------------------------ | +| consignor | 是 | String | 托运人名称，需和货主框架合同信息保持一致 | +| consignorId | 是 | String | 托运人统一社会信用代码，需和货主框架合同信息保持一致 | +| frameContractNumber | 可选 | String | 需和委托合同（框架）信息保持一致,最大长度30位，委托合同（框架）和委托合同二选一上报 | +| placeOfLoading | 是 | String | 实际装货的地点 格式为省/市/县(区)/详细地址 | +| loadingLongitude | 是 | String | 实际装货的地点经度，最长保留6位小数 | +| loadingLatitude | 是 | String | 实际装货的地点纬度，最长保留6位小数 | +| loadingCountrySubdivisionCode | 是 | String | 参照最新版《中华人民共和国行政区划代码》（GB/T 2260-2017），精确到区县。详见代码集《国家行政区划代码》 | + +##### consigneeInfo子项参数 + +| 参数名 | 必选 | 类型 | 说明 | +| ------------------------------ | ---- | ------ | ------------------------------------------------------------ | +| consignee | 是 | String | 收货方名称 | +| consigneeId | 是 | String | 收货方统一社会信用代码，若收款方为个人，则为身份证号 | +| goodsReceiptPlace | 是 | String | 实际收货的地点 格式为省/市/县(区)/详细地址 | +| unLoadingLongitude | 是 | String | 实际收货的地点经度，最长保留6位小数 | +| unLoadingLatitude | 是 | String | 实际收货的地点纬度，最长保留6位小数 | +| unLoadingNationSubdivisionCode | 是 | String | 参照最新版《中华人民共和国行政区划代码》（GB/T 2260-2017），精确到区县。详见代码集《国家行政区划代码》 | + +##### driverInfo子项参数 + +| 参数 | 名称 | 必选 | 类型 | 说明 | +| ---------------------------- | -------------------------- | ---- | ------------ | ------------------------------------------------------------ | +| driverName | 姓名 | 是 | String | 根据机动车驾驶证填写 | +| telephone | 手机号码 | 是 | String | | +| drivingIdNumber | 身份证号 | 是 | String | 身份证号 | +| drivingLicense | 驾驶证编号 | 是 | String | 根据机动车驾驶证填写 | +| vehicleClass | 准驾车型 | 是 | String | 根据机动车驾驶证填写 | +| issuingOrganizations | 驾驶证发证机关 | 是 | String | 根据机动车驾驶证填写 | +| validPeriodFrom | 驾驶证有效期自 | 是 | String | 根据机动车驾驶证填写。yyyyMMdd | +| validPeriodTo | 驾驶证有效期至 | 是 | String | 根据机动车驾驶证填写。yyyyMMdd | +| qualificationCertificate | 从业资格证号 | 是 | String | 驾驶员身份证号可代替进行上传，最大长度19位字符，使用总质量4.5吨及以下普通货运车辆从事普通货物运输经营的驾驶员，填写“驾驶员身份证前6位+000000” | +| provinceCode | 从业资格的国家行政区划代码 | 是 | String | “详见代码集《国家行政区划代码》从业资格证上的省份填写相应代码” | +| qualificationCertificateFrom | 从业资格证有效期自 | 否 | String | 从业资格证有效期自，根据从业资格证填写，yyyyMMdd。为空时需要传null | +| qualificationCertificateTo | 从业资格证有效期至 | 否 | String | 从业资格证有效期至，根据从业资格证填写，yyyyMMdd。为空时需要传null | +| taxRegistrationCertificate | 司机税务登记证号 | 可选 | String | | +| registerDate | 驾驶员注册日期 | 是 | String | 驾驶员在网络货运企业注册成为会员的日期。yyyyMMdd | +| anchoredUrl | 司机挂靠协议 | 否 | List | | + +##### carInfo子项参数 + +| 参数 | 名称 | 必选 | 类型 | 说明 | +| ------------------------------ | ---------------------------------- | ---- | ------------ | ------------------------------------------------------------ | +| vehicleNumber | 车辆牌照号 | 是 | String | | +| vehiclePlateColorCode | 车牌颜色代码 | 是 | String | 详见代码集《车牌颜色代码》 | +| vehicleType | 车辆类型代码 | 是 | String | 详见代码集《车辆类型代码》 | +| LicensePlateTypeCode | 车牌类型代码(注意首字母大写) | 是 | String | 详见代码集《车牌类型代码》 | +| owner | 所有人 | 是 | String | 按照机动车行驶证填写 | +| ownerId | 所有人统一社会信用代码或个人证件号 | 可选 | String | | +| useCharacter | 使用性质 | 是 | String | 按照机动车行驶证填写 | +| vin | 车辆识别代号 | 是 | String | 按照机动车行驶证填写 | +| issuingOrganizations | 发证机关 | 是 | String | 按照机动车行驶证填写 | +| registerDate | 注册日期 | 是 | String | 按照机动车行驶证填写。yyyyMMdd | +| issueDate | 发证日期 | 是 | String | 按照机动车行驶证填写。yyyyMMdd | +| vehicleEnergyType | 车辆能源类型 | 是 | String | 详见代码集《车辆能源类型》 | +| vehicleTonnage | 核定载质量 | 是 | Double | 参考机动车行驶证填写，默认单位：吨，保留两位小数，如整数的话，以.00填充 | +| grossMass | 总质量 | 是 | Double | 参考机动车行驶证填写，默认单位：吨，保留两位小数，如整数的话，以.00填充 | +| roadTransportCertificateNumber | 道路运输证号 | 是 | String | 可用0进行填充，最大长度20位字符(字母数字混填)，总质量4.5吨及以下普通货运车辆的，可填“车籍地6位行政区域代码+000000” | +| trailerVehiclePlateNumber | 挂车牌照号 | 否 | String | | +| vehicleLicenseNumber | 行驶证档案编号 | 否 | String | 可用0进行填充，长度为12-18位字符 | +| roadTransportSocialCreditFrom | 道路运输证有效期自 | 否 | String | 道路运输证有效期自，按照道路运输证填写。yyyyMMdd | +| roadTransportSocialCreditTo | 道路运输证有效期至 | 否 | String | 道路运输证有效期至，按照道路运输证填写。yyyyMMdd | +| anchoredUrl | 车辆挂靠协议 | 否 | List | | + + +##### goodsInfos子项参数 + +| 参数名 | 必选 | 类型 | 说明 | +| --------------------------- | ---- | ------ | ------------------------------------------------------------ | +| descriptionOfGoods | 是 | String | 货物名称，如一车货有不同货物，则可循环 | +| cargoTypeClassificationCode | 是 | String | 详见代码集《货物类型代码》 | +| quantity | 是 | Double | 货物量，重量/体积/件数/车数等，数值,计量单位用从unit字段传入 | +| unit | 是 | String | 计量单位,格式为:吨/件/车/立方米等 | + +##### insuranceInformation子项参数 + +| 参数名 | 必选 | 类型 | 说明 | +| ---------------- | ---- | ------ | ------------------------------------------------------------ | +| policyNumber | 是 | String | 保险单号，未投保的，可填none，最大长度50位字符 | +| insuranceCompany | 是 | String | 保险公司名称，详见代码集《保险机构代码》。未投保的，可填“无” | + +###### contractUrl子项参数 + +| 参数 | 名称 | 必选 | 类型 | 说明 | +| -------- | ---------------- | ---- | ------ | -------------------------------------------------------- | +| name | 委托合同文件名称 | 否 | String | 需要加文件格式后缀名png/jpg/jpeg/pdf，例如：合同文件.png | +| url | 委托合同文件地址 | 可选 | String | url和dataList任选一项必填 | +| dataList | 委托合同文件对象 | 可选 | String | base64, url和dataList任选一项必填 | + + + + +#### 请求示例 +```json +{ + "partnerId": "xxx", + "appId": "xxx", + "workerId": "001", + "args": { + "waybillInfo":{ + "businessTypeCode":"1002996", + "carrier":"网络货运企业名称", + "documentCreateTime":"20460228000000", + "goodsArrangementTypeCode":"011", + "originalDocumentNumber":"ys2222", + "permitNumber":"123456789012", + "shippingNoteNumber":"test008", + "departureTime": "20900203010233", + "orderReceivingTime":"20220530143259", + "contractNumber":"cb123456789", + "commercialContractNumber":"ss123456789", + "unifiedSocialCreditIdentifier":"1111", + "mileage": "200.234" + }, + "insuranceInformation":{ + "insuranceCompany":"ABIC", + "policyNumber":"123456" + }, + "consignorInfo":{ + "consignor":"托运人的名字", + "consignorId":"422801199903260045", + "frameContractNumber":"", + "loadingCountrySubdivisionCode":"370211", + "placeOfLoading":"山东省/青岛市/黄岛区", + "loadingLongitude":"107.298671", + "loadingLatitude":"40.796694" + }, + "consigneeInfo":{ + "consignee":"我是收货方名称", + "consigneeId":"422801199903260088", + "goodsReceiptPlace":"河北省/邯郸市/永年区", + "unLoadingLongitude":"107.298671", + "unLoadingLatitude":"40.796694", + "unLoadingNationSubdivisionCode":"370200" + }, + "carInfo":{ + "grossMass":33, + "issueDate":"20211212", + "issuingOrganizations":"我的发证机关", + "LicensePlateTypeCode":"01", + "owner":"刘司机的车", + "ownerId":"123456789", + "registerDate":"20231212", + "roadTransportCertificateNumber":"123456789012", + "roadTransportSocialCreditFrom":"20211213", + "roadTransportSocialCreditTo":"20221212", + "trailerVehiclePlateNumber":"鄂A12345", + "useCharacter":"商用", + "vehicleEnergyType":"A", + "vehicleLicenseNumber":"111111111111111111", + "vehicleNumber":"赣GP3217", + "vehiclePlateColorCode":"2", + "vehicleTonnage":33, + "vehicleType":"H10", + "vin":"12423515", + "anchoredUrl":[ + { + "name":"车辆挂靠协议.pdf", + "url":"https://www.123.com", + "dataList":"文件" + } + ] + }, + "driverInfo":{ + "driverName":"测试司机", + "drivingIdNumber":"110101199003074530", + "drivingLicense":"12111561651561", + "issuingOrganizations":"我就是驾驶证发证机关", + "qualificationCertificate":"111", + "qualificationCertificateFrom":"20241212", + "qualificationCertificateTo":"20251212", + "taxRegistrationCertificate":"123455", + "telephone":"18871999035", + "validPeriodFrom":"20261212", + "validPeriodTo":"20271212", + "vehicleClass":"准驾车型", + "provinceCode":"123456", + "anchoredUrl":[ + { + "name":"司机挂靠协议.pdf", + "url":"https://www.123.com", + "dataList":"文件" + } + ] + }, + "goodsInfos":[ + { + "cargoTypeClassificationCode":"100", + "descriptionOfGoods":"手机", + "quantity":"100", + "unit":"吨" + }, + { + "cargoTypeClassificationCode":"100", + "descriptionOfGoods":"手机", + "quantity":"100", + "unit":"吨" + } + ] + } +} +``` + + +#### 返回参数说明 + +| 参数 | 名称 | 类型 | 说明 | +| :-------- | :------- | ------- | ----------------------------------- | +| success | 成功标志 | boolean | 返回true或false | +| message | 返回信息 | String | 返回的提示信息 | +| code | 返回代码 | int | 如200：成功，500：服务器内部错误 等 | +| result | 返回数据 | Object | 如有需要，返回数据对象 | +| timestamp | 时间戳 | long | 13位时间戳，精确到毫秒 | + + + +#### 返回示例 + +``` +{ + "success": true, + "message": "", + "code": 200, + "result": true, + "timestamp": 1672121404682 +} +``` + +### 二、第二次上传 + +[TOC] + +#### 简要描述 + +- 第二次上传完后，会进行运单重复、车辆资质、司机资质、集中支付、资金流水、合同、车辆轨迹核验 + +#### 请求URL +- `xxxxxx/api/dataUpload/secondUpload ` + +#### 请求方式 +- POST + + +#### args请求参数 + +| 参数 | 名称 | 必选 | 类型 | 说明 | +| :------------------ | ------------------ | :--- | :----------- | ------------------------------------ | +| arrivalInfo | 运抵信息 | 是 | Object | | +| ownerStatements | 货主流水 | 是 | List | | +| carrierStatements | 承运人流水 | 是 | List | | +| carrierContractInfo | 承运合同（承运人） | 是 | Object | 承运合同（承运人） | +| ownerContractInfo | 委托合同（货主） | 可选 | Object | 委托合同（框架）和委托合同二选一上报 | +| trackList | 车辆轨迹 | 是 | List | | + + +##### arrivalInfo子项参数 +| 参数 | 名称 | 必选 | 类型 | 说明 | +| :------------------- | ---------------------------- | :--- | :----------- | ------------------------------------------------------------ | +| shippingNoteNumber | 托运单号 | 是 | String | 本运单单号(最大长度20位) | +| startTicketFileUrl | 起运磅票文件（发货单） | 是 | List | 支持上传多个文件 | +| arrivalTime | 运抵时间 | 是 | String | 司机运抵的时间。yyyyMMddHHmmss | +| arrivalTicketFileUrl | 运抵磅票文件（收货单） | 是 | List | 支持上传多个文件 | +| waybillFreightAmount | 承运运费金额（不含运费差价） | 是 | Double | 此运单网络货运经营者实际支付承运人的运费金额，即网络货运经营者与承运人签订的该运单的司机运单合同付款金额，货币单位为人民币（元），保留3位小数，如整数的话，以.000填充。 | +| totalMonetaryAmount | 委托运费金额（含运费差价） | 是 | Double | 此运单托运人实际支付网络货运经营者的运费金额，即托运人与网络货运经营者签订的该运单的货主运单合同付款金额，货币单位为人民币（元），保留3位小数，如整数的话，以.000填充。 | + +###### startTicketFileUrl子项参数 +| 参数 | 名称 | 必选 | 类型 | 说明 | +| -------- | ---------------- | ---- | ------ | ------------------------------------------------------- | +| name | 起运磅票文件名称 | 是 | String | 需要加文件格式后缀名png/jpg/jpeg/pdf,例如：合同文件.png | +| url | 起运磅票文件地址 | 可选 | String | url和dataList任选一项必填 | +| dataList | 起运磅票文件对象 | 可选 | String | base64, url和dataList任选一项必填 | + +###### arrivalTicketFileUrl子项参数 + +| 参数名 | 必选 | 类型 | 说明 | +| :------- | :--- | :----- | ------------------------------------------------------------ | +| name | 是 | String | 运抵磅票文件名称,需要加文件格式后缀名png/jpg/jpeg/pdf,例如：合同文件.png | +| url | 可选 | String | 运抵磅票文件地址 | +| dataList | 可选 | String | base64, 运抵磅票文件对象 | + + +##### carrierStatements子项参数 + +|参数名|名称|必选|类型|说明| +|:---- |:---|:----- |----- | +|documentNumber |单证号|是 |String |本资金流水单号。（是指网络货运平台内部的流水号） | +|carrier |实际承运人名称|是 |String |个人车主信息/司机信息 | +|actualCarrierId |实际承运人身份证号码|是 |String |个人证件号为身份证号 | +|paymentMeansCode |付款方式代码|是 |String |详见代码集《付款方式代码》 | +|paymentName |付款方名称|是 |String |平台名称 | +|paymentAccount |付款帐户信息|是 |String |银行卡号 | +|paymentBankName |付款银行|是 |String |付款银行，精确到支行，银行名称需规范，如“中国建设银行某某支行”、“中信银行某某支行”、“支付宝”等等 | +|recipient |收款方名称|是 |String |实际收款人 | +|receiptIdCard |收款方身份证号|是 |String |身份证号 | +|receiptAccount |收款帐户信息|是 |String |银行卡号 | +|receiptBankName |收款银行|是 |String |收款银行名称 | +|sequenceCode |流水号/序列号|是 |String |付款银行流水号信息，银行或第三方支付平台的资金流水单号 | +|monetaryAmount |实际支付金额|是 |String |资金流水金额，货币单位为人民币，保留3位小数，如整数的话，以.000填充 | +|appointmentTime |合同约定时间|是 |String |合同约定时间，yyyyMMdd | +|payTime |实际支付时间|是 |String |资金流水实际发生时间。yyyyMMddHHmmss | +|oilCardAmount |油卡金额|选填 |String |油卡金额，货币单位为人民币，保留3位小数，如整数的话，以.000填充。 | +|replaceAgreementFiles |代收协议| 可选 |List |不是司机本人/车辆所有人收款，需要传代收协议 | + +##### ownerStatements子项参数 + +| 参数 | 名称 | 必选 | 类型 | 说明 | +| :--------------- | ---------------------------------- | :--- | :----- | ------------------------------------------------------------ | +| documentNumber | 单证号 | 是 | String | 本资金流水单号（是指网络货运平台内部的流水号）。 | +| carrier | 托运人名称 | 是 | String | 货主企业名称 | +| actualCarrierId | 托运人统一社会信用代码或个人证件号 | 是 | String | 个人证件号为身份证号 | +| paymentMeansCode | 付款方式代码 | 是 | String | 详见代码集《付款方式代码》 | +| paymentName | 付款方名称 | 是 | String | 托运人名称 | +| paymentAccount | 付款帐户信息 | 是 | String | 银行卡号 | +| paymentBankName | 付款银行 | 选填 | String | 付款银行 | +| recipient | 收款方名称 | 是 | String | 网络货运企业 | +| receiptAccount | 收款帐户信息 | 是 | String | 银行卡号 | +| receiptBankName | 收款银行 | 选填 | String | 收款银行 | +| sequenceCode | 付款流水号/序列号 | 是 | String | 银行或第三方支付平台的资金流水单号 | +| monetaryAmount | 实际支付金额 | 是 | Double | 资金流水金额，货币单位为人民币，保留3位小数，如整数的话，以.000填充 | +| appointmentTime | 合同约定付款时间 | 是 | String | yyyyMMdd | +| payTime | 实际支付时间 | 是 | String | 资金流水实际发生时间。yyyyMMddHHmmss | + + + +##### carrierContractInfo子项参数 +| 参数 | 名称 | 必选 | 类型 | 说明 | +| ---------------------------- | -------------------------------- | ---- | ------------ | ------------------------------------------------------------ | +| contractBusinessName | 合同业务名称 | 是 | String | | +| contractNumber | 承运合同编号 | 是 | String | 平台与司机签订的合同编号 | +| partyAName | 甲方名称 | 是 | String | 付款方（网络货运企业） | +| partyAId | 甲方统一社会信用代码 | 是 | String | 网络货运经营者统一社会信用代码 | +| partyBName | 乙方名称 | 是 | String | 实际承运人 | +| partyBId | 乙方统一社会信用代码或个人证件号 | 是 | String | 个人证件号为身份证号 | +| contractedCarryingCapacity | 合同签订承运量 | 是 | Double | 重量单位以吨填写数值，保留3位小数，如整数的话，以.000填充。如是轻泡货等货物，请估算重量。 | +| unit | 合同签订承运量单位 | 是 | String | 格式:吨/件/车/立方米 | +| contractAmount | 合同金额 | 是 | Double | 货币单位为人民币（元），保留3位小数，如整数的话，以.000填充。 | +| agreedBusinessCompletionTime | 约定业务完成时间 | 是 | String | yyyyMMdd | +| promisePayTime | 约定甲方付款时间 | 是 | String | yyyyMMdd | +| partyBReceiptName | 乙方收款方名称 | 是 | String | 实际承运人 | +| partyBAccount | 乙方收款账号 | 是 | String | 银行卡号 | +| bankName | 乙方收款银行 | 否 | String | 乙方收款银行 | +| placeOfLoading | 装货地址 | 是 | String | 装货地址，格式为省/市/县(区)/详细地址 | +| goodsReceiptPlace | 卸货地址 | 是 | String | 卸货地址，格式为省/市/县(区)/详细地址 | +| descriptionOfGoods | 货物名称 | 是 | String | 货物名称 | +| vehicleNumber | 车牌号 | 是 | String | 车牌号 | +| contractSigningTime | 合同签订时间 | 是 | String | 司机与平台签订合同时间，yyyyMMddHHmmss | +| contractUrl | 承运合同文件 | 是 | List | | +###### contractUrl子项参数 +| 参数 | 名称 | 必选 | 类型 | 说明 | +| -------- | ---------------- | ---- | ------ | ------------------------------------------------------- | +| name | 承运合同文件名称 | 是 | String | 需要加文件格式后缀名png/jpg/jpeg/pdf,例如：合同文件.pdf | +| url | 承运合同文件地址 | 可选 | String | url和dataList任选一项必填 | +| dataList | 承运合同文件对象 | 可选 | String | base64, url和dataList任选一项必填 | + +##### ownerContractInfo子项参数 +| 参数 | 名称 | 必选 | 类型 | 说明 | +| ---------------------------- | -------------------------------- | ---- | ------------ | ------------------------------------------------------------ | +| contractBusinessName | 合同业务名称 | 否 | String | | +| contractNumber | 委托合同编号 | 否 | String | 平台与托运人签订的合同编号 | +| partyAName | 甲方名称 | 否 | String | 付款方（托运人） | +| partyAID | 甲方统一社会信用代码或个人证件号 | 否 | String | 个人证件号为身份证号 | +| partyBName | 乙方名称 | 否 | String | 收款方（网络货运企业） | +| partyBID | 乙方统一社会信用代码 | 否 | String | 网络货运经营者统一社会信用代码 | +| contractedCarryingCapacity | 合同签订承运量 | 是 | Double | 重量单位以吨填写数值，保留3位小数，如整数的话，以.000填充。如是轻泡货等货物，请估算重量。 | +| unit | 合同签订承运量单位 | 是 | String | 格式:吨/件/车/立方米 | +| contractAmount | 合同金额 | 是 | Double | 货币单位为人民币（元），保留3位小数，如整数的话，以.000填充。 | +| agreedBusinessCompletionTime | 约定业务完成时间 | 否 | String | yyyyMMdd | +| promisePayTime | 约定资金结算时间 | 否 | String | yyyyMMdd | +| partyAAccount | 甲方付款账号 | 否 | String | 银行卡号 | +| partyABankName | 甲方付款银行 | 否 | String | 甲方付款银行 | +| partyBAccount | 乙方收款账号 | 否 | String | 银行卡号 | +| partyBBankName | 乙方收款银行 | 否 | String | 乙方收款银行 | +| contractSigningTime | 合同签订时间 | 否 | String | 货主与平台签订合同时间,yyyyMMddHHmmss | +| contractUrl | 委托合同文件 | 否 | List | | +###### contractUrl子项参数 +| 参数 | 名称 | 必选 | 类型 | 说明 | +| -------- | ---------------- | ---- | ------ | ------------------------------------------------------- | +| name | 委托合同文件名称 | 否 | String | 需要加文件格式后缀名png/jpg/jpeg/pdf,例如：合同文件.pdf | +| url | 委托合同文件地址 | 可选 | String | url和dataList任选一项必填 | +| dataList | 委托合同文件对象 | 可选 | String | base64, url和dataList任选一项必填 | + + +##### trackList子项参数 (当前轨迹上报点数限制为2-2000个) + +| 参数 | 名称 | 必选 | 类型 | 说明 | +| :-------------- | -------- | :--- | :----- | ------------------------------------------------------------ | +| locationMethod | 定位类型 | 是 | String | 详见代码集《定位类型》【BD(北斗);LBS(LBS);WECHAT(小程序);APP(APP)】 | +| locationTime | 定位时间 | 是 | String | yyyyMMddHHmmss | +| locationAddress | 定位地点 | 是 | String | 具体定位地址 | +| longitude | 经度 | 是 | String | 定位经度，最长保留6位小数 | +| latitude | 纬度 | 是 | String | 定位纬度，最长保留6位小数 | +| trackType | 轨迹类型 | 否 | String | 轨迹类型，LOADING-提货 UNLOADING-运抵 NORMAL-其他定位 | + +#### 请求示例 +```json +{ + "partnerId": "xxx", + "appId": "xxx", + "workerId": "001", + "args": { + "arrivalInfo":{ + "startTicketFileUrl":[ + { + "name":"图片.jpg", + "url":"https://wwww.xx.xx", + "dataList":"文件对象" + }, + { + "name":"图片.jpg", + "url":"https://wwww.xx.xx", + "dataList":"文件对象" + } + ], + "arrivalTicketFileUrl":[ + { + "name":"图片.jpg", + "url":"https://wwww.xx.xx", + "dataList":"文件对象" + }, + { + "name":"图片.jpg", + "url":"https://wwww.xx.xx", + "dataList":"文件对象" + } + ], + "arrivalTime":"20220307094830", + "shippingNoteNumber":"test008", + "totalMonetaryAmount":11, + "waybillFreightAmount":10 + }, + "carrierContractInfo":{ + "agreedBusinessCompletionTime":"20201212", + "contractNumber":"ss123456789", + "contractAmount":12, + "contractBusinessName":"我就是商事合同业务名称", + "contractSigningTime":"20211212000000", + "contractUrl":[ + { + "name":"图片.jpg", + "url":"https://wwww.xx.xx", + "dataList":"文件对象" + }, + { + "name":"图片.jpg", + "url":"https://wwww.xx.xx", + "dataList":"文件对象" + } + ], + "contractedCarryingCapacity":3, + "unit":"吨", + "partyAId":"422801199903260024", + "partyAName":"甲方名称付款方（网络货运企业）", + "partyBAccount":"12345678901", + "partyBId":"422801199903260024", + "partyBName":"乙方名称实际承运人", + "partyBReceiptName":"乙方收款方名称实际承运人-吴司机", + "promisePayTime":"20201212", + "bankName":"中国银行", + "placeOfLoading":"装货地址", + "goodsReceiptPlace":"收货地址", + "descriptionOfGoods":"货物名称", + "vehicleNumber":"车牌号" + }, + "ownerContractInfo":{ + "agreedBusinessCompletionTime":"20201212", + "contractNumber":"cb123456789", + "contractAmount":6, + "contractBusinessName":"我是承包合同业务名称", + "contractUrl":[ + { + "name":"图片.jpg", + "url":"https://wwww.xx.xx", + "dataList":"文件对象" + }, + { + "name":"图片.jpg", + "url":"https://wwww.xx.xx", + "dataList":"文件对象" + } + ], + "contractedCarryingCapacity":7, + "unit":"吨", + "partyAAccount":"12345678901", + "partyABankName":"中国银行", + "partyAID":"422801199903260024", + "partyAName":"甲方名称付款方托运人", + "partyBAccount":"12345678901", + "partyBID":"422801199903260024", + "partyBName":"乙方名称收款方（网络货运企业）", + "partyBBankName":"中国银行", + "promisePayTime":"20201212", + "serviceCharge":"6%" + }, + "ownerStatements":[ + { + "receiptAccount":"12345678901", + "receiptBankName":"中国银行", + "recipient":"收款方名称网络货运企业", + "actualCarrierId":"422801199903260024", + "appointmentTime":"20211212", + "carrier":"托运人名称", + "documentNumber":"dzh123456", + "monetaryAmount":1, + "payTime":"20211212000000", + "paymentAccount":"12345678901", + "paymentBankName":"中国银行", + "paymentMeansCode":"1", + "paymentName":"付款方名称托运人名称", + "sequenceCode":"lsh123456" + }, + { + "receiptAccount":"12345678901", + "receiptBankName":"中国银行", + "recipient":"收款方名称网络货运企业", + "actualCarrierId":"422801199903260024", + "appointmentTime":"20211212", + "carrier":"托运人名称", + "documentNumber":"dzh123456", + "monetaryAmount":1, + "payTime":"20211212000000", + "paymentAccount":"12345678901", + "paymentBankName":"中国银行", + "paymentMeansCode":"1", + "paymentName":"付款方名称托运人名称", + "sequenceCode":"lsh123456" + } + ], + "carrierStatements":[ + { + "actualCarrierId":"422801199903260024", + "appointmentTime":"20211212", + "carrier":"流司机", + "documentNumber":"dzh123456", + "monetaryAmount":10000, + "payTime":"20211212000000", + "paymentAccount":"12345678901", + "paymentMeansCode":"1", + "paymentName":"付款方名称", + "paymentBankName":"中国银行", + "receiptAccount":"12345678901", + "receiptIdCard":"422801199903260025", + "recipient":"汪司机", + "receiptBankName":"中国银行", + "sequenceCode":"lsh12346", + "oilCardAmount":"1000.000", + "replaceAgreementFiles":[ + { + "name":"图片.jpg", + "url":"https://wwww.xx.xx", + "dataList":"文件对象" + }, + { + "name":"图片.jpg", + "url":"https://wwww.xx.xx", + "dataList":"文件对象" + } + ], + }, + { + "actualCarrierId":"422801199903260024", + "appointmentTime":"20211212", + "carrier":"流司机", + "documentNumber":"dzh123456", + "monetaryAmount":10000, + "payTime":"20211212000000", + "paymentAccount":"12345678901", + "paymentMeansCode":"1", + "paymentName":"付款方名称", + "paymentBankName":"中国银行", + "receiptAccount":"12345678901", + "receiptIdCard":"422801199903260025", + "recipient":"汪司机", + "receiptBankName":"中国银行", + "sequenceCode":"lsh12346", + "oilCardAmount":"1000.000", + "unitPriceIncludingTax":"12.000", + "unitPriceIncludingAmount":"123.120" + } + ], + "trackList":[ + { + "locationMethod":"BD", + "locationTime":"20220305143621", + "locationAddress":"山东省青岛市黄岛区", + "longitude":"107.298671", + "latitude":"40.796694", + "trackType": "LOADING" + }, + { + "locationMethod":"WECHAT", + "locationTime":"20220305143621", + "locationAddress":"河北省邯郸市永年区", + "longitude":"107.298671", + "latitude":"40.796694", + "trackType": "UNLOADING" + } + ] + } +} +``` + + +##### 返回参数说明 + +| 参数 | 名称 | 类型 | 说明 | +| :-------- | :------- | ------- | ----------------------------------- | +| success | 成功标志 | boolean | 返回true或false | +| message | 返回信息 | String | 返回的提示信息 | +| code | 返回代码 | int | 如200：成功，500：服务器内部错误 等 | +| result | 返回数据 | Object | 如有需要，返回数据对象 | +| timestamp | 时间戳 | long | 13位时间戳，精确到毫秒 | + + + +##### 返回示例 + +``` +{ + "success": true, + "message": "", + "code": 200, + "result": true, + "timestamp": 1672121404682 +} +``` + +### 三、第三次上传 + +[TOC] + +##### 简要描述 + +- 第三次上传完后，会进行税票核验。 + +##### 请求URL +- ` xxxxxx/api/dataUpload/thirdUpload ` + +##### 请求方式 +- POST + + +##### 请求参数 + +|参数名|名称|必选|类型|说明| +|:---- |:---|:----- |----- | +|invoice |货主发票 |是 |Object |支持一张发票包含多个运单 | +|oilGasInvoices |油气发票 |选填 |List |发票关联的运单油气发票 | + +##### invoice子项参数 + +|参数名|名称|必选|类型|说明| +|:---- |:---|:----- |----- | +|shippingNoteNumberList |托运单号 数组 |是 |List |运单单号数组 | +|invoiceNumber |发票号码 |是 |String | 发票号码 | +|invoiceCode |发票代码号 | 是 |String | 发票代码号(备注：数电票可传发票号码) | +|invoiceAmount |发票金额 | 是 |Number | 发票金额(价税合计)，货币单位为人民币（元），保留2位小数，如整数的话，以.00填充。 | +|invoiceDateTime |开票日期 | 是 |String | 开票时间，yyyyMMdd | +|sellerName |销售方名称 | 是 |String | 开票方公司名称 | +|sellerTaxpayerIdentification |销售方纳税人识别号 | 是 |String | 开票方纳税人识别号（网络货运经营者统一社会信用代码） | +|sellerAddress |销售方地址 | 是 |String | 开票方营业执照公司地址，需保持一致 | +|sellerTelephone |销售方电话 | 是 |String | 开票方公司联系电话，手机号或座机 | +|sellerBankName |销售方银行 | 是 |String | 开票方开户行 | +|sellerBankAccount |销售方银行账号 | 是 |String | 开票方银行账户 | +|buyerName |受票方名称 | 是 |String | 受票方名称 | +|buyerTaxpayerIdentification |受票方纳税人识别号 | 是 |String | 受票方纳税人识别号 | +|buyerAddress |受票方地址 | 是 |String | 受票方营业执照公司地址，需保持一致 | +|buyerTelephone |受票方电话 | 是 |String | 受票方公司联系电话，手机号或座机 | +|buyerBankName |受票方银行 | 是 |String | 受票方开户行 | +|buyerBankAccount |受票方银行账号 | 是 |String | 受票方银行卡号 | +|invoiceUrl |货主发票文件 | 可选 |List | 货主发票文件 | + +##### invoiceUrl子项参数 + +|参数名|名称|必选|类型|说明| +|:---- |:---|:----- |----- | +|name |货主发票文件名称 |是 |String |文件名称，需要加文件格式后缀名 | +|url |货主发票文件地址 |可选 |String | 文件地址 | +|dataList |货主发票文件对象 | 可选 |String | base64 | + +##### oilGasInvoices子项参数 + +|参数名|名称|必选|类型|说明| +|:---- |:---|:----- |----- | +|shippingNoteNumber |托运单号 |是 |String |油气托运单号必须存在于税票中 | +|oilGasFileUrl |油气发票地址 |是 |String | 油气发票地址 | + +##### oilGasFileUrl子项参数 + +|参数名|名称|必选|类型|说明| +|:---- |:---|:----- |----- | +|name |文件名称 |是 |String |文件名称，需要加文件格式后缀名 | +|url |文件地址 |可选 |String | 文件地址 | +|dataList |文件对象 | 可选 |String | base64 | + +##### 请求示例 +```json +{ + "partnerId": "xxx", + "appId": "xxx", + "workerId": "001", + "args": { + "invoice":{ + "shippingNoteNumberList":[ + "test007", + "test008" + ], + "invoiceNumber":"xxx", + "invoiceCode":"xxx", + "invoiceAmount":xxx, + "invoiceDateTime":"xxx", + "sellerName":"销售方名称", + "sellerTaxpayerIdentification":"123456", + "sellerAddress":"销售方地址", + "sellerTelephone":"xxx", + "sellerBankName":"中国银行", + "sellerBankAccount":"xxx", + "buyerName":"受票方名称", + "buyerTaxpayerIdentification":"123456", + "buyerAddress":"受票方地址", + "buyerTelephone":"xxx", + "buyerBankName":"中国银行", + "buyerBankAccount":"xxx", + "invoiceUrl":[ + { + "name":"税票文件.jpg", + "url":"https://www.123.123", + "dataList":"文件对象" + }, + { + "name":"税票文件.jpg", + "url":"https://www.123.123", + "dataList":"文件对象" + } + ] + }, + "oilGasInvoices":[ + { + "shippingNoteNumber":"test007", + "oilGasFileUrl":[ + { + "name":"图片.jpg", + "url":"https://wwww.xx.xx", + "dataList":"文件对象" + }, + { + "name":"图片.jpg", + "url":"https://wwww.xx.xx", + "dataList":"文件对象" + } + ] + }, + { + "shippingNoteNumber":"test008", + "oilGasFileUrl":[ + { + "name":"图片.jpg", + "url":"https://wwww.xx.xx", + "dataList":"文件对象" + }, + { + "name":"图片.jpg", + "url":"https://wwww.xx.xx", + "dataList":"文件对象" + } + ] + } + ] + } +} +``` + + +##### 返回参数说明 + +| 参数 | 名称 | 类型 | 说明 | +| :-------- | :------- | ------- | ----------------------------------- | +| success | 成功标志 | boolean | 返回true或false | +| message | 返回信息 | String | 返回的提示信息 | +| code | 返回代码 | int | 如200：成功，500：服务器内部错误 等 | +| result | 返回数据 | Object | 如有需要，返回数据对象 | +| timestamp | 时间戳 | long | 13位时间戳，精确到毫秒 | + + + +##### 返回示例 + +``` +{ + "success": true, + "message": "", + "code": 200, + "result": true, + "timestamp": 1672121404682 +} +``` + +### ETC发票上传 + +[TOC] + +##### 简要描述 + +- 第三次上传完后，可上传ETC发票。 + +##### 请求URL +- ` xxxxxx/api/dataUpload/etcInvoiceUpload ` + +##### 请求方式 +- POST + + +##### 请求参数 + +|参数名|名称|必选|类型|说明| +|:---- |:---|:----- |----- | +|shippingNoteNumber |托运单号 |是 |String |运单单号 | +|vehicleNumber |车牌号 | 是 |String | 车牌号 | +|vehiclePlateColorCode |车牌颜色编号 | 是 |String | 车牌颜色编号 | +|etcInvoices |etc发票 |是 |List |发票关联的运单ETC发票 | + +##### etcInvoices子项参数 + +|参数名|名称|必选|类型|说明| +|:---- |:---|:----- |----- | +|invoiceNumber |发票号码 |是 |String | 发票号码，不允许重复 | +|invoiceCode |发票代码号 | 是 |String | 发票代码号(备注：数电票可传发票号码) | +|invoicingTime |开票时间 | 是 |String | 开票时间，yyyyMMddHHmmss | +|invoiceAmount |不含税金额 | 是 |Number | 发票的不含税金额，货币单位为人民币（元），保留2位小数，如整数的话，以.00填充。 | +|taxRate |税率 | 是 |String | 税率，格式，x.x% | +|taxAmount |税额 | 是 |String | 税额，保留2位小数，如整数的话，以.00填充。 | +|totalPriceAndTax |发票金额 | 是 |String | 发票价税合计金额，保留2位小数，如整数的话，以.00填充。 | +|sellerName |销售方名称 | 是 |String | 销售方名称 | +|sellerTaxNumber |销售方税号 | 是 |String | 销售方税号 | +|acceptorName |受票方名称 | 是 |String | 受票方名称 | +|acceptorTaxNumber |受票方税号 | 是 |String | 受票方税号 | +|entranceTollStation |入口收费站 | 是 |String | 入口收费站 | +|exportTollStation |出口收费站 | 是 |String | 出口收费站 | +|transactionTime |交易时间 | 是 |String | 交易时间，yyyyMMddHHmmss | +|transactionAmount |交易金额 | 是 |String | 交易金额 | +|transactionMatchingTime |交易匹配时间 | 否 |String | 交易匹配时间，yyyyMMddHHmmss | +|transactionId |交易ID | 是 |String | 交易ID | +|etcFileUrl |ETC发票地址 |是 |String | ETC发票地址 | + +##### etcFileUrl子项参数 + +|参数名|名称|必选|类型|说明| +|:---- |:---|:----- |----- | +|name |文件名称 |是 |String |文件名称，需要加文件格式后缀名 | +|url |文件地址 |可选 |String | 文件地址 | +|dataList |文件对象 | 可选 |String | base64 | + +##### 请求示例 +```json +{ + "partnerId": "xxx", + "appId": "xxx", + "workerId": "001", + "argList": [ + { + "shippingNoteNumber": "test_12345611118116021", + "vehicleNumber": "鲁H825V7", + "vehiclePlateColorCode": "2", + "etcInvoices": [ + { + "invoiceNumber": "发票号码12345678912", + "invoiceCode": "发票代码12345678912", + "invoicingTime": "20250806121212", + "invoiceAmount": "500", + "taxRate": "3%", + "taxAmount": "20", + "totalPriceAndTax": "520", + "sellerName": "销售方名称", + "sellerTaxNumber": "销售方税号", + "acceptorName": "受票方名称", + "acceptorTaxNumber": "受票方税号", + "entranceTollStation": "入口收费站", + "exportTollStation": "出口收费站", + "transactionTime": "20250806121212", + "transactionAmount": "100", + "transactionMatchingTime": "20240102003125", + "transactionId": "11111111111111111", + "etcFileUrl": [ + { + "name": "发票文件.png", + "url": "https://xxxxx.com" + } + ] + } + ] + } + ] +} +``` + + +##### 返回参数说明 + +| 参数 | 名称 | 类型 | 说明 | +| :-------- | :------- | ------- | ----------------------------------- | +| success | 成功标志 | boolean | 返回true或false | +| message | 返回信息 | String | 返回的提示信息 | +| code | 返回代码 | int | 如200：成功，500：服务器内部错误 等 | +| result | 返回数据 | Object | 如有需要，返回数据对象 | +| timestamp | 时间戳 | long | 13位时间戳，精确到毫秒 | + + + +##### 返回示例 + +``` +{ + "success": true, + "message": "", + "code": 200, + "result": true, + "timestamp": 1672121404682 +} +``` + +### 修改第一次上报部分字段 + +[TOC] + +#### 简要描述 + +- 接口修改上传的数据。 + +#### 请求URL +- ` xxxxxx/api/dataUpload/updateFirstUploadParam ` + +#### 请求方式 +- POST + + +#### args请求参数 + +| 参数名 | 必选 | 类型 | 说明 | +| :----------------- | :--- | :----- | -------------------------------------- | +| shippingNoteNumber | 是 | String | 托运单号(最大长度为20位) | +| driverInfo | 可选 | Object | 驾驶员信息 ，其中字段全部为选填 | +| carInfo | 可选 | Object | 车辆信息，其中字段全部为选填 | +| waybillInfo | 可选 | Object | 运单信息，字段为里程 | +| consignorInfo | 可选 | Object | 托运人信息，其中字段为地址、经度、维度 | +| consigneeInfo | 可选 | Object | 收货方信息，其中字段为地址、经度、维度 | + + +#### 请求示例 +```json +{ + "partnerId": "xxx", + "appId": "xxx", + "workerId": "001", + "args": { + "carInfo": { + "grossMass": "1.00", + "issueDate": "11111111", + "issuingOrganizations": "1", + "LicensePlateTypeCode": "99", + "owner": "1", + "ownerId": "11111111111", + "registerDate": "11111111", + "roadTransportCertificateNumber": "111111000000", + "roadTransportSocialCreditFrom": "11111111", + "roadTransportSocialCreditTo": "11111111", + "trailerVehiclePlateNumber": "1", + "useCharacter": "1", + "vehicleEnergyType": "Z", + "vehicleLicenseNumber": "111111111111", + "vehicleNumber": "1", + "vehiclePlateColorCode": "3", + "vehicleTonnage": "1", + "vehicleType": "H21", + "vin": "1111111" + }, + "driverInfo": { + "anchoredUrl": [ + { + "dataList": "", + "name": "111.jpg", + "url": "https://img0.baidu.com/it/u=1705694933,4002952892&fm=253&app=138&size=w931&n=0&f=JPEG&fmt=auto?sec=1676394000&t=61c53ca8fb7c5e1cc2fd9e8ada096acd" + } + ], + "driverName": "1", + "drivingIdNumber": "1", + "drivingLicense": "1", + "issuingOrganizations": "1", + "provinceCode": "111111", + "qualificationCertificate": "1", + "qualificationCertificateFrom": "11111111", + "qualificationCertificateTo": "11111111", + "taxRegistrationCertificate": "1", + "telephone": "1", + "validPeriodFrom": "11111111", + "validPeriodTo": "11111111", + "vehicleClass": "1" + }, + "waybillInfo": { + "mileage": "200" + }, + "consignorInfo":{ + "placeOfLoading":"山东省/青岛市/黄岛区", + "loadingLongitude":"107.298672", + "loadingLatitude":"40.796695" + }, + "consigneeInfo":{ + "goodsReceiptPlace":"河北省/邯郸市/永年区", + "unLoadingLongitude":"107.298672", + "unLoadingLatitude":"40.796695" + }, + "shippingNoteNumber": "${danhao}" + } +} +``` + + +#### 返回参数说明 + +| 参数 | 名称 | 类型 | 说明 | +| :-------- | :------- | ------- | ----------------------------------- | +| success | 成功标志 | boolean | 返回true或false | +| message | 返回信息 | String | 返回的提示信息 | +| code | 返回代码 | int | 如200：成功，500：服务器内部错误 等 | +| result | 返回数据 | Object | 如有需要，返回数据对象 | +| timestamp | 时间戳 | long | 13位时间戳，精确到毫秒 | + + + +#### 返回示例 + +``` +{ + "success": true, + "message": "", + "code": 200, + "result": true, + "timestamp": 1672121404682 +} +``` + +### 常见问题 + +安徽省网络货运服务平台 + +接入问题解答 + +## 技术类 + +Q: carInfo子项参数中LicensePlateTypeCode首字母是大写吗？ + +A: 是的。 + +## 上报流程类 + +Q: 服务平台要求的上传时效是怎样的，是否要求实时上传？ + +A: 按照主管部门要求，网络货运企业需要在货物起运后及时上传运单信息，资金流水信息与发票信息也需要在一定周期内完成上传。 + +Q: 必须需要分三次传数据吗，运单完结后一次性上传所有数据是否可行？ + +A: 该上传方式可能会触发实时单异常，不建议企业在运单完结后统一上传。 + +Q：运单上传至服务平台后作废了该如何处理？是否有作废/取消运单接口？该类运单是否会对企业的合规率产生影响吗？ + +A：服务平台不支持取消或删除运单，按主管部门要求，上传至服务平台的运单不允许修改任何信息，建议企业在运单信息确认后再进行上传，服务平台在统计合规率时是不会将未完结的运单计算在内的。 + +## 合同类 + +Q: 委托合同（框架）和委托合同是否二选一上传就可以？ + +A: 是的。 + +Q: 委托合同（框架）的上传时间节点？ + +A: 在进行运单的第一次上报前需要将框架合同通过接口上传至服务平台，后续合同如果有新增或者修改，再调用上传或者修改接口即可。 + +Q: 上传了委托框架合同，在服务平台里可以看到框架合同吗？ + +A: 目前服务平台不支持单独查询合同，可在运单进行第一次上传后，在运单信息中查看合同。 + +## 车辆资质、人员资质类 + +Q: 网络货运企业目前没有收集从业资格证地址，从业资格证的国家行政区划代码如何填写？ + +A: 可按照身份证号的行政区划代码进行填写。 + +## 资金流水类 + +Q: 一条运单分多次支付司机运费是否可以上传多条资金流水信息？ + +A: 可以，服务平台支持一条运单上传多条流水信息。 + +Q: 货主支付的运费为预付款项（例如一次性支付500万），这种情况下货主流水如何上传？ + +A: 一笔货主支付流水可对应多条运单，将货主流水信息据实上传即可。 + +Q: 承运人流水中的税率和税额指的什么意思？ + +A: 目前税率统一传3%、税额按3%计算即可。 + +Q：油卡金额如何填写？ + +A：在上传承运人流水时据实填写油卡金额，如一条运单存在多条承运人流水，可在任一承运人流水中填写油卡金额。 + +## 车辆轨迹类 + +Q: 车辆轨迹上传的点数有要求吗？ + +A: 企业上传的轨迹点数需要在2-2000之间。 + +Q: 传轨迹的时候要详细地址，企业只有经纬度没有详细地址怎么办？ + +A: 地址字段没有的话先传“-”。 + +## 服务平台核验类 + +Q: 运单上传后多久开始核验？ + +A: 除承运人流水核验需等待次日银行提供数据后开始核验，其余核验项会在一至两小时内核验完成。 + +Q：服务平台的核验规则是怎样的？主要核验哪些内容？ + +A：企业完成与服务平台的数据对接后，可上传一批真实业务数据进行测试，届时可根据核验结果详细沟通核验规则。 + +Q：服务平台的核验结果怎么查看？异常运单如何处理？ + +A：查看服务平台核验结果有两种方式：一是在服务平台提供的企业端内进行查询，并可为异常运单提供相应的佐证材料进行申诉；二是对接服务平台异常查询接口，实现在企业自有系统内查询、处理异常运单。 + +## 发票类 + +Q：必须是合规的运单才允许开具货主发票吗？在什么节点可以看到运单是否可以开票？ + +A：按照主管部门要求，运单必须上传至服务平台且核验通过后才允许开具货主发票；企业完成运单的第二次上传后即可在服务平台企业端中查看核验结果，或对接服务平台核验结果查询接口进行查看。 + +Q：货主发票开具后需要红冲如何操作？ + +A：可在服务平台企业端内将货主发票作废，作废后再将重新开具的货主发票通过第三次上传接口上传至服务平台。 + +持续更新中... \ No newline at end of file diff --git a/source_docs/requirements_raw/网货企业端接口文档（最新）.pdf b/resources/integration/网货企业端接口文档（最新）.pdf similarity index 100% rename from source_docs/requirements_raw/网货企业端接口文档（最新）.pdf rename to resources/integration/网货企业端接口文档（最新）.pdf diff --git a/resources/prototypes/anhuibaba_enhanced.html b/resources/prototypes/anhuibaba_enhanced.html new file mode 100644 index 0000000..0b5a019 --- /dev/null +++ b/resources/prototypes/anhuibaba_enhanced.html @@ -0,0 +1,1123 @@ + + + + +安徽运八税务上报平台（以API文档重构） + + + + + +
+ + +
+

安徽运八税务上报

+
API V1.0.2 · 重构版
+ +
+ + +
+
+ 监管上报 + / +

上报运单看板

+
+
+ + +
+
+
⚠️
23
异常运单
+
⏳
12
待申诉（未申诉·100）
+
🔄
5
申诉中
+
✅
38
核验通过（110）
+
+ +
+ + + + + + + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
货源单号运单号托运单号车牌号司机姓名上报阶段托运方名称核验状态申诉状态异常项货物名称合同金额最新核验时间操作
GH20260710001TCNY0500260370070930012606170930492293197皖A12345张伟第二次上报安徽XX物流有限公司全部异常(120)未申诉(100)车辆轨迹(210)·资金流水(250)钢材¥3,200.002026-07-06 15:30
GH20260710002TCNY0500260370070930022606170930523344782皖B67890李强第二次上报合肥XX贸易有限公司全部异常(120)未申诉(100)·申诉中车辆资质(150)煤炭¥5,800.002026-07-06 15:28
GH20260710003TCNY0500260370070930032606170930554415893皖C54321王芳第一次上报南京XX供应链有限公司全部异常(120)审核通过(110)承运合同(120)粮食¥12,400.002026-07-06 15:25
GH20260710004TCNY0500260370070930042606170930585526104皖D98765刘洋已完成安徽XX运业有限公司核验通过(110)——矿石¥8,600.002026-07-06 15:20
GH20260710005TCNY0500260370070930052606170930616637215皖E11111陈明第一次上报合肥XX物流有限公司全部异常(120)审核不通过(120)委托合同(100)·车辆重复(190)水泥¥4,500.002026-07-06 15:15
+
共 23 条，第 1~5 条
+
+
+ + +
+
+ ℹ️ 前置步骤：在进行运单第一次上报前，需将委托合同（框架）通过接口 POST /api/dataUpload/mandateContractFrame 上传至省平台。委托合同（框架）和委托合同二选一上报。文件信息可暂不传，在修改委托合同时再补充合同文件。 +
+
+
✅
15
已上传
+
⏳
2
未上传合同
+
+
+ + + + + +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
合同编号合同类型托运企业名称统一社会信用代码关联托运企业数有效期截止合同文件上传时间上传状态操作
666666委托合同（框架）安徽XX物流有限公司91340000XXXXXXXXXX22022-12-14合肥税务监管平台V1.0 结项表.pdf2026-07-06 09:00已上传
777777委托合同（框架）合肥XX贸易有限公司91340100XXXXXXXXXX12023-05-20缺少合同文件2026-07-05 14:00缺少合同文件
+
共 17 条，第 1~2 条
+
+
+ + +
+
+
⏳
6
上传中
+
✅
38
已上传
+
❌
2
上传失败
+
⚠️
3
异常
+
+
+ + + +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
货源单号运单号托运单号车牌号司机姓名托运方名称业务类型货物名称装货地址卸货地址运输里程合同编号上报状态操作
GH20260710001TCNY0500260370070930012606170930492293197皖A12345张伟安徽XX物流有限公司普通货运钢材安徽省合肥市xx路xx号江苏省南京市xx路xx号358kmHT20260705001上传中
GH20260710002TCNY0500260370070930022606170930523344782皖B67890李强合肥XX贸易有限公司普通货运煤炭山东省济南市xx路xx号河南省郑州市xx路xx号420kmHT20260705002已上传
GH20260710003TCNY0500260370070930032606170930554415893皖C54321王芳南京XX供应链有限公司冷链运输粮食江苏省南京市xx路xx号浙江省杭州市xx路xx号280kmHT20260705003上传失败
+
共 11 条，第 1~3 条
+
+
+ + +
+
+
📤
6
待上报
+
✅
38
已上报
+
⚠️
2
异常
+
🔍
17
核验项
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
货源单号运单号托运单号车牌号司机姓名托运方名称承运运费总金额付款方式付款时间收款人收款账号收款账号类型核验状态异常项上报状态操作
GH20260709003TCNY0500260370070920012606090930492293197皖F12345赵六安徽XX物流有限公司¥3,200.00¥3,500.00银行转账2026-07-06 14:00赵六6222021234567890123个人账户全部异常(120)车辆轨迹(210)待上报
GH20260709004TCNY0500260370070920022606090930523344782皖G67890孙七合肥XX贸易有限公司¥5,800.00¥6,200.00微信支付2026-07-06 13:30合肥XX贸易有限公司34001623200809123456对公账户核验通过(110)—已上报
GH20260709005TCNY0500260370070920032606090930554415893皖H54321周八南京XX供应链有限公司¥12,400.00¥13,000.00银行转账2026-07-06 12:00南京XX供应链有限公司32011523456789012345对公账户全部异常(120)资金流水(250)异常
+
共 9 条，第 1~3 条
+
+
+ + +
+
+
📤
4
待上报
+
✅
35
已上报
+
⚠️
1
异常
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
货源单号运单号托运单号发票号码发票金额税率销售方名称受票方名称开票日期油气票张数核验状态异常原因上报状态操作
GH20260709004TCNY050026037007092002260609093052334478234002000000012345678¥6,200.009%合肥XX贸易有限公司安徽XX物流有限公司2026-07-062核验通过(110)—已上报
GH20260709005TCNY050026037007092003260609093055441589334002000000012345679¥13,000.009%南京XX供应链有限公司安徽XX物流有限公司2026-07-061全部异常(120)发票信息(260)·受票方信息不匹配待上报
+
共 5 条，第 1~2 条
+
+
+ + +
+
+
🧾
7
待上传
+
✅
28
已上传
+
⚠️
2
异常
+
+
+ ℹ️ 触发机制：ETC发票税务抵扣成功后，由运营人员在运八系统手动确认抵扣完成，确认后系统触发ETC发票上传（非自动触发）。接口：POST /api/dataUpload/etcInvoiceUpload（Showdoc定义）。 +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
货源单号运单号托运单号ETC发票号交易金额入口收费站出口收费站交易时间上传状态操作
GH20260709004TCNY050026037007092002260609093052334478234102000000000123456¥158.50皖A站皖B站2026-07-06 18:30已上传
GH20260709005TCNY050026037007092003260609093055441589334102000000000123457¥203.00皖C站皖D站2026-07-06 19:00待上传
+
共 9 条，第 1~2 条
+
+
+ + +
+
+
⏳
12
未申诉(100)·申诉中
+
✅
38
审核通过(110)
+
❌
8
审核不通过(120)
+
🚫
1
已取消(130)·省平台只读
+
+
+ + + + + +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
运单号托运单号车牌号司机姓名托运方名称上报阶段核验状态异常项申诉状态申诉时间申诉人省平台反馈结果省平台反馈时间操作
TCNY0500260370070930012606170930492293197皖A12345张伟安徽XX物流有限公司第二次上报全部异常(120)车辆轨迹(210)未申诉(100)·申诉中2026-07-06 16:00管理员待反馈—
TCNY0500260370070930022606170930523344782皖B67890李强合肥XX贸易有限公司第一次上报全部异常(120)驾驶证(170)审核通过(110)2026-07-05 10:30王经理审核通过2026-07-06 09:15
TCNY0500260370070930032606170930554415893皖C54321王芳南京XX供应链有限公司第一次上报全部异常(120)承运合同(120)审核不通过(120)2026-07-04 14:20赵主管审核不通过·证明材料不充分2026-07-05 11:00
TCNY0500260370070930062606170930712345678皖M11111吴九芜湖XX运输有限公司第二次上报全部异常(120)运费收款(220)已取消(130)2026-07-03 09:00陈运营申诉已取消2026-07-04 16:00
+
共 63 条，第 1~4 条
+
+
+ + +
+
+ + + + + 至 + + + +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
序号货源单号运单号托运单号上报阶段上报结果接口URLHTTP状态码响应时间上报时间操作
1GH20260710001TCNY0500260370070930012606170930492293197第一次上报成功https://api.ahyunba.com/v1/firstUpload200230ms2026-07-06 15:30
2GH20260710003TCNY0500260370070930032606170930554415893第一次上报失败https://api.ahyunba.com/v1/firstUpload500超时2026-07-06 15:25
3GH20260710002TCNY0500260370070930022606170930523344782第二次上报成功https://api.ahyunba.com/v1/secondUpload200312ms2026-07-06 15:28
+
共 156 条，第 1~3 条
+
+
+ +
+
+ + + + +
+
+

📜 委托合同上传详情（Showdoc: mandateContractFrame）

+
+
📄 合同基本信息
+
合同编号666666
+
合同类型委托合同（框架）
+
有效期截止2022-12-14 (yyyy-MM-dd)
+
备注委托合同（框架）和委托合同二选一上报
+
+
🏢 托运企业信息
+
托运企业（单）安徽XX物流有限公司
+
统一社会信用代码（单）91340000XXXXXXXXXX
+
+
关联企业列表（共2家）：
+
+
1. 统一社会信用代码: 111111 | 企业名称: 关联企业一
+
2. 统一社会信用代码: 222222 | 企业名称: 关联企业二
+
+
📎 合同文件信息
+
上传文件信息可选，后续可通过修改委托合同接口补充。
+
+
1. 合肥税务监管平台V1.0 结项表.pdf 查看
+
+
+
ℹ️ 接口字段规范（Showdoc）
+
+ 时间格式: 有效期截止用 yyyy-MM-dd（非14位）
+ 必选字段: contract_number(合同编号), expire_time(有效期截止时间)
+ 可选字段: unified_social_credit_identifier(单托运企业信用代码), owner_enterprise_name(单托运企业名称), enterpriseList(多托运企业列表), uploadFileInfo(文件信息) +
+
+
+
+
+
+ + +
+
+

📤 第一次上报详情（装货完成）

+
+
📋 建单信息（必选）（API时间格式: yyyyMMddHHmmss 14位）
+
运单号TCNY050026037007093001
+
货源单号GH20260710001
+
托运单号2606170930492293197
+
业务类型普通货运
+
建单时间(API)20260706090000→ 2026-07-06 09:00
+
起运时间(API)20260706180000→ 2026-07-06 18:00
+
运输里程358km
+
运单金额(3位小数)3200.000
+
运费支付方式银行转账
+
运费支付时间(API)20260706140000
+
+
👤 托运人信息（必选）
+
托运人名称安徽XX物流有限公司
+
统一社会信用代码91340000XXXXXXXXXX
+
托运人地址安徽省合肥市xx区xx路xx号
+
托运人联系人张经理
+
托运人联系电话138****1234
+
货物名称钢材
+
货物重量(吨)25.5
+
货物体积(方)30.2
+
+
📦 收货方信息（必选）
+
收货方名称江苏XX钢铁有限公司
+
统一社会信用代码91320000XXXXXXXXXX
+
收货方地址江苏省南京市xx区xx路xx号
+
卸货地址江苏省南京市xx区xx路xx号
+
签收状态已签收
+
+
🚗 司机信息（必选）· 省份代码=34
+
司机姓名张伟
+
身份证号340***********1234
+
驾驶证号3400********123456
+
联系电话138****8888
+
从业资格证号3400********654321
+
省份代码34
+
+
🚚 接单车辆信息（必选）
+
车牌号皖A12345
+
车辆类型重型半挂车
+
VIN码LVB********123456
+
道路运输证号交运字第3400XXXXXX
+
车辆所有人安徽XX物流有限公司
+
核定载质量(吨)32
+
+
📦 货物信息（必选，可多条）
+
+ 货物 #1（共1件）
+ 货物名称: 钢材 | 货物类型: 建材 | 重量: 25.5吨 | 体积: 30.2方 | 件数: 120 | 单价: ¥125.50/吨 +
+
+
🛡️ 保险信息（可选）
+
保单号PY202607060001
+
保险公司中国XX财产保险股份有限公司
+
+
⚠️ 异常信息
+
核验状态全部异常(120)
+
异常原因车辆资质(150)·驾驶证(170)
+
异常时间2026-07-06 15:30
+
处理状态未申诉(100)
+
+
+
+
+
+ + +
+
+

💰 第二次上报详情（打款完成）

+
+
📋 运单信息
+
运单号TCNY050026037007092002
+
货源单号GH20260709004
+
合同编号HT20260705002
+
合同金额¥5,800.00
+
运输里程420km
+
业务类型普通货运
+
+
💰 资金流水信息（必选·Showdoc定义）金额3位小数·时间yyyyMMddHHmmss
+
支付金额¥5,800.000
+
支付方式微信支付
+
支付时间(API)20260706133000
+
付款方名称安徽XX物流有限公司
+
收款方名称合肥XX贸易有限公司
+
收款人合肥XX贸易有限公司
+
收款账号34001623200809123456
+
收款账号类型对公账户
+
流水号1000010001202607060000001234
+
支付状态支付成功
+
+
🛰️ 车辆轨迹信息（必选·2~2000点）
+
共 150 个轨迹点，展示前5个：
+ + + + + +
#定位类型定位时间经度纬度轨迹类型
1GPS2026-07-06 09:05117.12345631.823456运输中
2GPS2026-07-06 09:10117.23456731.934567运输中
..................
+
+
🔍 17项核验结果
+
+
100委托合同 ✅
+
120承运合同 ✅
+
130实时定位 ✅
+
140运单时间逻辑 ✅
+
150车辆资质 ✅
+
160道路运输证 ✅
+
170驾驶证 ✅
+
180从业资格证 ✅
+
190车辆重复 ✅
+
200司机重复 ✅
+
210车辆轨迹 ❌
+
220运费收款 ✅
+
230公司统一收款 ✅
+
240集中支付 ✅
+
250资金流水 ❌
+
260发票信息 ✅
+
270非通行车辆可开票 ✅
+
+
+
⚠️ 异常信息
+
核验状态全部异常(120)
+
异常项车辆轨迹(210)·资金流水(250)
+
异常时间2026-07-06 15:30
+
处理状态未申诉(100)
+
+
+
+ + + +
+
+
+ + +
+
+

🧾 第三次上报详情（开票完成）

+
+
📄 发票信息（必选）
+
发票号码34002000000012345679
+
发票代码340020000000
+
发票金额¥13,000.00
+
税率9%
+
开票日期2026-07-06
+
销售方名称南京XX供应链有限公司
+
销售方纳税人识别号91320000XXXXXXXXXX
+
受票方名称安徽XX物流有限公司
+
受票方纳税人识别号91340000XXXXXXXXXX
+
发票合规系统核验合规(true)
+
+
⚠️ 异常信息
+
核验状态全部异常(120)
+
异常原因发票信息(260)·受票方信息不匹配
+
异常时间2026-07-06 15:30
+
处理状态待处理
+
+
+
+
+
+ + +
+
+

🛣️ ETC发票上传详情

+
+
📋 运单信息
+
运单号TCNY050026037007092002
+
货源单号GH20260709004
+
车牌号皖A12345
+
司机姓名张伟
+
+
🧾 ETC发票信息（Showdoc定义·17字段）时间yyyyMMddHHmmss·税率3%
+
ETC发票号码34102000000000123456
+
ETC发票代码341020000000
+
不含税金额(API)¥153.88← invoiceAmount
+
税率3%
+
税额¥4.62
+
价税合计(API)¥158.50← totalPriceAndTax
+
入口收费站皖A站
+
出口收费站皖B站
+
交易时间(API)20260706183000
+
发票状态有效
+
+
+
+
+
+ + +
+
+

📝 发起申诉 — verificationAbnormalItems 仅支持单值

+
+
+
⚠️ API约束（§3.3 /appeal/insert）：verificationAbnormalItems 仅支持单个异常项目申诉。如运单存在多个异常项（如车辆轨迹210 + 资金流水250），需分别逐个发起申诉，每次仅选一项。
+ +
+ + +
+ +
+ +
+
+
车辆轨迹(210)
异常原因：实际轨迹与上报轨迹不匹配
+ 待申诉 +
+
+
+
资金流水(250)
异常原因：金额不匹配
+ 待申诉 +
+
+ +
+ + +
+ +
+ + +
+ +
+ +
+ 📎点击上传附件 + ✅ 车辆轨迹截图.png +
+
+
+
+
+ + +
+
+
+ + + +
+
+

📝 申诉记录详情

+
+
📤 申诉信息（API: /appeal/page 响应）
+
申诉单号AP202607060001
+
申诉状态未申诉(100)·申诉中
+
异常项车辆轨迹(210)
+
申诉原因车辆实际轨迹与上报轨迹一致，请核实
+
申诉时间2026-07-06 16:00
+
申诉人管理员
+
申诉附件车辆轨迹截图.png
+
+
✅ 省平台反馈信息（API: /appeal/page → auditStateId）
+
审核状态待反馈（未申诉·申诉中）
+
审核人—
+
审核备注—
+
审核时间—
+
+
📜 处理记录（时间线）
+
+
2026-07-06 16:00
管理员 提交申诉至省平台 · 申诉内容: 车辆实际轨迹与上报轨迹一致，请核实
+
+
+
+
+ +
+
+
+ + +
+
+

📋 上报日志详情

+
+
📤 请求报文
+
POST /api/v1/firstUpload HTTP/1.1 +Host: api.ahyunba.com +Content-Type: application/json +Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9... + +{ + "waybillInfo": { + "shippingNoteNumber": "TCNY050026037007093001", + "carrier": "安徽XX物流有限公司", + ... + }, + "driverInfo": { + "driverName": "张伟", + "provinceCode": "34" + ... + } +}
+
+
📥 响应报文
+
HTTP/1.1 200 OK +Content-Type: application/json + +{ + "code": 200, + "message": "操作成功", + "data": {} +}
+
+ HTTP状态码: 200  |  响应时间: 230ms  |  上报时间: 2026-07-06 15:30 +
+
+
+
+
+
+ + + + diff --git a/scripts/case_pipeline.py b/scripts/case_pipeline.py index 6ce716f..f97cf1d 100644 --- a/scripts/case_pipeline.py +++ b/scripts/case_pipeline.py @@ -475,6 +475,8 @@ def iter_requirement_documents() -> list[Path]: continue if item.stat().st_size == 0: continue + if item.name.startswith("~$"): # 跳过 Office 临时锁定文件 + continue result.append(item) return result diff --git a/scripts/fleet_agents.py b/scripts/fleet_agents.py index f05646a..a44f4f5 100644 --- a/scripts/fleet_agents.py +++ b/scripts/fleet_agents.py @@ -229,3 +229,71 @@ def validate_all_agents() -> dict[str, Any]: result["empty"].append(agent_id) result["valid"] = False return result + + +def build_agent_invocation_context(base_name: str, agent_id: str) -> dict[str, Any]: + """为 AI Agent 调用构建完整的上下文注入字典。""" + from fleet_manifest import ZONE_ORDER, load_manifest_safe + + info = AGENT_REGISTRY.get(agent_id, {}) + zone = info.get("zone", "") + + context: dict[str, Any] = { + "base_name": base_name, + "agent_id": agent_id, + "agent_zone": zone, + "repo_root": str(REPO_ROOT), + "output_dir": str(REPO_ROOT / "output"), + "manifests_dir": str(REPO_ROOT / "output" / "manifests"), + "knowledge_base_dir": str(REPO_ROOT / "knowledge_base"), + "fleet_config_path": str(REPO_ROOT / "fleet_config.yml"), + "PROJECT_PROFILE": str(REPO_ROOT / "knowledge_base" / "00_project" / "project_profile.md"), + "FLEET_CONFIG": str(REPO_ROOT / "fleet_config.yml"), + } + + for prev_zone in ZONE_ORDER: + manifest = load_manifest_safe(base_name, prev_zone) + if manifest is None: + continue + context[f"manifest_{prev_zone}"] = manifest + for key, value in manifest.items(): + if key.endswith("_file") or key.endswith("_files"): + context[key] = value + if prev_zone == zone: + break + + return context + + +def get_agent_input_files(base_name: str, agent_id: str) -> list[str]: + """返回 Agent 需要的所有输入文件路径列表。""" + from fleet_manifest import ZONE_ORDER, load_manifest_safe + + info = AGENT_REGISTRY.get(agent_id, {}) + zone = info.get("zone", "") + input_files: list[str] = [] + + for prev_zone in ZONE_ORDER: + if prev_zone == zone: + break + manifest = load_manifest_safe(base_name, prev_zone) + if manifest is None: + continue + for key in manifest: + if key.endswith("_file") or key.endswith("_files"): + value = manifest[key] + if isinstance(value, str): + input_files.append(value) + elif isinstance(value, list): + input_files.extend(v for v in value if isinstance(v, str)) + + kb_files = [ + str(REPO_ROOT / "knowledge_base" / "00_project" / "project_profile.md"), + str(REPO_ROOT / "knowledge_base" / "01_standards" / "test_case_template.md"), + str(REPO_ROOT / "knowledge_base" / "01_standards" / "review_checklist.md"), + str(REPO_ROOT / "knowledge_base" / "01_standards" / "definition_of_done.md"), + str(REPO_ROOT / "fleet_config.yml"), + ] + input_files.extend(kb_files) + + return sorted(set(input_files)) diff --git a/scripts/fleet_manifest.py b/scripts/fleet_manifest.py index 7d86baf..284d5e3 100644 --- a/scripts/fleet_manifest.py +++ b/scripts/fleet_manifest.py @@ -189,3 +189,56 @@ def migrate_legacy_manifest(base_name: str) -> dict[str, Any]: save_manifest(base_name, "analyze", analyze_data) return build_merged_manifest(base_name) + + +def get_pending_ai_agents(base_name: str) -> list[dict[str, Any]]: + """扫描所有战区 manifest，返回状态为 'pending_ai' 的 Agent 列表。 + + 返回按战区依赖顺序排列的待执行 AI Agent 信息。 + """ + pending: list[dict[str, Any]] = [] + for zone in ZONE_ORDER: + manifest = load_manifest_safe(base_name, zone) + if manifest is None: + continue + agent_notes = manifest.get("agent_notes", {}) + for agent_id, note in agent_notes.items(): + if isinstance(note, dict) and note.get("status") == "pending_ai": + pending.append({ + "agent_id": agent_id, + "zone": zone, + "prompt_file": note.get("prompt_file", ""), + "output_file": note.get("output_file", ""), + "message": note.get("message", ""), + }) + elif isinstance(note, str) and "待 AI Agent" in note: + pending.append({ + "agent_id": agent_id, + "zone": zone, + "prompt_file": f"agents/{zone}/{agent_id.replace('-', '_')}.md", + "output_file": "", + "message": note, + }) + return pending + + +def update_agent_status(base_name: str, zone: str, agent_id: str, + status: str, message: str = "") -> bool: + """更新 manifest 中 Agent 的状态。 + + 返回 True 表示更新成功，False 表示 manifest 不存在或 agent 不存在。 + """ + manifest = load_manifest_safe(base_name, zone) + if manifest is None: + return False + agent_notes = manifest.setdefault("agent_notes", {}) + if agent_id in agent_notes: + if isinstance(agent_notes[agent_id], dict): + agent_notes[agent_id]["status"] = status + agent_notes[agent_id]["message"] = message + else: + agent_notes[agent_id] = {"status": status, "message": message} + else: + agent_notes[agent_id] = {"status": status, "message": message} + save_manifest(base_name, zone, manifest) + return True diff --git a/scripts/fleet_runner.py b/scripts/fleet_runner.py index 4639df8..ff651d4 100644 --- a/scripts/fleet_runner.py +++ b/scripts/fleet_runner.py @@ -179,7 +179,7 @@ def build_all_output_dirs(base_name: str) -> None: # ── 编排核心 ────────────────────────────────────────────────────────────── -def run_zone(zone: str, base_name: str, requirement_path: Path, config: dict[str, Any]) -> dict[str, Any]: +def run_zone(zone: str, base_name: str, requirement_path: Path, config: dict[str, Any], scaffold_only: bool = False) -> dict[str, Any]: """运行一个战区，返回该战区的 manifest 数据。""" zone_config = config.get("battle_zones", {}).get(zone, {}) @@ -214,7 +214,7 @@ def run_zone(zone: str, base_name: str, requirement_path: Path, config: dict[str if handler is None: raise ValueError(f"未知战区: {zone}") - result = handler(base_name, requirement_path, context, config, agents) + result = handler(base_name, requirement_path, context, config, agents, scaffold_only=scaffold_only) # 标记完成 if result: @@ -284,6 +284,7 @@ def _run_prepare_zone( context: dict[str, Any], config: dict[str, Any], agents: list[str], + scaffold_only: bool = False, ) -> dict[str, Any]: """执行 Prepare 战区: document-parser → knowledge-activator。""" @@ -315,6 +316,20 @@ def _run_prepare_zone( requirement_body = safe_read_text(normalized_requirement_file) confidence = _estimate_document_confidence(requirement_body, requirement_path.suffix.lower()) + # 附加文件检测：从需求文本中提取引用的文件路径和URL + attached_source_files = _detect_attached_files(requirement_body) + + # 构建多源注册表 + sources_registry = _build_sources_registry( + requirement_path=requirement_path, + technical_solution_files=technical_solution_files, + attached_files=attached_source_files, + ) + if attached_source_files: + print(f"📎 检测到 {len(attached_source_files)} 个附加源文件") + for af in attached_source_files: + print(f" - {af['path']} ({af.get('exists', 'unknown')})") + # 2. 知识激活 activated_knowledge = _activate_knowledge(requirement_path, config) @@ -334,6 +349,8 @@ def _run_prepare_zone( "document_confidence": confidence, "activated_knowledge": activated_knowledge, "knowledge_gaps": knowledge_gaps, + "attached_source_files": attached_source_files, + "sources_registry": sources_registry, "agent_notes": { "document-parser": f"解析完成，置信度 {confidence.get('requirement', 0):.0%}", "knowledge-activator": f"激活 {len(activated_knowledge.get('terminology', {}).get('permanent', []))} 常驻 + " @@ -447,6 +464,130 @@ def _detect_knowledge_gaps(activated_knowledge: dict[str, Any], requirement_text return gaps +def _detect_attached_files(requirement_text: str) -> list[dict[str, str]]: + """从需求文本中提取引用的文件路径和URL。 + + 支持三种模式: + 1. Windows 绝对路径 (E:\\Downloads\\xxx.pdf) + 2. URL (https://www.showdoc.com.cn/...) + 3. 相对项目路径 (output/prototype/xxx.md) + """ + import re + + attached: list[dict[str, str]] = [] + + # Pattern 1: Windows absolute paths with Chinese support + win_path_pattern = re.compile( + r'([A-Za-z]:[\\/](?:[^\\/:*?"<>|\r\n]+[\\/])*[^\\/:*?"<>|\r\n]+\.(?:pdf|docx?|xlsx?|html?|txt|md|json|xml|csv))', + re.IGNORECASE, + ) + for match in win_path_pattern.finditer(requirement_text): + path = match.group(1) + line_start = requirement_text.rfind('\n', 0, match.start()) + 1 + line_end = requirement_text.find('\n', match.end()) + context_line = requirement_text[line_start:line_end if line_end != -1 else len(requirement_text)] + attached.append({ + "path": path, + "type": "local_file", + "source": "embedded_path", + "exists": str(Path(path).exists()).lower() if path else "false", + "context_line": context_line.strip()[:200], + }) + + # Pattern 2: Documentation URLs (Showdoc, Confluence, etc.) + url_pattern = re.compile(r'(https?://[^\s\n\r一-鿿]+)') + doc_domains = ['showdoc', 'confluence', 'wiki', 'yuque', 'notion', 'figma', 'lanhu', 'axure', 'modao'] + for match in url_pattern.finditer(requirement_text): + url = match.group(1).rstrip('.,;:;）)') + if any(domain in url.lower() for domain in doc_domains): + attached.append({ + "path": url, + "type": "url", + "source": "embedded_url", + "exists": "unknown", + "context_line": "", + }) + + # Pattern 3: Project-relative paths with context keywords + rel_pattern = re.compile( + r'(?:(?:原型文件|接口文档|技术方案|设计稿|原型|文档|文件|路径)[\s：:]*)?' + r'([a-zA-Z0-9_\-\.]+/[a-zA-Z0-9_\-\./]+\.(?:html?|pdf|docx?|md|json))', + re.IGNORECASE, + ) + for match in rel_pattern.finditer(requirement_text): + rel_path = match.group(1) + if '/' not in rel_path: + continue + abs_path = REPO_ROOT / rel_path + attached.append({ + "path": str(abs_path), + "type": "project_file", + "source": "embedded_relative_path", + "exists": str(abs_path.exists()).lower(), + "context_line": "", + }) + + # Deduplicate by path + seen: set[str] = set() + unique: list[dict[str, str]] = [] + for item in attached: + if item["path"] not in seen: + seen.add(item["path"]) + unique.append(item) + return unique + + +def _build_sources_registry( + requirement_path: Path, + technical_solution_files: list[Path], + attached_files: list[dict[str, str]], +) -> list[dict[str, str]]: + """构建多源注册表，跟踪所有权威数据源及其角色。""" + registry: list[dict[str, str]] = [ + { + "path": str(requirement_path), + "type": "primary_requirement", + "role": "business_background", + "format": requirement_path.suffix.lower().lstrip("."), + "authority": "primary", + } + ] + for tf in technical_solution_files: + registry.append({ + "path": str(tf), + "type": "technical_solution", + "role": "technical_constraint", + "format": tf.suffix.lower().lstrip("."), + "authority": "technical_reference", + }) + for af in attached_files: + path = af.get("path", "") + file_type = af.get("type", "") + registry.append({ + "path": path, + "type": f"attached_{file_type}", + "role": _infer_source_role(af), + "format": Path(path).suffix.lower().lstrip(".") if file_type != "url" else "url", + "authority": "reference", + "exists": af.get("exists", "unknown"), + }) + return registry + + +def _infer_source_role(attached_file: dict[str, str]) -> str: + """推断附加源文件的角色。""" + path_lower = attached_file.get("path", "").lower() + if any(kw in path_lower for kw in ["接口", "api", "接口文档"]): + return "api_spec" + if any(kw in path_lower for kw in ["原型", "prototype", "html"]): + return "ui_prototype" + if any(kw in path_lower for kw in ["showdoc", "confluence", "wiki"]): + return "documentation" + if any(kw in path_lower for kw in ["技术方案", "technical", "设计"]): + return "technical_design" + return "reference" + + # ── Analyze 战区 ────────────────────────────────────────────────────────── def _run_analyze_zone( @@ -455,6 +596,7 @@ def _run_analyze_zone( context: dict[str, Any], config: dict[str, Any], agents: list[str], + scaffold_only: bool = False, ) -> dict[str, Any]: """执行 Analyze 战区: requirement-analyzer + conflict-detector → risk-assessor。""" @@ -640,6 +782,7 @@ def _run_design_zone( context: dict[str, Any], config: dict[str, Any], agents: list[str], + scaffold_only: bool = False, ) -> dict[str, Any]: """执行 Design 战区: strategist → (testpoint-designer + data-builder) → case-designer。""" @@ -672,13 +815,36 @@ def _run_design_zone( "test_cases_file": str(test_cases_path), "test_data_file": str(data_path), "p0_required_coverage": "100%" if p0_count > 0 else "N/A", - "agent_notes": { + } + if scaffold_only: + design_manifest["agent_notes"] = { + "test-strategist": {"status": "completed", "message": f"策略已生成，{p0_count} 个 P0 风险需 100% 覆盖"}, + "testpoint-designer": { + "status": "pending_ai", + "message": "待 AI Agent 生成测试点", + "prompt_file": "agents/design/testpoint_designer.md", + "output_file": str(test_points_path), + }, + "case-designer": { + "status": "pending_ai", + "message": "待 AI Agent 生成用例", + "prompt_file": "agents/design/case_designer.md", + "output_file": str(test_cases_path), + }, + "data-builder": { + "status": "pending_ai", + "message": "待 AI Agent 完善测试数据", + "prompt_file": "agents/design/data_builder.md", + "output_file": str(data_path), + }, + } + else: + design_manifest["agent_notes"] = { "test-strategist": f"策略已生成，{p0_count} 个 P0 风险需 100% 覆盖", "testpoint-designer": "待 AI Agent 生成测试点", "case-designer": "待 AI Agent 生成用例", "data-builder": "测试数据模板已生成", - }, - } + } save_manifest(base_name, "design", design_manifest) return design_manifest @@ -773,6 +939,7 @@ def _run_execute_zone( context: dict[str, Any], config: dict[str, Any], agents: list[str], + scaffold_only: bool = False, ) -> dict[str, Any]: """执行 Execute 战区: web-executor + mobile-executor → result-reporter。""" @@ -1376,6 +1543,7 @@ def _run_review_zone( context: dict[str, Any], config: dict[str, Any], agents: list[str], + scaffold_only: bool = False, ) -> dict[str, Any]: """执行 Review 战区: case-reviewer + coverage-auditor → quality-gatekeeper。""" @@ -1406,32 +1574,71 @@ def _run_review_zone( max_blockers = quality_gate_config.get("max_blockers", 0) # 模拟评审结果（实际由 Agent 填充） - verdict = "PASS" if case_count > 0 else "BLOCKED" - verdict_reason = ( - f"用例数量: {case_count}，覆盖率达标" if case_count > 0 - else "测试用例文件尚未生成或为空" - ) + if scaffold_only: + verdict = "PENDING_AI" + verdict_reason = "等待 AI Agent 评审（review 战区: case-reviewer → coverage-auditor → quality-gatekeeper）" + elif case_count > 0: + verdict = "PASS" + verdict_reason = f"用例数量: {case_count}，覆盖率达标" + else: + verdict = "BLOCKED" + verdict_reason = "测试用例文件尚未生成或为空" _write_verdict(base_name, verdict, verdict_reason, case_count, verdict_path) - review_manifest = { - "base_name": base_name, - "review_report_file": str(review_report_path), - "coverage_report_file": str(coverage_report_path), - "verdict_file": str(verdict_path), - "quality_verdict": { - "verdict": verdict, - "reason": verdict_reason, - "case_count": case_count, - "min_coverage_required": min_coverage, - "max_blockers_allowed": max_blockers, - }, - "agent_notes": { - "case-reviewer": f"评审完成，{case_count} 条用例" if case_count > 0 else "等待用例生成", - "coverage-auditor": "覆盖率审计待 AI Agent 执行", - "quality-gatekeeper": f"裁决: {verdict}", - }, - } + if scaffold_only: + review_manifest = { + "base_name": base_name, + "review_report_file": str(review_report_path), + "coverage_report_file": str(coverage_report_path), + "verdict_file": str(verdict_path), + "quality_verdict": { + "verdict": verdict, + "reason": verdict_reason, + "case_count": case_count, + "min_coverage_required": min_coverage, + "max_blockers_allowed": max_blockers, + }, + "agent_notes": { + "case-reviewer": { + "status": "pending_ai", + "message": "待 AI Agent 评审用例", + "prompt_file": "agents/review/case_reviewer.md", + "output_file": str(review_report_path), + }, + "coverage-auditor": { + "status": "pending_ai", + "message": "待 AI Agent 审计覆盖率", + "prompt_file": "agents/review/coverage_auditor.md", + "output_file": str(coverage_report_path), + }, + "quality-gatekeeper": { + "status": "pending_ai", + "message": "待 AI Agent 质量裁决", + "prompt_file": "agents/review/quality_gatekeeper.md", + "output_file": str(verdict_path), + }, + }, + } + else: + review_manifest = { + "base_name": base_name, + "review_report_file": str(review_report_path), + "coverage_report_file": str(coverage_report_path), + "verdict_file": str(verdict_path), + "quality_verdict": { + "verdict": verdict, + "reason": verdict_reason, + "case_count": case_count, + "min_coverage_required": min_coverage, + "max_blockers_allowed": max_blockers, + }, + "agent_notes": { + "case-reviewer": f"评审完成，{case_count} 条用例" if case_count > 0 else "等待用例生成", + "coverage-auditor": "覆盖率审计待 AI Agent 执行", + "quality-gatekeeper": f"裁决: {verdict}", + }, + } save_manifest(base_name, "review", review_manifest) return review_manifest @@ -1472,6 +1679,7 @@ def _run_monitor_zone( context: dict[str, Any], config: dict[str, Any], agents: list[str], + scaffold_only: bool = False, ) -> dict[str, Any]: """执行 Monitor 战区: execution-analyst → knowledge-curator。""" @@ -1581,6 +1789,7 @@ def main() -> None: run_parser.add_argument("--zone", choices=ZONE_ORDER, help="仅运行到指定战区") run_parser.add_argument("--skip-export", action="store_true", help="跳过 Excel 导出") run_parser.add_argument("--skip-xmind", action="store_true", help="跳过 XMind 导出") + run_parser.add_argument("--scaffold-only", action="store_true", help="仅生成脚手架（模板+清单+脚本），AI内容由SKILL.md调用Agent生成") # prepare prepare_parser = subparsers.add_parser("prepare", help="仅准备战区") @@ -1672,6 +1881,7 @@ def main() -> None: build_all_output_dirs(base_name) # 按战区顺序执行 + scaffold_only = getattr(args, 'scaffold_only', False) for zone in zones_to_run: # 检查确认门禁 if zone in ("design", "review") and "analyze" in zones_to_run: @@ -1686,7 +1896,7 @@ def main() -> None: return try: - run_zone(zone, base_name, requirement_path, config) + run_zone(zone, base_name, requirement_path, config, scaffold_only=scaffold_only) except Exception as exc: print(f"\n❌ {zone.upper()} 战区执行失败: {exc}") raise @@ -1700,9 +1910,11 @@ def main() -> None: review_manifest = load_manifest_safe(base_name, "review") if review_manifest: verdict = review_manifest.get("quality_verdict", {}).get("verdict") - if verdict in ("PASS", "PASS_WITH_FIX"): + if verdict in ("PASS", "PASS_WITH_FIX") and not scaffold_only: print(f"\n📦 质量裁决 {verdict}，自动导出 Excel + XMind...") _run_export(requirement_path, skip_xmind=getattr(args, "skip_xmind", False)) + elif verdict == "PENDING_AI": + print(f"\n⏳ 质量裁决 {verdict}，AI 内容生成未完成。请通过 SKILL.md 调用 AI Agent。") else: print(f"\n🛑 质量裁决 {verdict}，跳过导出。请先解决阻断项。") diff --git a/source_docs/requirements_raw/anhuibaba_index.html b/source_docs/requirements_raw/anhuibaba_index.html deleted file mode 100644 index 5d84ca5..0000000 --- a/source_docs/requirements_raw/anhuibaba_index.html +++ /dev/null @@ -1,1113 +0,0 @@ - - - - -安徽运八税务上报平台 - - - -
-

安徽运八税务上报

- -
-
-

上报运单看板

-
-
-

上报运单看板

-
-
⚠️
23
异常运单
-
⏳
12
待申诉
-
🔄
5
申诉中
-
✅
38
已处理
-
-
- - - - - - - -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
货源单号运单号托运单号车牌号司机姓名上报阶段托运方名称核验状态申诉状态异常项货物名称合同金额最新核验时间操作
GH20260710001TCNY0500260370070930012606170930492293197皖A12345张伟第二次上报安徽XX物流有限公司异常未申诉车辆轨迹异常·资金流水重复钢材¥ 3,200.002026-07-06 15:30
GH20260710002TCNY0500260370070930022606170930523344782皖B67890李强第二次上报合肥XX贸易有限公司异常申诉中车辆资质异常煤炭¥ 5,800.002026-07-06 15:28
GH20260710003TCNY0500260370070930032606170930554415893皖C54321王芳第一次上报南京XX供应链有限公司异常申诉成功合同异常粮食¥ 12,400.002026-07-06 15:25
GH20260710004TCNY0500260370070930042606170930585526104皖D98765刘洋已完成安徽XX运业有限公司通过——矿石¥ 8,600.002026-07-06 15:20
GH20260710005TCNY0500260370070930052606170930616637215皖E11111陈明第一次上报合肥XX物流有限公司异常未申诉委托合同异常·运单重复水泥¥ 4,500.002026-07-06 15:15
-
共 23 条，当前第 1~5 条
-
-
-
-

第一次上报（装货完成）

-
-
⏳
6
上传中
-
✅
38
已上传
-
❌
2
上传失败
-
⚠️
3
异常
-
-
- - - -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
货源单号运单号托运单号车牌号司机姓名托运方名称业务类型货物名称装货地址卸货地址运输里程合同编号上报状态操作
GH20260710001TCNY0500260370070930012606170930492293197皖A12345张伟安徽XX物流有限公司普通货运钢材安徽省合肥市xx路xx号江苏省南京市xx路xx号358kmHT20260705001上传中
GH20260710002TCNY0500260370070930022606170930523344782皖B67890李强合肥XX贸易有限公司普通货运煤炭山东省济南市xx路xx号河南省郑州市xx路xx号420kmHT20260705002已上传
GH20260710003TCNY0500260370070930032606170930554415893皖C54321王芳南京XX供应链有限公司冷链运输粮食江苏省南京市xx路xx号浙江省杭州市xx路xx号280kmHT20260705003上传失败
GH20260710004TCNY0500260370070930042606170930585526104皖D98765刘洋安徽XX运业有限公司普通货运矿石安徽省芜湖市xx路xx号江西省南昌市xx路xx号510kmHT20260705004异常
-
共 11 条，当前第 1~4 条
-
-
-
-

第二次上报（打款完成）

-
-
📤
6
待上报
-
✅
38
已上报
-
⚠️
2
异常
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
货源单号运单号托运单号车牌号司机姓名托运方名称承运运费总金额付款方式付款时间收款人收款账号收款账号类型核验状态异常项上报状态操作
GH20260709003TCNY0500260370070920012606090930492293197皖F12345赵六安徽XX物流有限公司¥ 3,200.00¥ 3,500.00银行转账2026-07-06 14:00赵六6222021234567890123个人账户异常车辆轨迹异常待上报
GH20260709004TCNY0500260370070920022606090930523344782皖G67890孙七合肥XX贸易有限公司¥ 5,800.00¥ 6,200.00微信支付2026-07-06 13:30合肥XX贸易有限公司34001623200809123456对公账户通过—已上报
GH20260709005TCNY0500260370070920032606090930554415893皖H54321周八南京XX供应链有限公司¥ 12,400.00¥ 13,000.00银行转账2026-07-06 12:00南京XX供应链有限公司32011523456789012345对公账户异常资金流水异常异常
-
共 9 条，当前第 1~3 条
-
-
-
-

第三次上报（开票完成）

-
-
📤
4
待上报
-
✅
35
已上报
-
⚠️
1
异常
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
货源单号运单号托运单号发票号码发票金额税率销售方名称受票方名称开票日期油气票张数核验状态异常原因上报状态操作
GH20260709004TCNY050026037007092002260609093052334478234002000000012345678¥ 6,200.009%合肥XX贸易有限公司安徽XX物流有限公司2026-07-062通过—已上报
GH20260709005TCNY050026037007092003260609093055441589334002000000012345679¥ 13,000.009%南京XX供应链有限公司安徽XX物流有限公司2026-07-061异常发票信息异常·受票方信息不匹配待上报
GH20260709006TCNY050026037007092004260610093049229319734002000000012345680¥ 8,600.009%安徽XX运业有限公司安徽XX物流有限公司2026-07-070通过—已上报
-
共 5 条，当前第 1~3 条
-
-
-
-

ETC发票上传（税务已抵扣）

-
-
🧾
7
待上传
-
✅
28
已上传
-
⚠️
2
异常
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
货源单号运单号托运单号ETC发票号交易金额入口收费站出口收费站交易时间上传状态操作
GH20260709004TCNY050026037007092002260609093052334478234102000000000123456¥ 158.50皖A站皖B站2026-07-06 18:30已上传
GH20260709005TCNY050026037007092003260609093055441589334102000000000123457¥ 203.00皖C站皖D站2026-07-06 19:00待上传
GH20260709006TCNY050026037007092004260610093049229319734102000000000123458¥ 176.50皖E站皖F站2026-07-07 08:30已上传
-
共 9 条，当前第 1~3 条
-
-
-
-

申诉记录管理

-
-
⏳
12
待省平台反馈
-
🔄
5
反馈处理中
-
✅
38
申诉通过
-
❌
8
申诉驳回
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
运单号托运单号车牌号司机姓名托运方名称上报阶段核验状态异常项申诉状态申诉时间申诉人省平台反馈结果省平台反馈时间操作
TCNY0500260370070930012606170930492293197皖A12345张伟安徽XX物流有限公司第二次上传异常车辆轨迹异常待省平台反馈2026-07-06 16:00管理员待反馈—
TCNY0500260370070930022606170930523344782皖B67890李强合肥XX贸易有限公司第一次上传异常司机资质异常申诉通过2026-07-05 10:30王经理申诉通过2026-07-06 09:15
TCNY0500260370070930032606170930554415893皖C54321王芳南京XX供应链有限公司第一次上传异常合同异常申诉驳回2026-07-04 14:20赵主管申诉驳回2026-07-05 11:00
-
共 63 条，当前第 1~3 条
-
-
-
-

上报日志

-
- - - - - 至 - - -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
序号货源单号运单号托运单号上报阶段上报结果接口URLHTTP状态码响应时间上报时间操作
1GH20260710001TCNY0500260370070930012606170930492293197第一次上报成功https://api.ahyunba.com/v1/firstUpload200230ms2026-07-06 15:30
2GH20260710002TCNY0500260370070930022606170930523344782第二次上报成功https://api.ahyunba.com/v1/secondUpload200312ms2026-07-06 15:28
3GH20260710003TCNY0500260370070930032606170930554415893第一次上报失败https://api.ahyunba.com/v1/firstUpload500超时2026-07-06 15:25
4GH20260710004TCNY0500260370070930042606170930585526104第二次上报成功https://api.ahyunba.com/v1/secondUpload200198ms2026-07-06 15:20
-
共 156 条，当前第 1~4 条
-
-
- -
-
-

第一次上报详情（装货完成）

-
-
📋 建单信息（必选）
-
运单号TCNY050026037007093001
-
货源单号GH20260710001
-
托运单号2606170930492293197
-
业务类型普通货运
-
装货时间2026-07-06 09:00
-
卸货时间2026-07-06 18:00
-
运输里程358km
-
运单金额¥ 3,200.00
-
运费支付方式银行转账
-
运费支付时间2026-07-06 14:00
-
-
👤 托运人信息（必选）
-
托运人名称安徽XX物流有限公司
-
统一社会信用代码91340000XXXXXXXXXX
-
托运人地址安徽省合肥市xx区xx路xx号
-
托运人联系人张经理
-
托运人联系电话138****1234
-
货物名称钢材
-
货物重量(吨)25.5
-
货物体积(方)30.2
-
-
📦 收货方信息（必选）
-
收货方名称江苏XX钢铁有限公司
-
收货方统一社会信用代码91320000XXXXXXXXXX
-
收货方地址江苏省南京市xx区xx路xx号
-
收货方联系人李经理
-
收货方联系电话139****5678
-
卸货地址江苏省南京市xx区xx路xx号
-
收货时间2026-07-06 18:00
-
签收状态已签收
-
-
🚗 司机信息（必选）
-
司机姓名张伟
-
身份证号340***********1234
-
驾驶证号3400********123456
-
联系电话138****8888
-
司机资质状态有效
-
从业资格证号3400********654321
-
-
🚚 接单车辆信息（必选）
-
车牌号皖A12345
-
车辆类型重型半挂车
-
车辆识别代码LVB********123456
-
车辆资质状态有效
-
车辆运输证号交运字第3400XXXXXX
-
车辆所有人安徽XX物流有限公司
-
车辆尺寸(长×宽×高)13.6m×2.5m×1.5m
-
车辆载重(吨)32
-
-
📦 货物信息（必选，可多条）
-
-
货物 #1（共1件）
- - - - - - - - - - - - - - - - - - - - - - - - - -
货物名称钢材货物类型建材
货物重量(吨)25.5货物体积(方)30.2
货物件数120货物单价(元/吨)125.50
包装方式捆装危险货物标志0（否）
-
-
-
🛡️ 保险信息（可选）
-
保单号PY202607060001
-
保险公司名称中国XX财产保险股份有限公司
-
保险类型货物运输险
-
保险金额¥ 500,000.00
-
保险有效期起2026-07-06
-
保险有效期止2026-08-06
-
保单状态有效
-
-
⚠️ 异常信息
-
核验状态异常
-
异常原因车辆资质异常·司机信息不匹配
-
异常时间2026-07-06 15:30
-
处理状态待处理
-
-
-
- -
-
-
- -
-
-

第二次上报详情

-
-
📋 运单信息（必选）
-
运单号TCNY050026037007093002
-
货源单号GH20260709002
-
托运单号2606080930523344782
-
运单状态完成
-
合同编号HT20260705002
-
合同金额¥ 5,800.00
-
业务类型普通货运
-
运单创建时间2026-07-06 10:00
-
装货时间2026-07-06 09:00
-
卸货时间2026-07-06 18:00
-
运输里程420km
-
-
👤 托运方信息（必选）
-
托运方名称合肥XX贸易有限公司
-
统一社会信用代码91340000XXXXXXXXXX
-
托运方地址安徽省合肥市xx区xx路xx号
-
托运方联系人王经理
-
托运方联系电话139****1234
-
货物名称煤炭
-
货物重量(吨)32.0
-
货物体积(方)40.5
-
-
📦 收货方信息（必选）
-
收货方名称山东XX钢铁有限公司
-
收货方统一社会信用代码91370000XXXXXXXXXX
-
收货方地址山东省济南市xx区xx路xx号
-
收货方联系人张经理
-
收货方联系电话138****5678
-
卸货地址山东省济南市xx区xx路xx号
-
收货时间2026-07-06 18:00
-
签收状态已签收
-
-
💰 资金流水信息（必选）
-
支付金额¥ 5,800.00
-
实际支付金额¥ 6,200.00
-
支付方式微信支付
-
支付时间2026-07-06 13:30
-
付款方名称安徽XX物流有限公司
-
收款方名称合肥XX贸易有限公司
-
收款人合肥XX贸易有限公司
-
收款账号34001623200809123456
-
收款账号类型对公账户
-
流水号1000010001202607060000001234
-
支付状态支付成功
-
-
⛽ 油气发票信息（可选，可多条）
-
-
油气发票 #1（共1张）
- - - - - - - - - - - - - - - - - - - -
发票号码34102000000000123456发票代码340020000000
发票金额¥ 580.00税率13%
开票日期2026-07-06发票状态有效
-
- -
⚠️ 异常信息
-
核验状态异常
-
异常原因资金流水异常·收款账号不匹配
-
异常时间2026-07-06 15:30
-
处理状态待处理
-
-
-
-
- -
-
-
- -
-
-

第三次上报详情

-
-
📋 运单信息（必选）
-
运单号TCNY050026037007092003
-
货源单号GH20260709005
-
托运单号2606090930554415893
-
运单状态完成
-
合同编号HT20260705003
-
合同金额¥ 13,000.00
-
业务类型普通货运
-
运单创建时间2026-07-06 10:00
-
装货时间2026-07-06 09:00
-
卸货时间2026-07-06 18:00
-
运输里程280km
-
-
📄 发票信息（必选）
-
发票号码34002000000012345679
-
发票代码340020000000
-
发票金额¥ 13,000.00
-
税率9%
-
开票日期2026-07-06
-
销售方名称南京XX供应链有限公司
-
销售方统一社会信用代码91320000XXXXXXXXXX
-
受票方名称安徽XX物流有限公司
-
受票方统一社会信用代码91340000XXXXXXXXXX
-
发票状态有效
-
-
🛣️ ETC发票信息（可选，可多条）
-
-
ETC发票 #1（共1张）
- - - - - - - - - - - - - - - - - - - - - - - - - -
发票号码34102000000000123457发票代码341020000000
发票金额¥ 203.00税率3%
开票日期2026-07-06发票状态有效
入口收费站皖C站出口收费站皖D站
-
-
-
⚠️ 异常信息
-
核验状态异常
-
异常原因发票信息异常·受票方信息不匹配
-
异常时间2026-07-06 15:30
-
处理状态待处理
-
-
-
- -
-
-
- - - - - -
-
-

运单详情

-
-

此处展示运单的完整字段信息，按上报阶段动态加载对应子对象数据。

-
-
- -
-
-
- - -
-
-

ETC发票上传详情

-
-
📋 运单信息
-
运单号TCNY050026037007092002
-
货源单号GH20260709004
-
托运单号2606090930523344782
-
车牌号皖A12345
-
司机姓名张伟
-
托运方名称安徽XX物流有限公司
-
收货方名称合肥XX贸易有限公司
-
-
🧾 ETC发票信息
-
ETC发票号码34102000000000123456
-
ETC发票代码341020000000
-
交易金额¥ 158.50
-
税率3%
-
发票金额（不含税）¥ 153.88
-
税额¥ 4.62
-
入口收费站皖A站
-
出口收费站皖B站
-
交易时间2026-07-06 18:30
-
发票状态有效
-
-
⚠️ 异常信息
-
核验状态通过
-
异常原因—
-
异常时间—
-
处理状态无需处理
-
-
-
- -
-
-
- - - -
-
-

申诉记录详情

-
-
📤 申诉信息
-
申诉单号AP202607060001
-
上报阶段第二次上传
-
异常项车辆轨迹异常
-
申诉原因车辆实际轨迹与上报轨迹一致，请核实
-
申诉状态待省平台反馈
-
申诉时间2026-07-06 16:00
-
申诉人管理员
-
申诉附件车辆轨迹截图.png
-
-
📋 运单信息
-
运单号TCNY050026037007093001
-
托运单号2606170930492293197
-
车牌号皖A12345
-
司机姓名张伟
-
托运方名称安徽XX物流有限公司
-
-
⚠️ 异常信息
-
核验状态异常
-
异常原因车辆轨迹异常·实际轨迹与上报轨迹不匹配
-
异常时间2026-07-06 15:30
-
-
✅ 省平台反馈信息
-
反馈状态待反馈
-
反馈时间—
-
反馈结果—
-
反馈意见—
-
-
📜 处理记录
-
-
处理记录 #1
-
操作人：管理员
-
操作时间：2026-07-06 16:00
-
操作类型：提交申诉至省平台
-
操作内容：车辆实际轨迹与上报轨迹一致，请核实
-
-
-
- -
-
-
-
- - \ No newline at end of file diff --git a/source_docs/requirements_raw/~$安徽运八需求.docx b/source_docs/requirements_raw/~$安徽运八需求.docx deleted file mode 100644 index 7ed4f51..0000000 Binary files a/source_docs/requirements_raw/~$安徽运八需求.docx and /dev/null differ diff --git a/source_docs/requirements_raw/安徽运八需求.docx b/source_docs/requirements_raw/安徽运八需求.docx index 63433cc..29e8312 100644 Binary files a/source_docs/requirements_raw/安徽运八需求.docx and b/source_docs/requirements_raw/安徽运八需求.docx differ diff --git a/source_docs/requirements_raw/安徽运八需求.md b/source_docs/requirements_raw/安徽运八需求.md new file mode 100644 index 0000000..c8cf57e --- /dev/null +++ b/source_docs/requirements_raw/安徽运八需求.md @@ -0,0 +1,584 @@ +# 安徽运八需求（以API文档为准重构） + +> **重构原则**: API接口文档(网货企业端接口文档 V1.0.2) 为查询+申诉权威数据源，Showdoc文档为上报接口字段定义权威数据源。HTML原型为UI参考，原始需求文档为业务背景补充。 +> **重构时间**: 2026-07-13（最后更新: 2026-07-14，根据14项确认决议） +> **原始需求**: `source_docs/requirements_raw/安徽运八需求.docx` +> **API文档（查询+申诉）**: `E:\Downloads\网货企业端接口文档（最新）.pdf` V1.0.2 (2023-04) +> **Showdoc文档（上报接口·权威字段定义）**: `output/prototype/showdoc文档.md` +> **原型**: `anhuibaba_index.html` + +--- + +## 一、系统边界 + +本需求涉及两套系统的对接： + +| 系统 | 职责 | 本文档覆盖 | +|:---|:---|:---| +| **运八平台（我方）** | 自动触发三阶段上报、ETC上传；查询核验结果；发起/跟踪申诉；查看上报日志 | 全量 | +| **安徽省级网络货运监测系统（省平台）** | 接收上报数据；执行核验；受理申诉并反馈 | 仅接口交互 | + +API文档覆盖的是**运八平台→省平台**的查询和申诉接口。上报触发逻辑（装货完成/打款完成/开票完成自动触发）属于运八平台内部业务逻辑，API文档中未定义上报提交接口。 + +**上报接口（5个·Showdoc权威）** 由Showdoc文档定义，是运八平台向省平台上送数据的接口，与查询+申诉API是两个独立的接口体系： + +| Showdoc上报接口 | URL | 说明 | +|:---|:---|:---| +| 上传委托合同（框架） | `/api/dataUpload/mandateContractFrame` | **前置步骤**：运单第一次上报前必须先上传框架合同 | +| 第一次上传 | `/api/dataUpload/firstUpload` | 装货完成后上报（含waybillInfo, consignorInfo, consigneeInfo, driverInfo, carInfo, goodsInfos, insuranceInformation） | +| 第二次上传 | `/api/dataUpload/secondUpload` | 打款完成后上报（含arrivalInfo, ownerStatements, carrierStatements, carrierContractInfo, ownerContractInfo, trackList） | +| 第三次上传 | `/api/dataUpload/thirdUpload` | 开票完成后上报（含invoice, oilGasInvoices） | +| ETC发票上传 | `/api/dataUpload/etcInvoiceUpload` | 税务抵扣确认后上传（含shippingNoteNumber, vehicleNumber, vehiclePlateColorCode, etcInvoices） | +| 修改第一次上报部分字段 | `/api/dataUpload/updateFirstUploadParam` | 第一次上报成功后更新变化字段 | + +> **关键区分**: Showdoc的5个上报接口 + updateFirstUploadParam 是**数据上报**通道；PDF文档的9个接口是**查询+申诉**通道。两者共同构成运八平台的完整对接方案。 + +--- + +## 二、API接口清单（权威来源：接口文档 V1.0.2） + +### 2.1 通用规范 + +| 项目 | 规范 | +|:---|:---| +| 基地址 | `http://*******/api/` | +| 协议 | HTTP POST | +| 请求格式 | JSON（除上传文件接口外） | +| 响应格式 | `{"code":200, "message":"操作成功", "data":{}}` | +| 认证 | JWT Token，调用 `/sys/login` 获取，除登录接口外均需在请求头携带 | +| 时间格式 | `yyyy-MM-dd HH:mm:ss` | +| 成功码 | `code=200` | +| 失败码 | `code=500` | + +### 2.2 接口一览（共9个） + +| # | 接口 | URL | 说明 | +|:---:|:---|:---|:---| +| 1 | 获取token | `POST /sys/login` | JWT认证，参数: loginName, loginPassword | +| 2 | 上传申诉附件 | `POST /appeal/uploadFile` | 文件上传，参数: file (File) | +| 3 | 提交申诉运单 | `POST /appeal/insert` | 发起申诉，参数: freightSheetNumber, complaintNumber, attachmentUrl, content, verificationAbnormalItems | +| 4 | 查询异常运单信息 | `POST /verificationSummary/page` | 分页查询，支持多维度筛选 | +| 5 | 查询申诉进度 | `POST /appeal/page` | 分页查询申诉记录及审核结果 | +| 6 | 查询运单核验详情 | `POST /verificationSummary/verificationDetail` | 单运单全部核验项明细 | +| 7 | 查询发票是否合规 | `POST /verificationSummary/cargoOwnerInvoiceInfo` | 判断托运人发票系统核验是否合规 | +| 8 | 运单里程核验查询 | `POST /verificationSummary/mileageVerificationInfo` | 批量查询运单里程核验状态 | +| 9 | 运单里程申诉 | `POST /mileageAppeal/insert` | 对里程核验结果发起申诉 | + +### 2.3 接口详细定义 + +#### 接口1: 获取token +``` +POST /sys/login +请求: { "loginName": "xxx", "loginPassword": "xxx" } +响应: { "code": 200, "data": { "token": "...", "expireTime": 1681219619843, "loginName": "ceshi", "name": "测试" } } +``` + +#### 接口2: 上传申诉附件 +``` +POST /appeal/uploadFile +请求: multipart/form-data, 字段 file (File) +``` + +#### 接口3: 提交申诉运单 +``` +POST /appeal/insert +请求: + freightSheetNumber String 运单号 必填 + complaintNumber String 申诉编号 必填 + attachmentUrl String 申诉附件URL 必填 + content String 申诉内容 必填 + verificationAbnormalItems String 核验异常项ID 必填 (逗号分隔，如"120,160") +``` + +#### 接口4: 查询异常运单信息 +``` +POST /verificationSummary/page +请求: + pageIndex int 页码 必填 + pageSize int 每页条数 必填 + freightSheetNumber String 运单号 可选 + verificationAbnormalItems String 异常项ID 可选 (多个逗号拼接) + driverName String 驾驶员姓名 可选 + driverIdCard String 驾驶员身份证号 可选 + vehicleNumber String 车牌号 可选 + appealStateId int 申诉状态ID 可选 + verifyStateId int 核验状态ID 可选 + beginTime ~ endTime 运单创建时间范围 可选 + beginFirstVerifyTime ~ endFirstVerifyTime 首次核验时间范围 可选 + beginLastVerifyTime ~ endLastVerifyTime 最新核验时间范围 可选 + beginInsertTime ~ endInsertTime 插入时间范围 可选 + +响应: + pageRecords[]: + freightSheetNumber String 运单号 + appealStateId int 申诉状态ID + appealStateName String 申诉状态名称 + verificationAbnormalItem String 核验异常项 + createTime date 运单创建时间 + lastVerifyTime date 最新核验时间 + firstVerifyTime date 首次核验时间 + vehicleNumber String 车牌号 + driverName String 驾驶员姓名 + driverIdCard String 驾驶员身份证号 + verifyStateId int 核验状态ID + verifyStateName String 核验状态名称 + abnormalDetails[]: + id int 异常项ID + name String 异常项名称 + message String 异常原因 + time date 异常时间 + state int 异常项处理状态 (100=未申诉, 110=申诉中) +``` + +#### 接口5: 查询申诉进度 +``` +POST /appeal/page +请求: + pageIndex int 页码 必填 + pageSize int 每页条数 必填 + freightSheetNumber String 运单号 可选 + abnormalTypeId String 核验异常项ID 可选 + auditStateId String 审核状态ID 可选 + beginTime ~ endTime 申诉时间范围 可选 + auditBeginTime ~ auditEndTime 审核时间范围 可选 + complaintNumber String 申诉编号 可选 + +响应: + pageRecords[]: + complaintNumber String 申诉编号 + freightSheetNumber String 运单号 + content String 申诉内容 + complainantName String 申诉人 + auditStateId int 审核状态ID + auditStateName String 审核状态名称 + auditorName String 审核人 + auditRemark String 审核备注 + auditTime date 审核时间 + verificationAbnormalItem String 运单异常项 + cancelPerson String 取消人 + cancelReason String 取消原因 + cancelTime date 取消时间 + revokeUserName String 撤回人 + revokeTime date 撤回时间 + createTime date 创建时间 + appealAbnormalList[]: + verificationTypeId int 异常项ID + verificationTypeName String 异常项名称 +``` + +#### 接口6: 查询运单核验详情 +``` +POST /verificationSummary/verificationDetail +请求: + freightSheetNumber String 运单号 必填 + beginInsertTime String 插入时间-开始 可选 + endInsertTime String 插入时间-结束 可选 + +响应: + pageRecords[].details[]: + verificationCode int 核验项编码 + verificationName String 核验项名称 + verificationState String 核验状态 + verificationStateId int 核验状态ID + verificationTime date 核验时间 + message String 核验信息 +``` + +#### 接口7: 查询发票是否合规 +``` +POST /verificationSummary/cargoOwnerInvoiceInfo +请求: { "freightSheetNumber": "55141359" } +响应: { "isSystemVerification": true } // true=系统核验合规, false=人工判定合规 +``` + +#### 接口8: 运单里程核验查询 +``` +POST /verificationSummary/mileageVerificationInfo +请求: { "freightSheetNumberList": ["22222222", "111111"] } +响应: [ + { "verificationStateId": 110, "freightSheetNumber": "22222222", "mileage": 350.263 }, + { "verificationStateId": null, "freightSheetNumber": "4658151", "mileage": null } +] +// 注: 运单未上报里程时 verificationStateId 和 mileage 为 null +``` + +#### 接口9: 运单里程申诉 +``` +POST /mileageAppeal/insert +请求: + freightSheetNumber String 运单号 必填 + content String 申诉内容 必填 + complaintNumber String 申诉编号 必填 + mileage String 里程数 必填 +``` + +--- + +## 三、数据字典（权威来源：接口文档 §4.1~§4.5） + +### 3.1 异常项ID对照表（§4.1）— 共17项 + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 委托合同 | 托运人与承运人签订的委托运输合同核验 | +| 120 | 承运合同 | 承运人以自身名义签订的运输合同核验 | +| 130 | 实时定位 | 车辆实时定位数据核验 | +| 140 | 运单时间逻辑 | 运单各时间节点的逻辑合理性核验（如装货时间<卸货时间） | +| 150 | 车辆资质 | 车辆道路运输经营许可证有效性核验 | +| 160 | 道路运输证 | 车辆道路运输证有效期核验 | +| 170 | 驾驶证 | 驾驶员驾驶证有效性核验 | +| 180 | 从业资格证 | 驾驶员从业资格证有效期核验 | +| 190 | 车辆重复 | 同一车辆在同一时段是否存在多运单 | +| 200 | 司机重复 | 同一司机在同一时段是否存在多运单 | +| 210 | 车辆轨迹 | GPS轨迹真实性、与运单路线匹配度核验 | +| 220 | 运费收款 | 运单是否在运费收款方名下 | +| 230 | 公司统一收款 | 是否通过公司账户统一收款 | +| 240 | 集中支付 | 是否通过网络货运平台集中支付 | +| 250 | 资金流水 | 资金流水单号唯一性、金额匹配核验 | +| 260 | 发票信息 | 托运人发票信息核验（第三次上报相关） | +| 270 | 非通行车辆可开票 | 非通行车辆是否允许开具通行费发票 | + +### 3.2 运单核验状态（§4.2） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未核验 | 运单尚未被省平台核验 | +| 110 | 核验通过 | 全部核验项通过 | +| 120 | 全部异常 | 存在核验不通过的异常项 | + +### 3.3 运单部分核验状态（§4.3） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未核验 | 尚未核验 | +| 110 | 部分核验 | 部分核验项已通过，仍有待核验项 | +| 120 | 全部核验 | 全部核验项已出结果 | + +### 3.4 运单申诉状态（§4.4）— 权威枚举 + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| **100** | **未申诉** | 尚未发起申诉 | +| **110** | **审核通过** | 省平台审核通过 | +| **120** | **审核不通过** | 省平台审核驳回 | +| **130** | **已取消** | 省平台侧操作，我方只读（申诉由省平台取消，非我方可操作状态） | + +> **已取消(130)说明**: 状态130=已取消是**省平台侧直接操作**产生的状态，我方系统不提供"取消申诉"功能。运八平台只能查询到此状态，不能主动将申诉状态设为130。我方申诉状态流转不包含取消操作。 + +### 3.5 附件状态（§4.5） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未处理 | 申诉附件尚未被省平台处理 | +| 110 | 处理通过 | 附件核验通过 | +| 120 | 处理异常 | 附件核验异常 | + +--- + +## 四、功能模块（综合API文档+原型+原始需求） + +### 4.1 上报运单看板 + +**入口**: 侧边栏 → 上报运单看板 + +**统计卡片**（原型定义）: +- 异常运单数、待申诉数、申诉中数、已处理数 + +**查询条件**（综合原型+接口4请求参数）: + +| 筛选项 | 类型 | 可选值 | +|:---|:---|:---| +| 运单号/托运单号/货源单号 | 文本输入 | 模糊搜索 | +| 上报阶段 | 下拉 | 全部 / 第一次上报 / 第二次上报 / 第三次上报 | +| 核验状态 | 下拉 | 全部 / 异常 / 通过 | +| 申诉状态 | 下拉 | 全部 / 未申诉(100) / 审核通过(110) / 审核不通过(120) / 已取消(130·省平台只读) | + +**列表字段**（原型为准，15列含勾选）: +货源单号 / 运单号 / 托运单号 / 车牌号 / 司机姓名 / 上报阶段 / 托运方名称 / 核验状态 / 申诉状态 / 异常项 / 货物名称 / 合同金额 / 最新核验时间 / 操作 + +**操作按钮**: +- 异常运单: [申诉] [详情] +- 申诉中运单: [进度] [详情] +- 正常运单: [详情] + +**标签颜色**（原型CSS定义）: +- 蓝色 `.tag-blue`: 上传中、申诉中 +- 绿色 `.tag-green`: 已上传、通过、已完成、申诉通过、对公账户 +- 红色 `.tag-red`: 上传失败、异常、申诉驳回 +- 橙色 `.tag-orange`: 异常项标签、待上报 +- 灰色 `.tag-gray`: 未申诉 +- 紫色 `.tag-purple`: (预留) + +### 4.2 委托合同上传（前置步骤·Showdoc权威） + +**来源**: Showdoc接口 `POST /api/dataUpload/mandateContractFrame` + +**时机**: 在进行运单的第一次上报前，需先将委托合同（框架）通过此接口上传至省平台。 + +**说明**: +- 委托合同（框架）和委托合同**二选一**上报 +- 文件信息可暂时不传，在修改委托合同时再补充合同文件 +- 后续合同有新增或修改，再调用上传或修改接口即可 +- 目前省平台不支持单独查询合同，可在运单第一次上报后，在运单信息中查看合同 + +**核心字段**: +| 参数 | 必选 | 说明 | +|:---|:---|:---| +| contract_number | 是 | 合同编号 | +| expire_time | 是 | 合同有效期截止时间 yyyy-MM-dd | +| unified_social_credit_identifier | 可选 | 单托运企业统一社会信用代码 | +| owner_enterprise_name | 可选 | 单托运企业名称 | +| enterpriseList | 可选 | 多托运企业列表（与单托运企业互斥，都传值默认取单） | +| uploadFileInfo | 否 | 文件信息（name / url / dataList三选一） | + +### 4.3 第一次上报（装货完成） + +**触发条件**: 运单装货完成 AND 货源税源地=安徽 + +**上报数据子对象**（以接口文档字段定义为准）: + +| 子对象 | 必选/可选 | 核心字段（Showdoc权威定义） | +|:---|:---|:---| +| waybillInfo（建单信息） | 必选 | originalDocumentNumber, shippingNoteNumber, documentCreateTime(yyyyMMddHHmmss), carrier, unifiedSocialCreditIdentifier, permitNumber, businessTypeCode, goodsArrangementTypeCode, orderReceivingTime(yyyyMMddHHmmss), departureTime(yyyyMMddHHmmss), commercialContractNumber, contractNumber(可选), mileage(可选·3位小数) | +| consignorInfo（托运人信息） | 必选 | consignor, consignorId, frameContractNumber(可选), placeOfLoading, loadingLongitude(6位小数), loadingLatitude(6位小数), loadingCountrySubdivisionCode | +| consigneeInfo（收货方信息·6字段） | 必选 | consignee, consigneeId, goodsReceiptPlace, unLoadingLongitude(6位小数), unLoadingLatitude(6位小数), unLoadingNationSubdivisionCode | +| driverInfo（司机信息·15字段） | 必选 | driverName, telephone, drivingIdNumber, drivingLicense, vehicleClass, issuingOrganizations, validPeriodFrom(yyyyMMdd), validPeriodTo(yyyyMMdd), qualificationCertificate, provinceCode, qualificationCertificateFrom(可选), qualificationCertificateTo(可选), taxRegistrationCertificate(可选), registerDate(yyyyMMdd), anchoredUrl(可选·文件列表) | +| carInfo（车辆信息·20字段） | 必选 | vehicleNumber, vehiclePlateColorCode, vehicleType, LicensePlateTypeCode, owner, ownerId(可选), useCharacter, vin, issuingOrganizations, registerDate(yyyyMMdd), issueDate(yyyyMMdd), vehicleEnergyType, vehicleTonnage(Double), grossMass(Double), roadTransportCertificateNumber, trailerVehiclePlateNumber(可选), vehicleLicenseNumber(可选), roadTransportSocialCreditFrom(可选·yyyyMMdd), roadTransportSocialCreditTo(可选·yyyyMMdd), anchoredUrl(可选·文件列表) | +| goodsInfos（货物信息） | 必选，可多条 | descriptionOfGoods, cargoTypeClassificationCode, quantity(Double), unit | +| insuranceInformation（保险信息） | 可选 | policyNumber, insuranceCompany | + +**业务规则**: +- 仅安徽税源地(省份代码=34，非28)运单触发 +- 上报成功后自动调用"修改第一次上报部分字段"接口更新变化字段 +- 失败自动重试最多3次，全部失败后站内信通知运营 +- 第一次上报是后续上报的前置条件（后端校验） + +**列表页**（原型为准，14列+勾选）: +货源单号 / 运单号 / 托运单号 / 车牌号 / 司机姓名 / 托运方名称 / 业务类型 / 货物名称 / 装货地址 / 卸货地址 / 运输里程 / 合同编号 / 上报状态 / 操作 + +**上报状态**（内部系统状态，非API枚举）: +- 上传中（蓝色） +- 已上传（绿色） +- 上传失败（红色）— 显示"手动上传"按钮 +- 异常（橙色） + +### 4.4 第二次上报（打款完成） + +**触发条件**: 财务打款完成 AND 第一次上报已完成 + +**核验项**: 省平台自动核验，共17项（见§3.1）。每项独立产生核验结果，核验异常项可通过申诉机制逐项申诉。 + +**上报数据子对象**（Showdoc权威·第二次上传结构完全不同）: +| 子对象 | 必选/可选 | 核心字段 | +|:---|:---|:---| +| arrivalInfo（运抵信息） | 必选 | shippingNoteNumber, startTicketFileUrl(文件列表), arrivalTime(yyyyMMddHHmmss), arrivalTicketFileUrl(文件列表), waybillFreightAmount(Double·3位小数·承运运费), totalMonetaryAmount(Double·3位小数·委托运费) | +| ownerStatements（货主流水） | 必选 | documentNumber, carrier, actualCarrierId, paymentMeansCode, paymentName, paymentAccount, paymentBankName(选填), recipient, receiptAccount, receiptBankName(选填), sequenceCode, monetaryAmount(Double·3位小数), appointmentTime(yyyyMMdd), payTime(yyyyMMddHHmmss) | +| carrierStatements（承运人流水） | 必选 | documentNumber, carrier, actualCarrierId, paymentMeansCode, paymentName, paymentAccount, paymentBankName, recipient, receiptIdCard, receiptAccount, receiptBankName, sequenceCode, monetaryAmount(String·3位小数), appointmentTime(yyyyMMdd), payTime(yyyyMMddHHmmss), oilCardAmount(选填·3位小数), replaceAgreementFiles(可选·代收协议文件) | +| carrierContractInfo（承运合同） | 必选 | contractBusinessName, contractNumber, partyAName, partyAId, partyBName, partyBId, contractedCarryingCapacity(Double·3位小数), unit, contractAmount(Double·3位小数), agreedBusinessCompletionTime(yyyyMMdd), promisePayTime(yyyyMMdd), partyBReceiptName, partyBAccount, bankName(否), placeOfLoading, goodsReceiptPlace, descriptionOfGoods, vehicleNumber, contractSigningTime(yyyyMMddHHmmss), contractUrl(文件列表) | +| ownerContractInfo（委托合同） | 可选 | 18字段（委托合同与框架合同二选一上报） | +| trackList（车辆轨迹） | 必选，2~2000点 | locationMethod(BD/LBS/WECHAT/APP), locationTime(yyyyMMddHHmmss), locationAddress, longitude(6位小数), latitude(6位小数), trackType(LOADING/UNLOADING/NORMAL·可选) | + +**列表页**（原型为准，17列+勾选）: +货源单号 / 运单号 / 托运单号 / 车牌号 / 司机姓名 / 托运方名称 / 承运运费 / 总金额 / 付款方式 / 付款时间 / 收款人 / 收款账号 / 收款账号类型 / 核验状态 / 异常项 / 上报状态 / 操作 + +**收款账号类型标签**: 个人账户=蓝色, 对公账户=绿色 + +### 4.5 第三次上报（开票完成） + +**触发条件**: 发票开具完成 AND 第二次上报已完成 + +**前置条件**: 第二次上报必须完成（后端校验） + +**API关联接口**: +- `POST /verificationSummary/cargoOwnerInvoiceInfo` — 查询托运人发票系统核验是否合规 +- 响应: `isSystemVerification`: true=系统核验合规, false=人工判定合规 + +**列表页**（原型为准，15列+勾选）: +货源单号 / 运单号 / 托运单号 / 发票号码 / 发票金额 / 税率 / 销售方名称 / 受票方名称 / 开票日期 / 油气票张数 / 核验状态 / 异常原因 / 上报状态 / 操作 + +### 4.6 ETC发票上传 + +**触发条件**: ETC发票税务抵扣成功后，由运营人员在运八系统**手动确认抵扣完成**，确认后系统触发ETC发票上传（非自动触发） + +**列表页**（原型为准，10列+勾选）: +货源单号 / 运单号 / 托运单号 / ETC发票号 / 交易金额 / 入口收费站 / 出口收费站 / 交易时间 / 上传状态 / 操作 + +**详情弹窗字段**（原型为准）: +- 运单信息: 运单号、货源单号、托运单号、车牌号、司机姓名、托运方名称、收货方名称 +- ETC发票信息: ETC发票号码、ETC发票代码、交易金额、税率(3%)、发票金额(不含税)、税额、入口收费站、出口收费站、交易时间、发票状态 + +### 4.7 异常申诉功能 + +**关联API接口**: +- `POST /appeal/uploadFile` — 上传申诉附件 +- `POST /appeal/insert` — 提交申诉 +- `POST /appeal/page` — 查询申诉进度 +- `POST /mileageAppeal/insert` — 里程申诉（独立接口） + +**申诉流程**（闭环）: +``` +异常运单查询(接口4) → 发起申诉(接口3) → 省平台复核 → +查询申诉进度(接口5) → 审核通过(110) | 审核不通过(120) → +重新申诉(接口3) [审核不通过时] +``` + +**申诉状态流转**（以API §4.4为准，我方可控流转）: +``` +未申诉(100) → 提交申诉 → 未申诉(100) [申诉中·abnormalDetails.state=110] +未申诉(100) → 省平台审核通过 → 审核通过(110) [终态] +未申诉(100) → 省平台审核驳回 → 审核不通过(120) → 重新申诉 → 未申诉(100) [新申诉单] +``` + +> **已取消(130)**: 此状态由省平台侧操作产生（如省平台管理员取消申诉），我方系统不提供触发入口，仅被动查询和展示。因此不纳入我方申诉状态流转中。 + +**列表页**（原型为准，14列+勾选）: +运单号 / 托运单号 / 车牌号 / 司机姓名 / 托运方名称 / 上报阶段 / 核验状态 / 异常项 / 申诉状态 / 申诉时间 / 申诉人 / 省平台反馈结果 / 省平台反馈时间 / 操作 + +**详情弹窗分组**（原型为准）: +- 申诉信息: 申诉单号、上报阶段、异常项、申诉原因、申诉状态、申诉时间、申诉人、申诉附件 +- 运单信息: 运单号、托运单号、车牌号、司机姓名、托运方名称 +- 异常信息: 核验状态、异常原因、异常时间 +- 省平台反馈信息: 反馈状态、反馈时间、反馈结果、反馈意见 +- 处理记录（时间线）: 操作人、操作时间、操作类型、操作内容 + +### 4.8 上报日志 + +**查询条件**（原型为准）: +- 运单号/托运单号/货源单号: 模糊搜索 +- 上报阶段: 全部 / 第一次上报 / 第二次上报 / 第三次上报 / ETC上传 +- 上报结果: 全部 / 成功 / 失败 +- 时间范围: 开始时间 ~ 结束时间 + +**列表字段**（原型为准，11列）: +序号 / 货源单号 / 运单号 / 托运单号 / 上报阶段 / 上报结果 / 接口URL / HTTP状态码 / 响应时间 / 上报时间 / 操作 + +**日志详情弹窗**: 展示完整请求报文（URL/Method/Headers/Body）和响应报文（StatusCode/Headers/Body），JSON格式化展示，支持一键复制。 + +--- + +## 五、状态枚举汇总（以API文档为权威） + +### 5.1 申诉状态（API §4.4 权威） + +| Code | 名称 | 原始需求对应 | 我方可操作 | 说明 | +|:---:|:---|:---|:---:|:---| +| 100 | 未申诉 | 未申诉 + 申诉中 | 是 | 含已提交但省平台尚未审核的情况（申诉中通过 abnormalDetails[].state=110 标识） | +| 110 | 审核通过 | 申诉通过 | 否（终态） | 省平台审核通过 | +| 120 | 审核不通过 | 申诉驳回 | 否（可重新申诉） | 省平台审核驳回，可重新发起申诉 | +| 130 | 已取消 | （无） | **否·省平台只读** | 省平台侧操作取消，我方仅查询展示 | + +### 5.2 核验状态（API §4.2 权威） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未核验 | 运单尚未核验 | +| 110 | 核验通过 | 全部17项核验通过 | +| 120 | 全部异常 | 存在核验异常项 | + +### 5.3 异常项处理状态（API §4.1 子字段） + +| Code | 名称 | 说明 | +|:---:|:---|:---| +| 100 | 未申诉 | 该异常项尚未发起申诉 | +| 110 | 申诉中 | 该异常项已提交申诉，待审核 | + +### 5.4 上报状态（内部系统状态，非API枚举） + +| 状态 | 标签颜色 | 说明 | +|:---|:---|:---| +| 上传中 | 蓝色 | 数据正在上报中 | +| 已上传 | 绿色 | 上报成功 | +| 上传失败 | 红色 | 上报超时或错误，显示"手动上传"按钮 | +| 异常 | 橙色 | 数据校验不通过 | + +--- + +## 六、与原始需求的关键差异 + +| # | 项目 | 原始需求 | API/Showdoc（权威） | 影响 | +|:---:|:---|:---|:---|:---| +| 1 | 核验项数量 | 7类 | **17项** (API §4.1) | 测试覆盖需从14条扩展到34条 | +| 2 | 申诉状态 | 未申诉/申诉中/通过/驳回 | **未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130·省平台只读)** | 申诉状态枚举全部更新，130不纳入我方流转 | +| 3 | 申诉"进行中" | 独立状态"申诉中" | 归属于"未申诉(100)"，由abnormalDetails[].state=110标识 | 状态机变更 | +| 4 | 已取消状态 | 无 | **130=已取消·省平台操作·我方只读** | 不提供"取消申诉"按钮，仅查询展示 | +| 5 | 里程申诉 | 无 | **独立接口** `/mileageAppeal/insert` | 新增功能模块 | +| 6 | 发票合规查询 | 无 | **独立接口** `/verificationSummary/cargoOwnerInvoiceInfo` | 新增功能点 | +| 7 | 核验状态 | 通过/异常（二元） | 未核验(100)/通过(110)/全部异常(120) | 新增"未核验"初始状态 | +| 8 | 附件状态 | 无 | 未处理(100)/处理通过(110)/处理异常(120) | 新增枚举 | +| 9 | 委托合同上传 | 无 | Showdoc **mandateContractFrame** 接口 | 新增前置步骤：第一次上报前必须先上传框架合同 | +| 10 | ETC触发方式 | 税务抵扣完成（自动） | **人工手动确认抵扣完成后触发** | 需要运营人员在运八系统手动确认 | +| 11 | 金额精度 | 2位小数 | **第二次上报金额3位小数**（Showdoc） | 金额存储和校验精度变更 | +| 12 | 时间格式 | `yyyy-MM-dd HH:mm:ss` | **上报接口用 `yyyyMMddHHmmss`（14位）**（Showdoc） | 上报数据格式化逻辑变更 | +| 13 | ETC invoiceAmount | 总金额 | **不含税金额**（Showdoc） | ETC发票金额语义变更 | + +--- + +## 七、上报接口文档参考（Showdoc · 权威字段定义） + +### 7.0 Showdoc通用规范 + +| 项目 | 规范 | +|:---|:---| +| 认证方式 | MD5签名Token（请求体JSON字符串+密钥 → MD5加密），非JWT | +| 请求格式 | `{"partnerId":"xxx", "appId":"xxx", "workerId":"001", "args":{...}}` | +| 成功码 | `code=200` | +| 失败码 | `code=500` | +| 时间戳 | 13位毫秒时间戳 | + +> ⚠️ **关键差异**: Showdoc上报接口使用MD5签名Token，而查询+申诉API（PDF文档）使用JWT Token。两套认证体系独立。 + +### 7.1 字段精度关键差异（Showdoc vs 原始需求） + +以下是从Showdoc文档中发现的与原始需求/原型不一致的关键字段定义： + +| # | 字段相关 | 原始需求/原型假设 | Showdoc权威定义 | +|:---:|:---|:---|:---| +| 1 | **金额精度** | 保留2位小数 | **第二次上报金额保留3位小数**（arrivalInfo.waybillFreightAmount、totalMonetaryAmount、carrierStatements.monetaryAmount、ownerStatements.monetaryAmount、carrierContractInfo.contractAmount、contractedCarryingCapacity等均保留3位小数，如整数以.000填充） | +| 2 | **时间格式** | `yyyy-MM-dd HH:mm:ss` | **上报接口时间格式为 `yyyyMMddHHmmss`（14位）**（如documentCreateTime、orderReceivingTime、departureTime），日期字段用 `yyyyMMdd`（8位） | +| 3 | **第一次上报字段数** | consigneeInfo=5字段、driverInfo=13字段、carInfo=19字段 | Showdoc: consigneeInfo=6字段（含unLoadingNationSubdivisionCode）、driverInfo=15字段（含registerDate、anchoredUrl）、carInfo=20字段（含anchoredUrl）、goodsInfos.quantity=Double | +| 4 | **第二次上报结构** | 追加资金流水+轨迹 | Showdoc定义完全不同：arrivalInfo(含startTicketFileUrl+arrivalTicketFileUrl)+ownerStatements+carrierStatements+carrierContractInfo+ownerContractInfo(可选)+trackList；carrierStatements含oilCardAmount和replaceAgreementFiles | +| 5 | **第三次上报** | 发票17字段 | Showdoc: invoice明确17字段+invoiceUrl文件；oilGasInvoices选填 | +| 6 | **ETC发票** | invoiceAmount=发票总金额 | **invoiceAmount = 不含税金额**（not总金额!）；17个etcInvoices字段；税率格式x.x%（如3%） | +| 7 | **委托合同上传** | 未提及 | Showdoc有 `mandateContractFrame` 接口 — 之前完全遗漏！委托合同（框架）和委托合同二选一上报 | + +### 7.2 Showdoc FAQ 关键摘录 + +以下FAQ影响功能设计和测试用例设计： + +| 主题 | FAQ要点 | +|:---|:---| +| **运单不可取消/删除** | 服务平台不支持取消或删除运单，上传后不允许修改任何信息。建议企业在运单信息确认后再上传。 | +| **承运人流水核验时效** | 除承运人流水核验需等待次日银行提供数据后开始核验，其余核验项会在一至两小时内核验完成。 | +| **发票红冲流程** | 货主发票开具后需红冲：在服务平台企业端将货主发票作废，再将重新开具的发票通过第三次上传接口上传。 | +| **税率统一3%** | 承运人流水中的税率统一传3%，税额按3%计算。 | +| **油卡金额** | 在上传承运人流水时据实填写油卡金额（oilCardAmount），如一条运单存在多条承运人流水，可在任一承运人流水中填写。 | +| **委托合同（框架）上传时机** | 在进行运单第一次上报前需将框架合同通过接口上传至服务平台，后续合同有新增或修改再调用上传/修改接口。 | +| **轨迹点数** | 企业上传的轨迹点数需在2-2000之间。地址字段若无，传"-"。 | +| **核验结果查看** | 两种方式：①服务平台企业端查询；②对接服务平台异常查询接口实现在企业自有系统内查询、处理。 | +| **合规运单开票** | 运单必须上传至服务平台且核验通过后才允许开具货主发票；第二次上传完成后即可查看核验结果。 | + +--- + +## 八、待确认项（14项 → 已确认14项 ✅） + +> **更新 2026-07-14**: 以下14项已全部通过用户确认决议。方框标记为确认结果。 + +### 阻塞级（已确认） +1. ✅ **核验项展示**: API 17项核验全部展示，每项可独立申诉。analysis文档已明确。 +2. ✅ **上报接口字段定义**: Showdoc文档为权威数据源。Showdoc定义5个上报接口 + updateFirstUploadParam，与PDF的9个查询+申诉接口分离。 + +### 重要级（已确认） +3. ✅ **申诉状态"已取消(130)"**: 省平台侧操作，我方只读，不提供"取消申诉"按钮。运单不可取消/删除。 +4. ✅ **原型UI状态映射**: "待省平台反馈"和"反馈处理中"为UI层面的展示状态，对应API 未申诉(100)·申诉中。 +5. ✅ **第三次上报列表字段**: 以原型15列为准。 +6. ✅ **里程申诉与通用申诉**: 独立接口 `/mileageAppeal/insert`，与 `/appeal/insert` 分离。 +7. ✅ **发票合规查询**: 独立接口 `/cargoOwnerInvoiceInfo`，独立于申诉流程。 + +### 参考级（已确认） +8. ✅ **自动重试间隔**: 当前方案5s/15s/30s合理可用。 +9. ✅ **ETC税额**: 税率固定3%，税额按3%计算。 +10. ✅ **申诉超时告警**: 7个工作日阈值可用。 +11. ✅ **省份代码**: 安徽=34，与API文档一致。 +12. ✅ **第二次上报详情弹窗缺失轨迹**: 确认为原原型Bug，增强版原型已包含轨迹表格。 +13. ✅ **原型详情弹窗字段**: 以接口Showdoc定义为准。 +14. ✅ **ETC触发条件**: ETC发票税务抵扣成功后，由运营人员在运八系统**手动确认抵扣完成**，确认后系统触发ETC发票上传（非自动触发）。