QaAutomationHub/output/test_points/安徽运八需求_测试点.md

安徽运八需求 测试点

生成时间: 2026-07-13 需求文档: output/normalized_inputs/安徽运八需求/requirement.md 关联分析: 风险评估报告 / 测试策略 / 关联与冲突

测试点概览

• 总测试点数: 140
• P0: 33 / P1: 71 / P2: 30 / P3: 6
• 模块分布: A(看板)=14, B(第一次上报)=22, C(第二次上报)=51, D(第三次上报)=12, E(ETC)=9, F(申诉)=16, G(日志)=9, X(跨模块)=7
• 来源分布: [需求] 66, [历史缺陷] 14, [风险矩阵] 8, [漏测清单] 52, [项目画像] 16, [最佳实践] 7, [技术方案] 36

注: 一个测试点可同时归属多个来源，因此来源分布合计数 > 总测试点数。

---

模块A: 上报运单看板 (14个测试点)

TP-A-001: 看板模糊搜索 — 运单号/托运单号/货源单号

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求]
• 描述: 验证看板支持按运单号、托运单号、货源单号进行模糊搜索，输入部分字符即可匹配相关运单。
• 关键验证点: 输入完整单号可精确匹配；输入部分字符可模糊匹配；输入不存在的单号显示空结果提示；三种单号输入框均支持模糊搜索。

TP-A-002: 看板按上报阶段筛选

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求]
• 描述: 验证看板支持按"全部/第一次上报/第二次上报/第三次上报"筛选，切换阶段后列表数据正确过滤。
• 关键验证点: 默认"全部"显示所有阶段运单；选择"第一次上报"仅显示对应阶段运单；切换阶段后列表即时刷新；各阶段数据条数与实际一致。

TP-A-003: 看板按核验状态筛选

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求][漏测清单]
• 描述: 验证看板支持按"全部/异常/通过"筛选核验状态，确保状态拆分独立验证。
• 关键验证点: "全部"显示所有核验状态运单；"异常"仅显示核验不通过的运单；"通过"仅显示核验通过的运单；列表中核验状态字段与筛选条件一致。

TP-A-004: 看板按申诉状态筛选

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求][漏测清单]
• 描述: 验证看板支持按"全部/未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130)"筛选申诉状态。注：已取消(130)由省平台外部操作设置，我方系统只读展示，不发起取消操作。⚠️ 待确认: 原型看板申诉状态下拉值为"未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回"，与API权威枚举不一致，需确认UI最终版本。
• 关键验证点: 四种申诉状态独立筛选，数据精确匹配；切换申诉状态后核验状态筛选联动正确；申诉状态标签展示与筛选值一致；已取消(130)状态为省平台侧操作结果，我方仅展示。

TP-A-005: 看板组合筛选 — 多条件叠加

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 规则组合
• 来源: [需求][漏测清单]
• 描述: 验证看板支持上报阶段 + 核验状态 + 申诉状态 + 模糊搜索同时组合筛选。
• 关键验证点: 选择"第二次上报+异常+未申诉(100)"组合后精确过滤；组合条件为空结果时友好提示；组合条件切换不丢失已输入的单号搜索关键字。

TP-A-006: 看板导出功能

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求][项目画像]
• 描述: 验证看板支持将当前筛选结果导出为 Excel 文件，大数据量导出正常。
• 关键验证点: 导出文件包含全部列表字段；导出数据与当前筛选条件一致；大数据量（≥2000条）导出不超时、不OOM；导出的 Excel 文件可正常打开和解析。

TP-A-007: 看板重置查询条件

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求][漏测清单]
• 描述: 验证点击"重置"按钮后，所有查询条件恢复默认值，列表刷新为初始全部数据。
• 关键验证点: 模糊搜索输入框清空；下拉筛选恢复"全部"；列表数据恢复为默认全部运单；重置后分页回到第1页。

TP-A-008: 看板列表字段完整性校验

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求]
• 描述: 验证看板列表展示的14个字段完整且顺序与需求一致：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、申诉状态、异常项、货物名称、合同金额、最新核验时间、操作。
• 关键验证点: 每个字段均有数据且格式正确；异常项为空时合理展示（如"-"或留空）；合同金额保留2位小数；最新核验时间为合理时间格式。

TP-A-009: 看板状态标签颜色映射

• 优先级: P2
• 类型: UI测试
• 覆盖维度: 数据校验
• 来源: [漏测清单]
• 描述: 验证上报阶段不同状态对应的标签颜色是否正确（蓝色=上传中、绿色=已上传/通过、红色=上传失败/审核不通过、橙色=异常）。
• 关键验证点: 每一种状态颜色独立验证；蓝色/绿色/红色/橙色与实际需求一致；申诉状态标签（未申诉灰色/审核通过绿色/审核不通过红色）颜色区分清晰。

TP-A-010: 看板操作按钮 — 申诉/进度/详情 入口

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求]
• 描述: 验证看板操作列中"申诉""进度""详情"按钮根据运单当前状态正确显示/隐藏，点击后正确跳转。
• 关键验证点: 仅异常运单显示"申诉"按钮；所有运单显示"详情"按钮；"进度"按钮展示上报阶段进度；点击后路由跳转正确，携带正确的运单ID参数。

TP-A-011: 看板详情弹窗 — 分组字段完整性

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求][漏测清单]
• 描述: 验证看板点击"详情"后弹窗内容完整，按子对象分组展示，各分组字段不缺失。
• 关键验证点: 建单信息分组13字段完整；托运人信息7字段完整；收货方信息5字段完整；司机信息13字段完整；车辆信息19字段完整；货物信息支持多条展示；可选字段为空时展示合理。

TP-A-012: 看板空数据状态

• 优先级: P3
• 类型: UI测试
• 覆盖维度: 边界条件
• 来源: [漏测清单]
• 描述: 验证看板在无运单数据时的空状态展示（如新部署环境或筛选无结果）。
• 关键验证点: 空状态有友好的占位提示图文；筛选无结果时明确提示"未找到匹配数据"；空状态不出现控制台报错或页面崩溃。

TP-A-013: 看板分页和默认排序

• 优先级: P3
• 类型: UI测试
• 覆盖维度: 边界条件
• 来源: [漏测清单]
• 描述: 验证看板列表分页功能正常（翻页、每页条数切换），默认按最新核验时间倒序排列。
• 关键验证点: 翻页后数据不重复不遗漏；切换每页条数后分页重新计算；数据更新后排序即时反映；总条数与数据库一致。

TP-A-014: 看板角色权限控制

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 权限控制
• 来源: [项目画像]
• 描述: 验证不同角色（运营/财务/客服/车队长/司机）对看板的访问权限和数据可见范围。
• 关键验证点: 运营人员可见全部运单；财务人员可见打款相关字段；客服人员仅可见其负责范围的运单；车队长和司机不可见平台端看板；越权访问被正确拦截。

---

模块B: 第一次上报-装货完成 (22个测试点)

TP-B-001: 装货完成后自动触发第一次上报

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求]
• 描述: 验证运单装货完成后，系统自动触发第一次上报，上报数据包含全部必选子对象（运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息）。
• 关键验证点: 装货完成事件触发上报；上报请求包含全部7个子对象；各子对象必选字段完整；上报接口收到正确的JSON结构；上报成功后状态变为"已上传"（绿色标签）。

TP-B-002: 仅安徽税源地运单触发上报

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [需求][项目画像]
• 描述: 验证货源税源地为非安徽的运单（如云南=28）装货完成后不会触发第一次上报。
• 关键验证点: 税源地为云南(28)的运单不触发上报；税源地为其他省份的运单不触发上报；不触发时无错误日志或告警；仅税源地为安徽(34)的运单触发上报。

TP-B-003: 第一次上报数据字段格式校验 — 建单信息

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求][漏测清单]
• 描述: 验证第一次上报的建单信息(waybillInfo)13个字段的格式、类型、长度符合接口规范，可选字段（委托合同编号、运输里程）为空时正常上报。
• 关键验证点: 必选字段缺失时上报拒绝并明确提示；统一社会信用代码格式校验（18位）；业务类型代码/运输组货方式代码为有效枚举值；运输里程为合理数值范围；经纬度为合法浮点数范围；时间字段使用 yyyyMMddHHmmss（14位）格式，如 documentCreateTime、orderReceivingTime、departureTime。

TP-B-004: 省份代码动态获取 — 安徽=34 非云南=28

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 数据校验 + 历史缺陷防御
• 来源: [历史缺陷][漏测清单]
• 描述: 防御 BUG-202607-04：验证司机信息中的省份代码(provinceCode)根据上报目标省份动态读取配置，安徽省使用代码"34"而非项目默认值云南省代码"28"。
• 关键验证点: 安徽运八上报的省份代码为"34"；不同省份配置隔离，云南=28、安徽=34 各自独立；修改省份配置后无需重启服务即可生效；数据库/Redis中无硬编码省份代码；装货地行政区划代码前2位=34（安徽省代码）。

