Files
Yb-QaAutomationHub/output/analysis/安徽运八需求_原型与接口分析.md

197 lines
8.2 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 安徽运八需求 — 原型&接口文档交叉分析
> 分析时间: 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接口清单