test: record step6 billing coverage
This commit is contained in:
@@ -0,0 +1,95 @@
|
|||||||
|
# 测试实施第六步执行记录
|
||||||
|
|
||||||
|
## 执行时间
|
||||||
|
|
||||||
|
- 日期:2026-07-01
|
||||||
|
- 总步骤数:8
|
||||||
|
- 当前步骤:第 6 步,执行计费和对账闭环测试
|
||||||
|
|
||||||
|
## 第六步目标
|
||||||
|
|
||||||
|
验证第一版计费能力,包括费用预估、人工充值、账户余额检查、冻结、扣费、释放、退款、短信计费记录、账务流水、trace、reconciliation,以及运营 dashboard/statistics 中计费和消息聚合数据的准确性。
|
||||||
|
|
||||||
|
本步同时探测发送链路是否已经自动接入计费闭环。
|
||||||
|
|
||||||
|
## 执行环境
|
||||||
|
|
||||||
|
| 项目 | 结果 |
|
||||||
|
| --- | --- |
|
||||||
|
| PostgreSQL | 可连接,使用真实数据库。 |
|
||||||
|
| Redis | 可连接,本步不需要 Send Worker。 |
|
||||||
|
| MinIO | 可连接,本步未执行文件上传。 |
|
||||||
|
| API | 使用 `API_PORT=3101 npm --prefix api run start:dev` 启动,执行完成后已停止。 |
|
||||||
|
|
||||||
|
## 已执行命令
|
||||||
|
|
||||||
|
```bash
|
||||||
|
$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 步计费能力连接起来。
|
||||||
|
|
||||||
|
## 下一步
|
||||||
|
|
||||||
|
进入第 7 步:执行 CMPP 连接状态、通道路由、客户/通道连接数量管理和展示测试。重点覆盖客户连接状态、通道 CMPP 连接状态、连接数量展示、通道 health/metrics、路由规则和 Gateway 相关契约。
|
||||||
@@ -52,6 +52,9 @@ node <inline step4 precheck smoke>
|
|||||||
$env:API_PORT='3101'; $env:API_ENABLE_SEND_WORKER='true'; npm --prefix api run start:dev
|
$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 send-chain smoke>
|
||||||
node <inline step5 schedule probe>
|
node <inline step5 schedule probe>
|
||||||
|
$env:API_PORT='3101'; npm --prefix api run start:dev
|
||||||
|
node <inline step6 billing/reconciliation smoke>
|
||||||
|
node <inline step6 auto-billing probe>
|
||||||
```
|
```
|
||||||
|
|
||||||
### 当前结果
|
### 当前结果
|
||||||
@@ -74,6 +77,10 @@ node <inline step5 schedule probe>
|
|||||||
- `TC-SEND-001 / TC-SEND-002`、`TC-SEND-003 / TC-SEND-004`、`TC-SEND-005`、`TC-SEND-006`、`TC-SEND-007`、`TC-SEND-008`、`TC-SEND-009 / TC-SEND-010` 均通过。
|
- `TC-SEND-001 / TC-SEND-002`、`TC-SEND-003 / TC-SEND-004`、`TC-SEND-005`、`TC-SEND-006`、`TC-SEND-007`、`TC-SEND-008`、`TC-SEND-009 / TC-SEND-010` 均通过。
|
||||||
- 使用真实 Redis/BullMQ 和 `API_ENABLE_SEND_WORKER=true` 验证了任务创建、号码去重拆分、自动入队、Worker 消费、submit record、submit result、receipt、uplink、72 小时 unknown 转 timeout、客户端/运营端任务查看。
|
- 使用真实 Redis/BullMQ 和 `API_ENABLE_SEND_WORKER=true` 验证了任务创建、号码去重拆分、自动入队、Worker 消费、submit record、submit result、receipt、uplink、72 小时 unknown 转 timeout、客户端/运营端任务查看。
|
||||||
- 定时发送探测发现 `scheduledAt/sendMode=scheduled` 会被接口忽略,任务直接变为 `queued`,已在 `docs/testing-execution-step-5.md` 记录为功能缺口。
|
- 定时发送探测发现 `scheduledAt/sendMode=scheduled` 会被接口忽略,任务直接变为 `queued`,已在 `docs/testing-execution-step-5.md` 记录为功能缺口。
|
||||||
|
- 第 6 步计费和对账 smoke 通过:
|
||||||
|
- `TC-BILLING-001`、`TC-BILLING-002 / TC-RECHARGE-001`、`TC-BILLING-003`、`TC-BILLING-004 / TC-BILLING-005 / TC-BILLING-006 / TC-BILLING-007`、`TC-BILLING-008 / TC-RECON-001 seed`、`TC-RECON-001`、`TC-DASHBOARD-001 / TC-STAT-001`、`TC-TRACE-001`、`TC-BILLING-009` 均通过。
|
||||||
|
- 验证了费用预估、人工充值、余额检查、冻结、扣费、释放、退款、短信计费记录、账务流水、dashboard/statistics、trace 和 reconciliation。
|
||||||
|
- 自动计费探测发现发送任务不会自动生成短信计费记录、账户交易流水,消息金额默认为 0,已在 `docs/testing-execution-step-6.md` 记录为发送计费集成缺口。
|
||||||
|
|
||||||
### 已知缺口
|
### 已知缺口
|
||||||
|
|
||||||
@@ -82,3 +89,4 @@ node <inline step5 schedule probe>
|
|||||||
- Gateway 未接真实运营商 SMSC;真实 CMPP 互通需要运营商测试环境后补充联调记录。
|
- Gateway 未接真实运营商 SMSC;真实 CMPP 互通需要运营商测试环境后补充联调记录。
|
||||||
- 客户侧导入发送、短信内容非法字符展示和敏感词发送前拦截尚未形成完整业务入口。
|
- 客户侧导入发送、短信内容非法字符展示和敏感词发送前拦截尚未形成完整业务入口。
|
||||||
- 定时短信发送缺少计划发送时间字段、scheduled 状态、到点触发和取消接口。
|
- 定时短信发送缺少计划发送时间字段、scheduled 状态、到点触发和取消接口。
|
||||||
|
- 发送链路尚未自动接入计费闭环,发送任务不会自动冻结/扣费/生成短信计费记录。
|
||||||
|
|||||||
Reference in New Issue
Block a user