dbtool-cli-v1/TEST_STRATEGY.md

dbtool-cli-v1 测试策略（初版）

目标

• 为 CLI 第一版建立可重复、可说明、可交付的验收方式。
• 在代码落地前先建立 QA 基线，避免后期以“本地能跑”代替“满足验收”。

当前盘点结果

• 当前已观察到 Rust workspace、CLI 二进制、release artifact、GitHub release-smoke workflow、demo seed SQL、query fixture、bootstrap 脚本和 smoke runbook。
• 当前 agent 环境可直接执行本地 Linux + SQLite 的运行型验证。
• 当前 agent 环境有 node v24.14.0 与预编译 target/release/dbtool，因此 SQLite bootstrap 与本地二进制 smoke 可重复执行。
• 当前 agent 环境仍缺 docker，因此 PostgreSQL / MySQL 运行时 smoke 不能在此本地复现。
• 当前 agent 环境也缺 cargo，因此 Docker-capable host 若无 Rust toolchain，需改用已构建二进制或 release artifact 执行 smoke。
• 当前 agent 环境也无法替代 GitHub 的 macOS / Windows runner 证据。
• 2026-03-26 已补做 SQLite non-db file 回归：connect 现在会在前置检查阶段失败，不再误报成功。

测试优先级

1. 工作区与可执行入口存在
2. 三种数据库的连接成功 / 失败路径
3. schema introspection
4. 查询执行
5. 导出流程
6. 跨平台差异与边界条件

测试层次

1. Smoke

• 验证 CLI 可启动、可显示帮助、可做最小连接检查。
• 必须能一条命令执行，且适合发布前快速复核。

2. 功能验收

• 按 PostgreSQL、MySQL、SQLite 分库执行 connect / inspect / query / export。
• happy path 与失败路径都要保留证据。

3. 回归

• 对已修缺陷建立回归步骤。
• 每次发布前至少回归：启动、连接、查询、导出、错误提示。

4. 边界条件

• 空数据库、空结果集、大结果集、非法路径、错误凭据、权限不足、Unicode、NULL、日期时间。

证据要求

• 每个通过项都需要命令、输入、输出摘要和环境信息。
• 每个失败项都需要复现步骤、预期行为、实际行为和严重级别。
• 未执行项必须明确标记原因，不能默认视为通过。

推荐交付资产

• 可复制的 README 或开发说明
• demo / seed 脚本
• smoke 脚本
• Docker 运行方式
• 跨数据库样例配置
• 缺陷复现模板

当前明显缺口

• 缺 PostgreSQL / MySQL 的本地 Docker 执行证据
• 缺 GitHub macOS / Windows release runner 的真实执行证据
• 缺大结果集 / 超时 / 空结果导出等剩余边界证据

下一次验证入口

• 在 Docker 可用环境执行 PostgreSQL / MySQL connect / inspect / query / export smoke；若宿主无 cargo，直接使用 target/release/dbtool 或 release artifact。
• 继续补齐 SQLite missing file 与其余边界路径证据。
• 在 CI 或等价 runner 上收集 Linux / macOS / Windows release artifact 证据。
• 将新增结果持续回填到验收检查表和发布前清单。