# 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 走完整闭环； - 隐私政策/授权页面就绪； - 微信小程序审核所需材料就绪； - 监控和告警正常； - 可回滚上一版本。