diff --git a/docs/system-functional-test-cases.md b/docs/system-functional-test-cases.md index 8358fdc..8a05a52 100644 --- a/docs/system-functional-test-cases.md +++ b/docs/system-functional-test-cases.md @@ -40,6 +40,7 @@ | 号码导入闭环 | 文件上传、解析、去重、非法号码、黑名单、导入结果展示、生成任务、生成手机号记录。 | | 发送闭环 | 立即发送、定时发送、到点触发、入队、submit、回执、上行、任务进度、发送详情、trace、对账。 | | CMPP 连接闭环 | 通道连接状态、登录认证、active test、断线重连、连接异常对路由/发送影响、状态监控和日志告警。 | +| Dashboard 闭环 | 客户端/运营端指标口径、数据范围、时间筛选、状态统计、账务统计、通道连接指标和明细跳转一致。 | | 内容校验闭环 | 非法字符展示、敏感词、控制字符、内容清洗或拒绝、计费不被非法字符干扰、错误原因可见。 | | 计费闭环 | 预估、余额校验、冻结、扣费、释放、退款、短信计费记录、账单流水、对账。 | | 系统日志闭环 | 登录、创建、修改、删除、审核、导入导出、密钥重置、发送、报备、账务动作均可查询和定位操作者。 | @@ -1396,6 +1397,254 @@ - 历史发送可查询、可对账。 - 配置删除、发送阻断、定时任务失败均有日志。 +### 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 @@ -1516,6 +1765,79 @@ - 历史任务、账单、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 @@ -1664,6 +1986,91 @@ - 日志包含 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 的一致初始状态。