---
title: "test: GEO Platform Quality Assurance System"
type: test
status: active
date: "2026-05-31"
origin: docs/brainstorms/2026-05-31-geo-platform-next-phase-quality-requirements.md
---

## Summary

GEO 平台质量保障体系建设，采用双轨并行策略：轨道一统一测试基础设施（合并分裂目录、完善 CI、建立共享 fixture），轨道二同步推进核心业务 E2E 测试和四项专项测试（性能基线、安全扫描、迁移验证、Agent E2E），确保核心业务流程尽早获得回归保护。

## Problem Frame

GEO 平台经过多轮迭代已具备 33 个 API、8 个 Agent、25+ 前端页面，但测试覆盖严重不足：后端两套测试目录分裂导致 17 个测试被 CI 忽略，前端仅 13 个单元测试且零组件测试，E2E 仅覆盖登录流程，核心业务完全无回归保护。CI 不运行 E2E 测试，无安全扫描，无性能基线。在用户开始使用前，必须建立质量保障体系防止功能回归。

---

## Requirements

### 测试基础设施

R1. 将 `geo/tests/` 下的 17 个测试迁移至 `backend/tests/` 对应子目录，合并两套 conftest.py 的 fixture，删除旧目录

R2. CI 中 `pytest tests/` 命令能发现并运行全部后端测试

R3. 将 `pytest-cov` 正式加入 `backend/requirements.txt`

R4. 建立共享 fixture 体系：数据库会话（含自动 rollback）、认证 mock（JWT token + auth headers）、测试用户创建、httpx AsyncClient

R5. 前端 vitest 覆盖范围扩展至 `lib/api/` 全部 27 个模块和关键页面组件

R6. 更新 `docs/03-开发指南/testing.md` 使其与实际目录结构、CI 配置、fixture 体系一致

### 核心业务 E2E 测试

R7. 编写用户注册→登录→Onboarding→品牌创建的完整 E2E 测试

R8. 编写诊断→查看诊断报告→生成 GEO 方案的 E2E 测试

R9. 编写内容生成→查看内容→效果追踪的 E2E 测试

R10. E2E 测试在 CI 中运行（至少 Chromium），使用 PostgreSQL 和 Redis service container

R11. E2E 测试失败时自动截图和录制视频

### 专项测试

R12. 为 5-10 个高频 API 端点建立性能基线（p50/p95/p99 响应时间），首轮只采集不设阈值

R13. CI 中集成 bandit（Python 安全扫描）和 npm audit（Node.js 依赖安全检查），PR 级别阻断高危漏洞

R14. CI 中添加 Alembic 迁移验证步骤

R15. 编写 Agent 框架端到端测试：任务创建→分发→执行→结果查询的完整链路（至少覆盖 CitationDetector 和 ContentGenerator）

### 前端组件测试

R16. 为 5 个关键页面组件编写 React Testing Library 测试

R17. 为 4 个新 Agent 的前端 API 客户端模块编写单元测试

---

## Key Technical Decisions

KTD1. **双轨并行而非分层递进** — 基础设施统一和 E2E 测试编写同步推进，两者几乎不涉及相同文件，并行没有实质冲突。E2E 测试初期用独立 setup，后续迁移到共享 fixture 是低成本重构。

KTD2. **E2E 测试仅覆盖 Chromium** — 先在一个浏览器上稳定运行，跨浏览器扩展作为后续迭代。Playwright 已配置 3 浏览器但当前 E2E 用例太少，扩展浏览器覆盖的 ROI 不高。

KTD3. **性能测试先建基线再设阈值** — 在没有历史数据时设定 SLA 容易过严或过松。第一轮只采集数据建立基线，第二轮根据基线设定阈值和告警。

KTD4. **Agent E2E 测试优先使用真实 LLM 调用** — 可使用 LLM API Key 进行真实调用测试，确保 Agent 在实际 LLM 响应下的行为正确。CI 中通过环境变量注入 API Key，无 Key 时降级为 mock 模式。

KTD5. **安全扫描集成到 CI 而非独立流程** — bandit 和 npm audit 作为 CI 步骤运行，在 PR 级别就暴露问题。

