xst/QaAutomationHub
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
QaAutomationHub/output/analysis/安徽运八需求_原型与接口分析.md
T

8.2 KiB
Raw Permalink Blame History

安徽运八需求 — 原型&接口文档交叉分析

分析时间: 2026-07-13 原型: E:\WeChat\xwechat_files\wxid_2n9ko0aq1th822_44c3\msg\file\2026-07\anhuibaba_index.html 接口文档: E:\Downloads\网货企业端接口文档（最新）.pdf (V1.0.2, 2023-04) 需求文档: source_docs/requirements_raw/安徽运八需求.docx

一、关键发现总览

# 发现 严重程度 影响范围
1 核验项数量：需求7类 vs API文档17项 P0 阻断 第二次上报核验覆盖
2 申诉状态枚举三套不一致 P1 申诉模块全部用例
3 第三次上报列表字段与原型不一致 P1 第三次上报列表验证
4 详情弹窗字段分组/数量与原型不一致 P1 所有详情弹窗用例
5 API新增里程申诉接口 P2 遗漏功能覆盖
6 看板申诉状态下拉值与需求不一致 P1 看板筛选用例
7 ETC发票详情含"不含税金额"字段 P2 ETC详情用例
8 原型看板有checkbox勾选列 P3 看板交互用例
9 接口文档异常代码枚举vs需求异常代码 P1 异常申诉用例

二、核验项对照（重大差异）

需求文档描述的7类核验

  1. 运单重复核验
  2. 车辆资质核验
  3. 司机资质核验
  4. 集中支付核验
  5. 资金流水核验
  6. 合同核验
  7. 车辆轨迹合规核验

API文档定义的17项核验（§4.1 异常项ID对照表）

Code 名称 需求是否提到
100 委托合同 合并为"合同核验"
120 承运合同 合并为"合同核验"
130 实时定位 ❌ 未提及
140 运单时间逻辑 ❌ 未提及
150 车辆资质 ✅
160 道路运输证 隐含在车辆资质
170 驾驶证 隐含在司机资质
180 从业资格证 ✅ 司机资质
190 车辆重复 ❌ 未提及（需求仅有运单重复）
200 司机重复 ❌ 未提及
210 车辆轨迹 ✅
220 运费收款 ❌ 未提及
230 公司统一收款 ❌ 未提及
240 集中支付 ✅
250 资金流水 ✅
260 发票信息 ❌ 未提及（第三次上报相关）
270 非通行车辆可开票 ❌ 未提及

⚠️ 待确认: 需求文档将17项核验归纳为7类是否合理？测试点应按需求7类还是API 17项逐项覆盖？建议按API 17项逐项覆盖（因为每项有独立的核验结果和申诉入口）。

三、申诉状态枚举对照

需求文档 HTML原型 API文档(§4.4) API Code
未申诉 未申诉 未申诉 100
申诉中 待省平台反馈 — —
— 反馈处理中 — —
申诉通过 申诉通过 审核通过 110
申诉驳回 申诉驳回 审核不通过 120
— — 已取消 130

⚠️ 待确认:

  • 需求"申诉中"被原型拆分为"待省平台反馈"+"反馈处理中"两个状态——哪个是最终版本？
  • API有"已取消"状态(130)但需求和原型均未体现——是否支持申诉取消？
  • 看板筛选下拉值以哪个为准？

四、列表字段差异

第三次上报列表

需求字段 原型字段 差异
车牌号 ✅ —
司机姓名 ✅ —
托运方名称 ✅ —
— 税率 需求未列出
— 销售方名称 需求未列出
— 受票方名称 需求未列出
— 油气票张数 需求未列出

原型比需求多4个字段（税率、销售方名称、受票方名称、油气票张数），共15列（含checkbox）。

第一次上报列表

需求与原型一致，14字段 + checkbox。

ETC上传列表

原型字段（10列+checkbox）：货源单号/运单号/托运单号/ETC发票号/交易金额/入口收费站/出口收费站/交易时间/上传状态/操作 缺少: 车牌号、司机姓名、托运方名称（需求中列出）、税率（需求中列出）

五、详情弹窗字段差异

第一次上报详情弹窗

