Files
QaAutomationHub/knowledge_base/03_best_practices/data_reporting_cases.md
T
xst e34a3c64ce feat: knowledge sync — 安徽运八需求知识沉淀回写知识库
知识库更新:
- historical_defects.md: +4条数据上报领域真实缺陷模式
  (阶段依赖链断裂/重试幂等/跨模块数据不一致/省份代码硬编码)
- common_missed_scenes.md: +11条数据上报专项易漏场景
  (多阶段依赖/第三方核验逐项/重试并发/跨模块一致性/省份隔离等)
- data_reporting_cases.md: 新增数据上报类需求优秀用例范式
  (8大覆盖框架+5条示例用例+7项关键风险点)
- terminology.md: +14条数据上报领域术语

系统修复:
- case_pipeline.py: 注册 data_reporting_cases.md + order_manage_cases.md
- governance_audit.py: 更新 case_generate/AGENTS 关键词期望(旧→新架构)
- AGENTS.md/README.md/.claude: 补全缺失关键词,治理审计通过
- .claude/skills/case_generate/: 创建向后兼容别名 skill
2026-07-13 14:22:31 +08:00

5.1 KiB
Raw Blame History

数据上报类需求优秀用例范式

适用于网络货运平台向省级/国家级监管系统分阶段上报数据的场景(如安徽运八、云南运八等)。 重点不是照抄标题,而是学习以下覆盖结构:多阶段依赖链、第三方核验逐项覆盖、重试幂等、跨模块数据一致性、申诉闭环。

推荐覆盖框架

1. 汇总看板

  • 列表字段完整性(14+字段)
  • 多条件组合筛选(模糊搜索 + 4级下拉筛选)
  • 排序、分页、导出
  • 空结果提示
  • 不同状态下操作按钮差异化(申诉/进度/详情)

2. 多阶段上报依赖链

  • 前一阶段成功后自动触发下一阶段
  • 前一阶段失败/未完成时后续阶段被阻断(前端+后端双重校验
  • 每个阶段的数据完整性验证(子对象分组、必选/可选字段区分)
  • 数据来源溯源验证(上报字段来源于哪个系统模块)

3. 自动重试与告警

  • 失败自动重试(3次上限 + 间隔递增)
  • 重试全部失败后通知运营人员(站内信/系统消息)
  • 重试期间手动触发的幂等保护(分布式锁/幂等键)
  • 重试次数与结果的日志完整性

4. 第三方核验逐项覆盖

  • 每项核验(车辆资质/司机资质/资金流水/合同/轨迹等)独立设计通过+异常用例
  • 核验异常后可发起申诉
  • 特定异常类型的补充功能(如补传轨迹)
  • 异常代码一览表的覆盖度

5. 跨模块数据一致性

  • 上报数据 vs 运单管理模块
  • 资金流水 vs 账户管理/支付流水模块
  • 司机/车辆信息 vs 审核管理模块
  • 发票数据 vs 开票审核模块

6. 申诉闭环

  • 异常查询 → 发起申诉 → 跟踪监管反馈 → 合规判断 完整闭环
  • 状态流转:未申诉 → 申诉中 → 申诉通过/驳回 → 重新申诉
  • 处理记录时间线展示
  • 多异常项独立申诉
  • 核验通过时申诉入口隐藏

7. 上报日志

  • 按上报阶段/结果/时间范围查询
  • 完整请求/响应报文查看(JSON格式化)
  • 日志分页与字段完整性

8. 区域与配置差异化

  • 省份代码根据目标省份动态获取(非硬编码)
  • 行政区划代码与上报目标一致
  • 多省份部署场景下数据隔离

示例用例(安徽运八模式)

用例编号 模块 用例标题 优先级 类型 前置条件 测试步骤 测试数据 预期结果 备注
RPT_FR_001 第一次上报 装货完成后系统自动触发上报(全字段完整性验证) P0 功能测试 1.运单已接单 2.车辆/司机/货物/托运方/收货方信息完整 3.司机确认装货完成 1.司机APP确认装货完成 2.回管理端查看上报状态 完整运单数据(建单13+托运人7+收货方5+司机13+车辆19+货物+保险) UI:列表出现该运单,状态:上传中(蓝)→已上传(绿)。数据:请求体含完整子对象,HTTP 200,DB状态更新 全字段覆盖
RPT_SR_001 第二次上报 资金流水单号重复→系统自动拦截 P0 功能测试 系统中已存在相同流水号的记录 1.创建新运单打款但流水号重复 2.触发第二次上报 重复流水号 UI:系统提示"流水单号已使用请核实";上报被阻止。数据:流水号唯一索引生效;接口未被调用 幂等保护
RPT_SR_002 第二次上报 车辆轨迹合规异常→补传轨迹→重新核验通过 P1 功能测试 第二次上报后轨迹合规核验异常 1.点"补传轨迹" 2.上传补充GPS点位 3.提交 4.等待重新核验 补充轨迹GPS文件 UI:补传轨迹按钮可见;上传后提示成功等待核验;核验通过后异常消除。数据:补传轨迹追加到原数据;重调核验接口 异常恢复
RPT_AP_001 异常申诉 核验异常→申诉→驳回→重新申诉→通过 完整闭环 P1 功能测试 运单第二次上报核验异常 1.发起申诉 2.监管驳回 3.补充材料重新申诉 4.监管通过 申诉原因、补充材料 UI:状态流转完整;处理记录时间线展示。数据:申诉记录完整保留,每次操作有日志 闭环验证
RPT_CM_001 通用跨模块 第二次上报资金流水与账户管理支付流水数据一致性 P1 功能测试 运单已完成打款 1.记录账户管理支付流水 2.触发第二次上报 3.核对上报详情资金流水 支付金额/流水号/时间/收款方 UI:上报详情资金流水与账户管理一致。数据:上报请求体资金流水来源于支付流水表,流水号完全匹配 跨模块一致性

关键风险点

风险项 等级 防御措施
阶段依赖链断裂 P0 前后端双重校验前置上报状态
重试幂等缺陷 P1 分布式锁/幂等键,手动+自动互斥
跨模块数据不一致 P1 上报数据实时从源表获取,不使用缓存
省份代码硬编码 P1 省份代码从配置中心动态获取
资金流水金额不匹配 P1 上报前校验合同金额与实付金额一致性
上报接口超时 P2 自动重试+超时告警+异步处理