TP-B-005: 后端校验 — 第一次上报是第二/三次上报的前置条件

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 状态流转 + 历史缺陷防御
• 来源: [历史缺陷][漏测清单]
• 描述: 防御 BUG-202607-01：验证第一次上报失败后，后端接口层面拒绝第二次和第三次上报请求，返回明确错误码"前置上报未完成"。前端+后端双重拦截。
• 关键验证点: 第一次上报失败时调用第二次上报接口返回错误；错误码明确标识"前置上报未完成"；后端通过查询运单上报状态表做校验，非前端布尔值；第一次上报重试3次全失败后第二次上报仍被拒绝；第三次上报同理，第二次上报失败时被拒绝。

TP-B-006: 第一次上报成功后自动调用"修改字段"接口

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求]
• 描述: 验证监管平台核验通过后，系统自动调用"修改第一次上报部分字段"接口，更新装货后可能变化的字段（如实际里程）。
• 关键验证点: 核验通过后自动触发修改接口；修改的字段为装货后变化字段（实际里程等）；修改成功后状态仍为"已上传"；修改接口调用记录出现在上报日志中；若修改失败有重试机制和告警。

TP-B-007: 第一次上报自动重试 — 最多3次

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 弱网超时
• 来源: [需求]
• 描述: 验证第一次上报失败后系统自动重试，最多3次，重试间隔递增。
• 关键验证点: 第1次失败后自动触发第2次重试；重试间隔合理递增（如5s/15s/30s）；第3次仍失败后标记为"上传失败"（红色标签）并停止重试；每次重试均记录到上报日志；重试次数不超过3次。

TP-B-008: 第一次上报全部重试失败后通知运营人员

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [需求]
• 描述: 验证第一次上报3次自动重试全部失败后，系统通过站内信或其他方式通知运营人员。
• 关键验证点: 3次重试失败后立即触发通知；通知内容包含运单号、失败原因、失败时间；站内信有明确的"上报失败"标记；运营人员可在通知中直接跳转到对应运单详情页。

TP-B-009: 第一次上报手工上传 — 上传失败后手动触发

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [需求]
• 描述: 验证运单上报状态为"上传失败"（红色标签）时，运营人员可点击"手动上传"按钮重新发起上报。
• 关键验证点: 仅"上传失败"状态显示"手动上传"按钮；点击后发起新的上报请求；手动上传成功后状态变为"已上传"（绿色）；手动上传同样记录到上报日志。

TP-B-010: 第一次上报状态标签颜色校验

• 优先级: P2
• 类型: UI测试
• 覆盖维度: 数据校验
• 来源: [漏测清单]
• 描述: 验证四种上报状态对应的标签颜色：上传中=蓝色、已上传=绿色、上传失败=红色、异常=橙色。
• 关键验证点: 每种状态颜色独立验证，不与需求描述偏离；上传中状态显示蓝色标签和加载动画；状态切换时标签颜色即时更新；颜色在亮色/暗色主题下均可辨识。

TP-B-011: 第一次上报详情弹窗 — 建单信息字段完整性

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求][漏测清单]
• 描述: 验收详情弹窗中"建单信息"分组的13个字段全部展示，数据取值来源正确。
• 关键验证点: 上游企业委托运输单号、本运单单号、托运人建单时间、网络货运经营者名称、统一社会信用代码、道路运输经营许可证编号、业务类型代码、运输组货方式代码、司机接单时间、司机起运时间、承运合同编号（必选）共11字段有值；委托合同编号和运输里程为可选字段，为空时合理展示。

TP-B-012: 第一次上报详情弹窗 — 托运人/收货方/司机/车辆/货物/保险子对象字段完整性

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求][漏测清单]
• 描述: 验证详情弹窗中各子对象字段完整且按分组展示：托运人信息7字段、收货方信息5字段、司机信息13字段、车辆信息19字段、货物信息4字段（可多条）、保险信息2字段（可选）。
• 关键验证点: 托运人统一社会信用代码格式正确；收货方身份证号脱敏展示（如适用）；司机从业资格证有效期起止日期格式正确；车辆VIN码(17位)正确显示；货物支持多条记录展开；保险单号为可选字段，无保险时合理展示。

TP-B-013: 第一次上报详情弹窗 — 异常信息展示

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求]
• 描述: 验证详情弹窗中"异常信息"分组包含核验状态、异常原因、异常时间、处理状态4个字段。
• 关键验证点: 核验通过时异常原因为空；核验异常时异常原因描述清晰可理解；异常时间为实际核验时间；处理状态与申诉模块数据联动。

TP-B-014: 第一次上报幂等性 — 防止重复上报

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 并发幂等 + 历史缺陷防御
• 来源: [历史缺陷][漏测清单]
• 描述: 防御 BUG-202607-02：验证同一运单同一上报阶段在短时间内不能重复上报。自动重试期间手动触发上传时，系统检测到上报进行中并拒绝重复提交。
• 关键验证点: 自动重试进行中点击"手动上传"返回"上报处理中"提示并拒绝；同一运单同一阶段1分钟内只能有1条成功上报记录；使用分布式锁或幂等键控制并发；快速连续点击"手动上传"按钮仅发起1次请求（前端防抖）；后端数据库层面唯一约束防重。

TP-B-015: 第一次上报接口超时处理

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 弱网超时
• 来源: [漏测清单][风险矩阵]
• 描述: 验证第一次上报接口调用超时后的处理逻辑（超时归类为上报失败，触发重试）。
• 关键验证点: 监管平台接口超时(>30s)后转为"上传失败"状态；超时状态下触发自动重试；超时不导致数据不一致或重复写入；超时时有 Loading 状态提示；前端页面超时后有友好提示。

TP-B-016: 第一次上报弱网环境处理

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 弱网超时
• 来源: [漏测清单]
• 描述: 验证在弱网环境（高延迟、高丢包率）下，第一次上报的重试机制正常工作。
• 关键验证点: 弱网下请求发送成功但响应延迟时不会立即判定失败；超时阈值合理（建议30s）；弱网恢复后重试成功则状态正常流转；断网时上报请求发送失败的提示友好。

TP-B-017: 第一次上报并发触发 — 多运单同时装货完成

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 并发幂等
• 来源: [项目画像][最佳实践]
• 描述: 验证多个运单同时装货完成时，第一次上报并发处理，各运单上报互不干扰。
• 关键验证点: 10个运单同时装货完成，各自独立触发上报；并发上报不产生数据库死锁；各运单上报记录正确隔离；并发上报后上报日志完整记录每个运单的请求。

TP-B-018: 第一次上报可选字段空值处理

• 优先级: P3
• 类型: 功能测试
• 覆盖维度: 边界条件
• 来源: [漏测清单]
• 描述: 验证各子对象中的可选字段（委托合同编号、运输里程、挂车牌照号、行驶证档案编号、道路运输证有效期起/至、保险单号、保险公司名称）为空时，上报接口正常处理。
• 关键验证点: 可选字段为空时上报不报错；JSON 中可选字段不传或传 null 均可正常处理；详情弹窗中可选字段为空时显示"-"或"N/A"等占位符，不显示"null"或"undefined"。

TP-B-019: 第一次上报货物信息多条记录

• 优先级: P3
• 类型: 功能测试
• 覆盖维度: 边界条件
• 来源: [需求][漏测清单]
• 描述: 验证当运单包含多种货物时，货物信息(goodsInfos)数组支持多条记录上报，每条包含货物名称、货物类型代码、货物量、计量单位。
• 关键验证点: 支持1条货物记录；支持多条（如5条）货物记录；每条货物信息独立完整；详情弹窗支持展开/折叠多条货物记录；货物类型代码与数据字典一致。

TP-B-020: 第一次上报列表字段完整性

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求][漏测清单]
• 描述: 验证第一次上报列表展示的字段完整且与需求一致，包括货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、业务类型、货物名称、装货地址、卸货地址、运输里程、合同编号、上报状态、操作共14个字段。
• 关键验证点: 列表表头与需求一致性；14个字段均正确展示且顺序符合设计；业务类型与数据字典一致；装货地址和卸货地址完整展示；运输里程带单位（km）；上报状态标签颜色映射正确（上传中=蓝色/已上传=绿色/上传失败=红色/异常=橙色）。

TP-B-021: 委托合同（框架）上传 — 第一次上报前置条件

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 状态流转
• 来源: [技术方案]
• 描述: 验证在进行运单的第一次上报前，需要先通过 POST /api/dataUpload/mandateContractFrame 接口将委托合同（框架）上传至服务平台；未上传委托合同时第一次上报应被拒绝。
• 关键验证点: 未上传委托合同时触发第一次上报被拒绝，返回明确错误提示；委托合同（框架）上传成功后第一次上报可正常进行；委托合同字段（contract_number合同编号、expire_time有效期截止日yyyy-MM-dd）必填校验；uploadFileInfo字段可选，可在修改委托合同时补充。

