xst/QaAutomationHub
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: /qe-fleet run 安徽运八需求 + 系统坑修复

Browse Source 
系统修复:
- fleet_runner.py: Windows UTF-8 编码兼容（reconfigure stdout/stderr）
- fleet_runner.py: run 命令自动生成合并清单供导出使用
- fleet_manifest.py: 新增 save_merged_manifest() 保存统一清单
- fleet_config.yml: 修复 YAML keywords 格式（block sequence → flow sequence）
- 恢复被误删的知识库文件(payment_flow_cases, marketing_activity_cases)

QE Fleet 产物 (安徽运八需求):
- 153个测试点 + 53条可执行测试用例
- 需求分析/风险评估/测试策略/质量裁决（PASS）
- Excel 导出 + 版本快照 v2
- 确认结论文件已归档
This commit is contained in:
xst
2026-07-13 09:49:54 +08:00
parent b958b75899
commit acdb441507
77 changed files with 4134 additions and 1597 deletions
Download Patch File Download Diff File Expand all files Collapse all files
output/analysis/安徽运八需求_关联与冲突.md
+18
View File
@@ -0,0 +1,18 @@
# 安徽运八需求 关联需求与冲突检查
## 目标需求
- `source_docs\requirements_raw\安徽运八需求.docx`
## 项目画像
- `knowledge_base\00_project\project_profile.md`
## 关联技术方案
- 未识别到同主题技术方案文档。
## 关联需求识别
| 序号 | 关联需求 | 相似度 |
| :--- | :--- | :--- |
| 1 | `source_docs\requirements_raw\网货企业端接口文档（最新）.pdf` | 0.0696 |
## 潜在冲突与修改建议
- 暂未识别到明显冲突条目。建议在需求评审时继续人工确认。
output/analysis/安徽运八需求_分析.md
+106
View File
@@ -0,0 +1,106 @@
# 安徽运八需求 分析报告
> 生成时间: 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 | 上报接口超时或不可用影响业务流程，需重试+告警兜底 |
output/analysis/安徽运八需求_测试数据.md
+18
View File
@@ -0,0 +1,18 @@
# 安徽运八需求 测试数据
> 本文件由 data-builder Agent 自动生成，为测试用例提供精确数据支持。
## 自动提取的候选数据
### 金额/数值
- `3%`
## 需要人工补充的数据
| 数据类别 | 示例值 | 说明 | 状态 |
| :--- | :--- | :--- | :--- |
| 测试账号 | - | 不同角色的测试账号 | ⚠️ 待补充 |
| 商品数据 | - | 测试商品ID/SKU | ⚠️ 待补充 |
| 券/积分模板 | - | 测试券模板ID | ⚠️ 待补充 |
| 边界值 | - | 金额/数量/时效的边界 | ⚠️ 待补充 |
| 状态枚举 | - | 各对象的状态枚举值 | ⚠️ 待补充 |
output/analysis/安徽运八需求_测试策略.md
+22
View File
@@ -0,0 +1,22 @@
# 安徽运八需求 测试策略
## 1. 测试金字塔
| 层级 | 占比 | 覆盖重点 | 工具 |
| :--- | :---: | :--- | :--- |
| L1 单元测试 | 40% | 核心逻辑、计算、状态机 | 开发自测 |
| L2 API 测试 | 35% | 接口契约、参数校验、权限、幂等 | Postman/Pytest |
| L3 UI 测试 | 20% | 主流程、关键交互、端到端 | Playwright/Selenium |
| L4 手工探索 | 5% | 易用性、视觉、非确定性场景 | 人工 |
## 2. P0 必测清单
## 3. 优先级覆盖规则
| 优先级 | 覆盖要求 | 评审标准 |
| :--- | :--- | :--- |
| P0 | 100% 覆盖，不可遗漏 | 必须包含正向+异常+边界+幂等 |
| P1 | ≥ 90% 覆盖 | 必须包含正向+异常 |
| P2 | ≥ 80% 覆盖 | 至少覆盖主流程+关键异常 |
| P3 | ≥ 60% 覆盖 | 覆盖典型场景 |
output/analysis/安徽运八需求_质量裁决.md
+12
View File
@@ -0,0 +1,12 @@
# 安徽运八需求 质量裁决
## 裁决结果: ✅ PASS
**裁决理由**: 用例数量: 8，覆盖率达标
- 用例数量: 8
- 裁决时间: 2026-07-13T01:33:01.582202+00:00
## 后续步骤
- ✅ 可执行 `/qe-fleet export` 导出 Excel
output/analysis/安徽运八需求_风险评估.md
+18
View File
@@ -0,0 +1,18 @@
# 安徽运八需求 风险评估报告
> 生成时间: 2026-07-13T01:33:01.552872+00:00
## 风险概览
- 总风险项: 2
- P0 高风险: 0
- P1 中风险: 1
## 风险矩阵
| 风险ID | 类别 | 可能性(1-5) | 影响度(1-5) | 风险评分 | 等级 | 冲突放大 |
| :--- | :--- | :---: | :---: | :---: | :---: | :---: |
| RISK-FINANCIAL | 资损 | 2 | 5 | 10 | **P1** | 否 |
| RISK-AVAILABILITY | 可用性 | 2 | 4 | 8 | **P2** | 否 |
## 风险缓解建议
output/analysis/新人礼需求_关联与冲突.md
-16
View File
@@ -1,16 +0,0 @@
# 新人礼需求 关联需求与冲突检查
## 目标需求
- `source_docs/requirements_raw/新人礼需求.docx`
## 项目画像
- `knowledge_base/00_project/project_profile.md`
## 关联技术方案
- `source_docs/technical_solutions/新人礼技术方案.docx`
## 关联需求识别
- 未识别到相似度达到阈值的历史需求文档。
## 潜在冲突与修改建议
- 暂未识别到明显冲突条目。建议在需求评审时继续人工确认。
output/analysis/新人礼需求_分析.md
-111
View File
@@ -1,111 +0,0 @@
# 新人礼需求分析
## 背景与目标
本期需求围绕“新人礼”活动能力建设，目标是在平台端和商家端支持配置新人礼活动，并在 C 端针对符合新人条件的用户展示领取入口与发放优惠券奖励，提升新注册用户的首单转化。
技术方案补充了两个关键限制：
- 同一时间仅允许存在 1 个进行中的新人礼活动。
- 每个新人礼活动仅允许绑定 1 张优惠券，发放结果需落新人礼发放记录表。
## 范围与边界
### 范围内
- 平台端“营销-新人有礼”列表、查询、新建、编辑、查看、失效、删除。
- 商家端“营销-新人有礼”同构能力。
- 新人礼活动配置字段校验：活动名称、活动时间、活动奖品、优惠券选择。
- 优惠券选择范围控制：平台端仅选平台券，商家端仅选本店铺优惠券。
- C 端首页和门店首页的新人礼弹窗检查与领取。
- 发放成功后的优惠券入账和发放记录落库。
- `ua/newGift/check` 与 `ua/newGift/send` 对应的资格校验和发放行为。
### 范围外
- 积分类型新人礼，需求和技术方案均明确“暂不支持”。
- 下单后退款再重新认定为新人场景，技术方案明确“暂不支持下单后退款场景”。
- 多奖品、多券组合、多人拼抢同一活动池等扩展玩法。
## 用户角色与前置条件
- 平台运营：维护平台维度新人礼活动。
- 商家运营：维护店铺维度新人礼活动。
- C 端用户：登录后触发首页或门店首页新人礼检查与领取。
- 后端系统：负责活动状态判断、资格校验、优惠券发放、发送日志写入。
前置条件：
- 已存在投放中、未过期、领取方式为“用户领取”的优惠券。
- 用户已登录，且能获取平台维度与店铺维度的历史下单信息。
- 发券接口可用，优惠券中心返回的券状态准确。
## 关键业务规则
1. 平台端和商家端都可以配置新人礼活动，但优惠券范围必须与端侧归属一致。
2. 活动名称最多 50 个字。
3. 活动开始时间必须大于等于当前时间，结束时间必须大于开始时间。
4. 活动奖品当前仅支持优惠券，且每个活动仅能关联 1 张优惠券。
5. 平台维度同一时间仅允许 1 个进行中的平台新人礼活动；店铺维度同一时间每个店铺仅允许 1 个进行中的门店新人礼活动。
6. 新人判定按订单提交结果范围判断：平台新人礼查询平台范围订单，店铺新人礼查询当前店铺订单；若用户从未提交过订单，或历史订单最终状态均为交易关闭（包括未支付取消、超时未付、已退款订单等），仍视为新人。
7. 用户登录首页时，若存在进行中的新人礼活动且用户未领取过，则展示新人礼弹窗。
8. 门店首页只对门店新人展示门店新人礼弹窗。
9. 若同时存在弹窗广告，新人礼弹窗必须先于广告弹窗展示。
10. 用户点击立即领取成功后，奖励进入“我的优惠券”，同时写入新人礼发放记录。
11. 活动“已结束”和“已失效”并存时，页面优先展示“已失效”。
12. 活动失效后状态展示为“已失效”，并支持后续删除。
13. 用户领取平台新人礼后，若仍满足门店新人条件，允许继续领取门店新人礼。
## 主流程描述
1. 运营在平台端或商家端进入“营销-新人有礼”列表页。
2. 运营新建活动，填写活动名称、活动时间并选择 1 张符合条件的优惠券。
3. 系统校验时间、优惠券范围、优惠券状态和活动并存规则，保存活动。
4. 活动进入“未开始”或“进行中”状态，列表页按状态展示可操作按钮。
5. C 端用户登录平台首页或门店首页时，调用资格检查接口。
6. 若存在进行中的匹配活动且用户符合新人条件且未领取过，则展示新人礼弹窗。
7. 用户点击“立即领取”，系统发放优惠券并记录发放日志。
8. 发放成功后，用户可在个人中心优惠券列表查看奖励。
## 跨需求关联与冲突修订建议
- 当前未识别到需要纳入本次评审的关联需求，也未发现需要基于历史需求执行的规则冲突修订。
- 当前无需对历史需求做口径覆盖修订，但仍需重点防御营销类公共风险：
- 重复点击导致重复发放。
- 前端传参篡改导致越权选券或跨店铺发券。
- 状态变更与页面展示不一致。
## 技术方案补充约束
- `ua/newGift/check` 负责资格检查，应重点验证平台维度和店铺维度“新人”判定口径。
- `ua/newGift/send` 负责发券，应重点验证幂等、防重复领取、失败原因记录和成功落库。
- 数据模型拆分为主表、礼物关联表、发放记录表，说明测试不能只看页面成功提示，还要覆盖：
- `new_gift` 主表活动状态和有效性字段。
- `new_gift_detail` 活动与券的绑定关系。
- `new_gift_send_log` 发放成功或失败记录。
- 技术目标给出用户响应 RT 1000ms，应至少对资格检查和领取动作补充性能基线关注。
## 产品确认口径
- 活动并存范围：平台维度同一时间仅允许 1 条进行中的平台活动；店铺维度同一时间每个店铺仅允许 1 条进行中的门店活动。
- 新人判定口径：若用户从未提交过订单，或历史订单最终状态均为交易关闭（包括未支付取消、超时未付、已退款订单），仍视为新人。
- 状态展示优先级：活动“已结束”和“已失效”并存时，优先展示“已失效”。
- 平台礼与门店礼关系：用户已领取平台新人礼后，只要满足门店新人条件，仍允许领取门店新人礼。
## 项目差异化测试约束
- 平台端、商家端、C 端是三套角色链路，必须覆盖角色隔离和数据隔离。
- 这是典型营销发券能力，需重点覆盖越权选券、重复发放、状态错发和资损场景。
- 预期结果必须同时覆盖 UI 反馈和后台状态变化，特别是活动状态、券领取结果、发放日志。
## 风险点与确认结果
- 风险点：重复点击“立即领取”或接口重试导致同一用户重复发放优惠券。
- 风险点：商家端错误选择了其他店铺的优惠券，导致跨店资损或越权发券。
- 风险点：活动失效、已结束、已删除三个状态口径不清，可能导致列表按钮和实际行为不一致。
- 风险点：平台新人和店铺新人的判定依赖历史订单数据，若口径不清，容易误发或漏发。
- 风险点：同一时间仅允许 1 个进行中的活动，如果平台端和商家端同时配置活动，范围口径不清会导致规则冲突。
- 确认结果：平台端和商家端活动可以并存，但约束粒度为“平台一条、每店铺各一条”。
- 确认结果：未支付取消、超时未付、已退款等最终交易关闭单据不影响新人资格。
- 确认结果：活动“已结束”和“已失效”同时成立时，页面优先展示“已失效”。
- 确认结果：已领取平台新人礼的用户，若满足门店新人条件，仍允许继续领取门店新人礼。