---

## Implementation Units

### U1. 统一后端测试目录

- **Goal:** 消除测试目录分裂，确保 CI 能发现并运行全部后端测试
- **Requirements:** R1, R2, R3
- **Dependencies:** none
- **Files:**
  - `geo/tests/` (17 files to migrate)
  - `backend/tests/conftest.py` (merge fixtures)
  - `geo/tests/conftest.py` (merge then delete)
  - `backend/requirements.txt` (add pytest-cov)
  - `.github/workflows/ci.yml` (verify pytest discovers all tests)
- **Approach:** 逐个迁移 `geo/tests/` 下的测试文件到 `backend/tests/` 对应子目录（test_api/, test_services/ 等）。合并两套 conftest.py：保留 `backend/tests/conftest.py` 的内存 SQLite 引擎，从 `geo/tests/conftest.py` 迁入 async_client、auth_token、auth_headers、override_get_current_user 等 fixture。删除 `geo/tests/` 目录。将 pytest-cov 加入 requirements.txt。
- **Patterns to follow:** `backend/tests/conftest.py` 现有 fixture 模式（async_engine, async_session, test_user）
- **Test scenarios:**
  - `cd backend && pytest tests/` 发现并运行全部测试（≥77 个）
  - 迁移后的测试功能与迁移前一致
  - CI 中 pytest 命令无需修改即可运行全量测试
- **Verification:** `cd backend && pytest tests/ --tb=short` 全部通过，`geo/tests/` 目录已不存在

### U2. 建立共享 fixture 体系

- **Goal:** 为后端集成测试和 E2E 测试提供可复用的测试基础设施
- **Requirements:** R4
- **Dependencies:** U1
- **Files:**
  - `backend/tests/conftest.py` (enhance with shared fixtures)
  - `backend/tests/fixtures/` (new directory for modular fixtures)
  - `backend/tests/fixtures/auth.py` (authentication fixtures)
  - `backend/tests/fixtures/database.py` (database fixtures)
  - `backend/tests/fixtures/client.py` (httpx client fixtures)
  - `backend/tests/fixtures/brands.py` (brand and competitor test data)
- **Approach:** 在 `backend/tests/fixtures/` 下按领域拆分 fixture 模块。auth.py 提供 override_get_current_user、auth_token、auth_headers。database.py 提供 async_engine、async_session（含自动 rollback）。client.py 提供 async_client（httpx AsyncClient with app）。brands.py 提供预创建的测试品牌和竞品数据。conftest.py 通过 pytest plugin 机制自动加载 fixtures/ 下所有模块。
- **Patterns to follow:** `geo/tests/conftest.py` 中已有的 fixture 实现（async_client, auth_token, override_get_current_user）
- **Test scenarios:**
  - 使用 auth_headers fixture 的测试能成功调用需要认证的 API
  - 使用 async_client fixture 的测试能发送 HTTP 请求到 FastAPI 应用
  - 数据库 fixture 在测试结束后自动 rollback，不污染数据库
  - 多个测试并行运行时 fixture 互不干扰
- **Verification:** 使用新 fixture 编写 2-3 个示例测试并全部通过

### U3. 核心业务 E2E — 用户注册到品牌创建

- **Goal:** 覆盖用户从注册到品牌创建的完整 Onboarding 流程
- **Requirements:** R7, R11
- **Dependencies:** none (独立 setup，不依赖 U2)
- **Files:**
  - `frontend/e2e/tests/onboarding.spec.ts` (new)
  - `frontend/e2e/fixtures/auth.ts` (new, independent setup)
  - `frontend/playwright.config.ts` (verify screenshot/video config)
- **Approach:** 编写 Playwright 测试覆盖：注册新用户→登录→进入 Onboarding→填写品牌名称→添加竞品→选择平台→查看健康报告→完成引导。使用独立 setup（直接调用 API 创建测试数据），后续可迁移到共享 fixture。确保 playwright.config.ts 中 screenshot:on-failure 和 video:retain-on-failure 已配置。
- **Patterns to follow:** `frontend/e2e/tests/login.spec.ts` 现有 E2E 测试模式
- **Test scenarios:**
  - Covers AE1 (from origin): 注册→登录→Onboarding→品牌创建全流程通过
  - 注册时输入无效邮箱显示错误提示
  - 品牌名称为空时无法提交
  - 不添加竞品也能完成 Onboarding
  - 已注册用户登录后直接跳转 Dashboard
