答题玩家 ———— 凡事预则立

[答题玩家团队账号]

这个作业属于哪个课程	2501_CS_SE_FZU
这个作业要求在哪里	团队作业——事后诸葛亮
这个作业的目标	为Beta冲刺制定详尽计划，涵盖功能、分工、工具和时间安排四大方面
其他参考文献	暂无

目录

• 下阶段改善与新增功能
• 优先完善
• 新增功能
• 扩展（未作为硬性目标）
• 团队分工改进
• Alpha阶段分工问题回顾
• Beta阶段分工与协作改进方案
• 工具流程改进
• Alpha阶段工具流程问题回顾
• Beta阶段工具流程改进方案
• 计划安排
• 事后诸葛亮博客安排
• β冲刺阶段博客安排
• β冲刺阶段具体每日安排

下阶段改善与新增功能

优先完善

• 认证与授权完善

  • 将/api/auth/mock-login规范为/api/auth/login，去掉“mock”语义；所有需要认证的接口统一开启JWT校验。现在只有登录和注册开启了JWT校验，安全性有很大隐患，后续补充接口。
  • 增加/api/auth/refresh和/api/auth/logout，实现刷新令牌与登出（可选：Redis黑名单支持令牌作废）。
  • 验收标准：登录返回Bearer令牌，受保护接口无令牌返回401，刷新令牌与登出流程联调通过。

• 请求与响应一致性

  • 对齐文档“所有POST使用{ data: ... }”的格式，统一ExamController.submit等接口的入参风格（当前使用@RequestParam）。
  • 统一响应包装Response<T>的code/message/data/timestamp字段语义与错误码规范。
  • 验收标准：所有POST接口支持标准Request<T>包裹；错误码与提示一致；全局异常返回格式统一。

• 题库与题目接口补齐

  • 新增并实现文档中缺失的接口：
    • GET /api/question-banks/{bankId}（题库详情）
    • GET /api/question-banks/page（分页与筛选）
    • GET /api/questions/bank/{bankId}（按题库取题）
    • GET /api/questions/{questionId}（题目详情）
  • 验收标准：接口返回DTO字段与文档一致；分页与筛选正确；空数据与异常处理完善。

• 考试全流程闭环

  • 已有/api/exam/start与/api/exam/submit，补充：
    • POST /api/exam/finish：结束考试，生成成绩与统计（时长、正确率、得分）。
    • GET /api/exam/record/{recordId}：查看考试记录与题目作答详情。
    • GET /api/exam/records?userId=...：分页查询我的考试/练习记录（现有/practice-records/{userId}可合并或对齐）。
  • 验收标准：从“开始—作答—提交—结束—回看”形成可追溯闭环；错题入库、成绩统计准确。

新增功能

• 错题本增强与掌握度追踪

  • 新增接口：POST /api/me/wrong-questions/master（标记为已掌握）、GET /api/me/wrong-questions/practice（仅练错题）。
  • 增加“错题次数、最近错题时间、掌握状态”的维度统计。
  • 验收标准：错题在提交失败时自动记录；能筛已掌握/未掌握；练错题专用模式可用。

• 收藏/星标题目

  • 新增：POST /api/me/favorites/toggle、GET /api/me/favorites，支持题目收藏与列表。
  • 验收标准：收藏状态与题目列表联动；题目详情页收藏按钮与接口联调通过。

• 勋章/成就系统

  • 设计成就规则（连击天数、累计答题数、正确率里程碑等），新增：
    • GET /api/me/medals、POST /api/me/medals/check（定时或在提交时评估）。这一部分不是核心功能，考虑放在最后添加，开发时与扩展部分的数据与分析同时进行，有交叉部分。验收标准：提交答案或每日登录触发成就评估；前端“medal”页面展示数据正确。

• 搜索与智能筛选

  • 新增GET /api/search/questions，支持关键词、题型、难度、题库筛选。

    现在前端已有初步的搜索功能，但是后端未能进行数据库的搜索。

  • 可选：引入MySQL全文索引（小规模先用LIKE+索引）。

  • 验收标准：搜索响应迅速、结果准确；分页与多条件组合稳定。

• 反馈与设置

  • POST /api/feedback记录用户反馈；GET /api/settings与POST /api/settings管理练习偏好（题型、难度、限时、抽题策略）。
  • 验收标准：反馈数据入库；用户设置在练习/考试生成题目时生效。

• 历年试卷与训练计划

  • 结合前端past/yearList与trains，新增：

    • GET /api/papers/year、GET /api/papers/{paperId}、POST /api/trains/generate（按偏好生成训练题集）。这一部分前端已基本完善，后端需要完成分页功能。

  • 验收标准：按年份列表加载试卷；训练计划生成可选择题型与难度；结果页统计完整。

• 管理与内容运营

  • 后台管理接口（Admin）：
    • 题库/题目CRUD、批量导入（CSV/Excel）、题目审校流程。
    • 用户管理、违规处理、公告发布。
  • 验收标准：受ROLE_ADMIN保护；审计日志可追溯；导入校验与回滚机制完善。

