# FastapiAdmin 测试与可验证性审计（t3 / 只读审计）

- 审计人：测试工程师（team `fastapiadmin-audit`，task `t3`）
- 工作区：`/Users/tao/workspace/FastapiAdmin`
- 审计范围：`backend/tests`、`backend/pyproject.toml` 的 pytest 配置、`frontend/web` 的 vitest 与用例、`frontend/app`（uniapp）测试能力、仓库级 CI 配置
- 本轮约束：只读，除本报告外未修改/删除任何仓库文件；未安装依赖、未启服务、未提交 git

---

## 0. 结论摘要（TL;DR）

| 维度 | 现状 | 结论 |
| --- | --- | --- |
| 后端 pytest 用例数 | **2 个**（收集 2 / 通过 2 / 失败 0 / 跳过 0 / 退出码 0） | 能跑通，但等于没有回归网 |
| 后端被测模块 | 216 个 `.py`、28519 行 → 仅 `/monitor/health/check/` 1 个接口被断言 | 209 个 OpenAPI 操作里 1 个有断言 |
| 历史测试规模 | 2026-07-17（commit `158c14a4`）前仓库内 9 个测试文件共 **238 个 test 函数**；`.pytest_cache` 记录过 38 个文件 / **761 个 node id** | 测试能力被"重构"清空，无替代物 |
| 断言有效性 | 唯一的行为测试断言的是恒为 `True/0` 的字段 | 该用例无法失败 |
| 夹具质量 | 手写 AsyncMock Redis（未用已声明的 fakeredis）+ 模块级 `patch().start()` + 无逐用例隔离 | 夹具本身会掩盖缺陷 |
| 迁移测试 | 只覆盖 SQLite 下 `create_all ≡ metadata`；`app/alembic/versions/` **没有任何迁移文件** | `alembic upgrade` 路径零覆盖 |
| 前端 web vitest | **有真实可运行用例**：2 文件 / 10 用例 / 全通过 / 退出码 0 | 能力存在，但未进门禁 |
| uniapp | 无 vitest/jest、无 `test` script、0 个 spec | 测试能力为零 |
| CI | 仓库根 `.github/` 为空且未跟踪（`git ls-files .github` = 0）；`frontend/web/.github`、`frontend/app/.github` 不在仓库根 → **GitHub 不会运行任何 workflow** | 零门禁 |

一句话：**后端"可运行但无验证力"，前端 web 有少量真用例却无一环节强制运行，uniapp 与 CI 是空白。当前任何回归都只能靠人工点测发现。**

---

## 1. 命令与真实输出

### 1.1 后端：`cd backend && uv run pytest -q`

环境：`uv 0.12.10`（/opt/homebrew/bin/uv），Python 3.12.12，pytest 9.0.2，pytest-asyncio 1.4.0，anyio 4.12.1，`backend/.venv` 已存在。

**第一次（原样执行，未改任何环境变量）**：

```text
$ cd backend && uv run pytest -q
error: Failed to initialize cache at `/Users/tao/.cache/uv`
  Caused by: failed to open file `/Users/tao/.cache/uv/sdists-v9/.git`: Operation not permitted (os error 1)
EXIT=2
```

→ 失败原因是 `uv` 需要写 home 下的缓存目录（`~/.cache/uv`），在该沙箱内不可写，**与项目代码无关**。

**第二次（把 uv 缓存重定向到 /tmp，同一命令语义）**：

```text
$ cd backend && UV_CACHE_DIR=/tmp/uv-cache-test uv run pytest -q
..                                                                       [100%]
2 passed in 1.80s
EXIT=0
```

**详细模式（收集清单 + 结果）**：

```text
$ cd backend && UV_CACHE_DIR=/tmp/uv-cache-test uv run pytest -v
============================= test session starts ==============================
platform darwin -- Python 3.12.12, pytest-9.0.2, pluggy-1.6.0 -- .../backend/.venv/bin/python3
cachedir: .pytest_cache
rootdir: /Users/tao/workspace/FastapiAdmin/backend
configfile: pyproject.toml
plugins: anyio-4.12.1, asyncio-1.4.0
asyncio: mode=Mode.AUTO, debug=False, asyncio_default_fixture_loop_scope=function, ...
collecting ... collected 2 items

tests/test_main.py::test_check_health PASSED                             [ 50%]
tests/test_migrations.py::test_bootstrap_matches_metadata PASSED         [100%]

============================== 2 passed in 2.02s ===============================
EXIT=0
```

**真实结果汇总**：收集 2、通过 2、失败 0、跳过 0、错误 0、退出码 0、耗时 ≈1.8–2.0s。

> 后续所有复现（探针脚本）改用 `backend/.venv/bin/python` 与带 `--no-sync` 的形式，避免 `uv` 再次触碰锁文件（见 §7 环境说明）。

### 1.2 前端 web：vitest

`frontend/web` 的 `node_modules` 已就绪（vitest 4.1.7）。

```text
$ cd frontend/web && ./node_modules/.bin/vitest run

 RUN  v4.1.7 /Users/tao/workspace/FastapiAdmin/frontend/web

 ✓ src/__tests__/smoke.spec.ts (3 tests) 24ms
stdout | src/__tests__/route-invariants.spec.ts > 静态路由 — 中间层不挂组件（深度跳级的前提） > ...
[i18n] 使用默认语言: zh

 ✓ src/__tests__/route-invariants.spec.ts (7 tests) 111ms

 Test Files  2 passed (2)
      Tests  10 passed (10)
   Duration  1.05s (transform 126ms, setup 0ms, import 91ms, tests 135ms, environment 1.36s)
EXIT=0
```

**真实结果汇总**：2 个测试文件、10 个用例、全部通过、退出码 0。

### 1.3 未执行的项目（说明原因，避免"看起来跑过了"）

| 项目 | 原因 |
| --- | --- |
| `pnpm test`（web） | `pnpm` 走 npm 源/网络，本轮禁止安装依赖；已直接用 `node_modules/.bin/vitest` |
| uniapp 任何测试 | 无测试脚本、无测试依赖、无用例，无可跑对象 |
| `pytest --cov` | `pytest-cov` / `coverage` 未安装（`import pytest_cov` → `ModuleNotFoundError`），且本轮不装依赖 → **无法给出行覆盖率数字**，报告中的"覆盖缺口"由路由表、模块清单与代码路径证据推导 |
| 集成/端到端、压测 | 本轮不启服务、不连真实 MySQL/Redis |

---

## 2. 测试资产现状与夹具审计

### 2.1 分层：名义三层，实际一层

