130 lines
10 KiB
Markdown
130 lines
10 KiB
Markdown
# QA 审核报告：AI-Ops 测试设计文档
|
||
|
||
> 审核日期：2026-05-11
|
||
> 审核人：QA Agent
|
||
> 审核对象：TEST_DESIGN.md / CASES.md / STRATEGY.md
|
||
> 对照基准：PRD.md (AC-01 ~ AC-12, F-01 ~ F-08)
|
||
|
||
---
|
||
|
||
## 总体评级：C
|
||
|
||
**评级依据**：测试策略框架和分层模型设计较为完整，Mock 策略、环境矩阵、灰度 Phase 规划具备可执行基础。但存在 3 项 P0 严重缺陷：AC 负向用例大面积缺失、异常流程 F-05~F-08 在 CASES.md 中完全遗漏、CI 集成零配置。上述问题将导致测试覆盖存在盲区，且无法形成自动化门禁闭环。
|
||
|
||
---
|
||
|
||
## 优点
|
||
|
||
1. **测试分层模型清晰**：TEST_DESIGN.md 1.1 明确划分 Unit → Integration → E2E 三层，STRATEGY.md 补充 Chaos Test，结构合理。
|
||
2. **Mock 策略全面**：覆盖 Prometheus、 supply-api、token-runtime、通知渠道、PostgreSQL、Redis 等全部核心外部依赖，工具选型合理（sqlmock / miniredis / gock / httptest）。
|
||
3. **环境矩阵设计完整**：Local Dev / CI / Sandbox / Staging / Production 五层环境各有明确的用途、数据特征和外部依赖策略。
|
||
4. **灰度 Phase 规划可落地**：Phase 1~4 的验证内容与回归集范围明确，与 PRD 发布策略对应。
|
||
5. **发布门禁检查表（8.1）覆盖关键风险点**：独立/集成双模式验证、沙盒验证、回滚演练、权限矩阵、端到端链路验证等 8 项全部列出。
|
||
6. **回归集分级合理**：区分快速回归集（9 条，5-10 分钟）与完整回归集（43 条，30-60 分钟），适合不同触发条件。
|
||
|
||
---
|
||
|
||
## 发现问题（按严重度分类）
|
||
|
||
### P0 — 阻塞级（必须修复，否则无法进入开发/提测）
|
||
|
||
| 编号 | 问题描述 | 影响 | 依据 |
|
||
|------|---------|------|------|
|
||
| P0-01 | **AC 负向测试用例大面积缺失**。12 个 AC 中至少 8 个（AC-01/02/04/05/06/09/10/11）在 CASES.md 与 TEST_DESIGN.md 中均无任何负向/异常输入用例。仅 AC-03、AC-08 有明确的 Negative 用例，AC-12 有权限越界类负向用例。 | 无法验证系统在非法输入、边界越界、权限不足、数据异常等场景下的行为，存在生产缺陷逃逸风险。 | 审核标准 #1 |
|
||
| P0-02 | **CASES.md 遗漏异常流程 F-05~F-08**。PRD 明确定义 F-01~F-08 共 8 条异常流程，CASES.md 仅覆盖 TC-E1~E4（对应 F-01~F-04），F-05（审计满盘）、F-06（级联故障）、F-07（数据库全面中断）、F-08（看板计算超时）完全缺失。 | 核心容灾与降级场景无测试用例兜底，与 PRD 6. 节要求不符。 | 审核标准 #2 |
|
||
| P0-03 | **CI 集成零配置**。STRATEGY.md 6. 仅文字描述"PR 提交时自动触发"，未提供任何 CI 配置文件（如 .github/workflows/ci.yml）、Pipeline 阶段定义、失败通知模板、覆盖率采集与阻断逻辑。 | 无法形成自动化质量门禁，所有覆盖率/通过率要求沦为纸面标准。 | 审核标准 #6 |
|
||
| P0-04 | **性能压测方法过于简略，无执行载体**。TEST_DESIGN.md 9.1 虽列出 k6 并发用户数，但未提供 k6 脚本、压测环境规格（CPU/内存/DB 实例）、数据量基准、P99 计算方式、持续时间。"单次告警触发计时"未说明计时起点/终点和采样次数。 | 性能基准无法复现和验证，灰度门禁中"性能基准测试通过"无法判定。 | 审核标准 #8 |
|
||
|
||
### P1 — 高优先级（强烈建议修复，否则提测后返工风险高）
|
||
|
||
| 编号 | 问题描述 | 影响 | 依据 |
|
||
|------|---------|------|------|
|
||
| P1-01 | **覆盖率门槛缺少验证机制**。文档多次声明 domain ≥70%、service/handler ≥80%，但未说明：使用 `go test -coverprofile` 还是第三方工具、CI 中如何解析并阻断未达标 PR、覆盖率报告存储位置、增量覆盖率是否校验。 | 覆盖率目标无法自动 enforce，开发者可能随时跌破门槛。 | 审核标准 #4 |
|
||
| P1-02 | **混沌测试（Chaos Test）无具体用例设计**。STRATEGY.md 提到 chaos-mesh / 自定义脚本和三类故障（单机故障、网络分区、主从切换），但 TEST_DESIGN.md 与 CASES.md 中均未设计任何 Chaos 用例（无 Given-When-Then、无验证点、无预期行为）。 | 混沌测试 layer 有名无实，无法验证系统韧性。 | 审核标准 #3 |
|
||
| P1-03 | **测试数据管理策略缺关键细节**。STRATEGY.md 提到 `test/fixtures/` 和"自洁"，但未给出：fixtures 目录结构规范、大数据量（如 10000 条审计日志）的生成脚本、敏感数据脱敏方法、不同测试并行时的数据隔离策略。 | 大数据量性能用例和 E2E 用例可能因数据准备不足而无法稳定执行。 | 审核标准 #7 |
|
||
| P1-04 | **灰度门禁缺少自动化判定脚本**。TEST_DESIGN.md 5.2 列出 6 项检查项，但均为人工勾选（`- [ ]`），未说明每项如何自动采集结果（如覆盖率报告解析、沙盒验证次数统计、安全扫描工具输出格式）。 | Phase 升级依赖人工审核，效率低且易遗漏。 | 审核标准 #5 |
|
||
| P1-05 | **安全扫描工具与阈值未指定**。灰度门禁和发布门禁均提到"安全扫描通过（无高危漏洞）"，但未指定扫描工具（Trivy / Snyk / Gosec）、漏洞等级定义、扫描时机（CI / 镜像构建 / 发布前）。 | 安全门禁无法执行。 | 审核标准 #5 |
|
||
| P1-06 | **E2E 测试缺少详细场景设计**。STRATEGY.md 提到"自定义 Go E2E 框架"和"前端流程测试"，但 TEST_DESIGN.md / CASES.md 中无任何 E2E 级别的 Given-When-Then 用例（如完整链路：模拟指标异常 → 告警触发 → 通知发送 → 自愈执行 → 事件记录）。 | E2E 覆盖率无法评估。 | 审核标准 #3 |
|
||
|
||
### P2 — 一般优化（建议修复，提升可维护性）
|
||
|
||
| 编号 | 问题描述 | 影响 |
|
||
|------|---------|------|
|
||
| P2-01 | **用例编号风格不统一**。TEST_DESIGN.md 使用 `TC-01-01`，CASES.md 使用 `TC-1.1`，同一项目内两种命名规范，易导致用例追溯混乱。 |
|
||
| P2-02 | **CASES.md TC-E2 与 PRD 描述不一致**。CASES.md 写"模拟 Webhook 8xx"，PRD F-2 写"Webhook 8xx/5xx"，遗漏 5xx 场景。 |
|
||
| P2-03 | **AC-06 自愈缺少负向/非法配置用例**。如：配置不存在的自愈动作类型、自愈脚本权限不足、沙盒模式未通过却尝试生产执行等。 |
|
||
| P2-04 | **AC-10 日志查询缺少负向用例**。如：超大时间范围查询、非法正则过滤、无权限访问其他服务日志等。 |
|
||
| P2-05 | **测试通过标准（TEST_DESIGN.md 1.2）中"告警噪声率 ≤1%"和"自愈误触发 0 次"缺少测量方法**。未说明沙盒测试的样本量、统计周期、噪声率计算公式。 |
|
||
|
||
---
|
||
|
||
## 改进建议
|
||
|
||
### 立即行动（进入开发前必须完成）
|
||
|
||
1. **补齐 AC 负向用例**
|
||
- AC-01：增加"未登录访问首页返回 401"、"非法时间范围参数返回 400"。
|
||
- AC-02：增加"下钻不存在的 service 返回空结果/404"、"超大时间范围返回 413/截断"。
|
||
- AC-04：增加"通知渠道全部失效时记录失败并触发内部告警"、"非法事件 ID 查询返回 404"。
|
||
- AC-05：增加"聚合阈值设置为 0 或负数时的校验拒绝"。
|
||
- AC-06：增加"沙盒未通过时禁止关联生产规则"、"自愈动作类型非法返回 400"。
|
||
- AC-09：增加"容量主板数据源丢失时展示降级提示"。
|
||
- AC-10：增加"导出超过 10000 条时返回 413 或分批"。
|
||
- AC-11：增加"查询已清理数据返回空并提示保留策略"。
|
||
|
||
2. **在 CASES.md 中补全 F-05~F-08**
|
||
- TC-E5：模拟审计磁盘满，验证丢弃非关键字段/异步上报且业务不阻断。
|
||
- TC-E6：模拟自愈切换导致新故障，验证自动回退 + P0 升级。
|
||
- TC-E7：模拟时序库全面中断，验证控制台只读 + 告警引擎缓存运行。
|
||
- TC-E8：模拟看板查询超时，验证显示上次成功结果 + 时间戳标注。
|
||
|
||
3. **提供 CI 配置文件**
|
||
- 创建 `.github/workflows/ci.yml`（或对应平台配置），至少包含：
|
||
- Go 版本声明（1.22+）
|
||
- `go test -race -coverprofile=coverage.out ./...`
|
||
- 覆盖率解析步骤（如使用 `gocov` 或自定义脚本检查 domain ≥70%、service ≥80%）
|
||
- 未达标时 PR 阻断（exit 1）
|
||
- 测试失败通知 TechLead / QA 的机制（如 Slack / 邮件 Webhook）
|
||
- 每日定时 E2E / 每周 Chaos 的 workflow 文件
|
||
|
||
4. **输出可执行的性能压测资产**
|
||
- 提供 `test/perf/` 目录，包含：
|
||
- `dashboard_k6.js`：50 并发首页加载压测脚本
|
||
- `drilldown_k6.js`：20 并发下钻压测脚本
|
||
- `alert_latency_test.go`：告警触发到通知的计时单测（含重试统计）
|
||
- `PERF_ENV.md`：压测环境规格、数据量基准、判定标准（P99 计算方式、持续 5min）
|
||
|
||
### 短期优化（提测前完成）
|
||
|
||
5. **建立覆盖率验证机制**
|
||
- 在 CI 中引入 `go tool cover -func=coverage.out` 解析，按模块（domain / service / handler）分别校验阈值。
|
||
- 引入增量覆盖率检查（如 codecov / coveralls），要求新增代码覆盖率 ≥80%。
|
||
|
||
6. **补充混沌测试用例**
|
||
- 在 TEST_DESIGN.md 中新增"混沌测试"章节，至少设计 3 条可执行用例：
|
||
- Chaos-01：随机杀死一个服务 Pod，验证告警引擎本地缓存持续运行且控制台进入只读。
|
||
- Chaos-02：模拟 Redis 网络分区 30s，验证告警抑制状态不丢失、恢复后不重复通知。
|
||
- Chaos-03：模拟 PostgreSQL 主从切换，验证审计写入短暂失败后异步补写。
|
||
|
||
7. **完善测试数据管理规范**
|
||
- 创建 `test/fixtures/` 目录结构文档，规定 SQL / JSON / Go seed 三种数据注入方式。
|
||
- 为大数据量性能测试提供数据生成脚本（如 `generate_audit_logs.go` 生成 10000 条审计记录）。
|
||
- 明确并行测试隔离方案（testcontainers 独立数据库 / 事务回滚 / 唯一 schema）。
|
||
|
||
8. **统一用例编号规范**
|
||
- 建议统一为 `TC-{AC}-{序号}`（如 `TC-01-01`），并同步修改 CASES.md。
|
||
|
||
---
|
||
|
||
## 审核结论
|
||
|
||
**当前状态：REQUEST_CHANGES**
|
||
|
||
本文档在测试策略框架层面具备较好的完整性，分层模型、Mock 策略、环境矩阵和发布门禁检查表已达到可评审水平。但由于 P0-01 ~ P0-04 四项阻塞级缺陷（负向用例大面积缺失、异常流程遗漏、CI 零配置、性能压测无载体），**当前测试设计不足以支撑进入开发或提测阶段**。
|
||
|
||
建议研发团队优先补齐上述"立即行动"项，完成后提交 QA 复评。
|
||
|
||
---
|
||
|
||
> 报告生成路径：`/home/long/project/ai-ops/tech/QA_REVIEW_REPORT.md`
|