TP-B-022: 委托合同与委托合同（框架）二选一上报

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 规则组合
• 来源: [技术方案]
• 描述: 验证委托合同（框架）和委托合同二选一进行上报：单个货主企业使用 unified_social_credit_identifier 字段；多家货主企业使用 enterpriseList 数组关联。若两者都传值，默认取单托运企业(unified_social_credit_identifier)。
• 关键验证点: 仅传 unified_social_credit_identifier（单企业）时正常上报；仅传 enterpriseList（多企业列表）时正常上报，列表中每项含 unified_social_credit_identifier 和 owner_enterprise_name；两者都传时默认取单企业；两者都不传时接口返回错误。

---

模块C: 第二次上报-打款完成 (51个测试点)

TP-C-001: 打款完成后自动触发第二次上报

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求]
• 描述: 验证运单运费支付（财务打款）完成后，系统自动触发第二次上报，上报数据包含资金流水信息和车辆轨迹信息。
• 关键验证点: 财务打款完成回调触发上报；上报请求包含运单信息+资金流水+车辆轨迹；上报成功后状态更新；第二次上报仅对已完成第一次上报的运单触发。

TP-C-002: 第二次上报资金流水数据来源于支付流水表

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 数据校验 + 历史缺陷防御
• 来源: [历史缺陷][漏测清单]
• 描述: 防御 BUG-202607-03：验证第二次上报的资金流水数据（支付金额、支付方式、支付时间、流水号等）从支付流水表实时读取，而非使用运单缓存中的合同金额。
• 关键验证点: 上报数据中的金额与支付流水表实际打款金额完全一致；非从运单表或Redis缓存读取金额；数据库查询SQL日志可确认数据来源为支付流水表；金额字段精确到分（2位小数），无精度丢失。

TP-C-003: 财务修改打款金额后第二次上报使用最新金额

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 数据校验 + 历史缺陷防御
• 来源: [历史缺陷][漏测清单]
• 描述: 防御 BUG-202607-03：验证财务在账户管理模块修改打款金额后，第二次上报感知数据变更并使用修改后的最新金额。
• 关键验证点: 合同金额10000元 → 财务调账修改为9500元 → 第二次上报金额为9500元；财务修改与上报触发有时间差时仍使用最新值；上报日志中可溯源金额来源；反例：不使用装货完成时缓存的合同金额。

TP-C-004: 第二次上报列表字段完整性校验

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求]
• 描述: 验证第二次上报列表展示的14个字段完整：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、承运运费、总金额、付款方式、付款时间、收款人、收款账号、收款账号类型、核验状态、异常项、上报状态、操作。
• 关键验证点: 承运运费和总金额保留2位小数；付款时间为实际财务打款时间；操作列根据上报状态显示"上报"或"详情"按钮。

TP-C-005: 收款账号类型标签颜色 — 个人账户(蓝色)/对公账户(绿色)

• 优先级: P2
• 类型: UI测试
• 覆盖维度: 数据校验
• 来源: [需求][漏测清单]
• 描述: 验证列表中收款账号类型标签颜色：个人账户显示蓝色标签，对公账户显示绿色标签。
• 关键验证点: 司机个人银行卡(个人账户)=蓝色；企业银行账号(对公账户)=绿色；颜色与需求定义严格一致；列表中每条记录标签颜色根据实际账号类型渲染，不混淆。

TP-C-006: 运单重复核验 — 通过场景

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求][漏测清单]
• 描述: 验证同一运单未重复上报时，监管平台"运单重复核验"返回通过。
• 关键验证点: 首次上报的运单核验通过；不同运单号各自独立上报通过；核验状态标记为"通过"；无"运单重复"异常项出现。

TP-C-007: 运单重复核验 — 异常场景（重复上报）

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [需求][漏测清单]
• 描述: 验证同一运单第二次上报时，监管平台"运单重复核验"检测到重复并返回异常。
• 关键验证点: 重复上报后核验状态变为"异常"；异常项明确标注"运单重复核验"；异常原因清晰可读；异常运单可触发申诉流程。

TP-C-008: 车辆资质核验 — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求][漏测清单]
• 描述: 验证车辆道路运输证在有效期内时，监管平台"车辆资质核验"返回通过。
• 关键验证点: 道路运输证有效期起止日期在有效期内；道路运输证号格式有效；车辆审核状态为"通过"的运单核验通过。

TP-C-009: 车辆资质核验 — 异常场景（证件过期/缺失）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [需求][漏测清单]
• 描述: 验证车辆道路运输证已过期或缺失时，监管平台"车辆资质核验"返回异常。
• 关键验证点: 道路运输证有效期的截止日期 < 当前日期时核验异常；无道路运输证号的车辆核验异常；异常项明确标注"车辆资质核验"；异常后可申诉。

TP-C-010: 司机资质核验 — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求][漏测清单]
• 描述: 验证司机从业资格证在有效期内时，监管平台"司机资质核验"返回通过。
• 关键验证点: 从业资格证有效期起止日期在有效期内；从业资格证号格式有效；司机审核状态为"通过"的运单核验通过。

TP-C-011: 司机资质核验 — 异常场景（证件过期/缺失）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [需求][漏测清单]
• 描述: 验证司机从业资格证已过期或缺失时，监管平台"司机资质核验"返回异常。
• 关键验证点: 从业资格证有效期至 < 当前日期时核验异常；无从业资格证号时核验异常；异常项明确标注"司机资质核验"；异常后可申诉。

TP-C-012: 集中支付核验 — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求][漏测清单]
• 描述: 验证资金流水通过网货平台集中支付时，监管平台"集中支付核验"返回通过。
• 关键验证点: 付款方为网货平台统一账户，核验通过；支付流水记录与集中支付模式匹配；核验状态为"通过"。

TP-C-013: 集中支付核验 — 异常场景（非集中支付/支付信息异常）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [需求][漏测清单]
• 描述: 验证资金流水未通过网货平台集中支付或支付信息异常时，监管平台"集中支付核验"返回异常。
• 关键验证点: 付款方非平台统一账户时核验异常；集中支付流水数据不完整时核验异常；异常项明确标注"集中支付核验"；异常后可申诉。

TP-C-014: 资金流水核验 — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求][漏测清单]
• 描述: 验证资金流水单号不重复且金额匹配时，监管平台"资金流水核验"返回通过。
• 关键验证点: 流水号唯一不重复；上报金额与支付流水表实际金额一致；核验状态为"通过"。

TP-C-015: 资金流水核验 — 异常场景（流水号重复/金额不匹配）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [需求][漏测清单]
• 描述: 验证资金流水单号重复或上报金额与支付流水不一致时，监管平台"资金流水核验"返回异常。
• 关键验证点: 重复流水单号核验异常并提示；上报金额与支付流水金额偏差>0.01元时核验异常；异常项明确标注"资金流水核验"；异常后可申诉。

TP-C-016: 合同核验 — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求][漏测清单]
• 描述: 验证运输合同和委托合同均有效时，监管平台"合同核验"返回通过。
• 关键验证点: 承运合同编号有效且存在于合同管理系统；委托合同编号（如有）有效；合同有效期覆盖运单执行日期；核验状态为"通过"。

TP-C-017: 合同核验 — 异常场景（合同无效/过期/缺失）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [需求][漏测清单]
• 描述: 验证运输合同或委托合同无效/过期/缺失时，监管平台"合同核验"返回异常。
• 关键验证点: 承运合同编号不存在时核验异常；合同有效期不包含运单执行日期时核验异常；异常项明确标注"合同核验"；异常后可申诉。

TP-C-018: 车辆轨迹合规核验 — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求][漏测清单]
• 描述: 验证车辆GPS轨迹真实、与运单路线匹配、轨迹点数量在2~2000范围内时，监管平台"车辆轨迹合规核验"返回通过。
• 关键验证点: 轨迹点数量≥2且≤2000；轨迹路线与装货地→卸货地路线基本一致；轨迹时间与运单执行时间匹配；核验状态为"通过"。

TP-C-019: 车辆轨迹合规核验 — 异常场景（点位不足/偏差过大/轨迹缺失）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [需求][漏测清单]
• 描述: 验证车辆轨迹点数量不足(<2)、偏差过大、或轨迹数据缺失时，监管平台"车辆轨迹合规核验"返回异常。
• 关键验证点: 轨迹点数量=1或0时核验异常；轨迹路线偏离装货-卸货路线超过合理范围时核验异常；异常项明确标注"车辆轨迹合规核验"；异常后可进入"补传轨迹"流程。

⚠️ API文档扩展说明 (来自原型&接口交叉分析): 根据网货企业端接口文档 V1.0.2 §4.1 异常项ID对照表，第二次上报核验项从需求的7类扩展为API定义的17项独立核验项。以下TP-C-006~TP-C-019覆盖了需求的7类核验（运单重复/车辆资质/司机资质/集中支付/资金流水/合同/轨迹合规），但API将其中部分类别拆分为更细粒度的独立核验项。

API文档完整17项: 100=委托合同, 120=承运合同, 130=实时定位, 140=运单时间逻辑, 150=车辆资质, 160=道路运输证, 170=驾驶证, 180=从业资格证, 190=车辆重复, 200=司机重复, 210=车辆轨迹, 220=运费收款, 230=公司统一收款, 240=集中支付, 250=资金流水, 260=发票信息, 270=非通行车辆可开票

