Files
lislgosms/docs/testing-execution-step-6.md
T

6.8 KiB

测试实施第六步执行记录

执行时间

  • 日期:2026-07-01
  • 总步骤数:8
  • 当前步骤:第 6 步,执行计费和对账闭环测试

第六步目标

验证第一版计费能力,包括费用预估、人工充值、账户余额检查、冻结、扣费、释放、退款、短信计费记录、账务流水、trace、reconciliation,以及运营 dashboard/statistics 中计费和消息聚合数据的准确性。

本步同时探测发送链路是否已经自动接入计费闭环。

执行环境

项目 结果
PostgreSQL 可连接,使用真实数据库。
Redis 可连接,本步不需要 Send Worker。
MinIO 可连接,本步未执行文件上传。
API 使用 API_PORT=3101 npm --prefix api run start:dev 启动,执行完成后已停止。

已执行命令

$env:API_PORT='3101'; npm --prefix api run start:dev
node <inline step6 billing/reconciliation smoke>
node <inline step6 auto-billing probe>

本步执行过的测试用例

用例编号 用例名称 执行范围 结果
TC-BILLING-001 费用预估 按 70/67 分段规则分别估算短内容和长内容,验证计费条数和金额。 通过
TC-BILLING-002 / TC-RECHARGE-001 人工充值闭环 创建账户、执行人工充值、验证充值订单、账户余额、短信条数、人工充值列表。 通过
TC-BILLING-003 余额检查 验证金额余额、授信额度和短信条数同时参与发送前账户检查。 通过
TC-BILLING-004 / TC-BILLING-005 / TC-BILLING-006 / TC-BILLING-007 冻结、扣费、释放、退款 依次执行 freeze、charge、release、refund,验证流水类型和余额变化。 通过
TC-BILLING-008 / TC-RECON-001 seed 短信计费记录 创建发送任务和 3 条短信计费记录,作为对账聚合数据。 通过
TC-RECON-001 对账 reconciliation 验证消息聚合、计费记录聚合、交易流水聚合和差异计算。 通过
TC-DASHBOARD-001 / TC-STAT-001 dashboard/statistics 展示准确性 验证 dashboard 中 billing/transactions 聚合,以及 statistics 按 tenant/application 聚合消息数据。 通过
TC-TRACE-001 发送链路 trace 按 messageId 查询 trace,验证消息和短信计费记录能被串联。 通过
TC-BILLING-009 账务流水查询 查询账户流水,验证 recharge、frozen、charged、released、refunded 均可见。 通过
TC-BILLING-AUTO-001 发送任务自动计费探测 创建发送任务后查询短信计费记录和交易流水。 未通过,记录缺口

本步创建的数据

数据类型 ID
测试运行编号 step6-1782900766973
Tenant cmr1x1hd50000wgyub26ij5ev
SmsApplication cmr1x1hk90001wgyu0jv6ashu
SmsBatchTask cmr1x1hyw000awgyuvaz8sv71
自动计费探测 Tenant cmr1x1vkw000jwgyuixewzayb
自动计费探测 Task cmr1x1w0y000nwgyuy7u7w19e

通过项

  • 费用预估支持 70 字以内单条、超过 70 后按 67 字分段。
  • 人工充值会生成 paid 充值订单,并同步增加账户余额和短信条数。
  • 账户检查会同时校验金额、授信和短信条数。
  • 冻结、扣费、释放、退款会生成对应账户流水,并更新账户余额和短信条数。
  • 短信计费记录可以按租户查询。
  • reconciliation 能聚合消息记录、短信计费记录和账户交易,并输出金额/条数差异。
  • dashboard 能展示任务数、消息状态、短信计费记录聚合和账户交易聚合。
  • statistics 能按租户、应用维度聚合消息数量、金额和计费条数。
  • trace 能按 messageId 串起消息记录和短信计费记录。

本步发现的问题

问题 影响 证据
发送任务未自动生成短信计费记录 客户发送后不能自动进入计费记录和对账体系,需要运营或后续流程显式创建 SmsBillingRecord 自动计费探测任务 cmr1x1w0y000nwgyuy7u7w19e 创建 2 条消息后,billingRecordCount=0
发送任务未自动生成账户交易流水 发送链路没有自动冻结、扣费、释放或退款,余额不会随发送自动变化。 自动计费探测任务对应 transactionCount=0
发送链路消息金额默认为 0 SmsMessageRecord.amountCents 在发送任务创建时为 0,当前没有从通道单价或计费规则取价。 自动计费探测返回 messageAmounts=[0,0]
BillingService 冻结语义是直接扣减余额 当前 freeze 会减少余额并生成 frozen 流水,但没有单独的冻结金额字段,后续 release 再加回。 账户模型只有 balanceCents/smsUnits/creditCents,无 frozen balance 字段。

未执行或阻塞项

用例编号 用例名称 原因
TC-BILLING-AUTO-002 submit 成功后自动扣费 发送链路尚未接入自动扣费逻辑,无法形成通过项。
TC-BILLING-AUTO-003 submit 失败自动释放/退款 发送链路尚未接入自动冻结和失败释放逻辑,无法形成通过项。
TC-BILLING-AUTO-004 余额不足阻断发送任务创建 第 4 步已验证 billing check 接口;发送任务创建接口当前未强制调用余额检查。

本步结论

第六步计费服务和运营聚合口径已通过。当前系统可以完成费用预估、人工充值、余额检查、冻结、扣费、释放、退款、短信计费记录、账务流水、dashboard/statistics、trace 和 reconciliation。

主要缺口是发送链路尚未自动调用计费闭环:发送任务创建后不会自动冻结或扣费,也不会自动生成短信计费记录,消息金额默认为 0。后续需要把第 5 步发送链路和第 6 步计费能力连接起来。

缺口修复复测记录

  • 发送创建时会按通道单价写入 SmsMessageRecord.billingUnits/unitPrice/amountCents
  • 立即发送创建时执行账户检查和冻结;定时发送创建时检查余额,到点触发再冻结。
  • Gateway submit accepted 后会生成/更新 SmsBillingRecord,写入 charged 流水。
  • Gateway submit rejected/timeout 会释放冻结。
  • 最终失败回执和 72 小时 unknown 转 timeout 会执行退款并更新计费记录状态。
  • trace、dashboard 和 reconciliation 可通过消息金额、计费记录和账户交易聚合看到自动计费数据。

复测命令:

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

下一步

进入第 7 步:执行 CMPP 连接状态、通道路由、客户/通道连接数量管理和展示测试。重点覆盖客户连接状态、通道 CMPP 连接状态、连接数量展示、通道 health/metrics、路由规则和 Gateway 相关契约。