# 第一版系统化测试计划

## 1. 测试目标

第一版测试优先保证短信业务主链路可回归：风控、计费、发送编排、通道路由与报备、查询统计、Gateway 追踪和模拟链路。系统功能验收必须使用真实 NestJS API、Prisma/PostgreSQL、Redis/BullMQ、MinIO 或对应的本地服务；不依赖真实运营商 CMPP 网关，但 Gateway 场景必须通过 Go Gateway、本地 SMSC 模拟器或连接状态回写 API 完成闭环。本地没有 PostgreSQL、Redis、MinIO 时，对应系统功能用例标记为阻塞或未执行，不能用 mock 作为通过依据。

系统功能测试用例详见 `docs/system-functional-test-cases.md`。该文档面向第一版验收、人工测试和后续 E2E 自动化改造，覆盖客户端、运营端、API、Gateway 和性能 smoke 场景。

## 2. 测试分层

### 2.1 单元测试

- NestJS/API 使用 Jest + ts-jest。
- Go Gateway 使用 Go 原生 `testing`。
- 目标：覆盖纯业务规则、状态流转、查询条件、Gateway tracker/reconnector/health 等无需真实外部服务的逻辑。
- 当前重点：
  - 风控规则评估：最大号码数、重复率、非法号码率、黑名单率、模板变量异常、直接拒绝、进入人工审核。
  - 计费：费用预估、余额检查、冻结、提交 accepted 扣费、失败回执退款、短信计费记录、应用级客户费率、重复回调幂等。
  - 发送链路：批量任务创建、手机号拆分、按应用队列等级分流普通/优先队列、优先队列插队消费、普通队列防饿死、运营商前缀正则分流、手机号段归属地识别、应用运营商通道组路由、省网/全国路由、submit result 更新、receipt 更新、迟到旧回执不覆盖最终成功、失败补发、补发停止条件、uplink 记录、72 小时未知转超时。
  - 通道与报备：通道创建、通道发送地区、三网通道通配、单运营商通道组、通道组明细 carrier 参与发送、省份与通道发送地区一致性、全国通道优先级唯一、企业应用通道组保存校验、禁止单通道发送规则、最终选中通道签名报备校验、签名报备任务、导出、回执导入、签名状态同步。
  - 查询统计：发送链路 trace、对账 reconciliation、dashboard/statistics。
  - Gateway：SEQID/MSGID 追踪、重连、health、gocmpp submit/resp 模拟器。

### 2.2 集成测试

- 单元/轻集成测试可以使用 mock Prisma/BullMQ/Redis 验证 Service 编排和异常分支，但这只代表代码级测试通过。
- 系统功能集成测试必须补充真实服务闭环：
  - Prisma/PostgreSQL test database 集成测试。
  - BullMQ + Redis 队列消费集成测试，覆盖普通队列、优先队列、混合积压、优先队列插队和普通队列恢复。
  - MinIO 预签名上传集成测试。
  - 前端页面调用真实 API 的浏览器 smoke。

### 2.3 契约测试

- 继续复用 `docs/contracts/gateway-queue-messages.schema.json`。
- 继续使用 `tools/spike/validate-gateway-queue-contract.mjs` 校验 SubmitCommand、SubmitResult、ReceiptEvent、UplinkEvent 示例。
- 队列消息变更必须先改 schema 和示例，再改 NestJS/Gateway 实现。
- 若队列消息新增 queuePriority、priority 或队列名称字段，必须同步更新契约 schema、示例、NestJS 生产者、Send Worker 消费者和 Gateway 消费入口。

### 2.4 端到端 Smoke

- 当前端到端 smoke 由阶段验证脚本覆盖：
  - 队列契约校验。
  - Go Gateway 测试。
  - BullMQ spike。
  - Prisma Client 生成。
  - API build。
  - 前端 build。
- 不接真实运营商网关。
- PostgreSQL/Redis 可用时必须执行 API HTTP smoke：创建任务 -> 入队 -> 模拟 submit result -> 回执 -> trace 查询；不可用时标记阻塞，不记为通过。

### 2.5 性能 Smoke

- 继续复用 `npm run spike:bullmq`。
- 验证 15000 条消息、并发 500 的入队和端到端队列链路吞吐。
- 混合优先级压测必须额外验证：普通队列已有积压时，新进入的优先队列消息能更早被消费；优先队列持续进入时，普通队列仍能按配置恢复消费，不出现永久饥饿。
- 性能 smoke 只验证第一版“可稳定入队并调度 500 条短信/秒”的链路能力，不替代生产压测。

## 3. 执行命令

```bash
npm run spike:contracts
npm run test:api
npm run test:gateway
npm run spike:bullmq
npm run verify:phase8
```

API 目录内也可直接执行：

```bash
npm --prefix api test
```

Gateway 目录内如 Go 已在 PATH，可直接执行：

```bash
go test ./...
```

Windows 本项目推荐使用根脚本 `npm run test:gateway`，脚本会临时补充 Go 安装路径。

## 4. 已知边界

- 单元测试和轻集成测试可以使用 mock Prisma/BullMQ/Redis 作为测试替身，但这只适用于测试隔离，不代表业务功能可以停留在 mock。
- 真实开发完成标准必须包含：Prisma/PostgreSQL 模型或查询、NestJS Service/Controller、必要的操作日志、前端调用真实 API，以及在真实 PostgreSQL/Redis/MinIO 可用时完成 smoke。
- 发送 Worker 的 Redis 限速和 BullMQ 投递可在 unit/light integration 中使用 mock；真实 Redis 链路仍需由 `spike:bullmq`、API smoke 或端到端验证覆盖。
- 前端暂未新增测试框架；`npm run build` 只作为构建 smoke，不代表页面业务通过。新增页面能力必须调用真实 API；前端本地状态、localStorage、静态数组、兜底数据不能作为系统功能验收通过依据。
- Gateway 不连接真实运营商 SMSC；使用 gocmpp 适配测试和内部模拟器测试。

## 5. 纯 mock 菜单回归要求

- 每次新增或修改菜单页后，必须用源码搜索确认非彩信/非待开发页面不存在 `clientService`、`adminService`、`initial*` 静态业务数组、业务 localStorage 兜底或 API 失败后静默回退。
- 对于后端暂未提供的业务动作，前端只允许展示不可用、待补接口或空态；不得用 `useState` 模拟创建、删除、审核、充值、发送、报备成功。
- 彩信相关页面当前可保留待开发占位，但测试报告必须单独标注，不得混入短信第一版已完成范围。