| 层 | 目录/文件 | 实际内容 |
| --- | --- | --- |
| 单元测试 | — | **不存在**（历史上有 `tests/test_unit.py` 47 个用例，已不在仓库） |
| 集成/API 测试 | `tests/test_main.py` | 1 个健康检查断言 |
| 迁移守卫 | `tests/test_migrations.py` | 1 个 `create_all ≡ metadata`（SQLite）断言 |
| 共享夹具 | `tests/conftest.py`（277 行） | session 级 TestClient + 手写 Redis mock + 自建 lifespan |

`conftest.py` 自己声明的能力（第 1–5 行）是"模块化 API 接口测试共享 fixture"，但仓库里已经**没有任何调用 `assert_route` 的用例**（`grep -rn assert_route backend/tests` 只命中定义处），也就是这套夹具的消费者全部被删除了。

### 2.2 `conftest.py` 逐项问题（带行号）

1. **导入期副作用**（L26–L46）：在 import 时创建临时 SQLite 文件并改写 `os.environ` 与全局 `settings`；甚至用 `sys.path.insert` 兜底（L17）。任何新测试文件只要 import `conftest`，全进程配置即被改写。
2. **临时库即业务库、用完不删**（L26）：`tempfile.NamedTemporaryFile(suffix=".db", delete=False).name`，每次 session 生成新文件、从不清理；`/tmp` 会持续积累。
3. **无逐用例隔离**：`_api_client` 是 session 级 TestClient（L204–208），`auth_headers` 是 session 级（L223–232），全程共享同一个 app、同一个 SQLite 库、同一个 token。没有任何 per-test 事务回滚/清库 → **用例顺序会互相影响**，且无法并行（`-n`）。
4. **测试专用 lifespan 覆盖真实 lifespan**（L173–197）：只跑 `init_db()` + 注入 mock redis，并用 `UPDATE` 把 admin 密码重置成 `admin123`。真实启动路径中的 `init_agno_tables`、`redis_connect`、`ParamsService.init_cache`、`DictDataService.init_cache`、`SchedulerUtil.init_scheduler` 全部被绕过 → 启动期回归完全无覆盖；同时"改业务表数据"这个动作本身是测试污染。
5. **用手写 AsyncMock 顶替 Redis，而 `fakeredis` 才是已声明依赖**（L53–161）：`pyproject.toml` dev 组声明了 `fakeredis>=2.21.0,<3`，但全仓库除该行外**没有任何 `import fakeredis`**。手写 mock 的语义与真实 Redis 不一致：
   - `_redis_ttl` 恒返回 3600 或 -2（L85–86）→ TTL/续期逻辑无法验证；
   - `_redis_expire` 恒返回"键是否存在"且不改 TTL（L89–90）→ 过期语义假通过；
   - `_redis_keys` 只做前缀切割，不支持 `user:*:x` 等通配（L75–78）；
   - **缺失被业务代码使用的方法**：`incr`、`eval`、`mget`、`scan_iter`、`publish`、`pubsub`、`call`（`grep -rhoE '\bredis\.[a-z_]+\(' app` 的结果与 mock 白名单对比）。
     后果 1：`LoginService._check_login_rate_limit`（`auth/service.py:155–173`）用 `redis.incr` → 拿到 `MagicMock`，`count > settings.LOGIN_RATE_LIMIT_MAX_ATTEMPTS` 抛 `TypeError` → 被 `except Exception` 吞掉并仅 warning → **登录限流在测试环境静默失效**。
     后果 2：`RedisCURD.compare_and_set` / `unlock` 依赖 `redis.eval`（`redis_crud.py:170、223`）→ `result == 1` 恒 False → **会话续期的 CAS 路径在测试里永远走失败分支**。
6. **模块级 `patch(...).start()` 永不 stop**（L161–164）：`redis.asyncio.Redis.from_url`、`SchedulerUtil.init_scheduler/shutdown` 被进程级替换，跨测试文件持续生效，且失败时不留痕迹。
7. **`assert_route` 把异常当通过**（L268–277）：

   ```python
   try:
       response = test_client.request(method, path, **kwargs)
   except Exception:
       # 后端代码异常（500 等），路由存在即不计为测试失败
       return
   ...
   assert response.status_code != 404, ...
   ```

   → 5xx/未捕获异常被计为"路由存在"，**接口挂掉也能绿**；默认断言只查 `!= 404`。当前无调用者，但它是后续补测试时最容易误用的"绿色陷阱"。
8. **完全没有异步夹具**：`pyproject.toml` 配了 `asyncio_mode = "auto"` + `asyncio_default_fixture_loop_scope = "function"`，但 `tests/` 内 `async def test_` / `async def fixture` 数量为 **0**。新增异步 DB 用例时若直接复用应用全局 `async_engine`（session 级 TestClient 在独立线程/事件循环中运行），会踩"连接绑定到另一个事件循环"的坑——现有夹具没有为这件事提供任何支撑（缺 async session/事务夹具）。
9. **pytest 配置过薄**（`pyproject.toml:155–157`）：无 `markers`、无 `--strict-markers`、无 `filterwarnings = error`、无 `timeout`、无覆盖率插件与阈值、无 `-p no:randomly`（无随机序，掩盖顺序依赖）。

### 2.3 是否依赖真实 MySQL / Redis

- **不依赖**：`conftest` 强制 `DATABASE_TYPE=sqlite` + 临时库文件，Redis 用 AsyncMock 顶替（L28–32、L141–178）。
- **代价**：
  - 生产主用 MySQL/Postgres，但测试只在 SQLite 上跑 → 方言相关代码（`information_schema` / `pg_catalog` 查询、`ON UPDATE CURRENT_TIMESTAMP`、`UNSIGNED`、`COLLATE`、JSON 列、`server_default` 渲染）**零覆盖**；
  - `app/modules/generator/gencode/crud.py:178–243` 的 MySQL/Postgres 物理表分页 SQL 分支只在真实方言下成立，测试永不会执行；
  - 真实 Redis 的 Lua 脚本（`eval`）、`incr`、SCAN 语义无覆盖（见 §2.2.5）。

### 2.4 迁移测试的有效性

`tests/test_migrations.py` 两个守卫确实有意义（守卫一：布局阶段 `app/alembic/versions/` 不得新增文件；守卫二：显式 `autogenerate` 必须零产出），但存在三个边界：

1. **`app/alembic/versions/` 里只有 `__init__.py`，没有任何迁移文件**。也就是说项目声明的"双轨制"（新装走 `create_all` + `stamp head`，存量走 `alembic upgrade`）目前只剩单轨：`alembic upgrade head` 无版本可升。**迁移链本身的正确性（upgrade/downgrade、数据回填、`stamp` 基线）100% 无测试**，而 `app/scripts/initialize.py:61–123` 里对空 `alembic_version` 的处理（清空、提示、跳过 stamp）也只是被间接启动过一次。
2. **只覆盖 SQLite 方言**：注释里已承认"MySQL 方言的 DDL 渲染差异由 dev 启动时的自动迁移承担"——而 dev 启动只发生在开发者本机，CI/无本地启动场景下无人守。
3. **守卫二有写仓库副作用**：`command.revision(cfg, autogenerate=True)` 会把产物写进 `app/alembic/versions/` 再删除（L31–34）。这是本次唯一会写仓库的测试路径；若未来在只读检出或并行执行（`pytest -n`）中运行，会互相打架或留下残留文件。