以下 TP-C-026~TP-C-049 为补充的12项独立核验项（每项 PASS + EXCEPTION），来源标注 [技术方案]。

TP-C-025: 里程申诉功能 — 提交里程申诉

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [技术方案]
• 描述: 验证运单里程数据异常时，可通过 POST /mileageAppeal/insert 接口提交里程申诉，携带运单号(freightSheetNumber)、申诉内容(content)、投诉编号(complaintNumber)、申诉里程(mileage)参数。
• 关键验证点: 里程申诉接口正常调用成功返回；必选参数齐全（运单号/申诉内容/投诉编号/申诉里程）；申诉提交后可在申诉记录中查看；里程申诉与异常申诉独立管理；缺少必选参数时接口返回明确错误提示。

TP-C-026: 委托合同核验(100) — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [技术方案]
• 描述: 验证委托合同编号有效且存在于合同管理系统、有效期覆盖运单执行日期时，监管平台"委托合同核验"返回通过。
• 关键验证点: 委托合同编号有效且存在于系统；委托合同有效期覆盖运单执行日期；核验状态为"通过"；无"委托合同核验"异常项出现。

TP-C-027: 委托合同核验(100) — 异常场景（合同无效/过期/缺失）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [技术方案]
• 描述: 验证委托合同编号不存在、无效或有效期不覆盖运单执行日期时，监管平台"委托合同核验"返回异常。
• 关键验证点: 委托合同编号不存在时核验异常；合同有效期不覆盖运单执行日期时核验异常；委托合同为空时核验异常；异常项明确标注"委托合同核验"（代码100）；异常后可申诉。

TP-C-028: 承运合同核验(120) — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [技术方案]
• 描述: 验证承运合同编号有效且存在于合同管理系统、有效期覆盖运单执行日期时，监管平台"承运合同核验"返回通过。
• 关键验证点: 承运合同编号有效且存在于系统；承运合同有效期覆盖运单执行日期；核验状态为"通过"；无"承运合同核验"异常项出现。

TP-C-029: 承运合同核验(120) — 异常场景（合同无效/过期/缺失）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [技术方案]
• 描述: 验证承运合同编号不存在、无效或有效期不覆盖运单执行日期时，监管平台"承运合同核验"返回异常。
• 关键验证点: 承运合同编号不存在时核验异常；合同有效期不覆盖运单执行日期时核验异常；承运合同为空时核验异常；异常项明确标注"承运合同核验"（代码120）；异常后可申诉。

TP-C-030: 实时定位核验(130) — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [技术方案]
• 描述: 验证车辆在运单执行期间有完整的实时定位数据（GPS轨迹覆盖整个运输过程）时，监管平台"实时定位核验"返回通过。
• 关键验证点: 运单执行期间车辆实时定位数据完整；定位时间覆盖运单起运至送达时间范围；核验状态为"通过"；无"实时定位核验"异常项出现。

TP-C-031: 实时定位核验(130) — 异常场景（定位数据缺失/不完整）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [技术方案]
• 描述: 验证车辆在运单执行期间缺少实时定位数据或定位数据不完整时，监管平台"实时定位核验"返回异常。
• 关键验证点: 运输过程中定位数据长时间中断时核验异常；无任何实时定位数据时核验异常；定位数据时间范围未覆盖运单执行时间时核验异常；异常项明确标注"实时定位核验"（代码130）；异常后可申诉或补传定位数据。

TP-C-032: 运单时间逻辑核验(140) — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [技术方案]
• 描述: 验证运单各时间节点逻辑合理（建单时间 < 接单时间 < 起运时间 < 送达时间）时，监管平台"运单时间逻辑核验"返回通过。
• 关键验证点: 建单时间早于接单时间；接单时间早于起运时间；起运时间早于送达时间；各时间节点无倒置或矛盾；核验状态为"通过"。

TP-C-033: 运单时间逻辑核验(140) — 异常场景（时间倒置/不合理）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [技术方案]
• 描述: 验证运单各时间节点存在逻辑矛盾（如送达时间早于起运时间、接单时间早于建单时间等）时，监管平台"运单时间逻辑核验"返回异常。
• 关键验证点: 起运时间晚于送达时间时核验异常；接单时间早于建单时间时核验异常；时间字段为空时核验异常；异常项明确标注"运单时间逻辑核验"（代码140）；异常后可申诉。

TP-C-034: 道路运输证核验(160) — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [技术方案]
• 描述: 验证车辆道路运输证在有效期内且证号格式有效时，监管平台"道路运输证核验"返回通过。
• 关键验证点: 道路运输证有效期起止日期在当前日期范围内；道路运输证号格式有效且可查询；道路运输证发证机关信息完整；核验状态为"通过"；无"道路运输证核验"异常项出现。

TP-C-035: 道路运输证核验(160) — 异常场景（过期/缺失/无效）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [技术方案]
• 描述: 验证车辆道路运输证过期、缺失或证号格式无效时，监管平台"道路运输证核验"返回异常。
• 关键验证点: 道路运输证有效期截止日期 < 当前日期时核验异常；道路运输证号为空或格式无效时核验异常；证号在运政系统中查询不存在时核验异常；异常项明确标注"道路运输证核验"（代码160）；异常后可申诉。

TP-C-036: 驾驶证核验(170) — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [技术方案]
• 描述: 验证司机驾驶证在有效期内且证号与交管系统一致时，监管平台"驾驶证核验"返回通过。
• 关键验证点: 驾驶证有效期覆盖运单执行日期；驾驶证号格式正确（18位）；驾驶证准驾车型与车辆类型匹配；核验状态为"通过"；无"驾驶证核验"异常项出现。

TP-C-037: 驾驶证核验(170) — 异常场景（过期/缺失/准驾不符）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [技术方案]
• 描述: 验证司机驾驶证过期、缺失或准驾车型不匹配时，监管平台"驾驶证核验"返回异常。
• 关键验证点: 驾驶证有效期截止日期 < 当前日期时核验异常；驾驶证号为空或格式无效时核验异常；准驾车型与实际驾驶车辆类型不匹配时核验异常；异常项明确标注"驾驶证核验"（代码170）；异常后可申诉。

TP-C-038: 车辆重复核验(190) — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [技术方案]
• 描述: 验证同一车辆未在同一时间段内被重复用于多个运单时，监管平台"车辆重复核验"返回通过。
• 关键验证点: 车辆在运单执行时段内无其他重叠运单；车辆未同时出现在多个进行中的运单中；核验状态为"通过"；无"车辆重复核验"异常项出现。

TP-C-039: 车辆重复核验(190) — 异常场景（车辆同时用于多个运单）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [技术方案]
• 描述: 验证同一车辆在同一时间段内被用于多个运单（时间重叠）时，监管平台"车辆重复核验"返回异常。
• 关键验证点: 车辆在运单A执行期间同时出现在运单B中时核验异常；时间重叠超过合理阈值时核验异常；异常项明确标注"车辆重复核验"（代码190）；异常后可申诉。

TP-C-040: 司机重复核验(200) — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [技术方案]
• 描述: 验证同一司机未在同一时间段内被重复分配给多个运单时，监管平台"司机重复核验"返回通过。
• 关键验证点: 司机在运单执行时段内无其他重叠运单；司机未同时驾驶多辆车辆执行不同运单；核验状态为"通过"；无"司机重复核验"异常项出现。

TP-C-041: 司机重复核验(200) — 异常场景（司机同时执行多个运单）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [技术方案]
• 描述: 验证同一司机在同一时间段内被分配给多个运单（时间重叠）时，监管平台"司机重复核验"返回异常。
• 关键验证点: 司机在运单A执行期间同时出现在运单B中时核验异常；时间重叠超过合理阈值时核验异常；异常项明确标注"司机重复核验"（代码200）；异常后可申诉。

TP-C-042: 运费收款核验(220) — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [技术方案]
• 描述: 验证运费收款方信息与实际司机/承运人一致、收款金额与运单运费匹配时，监管平台"运费收款核验"返回通过。
• 关键验证点: 收款方身份与运单司机一致；收款金额与运单运费一致；收款账户信息有效；核验状态为"通过"；无"运费收款核验"异常项出现。

TP-C-043: 运费收款核验(220) — 异常场景（收款人不一致/金额不匹配）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [技术方案]
• 描述: 验证运费收款人与运单司机不一致、收款金额与运费不匹配时，监管平台"运费收款核验"返回异常。
• 关键验证点: 收款人姓名/身份证号与司机信息不一致时核验异常；收款金额与运单运费偏差超过阈值时核验异常；异常项明确标注"运费收款核验"（代码220）；异常后可申诉。

TP-C-044: 公司统一收款核验(230) — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [技术方案]
• 描述: 验证当收款方为公司统一收款账户时，公司信息与运单托运方信息一致，监管平台"公司统一收款核验"返回通过。
• 关键验证点: 收款公司名称/统一社会信用代码与托运方一致；公司统一收款账户在系统中备案；核验状态为"通过"；无"公司统一收款核验"异常项出现。

