621 lines
35 KiB
Markdown
621 lines
35 KiB
Markdown
# 1
|
||
|
||
## 角色设定
|
||
|
||
你是资深的教育家，负责学生的就业对就业市场有深刻的理解，并且了解信息化和智慧化。
|
||
|
||
## 背景
|
||
|
||
我负责一家高校的AI实验室，主要工作是高校的智慧化建设工作。
|
||
今年计算机系与我们交流，看我们能不能担起一些学生实习、实训的工作。
|
||
|
||
在对计算机系的学生宣讲完后，有40多名学生报名参加。
|
||
我对实验室承担的实习、实训工作分了一个四层漏斗，往下深入，每一层的人会更少：
|
||
|
||
1. 科普。讲解AI的通识知识，有些同学听了这些就够了。
|
||
2. 见猪跑。计划为期一到两个月，主要目的是学生了解一个软件的研发过程，从需求到部署。
|
||
3. 实习。计划两个月左右，深入了解软件开发各阶段的特点，使用AI来做需求分析、设计、编程和测试。
|
||
4. 实训。实习的佼佼者，可以加入实验室，参与我们正在做的智慧化项目。
|
||
|
||
目前见猪跑项目结束，参与的学生分三个组提交了见猪跑项目的资料。
|
||
现在进入答辩环节。
|
||
|
||
### 见猪跑
|
||
|
||
```md
|
||
# **“见猪跑”项目7周里程碑节点计划**
|
||
|
||
**总体原则：** 每周都有明确的 **目标**、清晰的 **任务**、配套的 **培训** 和可量化的 **交付成果**。
|
||
|
||
## **第一周：启动与基础 (Kick-off & Foundation)**
|
||
|
||
* **周目标：** 完成团队组建与项目启动，掌握必备的协作工具，并输出初步的产品构想。
|
||
* **核心任务 (学生)：**
|
||
* 团队内部破冰，选举小组长（项目经理）。
|
||
* 在老师指导下，讨论并选定项目选题。
|
||
* 创建项目代码仓库（Gitee/GitHub）和任务管理看板（Trello/Leangoo）。
|
||
* 集体讨论，编写出项目最核心的 **用户故事 (User Stories)** 和功能列表。
|
||
* **您的角色与培训重点：**
|
||
* **培训1：项目启动会** - 讲解“见猪跑”的目的、流程和考核方式。
|
||
* **培训2：AI在软件开发中的应用** - 宏观介绍AI如何辅助需求、设计、编码、测试，并演示GitHub Copilot等工具，激发学生兴趣。
|
||
* **培训3：协作工具入门** - **Markdown** 语法、**Git** 核心命令 (`clone`, `add`, `commit`, `push`)、**Trello** 看板的基本用法。
|
||
* **交付成果：**
|
||
* ✅ 包含初始用户故事列表的任务管理看板。
|
||
* ✅ 创建好的、所有成员均有权限的Git代码仓库。
|
||
* ✅ 一份用Markdown编写的、简单的《项目启动说明书》。
|
||
|
||
---
|
||
|
||
#### **第二周：需求与设计 (Requirement & Design)**
|
||
|
||
* **周目标：** 将模糊的想法转化为清晰、可视化的产品设计方案和技术架构蓝图。
|
||
* **核心任务 (学生)：**
|
||
* 细化用户故事，明确每个功能的验收标准（Acceptance Criteria）。
|
||
* 使用原型工具绘制应用的主要界面 **线框图 (Wireframe)** 或高保真原型。
|
||
* 进行技术选型（如：前端Vue，后端Python+Flask）。
|
||
* 设计数据库的核心 **表结构 (Schema)**。
|
||
* 定义核心功能的 **API接口文档**。
|
||
* **您的角色与培训重点：**
|
||
* **培训1：如何写好需求** - 用户故事与验收标准的撰写技巧。
|
||
* **培训2：产品原型设计** - Figma或MasterGo等工具的快速入门。
|
||
* **培训3：后端基础** - 什么是RESTful API、数据库表设计三范式、Postman工具的使用。
|
||
* **交付成果：**
|
||
* ✅ 包含主要页面的Figma/MasterGo原型链接。
|
||
* ✅ 完整的数据库表结构设计图。
|
||
* ✅ 使用Postman或Markdown编写的核心API文档初稿。
|
||
|
||
---
|
||
|
||
#### **第三周：开发迭代一 (Sprint 1 - 搭建骨架)**
|
||
|
||
* **周目标：** 完成项目技术架构的搭建，并实现用户注册/登录等基础核心功能。
|
||
* **核心任务 (学生)：**
|
||
* 统一并搭建好本地开发环境。
|
||
* 搭建前后端项目的基础工程结构。
|
||
* 完成后端的用户模块API（注册、登录、获取用户信息）。
|
||
* 完成前端的登录/注册页面，并与后端API联调通过。
|
||
* **您的角色与培训重点：**
|
||
* **培训1：前后端框架入门** - Vue和Flask/Django的项目创建与核心概念。
|
||
* **培训2：Git分支管理** - 学习`develop`分支、`feature`分支的工作流。
|
||
* **指导：** 帮助学生解决环境配置、跨域（CORS）等初期常见问题。
|
||
* **交付成果：**
|
||
* ✅ 一个可以运行的前后端项目骨架。
|
||
* ✅ 用户可以成功通过界面完成注册和登录功能。
|
||
|
||
---
|
||
|
||
#### **第四周：开发迭代二 (Sprint 2 - 核心功能实现)**
|
||
|
||
* **周目标：** 完成项目最核心的业务功能模块的开发。
|
||
* **核心任务 (学生)：**
|
||
* **后端：** 开发核心业务API（例如：“失物招领”的发布、列表功能；“会议室预定”的预定、查询功能）。
|
||
* **前端：** 开发核心功能的展示与交互界面。
|
||
* 前后端进行核心功能的接口联调。
|
||
* **您的角色与培训重点：**
|
||
* **培训1：数据库操作** - ORM（如SQLAlchemy）的使用，数据库增删改查。
|
||
* **培训2：前端组件化开发** - 如何将页面拆分成可复用的组件。
|
||
* **Code Review：** 开始引导学生进行代码互评，提升代码质量。
|
||
* **交付成果：**
|
||
* ✅ 项目核心功能（如发布失物、预定会议室）可以完整跑通。
|
||
|
||
---
|
||
|
||
#### **第五周：开发迭代三 (Sprint 3 - 功能完善)**
|
||
|
||
* **周目标：** 完成其余的辅助功能，使项目功能趋于完整。
|
||
* **核心任务 (学生)：**
|
||
* 开发搜索、筛选、个人中心、详情页等辅助功能。
|
||
* 对已有功能进行优化和细节调整。
|
||
* 继续进行前后端联调和Bug修复。
|
||
* **您的角色与培训重点：**
|
||
* **培训1：应用状态管理** - 前端Vuex/Pinia等工具的使用。
|
||
* **指导：** 引导学生思考如何处理异常情况和边界条件。
|
||
* **交付成果：**
|
||
* ✅ 项目达到“功能完整”状态，所有计划内的主要、次要功能均已开发完成。
|
||
|
||
---
|
||
|
||
#### **第六周：测试与文档周 (Testing & Documentation)**
|
||
|
||
* **周目标：** 集中进行项目测试，修复Bug，确保软件质量，并完善项目文档。
|
||
* **核心任务 (学生)：**
|
||
* **全员测试：** 小组内所有成员交叉测试彼此开发的功能，记录Bug。
|
||
* **集中修复：** 集中精力解决测试中发现的Bug。
|
||
* **文档完善：** 撰写详细的《项目README文档》，包括项目介绍、技术栈、如何运行、部署说明等。
|
||
* **您的角色与培训重点：**
|
||
* **培训1：如何有效提Bug** - 学习编写清晰的Bug报告（重现步骤、期望结果、实际结果）。
|
||
* **培训2：浏览器调试技巧** - Chrome DevTools的深入使用。
|
||
* **交付成果：**
|
||
* ✅ 一个相对稳定的、Bug较少的待部署版本。
|
||
* ✅ 一份高质量、内容详尽的 `README.md` 文件。
|
||
|
||
---
|
||
|
||
#### **第七周：部署与复盘 (Deployment & Showcase)**
|
||
|
||
* **周目标：** 将项目成功部署到线上服务器，并进行项目总结与成果展示。
|
||
* **核心任务 (学生)：**
|
||
* 在老师指导下，学习并完成项目部署。
|
||
* 准备项目展示的PPT和演示稿。
|
||
* 进行小组内部和全体的 **项目复盘 (Retrospective)**，总结经验教训。
|
||
* **最终成果展示会！**
|
||
* **您的角色与培训重点：**
|
||
* **培训1：应用部署入门** - Docker基础、Nginx反向代理配置、服务器SSH操作入门。
|
||
* **组织与主持：** 组织最终的项目展示会，并进行点评。
|
||
* **交付成果：**
|
||
* ✅ 一个可以通过公网访问的应用URL。
|
||
* ✅ 一份项目展示PPT。
|
||
* ✅ 每位同学提交一份“见猪跑”实习总结报告。
|
||
|
||
```
|
||
|
||
### 答辩材料
|
||
|
||
```md
|
||
|
||
# 在线问卷/投票系统项目答辩材料
|
||
|
||
## 1. 项目概述
|
||
|
||
### 1.1 项目背景
|
||
在当今数字化时代，传统的纸质问卷已经无法满足高效、便捷的数据收集需求。学生会、社团及课程小组等团体在组织活动、收集意见时，常常面临以下痛点：
|
||
- 纸质问卷打印成本高、分发效率低
|
||
- 人工统计数据耗时耗力，容易出错
|
||
- 无法实时查看问卷回收情况
|
||
- 数据可视化程度低，难以直观分析
|
||
|
||
本项目旨在开发一个高效的在线问卷与投票工具，解决上述问题，提供一个便捷的平台，支持用户快速创建、发布、分享并自动统计问卷结果。
|
||
|
||
### 1.2 项目目标
|
||
1. **功能完整性**：支持多种题型、问卷管理、发布分享、结果统计等核心功能
|
||
2. **易用性**：提供直观友好的用户界面，降低使用门槛
|
||
3. **高效性**：实现问卷快速创建、发布和结果实时统计
|
||
4. **可扩展性**：采用模块化设计，便于后续功能扩展
|
||
5. **安全性**：确保用户数据和问卷内容的安全
|
||
|
||
### 1.3 项目团队
|
||
- **团队名称**：24计升集中实习奋斗项目组
|
||
- **团队成员**：陈浩东 白一帆 张赛琦 许雨孜 刘雪坤 杜蓉悦 李泽昕 陈毅 李轩昊 赵江恒 白锦程 田昭阳
|
||
|
||
### 1.4 团队分工
|
||
| 成员 | 负责模块 |
|
||
|------|----------|
|
||
|白锦程 田昭阳 | 需求分析 |
|
||
| 李轩昊 赵江恒 | 数据库设计 |
|
||
| 李泽昕 陈毅 | 测试 |
|
||
| 白一帆 | 部署 |
|
||
| 张赛琦 许雨孜 刘雪坤 杜蓉悦 | 材料的编写 |
|
||
|
||
## 2. 需求分析
|
||
|
||
|
||
### 2.2 核心功能需求
|
||
1. **问卷管理**：创建、编辑、删除、复制问卷
|
||
2. **问卷设计**：支持单选题、多选题、文本题等多种题型
|
||
3. **问卷发布**：生成分享链接，支持实时状态管理
|
||
4. **问卷填写**：简洁易用的填写界面
|
||
5. **结果统计**：实时数据统计与可视化图表展示
|
||
|
||
## 3. 系统设计
|
||
|
||
### 3.1 系统架构
|
||
- **前端**：HTML/CSS/JavaScript，使用Bootstrap等前端框架
|
||
- **后端**：Python Flask框架
|
||
- **数据库**：SQLite（开发环境）/MySQL（生产环境）
|
||
- **认证机制**：JWT Token认证
|
||
|
||
|
||
### 3.2 API设计
|
||
| API路径 | 方法 | 功能描述 | 请求参数 | 响应格式 | 认证要求 |
|
||
|---------|------|----------|----------|----------|----------|
|
||
| /api/login | POST | 用户登录，返回访问令牌和刷新令牌 | `username` (string, 必需)，`password` (string, 必需) | `{"code": 200, "message": "登录成功", "data": {"token": "...", "refresh_token": "...", "user": {...}}}` | 否 |
|
||
| /api/refresh | POST | 使用刷新令牌获取新的访问令牌 | `refresh_token` (string, 必需) | `{"code": 200, "message": "令牌刷新成功", "data": {"token": "..."}}` | 是 |
|
||
| /api/verify-token | POST | 验证访问令牌有效性 | Authorization头: `Bearer <token>` | `{"code": 200, "message": "令牌有效", "data": {"user": {...}, "expires_at": 1234567890}}` | 是 |
|
||
| /api/questionnaire/list | GET | 获取当前用户的问卷列表，支持分页和搜索 | `page` (int, 默认1)，`pageSize` (int, 默认10)，`title` (string, 可选) | `{"code": 200, "message": "获取问卷列表成功", "data": {"list": [...], "total": 100, "page": 1, "pageSize": 10}}` | 是 |
|
||
| /api/questionnaire/create | POST | 创建新问卷，包含题目和选项 | `title` (string, 必需)，`description` (string, 可选)，`questions` (array, 可选) | `{"code": 200, "message": "创建问卷成功", "data": {"id": 1}}` | 是 |
|
||
| /api/questionnaire/<int:questionnaire_id> | GET | 获取问卷详情，包含题目和选项（公开访问） | 无 | `{"code": 200, "message": "获取问卷详情成功", "data": {...}}` | 否 |
|
||
| /api/questionnaire/<int:questionnaire_id> | PUT | 更新问卷及其题目和选项 | `title` (string, 必需)，`description` (string, 可选)，`questions` (array, 可选) | `{"code": 200, "message": "问卷更新成功", "data": {"id": 1}}` | 是 |
|
||
| /api/questionnaire/<int:questionnaire_id> | DELETE | 删除问卷（预留接口） | 无 | `{"code": 200, "message": "删除问卷功能待实现", "data": null}` | 是 |
|
||
| /api/questionnaire/<int:questionnaire_id>/publish | POST | 发布问卷，将状态改为进行中 | 无 | `{"code": 200, "message": "问卷发布成功", "data": {"id": 1, "status": "published"}}` | 是 |
|
||
| /api/questionnaire/<int:questionnaire_id>/statistics | GET | 获取问卷统计结果，包含选择题统计和文本题列表 | 无 | `{"code": 200, "message": "获取问卷统计结果成功", "data": {"submission_count": 100, "questions": [...]}}` | 是 |
|
||
| /api/questionnaire/<int:questionnaire_id>/submit | POST | 提交问卷答案，增加问卷提交计数 | `answers` (array, 必需) | `{"code": 200, "message": "问卷提交成功", "data": {"submission_id": 1}}` | 否 |
|
||
|
||
## 4. 数据库设计
|
||
|
||
### 4.1 数据库表结构
|
||
系统包含6个核心表：
|
||
|
||
1. **users**：系统用户表（管理员和普通用户）
|
||
2. **questionnaires**：问卷主表
|
||
3. **questions**：问卷题目表
|
||
4. **options**：题目选项表
|
||
5. **submissions**：用户提交记录表
|
||
6. **answers**：具体题目答案表
|
||
|
||
### 4.2 核心表关系
|
||
```
|
||
users (1:N) questionnaires (1:N) questions (1:N) options
|
||
questionnaires (1:N) submissions (1:N) answers
|
||
questions (1:N) answers
|
||
```
|
||
|
||
### 4.3 关键表设计示例
|
||
```sql
|
||
-- 问卷主表
|
||
CREATE TABLE `questionnaires` (
|
||
`id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '问卷ID',
|
||
`creator_id` BIGINT UNSIGNED NOT NULL COMMENT '创建者ID',
|
||
`title` VARCHAR(50) NOT NULL COMMENT '问卷标题',
|
||
`description` TEXT COMMENT '问卷说明',
|
||
`status` VARCHAR(20) NOT NULL DEFAULT 'draft' COMMENT '状态',
|
||
`submission_count` INT UNSIGNED NOT NULL DEFAULT 0 COMMENT '总回收量',
|
||
`created_at` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
|
||
PRIMARY KEY (`id`),
|
||
CONSTRAINT `fk_q_creator` FOREIGN KEY (`creator_id`) REFERENCES `users` (`id`) ON DELETE CASCADE
|
||
) ENGINE=InnoDB;
|
||
```
|
||
|
||
## 5. 功能模块实现
|
||
|
||
### 5.1 用户认证模块
|
||
- **登录功能**：支持账号密码登录，前端实现实时表单验证
|
||
- **JWT Token管理**：采用JSON Web Token实现无状态认证，Token有效期24小时
|
||
- **权限控制**：基于角色的访问控制，区分普通用户和管理员权限
|
||
- **密码安全**：使用BCrypt算法对密码进行哈希存储，确保密码安全
|
||
|
||
### 5.2 问卷管理模块
|
||
- **问卷列表展示**：支持按标题搜索、分页（每页10条）、状态筛选
|
||
- **问卷状态管理**：实现草稿、进行中、已结束三种状态的流转
|
||
- **问卷操作**：支持查看、编辑、复制、删除等操作，编辑仅允许草稿状态
|
||
- **批量操作**：支持多选删除、批量复制等高效操作
|
||
|
||
### 5.3 问卷设计模块
|
||
- **多种题型支持**：实现单选题、多选题、单行文本、多行文本等题型
|
||
- **题目管理**：支持题目添加、删除、复制、上移、下移等操作
|
||
- **选项管理**：动态添加、删除选项，支持选项文字编辑
|
||
- **拖拽排序**：实现题目拖拽排序功能，提升用户体验
|
||
- **实时保存**：每30秒自动保存草稿到本地，防止数据丢失
|
||
- **预览功能**：实时预览问卷最终效果，支持PC和移动端预览
|
||
|
||
### 5.4 问卷发布模块
|
||
- **一键发布**：点击发布按钮即可将问卷状态改为进行中
|
||
- **分享链接生成**：自动生成唯一的问卷访问链接
|
||
- **截止时间设置**：支持设置问卷截止时间，到期自动结束
|
||
- **实时状态监控**：随时查看问卷回收进度和状态
|
||
|
||
### 5.5 问卷填写模块
|
||
- **响应式设计**：适配PC、平板、手机等不同设备
|
||
- **流畅的填写体验**：清晰的题目布局，直观的选项设计
|
||
- **实时校验**：前端实现必答题校验，未填写时给出明确提示
|
||
- **防重复提交**：实现表单重复提交防护机制
|
||
- **提交反馈**：提交成功后显示感谢页面，提交失败给出错误提示
|
||
|
||
### 5.6 结果统计模块
|
||
- **实时数据更新**：每5秒自动刷新统计数据
|
||
- **数据概览**：显示总回收量、平均完成时间、浏览量等关键指标
|
||
- **可视化图表**：
|
||
- 单选题：饼图展示各选项占比
|
||
- 多选题：柱状图展示各选项选择次数
|
||
- 文本题：文本云展示高频词汇
|
||
- **详细数据查看**：支持查看单份答卷详情，支持按时间筛选
|
||
- **数据导出**：支持将统计结果导出为Excel格式
|
||
|
||
### 5.7 技术实现要点
|
||
1. **前后端数据交互**：采用JSON格式进行数据传输，API遵循RESTful设计规范
|
||
2. **JWT认证机制**：
|
||
- 使用Flask-JWT-Extended实现token生成和验证
|
||
- 访问令牌有效期1小时，刷新令牌有效期7天
|
||
- 实现了令牌刷新和验证接口
|
||
- 提供了@jwt_required装饰器进行身份验证
|
||
- 实现了基于角色的访问控制（role_required装饰器）
|
||
3. **数据库事务处理**：问卷创建、更新和提交操作采用事务管理，确保数据一致性
|
||
4. **模块化设计**：
|
||
- 认证模块和问卷模块分离，便于维护和扩展
|
||
- 提供了JWT工具类，封装了常用的认证功能
|
||
5. **跨域支持**：使用Flask-CORS实现跨域资源共享
|
||
6. **数据库设计**：采用SQLAlchemy ORM框架，实现了表与表之间的关系映射
|
||
|
||
## 6. 系统亮点
|
||
|
||
### 6.1 技术亮点
|
||
1. **前后端分离**：便于团队协作和系统扩展
|
||
2. **JWT认证**：提供安全的用户认证机制
|
||
3. **响应式设计**：适配各种设备屏幕
|
||
4. **实时数据更新**：确保用户看到最新数据
|
||
5. **模块化设计**：便于功能扩展和维护
|
||
|
||
### 6.2 功能亮点
|
||
1. **多种题型支持**：满足不同场景需求
|
||
2. **直观的问卷设计界面**：降低使用门槛
|
||
3. **便捷的分享功能**：扩大问卷传播范围
|
||
4. **丰富的数据可视化**：便于数据分析
|
||
5. **完善的状态管理**：灵活控制问卷生命周期
|
||
|
||
## 7. 项目实施
|
||
|
||
### 7.1 开发环境搭建
|
||
1. **Python环境**：安装Python 3.8+，使用virtualenv创建虚拟环境
|
||
2. **依赖安装**：使用pip安装Flask及相关依赖（requirements.txt）
|
||
3. **数据库初始化**：执行数据库迁移脚本，创建表结构
|
||
4. **开发服务器启动**：运行`python app.py`启动本地开发服务器
|
||
|
||
### 7.2 部署方案
|
||
- **开发环境**：本地开发，使用SQLite数据库
|
||
- **测试环境**：阿里云ECS服务器，使用MySQL数据库
|
||
- **生产环境**：建议使用云服务器集群+负载均衡，数据库采用主从复制架构
|
||
|
||
### 7.3 项目管理
|
||
- **开发模式**：采用敏捷开发模式，两周一个迭代
|
||
- **版本控制**：使用Git进行代码管理，GitHub作为代码仓库
|
||
- **任务管理**：使用Trello进行任务分配和进度跟踪
|
||
- **代码规范**：遵循PEP8 Python代码规范，使用flake8进行代码检查
|
||
|
||
### 7.4 项目进度
|
||
| 阶段 | 时间 | 完成情况 | 主要成果 |
|
||
|------|------|----------|----------|
|
||
| 需求分析 | 第1周 | ✅ 完成 | 需求文档、用户故事 |
|
||
| 系统设计 | 第2周 | ✅ 完成 | 系统架构图、数据库设计 |
|
||
| 后端开发 | 第3-4周 | ✅ 完成 | API实现、数据库模型 |
|
||
| 前端开发 | 第5-6周 | ✅ 完成 | 页面开发、交互实现 |
|
||
| 测试与调试 | 第7周 | ✅ 完成 | 测试报告、bug修复 |
|
||
| 部署上线 | 第8周 | ✅ 完成 | 系统部署、文档编写 |
|
||
|
||
### 7.5 技术难点与解决方案
|
||
1. **问题**：问卷设计时的实时保存机制
|
||
**解决方案**：使用localStorage结合定时任务实现自动保存，每30秒保存一次
|
||
|
||
2. **问题**：问卷结果的实时统计
|
||
**解决方案**：采用WebSocket实现数据实时推送，或使用定时轮询（每5秒）
|
||
|
||
3. **问题**：多种题型的动态渲染
|
||
**解决方案**：使用组件化设计，针对不同题型开发独立组件
|
||
|
||
4. **问题**：防止问卷重复提交
|
||
**解决方案**：使用Token机制，每次提交生成唯一Token，服务器验证后失效
|
||
|
||
## 8. 测试与验证
|
||
|
||
### 8.1 测试策略
|
||
1. **单元测试**：使用pytest框架，覆盖率达到80%以上
|
||
2. **集成测试**：测试API接口间的交互，确保数据流转正确
|
||
3. **功能测试**：基于需求文档编写测试用例，验证所有功能点
|
||
4. **性能测试**：使用JMeter进行压力测试，确保系统能承受100并发访问
|
||
5. **安全性测试**：测试SQL注入、XSS攻击等安全漏洞
|
||
6. **用户体验测试**：邀请10名用户进行测试，收集反馈意见
|
||
|
||
### 8.2 测试用例示例
|
||
| 测试用例ID | 功能模块 | 测试场景 | 预期结果 | 实际结果 | 状态 |
|
||
|------------|----------|----------|----------|----------|------|
|
||
| TC_001 | 登录功能 | 正确账号密码登录 | 登录成功，返回访问令牌 | 通过 | ✅ |
|
||
| TC_002 | 登录功能 | 错误密码登录 | 登录失败，提示账号或密码错误 | 通过 | ✅ |
|
||
| TC_003 | 问卷管理 | 获取问卷列表 | 成功获取问卷列表，包含分页信息 | 通过 | ✅ |
|
||
| TC_004 | 问卷管理 | 创建包含多种题型的问卷 | 问卷创建成功，状态为草稿 | 通过 | ✅ |
|
||
| TC_005 | 问卷管理 | 发布问卷 | 问卷状态改为进行中 | 通过 | ✅ |
|
||
| TC_006 | 问卷填写 | 完整填写并提交问卷 | 提交成功，返回提交ID | 通过 | ✅ |
|
||
| TC_007 | 问卷统计 | 获取问卷统计结果 | 成功获取问卷统计数据，包含各题型的统计信息 | 通过 | ✅ |
|
||
| TC_008 | 认证功能 | 刷新访问令牌 | 成功获取新的访问令牌 | 通过 | ✅ |
|
||
| TC_009 | 认证功能 | 验证令牌有效性 | 正确返回令牌状态和用户信息 | 通过 | ✅ |
|
||
| TC_010 | 问卷管理 | 更新问卷内容 | 问卷更新成功，保留历史数据 | 通过 | ✅ |
|
||
|
||
### 8.3 测试结果
|
||
- **功能测试**：共执行120个测试用例，通过率98.3%
|
||
- **性能测试**：
|
||
- 平均响应时间：<500ms
|
||
- 并发用户数：支持100并发
|
||
- 系统稳定性：持续运行24小时无故障
|
||
- **安全性测试**：未发现严重安全漏洞
|
||
- **用户体验测试**：用户满意度评分4.5/5
|
||
|
||
### 8.4 质量保证
|
||
- 建立代码审查机制，确保代码质量
|
||
- 使用CI/CD pipeline自动运行测试
|
||
- 定期进行bug统计和分析，持续改进
|
||
|
||
## 9. 未来展望
|
||
|
||
### 9.1 功能扩展
|
||
1. **高级题型支持**：添加矩阵题、量表题、排序题、上传题等高级题型
|
||
2. **问卷模板库**：建立丰富的问卷模板库，支持一键套用
|
||
3. **数据分析增强**：
|
||
- 实现交叉分析功能
|
||
- 添加数据可视化自定义
|
||
- 支持生成数据分析报告
|
||
4. **协作编辑功能**：支持多人同时编辑同一问卷
|
||
5. **问卷逻辑跳转**：实现基于答案的动态逻辑跳转
|
||
6. **用户管理系统**：增强用户管理功能，支持用户分组、权限细化
|
||
|
||
### 9.2 性能优化
|
||
1. **数据库优化**：
|
||
- 优化查询语句，添加适当索引
|
||
- 实现数据库读写分离
|
||
- 考虑使用NoSQL存储部分数据
|
||
2. **前端优化**：
|
||
- 资源压缩和CDN加速
|
||
- 实现懒加载和代码分割
|
||
- 优化页面渲染性能
|
||
3. **缓存机制**：
|
||
- 使用Redis缓存热门问卷数据
|
||
- 实现API响应缓存
|
||
4. **高并发支持**：
|
||
- 优化系统架构，支持水平扩展
|
||
- 使用消息队列处理异步任务
|
||
|
||
### 9.3 安全性增强
|
||
1. **验证码功能**：添加图形验证码或行为验证码，防止恶意登录
|
||
2. **访问控制**：实现IP限制、访问频率限制
|
||
3. **数据安全**：
|
||
- 增强数据加密机制
|
||
- 实现数据备份和恢复策略
|
||
- 完善数据脱敏处理
|
||
4. **日志系统**：
|
||
- 完善系统日志记录
|
||
- 实现日志分析和告警功能
|
||
|
||
## 10. 项目成果展示
|
||
|
||
### 10.1 主要页面截图
|
||
1. **登录页面**：简洁的登录界面，支持实时表单验证
|
||
2. **问卷管理页面**：清晰的问卷列表，支持搜索、筛选和各种操作
|
||
3. **问卷设计页面**：直观的拖拽式问卷设计界面
|
||
4. **问卷填写页面**：响应式设计，适配各种设备
|
||
5. **结果统计页面**：丰富的数据可视化图表
|
||
|
||
### 10.2 核心功能演示
|
||
1. **问卷创建流程**：从创建到发布的完整流程
|
||
2. **问卷填写体验**：流畅的填写过程和实时验证
|
||
3. **结果统计展示**：实时数据更新和可视化图表
|
||
4. **问卷分享功能**：一键生成分享链接
|
||
|
||
## 11. 使用说明
|
||
|
||
### 11.1 管理员账号
|
||
- 用户名：admin
|
||
- 密码：admin123
|
||
|
||
### 11.2 快速入门
|
||
1. 登录系统
|
||
2. 点击"新建问卷"按钮创建问卷
|
||
3. 设计问卷内容（添加题目、设置选项等）
|
||
4. 点击"保存草稿"或"发布"按钮
|
||
5. 发布后生成分享链接，可分享给他人填写
|
||
6. 在问卷列表中查看回收结果和统计数据
|
||
|
||
### 11.3 常见问题
|
||
1. **问题**：忘记密码怎么办？
|
||
**解决方案**：联系管理员重置密码
|
||
|
||
2. **问题**：问卷发布后还能编辑吗？
|
||
**解决方案**：问卷发布后不能直接编辑，需要先结束问卷，然后复制为新问卷进行编辑
|
||
|
||
3. **问题**：如何查看问卷填写详情？
|
||
**解决方案**：在问卷列表中点击"查看结果"，然后选择"查看答卷详情"
|
||
|
||
## 12. 总结
|
||
|
||
### 12.1 项目成果
|
||
本项目成功开发了一个功能完整、易用性强的在线问卷/投票系统，主要成果包括：
|
||
1. 实现了完整的问卷生命周期管理：创建、编辑、发布、填写、统计
|
||
2. 支持多种题型和丰富的问卷设计功能
|
||
3. 提供了直观友好的用户界面和流畅的操作体验
|
||
4. 实现了实时数据统计和丰富的数据可视化
|
||
5. 采用了现代化的技术栈和良好的系统架构
|
||
|
||
### 12.2 经验教训
|
||
1. **需求分析的重要性**：充分的需求分析是项目成功的基础，避免了后期频繁的需求变更
|
||
2. **模块化设计的优势**：模块化设计便于功能扩展和维护，提高了开发效率
|
||
3. **测试的必要性**：全面的测试确保了系统的质量和稳定性
|
||
4. **团队协作的重要性**：良好的团队协作和沟通是项目成功的关键
|
||
5. **文档的价值**：完善的文档便于系统维护和后续开发
|
||
|
||
### 12.3 个人收获
|
||
通过本项目的开发，团队成员在以下方面获得了提升：
|
||
1. 掌握了Web应用开发的全流程
|
||
2. 熟悉了现代化的技术栈和开发工具
|
||
3. 提高了团队协作和项目管理能力
|
||
4. 增强了问题分析和解决能力
|
||
5. 积累了系统设计和架构经验
|
||
|
||
## 13. 致谢
|
||
|
||
感谢各位老师的指导，感谢团队成员的协作努力。
|
||
|
||
```
|
||
|
||
## 思路
|
||
|
||
我已经试用了这个组部署的服务，系统能够使用。从成果上讲，基本上达成了我想要做的见猪跑目标。
|
||
他们现在要进入答辩环节，答辩完成后，我将给他们一份实习证明。
|
||
我计划从这个组中抽取（或者全部）人员加入我们的实习项目，真正去做一个软件项目，同时给实验室提供生力军——完成一些体力活。
|
||
我不想以问题的形式——不克扣，而是以交流的形式进行答辩。了解每个人的想法，从中学习到的内容，对未来的想法，以及有什么问题。
|
||
|
||
## 指令
|
||
|
||
我需要你帮我整理：
|
||
1. 答辩形式建议，比如每个人都谈下想法，到开发的具体过程时，以负责人为主，其他人可以补充等等；
|
||
2. 答辩讨论的问题，及相关问题的考察点。
|
||
|
||
你好！很高兴看到这批学生顺利完成了“见猪跑”环节。对于一支由12名大二/大三学生组成的团队，能在7周内从0到1交付一个可部署、功能完整的Web应用，并且文档如此详尽，这本身就是一个非常值得肯定的成果。
|
||
|
||
特别是你提到**“不想克扣分数，而是以交流的形式，了解想法，选拔实习生”**，这非常符合现代科技企业和高水平实验室的选人逻辑——**比起“现在的代码水平”，我们更看重“学习潜力和工程思维”**。
|
||
|
||
针对这12人的庞大队伍（对于一个CRUD项目来说，12人确实稍显拥挤，容易出现“搭便车”现象），我建议采用**“分组聚焦 + 个人复盘”**的答辩策略。
|
||
|
||
以下是为你整理的答辩形式建议与讨论问题库。
|
||
|
||
---
|
||
|
||
### 第一部分：答辩形式建议 (时长控制在 60-90 分钟)
|
||
|
||
既然目的是选拔“实习”阶段的生力军，答辩现场的气氛应当是**“轻松但专业”**的。我们要把这里变成一个技术复盘会（Retrospective），而不是期末考试。
|
||
|
||
**建议流程：**
|
||
|
||
1. **成果演示 (10分钟) —— 由项目经理（小组长）主讲**
|
||
* **内容**：不仅仅是PPT念稿，而是直接打开浏览器，演示上线的功能。重点演示核心业务流程（创建->发布->填写->统计）。
|
||
* **目的**：确认交付物的真实性，给团队一个展示的高光时刻。
|
||
|
||
2. **“真心话”圆桌 (20-30分钟) —— 全员参与，每人2分钟**
|
||
* **形式**：不要按分工坐，打乱顺序。每个人简短回答三个问题：
|
||
* *在这个项目中，我最自豪的一个细节是什么？*
|
||
* *如果时间倒流，我会在哪个环节做得不一样？*
|
||
* *我对下一阶段（AI辅助开发）有什么期待？*
|
||
* **目的**：这是选人的关键。**过滤掉“混子”，识别出“有思考的人”。** 有些人可能代码写得少，但思考很深；有些人可能只是机械执行。
|
||
|
||
3. **模块化深度交流 (30分钟) —— 分角色切入，自由补充**
|
||
* **形式**：你抛出问题，主要负责人回答，鼓励其他组员补充或提出异议（比如开发吐槽需求变动，测试吐槽Bug难复现）。
|
||
* **目的**：考察技术深度和协作中的摩擦点。
|
||
|
||
4. **导师寄语与邀约 (10分钟)**
|
||
* **内容**：点评项目亮点，指出工业界的真实做法与他们目前的差距（这是教育者的价值），并发出实习邀请。
|
||
|
||
---
|
||
|
||
### 第二部分：交流问题与考察点
|
||
|
||
这些问题不是为了难倒学生，而是为了看他们是否“真懂”，以及他们的思维方式。
|
||
|
||
#### 1. 面向“需求与设计”组 (白锦程、田昭阳、李轩昊、赵江恒)
|
||
*这组人决定了项目的方向和地基。*
|
||
|
||
* **问题 A**：我看你们用了12个人做这个项目，沟通成本很高。在需求分析阶段，你们是如何决定“哪些功能必须做”而“哪些功能由于时间不够先砍掉”的？有没有发生过争执？
|
||
* **考察点**：**产品思维与优先级管理**。看他们是否懂得MVP（最小可行性产品）概念，还是全凭拍脑袋。
|
||
* **问题 B**：数据库设计里，你们把`submissions`（提交记录）和`answers`（具体答案）分开了。当时是怎么考虑的？如果一个问卷有100个问题，10000人填写，在这个表结构下查询会不会变慢？
|
||
* **考察点**：**数据建模能力与性能意识**。看他们是否理解范式设计，以及对大数据量下的性能有没有初步概念。
|
||
|
||
#### 2. 面向“开发与部署”组 (白一帆、项目全栈人员)
|
||
*这组人是干实活的核心，也是未来实验室的“熟练工”预备役。*
|
||
|
||
* **问题 A**：既然我们是AI实验室，在这次写代码的过程中，你们有没有尝试使用AI工具（如ChatGPT, Copilot等）？是在写SQL、写正则，还是Debug时用的？感觉它帮了倒忙还是大忙？
|
||
* **考察点**：**AI工具的亲和度与真实感悟**。实习阶段需要大量用AI，这里考察他们是否已经不仅是“听过”，而是“用过”并有自己的判断。
|
||
* **问题 B**：在这个项目中，最让你头疼的一个Bug是什么？你是怎么定位并解决它的？（比如JWT的过期处理，或者跨域问题）
|
||
* **考察点**：**问题解决能力**。优秀的工程师擅长讲故事，讲他如何战胜Bug的过程。
|
||
* **问题 C**：我看后端用了Python Flask。如果现在让你把这个项目部署到学校所有的社团使用，并发量突然变大，你觉得目前的架构哪里会最先撑不住？
|
||
* **考察点**：**系统架构的扩展性**。考察是否了解Web服务器、数据库连接池、缓存等概念，即便没做，也要有概念。
|
||
|
||
#### 3. 面向“测试与文档”组 (李泽昕、陈毅、张赛琦、许雨孜、刘雪坤、杜蓉悦)
|
||
*这组人数最多（6人），最容易出现“搭便车”。需要重点考察他们是否真正深入理解了系统。*
|
||
|
||
* **问题 A (针对测试)**：你们报告里写测试通过率98.3%。请问那个失败的1.7%是什么？在测试过程中，有没有发现过那种“开发人员觉得不是Bug，但你们觉得是Bug”的情况？
|
||
* **考察点**：**质量意识与批判性思维**。测试不仅仅是点点点，而是要敢于挑战开发。
|
||
* **问题 B (针对文档)**：你们有4个人负责编写材料。作为一个开发者，最讨厌写文档。你们是如何分工的？在写API文档时，你们是看着代码写的，还是先写文档让开发去实现的？
|
||
* **考察点**：**协作流程理解**。如果是“看着代码写文档”，那是事后诸葛亮；如果是“先写文档”，那是优秀的设计驱动开发。我想确认他们是否真的理解代码逻辑，而不是纯粹的文字搬运工。
|
||
|
||
#### 4. 面向全员的“灵魂拷问” (抢答或指定)
|
||
|
||
* **问题**：如果在接下来的实习中，我们要把这个问卷系统加入**“AI智能分析”**功能，比如自动总结问卷里的文本回答，或者自动生成问卷题目。你们觉得应该加在哪个模块？大概需要用到什么技术？
|
||
* **考察点**：**技术视野与创新力**。这是为了筛选进入第三层漏斗（实习）的最佳人选。看谁能跳出CRUD的思维，对接实验室的业务方向。
|
||
|
||
---
|
||
|
||
### 第三部分：选拔建议（您的私下评估表）
|
||
|
||
在听取回答时，建议您在心里（或笔记本上）为每个人打这三个标签：
|
||
|
||
1. **Tech Lead 苗子**：逻辑清晰，不仅懂代码还懂架构，能回答出“为什么这么做”。 -> **重点培养，给有挑战的任务。**
|
||
2. **Solid Doer (靠谱执行者)**：代码写得多，Bug解得快，虽然话不多但对技术细节如数家珍。 -> **实验室主力，负责具体模块开发。**
|
||
3. **Communication Hub (润滑剂)**：也许代码一般，但非常清楚团队在干什么，文档写得极好，能协调矛盾。 -> **适合做PM或负责需求与测试，协助管理项目。**
|
||
4. *(如果发现)* **Free Rider (搭便车者)**：对自己负责模块的细节支支吾吾，都在讲空话。 -> **礼貌地发一份“见猪跑”结业证书，但这层漏斗就此截止。**
|
||
|
||
祝您的答辩会顺利，为实验室筛选出得力干将！
|
||
|