测试与验收

你将学到

• 桌面端验收为什么分四层，每一层验证什么
• 每一层要跑的命令和要检查的项目
• 发布前的人工清单和常见遗漏

桌面端验收分四层，从快到慢、从抽象到具体。每一层验证的东西不一样，不能互相替代。

代码契约

这是最快的检查，跑一遍就知道类型和逻辑有没有问题：

vpr @01mvp/desktop#type-check
vpr @01mvp/desktop#lint
vpr @01mvp/desktop#test
vpr @01mvp/desktop#build
vpr @01mvp/desktop#tauri:check

当前测试覆盖三类场景：

改了 env、API base URL、auth cookie、runtime adapter 或偏好结构的话，先更新对应测试再跑。

后端契约

桌面端依赖 01MVP Web/API 后端。当改动涉及后端 origin、auth 或 oRPC 边界时，跑产品级测试：

vpr @01mvp/product#test

这会覆盖 config、auth、api、web 等产品级测试。纯桌面 UI 改动不需要每次跑，跨到后端配置时再跑就行。

浏览器预览

浏览器预览能快速验证 UI，但看不到 Tauri 原生能力。

启动方式：

vpr @01mvp/product#dev
vpr @01mvp/desktop#dev

浏览器打开 http://localhost:7410，检查这几项：

• 页面不是空白
• API status 能显示
• 登录表单能输入和提交
• 设置能保存和重置
• 窗口宽度接近桌面使用场景时布局合理

浏览器预览适合快速迭代，但不能代替 Tauri 原生窗口验收。

Tauri 原生窗口

这是桌面端的核心验收环节。Tauri command、tray、文件写入、系统权限这些能力只有在原生窗口里才能真正验证。

启动方式：

vpr @01mvp/desktop#tauri:dev

打开后检查：

• 原生窗口能正常打开
• 托盘菜单能显示 Open 和 Quit
• app data 目录能正常打开
• 本地偏好保存到 app data 后，重启仍存在
• 外部 URL 能通过系统默认浏览器打开
• 未配置 updater 时，检查更新不会导致应用崩溃

构建烟测

构建成功不代表应用好用，但构建失败一定说明有问题。

vpr @01mvp/desktop#tauri:build

构建成功后，打开生成的安装包或 .app，检查：

• 应用名、图标、版本号正确
• 首页能打开
• API URL 指向预期环境（不是 localhost）
• 登录和 profile API 可用
• app data 目录使用正式 identifier

发行包验收

准备发给真实测试用户前，还要检查这一组：

如果 updater 还没启用，检查更新按钮应该显示清楚的不可用或已关闭状态，不能抛错或停在 loading。

文档链接检查

新增、删除或改名 desktop 文档时，跑一次链接检查：

vpr @01mvp/web#docs:check-mdx

它会检查 sidebar、Card 和 MDX 内部链接。断链不会阻塞构建，但会影响用户体验。

发布前人工清单

最后一遍，手动过一遍：

• 干净机器能安装和打开
• 旧版本覆盖安装后用户偏好还在
• 没有把本地 localhost API 打进生产包
• macOS 签名和公证状态符合预期
• Windows 安装包不会被安全软件直接拦下
• 自动更新 endpoint 返回正确版本
• updater 签名产物和 endpoint 返回的签名匹配
• 下载页、文档和安装包版本一致
• 退出、重启、托盘行为符合产品预期
• 反馈、联系作者、版本号、检查更新这些设置入口可用

常见遗漏

这些问题看起来不起眼，但发布后会被用户直接碰到：

• 只跑浏览器预览 — Tauri command、tray、文件写入可能在真实窗口才失败
• 只改前端 env — 后端 CORS 或 trusted origins 仍然拒绝登录
• 随意改 identifier — 用户本地数据和 macOS 权限记录像换了一个应用
• 没跑 docs link check — sidebar 或 Card 链接会断
• 没验证安装包 — build 通过，但用户下载后打不开

下一步

测试全部通过后，进入构建和分发阶段。请阅读构建与分发。