### 2.5 前端 web 的 vitest：**真有可运行用例** ✅

- 配置：`frontend/web/vitest.config.ts`，`environment: jsdom`、`globals: true`、`include: ["src/**/*.{test,spec}.{ts,js}"]`，并同步了 `__APP_INFO__` 与 `@/` 等别名（配置质量不错）。
- 用例 1 `src/__tests__/smoke.spec.ts`（3 例）：断言 `MenuTypeEnum` 四个取值、代码生成枚举模块可导入。属于**冒烟级别**，价值低但零成本。
- 用例 2 `src/__tests__/route-invariants.spec.ts`（7 例）：把"有 children 的路由记录不得挂 component"（Vue Router 深度跳级 + 单层 KeepAlive 的前提）固化成断言，并校验后端 `backend/sql/sys_menu.json` 中目录节点不得配 `component_path`。**这是全仓库质量最高的一组测试**（带历史回归说明、有明确失败信息）。
- 缺口：
  - `package.json` 有 `"test": "vitest run"`、`SKILL.md` 也写了 `pnpm test`，但**没有任何环节会执行它**（CI 不跑、husky 的 `pre-commit` 只跑 `lint-staged`）；
  - **无覆盖率能力**：未安装 `@vitest/coverage-v8` 等 provider（`node_modules/@vitest/` 不存在），`vitest --coverage` 无法产出数据；
  - `@vue/test-utils`、`jsdom` 已安装，但 `src/` 中**没有任何组件挂载测试**（`grep -rn "@vue/test-utils" src/` 无命中）→ 组件/交互层零覆盖；
  - `route-invariants.spec.ts` 依赖仓库相对路径读取后端 `sql/sys_menu.json`（三个候选路径兜底）→ 前端用例与后端数据文件形成隐式耦合，脱离仓库根目录单独签出 web 会失败（首例带清晰报错，属可接受的取舍，但需要写进交接文档）。

### 2.6 uniapp（`frontend/app`）：测试能力为零

- `package.json` 无 `test` script，无 vitest/jest/@vue/test-utils（只有 `type-check`、`lint`）。
- 全目录 0 个 `*.spec.*` / `*.test.*` 文件。
- 自带的 `.github/workflows/ci.yml` 里的三步"测试"是：

  ```yaml
  - name: Test H5 dev mode
    shell: bash
    run: |
      timeout 30s pnpm dev:h5 || true
      echo "✅ H5 dev mode test completed"
  ```

  `|| true` + 仅打印 ✅ → **无论开发服务器是否启动成功都返回成功**，不构成任何验证（且 `windows-latest` + `shell: bash` 下 `timeout` 行为同样可疑）。

### 2.7 CI 覆盖：仓库级 **0**

- 仓库根 `.github/workflows/` **是空目录**，且 `git ls-files .github` 返回 0 → 未被跟踪。GitHub Actions **不会在本仓库运行任何 workflow**。
- `frontend/web/.github/workflows/ci.yml`：内容认真（`pnpm install --frozen-lockfile` → `type-check` → `lint` → `build:dev`），但 (a) 目录不在仓库根，不会被触发；(b) 即使被触发，也**只跑 type-check/lint/build，不跑 `vitest`**。
- `frontend/app/.github/workflows/ci.yml`：同上，且"测试"步骤是 `|| true` 空跑。
- 后端：**没有任何 workflow**，`pytest` 全靠人手敲。
- `deploy.sh` / `deploy-artifacts.sh` 只做打包与发布，不跑测试（仅在排除列表里提到 `.pytest_cache`）。
- 仓库的成文约定与实现不符：`SKILL.md:57/67/121` 要求"后端 `uv run pytest`；前端 `pnpm ts:check`、`pnpm lint`、`pnpm test`"，实际无任何自动执行点。

---

## 3. 覆盖缺口清单（含证据）

### 3.1 宏观证据

| 证据 | 数值 |
| --- | --- |
| 后端 Python 文件 / 行数（`backend/app`） | 216 个 / 28519 行 |
| OpenAPI 路径 / 操作 | 205 / 209（`app.openapi()` 实测；GET 79、POST 63、PUT 26、DELETE 30、PATCH 11） |
| `AuthPermission(...)` 调用 | 187 处（另有类定义等共 212 行出现该标识符） |
| 现有 pytest 用例 | 2 |
| 有断言的接口 | 1（`/monitor/health/check/`） |
| 历史用例数（`158c14a4^`，2026-07-17） | 238（`test_api_module_system.py` 92、`platform` 54、`task` 39、`monitor` 19、`generator` 12、`example` 9、`ai` 6、`common` 5、`test_main` 2） |
| 历史 node id（`.pytest_cache/v/cache/nodeids`） | 761 个 / 38 个文件（`test_codegen.py` 99、`test_api_module_system.py` 95、`test_api_module_platform.py` 90、`test_api_system.py` 72、`test_api_module_plugin.py` 58、`test_unit.py` 47、`test_permission_logic.py` 28、`test_integration.py` 20、`test_data_scope.py` 5 …） |
| `.pytest_cache/v/cache/lastfailed`（2026-09-06） | 120 个失败 id（含 `test_permission_logic.py` 21、`test_api_module_system.py` 21、`test_integration.py` 20） |
| 删除轨迹 | `158c14a4`(2026-07-17) 删 7 个模块化 API 测试文件；`d470c7eb`(2026-09-06) 删 `test_api_module_system.py`；`tests/__pycache__` 还残留 `test_sse_once/test_api_system/test_routes/test_architecture` 的 `.pyc` |

> 结论：**测试不是"从未有"，而是被两次重构清空且没有替代物**；`.pytest_cache` 显示本地曾存在 `test_codegen.py`(99)、`test_permission_logic.py`(28)、`test_data_scope.py`(5) 等成套用例，且当时已有 120 条失败——这些用例本身也需要重建而非"恢复"。

### 3.2 按模块的缺口（附只读探针实测）

探针脚本：`/tmp/probe_tests.py`（临时目录，不落仓库；`SECRET_KEY`/SQLite 环境变量隔离，不连真实 MySQL/Redis）。实测输出节选：

