79 lines
3.8 KiB
Markdown
79 lines
3.8 KiB
Markdown
# 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 可重复执行。
|
||
- 2026-03-26 [CMP-17](/CMP/issues/CMP-17#comment-0cd53e93-25a5-456b-8dba-31ea098c2aa8) 已回填：PostgreSQL / MySQL runtime smoke 在具备 Docker 的宿主机执行完成，因此“当前 QA runner 无 Docker”不再是该路径的发布 blocker。
|
||
- 当前 agent 环境中的 Rust toolchain不在默认 PATH，但可通过显式 PATH 与 `zig` 包装器运行 `cargo test` / `cargo build`。
|
||
- 当前 agent 环境也无法替代 GitHub 的 macOS / Windows runner 证据。
|
||
- 2026-03-26 已补做 SQLite non-db file 回归：`connect` 现在会在前置检查阶段失败，不再误报成功。
|
||
- 2026-03-26 已补做 MySQL 修复离线回归：驱动侧 `mysql_` 定向测试通过、CLI 测试通过、release binary 重建成功。
|
||
- 2026-03-27 新宿主机线索与 [CMP-22](/CMP/issues/CMP-22#comment-9b4ec6e1-408d-483d-a319-818be09d6d79) 一致：在干净重建并显式 UTF-8 导入后，MySQL 官方 CLI、`dbtool query`、`dbtool export` 都报告正常。
|
||
- 2026-03-27 [CMP-23](/CMP/issues/CMP-23#comment-ab7a7c16-aaa3-4e62-9543-5055925201b8) 已补齐宿主机 Unicode patched-run 证据：字符集变量、collation 变量、官方 CLI 查询、`dbtool query`、`dbtool export` 摘要均可审计。
|
||
- 2026-03-26 当前 live retest 仍缺环境：本机 `127.0.0.1:53306` 与 `127.0.0.1:55432` 端口关闭，无法直接完成修复后的 MySQL / PostgreSQL runtime 复验。
|
||
|
||
## 测试优先级
|
||
|
||
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 运行方式
|
||
- 跨数据库样例配置
|
||
- 缺陷复现模板
|
||
|
||
## 当前明显缺口
|
||
|
||
- 缺 GitHub macOS / Windows release runner 的真实执行证据
|
||
- 缺宿主机验证使用的具体 binary path 与 commit SHA / branch 留档
|
||
- 缺大结果集 / 超时 / 空结果导出等剩余边界证据
|
||
|
||
## 下一次验证入口
|
||
|
||
- 为已完成的宿主机 MySQL Unicode patched run 补上具体 binary path 与 commit SHA / branch，增强验收可追溯性。
|
||
- 继续补齐 SQLite missing file 与其余边界路径证据。
|
||
- 在 CI 或等价 runner 上收集 Linux / macOS / Windows release artifact 证据。
|
||
- 将新增结果持续回填到验收检查表和发布前清单。
|