- **Verification:** `cd frontend && npx playwright test onboarding` 通过

### U4. 核心业务 E2E — 诊断到 GEO 方案

- **Goal:** 覆盖诊断→方案生成的核心业务闭环
- **Requirements:** R8, R11
- **Dependencies:** U3 (需要已登录用户和品牌)
- **Files:**
  - `frontend/e2e/tests/diagnosis-strategy.spec.ts` (new)
- **Approach:** 在 U3 创建的品牌基础上，编写：进入诊断页面→触发诊断→查看诊断报告→点击"基于诊断制定 GEO 方案"→查看方案详情。诊断和方案生成可能需要较长时间，使用适当的等待策略。
- **Patterns to follow:** `frontend/e2e/tests/login.spec.ts` 现有 E2E 测试模式
- **Test scenarios:**
  - Covers AE2 (from origin): 诊断→报告→方案生成全流程通过
  - 诊断页面正确显示品牌评分
  - 方案生成后显示行动项列表
  - 方案行动项状态可更新
- **Verification:** `cd frontend && npx playwright test diagnosis-strategy` 通过

### U5. 核心业务 E2E — 内容生成到效果追踪

- **Goal:** 覆盖内容生成→查看→效果追踪的内容工坊流程
- **Requirements:** R9, R11
- **Dependencies:** U3 (需要已登录用户和品牌)
- **Files:**
  - `frontend/e2e/tests/content-monitoring.spec.ts` (new)
- **Approach:** 编写：进入内容工坊→输入关键词→生成内容→查看生成结果→进入效果追踪页面→查看监测数据。内容生成可能需要 LLM 调用，使用较长超时或 mock。
- **Patterns to follow:** `frontend/e2e/tests/login.spec.ts` 现有 E2E 测试模式
- **Test scenarios:**
  - Covers AE3 (from origin): 内容生成→查看→效果追踪全流程通过
  - 内容生成页面正确显示生成状态
  - 生成完成后内容可查看
  - 效果追踪页面显示监测数据
- **Verification:** `cd frontend && npx playwright test content-monitoring` 通过

### U6. CI 集成 E2E 测试

- **Goal:** 将 E2E 测试纳入 CI 流水线
- **Requirements:** R10
- **Dependencies:** U3, U4, U5
- **Files:**
  - `.github/workflows/ci.yml` (add E2E step)
  - `.github/workflows/pr-check.yml` (add E2E step)
- **Approach:** 在 CI 中添加 E2E 测试步骤：启动 PostgreSQL 和 Redis service container → 启动后端服务 → 启动前端服务 → 运行 Playwright 测试。仅运行 Chromium 项目以控制时间。E2E 步骤放在单元测试之后，允许失败但不阻塞（初期），稳定后改为阻塞。
- **Patterns to follow:** 现有 CI 中 PostgreSQL 和 Redis service container 配置
- **Test scenarios:**
  - PR 提交时 CI 自动运行 E2E 测试
  - E2E 测试失败时 CI 标记为失败
  - 截图和视频作为 artifact 上传
- **Verification:** 提交一个测试 PR，观察 CI 中 E2E 步骤是否正确运行

### U7. 性能基线测试

- **Goal:** 为高频 API 端点建立性能基线数据
- **Requirements:** R12
- **Dependencies:** U2
- **Files:**
  - `backend/tests/performance/` (new directory)
  - `backend/tests/performance/__init__.py` (new)
  - `backend/tests/performance/test_api_baseline.py` (new)
  - `backend/tests/performance/conftest.py` (new)