分组 需求字段数 原型字段数 差异
建单信息 13 10 原型无"上游企业委托运输单号""网络货运经营者名称""统一社会信用代码""道路运输经营许可证编号""运输组货方式代码"等
托运人信息 7 8 原型多了货物名称/重量/体积
收货方信息 5 8 原型多了联系人/电话/收货时间/签收状态
司机信息 13 6 原型大幅简化
车辆信息 19 8 原型大幅简化
货物信息 4/条 8/条(卡片式) 原型多了件数/单价/包装方式/危险货物标志
保险信息 2 7 原型多了保险类型/金额/有效期起止/保单状态
异常信息 4 4 一致

⚠️ 待确认: 需求文档字段定义来自接口文档（https://www.showdoc.com.cn/2210641821476236/9919735893682511），原型可能是简化版。详细字段数以接口文档为准还是以原型为准？

第二次上报详情弹窗

分组 需求 原型 差异
资金流水 10字段 11字段 原型多了"实际支付金额"
车辆轨迹 6字段/点 未展示 原型弹窗缺失车辆轨迹信息！
油气发票 — 有 需求未在第二次上报中提及油气发票

⚠️ 待确认: 原型第二次上报详情弹窗中车辆轨迹信息缺失——是原型bug还是实际不展示？

第三次上报详情弹窗

需求分组：运单信息/发票信息(17字段)/油气发票信息(可选)/异常信息 原型分组：运单信息/发票信息(10字段)/ETC发票信息(可选)/异常信息

  • 差异: 原型把"油气发票"换成了"ETC发票信息"，发票信息字段从17减为10

六、API接口清单

接口文档（V1.0.2）定义了以下接口：

接口 URL 方法 说明
获取token /sys/login POST JWT认证
上传申诉附件 /appeal/uploadFile POST 文件上传
提交申诉运单 /appeal/insert POST 发起申诉
查询异常运单信息 /verificationSummary/page POST 分页查询，含abnormalDetails
查询申诉进度 /appeal/page POST 分页查询，含审核状态/审核人/取消/撤回
查询运单核验详情 /verificationSummary/verificationDetail POST 单运单核验明细列表
查询发票合规 /verificationSummary/cargoOwnerInvoiceInfo POST 判断托运人发票是否系统核验合规
运单里程核验查询 /verificationSummary/mileageVerificationInfo POST 批量查询运单里程核验状态
运单里程申诉 /mileageAppeal/insert POST 需求未提及的新功能！

关键API数据结构

异常运单查询响应 (verificationSummary/page)

pageRecords[]:
  freightSheetNumber, appealStateId/Name, verificationAbnormalItem,
  createTime, lastVerifyTime, firstVerifyTime, vehicleNumber,
  driverName, driverIdCard, verifyStateId/Name,
  abnormalDetails[]:
    id (异常项ID), name (异常项名称), message (异常原因),
    time (异常时间), state (100=未申诉, 110=申诉中)

核验详情响应 (verificationSummary/verificationDetail)

details[]:
  verificationCode (核验项编码), verificationName (核验项名称),
  verificationState (核验状态), verificationStateId,
  verificationTime, message (核验信息)

七、需要更新的测试资产

测试点更新

  1. TP-C-006~TP-C-019: 将"7类核验"扩展为"17项核验"逐项覆盖（+20个测试点）
  2. TP-F-xxx: 申诉状态枚举对齐（确认最终版本后更新）
  3. TP-D-002: 第三次上报列表字段数修正为原型字段数
  4. TP-E-xxx: ETC上传列表字段对齐
  5. 新增TP: 里程申诉功能、发票合规查询功能
  6. TP-A-xxx: 看板申诉状态下拉值对齐

测试用例更新

  1. 核验项相关用例从14条扩展到34条（17项×2 pass+exception）
  2. 申诉状态相关用例枚举值对齐
  3. 第三次上报列表字段验证用例更新
  4. 新增里程申诉用例
  5. 新增发票合规查询用例

需求分析更新

  1. 核验项从7类更新为17项
  2. 申诉状态枚举标注三版本差异
  3. 新增API接口清单
Reference in New Issue View Git Blame Copy Permalink