99 lines
4.6 KiB
Markdown
99 lines
4.6 KiB
Markdown
# IT测试客户八千票待分柜数据生成方案
|
||
|
||
## 目标
|
||
|
||
通过测试环境正式 HTTP 接口，最多尝试生成 8,000 票头程订单并推进到：
|
||
|
||
- 入库单 `processStatus=WAIT_SPLIT`
|
||
- 测量审核 `reviewStatus=APPROVED`
|
||
|
||
只固定两个条件：
|
||
|
||
1. 商户账号登录后的企业名称必须精确等于“IT测试”。
|
||
2. 国内起运仓必须精确等于启用状态的“义乌仓”。
|
||
|
||
不固定渠道、报价税制、目的类型、目的仓、履约类型、提货方式、买单/退税、装载方式、是否查验、SKU 数、箱型、尺寸、托数和重量。它们从当前客户真实可选择且服务端校验通过的数据中选择。
|
||
|
||
## 数量规则
|
||
|
||
- 最大尝试数：8,000 票。
|
||
- 每票独立随机 `1–300` 箱，随机到多少就生成多少。
|
||
- 不要求 `1–300` 全部出现，允许重复和缺号。
|
||
- 每票随机总箱数必须等于所有 SKU 箱数之和，并与入库、测量和待分柜箱数保持一致。
|
||
- 托数固定按每托最多 30 箱计算：`palletCount = ceil(totalPackageCount / 30)`；1–30 箱为 1 托，31–60 箱为 2 托，300 箱为 10 托。
|
||
- 理论平均每票 `150.5` 箱，8,000 票理论期望总箱数约 `1,204,000` 箱；实际数量以成功结果为准。
|
||
- 执行按 100 票统计一个批次，共最多 80 批。
|
||
|
||
入仓码流水为四位数。8,000 票只能降低触及 `9999` 上限的概率，不能保证所有渠道前缀都有足够余量；测试环境已有流水、渠道各自计数和并发生成都会影响实际可用数量。
|
||
|
||
## 随机线路
|
||
|
||
每票执行时：
|
||
|
||
1. 查询“IT测试”客户可见的启用国内仓，并只保留“义乌仓”。
|
||
2. 查询义乌仓当前客户可见且具有报价税制的渠道。
|
||
3. 随机轮换渠道和报价税制候选。
|
||
4. 对 FBA/海外仓线路，通过正式估价接口选择真实可计价目的仓。
|
||
5. 私人地址只使用客户当前可选择的渠道，不伪造目的仓 ID。
|
||
6. 候选为空、价格变更或服务错误时记录失败，不回退到硬编码渠道或历史价格。
|
||
|
||
## SKU 与测量
|
||
|
||
- SKU 数随机为 `1–4`，但不得超过本票总箱数。
|
||
- 总箱数随机拆分到各 SKU，每个 SKU 至少 1 箱。
|
||
- 毛重、净重、数量、申报价值和体积根据各 SKU 箱数计算。
|
||
- 称重图片数量与上述托数一致；每托只在既有 `TP-001`、`YW-TP-002` 中随机复用一个托盘编码，不创建新的托盘主档，因此同一票和不同票都允许重复使用这两个编码。
|
||
- 库位由正式仓储预占/结算接口分配，不创建库位主档；普通库位不足时直接使用仓库公共位 `A0`。托盘复用不改变 `palletCount = ceil(totalPackageCount / 30)` 的业务托数。
|
||
- 箱唛打印冻结真实总箱数；多 SKU 测量使用各 SKU 实际箱数和对应箱序号。
|
||
- 通过正式文件、称重 OCR、托盘库位预占、测量提交和审核接口推进状态，不直接写数据库。
|
||
|
||
## 尽力执行语义
|
||
|
||
执行入口为：
|
||
|
||
```powershell
|
||
node scripts/it-test-wait-split-bulk.mjs `
|
||
--count 8000 `
|
||
--batch-size 100 `
|
||
--customer-name 'IT测试' `
|
||
--origin-warehouse-name '义乌仓' `
|
||
--box-min 1 `
|
||
--box-max 300 `
|
||
--output-dir '<本地报告目录>'
|
||
```
|
||
|
||
- 随机数在每票请求前直接产生，不设置预览或人工确认步骤。
|
||
- 每票先把本次箱数和随机值写入 `results.jsonl`，然后请求测试环境。
|
||
- 单票失败不会停止后续票，失败报告保存到 `failures/`。
|
||
- 每 100 票及每次失败后更新 `summary.json`。
|
||
- 成功标准以该票真实到达 `WAIT_SPLIT / APPROVED` 且箱数、客户、义乌仓一致为准。
|
||
- 最终允许不足 8,000 票成功，实际成功数、失败数和总箱数以 `summary.json` 为准。
|
||
|
||
## 报告内容
|
||
|
||
`results.jsonl` 对每票记录：
|
||
|
||
- 全局序号、批次、随机箱数
|
||
- 订单 ID/订单号
|
||
- 入库单 ID/入仓码
|
||
- 渠道、目的类型和目的仓
|
||
- 是否到达待分柜
|
||
- 断言失败、deployment blocker、`requestId`/`traceId`
|
||
|
||
`summary.json` 汇总：
|
||
|
||
- 已尝试、成功和失败票数
|
||
- 成功票总箱数、最小/最大/平均箱数
|
||
- 各渠道成功票数
|
||
- 各目的类型成功票数
|
||
- 进程 ID、开始时间、更新时间和报告目录
|
||
|
||
## 安全边界
|
||
|
||
- 仅用于已明确授权的测试环境，禁止用于生产环境。
|
||
- 账号、密码、Token 和环境地址只从本机环境配置加载，不进入源码或报告。
|
||
- 不自动删除已成功或部分成功的数据。
|
||
- 不新增托盘或库位主档；只能复用 `TP-001`、`YW-TP-002`，库位不足落公共位 `A0`。
|
||
- 不重置数据库、不执行 SQL、不绕过正式状态机。
|
||
- 清理测试数据或文件必须另行获得明确授权。
|