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