```text
resolve_condition('like','a')            : OK -> ['probe_tbl.id LIKE :id_1']
resolve_condition('in', [])              : OK -> ['false']                      # 空集合 → 恒假，合理
resolve_condition('between',[1])         : OK -> []                             # 长度≠2 → 静默丢弃条件
resolve_condition('date','2026-10-04')   : OK -> ['probe_tbl.id >= :id_1', 'probe_tbl.id < :id_1']
resolve_condition('month','2026-12')     : OK -> ['probe_tbl.id >= :id_1', 'probe_tbl.id < :id_1']
resolve_condition('date','not-a-date')   : ValueError: time data 'not-a-date' does not match format '%Y-%m-%d'
resolve_condition('unknown_op','x')      : OK -> []                             # 未知算子 → 无 WHERE，结果被静默放大
build_conditions unknown key             : AttributeError: type object 'ProbeModel' has no attribute 'no_such_col'
JWT tampered 'a.b.c'                     : CustomException: 无效认证,请重新登录
JWT empty                                : CustomException: 认证不存在,请重新登录
PwdUtil.hash/verify                      : OK -> True / verify wrong -> False
camel/snake 转换、bytes2human            : OK -> 'UserName' / 'user_name' / '1.0GB'
get_child_recursion(1, {1:[2],2:[1]})    : RecursionError: maximum recursion depth exceeded   # 无环检测
```

| 模块 | 关键代码 | 缺口与风险（有据） |
| --- | --- | --- |
| 认证 entry | `app/core/dependencies.py:43–189`（`get_current_user` / `_authenticate`） | **11 条 401 抛出点（`grep -c "status_code=401"` = 11）全部无测试**：空 token、`Bearer` 后为空、`is_refresh` 令牌、缺 `session_id`、session 不存在、session 数据不完整、超最大存活时长、缺 `user_name`、`user_status==1` 停用、缺 `user_id`、每请求查库确认用户存在且未删除；滑动续期（TTL==-1 兜底、`SESSION_MAX_LIFETIME_SECONDS` 绝对上限、双键同时续期）同样无测试 |
| RBAC 接口权限 | `app/core/dependencies.py:192–234`（`AuthPermission`） | 超管旁路（L216）、`permissions` 为空即放行（L219–220）、`*` / `*:*:*` 通配放行（L222）三条"放行"逻辑与"无权限 403"分支均无测试。187 处调用 ↔ 0 个用例；任何一处语义翻转都会静默放开或锁死全部接口 |
| 数据权限 | `app/core/permission.py` 全文；`app/utils/common_util.py:162–196` | 3 种 `data_scope`（SELF/DEPT_AND_CHILD/ALL）、`created_by.dept_id` 关系判定、`UserModel` 特例、`hasattr(model,"created_id")` 缺失模型、部门树异常时"降级为本部门"（L109–117）全部无测试；`get_child_recursion` 对 `parent_id` 成环会 `RecursionError`（探针实测），当前被 `except Exception` 兜成降级+warning → **权限范围静默收窄且只留一条 warning** |
| 登录/防爆破 | `auth/service.py:122–270`（`LoginService`）、`:540–649`（`CaptchaService`） | 用户不存在 / 密码错 / 停用 三类失败与登录日志写入、限流窗口、验证码开关、`ENVIRONMENT != PROD` 时的 docs Referer 豁免均无测试。两处已可见问题：① 限流对 `127.0.0.1/unknown/localhost` 直接 return（L161–162）→ 反代/本机部署形同不限流；② "用户不存在"与"账号或密码错误"文案不同（L217/L231）→ 用户名枚举 oracle |
| 会话与令牌 | `auth/service.py:349–539`（`create_token`/`refresh_token`/`logout`）、`core/redis_crud.py:147–245` | refresh 轮换、`compare_and_set` CAS 语义、`lock/unlock` Lua 原子性、`logout` 需同时清 `access_token:{sid}` / `refresh_token:{sid}` / `user_session:{sid}` 三键（`service.py:531–533`），全部无测试；且现有 Redis mock 缺失 `eval` → CAS 路径在测试中恒失败（§2.2.5） |
| 分页/查询封装 | `core/base_crud.py:104–182`（`count/get_list/page`）、`:303–387`（`_build_conditions/_resolve_condition/_parse_order`）、`utils/common_util.py:87–126`（`search_to_dict`） | `page()` 的 `total/has_next/page_no(=offset//limit+1)/limit=0`、软删 `is_deleted` 自动过滤与 `include_deleted`、`load_columns`/`preload` 与 COUNT 拆分的等价性，全部无测试；异常一律被包装成 `CustomException("分页查询失败: ...")`（L181–182）→ 非法 `date`（ValueError）、未知排序字段（AttributeError）、未知 search key（AttributeError）都退化成同一条"分页失败"，**无法区分 4xx 与 500**；未知算子静默返回空条件列表 → 查询范围被放大却无报错。`search_to_dict` 的 `_start/_end` 合并、`_time` 列表、`json_schema_extra={"q": ...}` 打包是所有列表接口过滤语义的唯一入口，无测试 |
| 代码生成器 | `gencode/service.py:375–449`（`create_table`）、`gencode/crud.py:148–350`（系统表分页 / `execute_sql`）、`gencode/gen_util.py`（309 行纯函数）、`jinja2_template_util.py`（759 行模板） | ① DDL 白名单：`has_create = any(isinstance(s, Create))` + 禁用 `(Delete, Drop, Insert, TruncateTable, Update)`；sqlglot 的 `Create` 同时涵盖 `CREATE VIEW/INDEX/DATABASE`，**会被放行并执行**；`Alter` 用字符串包含判定（`"SET " not in upper` 等）脆弱（合法的 `ON DELETE SET NULL` 反被拒）。② 物理表列表查询按方言走 `information_schema`/`pg_catalog`（L178–243），SQLite 测试永不触达。③ `GenUtils.get_db_type/get_column_length/split_column_type/arrays_contains/replace_first/convert_class_name` 等纯函数边界（`tinyint(1)`→boolean、`int UNSIGNED`、`COLLATE`、`integer[]`、`timestamp without time zone`、`decimal(10,2)`、空括号）无测试。④ 模板渲染产物语法正确性无测试 |
| 操作日志与脱敏 | `core/router_class.py:33–40`（`_redact_sensitive`）、`:59–134`（`OperationLogRoute`） | 敏感键递归脱敏（含请求体表单、响应体 → token 不得明文入库）、>2000 字符截断为"请求参数过长"、非 JSON 体兜底、后台写库失败仅告警，均无测试。这是"日志泄露 token/密码"的直接防线 |
| 中间件/异常 | `core/middlewares.py`、`core/exceptions.py`、`common/response.py` | 限流、XSS、请求 ID、`CustomException → ResponseSchema` 映射（`success/code/msg/status_code` 契约）、`ErrorResponse` 语义无测试 |
| SSE / WebSocket | `core/sse_manager.py`、`dependencies.py:52–87`（`get_websocket_token` 子协议解析、`websocket_authenticate`） | 无测试（`tests/__pycache__/test_sse_once.*.pyc` 说明曾经有过）；WS 鉴权、子协议回显、`?token=` 兜底都属于易回归点 |
| AI 会话 / 存储 / 任务 | `modules/ai/chat`（agno）、`modules/task/storage/*`（S3/OBS/OSS/COS/SFTP）、`modules/task/cronjob`、`core/ap_scheduler.py`（609 行） | 0 测试；外部 SDK（`boto3`/`esdk-obs-python`/`alibabacloud-oss-v2`/`cos-python-sdk-v5`/`paramiko`）全部无 mock 边界测试 |
| OAuth | `auth/oauth_service.py`（479 行，github/gitee/wechat/qq 换 token 与取 profile） | 0 测试（需 HTTP mock）；state 校验与前端跳转兜底无测试 |
| 迁移/schema | `tests/test_migrations.py`、`app/scripts/initialize.py:50–123` | 见 §2.4：无迁移文件、仅 SQLite、无 upgrade/downgrade 链路测试 |
| 前端 web | `frontend/web/src/**` | 覆盖仅限枚举与路由结构；`store`（pinia）、`utils`（request/axios 拦截器、storage、crypto）、`router` 动态路由加载（`route-loader.ts`）、权限指令、组件均无测试；无组件挂载测试 |
| uniapp | `frontend/app/src/**` | 0 测试、0 测试基建 |