TP-C-045: 公司统一收款核验(230) — 异常场景（公司信息不一致/未备案）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [技术方案]
• 描述: 验证公司统一收款账户信息与托运方不一致或收款账户未备案时，监管平台"公司统一收款核验"返回异常。
• 关键验证点: 收款公司名称与托运方名称不一致时核验异常；收款公司统一社会信用代码与托运方不一致时核验异常；收款账户未在系统中备案时核验异常；异常项明确标注"公司统一收款核验"（代码230）；异常后可申诉。

TP-C-046: 发票信息核验(260) — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [技术方案]
• 描述: 验证第三次上报关联的发票信息完整有效（发票号码/代码/金额匹配、销售方/受票方信息完整）时，监管平台"发票信息核验"返回通过。
• 关键验证点: 发票号码与发票代码匹配有效；发票金额（价税合计）计算正确；销售方纳税人识别号有效；受票方信息与托运方一致；核验状态为"通过"。

TP-C-047: 发票信息核验(260) — 异常场景（发票无效/信息不完整）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [技术方案]
• 描述: 验证发票号码/代码不匹配、发票信息不完整或发票已作废时，监管平台"发票信息核验"返回异常。
• 关键验证点: 发票号码在税务系统中查询不到时核验异常；发票已作废/红冲时核验异常；受票方名称/纳税人识别号与托运方不一致时核验异常；异常项明确标注"发票信息核验"（代码260）；异常后可申诉。

TP-C-048: 非通行车辆可开票核验(270) — 通过场景

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [技术方案]
• 描述: 验证运单关联的车辆属于可开票车辆（即车辆资质、运营证照齐全且在合规运营范围内）时，监管平台"非通行车辆可开票核验"返回通过。
• 关键验证点: 车辆运营证照齐全且在有效期内；车辆未被标记为不合规或黑名单；核验状态为"通过"；无"非通行车辆可开票核验"异常项出现。

TP-C-049: 非通行车辆可开票核验(270) — 异常场景（车辆不合规/证照缺失）

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [技术方案]
• 描述: 验证车辆运营证照不全、车辆被标记为不合规或不在可开票范围内时，监管平台"非通行车辆可开票核验"返回异常。
• 关键验证点: 车辆无有效道路运输证时核验异常；车辆被标记为运营异常/黑名单时核验异常；车辆类型不在可开票范围内时核验异常；异常项明确标注"非通行车辆可开票核验"（代码270）；异常后可申诉。

TP-C-050: 第二次上报金额精度3位小数校验 [技术方案]

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 边界条件
• 来源: [技术方案]
• 描述: 验证第二次上报中所有金额字段保留3位小数（非2位），货币单位为人民币（元），如整数以.000填充。涉及字段：arrivalInfo.waybillFreightAmount（承运运费金额）、arrivalInfo.totalMonetaryAmount（委托运费金额）、carrierStatements.monetaryAmount（承运人流水金额）、ownerStatements.monetaryAmount（货主流水金额）、carrierContractInfo.contractAmount（承运合同金额）、carrierContractInfo.contractedCarryingCapacity（承运量）、ownerContractInfo.contractAmount（委托合同金额）、ownerContractInfo.contractedCarryingCapacity（委托合同承运量）。
• 关键验证点: 整数金额如100 → 上报为100.000（3位小数）；小数金额如100.5 → 上报为100.500；小数金额如100.123 → 上报为100.123；金额字段使用DECIMAL类型而非FLOAT；数据库和UI展示均保留3位小数。

TP-C-051: 承运人流水核验次日延迟 [技术方案]

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [技术方案]
• 描述: 验证除承运人流水核验需等待次日银行提供数据后开始核验外，其余核验项会在一至两小时内核验完成。第二次上报后承运人流水核验状态初始为"待核验"（非异常），次日银行数据到后才执行核验。
• 关键验证点: 第二次上报后除"资金流水核验"外其他核验项1~2小时内完成；承运人流水核验在当日处于"待核验"或"核验中"状态；次日银行数据提供后承运人流水核验自动执行；若次日核验发现异常，核验状态更新为"异常"并可申诉。

TP-C-020: 后端校验 — 第二次上报依赖第一次上报完成

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 状态流转 + 历史缺陷防御
• 来源: [历史缺陷][漏测清单]
• 描述: 防御 BUG-202607-01：验证后端接口层面，第一次上报未完成（失败/进行中）时拒绝第二次上报，返回明确错误码。
• 关键验证点: 第一次上报"上传失败"状态下触发第二次上报被拒绝；第一次上报"上传中"状态下触发第二次上报被拒绝；后端通过查询运单上报状态表校验，非仅前端控制；错误码和错误消息明确。

TP-C-021: 第二次上报幂等性 — 防止重复上报

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 并发幂等 + 历史缺陷防御
• 来源: [历史缺陷][漏测清单]
• 描述: 防御 BUG-202607-02：验证第二次上报具有幂等性，重复触发不产生多条上报记录，自动重试和手动触发互斥。
• 关键验证点: 第二次上报自动重试期间禁止手动触发；同一运单第二次上报仅产生1条有效记录；分布式锁/幂等键控制并发；数据库唯一约束防止插入重复记录。

TP-C-022: 补传轨迹功能

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [需求]
• 描述: 验证车辆轨迹合规核验异常后，运营人员可通过"补传轨迹"功能补充GPS轨迹数据，重新触发核验。
• 关键验证点: 仅轨迹核验异常的运单显示"补传轨迹"按钮；补传后重新触发轨迹核验；补传的轨迹数据覆盖原有数据；补传后核验通过则异常项消除；补传操作记录到上报日志。

TP-C-023: 第二次上报失败自动重试机制

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [需求][漏测清单]
• 描述: 验证第二次上报失败（超时或接口返回错误）后，系统自动重试（最多3次），重试间隔递增，3次全部失败后告警通知运营人员。
• 关键验证点: 上报失败后自动触发重试（非人工触发）；最多重试3次；重试间隔递增（如5s/15s/30s）；每次重试在上报日志中独立记录；3次全部失败后通过站内信或短信告警通知运营人员；重试期间手动上传按钮不可用或提示"上报处理中"。

TP-C-024: 第二次上报详情弹窗资金流水与车辆轨迹字段完整性

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求][漏测清单]
• 描述: 验证第二次上报详情弹窗中资金流水信息（10字段）和车辆轨迹信息（6字段）的分组展示完整且字段顺序正确。
• 关键验证点: 资金流水信息完整展示（支付金额/支付方式/支付时间/付款方名称/收款方名称/收款人/收款账号/收款账号类型/流水号/支付状态）；车辆轨迹信息完整展示（定位类型/定位时间/定位地点/经度/纬度/轨迹类型）；可选字段缺失时显示"-"或"无"而不空白；弹窗分组标签正确（运单信息/托运方信息/收货方信息/资金流水信息/车辆轨迹信息/异常信息）。

---

模块D: 第三次上报-开票完成 (11个测试点)

TP-D-001: 开票完成后触发第三次上报

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求]
• 描述: 验证发票开具完成后，系统触发第三次上报，上报数据包含运单信息、发票信息和油气发票信息。
• 关键验证点: 发票开具完成后自动触发上报；上报数据包含托运单号数组、发票信息17字段；若有关联油气发票则包含油气发票信息；仅开票完成的运单触发。

TP-D-002: 第三次上报列表字段完整性校验

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求]
• 描述: 验证第三次上报列表展示的11个字段完整：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、发票号码、发票金额、开票日期、核验状态、异常原因、上报状态、操作。⚠️ 待确认: 原型列表比需求多4个字段（税率、销售方名称、受票方名称、油气票张数），共15列（含checkbox），需确认最终版本。
• 关键验证点: 发票金额保留2位小数（价税合计）；开票日期格式正确；核验状态/异常原因/上报状态数据准确。

TP-D-003: 第三次上报发票信息字段完整性

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求][漏测清单]
• 描述: 验证第三次上报详情弹窗中"发票信息"分组的17个字段完整展示。
• 关键验证点: 托运单号数组支持多个托运单号；发票号码、发票代码号、发票金额(价税合计)、开票日期必选完整；销售方8个字段(名称/纳税人识别号/地址/电话/开户行/银行账户)完整；受票方6个字段(名称/纳税人识别号/地址/电话/开户行/银行卡号)完整；注：第三次上报无税率字段。

TP-D-004: 第三次上报油气发票信息

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求]
• 描述: 验证运单关联油气发票时，第三次上报包含油气发票信息（油气托运单号、油气发票文件），支持多条油气发票。
• 关键验证点: 有油气发票时正常上报；无油气发票时不影响上报（可选字段）；多条油气发票时字段展示正确；油气发票文件支持查看/下载。

TP-D-005: 后端校验 — 第三次上报依赖第二次上报完成

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 状态流转 + 历史缺陷防御
• 来源: [历史缺陷][漏测清单]
• 描述: 防御 BUG-202607-01：验证后端接口层面，第二次上报未完成（失败/进行中/未触发）时拒绝第三次上报，返回明确错误码。
• 关键验证点: 第二次上报未完成时调用第三次上报接口被拒绝；错误码明确标识"前置上报（第二次）未完成"；后端通过查询运单上报状态表校验；第三阶段完整依赖链校验（第1→第2→第3）。

