102 lines
6.6 KiB
Markdown
102 lines
6.6 KiB
Markdown
# 测试实施第五步执行记录
|
||
|
||
## 执行时间
|
||
|
||
- 日期：2026-07-01
|
||
- 总步骤数：8
|
||
- 当前步骤：第 5 步，执行发送链路闭环测试
|
||
|
||
## 第五步目标
|
||
|
||
验证客户立即发送任务从创建到发送记录、队列入队、Send Worker 消费、Submit Result、回执、上行、任务查看和 72 小时未知回执转超时的闭环。
|
||
|
||
定时短信发送也在本步探测，当前系统尚未形成计划发送字段和到点触发闭环。
|
||
|
||
## 执行环境
|
||
|
||
| 项目 | 结果 |
|
||
| --- | --- |
|
||
| PostgreSQL | 可连接，使用真实数据库。 |
|
||
| Redis | 可连接，Send Worker 使用真实 BullMQ/Redis。 |
|
||
| MinIO | 可连接，本步未执行文件导入。 |
|
||
| API | 使用 `API_PORT=3101 API_ENABLE_SEND_WORKER=true npm --prefix api run start:dev` 启动，执行完成后已停止。 |
|
||
| Gateway | 未连接真实运营商 CMPP；使用 `/api/gateway/events/*` 模拟 Gateway 回传事件。 |
|
||
|
||
## 已执行命令
|
||
|
||
```bash
|
||
Test-NetConnection 127.0.0.1 -Port 5432
|
||
Test-NetConnection 127.0.0.1 -Port 6379
|
||
Test-NetConnection 127.0.0.1 -Port 9000
|
||
$env:API_PORT='3101'; $env:API_ENABLE_SEND_WORKER='true'; npm --prefix api run start:dev
|
||
node <inline step5 send-chain smoke>
|
||
node <inline step5 schedule probe>
|
||
```
|
||
|
||
## 本步执行过的测试用例
|
||
|
||
| 用例编号 | 用例名称 | 执行范围 | 结果 |
|
||
| --- | --- | --- | --- |
|
||
| TC-SEND-001 / TC-SEND-002 | 批量任务创建与手机号拆分 | 创建租户、应用、签名、模板、通道、通道组、路由规则；提交 3 个号码，其中 1 个重复，验证生成批量任务、API 请求记录和 2 条短信记录。 | 通过 |
|
||
| TC-SEND-003 / TC-SEND-004 | 发送入队与 Worker 消费 | 启用真实 Send Worker，验证任务创建后自动入队，Worker 消费后生成 2 条 submit records，短信记录进入 `submit_queued`。 | 通过 |
|
||
| TC-SEND-005 | submit result 更新 | 模拟 Gateway `accepted` submit result，验证短信记录变为 `submitted`，submit record 写入 `sequenceId` 和 `gatewayMessageId`。 | 通过 |
|
||
| TC-SEND-006 | delivered 回执更新 | 模拟 Gateway delivered 回执，验证短信记录变为 `delivered`，生成 receipt record。 | 通过 |
|
||
| TC-SEND-007 | 72 小时 unknown 转 timeout | 模拟 73 小时前 unknown 回执，调用 `POST /api/admin/send/timeouts/mark-unknown`，验证短信记录变为 `timeout`。 | 通过 |
|
||
| TC-SEND-008 | 上行记录 | 模拟 Gateway 上行，验证 `SmsUplinkMessage` 写入，并可按租户和通道查询。 | 通过 |
|
||
| TC-SEND-009 / TC-SEND-010 | 任务查看与进度 | 客户端和运营端分别查询任务列表、任务详情和消息明细，验证任务最终 `finished`，`successTotal=1`，`timeoutTotal=1`。 | 通过 |
|
||
| TC-SCHEDULE-001 / TC-SCHEDULE-002 | 定时短信创建与到点发送 | 探测 `scheduledAt/sendMode=scheduled` 入参。接口接受请求但忽略定时字段，任务直接变为 `queued`。 | 未通过，记录缺口 |
|
||
|
||
## 本步创建的数据
|
||
|
||
| 数据类型 | ID |
|
||
| --- | --- |
|
||
| 测试运行编号 | `step5-1782900420934` |
|
||
| Tenant | `cmr1wvlbf0008m8yu6so4fd6a` |
|
||
| SmsApplication | `cmr1wvlds0009m8yukei4omfw` |
|
||
| SmsChannel | `cmr1wvlg6000hm8yuo4wjsdos` |
|
||
| SmsBatchTask | `cmr1wvlmw000mm8yu3p8ytfvs` |
|
||
| UplinkMessage | `cmr1wvm6x000wm8yuxzu7uzpm` |
|
||
| 定时探测任务 | `cmr1wvyfu0010m8yuvkul1hkv` |
|
||
|
||
## 通过项
|
||
|
||
- 客户端创建发送任务后会生成批量任务、API 请求记录和短信消息记录。
|
||
- 手机号会在发送任务创建阶段去重，3 个入参号码最终生成 2 条消息记录。
|
||
- 任务 approved 后会自动调用 `enqueueBatchTask`，真实 BullMQ/Redis 入队可用。
|
||
- Send Worker 可消费 `sms.send.queue`，选择通道路由，创建 `SmsSubmitRecord`，并将消息状态更新为 `submit_queued`。
|
||
- Gateway submit result 可按平台 `messageId` / `gatewayMessageId` 回写消息和 submit record。
|
||
- delivered 回执可生成 `SmsReceiptRecord` 并更新消息状态。
|
||
- unknown 回执超过 72 小时后可由运营接口批量转为 timeout。
|
||
- 上行事件可写入并通过运营端接口查询。
|
||
- 客户端和运营端均可查询任务列表、任务详情和消息明细。
|
||
- 任务进度在成功和超时后刷新为 `finished`。
|
||
|
||
## 本步发现的问题
|
||
|
||
| 问题 | 影响 | 证据 |
|
||
| --- | --- | --- |
|
||
| 定时发送字段未实现 | 客户端传入 `scheduledAt`、`sendMode=scheduled` 后，接口未保存计划发送时间，也未进入 `scheduled` 状态，而是直接创建 `queued` 任务。 | 定时探测任务 `cmr1wvyfu0010m8yuvkul1hkv` 返回 `status=queued`。 |
|
||
| 创建发送任务未做账户余额冻结/扣费 | 当前发送链路只做费用预估并写入消息计费字段，不会在任务创建或 submit 成功后冻结、扣费或生成短信计费记录。 | `createBatchTask` 仅调用 `estimateSmsCost`，计费闭环需在第 6 步继续验证。 |
|
||
| 模板/签名/报备状态未在发送链路强制校验 | 发送链路主要依赖风控结果，当前未发现对签名审核状态、模板审核状态、签名报备状态的发送阻断。 | 本步使用 approved 数据通过，删除/失效/报备失败影响需在后续专项步骤验证。 |
|
||
|
||
## 未执行或阻塞项
|
||
|
||
| 用例编号 | 用例名称 | 原因 |
|
||
| --- | --- | --- |
|
||
| TC-SCHEDULE-001 | 创建定时短信任务 | `CreateBatchTaskDto` 和 Prisma 返回数据中没有计划发送时间字段，`scheduledAt` 被忽略。 |
|
||
| TC-SCHEDULE-002 | 定时任务到点发送并生成记录 | 缺少 scheduled 状态、延迟队列或调度器入口。 |
|
||
| TC-SCHEDULE-003 | 定时任务到点前取消 | 缺少定时任务取消接口。 |
|
||
| TC-SCHEDULE-004 | 定时任务到点余额不足 | 缺少定时任务到点前重新计费/余额检查逻辑。 |
|
||
| TC-SCHEDULE-005 | 定时任务到点模板或签名失效 | 缺少定时任务到点前重新校验模板/签名/报备状态逻辑。 |
|
||
| TC-SCHEDULE-006 | 定时任务查看和筛选 | 缺少 scheduled 状态和计划发送时间字段。 |
|
||
|
||
## 本步结论
|
||
|
||
第五步立即发送链路主干已通过。当前系统可以完成客户创建任务、消息拆分、真实 BullMQ 入队、Send Worker 消费、通道路由、submit result 回写、receipt 回写、上行记录、72 小时 unknown 转 timeout，以及客户端/运营端查询闭环。
|
||
|
||
主要缺口是定时发送未实现，且发送链路尚未把余额冻结扣费、模板/签名/报备状态阻断等业务规则接入完整闭环。
|
||
|
||
## 下一步
|
||
|
||
进入第 6 步：执行计费和对账闭环测试。重点覆盖人工充值、费用预估、余额检查、冻结、扣费、释放、退款、短信计费记录、对账 reconciliation，以及 dashboard/statistics 中计费相关数据准确性。
|