4.1 KiB
09 测试与验收
Phase 6–7 验收补充（2026-08-12）
自动化覆盖草稿公开隔离、审核发布历史、服务故事隐私确认、危险内容拒绝、消息 IDOR、订阅授权、统计未认证拒绝、脱敏汇总导出和导出审计。隔离 MySQL 部署 8 个 migration 后全量 34 个集成测试通过。
生产工程验收：权限扫描通过；官方源 High 级依赖审计无已知漏洞；密钥特征扫描无匹配；schema drift 无差异；基础/staging/production Compose 校验与 API Alpine 镜像构建通过；备份恢复到临时库后源/恢复库均为 42 张表并完成清理。
真实 staging、UAT、微信真机联调和生产部署不能由本地自动化替代，继续按发布清单留存人工证据。
1. 测试金字塔
Unit
业务规则、状态机、权限策略、计算。
Integration
API + DB，重点测试事务、唯一约束、权限和状态流转。
E2E
关键业务闭环。
2. P0 E2E 场景
E2E-001 本人申请
用户登录 → 选择老年服务 → 填写需求 → 提交 → 获得编号 → 我的申请可见。
E2E-002 防重复
用户连续点击提交两次 → 只能产生一个业务申请。
E2E-003 代申请
家属为老人申请 → 正确保存申请人与服务对象关系。
E2E-004 工作人员受理
工作人员登录 → 查看待处理 → 联系/评估 → 建档 → 受理 → 创建工单。
E2E-005 服务执行
负责人 → 开始服务 → 添加两条服务记录 → 完成 → 自动生成回访任务。
E2E-006 回访继续帮扶
回访选择“需要继续帮助” → 生成关联后续任务/申请，原历史不丢失。
Phase 4 自动化验收还必须覆盖：无服务记录禁止完成、服务完成/自动回访事务一致、相同请求安全重放而变更内容冲突、工作人员仅看本人回访、项目负责人可看全量、重点关爱待办统计、继续帮扶新授权和关联申请唯一、原申请关闭且原历史保留。
E2E-007 越权
志愿者 A 访问志愿者 B 的工单 → 403。
E2E-008 用户越权
用户 A 猜测用户 B 的 public_id → 404/403，不泄露存在性。
E2E-009 活动报名
报名 → 重复报名被唯一约束阻止 → 人数达到上限后不可继续报名。
Phase 5 自动化验收还必须覆盖：未认证用户禁止报名、草稿项目不能公开读取、志愿者申请/审核与角色授予事务一致、项目/活动状态机、报名请求安全重放、报名审核重放、签到重放、容量行锁、服务时长只来自已通过且已签到的已完成活动、历史与审计不重复写入。
E2E-010 文件
允许图片上传；exe/php/html 等危险类型拒绝；超限拒绝；私有文件无授权无法下载。
3. 安全验收
必须测试：
- IDOR
- broken access control
- mass assignment
- SQLi
- stored/reflected XSS
- CSRF（后台）
- upload bypass
- rate limit
- brute force
- token expiry
- session fixation
- sensitive log leakage
4. 可靠性验收
模拟：
- Redis 不可用；
- COS 暂时失败；
- 微信消息发送失败；
- 数据库瞬时错误；
- 客户端重复请求；
- 网络超时。
要求：
- 主业务不产生半状态；
- 可重试；
- 失败可追踪；
- UI 不假成功。
5. 性能目标（V1 建议基线）
不是大型互联网项目，不盲目追极限。
建议：
- 常规 API P95 < 500ms（不含第三方和大文件）
- 后台列表首屏合理数据量 < 2s
- 小程序首页优先内容快速可见
- 100 并发常规请求下无明显错误率上升
- 数据库常用列表避免 N+1
具体目标可根据云资源实测调整。
6. UAT 验收人员
至少模拟：
- 65+ 老年服务对象
- 家属代申请
- 普通工作人员
- 项目负责人
- 志愿者
- 管理员
UAT 不只让开发人员自测。
7. V1 上线门槛
必须全部满足：
- P0 E2E 全通过；
- 无 Critical/High 已知安全漏洞；
- 备份成功；
- 恢复演练通过；
- staging 走完整闭环；
- 隐私政策/授权页面就绪；
- 微信小程序审核所需材料就绪；
- 监控和告警正常；
- 可回滚上一版本。