TP-D-006: 增值税发票验证失败处理

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [需求]
• 描述: 验证增值税发票验证失败时（发票号码/代码/金额不匹配等），第三次上报失败并返回明确错误提示。
• 关键验证点: 发票号码格式无效时上报失败；发票代码与发票号码不匹配时上报失败；发票金额超出合理范围时上报失败；失败提示指明具体错误字段和原因。

TP-D-007: 第三次上报自动重试 — 最多3次

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 弱网超时
• 来源: [需求]
• 描述: 验证第三次上报失败后自动重试（最多3次），全部失败后告警通知运营人员。
• 关键验证点: 重试次数不超过3次；重试间隔递增；全部失败后标记"上传失败"并告警；告警通知中包含运单号、发票号、失败原因。

TP-D-008: 第三次上报异常信息展示

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求]
• 描述: 验证第三次上报详情弹窗中"异常信息"分组包含核验状态、异常原因、异常时间、处理状态，与申诉模块数据联动。
• 关键验证点: 核验通过时异常原因为空；核验异常时展示具体异常项和原因；核验状态与看板/申诉模块数据一致。

TP-D-009: 第三次上报幂等性

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 并发幂等
• 来源: [最佳实践][历史缺陷]
• 描述: 验证第三次上报具有幂等性，同一运单同一发票信息不能重复上报。
• 关键验证点: 同一运单重复触发第三次上报仅产生1条有效记录；分布式锁/幂等键控制并发；重复提交返回"上报已存在"提示。

TP-D-010: 第三次上报发票金额精度校验

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 边界条件
• 来源: [漏测清单][风险矩阵]
• 描述: 验证第三次上报的发票金额（价税合计）保留2位小数，不出现浮点数精度问题。
• 关键验证点: 金额计算精度正确（如0.01元不丢失）；大金额（如 999999.99）上报准确；金额字段使用 DECIMAL 类型而非 FLOAT；上报数据与开票系统数据完全一致。

TP-D-011: 第三次上报货物信息/保险信息逐源验证

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [漏测清单]
• 描述: 验证第三次上报中的运单信息字段数据来源正确——价格/货物信息来源于运单表，保险信息来源于保险模块，非缓存数据。
• 关键验证点: 修改运单表数据后上报使用最新值；修改保险信息后上报使用最新值；字段取值链路可追溯；不依赖装货完成时的数据快照。

TP-D-012: 发票合规查询 — 托运人发票是否系统核验合规

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [技术方案]
• 描述: 验证可通过 POST /verificationSummary/cargoOwnerInvoiceInfo 接口查询托运人（货主）发票是否已通过系统核验合规，用于判断第三次上报前置条件。
• 关键验证点: 输入有效托运人信息返回发票合规状态；发票合规时返回通过标识；发票不合规时返回异常原因；接口支持批量查询多个托运人发票合规状态；接口响应时间在合理范围内（< 3s）。

---

模块E: ETC发票上传 (9个测试点)

TP-E-001: ETC发票上传触发

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求]
• 描述: 验证ETC发票税务抵扣成功后，运营人员在运八系统手动确认抵扣完成，系统收到确认后触发ETC发票上传至安徽监管平台。
• 关键验证点: 运营人员手动确认税务抵扣完成 → 系统触发ETC上传；上传数据包含运单信息+ETC发票信息18字段；上传成功后可在列表查看状态。

TP-E-002: ETC发票列表字段完整性

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求]
• 描述: 验证ETC上传列表展示的11个字段完整：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、ETC发票号码、发票金额、税率、上传状态、操作。
• 关键验证点: ETC发票号码与高速公路电子发票号码一致；发票金额和税率（3%）正确展示；上传状态标签颜色符合规范。

TP-E-003: ETC发票详情弹窗 — 字段完整性

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求][漏测清单]
• 描述: 验证ETC发票详情弹窗包含3个分组：运单信息（7字段）、ETC发票信息（每张发票18字段）、异常信息。
• 关键验证点: ETC发票18字段全部展示：ETC发票号码、ETC发票代码、开票时间、发票金额、税率(3%)、税额、价税合计、销售方名称、销售方税号、受票方名称、受票方税号、入口收费站、出口收费站、交易时间、交易金额、交易匹配时间、交易流水号、ETC发票文件；运单信息7字段完整；异常信息4字段完整。

TP-E-004: 税务抵扣完成前置条件校验

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 状态流转
• 来源: [需求]
• 描述: 验证ETC发票上传必须在税务抵扣完成后进行，未完成税务抵扣时上传被拒绝。
• 关键验证点: 税务抵扣未完成时上传返回明确错误；错误提示包含"请先完成税务抵扣"；后端校验税务抵扣状态；税务抵扣完成后上传才可成功。

TP-E-005: ETC发票验证失败处理

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [需求]
• 描述: 验证ETC发票信息验证失败时（发票号码/代码无效、金额不匹配、税率不正确等），上传失败并给出明确提示。
• 关键验证点: 发票号码格式无效时上传失败；发票代码与号码不匹配时上传失败；税率非3%时提示税率异常；交易金额与实际通行费不匹配时验证失败；失败提示明确指示错误字段。

TP-E-006: ETC上传自动重试 — 最多3次

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 弱网超时
• 来源: [需求]
• 描述: 验证ETC上传失败后自动重试最多3次，全部失败后告警通知。
• 关键验证点: 3次重试均失败后标记"上传失败"并告警；重试间隔递增；每次重试记录到上报日志。

TP-E-007: ETC税额计算校验 — 税额=不含税金额×税率

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求][风险矩阵]
• 描述: 验证ETC发票税额计算公式：税额 = 不含税金额(invoiceAmount) x 税率(taxRate，如3%)。关键字段区分：invoiceAmount=不含税金额（保留2位小数）、totalPriceAndTax=价税合计（不含税金额+税额，保留2位小数）、taxAmount=税额（保留2位小数）。涉及资损风险需精确验证。
• 关键验证点: 不含税金额100元×3% → 税额=3.00元, 价税合计=103.00元；不含税金额0.01元 → 税额=0.00元(或四舍五入规则明确)；大金额(如1000000元)计算不溢出；税额+不含税金额=价税合计(totalPriceAndTax)逻辑关系正确。

TP-E-008: ETC上传幂等性

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 并发幂等
• 来源: [最佳实践][历史缺陷]
• 描述: 验证同一ETC发票不能重复上传，具有幂等性。
• 关键验证点: 同一ETC发票号重复上传被拒绝；返回"该ETC发票已上传"提示；数据库存在唯一约束防止重复记录。

TP-E-009: ETC多张发票同时上传

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 边界条件
• 来源: [需求][项目画像]
• 描述: 验证同一运单可能关联多张ETC发票（不同路段），支持批量上传和多张发票的列表展示。
• 关键验证点: 多张ETC发票各自独立上传互不干扰；列表中单运单可展示多张ETC发票记录；每张发票的税额独立计算；合计税额正确汇总。

---

模块F: 异常申诉功能 (16个测试点)

TP-F-001: 申诉完整闭环 — 发起→复核→反馈→判断

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求][漏测清单]
• 描述: 验证申诉功能的完整闭环：查看异常 → 发起申诉 → 省平台复核 → 接收反馈 → 合规判断，端到端验证每个环节。注：已取消(130)由省平台侧操作设置（如运单作废），我方系统只读同步，UI不提供取消申诉操作。异常项申诉中(abnormalDetails[].state=110)可由省平台取消→异常项状态回退为100。⚠️ 待确认: 申诉状态枚举三版本不一致——需求(未申诉/申诉中/申诉通过/申诉驳回)、原型(未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回)、API(未申诉100/审核通过110/审核不通过120/已取消130)，以API §4.4为权威，需确认UI映射。
• 关键验证点: 异常运单可发起申诉；申诉提交后状态保持"未申诉(100)"（异常项处理状态变为申诉中 abnormalDetails[].state=110）；省平台复核后反馈结果更新；反馈通过→申诉状态变为"审核通过(110)"；反馈驳回→申诉状态变为"审核不通过(120)"，可补充材料重新申诉。

TP-F-002: 申诉列表字段完整性校验

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求]
• 描述: 验证申诉记录管理页面列表展示的13个字段完整：运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、异常项、申诉状态、申诉时间、申诉人、省平台反馈结果、监管平台反馈时间、操作。
• 关键验证点: 每个字段有对应数据；申诉状态与需求定义一致；申诉时间为实际提交时间；省平台反馈结果与实际反馈内容一致。