### 3.3 断言有效性问题（最容易被忽略的一条）

唯一的行为测试 `tests/test_main.py`：

```python
response = test_client.get("/monitor/health/check/")
assert response.status_code == 200
assert body["success"] is True
assert body["code"] == 0
```

而 `app/modules/monitor/health/controller.py`：

```python
info = await HealthService.collect(redis)
ok = info.db_status == 1 and info.redis_status == 1
return SuccessResponse(data=info, msg=f"系统健康-{settings.VERSION}" if ok else f"服务异常-{settings.VERSION}")
```

`SuccessResponse` 的 `success`/`code` 恒为 `True`/`0`（`app/common/response.py:29–42`）。也就是说该用例**即使 DB 与 Redis 全部探活失败也会通过**——它只验证了路由存在 + JSON 形状，没有验证 `data.db_status/redis_status`，也没验证 `msg`。全仓唯一的行为断言是**不可失败断言**。

---

## 4. 最该先补的 10 个测试点（含验证方式）

排序原则：安全相关（越权/凭据）> 影响全部接口的公共封装 > 不可逆操作（DDL/迁移）> 业务模块。

---

### T1. 接口权限矩阵（`AuthPermission`）与认证失败矩阵 ✅最高优先

- **为什么**：187 处 `AuthPermission(...)` 调用、0 个用例；三条放行分支（超管 / 空权限 / 通配符）中任何一条回归都等于全站越权。
- **验证方式**
  - 新增 `backend/tests/test_auth_permission.py`（纯单元，无 DB）：
    ```python
    @pytest.mark.parametrize(("is_superuser", "user_perms", "required", "expect"), [
        (True,  [],                 ["system:user:create"], "allow"),   # 超管旁路
        (False, [],                 ["system:user:create"], "allow"),   # self.permissions 为空 → 放行
        (False, ["*"],              ["system:user:create"], "allow"),
        (False, ["*:*:*"],          ["system:user:create"], "allow"),
        (False, ["a:b:c"],          ["system:user:create"], "403-errcode"),  # 无权限分支
        (False, [],                 ["x:y:z", "a:b:c"],     "allow"),
    ])
    async def test_matrix(...):
        with_403 = pytest.raises(CustomException)
    ```
  - 组装 `AuthSchema(user=CoreUserSchema(id=1, is_superuser=..., ...), permissions=user_perms)` 直接 `await AuthPermission(required)(auth=...)`；对 403 分支断言 `code == RET.NO_PERMISSION.code`（而非只有 HTTP 状态码）。
  - 接口层（用现有 `test_client` 夹具）对任一受保护接口断言四类 401：无 `Authorization`、`Bearer` 空、随机串、签名正确但 session 已删（先 `logout` 再请求）。
- **验收**：T1 里"无权限 → 403"与"超管 → 200"两类用例必须同时存在，防止只测放行不测拦截。

### T2. 数据权限 `Permission` 的数据范围矩阵

- **为什么**：这是"用户 A 看到用户 B 数据"的唯一闸门，当前零覆盖；`created_id`/`dept_id`/`created_by.dept_id` 三条取值路径 + 降级逻辑都很绕。
- **验证方式**
  - 新增 `backend/tests/test_data_scope.py`，用内存 SQLite（`create_async_engine("sqlite+aiosqlite:///:memory:")`，独立于 conftest 的全局库）建 3 部门（1 → 2 → 3）+ 3 用户 + 若干带 `created_id` 的示例行。
  - 对 `Permission(model, auth, db)._permission_condition()` 断言生成的条件类别，而不是断言数据量：
    ```python
    cond = await Permission(UserModel, auth, db)._permission_condition()
    assert cond is None                                  # is_superuser 或 DATA_SCOPE_ALL
    sql = str(cond.compile(compile_kwargs={"literal_binds": True}))
    assert "dept_id IN (1, 2, 3)" in sql or "created_id = 2" in sql
    ```
  - 必测分支：`data_scope=ALL → None`、`DEPT_AND_CHILD → dept 子树包含自身`、`SELF → created_id = 当前用户`、模型无 `created_id` → `None`、`_load_dept_children` 抛异常 → 降级为"仅本部门"且捕获到 `logger.warning`（用 `caplog`）。
  - 顺带固化 §3.2 的环检测缺陷：构造 `parent_id` 自引用（`{1: [2], 2: [1]}`），断言**期望行为**是"不抛 `RecursionError`、返回有限集合"——当前会失败，正好作为修复工单的验收依据。
- **验收**：每条 `data_scope` 至少 1 个正例 + 1 个反例；环用例先标 `xfail(strict=True)` 并附 issue 说明，修复后转正。

### T3. 会话令牌全生命周期（create / refresh / logout / 滑动续期）

