feat: 安徽运八需求全流水线输出同步 + 知识库/agents/资源文件更新
This commit is contained in:
xst
@@ -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` |
|
||||
|
||||
@@ -1,6 +0,0 @@
|
||||
{
|
||||
"base_name": "安徽运八需求",
|
||||
"version": "v1",
|
||||
"snapshot_type": "partial_snapshot",
|
||||
"summary": []
|
||||
}
|
||||
@@ -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"
|
||||
}
|
||||
@@ -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 | 上报接口超时或不可用影响业务流程，需重试+告警兜底 |
|
||||
@@ -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%
|
||||
@@ -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.输入`<script>alert(1)</script>`点查询 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)
|
||||
Binary file not shown.
+5
-4
@@ -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"
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"base_name": "安徽运八需求",
|
||||
"version": "v2",
|
||||
"version": "v3",
|
||||
"snapshot_type": "full_pipeline",
|
||||
"summary": [
|
||||
"manifest",
|
||||
@@ -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"
|
||||
}
|
||||
+1
-3
@@ -10,9 +10,7 @@
|
||||
- 未识别到同主题技术方案文档。
|
||||
|
||||
## 关联需求识别
|
||||
| 序号 | 关联需求 | 相似度 |
|
||||
| :--- | :--- | :--- |
|
||||
| 1 | `source_docs\requirements_raw\网货企业端接口文档（最新）.pdf` | 0.0696 |
|
||||
- 未识别到相似度达到阈值的历史需求文档。
|
||||
|
||||
## 潜在冲突与修改建议
|
||||
- 暂未识别到明显冲突条目。建议在需求评审时继续人工确认。
|
||||
@@ -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（云企付二期）
|
||||
File diff suppressed because it is too large
Load Diff
@@ -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工具支持。
|
||||
Binary file not shown.
@@ -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"
|
||||
@@ -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上传触发条件"税务抵扣完成"由哪个系统事件触发
|
||||
@@ -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"
|
||||
]
|
||||
}
|
||||
@@ -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"
|
||||
}
|
||||
@@ -0,0 +1,16 @@
|
||||
# 安徽运八需求 关联需求与冲突检查
|
||||
|
||||
## 目标需求
|
||||
- `source_docs\requirements_raw\安徽运八需求.docx`
|
||||
|
||||
## 项目画像
|
||||
- `knowledge_base\00_project\project_profile.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（云企付二期）
|
||||
File diff suppressed because it is too large
Load Diff
@@ -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工具支持。
|
||||
Binary file not shown.
@@ -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"
|
||||
@@ -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发票上传（非自动触发）。
|
||||
@@ -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"
|
||||
]
|
||||
}
|
||||
@@ -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"
|
||||
}
|
||||
@@ -0,0 +1,16 @@
|
||||
# 安徽运八需求 关联需求与冲突检查
|
||||
|
||||
## 目标需求
|
||||
- `source_docs\requirements_raw\安徽运八需求.docx`
|
||||
|
||||
## 项目画像
|
||||
- `knowledge_base\00_project\project_profile.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（云企付二期）
|
||||
File diff suppressed because it is too large
Load Diff
@@ -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工具支持。
|
||||
Binary file not shown.
Reference in New Issue
Block a user