6.3 KiB

Raw Permalink Blame History

票 05 — 重流程实测报告（F-13 交割 / F-14 导入 / F-15 提醒 / F-16 查重消费侧）

脚本: e2e-heavy.py（~900 行，6 轮迭代收敛） · 终态: ✅54 ⚠4 ❌0（58 checks，含 3 条 SETUP） 产物: e2e-heavy-checks.json / e2e-heavy-specimens.json（19 端点）/ e2e-heavy-defects.json

执行环境

本地起服（JBR java 21，SPRING_PROFILES_ACTIVE=verify + MinIO admin/Itc@123456），远程共享 MySQL/Redis 8.129.84.155
f15 Job 观测经 restart_service() env 注入 CRM_CUSTOMER_REMINDERCRON=*/30 * * * * ?（U-02 拍板），测后还原默认 cron 0 0 4 * * ?，服务/规则均已还原（规则 30/7 全开）
测试账号：admin（罗伟健）/ BUDDY（曾偲青）；seed 销售甲 760000000000000001（华南销售部，teardown 留痕）
交割前提搭建：华南销售部 leader=admin（teardown 还原 NULL）→ 甲乙丙 assign→BUDDY → BUDDY 发起离职交接

F-13 客户交割（A4-7）— 18/18 ✅

用例	结果	关键证据
preview 圈定	✅	BUDDY 名下 3 条（甲乙丙），口径=名下全量
initiate 必填/范围 → 67011	✅	reason 缺失、toDirectorId 越范围各拦
initiate resign 自动推导	✅	JG202609040003，D22 推导接收总监=罗伟健，totalCount=3
重入 → 67010	✅	存在未完成交接单时拦截
整批原子 owner→总监	✅	customer.owner_user_id=admin（DB）
商机三列联动	✅	opportunity.owner/snapshot/dept 同步（经 opportunity_customer 反查）
oplog 交接编号	✅	「交割单【JG…】发起交接：客户归属由【曾偲青】移交【罗伟健】」
detail/assignable/page/续号	✅	续号 JG…0003 当日不重号；page transferNo 过滤命中
assign 序列	✅	单条/重复 67012/当前负责人 67012/无效对象 67012/批量 2/2
D23 自动完成	✅	assignedCount==totalCount → status=1；已完成单再分配失败行收口（STATUS_NOT_ALLOWED）

⚠ D-07(P1) assignable 接口超时：GET /api/customer/transfer/{id}/assignable 稳定超时（E2E 30s×2、手动 probe 60s×2，三轮复现）。疑因 getChildDeptIds 根部门全树递归 + 用户过滤全表扫描；assign 本体不受影响（直接指定 userId 成功）。前端「选择分配对象」将无法加载。

F-14 客户导入（A4-3-2）— 10 ✅ + 4 ⚠（缺陷验证模式）

✅ 通过：模板下载（RFC 5987 + xlsx 魔数）/ 67013 三连（mode 非法/表头不符/空数据）/ APPEND_ONLY 预检（t=7 i=1 f=5 s=1）/ 行级判定（已存在 FAIL、文件内重复组 FAIL「重复时不导入」、相似 SUSPECT）/ UPDATE_ONLY 按编号 u=1 / UPSERT 同名新编号→SUSPECT（不按名称匹配实证）/ confirm 状态机（重复 → 67014）/ creator 过滤（admin 有=True buddy 有=False）
⚠ D-05(P1) 导入新增客户行必失败：customer.is_biz_negotiated tinyint NOT NULL 无默认值，CustomerImportExecutor.createCustomer 未赋值 → INSERT 报 Field 'is_biz_negotiated' doesn't have a default value → 所有含 INSERT 行的导入任务 FAILED。证据：日志 客户导入单行执行异常 row=1 + SHOW COLUMNS（对照 is_child 有默认 '0'）。
⚠ D-04(P2) 失败明细丢失：insertFail 将完整 MyBatis 异常文本写入 fail_reason varchar(500) → Data too long 二次异常 → fail 表 0 行，明细全丢。与 D-05 构成连锁：INSERT 行必失败且无痕。
三条 warn（终态 FAILED/明细 0 行/r1 未落库）均为 D-05/D-04 的缺陷验证证据。

F-15 提醒规则族（a7-3-3-1）— 11/11 ✅（含 2 条断言口径修正）

✅ API：GET 单例回显 / PUT 全量覆盖保存即生效 / 64023（first=0、second=-1）/ 校验失败不落库 / 开关缺省=0（orDisabled 口径）
✅ Job 实测（重启注入 */30 cron）：
- 落表：plan=锚点+first(1)=2026-08-05 22:27:56，status=0 / type=FOLLOW_OVERDUE / target=owner / payload 快照（remindSeq/overdueDays/anchor/规则参数）全对
- 排除：未到期（followFuture）、公海、归档客户均不落
- 幂等=同 plan 不重写：30 轮 Job → 30 条，remindSeq 0..29 严格连续、plan 无重复（每轮补下一条升级提醒链，与 CustomerReminderJob 注释「每轮每客户只补下一条未建到期提醒」自洽）
- 锚点刷新：follow 后旧未发 30 条全置 INVALID(2)，新锚点重排
还原：PUT 30/7 + 服务回默认 cron + smoke 通过
口径修正记录：15.7/15.9 首测按「恒 1 条」判 fail；probe_notice.py DB 取证证明语义=「每轮补下一条」，修正断言后判 pass（证据链在 checks JSON note 字段）
观察点（非缺陷）：升级链无上限推进——客户永不跟进时提醒逐轮堆积（30 轮=30 条待发）。建议产品复核是否需要「存在未发提醒时暂停推进」口径。

F-16 查重设置消费侧（a7-3-3-2）— 7/7 ✅

check-credit-code 命中 / 创建撞码 → 67003 硬拦 / check-name 相似命中（出厂阈值 80）/ 创建相似名 → needConfirm=true 未落库 / check-phone 跨客户软提示 / 导入侧 SUSPECT 消费（F-14 引证）
单例未落地：customer_dedup_rule 表不存在 → DefaultCustomerDedupSettingProvider 出厂默认全开生效（名称相似开/80/信用码开/电话软提示开）——落地属票 09 范围；D26「关闭路径」因此无法实测，留观察点

缺陷汇总（票 05 新增）

编号	级别	标题	证据
D-05	P1	导入新增客户行必失败（is_biz_negotiated 缺省列）	日志堆栈 + SHOW COLUMNS
D-04	P2	insertFail 超长文本炸 varchar(500) → 失败明细全丢	fail 表 0 行 + MysqlDataTruncation
D-07	P1	交割 assignable 接口稳定超时	30s/60s×多轮复现

（D-06「导入分页恒空」经取证撤回——系测试脚本取 records 而 PageResult 序列化字段为 content，非产品缺陷。）

遗留与交接（→ 票 09）

customer_dedup_rule 单例落地（票 09）；D26 关闭路径实测依赖其落地
assignable 超时修复建议（D-07）：部门树缓存/子部门查询收窄
升级提醒链无上限的产品口径复核（观察点）
specimens 19 端点已落盘，与票 04 合并供票 06 Bruno 注入

6.3 KiB Raw Permalink Blame History