- **为什么**：令牌是唯一凭据；`compare_and_set`（CAS）+ 双键续期 + 绝对存活上限都是"并发下悄悄失效"的高危逻辑，且现有 Redis mock 缺失 `eval` 使它**不可能被测到**。
- **验证方式**
  - 先改夹具（这是本轮报告给出的必要前置）：把 `conftest` 的手写 `AsyncMock` 换成 `fakeredis.asyncio.FakeRedis`（依赖已在 dev 组声明），或至少补齐 `incr/eval/mget/scan_iter/publish/pubsub/call` 的语义实现。
  - 新增 `backend/tests/test_session_lifecycle.py`：
    - `create_token` 后断言 Redis 中同时存在 `access_token:{sid}` / `refresh_token:{sid}` / `user_session:{sid}` 三键且 TTL ≈ 配置值；
    - `refresh_token` 后断言旧 session 失效（返回 401）、`is_refresh` 令牌不能直接访问业务接口；
    - `logout` 后断言三个键都被删除、原 token 请求返回 401（`service.py:531–533` 少删一个键即为漏登出）；
    - CAS：写入 key→A 后并发/串行地先改成 B，再调 `compare_and_set(key, expected="A", ...)`，断言返回 `False` 且值仍为 B；
    - 滑动续期：`TOKEN_SLIDING_EXPIRE=True` 时把 session 值里的 `created_at` 设到 `SESSION_MAX_LIFETIME_SECONDS` 之前，断言请求被拒且键被删除（覆盖 `dependencies.py:125–156` 的三条分支）。
- **验收**：CAS 的成功与失败两条路径都必须有断言（现在测试环境恒为失败）。

### T4. 登录认证与防爆破（`LoginService.authenticate_user`）

- **为什么**：最直接的攻击面；且现有夹具**必然测不到限流**（`incr` 缺失 + 127.0.0.1 跳过）。
- **验证方式**
  - 新增 `backend/tests/test_login.py`（沿用 `test_client`）：
    - 三类失败：不存在用户、错误密码、`status=1` 停用 → 断言 HTTP 200 + 业务错误码 + `msg` 文案；同时断言 `LoginLogModel` 落库（`status=2` 与对应 `msg`）——这同时覆盖了 `_write_login_log`。
    - 成功登录：断言返回 `access_token`、Redis 有 session、`last_login` 被更新。
    - 限流：用 fakeredis + `X-Forwarded-For`（或 monkeypatch `get_client_ip` 返回 `10.0.0.9`）连续请求 `LOGIN_RATE_LIMIT_MAX_ATTEMPTS + 1` 次，断言第 N+1 次被拒；**并单独写一条用例固化"`127.0.0.1/unknown` 跳过限流"的既有行为**，让这个安全取舍显式可见。
    - 验证码：`CAPTCHA_ENABLE=True` 时缺 `captcha_key` → 明确报错；`ENVIRONMENT=PROD` 时 `Referer: .../docs` 不再豁免。
- **验收**：限流用例必须在"非本机 IP"下运行，否则等于没测。

### T5. `CRUDBase.page()` 的分页/软删语义

- **为什么**：所有列表接口都走它；`total/has_next/page_no` 算错会导致前端分页器错乱，软删过滤算错会导致数据泄漏。
- **验证方式**
  - 新增 `backend/tests/test_crud_page.py`：独立内存 SQLite + 一个测试模型（同时含 `is_deleted`、`created_id`），插入 25 行（其中 3 行 `is_deleted=True`）。
  - 断言矩阵：
    | 入参 | 期望 |
    | --- | --- |
    | `offset=0, limit=10` | `total=22, page_no=1, page_size=10, has_next=True, len(items)=10` |
    | `offset=20, limit=10` | `page_no=3, has_next=False, len(items)=2` |
    | `offset=25, limit=10` | `items=[]`, `has_next=False` |
    | `limit=0` | 不抛 `ZeroDivisionError`，`page_size` 回落到 10 |
    | `include_deleted=True` | `total=25` |
    | `page()` 与 `get_list()` 同参 | 行集合一致（COUNT/数据两趟查询的条件等价） |
    | `order_by=[{"id":"desc"}]` / 多字段 | 顺序与预期一致 |
  - 断言 `page()` 抛出的异常类型是 `CustomException` 且 `msg` 可区分（不要只断言"抛异常"）。
- **验收**：`limit=0` 与多字段排序必须入用例（前者是边界除零，后者是 `_parse_order` 的循环语义）。

### T6. 查询算子与查询参数封装（含非法输入的错误语义）

- **为什么**：决定了所有列表接口的过滤语义与错误码；探针已证实**未知算子静默丢弃条件**、非法日期抛裸 `ValueError` 后被包装成统一的"分页查询失败"。
- **验证方式**
  - 新增 `backend/tests/test_query_operators.py`，参数化 `CRUDBase._resolve_condition`（纯静态方法，零依赖）：
    | 输入 | 期望 |
    | --- | --- |
    | `("None", None)` / `("not None", None)` | `IS NULL` / `IS NOT NULL`，不依赖 val |
    | `("like", "a")` | `LIKE '%a%'` |
    | `("in", [])` | `false()`（恒假，不得退化为"无条件"） |
    | `("between", [1])` | 长度非法 → 明确行为（当前 `[]`，建议改为拒绝） |
    | `("date", "2026-10-04")` | `>= 00:00` 且 `< 次日 00:00` |
    | `("month", "2026-12")` | 跨年到次年 1 月 1 日 |
    | `("date", "not-a-date")` | **期望** `CustomException`（清晰 4xx），当前 `ValueError` |
    | `("unknown_op", "x")` | **期望** 抛错或忽略但记录告警，当前静默返回 `[]` |
    | `_OPERATOR_MAP` 8 个比较符 | `attr.__eq__/__ne__/__gt__/...` 映射正确 |
  - 同一文件覆盖 `search_to_dict`：`xxx_start`/`xxx_end` 合并为 `("between", [s, e])`、`xxx_time` 列表合并、`json_schema_extra={"q": "like"}` 打包、`None` 值被排除。
- **验收**：非法日期这条用例的断言应指向"统一 `CustomException`"，把"500 类错误伪装成业务错误"的问题钉住。

### T7. 代码生成器 `create_table` 的 DDL 白名单（安全）

