group_xinghuo_jinrong/docs/memory/tests/2026-09-13-customer-trade-e2e

TEST-CT-001 · 客户线交易（申购 / 赎回 / 转换 T+1 + 对话挂单 + 交易中心）端到端包

当前结论：本轮新增 203 用例 · 162 PASS / 6 FAIL / 2 SKIP / 33 INFO；6 条 FAIL 收敛为 2 个缺陷（P0 鉴权越权 · P1 R4 需揭示在交易通道未强制），另有 1 项潜在风险 + 1 项测试资产腐化 + 1 项既有基线不一致。 业务代码全程零改动，按「先报告、确认后再修」交付。

与前三轮的口径差异（本轮的重点）：此前 E2E 只验「页面渲染出来 + 无 4xx/5xx」，页面上的数字是否正确未验证（CHAT-1~4 四条真缺陷即由此漏掉，见 TODO.md:236-239）。本轮逐条把前端渲染值与后端 raw 响应核对到分（B3.2 总资产 Δ 恰等于提交金额、B4.1 交易明细行文本对齐、A 侧四条写链同断言）。

---

产物

产物	路径	位置
企业级测试日志	TEST-LOG-2026-09-13-CT-001.md	本包
客户交易 API 真实 HTTP 冒烟（155 用例）	scripts/dev/customer_trade_e2e_smoke.py	仓库内（本轮新建）
浏览器 E2E 共用骨架	scripts/e2e/harness.mjs	仓库内（本轮新建）
客户交易浏览器 E2E（48 用例）	scripts/e2e/12-customer-trade.mjs	仓库内（本轮新建）
顾问前端浏览器回归（17 用例）	09-advisor-pages.mjs	仓库外 C:/Users/Windows/e2e-jinrong/
风控前端浏览器回归（21 用例）	10-risk-pages.mjs	仓库外
跨角色直达/菜单隔离（9 用例）	11-cross-role.mjs	仓库外
结果明细（原始数据）	_raw/ —— 逐用例矩阵 + JSON + 截图	本包

TODO.md:197 的 P0「E2E 最小集进仓库」本轮部分关闭：客户线两支脚本已入库（原先一支都不在仓库里）。 三支回归脚本仍在仓库外 —— 这是刻意的（不改 web/package.json、不新增浏览器依赖），代价已由本轮实测暴露：前端登录页重写后它们集体失效（见日志 §8 T1）。

结果明细 _raw/（逐用例原始记录，未加工）

文件	内容	用例	结果
_raw/ct-api-report.md	客户交易 API 明细矩阵（--report 原生输出）	155	122 PASS / 6 FAIL / 1 SKIP / 26 INFO
_raw/results-12-customer-trade.json	客户前端逐用例（含 console / pageerror / HTTP≥400 / 请求响应采集）	48	40 PASS / 0 FAIL / 1 SKIP / 7 INFO
_raw/shots/	本轮 11 张页面截图取证	—	—

ct-api-report.md 由脚本 --report 直接落盘；results-12-customer-trade.json 是脚本 writeResults() 的原产物。两者均原样搬运、未加工。

---

一眼结论

跑道	用例	PASS	FAIL	SKIP	退出码
A 客户交易 API（真实 HTTP + 真实 MySQL）	155	122	6	1	1
B 客户前端（真浏览器 + 真实 LLM）	48	40	0	1	0
合计	203	162	6	2

业务面	状态
下单闸门（本人 / 归属顾问 / risk_demo 放行；非本人 / 非归属 403；缺 X-Agent-Type 401）	✅ 全绿
申购放行写链（core_trade + core_share_lot + core_holding + 读侧 四链同断言）	✅ 全绿
赎回放行 · FIFO 跨档扣减 · 费率分项 · 超份额 400 · 无净值 503	⚠️ 本轮未覆盖 —— CT6 整组在首条断言前提前返回（库内 T+2 可用份额不足），赎回写路径本轮无证据，见下
转换受理 202（T 日不扣份额）· 跨主体 400 · 幂等 · 撤单 owner/scope 双闸门	✅ 全绿
转换管理端点（risk_officer 专属 · latest_nav_date 与库一致 · 并发锁 409）	✅ 全绿
读侧对账（holdings / trades / products 与库逐项一致 · 无敏感字段原文 · limit 边界）	✅ 全绿
对话线（SSE 帧序 · 挂单不写库红线 · 序号续槽 · R4 不生成挂单）	✅ 全绿
前端渲染值对账（总资产 Δ · 明细行文本 · 事件派发/不派发 · 错误态）	✅ 全绿
鉴权：roles 注入提权	❌ FAIL ×2 → 缺陷 P0
适当性：R4「需揭示」在交易通道未被强制	❌ FAIL ×4 → 缺陷 P1

交叉印证成立：P1 在申购（CT4-01/02）与转换（CT7-07/7-07b）两条通道同一根因复现，且前端 tradeEligibility.ts、对话清单、products API 三处都已判 R4 不可自助 —— 仅交易网关这一条通道漏判，说明不是设计分歧而是单点实现缺失。

---

复现三连

# 0) 前置：uvicorn 8000 + Vite 5173 + Redis 6380（Redis 必须起，序号续槽走真实抽槽路径）
curl -s http://127.0.0.1:8000/api/ready        # 期望 ok=true, redis=true

# 1) 类型闸门 + 单测基线（比浏览器便宜得多，先跑）
cd web && npm run build && cd ..               # 期望退出码 0
python -m pytest tests/test_trade_gateway.py tests/test_trade_flow_service.py \
                 tests/test_trade_action_service.py tests/test_convert_confirm.py -q   # 期望 76 passed

