测试实施第五步执行记录

执行时间

日期：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 回传事件。

已执行命令

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，以及客户端/运营端查询闭环。

主要缺口是定时发送未实现，且发送链路尚未把余额冻结扣费、模板/签名/报备状态阻断等业务规则接入完整闭环。

缺口修复复测记录

定时发送已补齐 scheduledAt、canceledAt 字段，支持 sendMode=scheduled 创建 scheduled 任务。
新增 POST /api/client/send/batch-tasks/:id/cancel 支持到点前取消。
新增 POST /api/admin/send/scheduled/dispatch-due 支持到点触发入队。
到点触发前会重新校验企业状态、认证状态、应用状态、模板审核状态、签名审核/报备状态和账户余额。
api/src/send-chain/send-chain.service.spec.ts 已覆盖定时创建、取消、到点触发和到点余额/资源校验基础路径。

复测命令：

npm --prefix api test -- send-chain.service.spec.ts
npm --prefix api run build

下一步

进入第 6 步：执行计费和对账闭环测试。重点覆盖人工充值、费用预估、余额检查、冻结、扣费、释放、退款、短信计费记录、对账 reconciliation，以及 dashboard/statistics 中计费相关数据准确性。

7.3 KiB Raw Blame History Unescape Escape