TP-F-003: 申诉状态流转 — 全部合法路径

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 状态流转
• 来源: [需求][漏测清单]
• 描述: 验证申诉状态流转全路径（以API §4.4为权威）：未申诉(100) → [提交申诉，异常项state=110申诉中] → 审核通过(110)[终态] / 审核不通过(120)[可重新申诉] → (审核不通过后) 重新申诉 → 未申诉(100)[新申诉单]。注：已取消(130)为省平台侧操作（如运单作废等），我省平台只读同步该状态，不主动发起取消；UI层不提供"取消申诉"按钮。⚠️ 待确认: 原型中"待省平台反馈"+"反馈处理中"如何映射到API枚举。
• 关键验证点: 未申诉(100)状态下可发起申诉；异常项申诉中(abnormalDetails[].state=110)状态下不可重复发起同一异常项申诉；审核通过(110)后状态不可再变更（终态）；审核不通过(120)后可点击"重新申诉"发起新一轮申诉；已取消(130)为省平台外部操作设置的终态，我方系统只读；每种状态变更记录到处理记录时间线。

TP-F-004: 申诉详情弹窗 — 分组字段完整性

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求][漏测清单]
• 描述: 验证申诉详情弹窗包含5个分组：申诉信息、运单信息、异常信息、省平台反馈信息、处理记录。
• 关键验证点: 申诉信息分组含申诉单号/上报阶段/异常项/申诉原因/申诉状态/申诉时间/申诉人/申诉附件；省平台反馈信息含反馈结果/反馈时间/反馈意见；处理记录以时间线形式展示：操作人/操作时间/操作类型/操作内容。

TP-F-005: 申诉附件上传功能

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求][项目画像]
• 描述: 验证发起申诉时支持上传附件（如证明材料图片/PDF），附件上传功能正常。
• 关键验证点: 支持上传多个附件；附件格式支持常见类型(png/jpg/pdf)；附件大小有限制且超标时提示；上传后可在详情弹窗中查看/下载；上传失败有重试机制。

TP-F-006: 审核不通过(120)后重新申诉 — 补充材料再发起

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [需求]
• 描述: 验证申诉被省平台审核不通过(120)后，运营人员可补充材料，点击"重新申诉"发起新一轮申诉。
• 关键验证点: 审核不通过(120)状态下"重新申诉"按钮可见可用；重新申诉时原有申诉记录保留；新一轮申诉生成新的申诉单号；重新申诉可上传新的附件材料；新的申诉有独立的处理记录时间线。

TP-F-007: 17项核验（API文档定义）异常各自发起申诉

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 规则组合
• 来源: [需求]
• 描述: 验证第二次上报的17项核验（API文档§4.1定义：委托合同100/承运合同120/实时定位130/运单时间逻辑140/车辆资质150/道路运输证160/驾驶证170/从业资格证180/车辆重复190/司机重复200/车辆轨迹210/运费收款220/公司统一收款230/集中支付240/资金流水250/发票信息260/非通行车辆可开票270）每项核验异常均可独立发起申诉。⚠️ 待确认: 核验项从需求7类扩展为API文档17项，需确认每项是否均有独立申诉入口。
• 关键验证点: 每种核验异常项对应独立的申诉入口；申诉中(abnormalDetails[].state=110)的异常项信息与核验结果一致；不同异常项的申诉原因字段独立；某一异常项申诉不影响其他异常项。

TP-F-008: 从看板直接跳转申诉

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求]
• 描述: 验证从看板"操作"列点击"申诉"按钮，可跳转到申诉页面并自动填充运单号、异常项信息。
• 关键验证点: 看板"申诉"按钮点击后路由跳转正确；跳转后页面自动加载该运单的异常信息；运单号和异常项预填充正确；不需要运营人员手动查找运单。

TP-F-009: 申诉权限控制

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 权限控制
• 来源: [项目画像]
• 描述: 验证仅运营人员有权发起申诉和管理申诉记录，其他角色（司机/车队长/货主/财务）不能操作申诉功能。
• 关键验证点: 运营人员可见"申诉"按钮和申诉记录页面；司机端不可见申诉功能；财务人员可查看申诉记录但不可发起申诉；越权操作被正确拦截并记录审计日志。

TP-F-010: 申诉处理记录时间线展示

• 优先级: P2
• 类型: UI测试
• 覆盖维度: 数据校验
• 来源: [需求]
• 描述: 验证申诉详情弹窗中"处理记录"以时间线形式展示，每条记录包含操作人、操作时间、操作类型、操作内容。
• 关键验证点: 时间线按时间倒序排列；每步操作（发起申诉/省平台反馈/重新申诉）均有一条记录；操作时间精确到秒；操作类型准确（发起申诉/审核通过/审核不通过等）。

TP-F-011: 异常代码一览表匹配校验

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求]
• 描述: 验证需求文档中"异常代码一览表"定义的每种异常代码，在申诉页面中正确映射为对应的中文异常项名称。
• 关键验证点: 每种异常代码有明确的中文描述；异常代码与异常项名称一一对应；省平台返回的异常代码能被正确解析；未知异常代码有兜底展示（如显示原始代码+标注"未知异常"）。

TP-F-012: 申诉并发控制 — 同一异常项不可重复申诉

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 并发幂等
• 来源: [漏测清单]
• 描述: 验证同一运单同一异常项申诉中(abnormalDetails[].state=110)状态下不可再次发起申诉，防止重复提交。
• 关键验证点: 异常项申诉中(abnormalDetails[].state=110)状态下点击"申诉"按钮被禁用或提示"申诉处理中"；快速双击"提交申诉"按钮仅产生1条申诉记录；后端有状态校验，申诉中不可重新发起。

TP-F-013: 申诉超时处理 — 省平台长时间无反馈

• 优先级: P3
• 类型: 功能测试
• 覆盖维度: 弱网超时
• 来源: [漏测清单]
• 描述: 验证申诉提交后，省平台长时间无反馈时，系统有合理的超时处理和状态提示。
• 关键验证点: 申诉提交后超过一定时间（如7个工作日）无反馈时，系统给出"等待省平台复核中"的提示或超时告警；不自动变更申诉状态为通过/驳回；运营人员可查看申诉等待时长。

TP-F-014: 单次申诉仅支持单个异常项 — 申诉表单单选约束

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 规则组合
• 来源: [技术方案]
• 描述: 验证申诉表单中异常项选择器仅支持单选（radio或单选下拉），不可多选。根据API §3.3，verificationAbnormalItems参数"只支持单个异常项目申诉"。
• 关键验证点: 异常项选择器为单选控件（非复选框）；不可同时勾选多个异常项后提交；选择器交互方式明确为单选（radio button 或 single-select dropdown）。

TP-F-015: 多异常项运单逐次申诉 — 同一运单分别发起多次申诉

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 规则组合
• 来源: [技术方案]
• 描述: 验证同一运单存在两个或多个异常项（如"车辆资质150"和"资金流水250"同时异常）时，需分别对每个异常项发起独立申诉，每个申诉对应一个申诉单号。
• 关键验证点: 运单有2个异常项时，可分别发起2次申诉（每次选1个异常项）；每次申诉生成独立的申诉单号(complaintNumber)；申诉记录列表中该运单有2条独立申诉记录；不同异常项的申诉互不影响（一项通过另一项驳回各自独立流转）。

TP-F-016: 申诉接口 verificationAbnormalItems 参数单值校验 — 传入多个ID时接口拒绝

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 规则组合
• 来源: [技术方案]
• 描述: 验证调用 POST /appeal/insert 时，若 verificationAbnormalItems 传入多个异常项ID（如 "120,160"），接口应返回错误并拒绝提交。API §3.3 明确"只支持单个异常项目申诉"。
• 关键验证点: 传入逗号分隔的多个ID（如"120,160"）时接口返回错误；错误码明确指示"仅支持单个异常项申诉"；传入单个ID时接口正常处理；传入空字符串或null时接口返回参数缺失错误；前端在提交前已做单选校验（双保险）。

---

模块G: 上报日志 (9个测试点)

TP-G-001: 上报日志 — 按运单号/托运单号/货源单号模糊搜索

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求]
• 描述: 验证上报日志页面支持按运单号/托运单号/货源单号模糊搜索，快速定位相关日志。
• 关键验证点: 输入完整单号精确匹配；输入部分字符模糊匹配；输入不存在的单号显示空结果；三种单号搜索互不干扰。

TP-G-002: 上报日志 — 按上报阶段筛选

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求]
• 描述: 验证上报日志支持按"全部/第一次上报/第二次上报/第三次上报/ETC上传"筛选。
• 关键验证点: 每种阶段独立筛选数据正确；ETC上传有独立筛选项；默认"全部"展示所有阶段日志。

TP-G-003: 上报日志 — 按上报结果筛选

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求]
• 描述: 验证上报日志支持按"全部/成功/失败"筛选上报结果。
• 关键验证点: "成功"仅展示HTTP 2xx的日志；"失败"展示所有非成功日志(含超时/4xx/5xx)；筛选结果与实际日志记录一致。

TP-G-004: 上报日志 — 时间范围筛选

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求]
• 描述: 验证上报日志支持按开始时间-结束时间范围筛选日志记录。
• 关键验证点: 精确时间范围筛选数据正确；跨天/跨月筛选正常；开始时间>结束时间时给出提示或自动交换；不选时间范围默认显示全部。