- **Approach:** 使用 httpx AsyncClient 对 5-10 个高频端点（dashboard/stats, brands, queries, citations, content/generate, strategy/generate, monitoring/brand/{id}, analytics/overview, diagnosis, ai-engines/query）发送多次请求，采集 p50/p95/p99 响应时间，输出为 JSON 基线文件。首轮只采集不设阈值。使用 pytest-benchmark 或自定义计时逻辑。
- **Patterns to follow:** `backend/tests/` 现有测试结构
- **Test scenarios:**
  - Covers AE4 (from origin): 对 dashboard/stats 发送 100 次请求采集性能数据
  - 基线数据以 JSON 格式保存
  - 性能测试可在本地和 CI 中运行
  - 首轮不设阈值不阻断
- **Verification:** `cd backend && pytest tests/performance/ --tb=short` 运行并输出基线数据

### U8. CI 安全扫描和迁移验证

- **Goal:** 在 CI 中集成安全扫描和数据库迁移验证
- **Requirements:** R13, R14
- **Dependencies:** none
- **Files:**
  - `.github/workflows/ci.yml` (add security scan and migration steps)
  - `.github/workflows/pr-check.yml` (add security scan and migration steps)
- **Approach:** 在 CI 中添加：1) `pip install bandit && bandit -r backend/app/ -ll` 扫描 Python 代码安全问题；2) `cd frontend && npm audit --audit-level=high` 检查 Node.js 依赖漏洞；3) `cd backend && alembic upgrade head` 在空数据库上验证迁移。安全扫描发现高危问题时 CI 失败。
- **Patterns to follow:** 现有 CI 步骤结构
- **Test scenarios:**
  - Covers AE3 (from origin): PR 中引入有漏洞依赖时 CI 报告失败
  - Covers AE5 (from origin): 新增迁移脚本时 CI 验证迁移可执行
  - bandit 扫描 Python 代码中的安全问题
  - npm audit 检查前端依赖漏洞
  - alembic upgrade head 在空数据库上成功执行
- **Verification:** 提交测试 PR，观察 CI 中安全扫描和迁移验证步骤

### U9. Agent 框架 E2E 测试

- **Goal:** 测试 Agent 框架的完整任务调度链路
- **Requirements:** R15
- **Dependencies:** U2
- **Files:**
  - `backend/tests/test_agent_framework/` (new or extend existing)
  - `backend/tests/test_agent_framework/test_e2e_citation.py` (new)
  - `backend/tests/test_agent_framework/test_e2e_content.py` (new)
- **Approach:** 测试完整链路：创建 Agent 任务→Dispatcher 分发→Agent 执行→结果写入数据库→查询结果。至少覆盖 CitationDetector（citation_detect 任务）和 ContentGenerator（content_generate 任务）。优先使用真实 LLM API Key 调用，CI 中通过环境变量注入；无 Key 时降级为 mock 模式使用预定义响应。
- **Patterns to follow:** `backend/tests/test_agent_framework/` 现有 Agent 测试模式
- **Test scenarios:**
  - CitationDetector: 创建 citation_detect 任务→执行→结果包含引用数据
  - ContentGenerator: 创建 content_generate 任务→执行→结果包含生成内容
  - 任务状态从 pending→running→completed 正确流转
  - 任务失败时状态变为 failed 并记录错误信息
  - 无 Redis 时 Agent 以 standalone 模式运行
- **Verification:** `cd backend && pytest tests/test_agent_framework/test_e2e_*.py --tb=short` 通过

### U10. 前端组件和 API 客户端测试

- **Goal:** 扩展前端测试覆盖至关键组件和新 API 客户端模块
- **Requirements:** R16, R17
- **Dependencies:** none
- **Files:**
  - `frontend/__tests__/components/` (new directory)
  - `frontend/__tests__/components/dashboard.test.tsx` (new)
  - `frontend/__tests__/components/brand-detail.test.tsx` (new)
  - `frontend/__tests__/components/diagnosis.test.tsx` (new)
  - `frontend/__tests__/components/strategy.test.tsx` (new)
  - `frontend/__tests__/components/content-editor.test.tsx` (new)
  - `frontend/__tests__/api/monitoring.test.ts` (new)
  - `frontend/__tests__/api/competitor-analysis.test.ts` (new)
  - `frontend/__tests__/api/schema-advisor.test.ts` (new)
  - `frontend/__tests__/api/trends.test.ts` (new)
  - `frontend/vitest.config.ts` (extend coverage include)