- **为什么**：这是"用户提交 SQL → 服务端执行 DDL"的路径，白名单一旦漏判就是任意建表/建视图/建索引；当前 0 测试。
- **验证方式**
  - 新增 `backend/tests/test_codegen_create_table.py`：不连库，`monkeypatch` 掉 `GenTableCRUD.execute_sql`（记录被执行的语句）、`check_table_exists`（恒 False）、`get_gen_table_by_name`（恒 None），直接 `await GenCodeService(auth, db).create_table(sql)`。
    | SQL 输入 | 期望 |
    | --- | --- |
    | `CREATE TABLE t1 (id INT PRIMARY KEY)` | 通过，且执行语句集合 == {该 DDL} |
    | `DROP TABLE t1` / `INSERT` / `UPDATE` / `DELETE` / `TRUNCATE` | 拒绝，`msg` 命中"禁止的关键操作" |
    | `CREATE TABLE t1 (...); DROP TABLE t1;` | 整体拒绝（破坏性语句检测在 has_create 之后仍生效） |
    | `CREATE TABLE t1 (...); ALTER TABLE t1 ADD CONSTRAINT fk FOREIGN KEY (a) REFERENCES b(id);` | 通过 |
    | `ALTER TABLE t1 DROP COLUMN c;` | 拒绝 |
    | `ALTER TABLE t1 ADD CONSTRAINT fk FOREIGN KEY (a) REFERENCES b(id) ON DELETE SET NULL;` | **当前会误拒**（含 `SET `）→ 用例固化预期行为，暴露字符串判定缺陷 |
    | `CREATE VIEW v AS SELECT 1` / `CREATE INDEX i ON t1(id)` | **当前会被放行** → 用例断言必须先确定安全预期（建议归为拒绝），作为加固依据 |
    | 表已存在 / 已在代码生成模块存在 | 拒绝，`msg` 区分两种原因 |
  - 断言"未执行的语句不被执行"（例如含 DROP 的多语句输入下，`execute_sql` 调用次数为 0）。
- **验收**：`CREATE VIEW`/`CREATE INDEX` 与 `ON DELETE SET NULL` 三条必须显式入用例，否则等于没有白名单。

### T8. 代码生成元数据纯函数 + 模板渲染

- **为什么**：`gen_util.py`（309 行）+ `jinja2_template_util.py`（759 行）是"生成代码给用户跑"的核心，边界输入容易产出语法错误的 Python；纯函数测试成本极低（毫秒级、零依赖）。
- **验证方式**
  - 新增 `backend/tests/test_gen_util.py`，参数化：
    - `get_db_type`：`tinyint(1)`→`boolean`、`tinyint`→`tinyint`、`int UNSIGNED`→`int`、`varchar(64) COLLATE utf8mb4_bin`→`varchar`、`integer[]`/`ARRAY[INTEGER]`→`array`、`timestamp without time zone`→`timestamp`、`""`→`""`；
    - `get_column_length`：`varchar(255)`→255、`decimal(10,2)`→10、`numeric(20, 0)`→20、无括号→0、`varchar()`→0、`text`→0；
    - `split_column_type`：`decimal(10,2)`→`["10","2"]`、无括号→`[]`；
    - `arrays_contains`：大小写不敏感、`COLLATE`/`UNSIGNED` 修饰剥离、`TINYINT(1)` 与 `tinyint` 的基类型比较；
    - `replace_first` / `convert_class_name`（`sys_user`→`SysUser`）；
    - `StringUtil`（`app/utils/string_util.py`）的同族转换。
  - 模板：对 `jinja2_template_util` 用最小 `GenTableSchema` 渲染一轮，断言 `compile(rendered, "<gen>", "exec")` 不抛 `SyntaxError`（比逐字快照更稳，能挡住"生成的代码是坏的"这类真实事故）；再对 1–2 个关键模板做字符级快照防意外改动。
- **验收**：模板用例的断言必须是"能编译"而非"包含某段字符串"。

### T9. 操作日志脱敏与响应契约

- **为什么**：这是阻止"密码/token 明文入库"的唯一防线；`_redact_sensitive` 是纯函数，测试成本极低。
- **验证方式**
  - 新增 `backend/tests/test_operation_log.py`：
    - 纯单元（无 DB）：`_redact_sensitive({"Password": "x", "nested": {"access_token": "y"}, "list": [{"client_secret": "z"}]})` → 三个值均为 `"******"`，非敏感键原样保留；大小写混写（`Authorization`、`SECRET_KEY`）命中断言。
    - 路由层：`test_client` 打 `/system/auth/login`（含密码表单）与一个返回 token 的接口，断言 `OperationLogModel.request_payload` 不含明文密码、`response_json` 不含 `access_token` 明文；
    - 长度：构造 > 2000 字符的请求体，断言 `request_payload == "请求参数过长"`；
    - 非 JSON：`Content-Type: text/plain` 请求，断言记录走 `errors="ignore"` 兜底且不抛异常；
    - 写库失败：`monkeypatch` 使 `async_db_session` 抛异常，断言响应仍为 200（日志失败不得影响主流程）。
- **验收**：`Authorization`/`access_token` 两个键必须各有一条"明文不得出现"的负向断言。

### T10. 迁移与 schema 一致性守卫升级

- **为什么**：迁移漂移是"本地好、线上崩"的典型来源；现有守卫只覆盖 SQLite，且 `versions/` 为空使 upgrade 路径完全没被验证。
- **验证方式**（扩展现有 `backend/tests/test_migrations.py`，不新建平行文件）
  - 守卫 1/2 保留，新增守卫 3：断言 `ALEMBIC_VERSION_DIR` 的实际状态与启动路径一致——当目录为空时，断言 `init_db` 走的确实是"create_all（不 stamp）"分支（可断言 `alembic_version` 表不存在或为空 + 捕获对应日志），避免未来悄悄变成"空库被 stamp head"。
  - 守卫 4（关键）：把一致性检查从 SQLite 扩到 MySQL/Postgres。**注意：`MigrationContext.configure(dialect_name="mysql")` + `compare_metadata` 无法离线使用**（本次实测三种方言均直接 `AssertionError`，因为 `compare_metadata` 需要真实 `Connection` 做反射），所以分两条腿：
    1. **离线多方言 DDL 渲染**（无需数据库，可进常规 CI）：先 `from app import create_app; create_app()` 把全部模型 import 进来（否则 `UserModel.__table__` 会因 `sys_user_roles → sys_role` 外键找不到表而抛 `NoReferencedTableError`），然后逐方言编译：
       ```python
       from sqlalchemy.dialects import mysql, postgresql
       from sqlalchemy.schema import CreateTable
       from app.core.base_model import MappedBase          # 实测 29 张表

       for name, dialect in (("mysql", mysql.dialect()), ("postgresql", postgresql.dialect())):
           for table_name, table in MappedBase.metadata.tables.items():
               ddl = str(CreateTable(table).compile(dialect=dialect))   # 实测：sys_user → 1586/1199 字符
               assert ddl.strip(), f"{name}.{table_name} 渲染为空"
               # 断言口径二选一：① 关键表 DDL 字符级快照；② 规则断言（如禁止 "VARCHAR" 无长度、
               # 禁止 MySQL 专有修饰出现在 Postgres 渲染结果里），避免快照噪音过大。
       ```
       用途：挡住"某字段在 MySQL 下渲染出非法/退化 DDL（如 `UNSIGNED`、`ON UPDATE`、`COLLATE`、无长度 `VARCHAR`）"这类只在方言上暴露的问题。
    2. **真连接等价检查**（`@pytest.mark.integration`，按需开启，仓库已有 `docker/mysql` compose）：连上真实 MySQL/Postgres 后
       ```python
       with engine.connect() as conn:
           diffs = compare_metadata(MigrationContext.configure(conn), MappedBase.metadata)
           assert diffs == [], diffs          # 实测 SQLite 真连接下为 0 diff
       ```
  - 守卫 5：让迁移用例在**只读检出**下也能跑——把 `command.revision(autogenerate=True)` 的写法改为在临时目录（`tmp_path` + 覆盖 `script_location`）中执行，消除测试写仓库的副作用（当前 `test_migrations.py:31–34` 会向 `app/alembic/versions/` 写文件再删）。
  - 若后续补回迁移文件：新增一条"`alembic upgrade head` 从空库升到 head 后，`compare_metadata` 零 diff"的端到端用例（这是当前最大盲区）。