扩展（未作为硬性目标）

自动生成试题

如果时间充裕，考虑引入SpringAI，补充AI自动生成题目的功能，可以把生成的题目提交作为试卷。

如果可行，计划使用通义千问的api。

扩展方向可以包括：支持多种题型（判断题、简答题、编程题等）， 题目去重与质量评分 ，与现有题库混合组卷 ，

用户反馈机制优化 AI 提示词

安全与合规

这一部分编写博客人员缺乏相关知识，但安全校验必不可少，后续可改变方案。

• 认证中间件与角色权限
  • 全局JWT过滤器，放行/api/auth/*与静态资源；其余接口强校验，注入userId上下文。
  • RBAC角色：USER/ADMIN，接口鉴权注解或AOP切面。
• 防刷与反作弊
  • 对/api/exam/start与/api/exam/submit增加Redis滑动窗口限流；异常高频行为告警。
  • 考试模式引入“限时、禁止重复提交、签名校验（题目集签名+题目序列）”。
• 隐私与数据保护
  • 明文密码迁移至bcrypt；敏感字段脱敏日志；开放接口进行安全审计。
• 验收标准：限流命中返回429；权限不足返回403；密码迁移脚本完成并验证登录有效。

数据与分析

前端有这部分的页面和简单交互，这一功能不能舍弃，虽然有难度，应逐步添加这部分内容并加以完善。

• 学习数据看板

  • 新增GET /api/me/analytics：周/月统计、题型正确率、难度分布、学习时长。
  • 排行榜：GET /api/leaderboard（周榜/月榜/总榜），结合score/rank字段。

• 验收标准：数据口径清晰、与提交日志一致；前端图表展示准确。

  性能与稳定性

  由于后端开发成员不擅长此部分技术栈，这部分功能可以交给ai或者暂时搁置。

• 缓存策略

  • Redis缓存：categories、question-banks、questions/page，设置TTL与主动失效；练习记录分页可做热点缓存。

• SQL与索引优化

  • 建议索引：questions(bank_id, question_type, difficulty)、wrong_questions(user_id, question_id)、practice_records(user_id, start_time)。

• 事务与一致性

  • 提交答案、记录成绩、写入错题、更新用户统计在同一事务（必要时拆分为可靠消息+最终一致性）。

• 验收标准：热点接口响应<100ms（缓存命中）；慢查日志可定位；提交高并发下数据一致无脏写。

团队分工改进

Alpha阶段分工问题回顾

在Alpha阶段的开发中，我们遇到的主要分工与协作问题如下：

• 角色边界模糊：初期仅粗略划分为“前端”与“后端”，但在实际开发中，诸如“小程序页面路由设计”、“云函数业务逻辑分配”、“全局状态管理”等任务的责任人不明确，出现了任务重叠（多人修改同一处）和遗漏（如某些页面的测试用例缺失）的情况，影响了开发效率。

• 组间协作不畅：沟通主要依赖每日站会。当小程序前端页面逻辑需要调整或云函数接口发生变更时，信息无法及时同步，导致出现过“前端等待后端接口”或“后端接口与前端的期望不符”的进度阻塞问题。

Beta阶段分工与协作改进方案

针对上述问题，我们制定了以下改进措施：

细化角色与任务认领制：

• 角色补充与明确：

  • 小程序端开发：负责WXML/WXSS/JS编写、页面交互和用户体验优化。

  • 云开发架构：负责云函数、数据库设计、API接口规范。

  • UI/UX协调员：确保所有页面遵循统一的视觉规范，并与小程序设计指南保持一致。

  • 测试负责人：统筹测试计划，编写测试用例，重点关注小程序在不同机型上的兼容性。

• 任务看板与认领：使用GitHub Projects/Trello创建任务看板，将每项任务拆解为具体的Issue。在每日站会后，成员主动认领任务，使责任清晰可见。

• 梯队化任务分配：将“静态页面编写”、“已有Bug修复”等定义为“新手任务”，由经验较少的成员承担；而“性能优化”、“复杂云函数逻辑实现”等“核心任务”则由资深成员负责。

建立高效沟通机制：

• 核心小组短会：除每日全员站会外，由PM在每日下午固定时间组织一次前后端核心成员短会（15分钟），快速同步云函数接口变更、联调进度和当前阻塞问题。

• 接口文档契约化：任何云函数接口的变更，必须立即更新在线共享文档（如腾讯文档、Notion），并以群公告形式通知，确保前后端开发依据统一的“契约”进行。

• 定义“完成”标准：明确规定一个功能的“完成”必须包含：前端页面开发、与云函数成功联调、并通过自测。

工具流程改进

Alpha阶段工具流程问题回顾

• 版本控制不规范：虽然使用了Git，但提交信息（Commit Message）过于简单（如“更新”、“搞定”），且未与具体任务关联。在需要回溯代码、定位引入Bug的提交时非常困难，无法快速理清版本迭代脉络。

• 测试流程薄弱，缺乏自动化与智能化：

  • 测试方式原始：测试工作完全依赖冲刺末期的人工手动点按，效率低下，且每次发布都担心引入回归Bug。

  • 自动化测试缺失：未建立任何自动化测试流程（包括单元测试、端到端测试），无法快速验证代码变更的影响，耗费大量人力进行重复测试。

  • 测试场景覆盖不足：测试用例设计完全依赖人工经验，难以覆盖复杂的边界情况和异常场景，测试深度和广度有限。

  • 暂未利用新兴技术：完全没有探索和使用大模型等AI技术来辅助测试用例生成、代码审查或UI验证，错过了提升测试效率和质量的机会。

Beta阶段工具流程改进方案

推行GitHub精细化工作流：

• Issue驱动开发：所有功能、Bug修复都必须先创建GitHub Issue，并详细描述需求、验收标准和相关界面截图。

• 分支管理规范：

  • feature/*：新功能分支

  • fix/*：Bug修复分支

  • hotfix/*：紧急线上修复分支

• 规范的提交信息：强制要求Commit Message遵循约定式提交格式，例如：

  • feat(pages/index): 实现首页轮播图组件

  • fix(cloud/functions): 修复用户登录云函数token验证失败问题 Closes #15

构建多层次自动化测试体系：

• 云函数单元测试：为所有核心业务云函数引入Jest单元测试框架，确保每个函数逻辑的正确性。将单元测试覆盖率作为合并请求（Pull Request）的准入门槛之一。

• 小程序端组件/工具函数测试：针对小程序端的复杂工具函数和自定义组件，使用Jest等框架进行单元测试，保障基础代码质量。

• 端到端（E2E）自动化测试：引入MiniProgram Automator或类似工具，对小程序核心用户流程（如用户登录、核心功能操作等）编写端到端自动化测试脚本，模拟真实用户操作，确保关键路径的稳定性。

• CI/CD流水线集成：使用GitHub Actions建立持续集成流水线，在每次代码推送时自动运行单元测试和端到端测试，只有通过所有测试的代码才能合并入主分支，实现质量门禁。

探索大模型赋能的智能测试：

• AI辅助测试用例生成：利用大语言模型（如GPT系列、文心一言等）基于需求文档和接口说明，自动生成边界测试用例和异常场景测试用例，补充人工可能遗漏的测试场景。

• 智能代码审查助手：在代码审查环节，使用GitHub Copilot或类似AI工具辅助审查，快速识别潜在的代码坏味道、安全漏洞和性能问题。

• UI/UX一致性智能检查：探索使用基于计算机视觉的AI工具，对比设计稿与实现页面的差异，自动检测UI元素位置、颜色、字体等不一致问题。

• 测试数据智能生成：利用大模型根据数据结构自动生成大量、多样化的模拟测试数据，覆盖各种边界情况，提升测试的全面性。

优化测试流程与规范：

• 测试计划前置：在开发阶段初期，测试人员即根据Issue内容和AI生成的测试用例，共同制定详细的测试计划。

• 建立真机测试清单：针对微信小程序的特殊性，创建标准的真机测试清单，覆盖主流机型、微信版本和网络环境，确保每次发布前的兼容性。

• 测试报告自动化：通过CI/CD工具自动生成测试报告，包括测试覆盖率、通过率、失败用例等，便于团队快速了解代码质量状态。

计划安排

事后诸葛亮博客安排

博客内容	时间安排
α冲刺阶段问题总结	11月9号前完成撰写，于9号发布
换组交接博客	11月9前完成撰写，于9号发布
凡事预则立	11月10前完成撰写，于10号发布

β冲刺阶段博客安排

博客类型	博客内容	安排
冲刺前规划	对β冲刺阶段的计划和每天内容进行详细规划讨论（包括此次博客）	于β冲刺阶段开始前
冲刺中进程	冲刺期间每日的进程跟进，进行团队的分工及合作	每日工作内容结束及站立式会议结束后
冲刺后总结	冲刺后项目内容的实现，冲刺的结果展示，后续的计划及可能的优化	于β阶段冲刺结束后

β冲刺阶段具体每日安排

冲刺天数	阶段主要目标	计划任务内容
Day 1	冲刺启动，完善不足	在会议中详细确定计划和任务，分小队完成完成各自目标，进行α阶段结束后项目前端的内容完善及问题解决
Day 2	冲刺开始，实现功能	开始全面实现后端的功能，进行逻辑的完善，接口的搭建使用
Day 3	冲刺进行，前后结合	对完善好的前端后端进行匹配，让答题及题库功能达成真正实现，大体上完成项目程序的内容
Day 4	冲刺加速，拓展功能	寻找不足及对可拓展的更多功能进行尝试实现，提供更好的体验和功能内容
Day 5	冲刺坚持，优化突破	进行各个接口功能实现和调用的优化，进行前端界面的优化，提高反应速度
Day 6	冲刺尾声，测试修复	进行大范围的功能及代码测试，寻找可能出现的bug并依照优先级进行解决修复bug
Day 7	冲刺结束，总结发布	验证项目程序的功能实现正常，可运行展示，整理技术文档，进行冲刺的总结及博客的发布