iven/hms
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
281c71ebfc34c59edcbfdb65ff421b67ebfe008f
hms/docs/superpowers/specs/2026-05-05-quality-verification-strategy-design.md
iven df1d85bfde docs: T40 UI 审计报告 + wiki 更新 + Docker 配置 
- T40 UI 审计计划和结果文档（docs/qa/）
- wiki 更新：miniprogram 设计系统合规审计记录 + index 关键数字更新
- 审计 V2 完整报告（docs/audits/v2/）
- 讨论记录文档（docs/discussions/）
- 设计规格和实施计划（docs/superpowers/）
- 角色测试计划和结果（docs/qa/role-test-*）
- Docker 生产部署配置
2026-05-13 23:29:42 +08:00

302 lines
16 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# HMS 质量验证策略 — 分层端到端验证
> 日期: 2026-05-05 | 状态: Draft
## 1. 背景
HMS 健康管理平台已完成 Phase 0-1 的功能开发，Phase 2 Web UI 补全正在进行中。系统当前拥有：
- 18 个 Rust crate，87k 行后端代码，328 个 API 路由
- 46 个健康业务实体，80+ 个 health 模块端点
- Web 管理后台 36+ 条健康路由，微信小程序 40+ 页面
- 772 个后端单元/集成测试（97.5% 通过率）
**核心矛盾：** 功能完整度很高（前后端几乎全部贯通），但从未从业务角色视角进行过端到端的系统性验证。无法确认所有业务链路闭环、各角色的功能是否可用、是否存在过度开发。
**触发因素：** 已签约的血透中心客户要求 1-2 周内看到可试用的版本。
## 2. 策略概述
采用**分层验证**策略（Layer C）：
- **第一周（Day 0-5）：** 角色场景冒烟测试 — 定义 6 条端到端业务链路，手动走通并记录问题
- **第二周（Day 6-10）：** 修复 + 固化 — 修复 P0 问题，将通过的链路固化为 Playwright 自动化测试
## 3. 前置准备（Day 0）
开始冒烟测试前，必须确认以下基础环境：
| 检查项 | 验证方式 | 通过标准 |
|--------|---------|---------|
| 后端服务启动 | `cd crates/erp-server && cargo run` | 无报错，监听 3000 端口 |
| 前端开发服务 | `cd apps/web && pnpm dev` | 无报错，访问 localhost:5174 正常 |
| 数据库迁移 | 查看启动日志 | 所有迁移成功执行 |
| 初始种子数据 | 检查数据库 | 有默认管理员账号 + 基础科室/角色数据 |
| 小程序开发工具 | 微信开发者工具加载项目 | 编译无错误，模拟器正常运行 |
| API 文档 | 访问 `/api/docs/openapi.json` | OpenAPI spec 正常返回 |
**种子数据最低要求：**
- 1 个管理员账号（admin/Admin@2026）
- 2 个科室（血透室、体检科）
- 4 个用户（2 医生 + 2 护士），已分配对应角色
- 5 个患者档案（其中 2 个需绑定微信测试号，供 S4 使用）
- 下周的排班数据
- 基础告警规则（血压/心率阈值）
**已知审计问题确认（Day 0 必须检查）：**
| 审计 ID | 问题描述 | 状态 | 冒烟测试影响 |
|---------|---------|------|-------------|
| CRITICAL-1 | 小程序晚间血压丢失（`blood_pressure_evening` 类型缺失） | wiki 显示已修复 | S4 步骤 3 涉及体征录入，需确认晚间血压可正常保存 |
| CRITICAL-2 | 告警权限码拼写错误（`health.alert.manage` vs `health.alerts.manage`） | 待确认 | S2 步骤 6-7 涉及告警查看/处理，如权限码错误将导致 403 |
| HIGH-1 | 透析管理小程序端缺失 | 未修复 | S4 仅验证 Web 端透析功能，小程序端降级为"查看透析记录" |
| HIGH-2 | 知情同意小程序端缺失 | 未修复 | S4 跳过知情同意功能验证 |
| HIGH-3 | 前端日志严重不足 | 未修复 | 不阻塞冒烟测试，但影响问题定位效率 |
**降级策略：** HIGH-1/HIGH-2 未修复的小程序功能，在 S4 中标记为 SKIP，不阻塞场景判定。
## 4. 冒烟测试场景
### 4.0 场景数据依赖
```
S1 系统初始化（数据基础）
├── S2 透析日流程（依赖 S1 创建的科室、护士、排班）
├── S3 患者管理（依赖 S1 创建的医生、患者数据）
├── S4 小程序核心（依赖 S1 创建的患者 + 微信测试号绑定）
├── S5 运营配置（依赖 S1 创建的告警规则基础数据）
└── S6 关怀闭环（依赖 S1 创建的患者/医生数据）
```
**硬前置：** S1 必须先通过，否则 S2-S6 无法执行。如果 S1 FAIL，优先修复 S1 再继续。
### 4.1 场景定义
#### S1: 系统初始化（管理员）
| # | 步骤 | 操作路径 | 端 | 期望结果 |
|---|------|---------|----|---------|
| 1 | 管理员登录 | `/` 登录页 | Web | 进入工作台首页，仪表盘渲染正常 |
| 2 | 创建科室 | 侧边栏 > 组织管理 > `/organizations` > 新增科室 | Web | 科室列表显示血透室、体检科 |
| 3 | 添加医生 ×2 + 护士 ×2 | 侧边栏 > 用户管理 > `/users` > 新增用户 | Web | 用户列表显示新创建的用户 |
| 4 | 分配角色和权限 | 侧边栏 > 角色管理 > `/roles` > 编辑角色 > 绑定用户 | Web | 角色绑定生效，权限控制正确 |
| 5 | 创建下周排班 | 侧边栏 > 健康管理 > 排班管理 > `/health/schedules` > 新增排班 | Web | 排班日历视图显示排班数据 |
| 6 | 查看统计看板 | 侧边栏 > 健康管理 > 统计报表 > `/health/statistics` | Web | 图表渲染正常，数据不为空 |
**验证重点：** 系统初始化后所有基础数据就绪，后续场景可使用这些数据。
---
#### S2: 透析日流程（护士）
| # | 步骤 | 操作路径 | 端 | 期望结果 |
|---|------|---------|----|---------|
| 1 | 护士登录 | `/` 登录页 | Web | 进入工作台，看到今日待办 |
| 2 | 查看今日排班 | 侧边栏 > 健康管理 > 排班管理 > `/health/schedules` | Web | 显示今日透析排班列表 |
| 3 | 患者签到 | 侧边栏 > 健康管理 > 预约管理 > `/health/appointments` > 签到按钮 | Web | 患者状态变为"已签到" |
| 4 | 采集体征 | 患者详情页 > `/health/patients/:id` > 体征 Tab > 录入按钮 | Web | 体征数据保存成功（血压/心率/体温） |
| 5 | 记录透析会话 | 侧边栏 > 健康管理 > 透析管理 > `/health/dialysis` > 新建透析记录 > 状态按钮切换（待开始 → 进行中 → 已完成） | Web | 透析记录完整，状态流转正确 |
| 6 | 触发异常 | 患者详情页体征录入 > 输入超标血压值（如 200/120） | Web | 告警自动生成，告警列表可见 |
| 7 | 确认告警 | 侧边栏 > 健康管理 > 告警列表 > `/health/alerts` > 处理按钮 | Web | 告警状态变为"已处理" |
| 8 | 填写交接班记录 | 侧边栏 > 健康管理 > 班次管理 > `/health/shifts/:id` > 交接记录 Tab > 新增 | Web | 交接班记录保存成功 |
**验证重点：** 血透中心最核心的日常工作流，一条龙走通。
---
#### S3: 患者管理与决策（医生）
| # | 步骤 | 操作路径 | 端 | 期望结果 |
|---|------|---------|----|---------|
| 1 | 医生登录 | `/` 登录页 | Web | 进入医生工作台/仪表盘 |
| 2 | 查看患者列表 | 侧边栏 > 健康管理 > 患者管理 > `/health/patients` | Web | 列表显示患者，可搜索/筛选 |
| 3 | 查看患者详情 | 患者列表 > 点击某患者 > `/health/patients/:id` | Web | 详情页显示基本信息、体征、诊断、用药 |
| 4 | 查看体征趋势图 | 患者详情页 > 趋势 Tab | Web | 趋势图表渲染正确，数据连续 |
| 5 | 审阅透析处方 | 小程序医生端 > 透析 > 处方列表 > `pages/doctor/prescription/detail` | MP | 处方详情显示正常 |
| 6 | 创建随访计划 | 侧边栏 > 健康管理 > 随访任务 > `/health/follow-up-tasks` > 新建 | Web | 随访任务生成成功 |
| 7 | 查看 AI 分析报告 | 侧边栏 > 健康管理 > AI 分析 > `/health/ai-analysis` | Web | AI 分析结果正常展示 |
| 8 | 处理行动收件箱 | 侧边栏 > 健康管理 > 行动收件箱 > `/health/action-inbox` > 完成按钮 | Web | 任务可标记完成 |
**验证重点：** 医生日常查看数据 + 做决策的完整流程。
---
#### S4: 小程序核心体验（患者）
| # | 步骤 | 操作路径 | 端 | 期望结果 |
|---|------|---------|----|---------|
| 1 | 微信登录 → 手机绑定 | 首页 `pages/index/index` > 登录按钮 > `pages/login/index` | MP | 登录成功，进入健康首页（`ERP__WECHAT__DEV_MODE=true` 跳过 jscode2session） |
| 2 | 查看健康首页 | 底部 Tab > 健康 > `pages/health/index` | MP | 显示今日体征/待办/通知 |
| 3 | 体征数据录入 | 健康首页 > 体征录入 > `pages/pkg-health/input/index` | MP | 数据提交成功（含晚间血压验证） |
| 4 | 查看体征趋势 | 健康首页 > 趋势查看 > `pages/pkg-health/trend/index` | MP | 趋势图表渲染正常 |
| 5 | 查看预约列表 | 底部 Tab > 预约 > `pages/appointment/index` | MP | 显示预约记录 |
| 6 | 查看告警通知 | 健康首页 > 告警 > `pages/pkg-health/alerts/index` | MP | 告警列表正常显示 |
| 7 | 查看用药记录 | 个人中心 > 用药记录 > `pages/pkg-profile/medication/index` | MP | 用药列表显示正常 |
| 8 | 查看诊断记录 | 个人中心 > 诊断记录 > `pages/pkg-profile/diagnoses/index` | MP | 诊断记录显示正常 |
> **注意：** 透析管理（HIGH-1）和知情同意（HIGH-2）的小程序端尚未实现，本场景跳过这两项。
**验证重点：** 患者端小程序的基础可用性。
---
#### S5: 运营配置（管理员）
| # | 步骤 | 操作路径 | 端 | 期望结果 |
|---|------|---------|----|---------|
| 1 | 配置告警规则 | 侧边栏 > 健康管理 > 告警规则 > `/health/alert-rules` > 新建规则 | Web | 规则保存成功，列表显示 |
| 2 | 配置危急值阈值 | 侧边栏 > 健康管理 > 危急值阈值 > `/health/critical-value-thresholds` > 新建 | Web | 阈值保存成功 |
| 3 | 注册 BLE 网关 | 侧边栏 > 健康管理 > BLE 网关 > `/health/ble-gateways` > 新建网关 | Web | 网关显示为在线/离线状态 |
| 4 | 创建知情同意模板 | 侧边栏 > 健康管理 > 知情同意 > `/health/consents` > 新建 | Web | 模板保存成功 |
| 5 | 创建随访模板 | 侧边栏 > 健康管理 > 随访模板 > `/health/follow-up-templates` > 新建 | Web | 模板保存成功 |
| 6 | 检查侧边栏菜单完整性 | 以管理员登录，逐一点击侧边栏所有健康管理子菜单 | Web | 所有健康模块功能在菜单中可见（参见第 7 节缺口清单） |
**验证重点：** 管理后台的配置能力是否完整，菜单可见性是否正确。
---
#### S6: 关怀闭环（医生）
| # | 步骤 | 操作路径 | 端 | 期望结果 |
|---|------|---------|----|---------|
| 1 | 创建护理计划 | 侧边栏 > 健康管理 > 护理计划 > `/health/care-plans` > 新建 > 添加条目 | Web | 计划保存成功，条目可见 |
| 2 | 查看行动收件箱 | 侧边栏 > 健康管理 > 行动收件箱 > `/health/action-inbox` | Web | 显示待处理行动（与 S3 步骤 8 共享页面，重点关注护理计划相关行动） |
| 3 | 回复咨询消息 | 侧边栏 > 健康管理 > 咨询管理 > `/health/consultations/:id` > 发送消息 | Web | 消息发送成功 |
| 4 | 审批 AI 建议 | 行动收件箱 > AI 建议 Tab > 审批按钮 | Web | 建议状态变更 |
| 5 | 记录结果测量 | 护理计划详情 > `/health/care-plans/:id` > 结果测量 Tab > 新增 | Web | 测量数据保存成功 |
| 6 | 查看内容管理文章 | 侧边栏 > 健康管理 > 文章管理 > `/health/articles` | Web | 文章列表和详情正常显示 |
> **S3 与 S6 的边界：** S3 侧重"数据查看与决策"（查看趋势、开处方、AI 报告），S6 侧重"计划执行与闭环"（护理计划、咨询回复、结果测量）。行动收件箱在两个场景中都会用到但关注点不同。
**验证重点：** 护理计划 → 执行 → 测量结果的关怀闭环。
### 4.2 场景优先级
| 优先级 | 场景 | 原因 |
|--------|------|------|
| P0 | S1 系统初始化 | 所有后续场景的数据基础 |
| P0 | S2 透析日流程 | 血透中心最核心的业务流程 |
| P0 | S3 患者管理 | 医生日常工作的核心路径 |
| P0 | S4 小程序核心 | 患者端唯一入口，必须可用 |
| P1 | S5 运营配置 | 管理能力，首次演示可以后补 |
| P1 | S6 关怀闭环 | 旗舰功能但复杂度高，可降级 |
## 5. 判定标准
### 5.1 步骤级判定
| 状态 | 含义 | 处理方式 |
|------|------|---------|
| PASS | 步骤完全通过 | 记录，无需修复 |
| PARTIAL | 步骤可用但有瑕疵 | 记录问题，不阻塞后续 |
| FAIL | 步骤无法完成 | 记录并立即标记为 BUG |
### 5.2 场景级判定
| 状态 | 含义 |
|------|------|
| PASS | 全部步骤 PASS |
| PASS_WITH_ISSUES | 全部关键步骤 PASS，有 PARTIAL 项 |
| FAIL | 任一关键步骤 FAIL |
### 5.3 BUG 优先级
| 级别 | 条件 | 修复时限 |
|------|------|---------|
| BLOCKER | P0 场景的关键步骤 FAIL | 当天修复 |
| CRITICAL | P0 场景非关键步骤 FAIL，或数据不一致 | 48h 内修复 |
| HIGH | P1 场景 FAIL | 第二周修复 |
| MEDIUM | PARTIAL 问题（UI 错位、文案错误等） | 记录，按优先级排期 |
| LOW | 建议性改进 | 积压 |
## 6. 执行计划
### 6.1 第一周：冒烟测试
| 天 | 日期 | 任务 | 交付物 |
|----|------|------|--------|
| Day 0 | W1-Mon | 前置环境检查 + 种子数据准备 | 环境就绪确认 |
| Day 1 | W1-Tue | S1 系统初始化 + 菜单可见性排查 | S1 验证报告 + 菜单缺口清单 |
| Day 2 | W1-Wed | S2 透析日流程 | S2 验证报告 |
| Day 3 | W1-Thu | S3 患者管理与决策 | S3 验证报告 |
| Day 4 | W1-Fri | S4 小程序核心体验 | S4 验证报告 |
| Day 5 | W1-Sat/Sun | S5 运营配置 + S6 关怀闭环 + 汇总 | 全场景验证报告 + BUG 清单 |
### 6.2 第二周：修复 + 固化
| 天 | 任务 | 交付物 |
|----|------|--------|
| Day 6-7 | BLOCKER + CRITICAL BUG 修复 | 修复提交 |
| Day 8 | P0 场景回归验证（重跑修复步骤 + 前后各一个相邻步骤） | 回归报告 |
| Day 9-10 | S2 透析日流程 Playwright 自动化 + P1 场景验证 + 质量报告 | 测试脚本 + 完整质量报告 |
## 7. 菜单可见性排查
根据代码分析，以下功能的路由已注册但可能不在侧边栏菜单中显示（需要通过数据库迁移或手动配置添加菜单项）：
- 透析管理
- 护理计划
- 班次管理
- 用药记录
- BLE 网关
- 危急值阈值
- 诊断记录
- 家庭健康代理
- 知情同意
- 随访模板
- 行动收件箱
- 内容管理（文章/分类/标签）
- 实时监控
- OAuth 合作方
**排查方式：** 以管理员登录后查看侧边栏，逐一确认以上功能是否有菜单入口。缺失的需创建菜单迁移文件。
## 8. 第二周 Playwright 自动化范围
优先固化最核心的 S2 透析日流程为自动化测试。每个场景预计 4-8 小时（含调试），因此两周内只覆盖 S2：
1. **S2 透析日流程（Day 9-10）** — 登录 → 排班查看 → 体征录入 → 透析记录 → 告警处理
S1 和 S3 的自动化留到后续迭代。现有 Playwright 基础设施（`apps/web/e2e/`）已有 page object 和 fixture 模式可复用。
**自动化质量标准：**
- 每个关键步骤至少一个断言
- flaky 测试最大重试 2 次
- 测试数据通过 API setup 生成，不依赖手动准备
小程序端（S4）暂不纳入自动化（微信开发者工具的自动化测试生态不成熟），持续手动验证。
## 9. 交付物清单
| 交付物 | 产出时间 | 说明 |
|--------|---------|------|
| 环境就绪确认 | Day 0 | 所有前置检查通过 |
| 可重复执行的种子数据脚本 | Day 0 | SQL 或 seed 脚本，可一键初始化测试数据 |
| 6 份场景验证报告 | Day 1-5 | 每条链路的步骤级结果 |
| 菜单缺口清单 | Day 1 | 需要补充的侧边栏菜单项 |
| BUG 清单 | Day 5 | 按优先级排列的完整问题列表 |
| 修复提交记录 | Day 6-8 | 所有 BLOCKER/CRITICAL 的修复 |
| Playwright 测试脚本（S2） | Day 9-10 | 透析日流程自动化测试 |
| 质量报告 | Day 10 | 两周验证总结 + 发布建议 |
### 质量报告模板
质量报告应包含以下内容：
1. **场景判定汇总** — 6 个场景的最终判定（PASS / PASS_WITH_ISSUES / FAIL）
2. **BUG 清单及修复状态** — 所有发现的问题、当前状态（已修复/待修复/降级）
3. **发布风险评估** — GO / CONDITIONAL GO / NO-GO 判定及理由
4. **遗留问题清单** — 未修复问题的清单、影响范围和后续计划
5. **下一步建议** — 第二阶段验证或正式发布的前置条件
## 10. 风险与应对
| 风险 | 概率 | 影响 | 应对 |
|------|------|------|------|
| 种子数据不完整，S1 无法执行 | 中 | 高 | Day 0 优先准备可重复执行的种子数据脚本 |
| BLOCKER 数量过多，修复超过 2 天 | 中 | 高 | 降级 P1 场景，集中修复 P0 |
| 小程序登录流程不通 | 中 | 高 | 提前准备测试号和 mock 环境（`ERP__WECHAT__DEV_MODE=true`） |
| 微信开发者工具版本兼容性导致登录失败 | 中 | 中 | 使用稳定版开发者工具，避免最新 beta 版 |
| 菜单缺失导致功能"找不到" | 高 | 低 | Day 1 集中排查并补充菜单迁移 |
| 两周时间不够完成所有修复 | 中 | 中 | 只交付 P0 通过的版本给客户 |
Reference in New Issue View Git Blame Copy Permalink