# 2) 快照（跑前；跑后还原，见下）
MD=/c/tools/mysql/mysql-8.0.27-winx64/bin
$MD/mysqldump -h127.0.0.1 -uroot -p jinrong_core \
  core_trade core_holding core_share_lot core_convert_request core_convert_lot_detail \
  --single-transaction --add-drop-table > /tmp/ct-snapshot.sql

# 3) Part A 真实 HTTP E2E（退出码 0 全过 / 1 有 FAIL / 2 前置失败）
python scripts/dev/customer_trade_e2e_smoke.py --report /tmp/ct-api.md
python scripts/dev/customer_trade_e2e_smoke.py --only CT2 --only CT4   # 单组复跑

# 4) Part B 真浏览器 E2E（须 Vite 5173；app 无 CORS，浏览器不能直连 8000）
node scripts/e2e/12-customer-trade.mjs        # Playwright 由 PW_HOME 解析，不装依赖

# 5) Part C 回归复跑（三支共用同一 5173，必须串行 —— 脚本内切角色会互相顶掉 localStorage）
cd C:/Users/Windows/e2e-jinrong && node 09-advisor-pages.mjs && node 10-risk-pages.mjs && node 11-cross-role.mjs
python scripts/dev/risk_e2e_smoke.py --only R6      # 借风控视角反向印证同一批 convert 语义

# 6) 还原并核对（用 CT12-01 的计数对照；本轮实测 5 表精确回到首值）
$MD/mysql -h127.0.0.1 -uroot -p jinrong_core < /tmp/ct-snapshot.sql

2 条 SKIP —— 无一是应用缺陷，但其中一条是覆盖缺口

SKIP	性质	说明
A/CT6-01 赎回放行与金额复算	覆盖缺口（脚本设计疏漏）	不只是一条用例被跳过 —— 它是 CT6 组的唯一一条记录，组内其余断言随 return 一并未执行。原因是用例把申报量写死为 35000，而库内 T+2 可用份额只有 15000.0000
B/B3.3 首页持仓只数 +1	数据耗尽（非缺陷）	标的 PROD-510300 本轮已持有，只数不变属预期。成因是多轮 E2E 已把可自助未持有品买空 —— 脚本据此把该例判 SKIP 而非 FAIL 是正确的

---

未覆盖 / 已声明的缺口

0. ⚠️ 赎回写路径整组未覆盖（本轮最大缺口） —— CT6 组在 customer_trade_e2e_smoke.py:1250 提前 return：t2_lots(CUST-9527, PROD-005827) 的 T+2 可用批次合计仅 15000.0000，低于用例计划的申报 35000。脚本正确地降级为 1 条 SKIP 而非伪造 PASS，但后果是 FIFO 跨档扣减、费率分项复算、超份额 400 INSUFFICIENT_SHARES、无净值 503 NAV_NOT_READY 四条断言一条都没跑。 连带影响：CT10-07 赎回后读侧与快照一致 的 PASS 是空断言（CT6 未发生赎回 ⇒ 状态本就不变），不得计入赎回能力的证据。 修复方向（只写方向）：把 CT6 的申报量改为由库内事实推导（如 min(total_avail, 跨两档的最小值)）而非写死 35000 —— 本轮脚本在这一点上仍留有写死值，是设计疏漏。未动手。

1. Redis 容灾降级路径未验证 —— 计划里的「可选对照轮」（停 Redis 复跑 CT11 组，验证 restore_flow_from_context 兜底）本轮未执行。主口径（Redis 起）已全绿，但降级路径的正确性本轮无证据。

2. _maintain_lots 静默失败路径未被触发 —— 本轮四条写链全部同断言通过（R1 风险点的最坏情况未出现），但该函数整段 try 吞异常的结构性风险仍在，本轮只是没踩到。

3. 浏览器结论均在 reload() 之后成立 —— harness.mjs:176-179 的 reload 是对仓库外 BUG-1 的既有绕过手段。B11.1 已用不 reload 的真实登录路径反测（无 ErrorBoundary、三 Tab 就位），但其余用例的首屏结论仍以 reload 后为准。

4. 三支回归脚本仍在仓库外，他人 clone 拿不到脚本本体（结论可查阅，不可重跑）。

5. B7 取样点重合 —— 本轮「未持有品」与「R4 品」恰为同一只 PROD-003095，故「未持有 ⇒ 赎回 disabled」与「R4 ⇒ 申购 disabled」两条结论落在同一点上，没有取到「未持有且非 R4」的干净样本（成因同 B3.3：可自助未持有品已被多轮 E2E 买空）。B7.1 的按钮文案 赎回（无持仓） 仍独立证明了赎回闸门。

---

附：本轮发现（只报告，未修）

编号	级别	一句话	落点
P0	高	/api/auth/login 无条件信任调用方传入的 roles，可自造任意角色 token	app/gateway/jwt_service.py:118-120 · app/api/auth.py
P1	中	R4「需揭示」产品在交易网关被当普通放行，申购与转换两通道同时漏判	app/gateway/trade_gateway.py:534
L1	低	幂等键相同但请求体不同 → 静默返回原单，调用方无从察觉	app/service/convert/*
T1	—	前端登录页重写令仓库外三支回归脚本集体失效（本轮已临时修补）	scripts/e2e/harness.mjs 注释 + 日志 §8
B1	—	（既有，非本轮引入）core_holding 快照与 SUM(core_share_lot) 不一致，8 只产品中 3 只对不上	见日志 §10

逐条根因见 TEST-LOG-2026-09-13-CT-001.md §6。