TP-G-005: 上报日志列表字段完整性校验

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [需求]
• 描述: 验证上报日志列表展示的9个字段完整：序号、货源单号、运单号、托运单号、上报阶段、上报结果、接口URL、HTTP状态码、响应时间、上报时间、操作。
• 关键验证点: 接口URL完整展示（含域名和路径）；HTTP状态码为实际返回状态码（200/400/500等）；响应时间单位明确（ms）；上报时间为实际请求发起时间。

TP-G-006: 上报日志操作 — 弹窗查看完整请求/响应报文

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求]
• 描述: 验证点击日志"操作"列的详情按钮，弹窗展示完整的请求报文（Request）和响应报文（Response），用于问题排查。
• 关键验证点: 请求报文完整展示：URL、Method、Headers、Body；响应报文完整展示：Status Code、Headers、Body；JSON 报文格式化展示（缩进/语法高亮）；长报文支持滚动查看和复制。

TP-G-007: 上报日志全阶段覆盖 — 每个上报阶段的日志记录

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求][漏测清单]
• 描述: 验证每个上报阶段（第一次/第二次/第三次/ETC）以及自动修改字段接口的每次调用都在日志中有完整记录。
• 关键验证点: 第一次上报+自动修改字段接口均有日志；第二次上报+7类核验结果均有日志；第三次上报日志完整；ETC上传日志完整；自动重试的每次请求均独立记录。

TP-G-008: 上报日志失败记录的可追溯性

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 数据校验
• 来源: [漏测清单]
• 描述: 验证上报失败的日志记录足够详细，可通过日志定位失败原因——包括错误响应体、异常堆栈（如有）、重试次数等。
• 关键验证点: 失败日志包含完整的Error Response Body；超时日志标注"timeout"并记录超时时长；重试日志中标注当前是第几次重试；异常日志可关联到具体运单ID便于排查。

TP-G-009: 上报日志审计 — 操作人追踪

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 权限控制
• 来源: [项目画像][最佳实践]
• 描述: 验证上报日志中可区分自动触发上报和手动触发上报，并记录操作人信息。
• 关键验证点: 自动触发上报的日志标注"系统自动"或"auto"；手动触发上报的日志记录操作人用户名；手动上传的操作人信息与实际登录用户一致；审计能力满足合规要求。

---

跨模块测试点（7个测试点）

TP-X-001: 完整三阶段依赖链端到端验证 — 后端三重校验

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 状态流转 + 历史缺陷防御
• 来源: [历史缺陷][漏测清单]
• 描述: 端到端验证三阶段依赖链：装货完成→第一次上报成功→打款完成→第二次上报成功→开票完成→第三次上报成功。核心验证后端在每个阶段都做了前置状态校验。
• 关键验证点: 第1次上报失败→第2次上报接口拒绝；第2次上报失败→第3次上报接口拒绝；第1、2、3次顺序不可跳级；依赖链校验在后端实现（非仅前端控制）；每个阶段的阻断/通过状态独立。

TP-X-002: 多模块数据一致性 — 修改源数据后上报同步

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 数据校验 + 历史缺陷防御
• 来源: [历史缺陷][漏测清单]
• 描述: 防御 BUG-202607-03：验证上报数据字段溯源正确，修改来源表数据后各阶段上报能感知变更并使用最新值。
• 关键验证点: 修改司机信息→第一次上报使用最新司机信息；修改支付流水→第二次上报使用最新金额；修改发票信息→第三次上报使用最新发票数据；修改ETC信息→ETC上传使用最新数据；数据库查询日志可确认数据来源表，非缓存。

TP-X-003: 安徽运八全流程 — 正常运单完整上报链路

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 主流程
• 来源: [需求]
• 描述: 端到端验证一个安徽税源地运单从装货到ETC上传的完整三阶段+ETC上报链路，所有阶段核验通过，无异常。
• 关键验证点: 装货完成→第1次上报成功(绿色)→核验通过→自动修改字段→打款完成→第2次上报成功(核验全通过)→开票完成→第3次上报成功→税务抵扣→ETC上传成功；每个阶段看板数据正确更新；上报日志完整记录全链路。

TP-X-004: 非安徽税源地运单 — 全流程不上报

• 优先级: P0
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [需求][项目画像]
• 描述: 验证税源地为非安徽省（如云南=28）的运单，全部三个阶段和ETC上传均不触发上报。
• 关键验证点: 云南税源地运单装货完成不触发第1次上报；打款完成不触发第2次上报；开票完成不触发第3次上报；税务抵扣不触发ETC上传；看板中不显示该运单。

TP-X-005: 三阶段上报各省份数据隔离

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 权限控制
• 来源: [项目画像][历史缺陷]
• 描述: 验证多省份部署场景下，安徽运八上报数据与其他省份（如云南）上报数据完全隔离，互不干扰。
• 关键验证点: 安徽运单仅上报至安徽监管平台；云南运单仅上报至云南监管平台；省份代码各自独立（安徽=34、云南=28）；不同省份的上报日志和数据记录物理/逻辑隔离。

TP-X-006: 回单签收后自动流转上报 — 时序正确性

• 优先级: P2
• 类型: 功能测试
• 覆盖维度: 状态流转
• 来源: [需求][项目画像]
• 描述: 验证运单在回单签收→财务打款的时序下，第二次上报的触发时机为"打款完成"而非"回单签收"，时序正确。
• 关键验证点: 回单签收完成但未打款时，不触发第二次上报；财务打款完成后才触发第二次上报；上报时间戳与打款完成时间关系合理。

TP-X-007: 已上报运单不可取消或删除 [技术方案]

• 优先级: P1
• 类型: 功能测试
• 覆盖维度: 异常流程
• 来源: [技术方案]
• 描述: 验证上传至服务平台的运单不支持取消或删除操作。按主管部门要求，上传后的运单不允许修改任何信息，企业应在运单信息确认后再进行上报。服务平台在统计合规率时不会将未完结的运单计算在内。
• 关键验证点: 已上报运单在服务平台无"取消"或"删除"操作入口；API层面无取消/删除运单接口；尝试通过任何方式取消运单均被拒绝并有明确提示；未完结运单不影响合规率统计。

---

历史缺陷防御映射表

历史缺陷ID	防御测试点
BUG-202607-01（阶段依赖链断裂）	TP-B-005, TP-C-020, TP-D-005, TP-X-001
BUG-202607-02（重试幂等缺陷）	TP-B-014, TP-C-021, TP-D-009, TP-E-008, TP-F-012
BUG-202607-03（跨模块数据不一致）	TP-C-002, TP-C-003, TP-D-011, TP-X-002
BUG-202607-04（省份代码硬编码）	TP-B-004, TP-X-005

漏测清单覆盖映射表

漏测项	覆盖测试点
空值/Null	TP-B-018
金额精度	TP-C-002, TP-D-010, TP-E-007
重复提交/防抖	TP-B-014, TP-C-021, TP-D-009, TP-E-008
超时处理	TP-B-015, TP-B-016, TP-F-013
列表字段完整性	TP-A-008, TP-C-004, TP-D-002, TP-E-002, TP-F-002, TP-G-005
查询重置	TP-A-007
状态与按钮映射	TP-A-010, TP-B-009
多阶段依赖链	TP-B-005, TP-C-020, TP-D-005, TP-X-001
第三方核验逐项覆盖	TP-C-006 ~ TP-C-019（7类核验×通过+异常=14个测试点）+ TP-C-026 ~ TP-C-049（API文档12项补充核验×通过+异常=24个测试点），共覆盖API文档17项核验
重试+手动触发并发	TP-B-014, TP-C-021
跨模块数据一致性	TP-C-002, TP-C-003, TP-X-002
省份/区域配置隔离	TP-B-004, TP-X-005
上报数据字段溯源	TP-C-002, TP-D-011, TP-X-002
标签颜色映射	TP-A-009, TP-B-010, TP-C-005
详情弹窗分组完整性	TP-A-011, TP-B-011, TP-B-012, TP-C-004, TP-D-003, TP-E-003, TP-F-004
轨迹数据边界（2~2000）	TP-C-018, TP-C-019
申诉闭环	TP-F-001, TP-F-003, TP-F-006
操作日志可追溯	TP-G-005, TP-G-006, TP-G-007, TP-G-008, TP-G-009

---

⚠️ 待确认项：

1. 需求中"异常代码一览表"章节仅有标题无具体内容，需与产品确认完整的异常代码映射表后补充 TP-F-011 的详细验证数据。
2. 自动重试的具体间隔时间（5s/15s/30s 为假设值），需与技术方案确认后更新 TP-B-007, TP-C-022, TP-D-007, TP-E-006 中的重试间隔。
3. ETC税额边界值（0.01元 → 税额=0.00）的四舍五入规则需与财务确认，更新 TP-E-007。
4. 申诉超时告警阈值（假设7个工作日）需与产品确认，更新 TP-F-013。
5. 需求关联与冲突报告未识别到冲突项，建议在后续需求评审中人工确认安徽运八与现有云南运八上报逻辑是否存在字段/接口冲突。