niuniu/ai-ops
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
fc54ba84b20c2f129780edfa9a20d0306eae2d4c
ai-ops/tech/QA_REVIEW_REPORT.md
phamnazage-jpg fc54ba84b2 chore: initial import
2026-05-12 17:48:22 +08:00

10 KiB
Raw Blame History

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-01F-08 共 8 条异常流程，CASES.md 仅覆盖 TC-E1E4（对应 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）

短期优化（提测前完成）

  1. 建立覆盖率验证机制

    • 在 CI 中引入 go tool cover -func=coverage.out 解析，按模块（domain / service / handler）分别校验阈值。
    • 引入增量覆盖率检查（如 codecov / coveralls），要求新增代码覆盖率 ≥80%。

  2. 补充混沌测试用例

    • 在 TEST_DESIGN.md 中新增"混沌测试"章节，至少设计 3 条可执行用例：
      • Chaos-01：随机杀死一个服务 Pod，验证告警引擎本地缓存持续运行且控制台进入只读。
      • Chaos-02：模拟 Redis 网络分区 30s，验证告警抑制状态不丢失、恢复后不重复通知。
      • Chaos-03：模拟 PostgreSQL 主从切换，验证审计写入短暂失败后异步补写。

  3. 完善测试数据管理规范

    • 创建 test/fixtures/ 目录结构文档，规定 SQL / JSON / Go seed 三种数据注入方式。
    • 为大数据量性能测试提供数据生成脚本（如 generate_audit_logs.go 生成 10000 条审计记录）。
    • 明确并行测试隔离方案（testcontainers 独立数据库 / 事务回滚 / 唯一 schema）。

  4. 统一用例编号规范

    • 建议统一为 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

Reference in New Issue View Git Blame Copy Permalink