- **验收**：多方言断言必须真编译一次 DDL（不得只 mock `CreateTable`），且**不要**使用 `MigrationContext.configure(dialect_name=...)` 冒充等价检查；真连接等价检查须放在有 DB 的 job / 本地显式开启；迁移用例执行后 `git status` 必须保持干净。

---

## 5. 落地顺序建议（3 个批次）

| 批次 | 内容 | 目的 | 门禁 |
| --- | --- | --- | --- |
| **第 1 批（≤2 天）** | T1、T6、T8、T9（纯函数/纯单元为主，不需要新夹具）+ 重建 `pytest-cov` 与覆盖率基线 | 用最低成本拿到"安全 + 公共封装"的回归网 | 后端 `uv run pytest` 纳入 CI，覆盖率设"不回退"而非固定阈值 |
| **第 2 批（3–5 天）** | 夹具改造（fakeredis 替换手写 mock、`assert_route` 改为对 5xx 失败、增加 async session/事务夹具、逐用例隔离）+ T3、T4、T5、T2 | 让"测试能失败"，覆盖凭据与数据权限 | 新增 async 夹具后开启 `filterwarnings = error`；`pytest -q --strict-markers` |
| **第 3 批（1–2 周）** | T7、T10 + 启动路径（真实 lifespan）冒烟 + 前端 vitest 扩展（request 拦截器、storage、route-loader）+ uniapp 最小 vitest 接入 | 覆盖不可逆操作与真实启动链 | 仓库根新建 `.github/workflows/ci.yml`：backend（ruff + pytest）+ web（type-check + lint + **vitest run**）+ app（type-check + lint） |

配套的"制度性"修复（与测试点同等重要，均属零成本配置）：

1. **在仓库根建 CI**（当前为空目录，`git ls-files .github` = 0）：把 `frontend/web/.github/workflows/ci.yml` 的内容上提并补 `pnpm test`；后端加 `uv sync --group dev && uv run pytest -q`。
2. **保留 `frontend/web` 的 vitest 并扩面**：它已有 10 个真用例，只要进 CI 就能立刻防住路由结构回归。
3. **修正 `assert_route`**（`backend/tests/conftest.py:240–277`）：`except Exception` 应转为失败（或改为显式允许 5xx 白名单），默认断言从"`!= 404`"升级为"status < 500"。
4. **把 `fakeredis` 用起来或从 dev 组删掉**：声明了却不用，是明确的误导信号。
5. **`SKILL.md` 与实现对齐**：文档要求 `pnpm test` / `uv run pytest`，实际无执行点；要么加门禁，要么改文档。

---

## 6. 附：本次审计用到的只读命令

```bash
# 1) 后端测试（uv 缓存需重定向；详见 §1.1）
cd backend && uv run pytest -q                      # 原样执行：uv 缓存权限失败，exit 2
cd backend && UV_CACHE_DIR=/tmp/uv-cache-test uv run pytest -q      # exit 0, 2 passed
cd backend && UV_CACHE_DIR=/tmp/uv-cache-test uv run pytest -v      # 收集清单
cd backend && .venv/bin/python -m pytest -q         # 等价路径（不再触碰 uv.lock）

# 2) 前端测试
cd frontend/web && ./node_modules/.bin/vitest run   # exit 0, 2 files / 10 tests

# 3) 规模与路由统计（只读探针，见 /tmp/probe_tests.py）
cd backend && .venv/bin/python -c "from app import create_app; print(len(create_app().openapi()['paths']))"   # 205
find backend/app -name '*.py' | wc -l ; find backend/app -name '*.py' -exec cat {} + | wc -l                  # 216 / 28519

# 4) 测试资产溯源
git ls-files .github                                  # 0（根 CI 为空）
git log --diff-filter=D --name-only -- backend/tests  # 删除轨迹
python3 -c "import json;print(len(json.load(open('backend/.pytest_cache/v/cache/nodeids'))))"                 # 761
```

## 7. 环境与合规说明（重要）

1. **工作区在本次审计开始前即为脏**（其他 teammate 的并行产物）：`git status --porcelain` 显示已修改 `backend/app/config/setting.py`、`backend/pyproject.toml`、`backend/requirements.txt`、`backend/uv.lock`、`docker/.env.example`，未跟踪 `backend/requirements/`、`backend/audit-requirements.md`、`docker/audit-deploy.md`、`deploy-artifacts.sh`、`.agent-teams/`。其中 `pyproject.toml` 的 mtime 为 03:29（早于本会话），改动内容是把 mysql/pg 驱动从核心依赖迁到 `optional-dependencies`。
2. **`backend/uv.lock` 的 mtime 被本次 `uv run pytest -q`（未加 `--no-sync`）刷新为 03:58**。该文件的 diff 内容与上述 03:29 的 `pyproject.toml` 改动严格对应（`aiomysql`/`asyncpg`/`pymysql`/`psycopg` 从核心组迁入 `optional-dependencies`，并新增 `all-db` 组），未发现与之无关的内容变化；后续所有命令已改为 `backend/.venv/bin/python` 或 `--no-sync`，不再触碰锁文件。**此为本轮唯一可能非预期的写操作，特此披露。**
3. 除本报告文件 `backend/audit-testing.md` 外，**未新建、修改或删除仓库内任何文件**；未安装依赖、未启服务、未执行 git 提交。
4. `backend/app/alembic/versions/`、`backend/tests/` 在审计前后内容一致（分别只有 `__init__.py` / 3 个 `.py`）。
5. 本报告中的"探针实测"结果来自 `/tmp/probe_tests.py`（临时目录），仅使用内存/SQLite 与纯函数路径，未连接真实 MySQL、PostgreSQL 或 Redis。
6. 未取得**行覆盖率数字**：`pytest-cov` 与 `@vitest/coverage-*` 均未安装，且本轮不安装依赖。所有"缺口"结论基于：OpenAPI 路由清单、模块清单、`AuthPermission` 引用计数、代码路径静态审读与上述探针行为实测。