3.5 KiB
3.5 KiB
第一版系统化测试计划
1. 测试目标
第一版测试优先保证短信业务主链路可回归：风控、计费、发送编排、通道路由与报备、查询统计、Gateway 追踪和模拟链路。不依赖真实运营商 CMPP 网关；本地没有 PostgreSQL、Redis、MinIO 时，优先使用 mock、测试替身或 spike 模拟器。
2. 测试分层
2.1 单元测试
- NestJS/API 使用 Jest + ts-jest。
- Go Gateway 使用 Go 原生
testing。 - 目标：覆盖纯业务规则、状态流转、查询条件、Gateway tracker/reconnector/health 等无需真实外部服务的逻辑。
- 当前重点：
- 风控规则评估：最大号码数、重复率、非法号码率、黑名单率、模板变量异常、直接拒绝、进入人工审核。
- 计费：费用预估、余额检查、冻结、扣费、释放、退款、短信计费记录。
- 发送链路：批量任务创建、手机号拆分、发送入队、submit result 更新、receipt 更新、uplink 记录、72 小时未知转超时。
- 通道与报备：通道创建、路由规则、签名报备任务、导出、回执导入、签名状态同步。
- 查询统计：发送链路 trace、对账 reconciliation、dashboard/statistics。
- Gateway：SEQID/MSGID 追踪、重连、health、gocmpp submit/resp 模拟器。
2.2 集成测试
- 第一版本轮采用“Service + mock Prisma/BullMQ/Redis”的轻集成方式，验证 NestJS service 编排和数据访问参数。
- 后续如本地或 CI 具备 PostgreSQL/Redis/MinIO，可增加：
- Prisma test database 集成测试。
- BullMQ + Redis 队列消费集成测试。
- MinIO 预签名上传集成测试。
2.3 契约测试
- 继续复用
docs/contracts/gateway-queue-messages.schema.json。 - 继续使用
tools/spike/validate-gateway-queue-contract.mjs校验 SubmitCommand、SubmitResult、ReceiptEvent、UplinkEvent 示例。 - 队列消息变更必须先改 schema 和示例，再改 NestJS/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. 执行命令
npm run spike:contracts
npm run test:api
npm run test:gateway
npm run spike:bullmq
npm run verify:phase8
API 目录内也可直接执行：
npm --prefix api test
Gateway 目录内如 Go 已在 PATH，可直接执行：
go test ./...
Windows 本项目推荐使用根脚本 npm run test:gateway，脚本会临时补充 Go 安装路径。
4. 已知边界
- 本轮 API 测试不连接真实 PostgreSQL、Redis、MinIO。
- 发送 Worker 的 Redis 限速和 BullMQ 投递在 unit/light integration 中使用 mock；真实 Redis 链路由
spike:bullmq覆盖。 - 前端暂未新增测试框架；当前保留
npm run build作为 smoke。若后续引入 Vitest/Playwright，应先覆盖登录页、客户端发送页、运营端监控页的加载 smoke。 - Gateway 不连接真实运营商 SMSC；使用 gocmpp 适配测试和内部模拟器测试。