2199 lines
81 KiB
Markdown
2199 lines
81 KiB
Markdown
# CMPP 短信平台第一版系统功能测试用例
|
||
|
||
## 1. 用例说明
|
||
|
||
本文档补充第一版系统功能测试用例，面向验收测试、人工回归测试和后续 E2E 自动化改造。用例不依赖真实运营商 CMPP 网关；Gateway 场景使用项目模拟器、队列契约或测试替身。
|
||
|
||
优先级定义：
|
||
|
||
- P0：第一版上线阻断项，必须通过。
|
||
- P1：核心功能回归项，建议每轮发布通过。
|
||
- P2：增强/边界项，可按时间和环境选择执行。
|
||
|
||
## 2. 测试数据基线
|
||
|
||
| 数据类型 | 建议数据 |
|
||
| --- | --- |
|
||
| 租户 | `tenant-a` 正常企业，`tenant-b` 用于租户隔离验证。 |
|
||
| 用户 | 客户端企业管理员、客户端普通用户、运营管理员、运营审核员。 |
|
||
| 短信应用 | `app-a`，状态 active，日限额开启，模板不匹配策略分别准备 reject/manual_review/allow 三组。 |
|
||
| 签名 | `【测试签名】`，审核通过且报备通过；另准备待审核、驳回、报备失败签名。 |
|
||
| 模板 | 验证码模板 `验证码为 ${code}`，营销模板 `尊敬的${name}，优惠活动开始`，分别准备草稿、待审核、通过、驳回。 |
|
||
| 通道 | active CMPP 通道、disabled 通道、备用通道；通道组包含主备优先级。 |
|
||
| 号码 | 合法号码、重复号码、非法号码、企业黑名单号码、全局黑名单号码。 |
|
||
| 账户 | 余额充足、余额不足、套餐余量充足、套餐余量不足、授信额度可用。 |
|
||
| 企业认证 | 未认证、待审核、已通过、已驳回四类企业认证资料。 |
|
||
| 客户 | 正常客户、停用客户、欠费客户、未认证客户、跨租户客户、客户联系人和开票资料。 |
|
||
| 导入文件 | UTF-8 CSV、GBK CSV、TXT、超 20 MB 文件、含空行/重复/非法号码/非法字符文件。 |
|
||
| 非法内容 | 控制字符、emoji、换行、不可见字符、超长变量、签名外置内容、敏感词内容。 |
|
||
|
||
## 3. 业务闭环覆盖矩阵
|
||
|
||
| 业务闭环 | 必须验证 |
|
||
| --- | --- |
|
||
| 企业认证闭环 | 客户提交资料、运营审核、客户查看状态、驳回重提、通过后才允许使用受限发送能力、日志可追溯。 |
|
||
| 客户管理闭环 | 客户创建、编辑、启停、认证、额度/余额、客户下应用/签名/模板/发送记录联动、租户隔离、日志可追溯。 |
|
||
| 短信应用闭环 | 创建、启停、删除、密钥重置、IP 白名单、模板不匹配策略、变更后对发送实时生效、日志可追溯。 |
|
||
| 签名闭环 | 创建、材料、审核、删除、报备状态变化、发送可用性校验、历史任务不受错误覆盖、日志可追溯。 |
|
||
| 引流信息闭环 | 字段配置、客户填写、删除字段或删除客户引流信息、报备材料影响、发送阻断或审核原因可见。 |
|
||
| 模板闭环 | 单变量、多变量、审核、删除、变量缺失/多传/格式异常、计费预估、发送可用性校验。 |
|
||
| 号码导入闭环 | 文件上传、解析、去重、非法号码、黑名单、导入结果展示、生成任务、生成手机号记录。 |
|
||
| 发送闭环 | 立即发送、定时发送、到点触发、入队、submit、回执、上行、任务进度、发送详情、trace、对账。 |
|
||
| CMPP 连接闭环 | 通道连接状态、登录认证、active test、断线重连、连接异常对路由/发送影响、状态监控和日志告警。 |
|
||
| Dashboard 闭环 | 客户端/运营端指标口径、数据范围、时间筛选、状态统计、账务统计、通道连接指标和明细跳转一致。 |
|
||
| 内容校验闭环 | 非法字符展示、敏感词、控制字符、内容清洗或拒绝、计费不被非法字符干扰、错误原因可见。 |
|
||
| 计费闭环 | 预估、余额校验、冻结、扣费、释放、退款、短信计费记录、账单流水、对账。 |
|
||
| 系统日志闭环 | 登录、创建、修改、删除、审核、导入导出、密钥重置、发送、报备、账务动作均可查询和定位操作者。 |
|
||
|
||
## 4. 客户端功能用例
|
||
|
||
### TC-CLIENT-001 登录与租户隔离
|
||
|
||
- 优先级：P0
|
||
- 前置条件：存在 `tenant-a` 和 `tenant-b`，两个租户各有发送任务和账单流水。
|
||
- 步骤：
|
||
1. 使用 `tenant-a` 企业管理员登录客户端。
|
||
2. 打开工作台、批量任务、发送详情、上行短信、账单流水。
|
||
3. 使用查询条件搜索 `tenant-b` 的任务编号或手机号。
|
||
- 预期结果：
|
||
- 登录成功，返回当前租户上下文。
|
||
- 所有列表只展示 `tenant-a` 数据。
|
||
- 查询 `tenant-b` 数据无结果或返回无权限。
|
||
|
||
### TC-CLIENT-002 创建短信应用并重置密钥
|
||
|
||
- 优先级：P1
|
||
- 前置条件：企业管理员已登录。
|
||
- 步骤：
|
||
1. 创建短信应用，填写名称、场景、回调地址、IP 白名单、日限额。
|
||
2. 查询应用列表和详情。
|
||
3. 执行应用密钥重置。
|
||
- 预期结果：
|
||
- 应用创建成功，状态为 active。
|
||
- IP 白名单、日限额、模板不匹配策略保存正确。
|
||
- 密钥重置后旧密钥不可见，新密钥或密钥摘要更新。
|
||
- 生成操作日志。
|
||
|
||
### TC-CLIENT-003 签名创建、材料上传与提交审核
|
||
|
||
- 优先级：P0
|
||
- 前置条件：MinIO 不可用时使用文件服务 mock 或跳过真实上传。
|
||
- 步骤：
|
||
1. 创建短信签名，填写名称、用途、引流信息。
|
||
2. 上传或登记签名证明材料。
|
||
3. 提交审核。
|
||
4. 打开签名列表和详情。
|
||
- 预期结果：
|
||
- 签名初始为 draft。
|
||
- 材料与签名关联成功。
|
||
- 提交后签名状态变为 pending。
|
||
- 生成审核记录。
|
||
|
||
### TC-CLIENT-004 模板变量识别与提交审核
|
||
|
||
- 优先级：P0
|
||
- 前置条件：存在 active 应用和可用签名。
|
||
- 步骤：
|
||
1. 创建模板 `验证码为 ${code}`。
|
||
2. 保存后查看变量列表。
|
||
3. 提交模板审核。
|
||
- 预期结果：
|
||
- 系统识别变量 `code`。
|
||
- 计费条数按 70/67 字规则预估。
|
||
- 提交后模板状态为 pending。
|
||
- 生成审核记录。
|
||
|
||
### TC-CLIENT-005 客户端发送任务创建成功
|
||
|
||
- 优先级：P0
|
||
- 前置条件：应用、签名、模板审核通过；签名报备通过；账户余额充足；通道可用。
|
||
- 步骤：
|
||
1. 选择应用、签名、模板。
|
||
2. 填写模板变量。
|
||
3. 输入 3 个合法手机号。
|
||
4. 提交立即发送。
|
||
5. 查看批量任务详情和发送明细。
|
||
- 预期结果：
|
||
- 返回批量任务编号。
|
||
- 批量任务 `sourceType=client`。
|
||
- 手机号维度生成 3 条短信记录。
|
||
- 任务进入 queued/sending/completed 之一的正常流转状态。
|
||
- 发送明细可按手机号查询。
|
||
|
||
### TC-CLIENT-006 手机号去重与非法号码提示
|
||
|
||
- 优先级：P0
|
||
- 前置条件：存在通过审核的发送资源。
|
||
- 步骤：
|
||
1. 输入合法号码 A、合法号码 A、非法号码 X、合法号码 B。
|
||
2. 提交发送。
|
||
3. 查看预审结果和任务明细。
|
||
- 预期结果：
|
||
- 重复号码被识别，重复率写入风控指标。
|
||
- 非法号码被识别，非法率写入风控指标。
|
||
- 如命中拒绝阈值，任务被 rejected，返回可读拒绝原因。
|
||
- 如未命中拒绝阈值，仅合法且去重后的号码进入后续发送。
|
||
|
||
### TC-CLIENT-007 账户余额不足禁止发送
|
||
|
||
- 优先级：P0
|
||
- 前置条件：账户余额、套餐余量和授信额度不足。
|
||
- 步骤：
|
||
1. 使用长内容和多个手机号生成较高预估费用。
|
||
2. 提交发送。
|
||
3. 查看账单流水。
|
||
- 预期结果：
|
||
- 发送前账户校验失败。
|
||
- 不创建可发送状态的批量任务，或任务进入 rejected。
|
||
- 不生成冻结/扣费流水。
|
||
- 客户端展示余额不足原因。
|
||
|
||
### TC-CLIENT-008 客户端账单流水查询
|
||
|
||
- 优先级：P1
|
||
- 前置条件：存在充值、冻结、扣费、退款、释放流水。
|
||
- 步骤：
|
||
1. 打开账单流水。
|
||
2. 按时间、交易类型、任务编号查询。
|
||
3. 查看单条流水关联对象。
|
||
- 预期结果：
|
||
- 流水类型和金额方向正确。
|
||
- 任务、短信记录或充值订单可追溯。
|
||
- 客户端只展示本租户流水。
|
||
|
||
### TC-CLIENT-009 客户端上行短信查询
|
||
|
||
- 优先级：P1
|
||
- 前置条件：已通过 Gateway 模拟器写入上行事件。
|
||
- 步骤：
|
||
1. 打开上行短信页面。
|
||
2. 按手机号和时间查询。
|
||
3. 查看上行关联下发记录。
|
||
- 预期结果：
|
||
- 展示上行内容、接入号、接收时间。
|
||
- 可展示匹配到的下发 messageId。
|
||
- 未匹配上行仍可查询，状态或关联为空。
|
||
|
||
## 5. 运营端功能用例
|
||
|
||
### TC-ADMIN-001 签名审核通过
|
||
|
||
- 优先级：P0
|
||
- 前置条件：客户端已提交待审核签名。
|
||
- 步骤：
|
||
1. 运营审核员打开签名审核列表。
|
||
2. 查看签名材料和引流信息。
|
||
3. 点击通过。
|
||
- 预期结果：
|
||
- 签名状态变为 approved。
|
||
- 写入审核记录，包含审核人、动作、时间。
|
||
- 客户端签名列表同步展示通过状态。
|
||
|
||
### TC-ADMIN-002 模板审核驳回
|
||
|
||
- 优先级：P0
|
||
- 前置条件：客户端已提交待审核模板。
|
||
- 步骤：
|
||
1. 运营审核员打开模板审核详情。
|
||
2. 填写驳回原因。
|
||
3. 点击驳回。
|
||
- 预期结果：
|
||
- 模板状态变为 rejected。
|
||
- 驳回原因保存并返回客户端。
|
||
- 被驳回模板不能用于发送。
|
||
|
||
### TC-ADMIN-003 通道创建与启停
|
||
|
||
- 优先级：P0
|
||
- 前置条件：运营管理员已登录。
|
||
- 步骤：
|
||
1. 创建 CMPP 通道，填写网关地址、端口、账号、密码密文、接入号、限速。
|
||
2. 查询通道列表。
|
||
3. 停用通道后创建发送任务。
|
||
- 预期结果：
|
||
- 通道协议默认为 CMPP，版本默认为 3.0。
|
||
- 通道限速保存正确。
|
||
- 停用通道不会被路由选中。
|
||
|
||
### TC-ADMIN-004 通道组与路由规则
|
||
|
||
- 优先级：P0
|
||
- 前置条件：存在主通道和备用通道。
|
||
- 步骤：
|
||
1. 创建通道组。
|
||
2. 添加主通道优先级 10、备用通道优先级 20。
|
||
3. 创建租户/应用维度路由规则。
|
||
4. 创建发送任务触发送链路。
|
||
- 预期结果：
|
||
- 路由优先命中租户/应用规则。
|
||
- 主通道 active 时选择主通道。
|
||
- 主通道 disabled 时选择备用 active 通道。
|
||
|
||
### TC-ADMIN-005 签名报备任务生成与导出
|
||
|
||
- 优先级：P0
|
||
- 前置条件：签名审核通过，通道配置了报备字段。
|
||
- 步骤：
|
||
1. 为签名登记通道报备材料。
|
||
2. 生成报备任务。
|
||
3. 执行报备资料导出。
|
||
4. 查看报备记录。
|
||
- 预期结果：
|
||
- 生成 pending 报备任务。
|
||
- 导出后任务状态变为 exporting。
|
||
- 生成导出文件记录。
|
||
- 报备记录包含 create/export 两个动作。
|
||
|
||
### TC-ADMIN-006 报备回执导入通过
|
||
|
||
- 优先级：P0
|
||
- 前置条件：存在 exporting 报备任务。
|
||
- 步骤：
|
||
1. 导入全部成功的通道回执。
|
||
2. 查看报备任务和签名状态。
|
||
- 预期结果：
|
||
- 导入批次记录 rowCount、successCount、failedCount。
|
||
- 报备任务状态变为 approved。
|
||
- 签名 `reportStatus` 同步为 approved。
|
||
- 报备记录包含 receipt_import。
|
||
|
||
### TC-ADMIN-007 报备回执导入失败
|
||
|
||
- 优先级：P1
|
||
- 前置条件：存在 exporting 报备任务。
|
||
- 步骤：
|
||
1. 导入存在失败行的通道回执。
|
||
2. 填写失败原因。
|
||
3. 查看签名报备状态。
|
||
- 预期结果：
|
||
- 报备任务状态变为 rejected 或 partial_approved。
|
||
- 失败原因可查询。
|
||
- 签名报备状态同步为对应失败状态。
|
||
|
||
### TC-ADMIN-008 风控规则配置覆盖默认规则
|
||
|
||
- 优先级：P0
|
||
- 前置条件：存在平台默认风控规则。
|
||
- 步骤：
|
||
1. 为 `tenant-a` 创建同 code 的租户级规则，阈值低于平台默认值。
|
||
2. 提交达到租户阈值但未达到平台阈值的任务。
|
||
3. 查看风控命中记录。
|
||
- 预期结果：
|
||
- 生效规则使用租户级配置。
|
||
- 风控命中记录写入租户规则 id、规则编号、阈值、实际值、处理动作。
|
||
- 运营端审核页面展示命中原因。
|
||
|
||
### TC-ADMIN-009 短信审核通过后入队
|
||
|
||
- 优先级：P0
|
||
- 前置条件：发送任务因风控进入 pending_review。
|
||
- 步骤：
|
||
1. 运营审核员打开短信审核详情。
|
||
2. 查看号码量、内容、计费条数、命中规则。
|
||
3. 点击通过。
|
||
4. 查看发送队列和任务状态。
|
||
- 预期结果：
|
||
- 审核状态变为 approved。
|
||
- 任务进入 queued/sending。
|
||
- 生成发送队列消息。
|
||
- 审核动作写入日志。
|
||
|
||
### TC-ADMIN-010 短信审核驳回
|
||
|
||
- 优先级：P0
|
||
- 前置条件：发送任务因风控进入 pending_review。
|
||
- 步骤：
|
||
1. 运营审核员填写驳回原因。
|
||
2. 点击驳回。
|
||
3. 客户端查看任务状态。
|
||
- 预期结果：
|
||
- 任务状态变为 rejected。
|
||
- 不再进入发送队列。
|
||
- 客户端可见驳回原因。
|
||
|
||
### TC-ADMIN-011 运营看板与监控
|
||
|
||
- 优先级：P1
|
||
- 前置条件：存在 delivered、failed、unknown、timeout 多种短信记录。
|
||
- 步骤：
|
||
1. 打开运营看板。
|
||
2. 打开发送监控。
|
||
3. 按租户和通道过滤。
|
||
- 预期结果：
|
||
- 看板展示任务数、发送状态分布、上行数、账务聚合。
|
||
- 监控展示最近发送、最近回执、最近上行。
|
||
- 过滤条件生效。
|
||
|
||
### TC-ADMIN-012 发送链路 Trace
|
||
|
||
- 优先级：P0
|
||
- 前置条件：存在一条完成 submit result、receipt、billing、uplink 的短信。
|
||
- 步骤：
|
||
1. 在运营端按 messageId 查询 trace。
|
||
2. 查看批量任务、API 请求、提交记录、回执记录、计费记录、上行记录。
|
||
- 预期结果：
|
||
- trace 返回完整链路。
|
||
- submitId、sequenceId、gatewayMessageId 可追踪。
|
||
- 计费记录和短信记录金额一致。
|
||
|
||
### TC-ADMIN-013 对账 reconciliation
|
||
|
||
- 优先级：P0
|
||
- 前置条件：存在同一 taskId 下的短信记录、短信计费记录和账户流水。
|
||
- 步骤：
|
||
1. 按租户和 taskId 查询对账。
|
||
2. 对比短信记录金额、计费记录金额、账户流水金额。
|
||
- 预期结果：
|
||
- 无异常时 diff 为 0。
|
||
- 若人为构造缺失流水，diff 展示差额。
|
||
- 查询结果支持定位 taskId/messageId。
|
||
|
||
## 6. 风控规则专项用例
|
||
|
||
### TC-RISK-001 单任务最大号码数直接拒绝
|
||
|
||
- 优先级：P0
|
||
- 前置条件：应用最大号码数阈值为 100。
|
||
- 步骤：提交 101 个合法号码。
|
||
- 预期结果：
|
||
- 命中 `MAX_PHONES_PER_TASK`。
|
||
- 任务 rejected。
|
||
- 风控命中记录包含阈值 100、实际值 101、动作 reject/block。
|
||
|
||
### TC-RISK-002 重复号码比例进入人工审核
|
||
|
||
- 优先级：P0
|
||
- 前置条件：重复率阈值为 30%，动作为人工审核。
|
||
- 步骤：提交 10 个号码，其中 4 个为重复号码。
|
||
- 预期结果：
|
||
- duplicateRatio 为 0.4。
|
||
- 命中重复号码规则。
|
||
- 任务 pending_review。
|
||
|
||
### TC-RISK-003 非法号码比例直接拒绝
|
||
|
||
- 优先级：P0
|
||
- 前置条件：非法率阈值为 10%，动作为拒绝。
|
||
- 步骤：提交 10 个号码，其中 2 个非法。
|
||
- 预期结果：
|
||
- illegalRatio 为 0.2。
|
||
- 任务 rejected。
|
||
- 客户端展示非法号码比例过高。
|
||
|
||
### TC-RISK-004 黑名单命中比例人工审核
|
||
|
||
- 优先级：P0
|
||
- 前置条件：黑名单率阈值为 5%，动作为人工审核。
|
||
- 步骤：提交 20 个号码，其中 2 个在企业或全局黑名单。
|
||
- 预期结果：
|
||
- blacklistHitRatio 为 0.1。
|
||
- 任务 pending_review。
|
||
- 命中记录写入黑名单规则。
|
||
|
||
### TC-RISK-005 模板变量缺失直接拒绝
|
||
|
||
- 优先级：P0
|
||
- 前置条件：模板要求变量 `code`。
|
||
- 步骤：提交发送时不传 `code`，或额外传入未定义变量。
|
||
- 预期结果：
|
||
- 命中 `TEMPLATE_VARIABLE_ANOMALY`。
|
||
- 任务 rejected。
|
||
- variableIssues 记录缺失或多传变量。
|
||
|
||
### TC-RISK-006 非工作时间营销大批量人工审核
|
||
|
||
- 优先级：P1
|
||
- 前置条件：非工作时间大批量阈值为 5000。
|
||
- 步骤：在 21:00 后提交营销类短信 5001 个号码。
|
||
- 预期结果：
|
||
- 命中非工作时间营销大批量规则。
|
||
- 任务 pending_review。
|
||
- 审核原因可见。
|
||
|
||
### TC-RISK-007 短时间任务创建频控
|
||
|
||
- 优先级：P1
|
||
- 前置条件：10 分钟最多创建 10 次任务。
|
||
- 步骤：同租户同应用 10 分钟内创建第 11 个任务。
|
||
- 预期结果：
|
||
- 命中频控规则。
|
||
- 按规则动作进入人工审核或拒绝。
|
||
- 命中记录包含 recentTaskCount。
|
||
|
||
## 7. 计费专项用例
|
||
|
||
### TC-BILLING-001 70/67 计费条数
|
||
|
||
- 优先级：P0
|
||
- 步骤：
|
||
1. 使用 70 字内容提交 1 个号码。
|
||
2. 使用 71 字内容提交 1 个号码。
|
||
3. 使用 134 字内容提交 1 个号码。
|
||
- 预期结果：
|
||
- 70 字为 1 条。
|
||
- 71 字为 2 条。
|
||
- 134 字为 2 条。
|
||
- 金额等于计费条数乘单价。
|
||
|
||
### TC-BILLING-002 发送前冻结
|
||
|
||
- 优先级：P0
|
||
- 前置条件：账户余额充足，计费口径需要发送前冻结。
|
||
- 步骤：创建发送任务并进入待发送。
|
||
- 预期结果：
|
||
- 生成 frozen 流水。
|
||
- 账户余额或套餐余量减少。
|
||
- 流水关联 taskId。
|
||
|
||
### TC-BILLING-003 submit 成功扣费
|
||
|
||
- 优先级：P0
|
||
- 前置条件：计费口径为 submit_success。
|
||
- 步骤：模拟 Gateway 返回 submit accepted。
|
||
- 预期结果：
|
||
- 生成 charged 流水。
|
||
- 短信计费记录状态更新为 charged。
|
||
- 可按 messageId 对账。
|
||
|
||
### TC-BILLING-004 最终失败退款
|
||
|
||
- 优先级：P0
|
||
- 前置条件：短信已扣费。
|
||
- 步骤：模拟 receipt undelivered。
|
||
- 预期结果：
|
||
- 短信状态 failed/undelivered。
|
||
- 生成 refunded 流水。
|
||
- 退款金额与原扣费一致。
|
||
|
||
### TC-BILLING-005 72 小时超时退款
|
||
|
||
- 优先级：P0
|
||
- 前置条件：短信状态 unknown 且超过 72 小时。
|
||
- 步骤：执行未知转超时补偿任务。
|
||
- 预期结果：
|
||
- 短信状态 timeout。
|
||
- 生成退款或释放流水。
|
||
- 后续二次成功回执不自动覆盖 timeout 状态。
|
||
|
||
## 8. 发送链路专项用例
|
||
|
||
### TC-SEND-001 批量任务创建和手机号拆分
|
||
|
||
- 优先级：P0
|
||
- 步骤：提交包含多个手机号的客户端批量任务。
|
||
- 预期结果：
|
||
- 生成 1 条 `SmsBatchTask`。
|
||
- 每个有效手机号生成 1 条 `SmsMessageRecord`。
|
||
- `SmsBatchTask.progressTotal` 等于有效手机号数量。
|
||
|
||
### TC-SEND-002 发送任务入队
|
||
|
||
- 优先级：P0
|
||
- 前置条件：任务审核通过。
|
||
- 步骤：触发送 worker 入队。
|
||
- 预期结果：
|
||
- 每条 queued 短信生成一个发送 job。
|
||
- jobId 使用 messageRecordId，避免重复入队。
|
||
- 批量任务状态变为 queued。
|
||
|
||
### TC-SEND-003 通道路由和 Gateway SubmitCommand
|
||
|
||
- 优先级：P0
|
||
- 前置条件：存在 active 通道和路由规则。
|
||
- 步骤：处理一条发送 job。
|
||
- 预期结果：
|
||
- 选择正确通道。
|
||
- 创建 SmsSubmitRecord。
|
||
- 投递 Gateway SubmitCommand，包含 traceId、messageId、channelId、submitId、phoneNumber、content、cmpp 参数。
|
||
|
||
### TC-SEND-004 SubmitResult accepted
|
||
|
||
- 优先级：P0
|
||
- 步骤：模拟 Gateway 返回 accepted。
|
||
- 预期结果：
|
||
- SmsSubmitRecord 写入 sequenceId、gatewayMessageId、accepted 状态。
|
||
- SmsMessageRecord 状态变为 submitted。
|
||
- 批量任务进度刷新。
|
||
|
||
### TC-SEND-005 SubmitResult rejected
|
||
|
||
- 优先级：P0
|
||
- 步骤：模拟 Gateway 返回 rejected 和错误码。
|
||
- 预期结果：
|
||
- SmsMessageRecord 状态变为 submit_failed。
|
||
- 记录 errorCode/errorMessage。
|
||
- 失败数统计增加。
|
||
|
||
### TC-SEND-006 Receipt delivered
|
||
|
||
- 优先级：P0
|
||
- 步骤：模拟 deliver 回执 `DELIVRD`。
|
||
- 预期结果：
|
||
- 创建 SmsReceiptRecord。
|
||
- SmsMessageRecord 状态变为 delivered。
|
||
- 成功数统计增加。
|
||
|
||
### TC-SEND-007 Receipt unknown 后超时
|
||
|
||
- 优先级：P0
|
||
- 步骤：
|
||
1. 模拟 unknown 回执。
|
||
2. 将 deliveredAt 调整为 72 小时前。
|
||
3. 执行超时补偿。
|
||
- 预期结果：
|
||
- unknown 记录转为 timeout。
|
||
- timeoutTotal 增加。
|
||
- 错误信息说明 72 小时未收到明确回执。
|
||
|
||
### TC-SEND-008 上行短信匹配
|
||
|
||
- 优先级：P1
|
||
- 步骤：模拟带 messageId 的上行事件。
|
||
- 预期结果：
|
||
- 创建 SmsUplinkMessage。
|
||
- tenantId 可通过 messageId 关联。
|
||
- 客户端和运营端均可查询。
|
||
|
||
### TC-SEND-009 未匹配上行短信入库
|
||
|
||
- 优先级：P1
|
||
- 步骤：模拟不带 messageId 或匹配不到下发记录的上行事件。
|
||
- 预期结果：
|
||
- 上行短信仍入库。
|
||
- tenantId 可为空。
|
||
- 运营端可查询并人工判断。
|
||
|
||
## 9. Gateway 专项用例
|
||
|
||
### TC-GW-001 SEQID/MSGID 追踪
|
||
|
||
- 优先级：P0
|
||
- 步骤：
|
||
1. Gateway 接收 SubmitCommand。
|
||
2. 分配 sequenceId。
|
||
3. 模拟 submit resp 返回 gatewayMessageId。
|
||
4. 按 gatewayMessageId 查询映射。
|
||
- 预期结果：
|
||
- messageId、sequenceId、gatewayMessageId 三者可互查。
|
||
- 并发提交时映射不串。
|
||
|
||
### TC-GW-002 重连后继续消费
|
||
|
||
- 优先级：P0
|
||
- 步骤：
|
||
1. 模拟 SMSC 连接失败。
|
||
2. Gateway 执行重连。
|
||
3. 重连成功后继续处理新 SubmitCommand。
|
||
- 预期结果：
|
||
- 重连次数可观测。
|
||
- 未成功连接时不丢失任务。
|
||
- 连接恢复后继续消费。
|
||
|
||
### TC-GW-003 Health 检查
|
||
|
||
- 优先级：P0
|
||
- 步骤：访问 Gateway `/health`。
|
||
- 预期结果：
|
||
- 返回 HTTP 200。
|
||
- payload 包含 `status=ok` 和服务名。
|
||
|
||
### TC-GW-004 gocmpp submit/resp 模拟器
|
||
|
||
- 优先级：P0
|
||
- 步骤：
|
||
1. 启动或调用模拟 SMSC。
|
||
2. Gateway 发起 submit。
|
||
3. 模拟器返回 submit resp 和 deliver。
|
||
- 预期结果：
|
||
- submit resp 可解析。
|
||
- deliver 回执可转为队列事件。
|
||
- 不依赖真实运营商。
|
||
|
||
### TC-GW-005 重复回执
|
||
|
||
- 优先级：P1
|
||
- 步骤：同一 gatewayMessageId 连续发送两次 delivered 回执。
|
||
- 预期结果：
|
||
- 第一条更新最终状态。
|
||
- 第二条记录历史或被幂等处理。
|
||
- 不重复扣费或重复变更最终状态。
|
||
|
||
## 10. 契约与队列用例
|
||
|
||
### TC-CONTRACT-001 SubmitCommand Schema 校验
|
||
|
||
- 优先级：P0
|
||
- 步骤：运行 `npm run spike:contracts`。
|
||
- 预期结果：`submit-command.json` 通过 schema 校验。
|
||
|
||
### TC-CONTRACT-002 SubmitResult Schema 校验
|
||
|
||
- 优先级：P0
|
||
- 步骤：运行 `npm run spike:contracts`。
|
||
- 预期结果：`submit-result.json` 通过 schema 校验。
|
||
|
||
### TC-CONTRACT-003 ReceiptEvent Schema 校验
|
||
|
||
- 优先级：P0
|
||
- 步骤：运行 `npm run spike:contracts`。
|
||
- 预期结果：`receipt-event.json` 通过 schema 校验。
|
||
|
||
### TC-CONTRACT-004 UplinkEvent Schema 校验
|
||
|
||
- 优先级：P0
|
||
- 步骤：运行 `npm run spike:contracts`。
|
||
- 预期结果：`uplink-event.json` 通过 schema 校验。
|
||
|
||
## 11. 端到端 Smoke 用例
|
||
|
||
### TC-E2E-001 核心发送闭环
|
||
|
||
- 优先级：P0
|
||
- 前置条件：使用测试替身或本地 PostgreSQL/Redis 环境。
|
||
- 步骤：
|
||
1. 创建租户、应用、签名、模板、通道、路由。
|
||
2. 审核签名和模板通过。
|
||
3. 创建发送任务。
|
||
4. 发送入队。
|
||
5. 模拟 Gateway submit accepted。
|
||
6. 模拟 receipt delivered。
|
||
7. 查询 trace 和 reconciliation。
|
||
- 预期结果：
|
||
- 任务从 created/ready 流转到 finished。
|
||
- 单条短信状态为 delivered。
|
||
- trace 链路完整。
|
||
- 对账差异为 0。
|
||
|
||
### TC-E2E-002 风控人工审核闭环
|
||
|
||
- 优先级：P0
|
||
- 步骤：
|
||
1. 提交命中人工审核规则的发送任务。
|
||
2. 运营端查看审核原因。
|
||
3. 审核通过。
|
||
4. 发送入队并完成回执。
|
||
- 预期结果：
|
||
- 审核前不入队。
|
||
- 审核原因包含命中规则。
|
||
- 审核通过后进入发送链路。
|
||
|
||
### TC-E2E-003 失败退款闭环
|
||
|
||
- 优先级：P0
|
||
- 步骤：
|
||
1. 创建余额充足的发送任务。
|
||
2. 发送前冻结或 submit 成功扣费。
|
||
3. 模拟最终失败回执。
|
||
4. 查询账单流水和对账。
|
||
- 预期结果：
|
||
- 失败短信触发退款。
|
||
- 账务流水可追溯。
|
||
- 对账 diff 为 0。
|
||
|
||
## 12. 前端 Smoke 用例
|
||
|
||
### TC-WEB-001 客户端主页面加载
|
||
|
||
- 优先级：P1
|
||
- 步骤：打开客户端工作台、短信发送、批量任务、发送详情、上行短信、账单流水。
|
||
- 预期结果：
|
||
- 页面无白屏。
|
||
- 关键表格、筛选项、按钮可见。
|
||
- 控制台无阻断错误。
|
||
|
||
### TC-WEB-002 运营端主页面加载
|
||
|
||
- 优先级：P1
|
||
- 步骤：打开运营看板、发送监控、短信审核、通道管理、报备任务、短信记录、账单流水。
|
||
- 预期结果：
|
||
- 页面无白屏。
|
||
- 表格和操作按钮可见。
|
||
- 彩信相关页面仍保持第一版边界，不进入短信主链路。
|
||
|
||
### TC-WEB-003 响应式 Smoke
|
||
|
||
- 优先级：P2
|
||
- 步骤：在桌面宽屏和移动宽度打开核心页面。
|
||
- 预期结果：
|
||
- 文本不重叠。
|
||
- 表格或卡片可滚动/适配。
|
||
- 主要操作按钮不被遮挡。
|
||
|
||
## 13. 性能 Smoke 用例
|
||
|
||
### TC-PERF-001 BullMQ 500 TPS Smoke
|
||
|
||
- 优先级：P0
|
||
- 步骤：运行 `npm run spike:bullmq`。
|
||
- 预期结果：
|
||
- 15000 条消息处理完成。
|
||
- endToEndTps 不低于 500。
|
||
- submitResults 和 receiptEvents 均等于 15000。
|
||
|
||
### TC-PERF-002 队列积压恢复
|
||
|
||
- 优先级：P1
|
||
- 步骤：
|
||
1. 连续提交 15000 条消息。
|
||
2. 观察处理完成时间和队列积压。
|
||
- 预期结果：
|
||
- 压测停止后队列可恢复到无积压。
|
||
- 无重复最终状态。
|
||
- 错误率满足阶段 0/8 性能报告要求。
|
||
|
||
## 14. 业务闭环补充用例
|
||
|
||
### TC-CERT-001 企业认证资料提交
|
||
|
||
- 优先级：P0
|
||
- 前置条件：企业处于未认证状态，客户端企业管理员已登录。
|
||
- 步骤：
|
||
1. 打开企业认证页面。
|
||
2. 填写企业名称、统一社会信用代码、联系人、联系电话。
|
||
3. 上传营业执照和授权材料，提交认证。
|
||
4. 打开客户端工作台和企业认证详情。
|
||
- 预期结果：
|
||
- 企业认证状态从未认证变为 pending。
|
||
- 认证资料、文件对象、提交人和提交时间保存。
|
||
- 客户端可查看待审核状态，不允许重复提交相同版本资料。
|
||
- 系统日志记录企业认证提交动作。
|
||
|
||
### TC-CERT-002 企业认证审核通过后开放发送能力
|
||
|
||
- 优先级：P0
|
||
- 前置条件：企业认证状态为 pending，短信应用/签名/模板已准备好。
|
||
- 步骤：
|
||
1. 运营审核员查看企业认证资料。
|
||
2. 审核通过。
|
||
3. 客户端刷新企业认证状态。
|
||
4. 客户端创建或提交短信发送任务。
|
||
- 预期结果：
|
||
- 企业认证状态变为 approved。
|
||
- 审核记录包含审核人、审核时间、审核动作。
|
||
- 客户端可见已认证状态。
|
||
- 受认证约束的发送能力开放，发送任务可进入后续风控/计费/发送链路。
|
||
- 系统日志记录审核通过动作。
|
||
|
||
### TC-CERT-003 企业认证驳回与重新提交
|
||
|
||
- 优先级：P0
|
||
- 前置条件：企业认证状态为 pending。
|
||
- 步骤：
|
||
1. 运营审核员填写驳回原因并驳回。
|
||
2. 客户端查看驳回原因。
|
||
3. 客户端修改资料并重新提交。
|
||
4. 运营端再次审核通过。
|
||
- 预期结果：
|
||
- 驳回后状态为 rejected，驳回原因对客户端可见。
|
||
- 驳回状态下，受认证约束的发送能力被阻断，并给出认证未通过原因。
|
||
- 重新提交后状态回到 pending，保留历史审核记录。
|
||
- 最终通过后可正常发送。
|
||
|
||
### TC-CERT-004 企业停用对发送的影响
|
||
|
||
- 优先级：P0
|
||
- 前置条件：企业已认证并存在可发送资源。
|
||
- 步骤：
|
||
1. 运营端将企业状态改为 disabled。
|
||
2. 客户端尝试创建立即发送任务。
|
||
3. 客户端尝试创建定时发送任务。
|
||
4. 到达已有定时任务执行时间。
|
||
- 预期结果：
|
||
- 新建立即任务被拒绝，原因包含企业已停用。
|
||
- 新建定时任务被拒绝。
|
||
- 已存在但未执行的定时任务到点前重新校验企业状态，企业停用时不入队，任务变为 rejected/canceled。
|
||
- 系统日志记录企业停用和发送阻断。
|
||
|
||
### TC-TEMPLATE-001 多变量模板识别与顺序展示
|
||
|
||
- 优先级：P0
|
||
- 前置条件：存在 active 应用和可用签名。
|
||
- 步骤：
|
||
1. 创建模板 `尊敬的${name}，您的订单${orderNo}将于${date}送达，验证码${code}`。
|
||
2. 保存模板并查看变量列表。
|
||
3. 提交审核并由运营端审核通过。
|
||
4. 客户端进入发送页选择该模板。
|
||
- 预期结果：
|
||
- 系统识别 `name`、`orderNo`、`date`、`code` 四个变量。
|
||
- 变量不重复，展示顺序与模板中首次出现顺序一致。
|
||
- 审核通过后模板可被选择发送。
|
||
- 系统日志记录模板创建、提交审核、审核通过。
|
||
|
||
### TC-TEMPLATE-002 多变量完整填充发送成功
|
||
|
||
- 优先级：P0
|
||
- 前置条件：多变量模板审核通过，签名报备通过，账户余额充足。
|
||
- 步骤：
|
||
1. 选择多变量模板。
|
||
2. 填写全部变量：`name`、`orderNo`、`date`、`code`。
|
||
3. 输入合法手机号并提交立即发送。
|
||
4. 模拟 submit accepted 和 delivered 回执。
|
||
5. 查询发送详情、trace 和计费记录。
|
||
- 预期结果：
|
||
- 发送内容正确替换所有变量。
|
||
- 内容长度按替换后的真实内容计费。
|
||
- 生成批量任务、手机号记录、提交记录、回执记录和计费记录。
|
||
- trace 中可看到模板、变量、messageId、submitId、gatewayMessageId。
|
||
|
||
### TC-TEMPLATE-003 多变量缺失、空值和多传
|
||
|
||
- 优先级：P0
|
||
- 前置条件：多变量模板审核通过。
|
||
- 步骤：
|
||
1. 缺少 `orderNo` 提交发送。
|
||
2. 将 `date` 传为空字符串提交发送。
|
||
3. 额外传入未定义变量 `coupon` 提交发送。
|
||
4. 查看风控命中和客户端错误展示。
|
||
- 预期结果：
|
||
- 缺少必填变量命中模板变量异常。
|
||
- 必填变量为空按缺失或格式异常处理。
|
||
- 多传变量命中模板变量异常或被明确提示不允许。
|
||
- 任务不入队，错误原因包含变量名。
|
||
- 不生成冻结/扣费流水。
|
||
|
||
### TC-TEMPLATE-004 多变量重复出现只需填写一次
|
||
|
||
- 优先级：P1
|
||
- 前置条件：模板内容为 `${name}您好，${name}的验证码为${code}`。
|
||
- 步骤：
|
||
1. 保存模板并查看变量列表。
|
||
2. 发送时只填写一次 `name` 和一次 `code`。
|
||
3. 提交发送。
|
||
- 预期结果：
|
||
- 变量列表只展示一个 `name`。
|
||
- 发送内容中两处 `${name}` 均被替换。
|
||
- 计费按最终内容长度计算。
|
||
|
||
### TC-TEMPLATE-005 变量值超长导致计费条数变化
|
||
|
||
- 优先级：P1
|
||
- 前置条件：模板审核通过，单价已配置。
|
||
- 步骤：
|
||
1. 使用短变量值预估费用。
|
||
2. 使用超长变量值，使最终内容从 1 条变为 2 条或更多。
|
||
3. 提交发送。
|
||
- 预期结果：
|
||
- 费用预估按最终替换内容计算。
|
||
- 发送前账户校验使用最终计费条数。
|
||
- 短信计费记录的 contentLength、billingUnits、amountCents 与最终内容一致。
|
||
|
||
### TC-IMPORT-001 CSV 导入发送成功闭环
|
||
|
||
- 优先级：P0
|
||
- 前置条件：模板审核通过，账户余额充足，准备 UTF-8 CSV 文件，包含手机号和变量列。
|
||
- 步骤：
|
||
1. 在发送页选择文件导入。
|
||
2. 上传 CSV，字段包含 `phone,name,code`。
|
||
3. 系统解析并展示导入总数、有效数、无效数、重复数。
|
||
4. 确认提交发送。
|
||
5. 模拟 Gateway submit 和 receipt。
|
||
6. 查询批量任务、发送详情、trace、账单流水。
|
||
- 预期结果：
|
||
- CSV 解析成功，变量列映射到模板变量。
|
||
- 每个有效手机号生成一条短信记录。
|
||
- 无效和重复数据展示在导入结果中，不进入发送或按配置处理。
|
||
- 生成任务、明细、提交记录、回执记录、计费记录和账务流水。
|
||
|
||
### TC-IMPORT-002 TXT 导入号码发送
|
||
|
||
- 优先级：P0
|
||
- 前置条件：无变量模板或变量使用统一值。
|
||
- 步骤：
|
||
1. 上传 TXT 文件，号码以换行、逗号、空格混合分隔。
|
||
2. 预览解析结果。
|
||
3. 提交发送。
|
||
- 预期结果：
|
||
- 系统正确拆分号码。
|
||
- 去除空行和前后空格。
|
||
- 合法号码进入发送，非法号码展示原因。
|
||
- 生成批量任务和手机号记录。
|
||
|
||
### TC-IMPORT-003 GBK CSV 导入兼容
|
||
|
||
- 优先级：P1
|
||
- 前置条件：准备 GBK 编码 CSV，包含中文变量值。
|
||
- 步骤：
|
||
1. 上传 GBK CSV。
|
||
2. 预览变量值。
|
||
3. 提交发送并查看发送内容。
|
||
- 预期结果：
|
||
- 中文内容不乱码。
|
||
- 变量替换正确。
|
||
- 计费长度按正确解码后的内容计算。
|
||
|
||
### TC-IMPORT-004 导入文件超过 20 MB
|
||
|
||
- 优先级：P0
|
||
- 前置条件：准备大于 20 MB 的 CSV/TXT 文件。
|
||
- 步骤：上传文件。
|
||
- 预期结果：
|
||
- 上传或解析前被拒绝。
|
||
- 客户端展示文件大小超限。
|
||
- 不创建批量任务，不生成计费或发送记录。
|
||
- 系统日志记录导入失败原因。
|
||
|
||
### TC-IMPORT-005 导入文件中含重复、非法、黑名单号码
|
||
|
||
- 优先级：P0
|
||
- 前置条件：文件包含重复号码、非法号码、企业黑名单号码、全局黑名单号码。
|
||
- 步骤：
|
||
1. 上传文件。
|
||
2. 查看导入分析。
|
||
3. 提交发送。
|
||
4. 查看风控命中记录和发送明细。
|
||
- 预期结果：
|
||
- 导入分析展示总数、重复数、非法数、黑名单命中数。
|
||
- 重复率、非法率、黑名单率进入风控评估。
|
||
- 命中拒绝规则时任务 rejected，不入队。
|
||
- 命中人工审核规则时任务 pending_review，审核原因展示具体指标。
|
||
|
||
### TC-IMPORT-006 导入变量列缺失
|
||
|
||
- 优先级：P0
|
||
- 前置条件：模板要求 `name` 和 `code`，CSV 只包含 `phone,name`。
|
||
- 步骤：
|
||
1. 上传 CSV。
|
||
2. 尝试提交发送。
|
||
- 预期结果：
|
||
- 导入预览提示缺少 `code` 列。
|
||
- 不允许提交，或提交后风控变量异常直接拒绝。
|
||
- 不生成发送队列，不产生扣费。
|
||
|
||
### TC-CONTENT-001 发送内容包含控制字符
|
||
|
||
- 优先级：P0
|
||
- 前置条件：模板或变量值中包含不可见控制字符，例如 `\u0000`、`\u001F`。
|
||
- 步骤：
|
||
1. 输入含控制字符的变量值。
|
||
2. 查看发送预览。
|
||
3. 提交发送。
|
||
- 预期结果：
|
||
- 客户端明确标识或提示非法字符位置。
|
||
- 后端校验拒绝或清洗策略明确且一致。
|
||
- 若拒绝，不创建可发送状态任务，不计费。
|
||
- 若清洗，预览内容、计费内容、实际发送内容必须一致。
|
||
- 系统日志记录非法字符校验结果。
|
||
|
||
### TC-CONTENT-002 emoji 和 UCS2 内容计费
|
||
|
||
- 优先级：P0
|
||
- 前置条件：内容或变量值包含 emoji 或非 GSM 字符。
|
||
- 步骤：
|
||
1. 输入包含 emoji 的短信内容。
|
||
2. 查看预估字数和计费条数。
|
||
3. 提交发送并查看短信计费记录。
|
||
- 预期结果：
|
||
- 系统明确展示特殊字符。
|
||
- 计费条数按第一版规则 70/67 执行，不被 emoji 拆分错误干扰。
|
||
- contentLength 与系统定义的字符统计口径一致。
|
||
- 发送记录、计费记录、trace 中内容一致。
|
||
|
||
### TC-CONTENT-003 换行、制表符和多空格展示
|
||
|
||
- 优先级：P1
|
||
- 前置条件：模板变量值包含换行、制表符或连续空格。
|
||
- 步骤：
|
||
1. 输入特殊空白字符。
|
||
2. 查看发送预览、审核详情和发送详情。
|
||
3. 提交发送。
|
||
- 预期结果：
|
||
- 页面展示不破版，特殊空白有可识别展示或被规范化。
|
||
- 计费按最终规范化后的内容计算。
|
||
- 审核详情和发送详情展示内容一致。
|
||
|
||
### TC-CONTENT-004 敏感词和非法字符同时命中
|
||
|
||
- 优先级：P0
|
||
- 前置条件：敏感词库包含 `测试敏感词`。
|
||
- 步骤：
|
||
1. 发送内容同时包含敏感词和非法控制字符。
|
||
2. 提交发送。
|
||
- 预期结果：
|
||
- 任务被拒绝。
|
||
- 错误原因同时或按优先级展示敏感词、非法字符问题。
|
||
- 不入队，不冻结，不扣费。
|
||
- 风控命中或系统日志可追溯两个校验结果。
|
||
|
||
### TC-SCHEDULE-001 创建定时短信任务
|
||
|
||
- 优先级：P0
|
||
- 前置条件：发送资源审核和报备均通过，账户余额充足。
|
||
- 步骤：
|
||
1. 在发送页选择定时发送。
|
||
2. 设置发送时间为当前时间 10 分钟后。
|
||
3. 提交任务。
|
||
4. 查看批量任务列表和详情。
|
||
- 预期结果：
|
||
- 返回批量任务编号。
|
||
- 任务状态为 scheduled。
|
||
- 任务详情展示计划发送时间。
|
||
- 到点前不生成 Gateway SubmitCommand，不产生 submit 记录。
|
||
- 如采用发送前冻结，冻结流水生成；如采用到点前冻结，则无冻结流水但有费用预估。
|
||
|
||
### TC-SCHEDULE-002 定时任务到点发送并生成记录
|
||
|
||
- 优先级：P0
|
||
- 前置条件：存在 scheduled 任务，计划发送时间已到。
|
||
- 步骤：
|
||
1. 触发调度器或等待时间到达。
|
||
2. 观察任务状态。
|
||
3. 模拟 Gateway submit accepted 和 delivered。
|
||
4. 查询批量任务、发送详情、submit 记录、receipt 记录、trace、账单流水。
|
||
- 预期结果：
|
||
- 到点后任务重新校验应用、签名、模板、报备状态、账户余额和通道状态。
|
||
- 校验通过后任务进入 queued/sending。
|
||
- 按手机号生成发送记录或将已创建记录推进到 queued。
|
||
- 生成 SubmitCommand、SmsSubmitRecord、SmsReceiptRecord、SmsBillingRecord 和账务流水。
|
||
- 任务最终完成，成功数、失败数、未知数统计正确。
|
||
|
||
### TC-SCHEDULE-003 定时任务到点前取消
|
||
|
||
- 优先级：P0
|
||
- 前置条件：存在 scheduled 任务且未到执行时间。
|
||
- 步骤：
|
||
1. 客户端取消定时任务。
|
||
2. 查看任务详情和账单流水。
|
||
3. 到达原计划时间。
|
||
- 预期结果：
|
||
- 任务状态变为 canceled。
|
||
- 如已冻结费用，应生成 release 流水。
|
||
- 到点后不会入队，不生成提交记录。
|
||
- 系统日志记录取消动作。
|
||
|
||
### TC-SCHEDULE-004 定时任务到点时余额不足
|
||
|
||
- 优先级：P0
|
||
- 前置条件：创建 scheduled 任务时余额充足，到点前账户余额被其他任务消耗。
|
||
- 步骤：
|
||
1. 创建定时任务。
|
||
2. 调整或消耗账户余额至不足。
|
||
3. 到点触发调度。
|
||
- 预期结果：
|
||
- 到点前重新进行账户校验。
|
||
- 余额不足时任务不入队，状态变为 rejected/failed。
|
||
- 失败原因展示余额不足。
|
||
- 不生成扣费流水；如曾冻结则释放。
|
||
|
||
### TC-SCHEDULE-005 定时任务到点时模板或签名已失效
|
||
|
||
- 优先级：P0
|
||
- 前置条件：存在 scheduled 任务。
|
||
- 步骤：
|
||
1. 创建定时任务。
|
||
2. 到点前运营端驳回、停用或删除关联模板/签名。
|
||
3. 到点触发调度。
|
||
- 预期结果：
|
||
- 调度前重新校验模板和签名可用性。
|
||
- 关联资源不可用时任务不入队。
|
||
- 任务失败原因明确指出模板或签名不可用。
|
||
- 历史任务详情仍可展示原模板/签名快照或名称，不因删除而空白。
|
||
|
||
### TC-SCHEDULE-006 定时任务查看和筛选
|
||
|
||
- 优先级：P1
|
||
- 前置条件：存在 scheduled、queued、finished、canceled 多状态任务。
|
||
- 步骤：
|
||
1. 客户端按任务编号、应用、发送时间、状态查询。
|
||
2. 运营端按租户、应用、状态查询任务进度。
|
||
3. 打开定时任务详情。
|
||
- 预期结果：
|
||
- 查询条件准确生效。
|
||
- 定时任务详情展示计划发送时间、创建时间、创建人、号码总数、预估费用、当前状态。
|
||
- 到点执行后的状态变化在客户端和运营端一致。
|
||
|
||
### TC-LOG-001 登录和登出日志
|
||
|
||
- 优先级：P1
|
||
- 前置条件：存在客户端用户和运营端用户。
|
||
- 步骤：
|
||
1. 分别登录客户端和运营端。
|
||
2. 执行登出或 token 失效。
|
||
3. 查询系统日志。
|
||
- 预期结果：
|
||
- 登录日志记录用户、租户、IP、User-Agent、时间。
|
||
- 登录失败记录失败原因。
|
||
- 运营端可按用户、租户、动作查询。
|
||
|
||
### TC-LOG-002 配置变更日志
|
||
|
||
- 优先级：P0
|
||
- 前置条件：运营管理员和企业管理员均可操作配置。
|
||
- 步骤：
|
||
1. 创建、编辑、删除应用。
|
||
2. 创建、编辑、删除签名、模板、引流信息。
|
||
3. 创建、编辑、停用通道和路由规则。
|
||
4. 查询系统日志。
|
||
- 预期结果：
|
||
- 每个动作均记录 action、resource、resourceId、操作者、租户、时间。
|
||
- 日志 detail 包含关键变更字段的前后值或摘要。
|
||
- 客户端只能查看本企业相关日志，运营端可看全平台。
|
||
|
||
### TC-LOG-003 审核和报备日志
|
||
|
||
- 优先级：P0
|
||
- 步骤：
|
||
1. 执行企业认证审核、签名审核、模板审核、短信审核。
|
||
2. 生成报备任务、导出报备资料、导入回执。
|
||
3. 查询系统日志和业务审核记录。
|
||
- 预期结果：
|
||
- 审核动作有业务审核记录和系统日志两类证据。
|
||
- 报备动作有报备记录和系统日志两类证据。
|
||
- 日志可定位操作人、状态前后值和原因。
|
||
|
||
### TC-LOG-004 导入导出日志
|
||
|
||
- 优先级：P1
|
||
- 步骤：
|
||
1. 导入号码文件。
|
||
2. 导出发送明细或报备资料。
|
||
3. 导入报备回执。
|
||
4. 查询系统日志。
|
||
- 预期结果：
|
||
- 日志记录文件名、文件大小、行数、成功数、失败数、操作者、时间。
|
||
- 导出日志记录导出条件和导出文件 id。
|
||
- 导入失败也应记录失败原因。
|
||
|
||
### TC-DELETE-001 删除未被使用的签名
|
||
|
||
- 优先级：P1
|
||
- 前置条件：签名未关联模板或发送任务。
|
||
- 步骤：
|
||
1. 客户端或运营端删除签名。
|
||
2. 查询签名列表。
|
||
3. 尝试发送时选择该签名。
|
||
- 预期结果：
|
||
- 删除成功或状态变为 deleted。
|
||
- 列表默认不展示。
|
||
- 发送页不可选择该签名。
|
||
- 系统日志记录删除动作。
|
||
|
||
### TC-DELETE-002 删除已关联模板的签名
|
||
|
||
- 优先级：P0
|
||
- 前置条件：签名已关联审核通过模板。
|
||
- 步骤：
|
||
1. 尝试删除签名。
|
||
2. 如系统允许软删除，使用关联模板发起发送。
|
||
3. 查看模板列表和发送错误。
|
||
- 预期结果：
|
||
- 系统应阻止硬删除并提示存在关联模板，或执行软删除/停用。
|
||
- 被删除或停用签名不可用于新发送。
|
||
- 历史发送记录仍保留签名名称或快照。
|
||
- 系统日志记录删除失败或软删除动作。
|
||
|
||
### TC-DELETE-003 删除应用对发送的影响
|
||
|
||
- 优先级：P0
|
||
- 前置条件：应用下存在签名、模板、历史任务和 scheduled 任务。
|
||
- 步骤：
|
||
1. 删除或停用应用。
|
||
2. 尝试创建立即发送任务。
|
||
3. 到达 scheduled 任务执行时间。
|
||
4. 查询历史批量任务和发送明细。
|
||
- 预期结果：
|
||
- 新发送被阻断，原因包含应用不可用。
|
||
- 关联 scheduled 任务到点前重新校验应用状态，应用不可用时不入队。
|
||
- 历史任务和发送明细可查询，不因应用删除丢失。
|
||
- 系统日志记录应用删除/停用和发送阻断。
|
||
|
||
### TC-DELETE-004 删除模板对发送的影响
|
||
|
||
- 优先级：P0
|
||
- 前置条件：模板已审核通过并有历史任务。
|
||
- 步骤：
|
||
1. 删除或停用模板。
|
||
2. 发送页尝试选择该模板。
|
||
3. 使用已保存草稿或 scheduled 任务触发送。
|
||
4. 查询历史发送详情。
|
||
- 预期结果：
|
||
- 新发送不可选择已删除模板。
|
||
- 草稿或 scheduled 到点时校验失败，不入队。
|
||
- 历史发送详情仍展示原短信内容、模板名称或模板快照。
|
||
- 不影响历史计费和对账。
|
||
|
||
### TC-DELETE-005 删除引流信息字段
|
||
|
||
- 优先级：P0
|
||
- 前置条件：签名报备材料依赖某个引流信息字段。
|
||
- 步骤：
|
||
1. 运营端删除或停用引流字段。
|
||
2. 客户端编辑签名引流信息。
|
||
3. 生成或重新生成报备任务。
|
||
4. 使用该签名发送。
|
||
- 预期结果：
|
||
- 新签名资料不再要求已删除字段。
|
||
- 已存在报备材料保留历史值或标记字段已停用。
|
||
- 如通道仍要求该字段但客户资料缺失，报备任务无法通过或发送前校验失败。
|
||
- 失败原因明确指向缺少报备/引流资料。
|
||
|
||
### TC-DELETE-006 删除客户签名引流信息对报备和发送影响
|
||
|
||
- 优先级：P0
|
||
- 前置条件：签名已报备通过，且发送依赖引流信息。
|
||
- 步骤：
|
||
1. 客户端删除签名上的某项引流信息。
|
||
2. 查看签名报备状态。
|
||
3. 尝试使用该签名发送。
|
||
4. 运营端查看报备任务或报备记录。
|
||
- 预期结果：
|
||
- 删除关键引流信息后，签名报备状态应变为 waiting_material/pending 或标记需重新报备。
|
||
- 使用未重新报备通过的签名发送应被阻断或进入人工审核。
|
||
- 系统记录引流信息删除日志和报备状态变化记录。
|
||
|
||
### TC-REPORT-001 签名审核通过但未报备不能发送
|
||
|
||
- 优先级：P0
|
||
- 前置条件：签名 auditStatus=approved，reportStatus=waiting_material 或 pending。
|
||
- 步骤：
|
||
1. 客户端选择该签名和已审核模板。
|
||
2. 提交发送。
|
||
- 预期结果：
|
||
- 发送被阻断或进入人工审核，按第一版策略明确处理。
|
||
- 原因包含签名未完成通道报备。
|
||
- 不投递 Gateway SubmitCommand。
|
||
- 不扣费，或已冻结需释放。
|
||
|
||
### TC-REPORT-002 报备通过后允许发送
|
||
|
||
- 优先级：P0
|
||
- 前置条件：签名审核通过但报备未通过。
|
||
- 步骤：
|
||
1. 运营端导入报备成功回执。
|
||
2. 签名 reportStatus 变为 approved。
|
||
3. 客户端使用该签名发送。
|
||
4. 模拟 submit 和 receipt。
|
||
- 预期结果：
|
||
- 报备状态同步到签名详情和客户端列表。
|
||
- 发送可进入队列。
|
||
- 生成发送记录和计费流水。
|
||
|
||
### TC-REPORT-003 报备失败后阻断发送
|
||
|
||
- 优先级：P0
|
||
- 前置条件：签名已审核通过，报备任务导入失败回执。
|
||
- 步骤：
|
||
1. 确认签名 reportStatus=rejected。
|
||
2. 客户端使用该签名发送。
|
||
3. 运营端查看发送审核或风控记录。
|
||
- 预期结果：
|
||
- 发送被阻断，不入队。
|
||
- 客户端展示报备失败原因。
|
||
- 运营端可查询失败报备记录。
|
||
|
||
### TC-REPORT-004 报备状态从通过变为失败对 scheduled 任务的影响
|
||
|
||
- 优先级：P0
|
||
- 前置条件：签名 reportStatus=approved，存在未来执行的 scheduled 任务。
|
||
- 步骤：
|
||
1. 创建定时发送任务。
|
||
2. 到点前运营端将该签名通道报备状态改为 rejected 或 waiting_material。
|
||
3. 到点触发调度。
|
||
- 预期结果：
|
||
- 调度前重新校验报备状态。
|
||
- 报备状态不可用时任务不入队。
|
||
- 任务失败原因包含报备状态变化。
|
||
- 如已冻结费用，生成释放流水。
|
||
|
||
### TC-REPORT-005 多通道报备状态影响路由
|
||
|
||
- 优先级：P0
|
||
- 前置条件：通道 A 报备通过，通道 B 报备失败，通道组包含 A/B。
|
||
- 步骤：
|
||
1. 使用该签名发送，路由规则优先通道 A。
|
||
2. 停用通道 A 或模拟 A 不可用。
|
||
3. 系统尝试切换到通道 B。
|
||
- 预期结果：
|
||
- 通道 A 可用时正常发送。
|
||
- 切换备用通道前必须校验签名在备用通道的报备状态。
|
||
- 通道 B 报备失败时不能切换发送，应选择其他报备通过通道或失败并给出原因。
|
||
|
||
### TC-REPORT-006 引流信息字段变更触发重新报备
|
||
|
||
- 优先级：P1
|
||
- 前置条件：签名已在通道报备通过。
|
||
- 步骤：
|
||
1. 客户端修改签名引流信息中的关键字段。
|
||
2. 查看签名报备状态。
|
||
3. 运营端生成新的报备任务。
|
||
4. 新报备通过后再次发送。
|
||
- 预期结果：
|
||
- 修改关键引流信息后原报备状态失效或标记需重新报备。
|
||
- 重新报备前发送被阻断或进入人工审核。
|
||
- 新报备通过后恢复发送。
|
||
- 保留旧报备记录和新报备记录。
|
||
|
||
### TC-STATUS-001 已有历史任务不受配置删除错误覆盖
|
||
|
||
- 优先级：P0
|
||
- 前置条件：存在已完成发送任务，关联应用、签名、模板随后被删除或停用。
|
||
- 步骤：
|
||
1. 删除或停用应用、签名、模板。
|
||
2. 打开历史批量任务、发送详情、trace、对账。
|
||
- 预期结果：
|
||
- 历史任务仍可查询。
|
||
- 历史短信内容、手机号、计费条数、通道、回执、账务流水不丢失。
|
||
- trace 不因关联资源删除而报错。
|
||
- 对账结果不受配置删除影响。
|
||
|
||
### TC-STATUS-002 配置状态变化必须写入系统日志
|
||
|
||
- 优先级：P0
|
||
- 前置条件：准备应用、签名、模板、引流字段、通道、路由规则。
|
||
- 步骤：
|
||
1. 分别执行启用、停用、删除、恢复。
|
||
2. 对每次操作查询系统日志。
|
||
- 预期结果：
|
||
- 每次状态变化都有日志。
|
||
- 日志包含状态前后值。
|
||
- 日志能区分客户侧操作和运营侧操作。
|
||
- 日志 resourceId 可跳转或定位到原业务对象。
|
||
|
||
### TC-E2E-004 定时发送完整闭环
|
||
|
||
- 优先级：P0
|
||
- 步骤：
|
||
1. 企业认证通过。
|
||
2. 创建应用、签名、模板和报备材料。
|
||
3. 审核签名和模板，报备通过。
|
||
4. 充值账户。
|
||
5. 创建定时发送任务。
|
||
6. 到点触发送链路。
|
||
7. 模拟 submit accepted、receipt delivered、uplink。
|
||
8. 查询任务、发送详情、trace、账单流水、系统日志。
|
||
- 预期结果：
|
||
- 全链路状态流转完整。
|
||
- 发送和回执记录完整。
|
||
- 账务预估、冻结、扣费或释放逻辑正确。
|
||
- 系统日志覆盖认证、配置、审核、报备、发送、回执关键动作。
|
||
|
||
### TC-E2E-005 导入数据发送完整闭环
|
||
|
||
- 优先级：P0
|
||
- 步骤：
|
||
1. 使用多变量模板。
|
||
2. 上传 CSV，包含手机号和变量列。
|
||
3. 处理重复、非法、黑名单行。
|
||
4. 提交合法数据发送。
|
||
5. 模拟 submit 和 receipt。
|
||
6. 查询导入结果、批量任务、发送明细、trace、对账。
|
||
- 预期结果：
|
||
- 导入解析、变量映射、风控、计费、发送、回执、对账形成闭环。
|
||
- 被过滤或拒绝的数据有明确原因。
|
||
- 合法数据生成完整发送记录。
|
||
|
||
### TC-E2E-006 配置删除影响发送完整闭环
|
||
|
||
- 优先级：P0
|
||
- 步骤：
|
||
1. 创建并完成一条历史发送。
|
||
2. 创建一条未来定时发送。
|
||
3. 删除或停用应用、签名、模板、引流信息之一。
|
||
4. 尝试新建立即发送。
|
||
5. 等待定时任务到点。
|
||
6. 查询历史任务和日志。
|
||
- 预期结果：
|
||
- 新建发送被阻断。
|
||
- 定时任务到点重新校验并失败或取消。
|
||
- 历史发送可查询、可对账。
|
||
- 配置删除、发送阻断、定时任务失败均有日志。
|
||
|
||
### TC-DASHBOARD-001 客户端 Dashboard 今日发送数据准确
|
||
|
||
- 优先级：P0
|
||
- 前置条件：客户 A 当天存在 delivered 10 条、failed 3 条、unknown 2 条、timeout 1 条；客户 B 有任意发送数据。
|
||
- 步骤：
|
||
1. 使用客户 A 管理员登录客户端。
|
||
2. 打开客户端 Dashboard。
|
||
3. 查看今日发送量、成功量、失败量、未知量、成功率。
|
||
4. 点击今日发送量或成功率卡片跳转到发送明细。
|
||
5. 使用同样时间范围在发送明细中筛选核对。
|
||
- 预期结果：
|
||
- 今日发送量只统计客户 A 数据，不包含客户 B。
|
||
- 总量为 16，成功量为 10，失败量按 failed+timeout 口径为 4，unknown 为 2。
|
||
- 成功率口径明确，若按 delivered/total，应为 62.5%。
|
||
- 卡片跳转后的列表筛选条件与 Dashboard 统计口径一致。
|
||
|
||
### TC-DASHBOARD-002 客户端 Dashboard 余额和可发送额度准确
|
||
|
||
- 优先级：P0
|
||
- 前置条件：客户 A 账户余额 10000 分，套餐余量 200 条，授信额度 5000 分；存在冻结、扣费、退款、释放流水。
|
||
- 步骤：
|
||
1. 打开客户端 Dashboard。
|
||
2. 查看余额、套餐余量、授信额度、可发送额度。
|
||
3. 打开账单流水。
|
||
4. 按交易类型核对充值、冻结、扣费、退款、释放后的余额。
|
||
- 预期结果：
|
||
- Dashboard 余额与账户表和流水计算结果一致。
|
||
- 冻结金额不应被当作可用余额重复计算。
|
||
- 套餐余量和金额余额分别展示，口径不混淆。
|
||
- 跳转账单流水后可核对组成明细。
|
||
|
||
### TC-DASHBOARD-003 客户端 Dashboard 待处理事项准确
|
||
|
||
- 优先级：P1
|
||
- 前置条件：客户 A 有待审核签名 2 个、待审核模板 3 个、待报备签名 1 个、pending_review 发送任务 4 个。
|
||
- 步骤：
|
||
1. 打开客户端 Dashboard。
|
||
2. 查看待审核/待处理事项数量。
|
||
3. 分别点击进入签名、模板、发送任务页面。
|
||
- 预期结果：
|
||
- Dashboard 数量与对应列表筛选结果一致。
|
||
- 只展示客户 A 的事项。
|
||
- 点击跳转后自动带入对应状态筛选。
|
||
|
||
### TC-DASHBOARD-004 运营端 Dashboard 全平台核心指标准确
|
||
|
||
- 优先级：P0
|
||
- 前置条件：准备多个客户、多通道、多状态短信记录和账务流水。
|
||
- 步骤：
|
||
1. 运营管理员打开运营端 Dashboard。
|
||
2. 查看总客户数、活跃客户数、今日发送量、成功率、失败率、待审核数量、账务收入。
|
||
3. 分别在客户列表、短信记录、审核列表、账单流水中按相同时间范围核对。
|
||
- 预期结果：
|
||
- 运营端 Dashboard 统计全平台数据。
|
||
- 各指标与明细列表聚合一致。
|
||
- 时间范围切换后所有指标同步刷新。
|
||
- 待审核数量按企业认证、签名、模板、短信审核分类可追溯。
|
||
|
||
### TC-DASHBOARD-005 运营端 Dashboard 按客户筛选准确
|
||
|
||
- 优先级：P0
|
||
- 前置条件：客户 A、客户 B 均有发送、账务和审核数据。
|
||
- 步骤：
|
||
1. 运营端 Dashboard 选择客户 A。
|
||
2. 查看发送趋势、状态分布、账务汇总、待审核。
|
||
3. 切换到客户 B。
|
||
4. 点击指标进入明细页。
|
||
- 预期结果：
|
||
- 客户筛选生效，A/B 数据互不混入。
|
||
- 明细页继承客户筛选条件。
|
||
- 账务汇总与客户账单流水一致。
|
||
|
||
### TC-DASHBOARD-006 运营端通道健康和 CMPP 连接指标展示
|
||
|
||
- 优先级：P0
|
||
- 前置条件：通道 A online 且连接数 2/2，通道 B disconnected 且连接数 0/2，通道 C auth_failed。
|
||
- 步骤：
|
||
1. 打开运营端 Dashboard 和发送监控。
|
||
2. 查看通道健康度、在线连接数、断线通道数、认证失败通道数、重连次数。
|
||
3. 点击通道健康卡片进入通道监控详情。
|
||
- 预期结果：
|
||
- Dashboard 展示的在线连接总数等于各通道 currentConnections 之和。
|
||
- 异常通道数量按连接状态准确分类。
|
||
- 明细页与 Dashboard 指标一致。
|
||
- 点击异常通道可查看错误原因和最近状态变化时间。
|
||
|
||
### TC-DASHBOARD-007 Dashboard 趋势图时间边界准确
|
||
|
||
- 优先级：P1
|
||
- 前置条件：准备跨日、跨小时发送记录，含时区边界数据。
|
||
- 步骤：
|
||
1. 在客户端和运营端分别选择今日、近 7 天、近 30 天。
|
||
2. 查看发送趋势图和成功率趋势。
|
||
3. 与数据库或明细列表按时间范围聚合结果核对。
|
||
- 预期结果：
|
||
- 今日使用平台配置时区，不错算跨日数据。
|
||
- 近 7 天和近 30 天边界包含/排除规则明确。
|
||
- 趋势图每个点位与明细聚合一致。
|
||
|
||
### TC-BILLING-006 运营端人工充值闭环
|
||
|
||
- 优先级：P0
|
||
- 前置条件：客户 A 已创建账户，运营管理员具备充值权限。
|
||
- 步骤：
|
||
1. 运营端进入客户详情或充值记录页面。
|
||
2. 发起人工充值，填写金额、短信条数、支付方式、备注、操作人。
|
||
3. 保存后查看充值记录。
|
||
4. 客户端查看 Dashboard 余额和账单流水。
|
||
5. 运营端查看账户余额、账单流水和系统日志。
|
||
- 预期结果：
|
||
- 生成 RechargeOrder，状态为 paid 或人工充值完成状态。
|
||
- 账户余额和套餐余量同步增加。
|
||
- 生成 account_transaction，类型为 recharge，关联 recharge_order。
|
||
- 客户端余额、账单流水即时可见。
|
||
- 运营端充值记录、账单流水、系统日志三处可追溯。
|
||
|
||
### TC-BILLING-007 人工充值金额和短信条数只填其一
|
||
|
||
- 优先级：P1
|
||
- 前置条件：客户 A 账户存在。
|
||
- 步骤：
|
||
1. 运营端只填写充值金额，不填写短信条数。
|
||
2. 再发起一笔只填写短信条数，不填写充值金额。
|
||
3. 查看账户和流水。
|
||
- 预期结果：
|
||
- 系统按填写项分别增加余额或套餐余量。
|
||
- 未填写项按 0 处理，不产生脏数据。
|
||
- 流水金额和短信条数字段方向正确。
|
||
- 备注和操作人保留。
|
||
|
||
### TC-BILLING-008 人工充值撤销或冲正闭环
|
||
|
||
- 优先级：P0
|
||
- 前置条件：存在一笔人工充值，且客户尚未完全消费该充值额度。
|
||
- 步骤：
|
||
1. 运营端对人工充值发起撤销或冲正。
|
||
2. 填写冲正原因。
|
||
3. 查看账户余额、充值记录、账单流水、系统日志。
|
||
4. 客户端查看账单流水。
|
||
- 预期结果：
|
||
- 原充值记录状态变为 canceled/reversed，或生成一笔反向调整流水。
|
||
- 账户余额和套餐余量正确回退。
|
||
- 若余额已消费导致不能全额撤销，应提示不可撤销或只允许人工调整。
|
||
- 客户端和运营端均可看到冲正流水和原因。
|
||
- 系统日志记录冲正操作者和原因。
|
||
|
||
### TC-BILLING-009 人工充值权限和审批校验
|
||
|
||
- 优先级：P0
|
||
- 前置条件：存在运营管理员、运营审核员、无充值权限用户。
|
||
- 步骤：
|
||
1. 无充值权限用户访问人工充值入口。
|
||
2. 运营审核员尝试发起充值。
|
||
3. 运营管理员发起大额充值。
|
||
4. 若系统配置大额审批，执行审批通过或驳回。
|
||
- 预期结果：
|
||
- 无权限用户不能发起充值。
|
||
- 权限不足时返回明确错误并写入安全日志。
|
||
- 大额充值按审批规则进入 pending/approved/rejected。
|
||
- 审批通过后才更新账户余额，驳回不更新余额。
|
||
|
||
### TC-BILLING-010 人工充值后立即发送扣费
|
||
|
||
- 优先级：P0
|
||
- 前置条件：客户原余额不足，人工充值后余额足够。
|
||
- 步骤：
|
||
1. 客户端发送任务，确认余额不足被阻断。
|
||
2. 运营端进行人工充值。
|
||
3. 客户端重新提交同样发送任务。
|
||
4. 模拟 submit accepted 和 delivered。
|
||
5. 查询对账。
|
||
- 预期结果：
|
||
- 充值前发送失败且不扣费。
|
||
- 充值后发送可进入发送链路。
|
||
- 扣费流水与充值流水都可查询。
|
||
- reconciliation diff 为 0。
|
||
|
||
### TC-LOG-005 客户端系统日志展示范围
|
||
|
||
- 优先级：P0
|
||
- 前置条件：客户 A 和客户 B 均有登录、发送、导入、配置变更日志。
|
||
- 步骤：
|
||
1. 使用客户 A 管理员打开客户端系统日志。
|
||
2. 按动作、时间、操作者筛选。
|
||
3. 尝试通过 URL 或参数查询客户 B 日志。
|
||
- 预期结果：
|
||
- 客户端只展示客户 A 日志。
|
||
- 筛选条件准确生效。
|
||
- 日志字段包含时间、用户、动作、资源、结果、IP、User-Agent。
|
||
- 越权查询客户 B 日志失败。
|
||
|
||
### TC-LOG-006 客户端系统日志记录发送与导入
|
||
|
||
- 优先级：P0
|
||
- 前置条件：客户 A 可创建发送任务并导入号码文件。
|
||
- 步骤：
|
||
1. 客户端导入号码文件。
|
||
2. 创建立即发送任务。
|
||
3. 创建定时发送任务并取消。
|
||
4. 查看客户端系统日志。
|
||
- 预期结果：
|
||
- 导入日志记录文件名、行数、成功数、失败数。
|
||
- 发送日志记录任务编号、号码数、发送类型、结果。
|
||
- 取消定时任务记录任务编号和取消人。
|
||
- 日志中的资源 id 可定位到对应任务或导入批次。
|
||
|
||
### TC-LOG-007 运营端系统日志全平台查询
|
||
|
||
- 优先级：P0
|
||
- 前置条件：多个客户产生认证、审核、充值、通道、发送、报备日志。
|
||
- 步骤：
|
||
1. 运营管理员打开运营端系统日志。
|
||
2. 按客户、操作者、动作、资源类型、结果、时间查询。
|
||
3. 导出查询结果。
|
||
- 预期结果：
|
||
- 运营端可查询全平台日志。
|
||
- 客户筛选和动作筛选准确。
|
||
- 导出内容与当前筛选结果一致。
|
||
- 导出动作本身也写入系统日志。
|
||
|
||
### TC-LOG-008 运营端系统日志记录人工充值
|
||
|
||
- 优先级：P0
|
||
- 前置条件：运营管理员发起人工充值、冲正或调整。
|
||
- 步骤：
|
||
1. 执行人工充值。
|
||
2. 执行充值冲正或账户调整。
|
||
3. 在运营端系统日志中查询。
|
||
- 预期结果：
|
||
- 日志记录客户、金额、短信条数、订单号、流水号、操作者。
|
||
- 冲正日志记录原订单号、原因、前后余额摘要。
|
||
- 敏感字段按脱敏规则展示。
|
||
|
||
### TC-LOG-009 系统日志失败动作也必须记录
|
||
|
||
- 优先级：P0
|
||
- 前置条件：准备无权限用户、非法参数、余额不足、通道离线等失败场景。
|
||
- 步骤：
|
||
1. 触发无权限充值。
|
||
2. 触发余额不足发送。
|
||
3. 触发通道无在线连接发送。
|
||
4. 查询客户端和运营端系统日志。
|
||
- 预期结果：
|
||
- 失败动作同样记录日志。
|
||
- 日志 result/status 标识失败。
|
||
- 失败原因可读且与前端提示一致。
|
||
- 客户端只可见本客户失败日志，运营端可全平台查询。
|
||
|
||
### TC-CUSTOMER-001 运营端创建客户并初始化租户
|
||
|
||
- 优先级：P0
|
||
- 前置条件：运营管理员已登录。
|
||
- 步骤：
|
||
1. 运营端新建客户，填写客户名称、客户编码、联系人、手机号、邮箱、状态、备注。
|
||
2. 保存后打开客户详情。
|
||
3. 查看客户下应用、签名、模板、账户、认证资料、发送记录入口。
|
||
4. 使用该客户管理员账号登录客户端。
|
||
- 预期结果：
|
||
- 创建客户成功，同时生成或关联租户。
|
||
- 客户详情展示基础信息和业务入口。
|
||
- 客户管理员只能进入本客户租户上下文。
|
||
- 系统日志记录客户创建动作和操作者。
|
||
|
||
### TC-CUSTOMER-002 客户资料编辑影响展示但不破坏历史数据
|
||
|
||
- 优先级：P1
|
||
- 前置条件：客户已有应用、签名、模板和历史发送记录。
|
||
- 步骤：
|
||
1. 运营端修改客户名称、联系人、联系电话、备注。
|
||
2. 客户端刷新工作台和账号信息。
|
||
3. 运营端查看历史发送记录、账单流水、trace。
|
||
- 预期结果：
|
||
- 新客户资料在客户端和运营端同步展示。
|
||
- 历史发送记录、账单流水、trace 仍可查询。
|
||
- 历史记录中的 tenantId 不变化，必要时展示当前客户名称或历史快照。
|
||
- 系统日志记录修改前后关键字段。
|
||
|
||
### TC-CUSTOMER-003 客户停用阻断新发送
|
||
|
||
- 优先级：P0
|
||
- 前置条件：客户已认证且有可用应用、签名、模板、余额和 active 通道。
|
||
- 步骤：
|
||
1. 运营端将客户状态改为 disabled。
|
||
2. 客户端尝试创建立即发送任务。
|
||
3. 客户端尝试创建定时发送任务。
|
||
4. API 调用或 CMPP 接入尝试发送。
|
||
5. 查询系统日志和发送任务列表。
|
||
- 预期结果：
|
||
- 客户端、API、CMPP 接入的新发送均被阻断。
|
||
- 错误原因包含客户已停用。
|
||
- 不生成可发送状态任务，不入队，不扣费。
|
||
- 历史任务仍可查询。
|
||
- 系统日志记录客户停用和发送阻断。
|
||
|
||
### TC-CUSTOMER-004 客户停用对定时任务到点执行的影响
|
||
|
||
- 优先级：P0
|
||
- 前置条件：客户 active 时已创建未来定时发送任务。
|
||
- 步骤：
|
||
1. 创建 scheduled 任务。
|
||
2. 到点前运营端停用客户。
|
||
3. 等待或触发调度器执行。
|
||
4. 查询任务详情、账单流水和系统日志。
|
||
- 预期结果：
|
||
- 定时任务到点前重新校验客户状态。
|
||
- 客户停用时任务不入队，状态变为 rejected/canceled/failed。
|
||
- 如已冻结费用，生成 release 流水。
|
||
- 任务失败原因和系统日志均指向客户停用。
|
||
|
||
### TC-CUSTOMER-005 客户重新启用恢复发送能力
|
||
|
||
- 优先级：P0
|
||
- 前置条件：客户曾被停用，应用/签名/模板/报备/账户均可用。
|
||
- 步骤：
|
||
1. 运营端重新启用客户。
|
||
2. 客户端创建立即发送任务。
|
||
3. 模拟 submit accepted 和 delivered。
|
||
4. 查询任务、发送详情、账单流水。
|
||
- 预期结果：
|
||
- 客户状态变为 active。
|
||
- 新发送可进入风控、计费和发送链路。
|
||
- 发送记录和账务流水完整。
|
||
- 系统日志记录重新启用动作。
|
||
|
||
### TC-CUSTOMER-006 客户欠费或额度不足状态联动发送
|
||
|
||
- 优先级：P0
|
||
- 前置条件：客户余额、套餐余量、授信额度不足，或运营端标记欠费。
|
||
- 步骤：
|
||
1. 客户端创建发送任务。
|
||
2. API 调用发送。
|
||
3. 运营端查看客户账户、账单流水、发送失败记录。
|
||
- 预期结果：
|
||
- 发送前账户校验失败。
|
||
- 错误原因包含余额/额度/欠费。
|
||
- 不生成扣费流水，不投递 Gateway。
|
||
- 运营端客户详情可看到欠费或余额不足状态。
|
||
|
||
### TC-CUSTOMER-007 客户租户隔离和越权访问
|
||
|
||
- 优先级：P0
|
||
- 前置条件：存在客户 A 和客户 B，各有应用、签名、模板、任务、账单流水。
|
||
- 步骤：
|
||
1. 使用客户 A 用户登录客户端。
|
||
2. 尝试通过 URL、筛选条件或 API 参数访问客户 B 的资源 id。
|
||
3. 运营端使用客户维度查询两边数据。
|
||
- 预期结果：
|
||
- 客户 A 无法访问客户 B 的任何资源。
|
||
- 返回无权限或无数据，不泄露客户 B 业务信息。
|
||
- 运营端按客户过滤时数据准确。
|
||
- 越权访问失败记录进入安全或系统日志。
|
||
|
||
### TC-CUSTOMER-008 客户删除或归档的业务影响
|
||
|
||
- 优先级：P0
|
||
- 前置条件：客户有历史任务、账单流水、应用、签名、模板和 scheduled 任务。
|
||
- 步骤：
|
||
1. 运营端删除、归档或停用客户。
|
||
2. 客户端尝试登录和发送。
|
||
3. 到达 scheduled 任务执行时间。
|
||
4. 运营端查询历史任务、账单流水、trace。
|
||
- 预期结果：
|
||
- 如系统不允许硬删除，应提示存在业务数据并要求停用/归档。
|
||
- 被归档/停用客户不能新建发送。
|
||
- 未执行定时任务不应继续发送。
|
||
- 历史任务、账单、trace 必须保留可查。
|
||
- 系统日志记录删除失败、归档或停用动作。
|
||
|
||
### TC-CUSTOMER-009 客户详情展示业务总览准确
|
||
|
||
- 优先级：P0
|
||
- 前置条件：客户 A 下存在应用 3 个、签名 4 个、模板 5 个、通道绑定 2 个、今日发送 100 条、余额和套餐余量。
|
||
- 步骤：
|
||
1. 运营端打开客户详情。
|
||
2. 查看客户业务总览：应用数、签名数、模板数、今日发送量、成功率、余额、套餐余量、待审核数。
|
||
3. 点击每个指标进入对应明细列表。
|
||
- 预期结果：
|
||
- 客户详情总览只统计客户 A。
|
||
- 指标与对应明细列表聚合一致。
|
||
- 点击跳转时自动带入客户筛选。
|
||
- 客户停用、欠费、未认证等状态在总览中有清晰标识。
|
||
|
||
### TC-CUSTOMER-010 客户维度通道绑定和连接状态展示
|
||
|
||
- 优先级：P0
|
||
- 前置条件：客户 A 绑定通道组 G1，G1 包含通道 A/B；通道 A online，通道 B disconnected。
|
||
- 步骤：
|
||
1. 运营端打开客户详情的通道或发送配置区域。
|
||
2. 查看客户绑定通道组、主备通道、通道业务状态、CMPP 连接状态。
|
||
3. 创建客户 A 发送任务。
|
||
4. 查看 trace 中实际使用通道。
|
||
- 预期结果：
|
||
- 客户详情展示客户可用通道组和各通道连接状态。
|
||
- online/disconnected 状态与通道监控页一致。
|
||
- 发送路由选择 online 且报备通过的通道。
|
||
- trace 中 channelId 与客户通道配置一致。
|
||
|
||
### TC-CUSTOMER-011 客户维度通道连接数量展示
|
||
|
||
- 优先级：P0
|
||
- 前置条件：客户 A 绑定通道 A，配置连接数 2；当前 Gateway 建立 2 条连接。客户 B 绑定通道 B，配置连接数 3，当前在线 1 条。
|
||
- 步骤：
|
||
1. 运营端打开客户列表。
|
||
2. 查看客户 A/B 的通道连接摘要。
|
||
3. 打开客户详情查看连接数明细。
|
||
4. 与通道监控页核对。
|
||
- 预期结果：
|
||
- 客户列表展示连接摘要，例如 `2/2 online`、`1/3 degraded`。
|
||
- 客户详情展示每个绑定通道的配置连接数、当前在线连接数、异常连接数。
|
||
- 客户维度连接数与通道监控按客户/通道过滤结果一致。
|
||
- 异常连接有状态和最近错误原因。
|
||
|
||
### TC-CUSTOMER-012 客户通道连接数量调整影响后续发送
|
||
|
||
- 优先级：P1
|
||
- 前置条件：客户 A 通道 A 当前配置连接数为 1，发送正常。
|
||
- 步骤：
|
||
1. 运营端将客户 A 在通道 A 上的连接数调整为 2。
|
||
2. Gateway 重新加载配置或重启连接。
|
||
3. 查看客户详情和通道监控连接数。
|
||
4. 提交多条发送任务。
|
||
- 预期结果：
|
||
- 配置连接数展示为 2。
|
||
- Gateway 连接数最终达到 2/2 online。
|
||
- 发送提交能力或窗口容量按新连接配置生效。
|
||
- 系统日志记录连接数配置变更。
|
||
|
||
### TC-CUSTOMER-013 客户通道连接数量超限校验
|
||
|
||
- 优先级：P1
|
||
- 前置条件：通道 A 平台最大连接数为 5，已分配客户 A 3 条、客户 B 2 条。
|
||
- 步骤：
|
||
1. 尝试将客户 C 在通道 A 上配置 1 条连接。
|
||
2. 尝试将客户 A 连接数从 3 调整为 4。
|
||
3. 查看错误提示和系统日志。
|
||
- 预期结果：
|
||
- 超过通道最大连接数时保存失败。
|
||
- 错误提示包含通道最大连接数和当前已分配连接数。
|
||
- 不影响已有连接。
|
||
- 失败操作写入系统日志。
|
||
|
||
### TC-CMPP-STATUS-001 通道初始连接状态展示
|
||
|
||
- 优先级：P0
|
||
- 前置条件：运营端已创建 CMPP 通道，Gateway 未启动或未连接。
|
||
- 步骤：
|
||
1. 打开运营端通道管理和发送监控。
|
||
2. 查看通道连接状态、最近心跳时间、重连次数、错误信息。
|
||
3. 调用健康检查或监控接口。
|
||
- 预期结果：
|
||
- 通道业务状态 active 与 CMPP 连接状态分开展示。
|
||
- Gateway 未连接时连接状态显示 disconnected/unknown。
|
||
- 最近心跳为空或过期。
|
||
- 不误显示为可提交状态。
|
||
|
||
### TC-CMPP-STATUS-002 CMPP 登录成功后连接状态变为在线
|
||
|
||
- 优先级：P0
|
||
- 前置条件：模拟 SMSC 可用，通道账号密码正确。
|
||
- 步骤：
|
||
1. 启动 Gateway。
|
||
2. Gateway 连接模拟 SMSC 并完成 CMPP connect/login。
|
||
3. 运营端刷新通道详情和监控。
|
||
4. 创建发送任务并提交一条短信。
|
||
- 预期结果：
|
||
- 连接状态变为 connected/online。
|
||
- 展示连接建立时间、最近 active test 时间、窗口大小或可用窗口。
|
||
- 发送任务可被路由到该通道。
|
||
- submit accepted 后通道健康指标更新。
|
||
|
||
### TC-CMPP-STATUS-003 CMPP 登录失败展示认证错误
|
||
|
||
- 优先级：P0
|
||
- 前置条件：通道账号、密码或企业代码配置错误。
|
||
- 步骤：
|
||
1. 启动 Gateway 连接模拟 SMSC。
|
||
2. 模拟 SMSC 返回登录失败。
|
||
3. 运营端查看通道状态和错误信息。
|
||
4. 创建发送任务。
|
||
- 预期结果：
|
||
- 连接状态显示 auth_failed/login_failed。
|
||
- 错误信息包含认证失败原因或错误码。
|
||
- 发送路由不应选择该通道，除非无备用通道时任务失败并展示原因。
|
||
- 系统日志或告警记录登录失败。
|
||
|
||
### TC-CMPP-STATUS-004 Active Test 心跳超时变更连接状态
|
||
|
||
- 优先级：P0
|
||
- 前置条件：Gateway 已连接模拟 SMSC。
|
||
- 步骤：
|
||
1. 模拟 SMSC 停止响应 active test。
|
||
2. 等待心跳超时。
|
||
3. 查看通道连接状态。
|
||
4. 提交发送任务。
|
||
- 预期结果：
|
||
- 通道连接状态从 online 变为 heartbeat_timeout/disconnected。
|
||
- 最近心跳时间不再刷新。
|
||
- Gateway 进入重连流程。
|
||
- 新发送不应继续提交到该失联连接，应走备用通道或失败排队。
|
||
|
||
### TC-CMPP-STATUS-005 断线重连成功后恢复发送
|
||
|
||
- 优先级：P0
|
||
- 前置条件：通道在线，存在备用通道或队列可暂存。
|
||
- 步骤：
|
||
1. 模拟 SMSC 断开 TCP 连接。
|
||
2. 观察 Gateway 重连次数和连接状态。
|
||
3. 恢复模拟 SMSC。
|
||
4. 提交新发送任务。
|
||
- 预期结果：
|
||
- 断线后状态变为 disconnected/reconnecting。
|
||
- 重连次数增加，日志记录断线原因。
|
||
- 重连成功后状态回到 online。
|
||
- 新发送可正常 submit。
|
||
- 断线期间未确认的消息有明确重试、失败或待补偿状态。
|
||
|
||
### TC-CMPP-STATUS-006 通道连接离线时路由到备用通道
|
||
|
||
- 优先级：P0
|
||
- 前置条件：通道组包含主通道 A 和备用通道 B，A active 但连接离线，B active 且 online，签名在 B 报备通过。
|
||
- 步骤：
|
||
1. 确认 A 业务状态 active、连接状态 disconnected。
|
||
2. 确认 B 业务状态 active、连接状态 online。
|
||
3. 创建发送任务。
|
||
4. 查询 submit record 和 trace。
|
||
- 预期结果：
|
||
- 路由跳过连接离线的 A。
|
||
- 选择 B 提交。
|
||
- trace 显示实际 channelId 为 B。
|
||
- 通道健康指标记录 A 不可用和 B 提交成功。
|
||
|
||
### TC-CMPP-STATUS-007 无在线通道时发送任务失败或等待
|
||
|
||
- 优先级：P0
|
||
- 前置条件：路由范围内所有通道连接状态均 disconnected/auth_failed/heartbeat_timeout。
|
||
- 步骤：
|
||
1. 创建发送任务。
|
||
2. 触发送 worker。
|
||
3. 查看任务状态、发送明细、系统日志。
|
||
- 预期结果：
|
||
- 系统不向离线连接 submit。
|
||
- 按设计进入 delayed/retry、failed 或 pending_channel 状态。
|
||
- 客户端和运营端展示“无可用在线通道”原因。
|
||
- 不产生 submit accepted 记录，不错误扣费。
|
||
|
||
### TC-CMPP-STATUS-008 连接状态与通道启停状态组合
|
||
|
||
- 优先级：P1
|
||
- 前置条件：通道连接 online。
|
||
- 步骤：
|
||
1. 运营端将通道业务状态改为 disabled。
|
||
2. 查看连接状态是否仍可展示。
|
||
3. 创建发送任务。
|
||
4. 再将通道启用。
|
||
- 预期结果：
|
||
- disabled 通道即使连接 online，也不可被路由选中。
|
||
- 连接状态可继续用于运维观察，但发送可用性显示为不可用。
|
||
- 启用后如连接仍 online，可恢复路由；如连接已断开，需要等待重连。
|
||
- 系统日志记录启停操作。
|
||
|
||
### TC-CMPP-STATUS-009 慢响应导致窗口占满和状态告警
|
||
|
||
- 优先级：P1
|
||
- 前置条件：模拟 SMSC 可配置慢 submit resp，Gateway 有滑动窗口限制。
|
||
- 步骤：
|
||
1. 配置模拟 SMSC 延迟 submit resp。
|
||
2. 连续提交多条短信直到窗口占满。
|
||
3. 查看通道监控和队列积压。
|
||
4. 恢复 SMSC 正常响应。
|
||
- 预期结果：
|
||
- 通道状态展示窗口占用、慢响应或拥塞指标。
|
||
- 新消息排队等待，不丢失。
|
||
- 恢复后积压逐步下降。
|
||
- 超时消息按 submit timeout 处理并可追踪。
|
||
|
||
### TC-CMPP-STATUS-010 连接状态变化写入日志和监控
|
||
|
||
- 优先级：P0
|
||
- 前置条件：通道经历 online、disconnected、reconnecting、online 状态变化。
|
||
- 步骤：
|
||
1. 触发连接成功、断线、重连成功。
|
||
2. 查询通道健康指标。
|
||
3. 查询系统日志或运维日志。
|
||
- 预期结果：
|
||
- 每次连接状态变化都有时间戳。
|
||
- 健康指标记录重连次数、连接可用性、submit 成功/失败。
|
||
- 日志包含 channelId、channelCode、错误原因、恢复时间。
|
||
- 运营端监控可按通道查看状态历史。
|
||
|
||
### TC-CMPP-STATUS-011 通道连接数量配置展示
|
||
|
||
- 优先级：P0
|
||
- 前置条件：通道 A 配置最大连接数 4，期望连接数 2，窗口大小 16；Gateway 当前在线连接 2 条。
|
||
- 步骤：
|
||
1. 运营端打开通道详情。
|
||
2. 查看最大连接数、期望连接数、当前在线连接数、窗口大小、连接列表。
|
||
3. 打开发送监控通道详情。
|
||
- 预期结果：
|
||
- 通道详情展示 maxConnections、desiredConnections、currentConnections。
|
||
- 连接列表展示每条连接的连接 id、状态、登录时间、最近心跳、sequence 范围或当前 sequence。
|
||
- 发送监控与通道详情连接数一致。
|
||
|
||
### TC-CMPP-STATUS-012 增加通道连接数后 Gateway 建立新连接
|
||
|
||
- 优先级：P0
|
||
- 前置条件：通道 A 当前 desiredConnections=1，currentConnections=1。
|
||
- 步骤：
|
||
1. 运营端将 desiredConnections 调整为 3。
|
||
2. Gateway 监听配置变更或重载配置。
|
||
3. 观察连接状态变化。
|
||
4. 提交批量发送任务。
|
||
- 预期结果：
|
||
- Gateway 新建连接直到 currentConnections=3。
|
||
- 三条连接均完成 CMPP 登录和 active test。
|
||
- 发送任务可按连接/窗口分摊提交。
|
||
- 通道监控展示连接数变更历史。
|
||
- 系统日志记录连接数量调整。
|
||
|
||
### TC-CMPP-STATUS-013 减少通道连接数后优雅关闭多余连接
|
||
|
||
- 优先级：P0
|
||
- 前置条件：通道 A desiredConnections=3，currentConnections=3，队列中有待发送任务。
|
||
- 步骤：
|
||
1. 运营端将 desiredConnections 调整为 1。
|
||
2. Gateway 执行配置重载。
|
||
3. 观察连接关闭和发送任务处理。
|
||
- 预期结果：
|
||
- Gateway 不强制中断正在等待 submit resp 的连接，或按设计安全失败并重试。
|
||
- 最终 currentConnections=1。
|
||
- 关闭的连接有 terminate/close 日志。
|
||
- 发送任务不丢失、不重复提交。
|
||
|
||
### TC-CMPP-STATUS-014 单连接异常时连接数量降级展示
|
||
|
||
- 优先级：P0
|
||
- 前置条件：通道 A desiredConnections=3，currentConnections=3。
|
||
- 步骤：
|
||
1. 模拟其中一条连接断开。
|
||
2. 查看通道详情和 Dashboard。
|
||
3. Gateway 自动重连该连接。
|
||
- 预期结果：
|
||
- 通道状态展示 degraded 或 partial_online。
|
||
- 连接数量展示为 2/3 online。
|
||
- Dashboard 异常连接数增加 1。
|
||
- 重连成功后恢复 3/3 online。
|
||
|
||
### TC-CMPP-STATUS-015 连接数量为 0 的通道不可发送
|
||
|
||
- 优先级：P0
|
||
- 前置条件：通道业务状态 active，但 desiredConnections=0 或 currentConnections=0。
|
||
- 步骤：
|
||
1. 查看通道详情和客户通道配置。
|
||
2. 创建发送任务。
|
||
3. 查看路由结果和错误提示。
|
||
- 预期结果：
|
||
- 系统明确展示该通道无在线连接。
|
||
- 路由不选择 currentConnections=0 的通道。
|
||
- 无备用通道时任务失败或等待，原因包含无在线连接。
|
||
- 不产生 submit accepted 和错误扣费。
|
||
|
||
### TC-CMPP-STATUS-016 连接数量指标与 submit 能力联动
|
||
|
||
- 优先级：P1
|
||
- 前置条件：通道 A 单连接限速 100 条/秒，连接数可配置。
|
||
- 步骤：
|
||
1. 连接数为 1 时运行性能 smoke。
|
||
2. 连接数调整为 2 并稳定 online。
|
||
3. 再次运行性能 smoke。
|
||
4. 查看 Dashboard 和通道监控。
|
||
- 预期结果：
|
||
- 平台展示理论提交能力随在线连接数变化。
|
||
- 实际 submit TPS 不超过通道配置和连接数限制。
|
||
- 连接数变化不会导致重复发送。
|
||
|
||
## 15. 测试实施步骤
|
||
|
||
系统功能测试建议分 8 步执行。第一步先做测试基线和数据准备，不直接开始点页面；原因是后续所有闭环都依赖客户、认证、应用、签名、模板、通道、账户和模拟 Gateway 的一致初始状态。
|
||
|
||
### 第一步：准备测试环境和基线数据
|
||
|
||
- 目标：让后续所有测试在同一套可复现数据上执行。
|
||
- 执行内容：
|
||
1. 启动或确认 PostgreSQL、Redis、MinIO、API、前端、Gateway、模拟 SMSC。
|
||
2. 初始化客户 A、客户 B、运营管理员、运营审核员、客户管理员、客户普通用户。
|
||
3. 初始化 active/disabled 客户、未认证/待审核/已认证/驳回企业认证资料。
|
||
4. 初始化可用应用、停用应用、待删除应用。
|
||
5. 初始化签名、引流信息、模板、多变量模板、通道、通道组、路由规则。
|
||
6. 初始化账户余额、套餐余量、欠费/不足余额场景。
|
||
7. 准备 CSV/TXT/GBK/大文件/非法字符/黑名单号码测试文件。
|
||
8. 确认 Gateway 模拟器可切换 online、auth_failed、heartbeat_timeout、disconnected、slow_response。
|
||
- 产出物：
|
||
- 测试账号清单。
|
||
- 测试客户和租户 id。
|
||
- 测试应用/签名/模板/通道 id。
|
||
- 测试文件目录。
|
||
- 环境健康检查截图或日志。
|
||
|
||
### 第二步：执行静态配置和权限基础测试
|
||
|
||
- 覆盖范围：
|
||
- 客户创建、编辑、启停、租户隔离。
|
||
- 登录、用户权限、客户越权访问。
|
||
- 应用、签名、模板、引流字段、通道、路由规则的基础 CRUD。
|
||
- 通过标准：
|
||
- 数据隔离正确。
|
||
- 启停/删除状态能影响后续发送。
|
||
- 系统日志记录所有关键配置变更。
|
||
|
||
### 第三步：执行认证、审核、报备闭环测试
|
||
|
||
- 覆盖范围：
|
||
- 企业认证提交、审核通过、驳回重提、企业停用。
|
||
- 签名审核、模板审核、短信审核。
|
||
- 签名引流信息和通道报备状态变更。
|
||
- 通过标准：
|
||
- 审核状态在客户端和运营端一致。
|
||
- 报备未通过或失效时发送被阻断。
|
||
- 审核记录、报备记录、系统日志三类证据完整。
|
||
|
||
### 第四步：执行发送前校验测试
|
||
|
||
- 覆盖范围：
|
||
- 多变量模板、变量缺失/多传/超长。
|
||
- 导入文件解析、重复、非法、黑名单。
|
||
- 非法字符、敏感词、内容展示和计费预估。
|
||
- 风控规则和账户余额校验。
|
||
- 通过标准：
|
||
- 所有阻断场景都不入队、不扣费，原因可读。
|
||
- 所有允许场景的计费预估与最终内容一致。
|
||
- 风控命中记录包含阈值、实际值、动作和原因。
|
||
|
||
### 第五步：执行发送链路闭环测试
|
||
|
||
- 覆盖范围：
|
||
- 立即发送。
|
||
- 定时发送创建、查看、取消、到点执行。
|
||
- 导入数据发送。
|
||
- submit result、receipt、uplink、72 小时超时。
|
||
- 通过标准：
|
||
- 批量任务、手机号记录、提交记录、回执记录、上行记录完整。
|
||
- 任务进度统计准确。
|
||
- trace 能串起 messageId、submitId、sequenceId、gatewayMessageId。
|
||
|
||
### 第六步：执行计费和对账测试
|
||
|
||
- 覆盖范围：
|
||
- 70/67 计费。
|
||
- 预估、冻结、扣费、释放、退款。
|
||
- 失败退款、超时退款。
|
||
- 账单流水和 reconciliation。
|
||
- 通过标准：
|
||
- 每条短信记录可追溯到账务流水。
|
||
- 成功、失败、超时的金额方向正确。
|
||
- 对账 diff 符合预期。
|
||
|
||
### 第七步：执行 CMPP 连接状态和通道路由测试
|
||
|
||
- 覆盖范围：
|
||
- online、auth_failed、heartbeat_timeout、disconnected、reconnecting、slow_response。
|
||
- 主备通道路由。
|
||
- 无在线通道。
|
||
- 连接状态和业务启停状态组合。
|
||
- 通过标准：
|
||
- 离线或认证失败通道不被错误提交。
|
||
- 可用备用通道能接管。
|
||
- 连接状态变化有监控、健康指标和日志。
|
||
|
||
### 第八步：执行回归验证和报告归档
|
||
|
||
- 覆盖范围：
|
||
- 自动化测试命令。
|
||
- 前端 smoke。
|
||
- 性能 smoke。
|
||
- 缺陷复测。
|
||
- 建议执行命令：
|
||
```bash
|
||
npm run spike:contracts
|
||
npm run test:api
|
||
npm run test:gateway
|
||
npm run verify:phase8
|
||
```
|
||
- 产出物：
|
||
- 测试执行记录。
|
||
- 缺陷列表和复测结果。
|
||
- 性能 smoke 结果。
|
||
- 未覆盖项和延期说明。
|
||
|
||
## 16. 回归执行建议
|
||
|
||
每次阶段回归至少执行：
|
||
|
||
```bash
|
||
npm run spike:contracts
|
||
npm run test:api
|
||
npm run test:gateway
|
||
npm run verify:phase8
|
||
```
|
||
|
||
若测试环境具备 PostgreSQL、Redis、MinIO，再补充执行 E2E smoke 和真实 API HTTP 测试。
|