release: prepare RealeseV2.3
This commit is contained in:
hectorzhao
@@ -1405,7 +1405,7 @@
|
||||
1. 让同一条 `SubmitCommand` 连续处理失败，达到 Gateway 配置的异常转存阈值。
|
||||
2. 检查 Redis PEL 中该消息是否被 ack，不再无限 pending。
|
||||
3. 检查 NestJS 是否在真实数据库写入一条 `GatewaySubmitDeadLetter`，保存失败原因、尝试次数和原始命令载荷。
|
||||
4. 从运营端“Gateway提交异常”页面查询异常列表并打开脱敏详情。
|
||||
4. 从运营端“网关异常”的“提交异常”Tab查询异常列表并打开脱敏详情。
|
||||
5. 完成风险确认、原因和状态校验后，将该异常命令重新写回 `gateway.submit.commands`。
|
||||
- 预期结果：
|
||||
- 达到阈值后，Gateway 会把该消息转存为提交异常，而不是永久卡在 PEL。
|
||||
@@ -3416,7 +3416,7 @@ npm run verify:phase8
|
||||
| TC-ADMIN-018 | 企业应用列表展示 CMPP 连接数，打开连接详情，删除连接，复制 CMPP 参数。 | 连接数来自连接状态 API；详情含 connectionId/status/heartbeat/window/lastSubmitAt；删除连接调用真实接口；复制文本与 API 返回一致。 |
|
||||
| TC-ADMIN-019 | 打开通道连接日志，按事件类型和时间查看。 | 日志包含 connect、active_test、disconnect、reconnect、auth_failed、slow_response；按时间倒序；可定位 channelId/connectionId。 |
|
||||
| TC-ADMIN-020 | 企业黑名单、全局黑名单、敏感词分别执行搜索、新增、停用、删除。 | 企业黑名单必须绑定短信应用且按应用生效；搜索由 API 处理；停用/删除后发送前风控只使用 active 数据；删除不影响历史命中记录；所有动作写日志。 |
|
||||
| TC-ADMIN-021 | 创建待审核企业认证、签名、模板、短信审核任务，检查铃铛总数和分类数。 | 总数等于分类汇总；点击分类跳转并带入筛选；审核完成后数量刷新；新增待办触发站内提醒或浏览器通知。 |
|
||||
| TC-ADMIN-021 | 创建待审核企业认证、签名、模板、短信审核任务，检查铃铛总数和分类数，并观察首次加载、30 秒轮询、窗口重新获得焦点及审核完成后的网络请求。 | 总数等于分类汇总；点击分类跳转并带入筛选；审核完成后数量刷新；新增待办触发站内提醒或浏览器通知；所有全局角标刷新只请求独立待审核数量接口，不请求完整运营看板统计。 |
|
||||
| TC-ADMIN-022 | 运营日志按客户、操作者、动作、资源、时间搜索，查看长详情。 | 后端分页和搜索准确；详情不截断；可查到通道复制、启停、删除、连接状态变化、安全控制变更、充值等日志。 |
|
||||
| TC-ADMIN-023 | 准备多个企业产生不同的当日真实消费金额后打开企业列表。 | API 结果按 `todaySpendCents` 降序；相同金额按企业名称和 id 稳定排序；金额来自 PostgreSQL 当日短信记录聚合。 |
|
||||
| TC-ADMIN-024 | 准备多个企业应用产生不同的当日真实发送数量后打开企业应用列表。 | API 结果按 `sentToday` 降序；相同数量按应用名称和 id 稳定排序；数量来自 PostgreSQL 当日短信记录聚合。 |
|
||||
@@ -3625,7 +3625,7 @@ npm run verify:phase8
|
||||
|
||||
| 用例编号 | 操作 | 预期结果 |
|
||||
| --- | --- | --- |
|
||||
| TC-GW-SUBMIT-EXCEPTION-001 | 制造一条超过 Gateway 最大处理次数的真实 `SubmitCommand`，打开运营端“Gateway提交异常”，按状态、应用、通道和关键字筛选并查看详情。 | 记录写入 PostgreSQL，页面汇总、分页和详情来自 NestJS API；手机号脱敏，命令中的密码、密钥和原始 payload 不返回浏览器，页面不使用“死信”作为业务名称。 |
|
||||
| TC-GW-SUBMIT-EXCEPTION-001 | 制造一条超过 Gateway 最大处理次数的真实 `SubmitCommand`，打开运营端“网关异常”的“提交异常”Tab，按状态、应用、通道和关键字筛选并查看详情。 | 记录写入 PostgreSQL，页面汇总、分页和详情来自 NestJS API；手机号脱敏，命令中的密码、密钥和原始 payload 不返回浏览器，页面不使用“死信”作为业务名称。 |
|
||||
| TC-GW-SUBMIT-EXCEPTION-002 | 对短信仍处于 pending/failed、通道 active 且 connected 的异常记录，输入 5～500 字原因，勾选“已确认上游未受理”并重新入队。 | 近期认证通过后服务端原子抢占记录、真实写入 Redis Stream；记录变为 requeued，人工次数、操作人、原因、Stream ID 和时间完整留痕，收到 SubmitResult 后变为 resolved。 |
|
||||
| TC-GW-SUBMIT-EXCEPTION-003 | 不勾选确认、原因过短、重复点击同一记录，或分别把短信置为 accepted/submitted/delivered/unknown、把通道置为停用/断开、人工重试达到 3 次后尝试重新入队。 | API 拒绝危险或重复操作，不产生额外 Stream 命令；页面显示可读原因，操作日志不伪造成功。 |
|
||||
| TC-GW-RATE-001 | 给通道 A 配置 10 TPS，连续投递 20 条；通道 B 同时配置 20 TPS 并投递，另让提交命令携带高于通道配置的数值。 | Gateway A 实际提交节奏不超过 10 TPS，B 独立按自身额度执行；消息值不能放大 A 的权威上限，同一通道跨通道组共享额度。 |
|
||||
@@ -3666,6 +3666,7 @@ npm run verify:phase8
|
||||
| TC-HTTP-WEBHOOK-002 | 回调依次返回 500、429、408、400、302 和 200，并模拟超时。 | 500/429/408/网络错误按既定退避重试，400 和重定向终结，2xx 成功；每次尝试、状态码、耗时和截断响应写 PostgreSQL，可授权手工重投。 |
|
||||
| TC-HTTP-WEBHOOK-003 | 保存指向 localhost、RFC1918、链路本地、共享地址、云元数据 IP、会解析到私网的域名和发生 DNS 重绑定的 URL。 | 保存或投递前被 SSRF 校验拒绝；不跟随重定向；生产 HTTPS 约束开启时 HTTP URL 被拒绝。 |
|
||||
| TC-HTTP-CLIENT-001 | 客户端打开“接口对接”五个页签，切换应用、创建凭据、配置回调、查看文档与日志；API 断开后重试。 | 所有状态来自真实 API/PostgreSQL/Redis；应用卡片显示 HTTP 状态；API 失败展示错误，不使用 localStorage 或前端静态数据伪造成功。 |
|
||||
| TC-HTTP-PUBLIC-ORIGIN-001 | 将管理页面部署在 `https://sms.lisglo.com`，设置 `HTTP_API_PUBLIC_ORIGIN=https://api.lisglo.com`，分别在运营端参数弹窗和客户端接口对接页查看并复制参数。 | 页面展示、复制内容和 Swagger 链接均使用 `https://api.lisglo.com`；灰云域名的四个开放接口及文档可访问，admin/client 管理接口和前端页面返回 404；不回退为管理页面域名。 |
|
||||
|
||||
### 17.15 手工验收瑕疵回归
|
||||
|
||||
@@ -3915,7 +3916,7 @@ npm run verify:phase8
|
||||
| TC-CHANNEL-RECONNECT-005 | 修改网关地址、账号、连接数、窗口或心跳参数 | 保存后发送连接控制请求；停用/启用仍正确断开/连接 |
|
||||
| TC-SMS-RECORD-006 | 首次进入短信记录或点击重置 | 日期默认覆盖北京时间昨天和今天，并以该范围请求真实后端 |
|
||||
| TC-DOWNSTREAM-UI-007 | 查看包含多次投递的下游投递详情 | 每次投递按纵向时间线展示中文状态、时间、连接和ACK证据，窄屏无需横向滚动 |
|
||||
| TC-GATEWAY-UI-008 | 查看Gateway提交异常列表 | 标题、说明、总数、表格和分页层次清晰，不紧贴容器边框 |
|
||||
| TC-GATEWAY-UI-008 | 查看“网关异常”的“提交异常”Tab | 标题、说明、总数、表格和分页层次清晰，不紧贴容器边框 |
|
||||
| TC-REPORT-SCOPE-009 | 检查本轮报表变更范围 | T-4未知转失败未实现，日报未知口径和历史数据保持不变 |
|
||||
|
||||
## 2026-07-26 通道补发归因与发送详情用例
|
||||
@@ -4387,3 +4388,14 @@ npm run verify:phase8
|
||||
| TC-RECEIPT-FRAGMENT-004 | 客户在线时分别向同一长短信的两个分片推送回执 | Gateway发送的两个`CMPP_DELIVER`回执内容分别携带两个不同的原SubmitResp Msg_Id，不因在线会话按业务消息查找而都复用第一片Msg_Id |
|
||||
| TC-RECEIPT-TIMEOUT-005 | HTTP消息超过72小时无明确回执，首次Webhook建单失败，下一轮扫描恢复 | 主记录只转一次`timeout`并只退款一次；失败时`timeoutReceiptQueuedAt`为空，后续扫描补建`undelivered/EXPIRED/RECEIPT_TIMEOUT`事件后写入标记，HTTP最终事件只有一个 |
|
||||
| TC-RECEIPT-TIMEOUT-006 | CMPP长短信超过72小时无明确回执，其中部分片已有真实回执，其余片缺失 | 已有结果的分片保留自己的最终状态；缺失片收到明确`EXPIRED`失败回执；每片使用各自原SubmitResp Msg_Id并可分别ACK，重复扫描不重复发送 |
|
||||
|
||||
## 2026-08-06 供应商整条级回执与网关异常中心用例
|
||||
|
||||
| 用例编号 | 操作 | 预期结果 |
|
||||
| --- | --- | --- |
|
||||
| TC-RECEIPT-MODE-001 | 新建或编辑通道，不设置长短信成功回执口径；两分片长短信只收到第一片成功 | 后端按`per_segment`默认值保存；真实回执和第一片审计落库，第二片仍无回执，主记录保持`submitted`，不提前退款、补发或推送最终成功 |
|
||||
| TC-RECEIPT-MODE-002 | 将测试通道设置为`message_level`，两分片当前提交尝试只收到一条明确成功回执 | 只新增一条真实`SmsReceiptRecord`；缺失分片审计被标记`delivered`且`compensationType=supplier_message_level_receipt`，主记录形成一次成功终态，并按客户原始`Registered_Delivery`逐片幂等建立CMPP回执或建立一个HTTP事件 |
|
||||
| TC-RECEIPT-MODE-003 | 在`message_level`通道中，对含明确失败分片、历史提交尝试或单分片短信输入成功回执 | 明确失败不被覆盖，历史尝试不改变当前终态，单分片不产生推断分片；不得重复计费、退款、补发或下游投递 |
|
||||
| TC-RECEIPT-CONFLICT-001 | 整条级成功已经形成`delivered`后，同一提交尝试又收到明确失败回执，并重复输入同一矛盾事件 | 原始失败回执和分片证据保留；主记录仍为`delivered`，不补发、不退款、不向客户推送失败；`SmsReceiptAnomaly`按稳定键只有一条记录并累加发生次数 |
|
||||
| TC-GATEWAY-EXCEPTION-UI-001 | 打开运营端“网关异常”，切换“提交异常”和“回执异常”Tab并刷新、筛选、翻页 | 菜单新名称和两个Tab正常展示且原路由可访问；两个Tab分别调用真实提交死信API和回执异常API，筛选、汇总、总数和分页与PostgreSQL一致，不使用mock、静态数据或localStorage |
|
||||
| TC-GATEWAY-EXCEPTION-UI-002 | 阅读两个Tab标题说明并打开两类详情 | “提交异常”明确说明死信不等于供应商拒绝/送达失败及重入队风险；“回执异常”明确说明其为终态冲突摘要，并指向真实回执记录和通讯交互日志，详情不泄露通道密码或鉴权信息 |
|
||||
|
||||
Reference in New Issue
Block a user