7.6 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 走完整闭环；
- 隐私政策/授权页面就绪；
- 微信小程序审核所需材料就绪；
- 监控和告警正常；
- 可回滚上一版本。
8. 财务公开验收
- DOCX 可在管理端本地导入，基础标题、段落、列表和表格可继续编辑并预览。
- 危险 HTML、脚本、事件属性、iframe 和非 HTTPS 外链不能进入公开正文。
- 未登录或无权限人员不能访问管理接口；草稿和归档文档不能从公众接口获取。
- 草稿可编辑并使用 revision 防并发覆盖；已发布文档不能覆盖编辑，只能归档。
- 创建、发布和归档幂等，状态历史和审计完整；小程序列表、详情、空状态和失败状态可用。
9. 旧物善用 Phase 1 验收
- 首页和个人中心入口均可到达模块主页；模块主页统计只显示真实业务事实。
- 上门取件必须填写联系人、合法手机号、地址、未来预约时间并由后台选择工作人员；定点投递必须选择已启用点位。
- 最多六张图片通过私有对象存储预签名上传并确认元数据；只有捐赠本人和具备旧物查看权限的后台人员可获取五分钟短期下载 URL，访问需审计。
- 捐赠创建幂等，其他用户不能读取猜测的公开 ID；审核、接收、分拣和完成严格校验 revision 与状态机，每次变化都有不可变历史和审计。
- 需求仅在发布后公开；定向捐赠完成时原子增加已满足数量；统计从接收/完成事实计算，不允许后台人工覆盖。
- 管理端可处理订单、人工分配、发布/下架需求和新增投递点；Phase 2 台账、Excel、证书和积分不得以空按钮冒充完成。
10. 旧物善用 Phase 2 验收
- 手工入库和标准 Excel 批量入库都生成不可预测台账编号、在库主记录、入库事件和审计；同一请求安全重放，不同内容复用请求 ID 被拒绝。
- Excel 模板具有固定表头、品类下拉、整数数量、日期格式、冻结表头与合理列宽；公式、错误表头、非法品类、非正整数数量、重复来源捐赠和超过 500 行必须拒绝，任一行失败时整批不落库。
- 状态只能按在库、分拣、消毒、出库、落地推进，跳级/回退和过期 revision 被拒绝；出库缺少需求/对象/区域或落地缺少实际帮扶人数时拒绝。
- 详情包含完整只追加事件；导出和打印不包含手机号、地址、受助对象姓名或内部备注，导出有独立权限和审计。
- 关联捐赠的小程序详情只展示脱敏节点、时间和粗粒度帮扶地区，不展示内部仓位、操作人或受助对象个人信息。
11. 旧物善用 Phase 3 验收
- 捐赠完成时证书、积分账户、积分流水和审计与业务状态同事务提交；同一捐赠不能重复计分或同时存在多张有效证书。
- 规则按不可变版本激活，非法占位符必须拒绝；新规则只影响未来签发，既有证书保留当时标题、正文、颁发方和法律声明快照。
- 证书只能由捐赠本人查看，其他微信用户读取相同随机公开 ID 返回不存在；管理端读取/管理要求独立权限。
- 补发会撤销旧证书并保留历史，显式撤销必须填写原因；重复请求安全重放，竞态状态变化被拒绝。
- 自动积分受品类规则和单笔上限约束；人工调整必须填写原因、校验 revision、生成只追加流水且不能产生负余额。
- 小程序明确展示积分仅为公益荣誉、不可兑换/购买/转让/提现，证书明确不是捐赠收据、税务凭证或财产权利证明。