- **Approach:** 使用 React Testing Library 为 5 个关键页面组件编写渲染和交互测试。使用 vitest 为 4 个新 API 客户端模块编写单元测试（mock fetchWithAuth，验证正确的 URL 和参数传递）。扩展 vitest.config.ts 的 coverage.include 配置。
- **Patterns to follow:** `frontend/__tests__/` 现有测试模式（hooks, stores, lib）
- **Test scenarios:**
  - Dashboard 组件正确渲染评分和平台数据
  - 品牌详情页正确显示 GEO 评分维度
  - 诊断页触发诊断后显示结果
  - 策略页显示 GEO 方案和行动项
  - 内容编辑器正确渲染和提交
  - monitoring.ts API 客户端调用正确的端点
  - competitor-analysis.ts API 客户端传递正确的参数
  - schema-advisor.ts API 客户端处理响应
  - trends.ts API 客户端处理查询参数
- **Verification:** `cd frontend && npm run test:ci` 通过，覆盖率报告显示 lib/api/ 模块覆盖

### U11. 更新测试策略文档

- **Goal:** 使文档与实际项目结构和 CI 配置一致
- **Requirements:** R6
- **Dependencies:** U1, U2, U6, U8
- **Files:**
  - `docs/03-开发指南/testing.md` (update)
- **Approach:** 更新 testing.md 中的目录结构描述（test_api/, test_services/ 等按领域分类），更新 fixture 体系说明（fixtures/ 模块化 fixture），更新 CI 配置示例（包含 E2E 步骤、安全扫描、迁移验证），添加 E2E 测试编写指南。
- **Patterns to follow:** 现有 testing.md 文档风格
- **Test scenarios:**
  - Test expectation: none — documentation update
- **Verification:** 文档内容与实际项目结构一致

---

## Scope Boundaries

**Deferred for later:**

- 跨浏览器 E2E 测试（Firefox / WebKit）
- 覆盖率报告上传第三方服务（Codecov / Coveralls）
- 测试数据工厂（factory-boy / faker）
- PR 评论中显示覆盖率变化
- 生产环境监控告警集成

**Outside this product's identity:**

- 新业务功能开发
- UI/UX 改进和设计优化
- 基础设施级别的渗透测试
- 移动端适配测试

### Deferred to Follow-Up Work

- E2E 测试迁移到共享 fixture（U3/U4/U5 完成后，将独立 setup 替换为 U2 的共享 fixture）
- 性能基线设定阈值和告警（U7 采集基线后，根据数据设定合理阈值）
- 跨浏览器 E2E 扩展（稳定 Chromium 后再扩展）

---

## Risks & Dependencies

- **E2E 测试稳定性** — 依赖后端服务启动和数据库初始化，CI 环境可能比本地更不稳定。缓解：E2E 初期允许失败不阻塞，稳定后再改为阻塞。
- **LLM 依赖** — 内容生成和诊断 E2E 测试可能需要 LLM 调用。缓解：使用 mock 或较长超时，Agent E2E 使用 mock LLM。
- **测试目录迁移风险** — 旧测试可能依赖 `geo/tests/conftest.py` 的特定 fixture，迁移后可能需要调整 import 路径。缓解：逐个迁移并验证。
- **CI 时间增长** — 添加 E2E、安全扫描、迁移验证会延长 CI 运行时间。缓解：E2E 仅 Chromium，安全扫描仅高危阻断，迁移验证快速执行。

---

## Sources & Research

- 现有测试配置：`backend/pyproject.toml`, `frontend/vitest.config.ts`, `frontend/playwright.config.ts`
- CI 配置：`.github/workflows/ci.yml`, `.github/workflows/pr-check.yml`
- 测试策略文档：`docs/03-开发指南/testing.md`
- 现有 E2E 测试：`frontend/e2e/tests/` (7 files)
- 现有后端测试：`backend/tests/` (~60 files) + `geo/tests/` (17 files)
- 现有前端测试：`frontend/__tests__/` (13 files)
- Origin document: `docs/brainstorms/2026-05-31-geo-platform-next-phase-quality-requirements.md`