本文档定义一个务实的测试策略，用来保护当前收敛后的业务主线。
当前测试重点不再是泛化内容平台，而是以下闭环：
- 前台公开浏览
- 活动开放报名
- 加入申请
- 后台内容发布
- 后台审核与权限控制
- 在最低合适层验证最高风险逻辑
- 先保护权限、发布状态、公开写接口
- 测试范围必须跟当前产品范围同步收敛
- 不让旧
topic/city原型继续占据测试主线
当前建议分为：
- 单元测试
- 集成测试
- 端到端测试
- 手工发布检查
适合覆盖：
- 权限解析
- 发布状态判断
- 表单字段归一化
- 存储键生成
- 审计日志封装
必须优先覆盖：
- 未登录访问后台被拒绝
- 已登录但无
staff_account被拒绝 - 工作人员无权限被拒绝
- 公开接口只返回已发布内容
- 成员列表与详情按公开状态过滤
- 分会与董事会接口按公开状态过滤
- 活动开放报名提交流程可用
- 后台可审核并确认报名记录
- 加入申请提交流程可用
- 报名审核写入审核字段
- 申请审核写入审核字段
- 审计日志记录敏感写操作
- 上传完成后资源元数据正确落库
- 所有响应包含
X-Request-ID
当前前台至少应覆盖：
- 首页渲染组织介绍与 CTA
- 分会董事会页展示分会与董事会成员
- 成员列表展示与筛选
- 成员详情渲染关键字段
- 活动列表与城市筛选
- 活动详情显示报名状态
- 活动详情可提交报名
- 文章列表与详情渲染
/join页面展示申请条件/join页面内申请表可提交/apply能正确跳转到/join#application-form/about页面加载成功
当前后台至少应覆盖：
- 登录必需与受保护路由跳转
- 仪表盘显示统计与系统状态
- 文章创建、编辑、发布
- 活动创建、编辑、发布
- 活动报名审核
- 加入申请审核
- 成员编辑
- 分会与董事会维护
- 工作人员创建/编辑
- 角色权限更新
- 审计日志列表可见性
当前推荐优先保留以下 E2E：
- 工作人员登录后台
- 新建并发布一篇文章
- 新建并发布一个活动
- 前台提交活动报名，后台完成审核
- 前台提交加入申请，后台完成审核
- 新增或编辑一个成员并在前台详情页看到更新
- 维护一个分会及董事会，并在前台看到更新
- 调整一个工作人员角色并验证权限生效
- 查看审计日志中出现对应敏感操作
当前仓库中与旧 topic/city 原型相关的自动化测试，已经收敛为退场 404 断言与迁移兼容校验。
接下来测试工作应做两件事：
- 保留仍然有效的基础能力测试，如认证、限流、上传、请求追踪
- 持续围绕
branches / members / events / join / homepage主线补足页面级和业务级覆盖 - 继续保持文章发布验证不依赖旧
topic/city绑定
换句话说，测试应该跟着新的产品范围迁移，而不是继续放大旧原型。
发版前至少手工验证：
- 后台登录
- 首页内容加载
- 分会董事会页加载
- 成员列表与详情
- 活动列表与详情
- 活动报名提交
- 非成员加入申请提交
- 加入说明页与申请表提交
- 文章列表与详情
- 后台文章发布
- 后台活动报名审核
- 后台加入申请审核
- 后台成员与分会信息修改
- 后台工作人员与角色更新
- 审计日志可查看对应记录
推荐：
- 固定种子角色与权限
- 固定一个超级管理员
- 固定最小公开数据集：分会、成员、文章、活动、加入页、关于页
- 让用例尽量使用确定性数据
避免：
- 不同测试共享可变状态
- 依赖人工维护的脏数据库
在当前范围下，至少满足以下条件才算可上线：
- 权限相关集成测试通过
- 活动报名与加入申请相关集成测试通过
- 最低限度 E2E 主链路通过
- 关键前台页面无 404、无空白页
- 审计日志对敏感操作有记录