简介：这份资源是面向软件工程、计算机专业学生的Java Web课程设计参考资料，以PDF形式呈现《基于Java的在线考试系统课程设计说明书》及配套源程序，适合正在做课程设计或想了解Java Web完整开发流程的学习者。内容围绕在线考试系统的需求分析、三层架构设计（表现层、业务逻辑层、数据访问层）展开，涵盖用户注册登录、题目列表、在线测试、成绩统计、题库管理及管理员权限等模块，并涉及JSP、Servlet、JDBC与MySQL的具体实现思路。资源包共1个PDF文件，约1.02MB，结构紧凑，便于通读与对照实践。目前已有488人学习浏览。读者可从中获取一套较完整的系统设计文档与源码参考，理解Java EE平台下前后端交互、数据库增删改查及多线程并发处理的基本做法，也可作为撰写课程设计说明书、梳理功能模块与界面流程的实用范例。
1. 从一份课程设计说明书说起：Java 在线考试系统到底要交付什么
很多人拿到「基于 Java 的在线考试系统课程设计说明书（含源程序）」这个题目，第一反应是去搜一套现成源码改改交差。但真正答辩时被问住的，往往不是代码写没写出来，而是「你为什么这么设计」。课程设计交付的从来不只是能跑的.jar，而是一份能自圆其说的说明书加一套结构清晰的源程序。
这个系统要解决的核心问题很具体：教师出题组卷、学生限时作答、系统自动判分并给出成绩。它适合计算机相关专业的课程设计、毕业设计前期练手，也适合想用 Java 把「增删改查 + 业务规则」串一遍的后端入门者。热词里高频出现的 Java 基础、数据库课程设计、Java 课程设计案例源码，其实都指向同一件事——用一套完整业务把 Java SE、JDBC、Servlet 这些零散知识点焊在一起。
我一般建议把它当成一个「缩小版的真实系统」来做：功能砍到刚好够用，但分层、异常处理、数据库设计这些骨架不能省。下面按理论选型、环境搭建、核心模块实现、判分与防作弊、说明书撰写与答辩的顺序展开。
2. Java 在线考试系统的技术选型与数据库表设计
2.1 为什么用 Servlet + JSP + JDBC 而不是上来就 Spring Boot
课程设计的评分点里，「技术栈是否匹配课程」往往比「技术是否新」更重要。如果课程讲的是 Java Web 基础，你直接上 Spring Boot，答辩老师很可能追问自动配置原理，反而暴露短板。常见做法是：控制层用 Servlet，视图层用 JSP，持久层用原生 JDBC 加一个薄薄的 DAO 封装。
这套组合的好处是每一层都看得见。请求怎么进来、参数怎么取、SQL 怎么拼、结果怎么回填，全在你自己手里。热词里的 Java Server Pages、Java 基础、Java 环境变量配置，正好对应这条路线。等这套跑通了，再迁移到 Spring Boot 只是换个壳。
选型上还有两个现实约束：一是课程设计周期通常两三周，二是要能在普通笔记本上跑起来。Servlet + JSP 不需要额外学依赖注入和 AOP，Tomcat 解压即用，MySQL 装完就能连。这就是它作为课程设计主线的合理性。
2.2 考试系统必须落地的 6 张核心表
数据库设计是说明书里最容易被追问的部分。表结构不合理，后面判分和统计全是坑。下面这套是经过多届课程设计验证过的最小可用集合。
| 表名 | 作用 | 关键字段 |
|---|---|---|
| user | 用户（学生/教师） | id, username, password, role |
| question | 题库 | id, content, option_a~d, answer, score, type |
| paper | 试卷 | id, title, total_score, duration, create_time |
| paper_question | 试卷与题目关联 | paper_id, question_id, sort_no |
| exam_record | 考试记录 | id, user_id, paper_id, start_time, submit_time, score |
| answer_detail | 作答明细 | id, record_id, question_id, user_answer, is_correct |
role字段用 0/1 区分学生和教师，避免建两张用户表。paper_question用中间表而不是在 paper 里存题目 ID 字符串，是为了后面按顺序取题和统计正确率时不用做字符串切割。
建表语句示例：
CREATE TABLE question ( id INT PRIMARY KEY AUTO_INCREMENT, content VARCHAR(500) NOT NULL, option_a VARCHAR(200), option_b VARCHAR(200), option_c VARCHAR(200), option_d VARCHAR(200), answer CHAR(1) NOT NULL, -- 正确选项 A/B/C/D score INT DEFAULT 5, -- 单题分值 type TINYINT DEFAULT 1 -- 1 单选 2 多选 3 判断 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;answer用单字符存选项，判分时直接和用户提交的字符比对，比存整段文本可靠。type预留多选和判断，方便后续扩展。字符集统一 utf8mb4，否则中文题干和选项会出现乱码，这是新手最常踩的坑。
2.3 分层结构与包命名规范
说明书里画一张包结构图，比写一千字都管用。我一般用这样的划分：
com.exam ├── entity // 实体类，与表一一对应 ├── dao // 数据库访问，一个表一个 DAO ├── service // 业务逻辑，组卷、判分放这里 ├── servlet // 控制层，接收请求 ├── util // DBUtil、MD5 工具 └── filter // 登录校验、编码过滤判分逻辑必须放在 service 层，不能写在 Servlet 里。因为判分既要用到题目答案，又要写 exam_record 和 answer_detail 两张表，属于跨表业务。放在 Servlet 里会导致代码无法复用，补考、重判时只能复制粘贴。
3. 用 JDBC 打通题库管理与组卷的最小实现
3.1 数据库连接工具类的正确写法
很多课程设计源码把DriverManager.getConnection散落在每个 DAO 里，改一次数据库密码要改十几处。正确做法是抽一个 DBUtil，用静态块加载驱动，用配置文件读连接参数。
public class DBUtil { private static String url; private static String user; private static String password; static { try (InputStream in = DBUtil.class.getClassLoader() .getResourceAsStream("db.properties")) { Properties p = new Properties(); p.load(in); url = p.getProperty("jdbc.url"); user = p.getProperty("jdbc.user"); password = p.getProperty("jdbc.password"); Class.forName(p.getProperty("jdbc.driver")); } catch (Exception e) { throw new ExceptionInInitializerError("数据库配置加载失败"); } } public static Connection getConnection() throws SQLException { return DriverManager.getConnection(url, user, password); } }db.properties放在src根目录，打包后会在classes下。Class.forName加载驱动只需一次，放在静态块里避免重复执行。注意这里没有用连接池，课程设计并发量小，够用；如果说明书里想体现优化意识，可以补一句「生产环境应替换为 Druid 或 HikariCP」。
3.2 随机组卷的 SQL 与参数说明
组卷是考试系统的核心动作。教师选好题型和数量，系统从题库随机抽题。MySQL 里用ORDER BY RAND()最简单：
SELECT id, content, option_a, option_b, option_c, option_d, score FROM question WHERE type = ? ORDER BY RAND() LIMIT ?;type对应题型，LIMIT对应抽题数量。这两个参数由教师在组卷页面填写。ORDER BY RAND()在数据量上万时性能会下降，但课程设计题库通常几百题，完全没问题。如果说明书要写优化，可以提「按 id 区间随机取」的思路，但不必真实现。
抽完题后要写入paper_question表，并计算总分：
int total = 0; for (Question q : list) { total += q.getScore(); paperQuestionDao.insert(paperId, q.getId(), ++sortNo); } paperDao.updateTotalScore(paperId, total);sortNo保证题目顺序稳定，学生刷新页面不会换题。总分在组卷时算好存进 paper 表，判分时直接读，避免每次重新累加。
3.3 分页查询题库的通用写法
题库管理页面需要分页，否则几百题一页拉到底。分页 SQL 用LIMIT offset, size：
SELECT * FROM question ORDER BY id DESC LIMIT ?, ?;offset = (pageNo - 1) * pageSize。DAO 里接收 pageNo 和 pageSize 两个参数，Servlet 从请求里取，默认 pageNo=1、pageSize=10。总页数用SELECT COUNT(*)单独查一次。
注意：
LIMIT的两个参数在 JDBC 里都用setInt设置，不要用字符串拼接，否则会有 SQL 注入风险，答辩时这是高频提问点。
4. 考试作答、自动判分与防刷新丢失的实战处理
4.1 考试计时与提交的会话控制
学生进入考试后，试卷和开始时间要存进 session。计时用前端 JavaScript 倒计时，但真正的截止判断必须在服务端做，因为前端时间可以被改。
// 进入考试 session.setAttribute("paper", paper); session.setAttribute("startTime", System.currentTimeMillis()); // 提交时校验 long start = (Long) session.getAttribute("startTime"); long used = (Long) session.getAttribute("duration") * 60 * 1000; if (System.currentTimeMillis() - start > used + 5000) { // 超时，按已作答内容判分 }多给 5 秒是给网络延迟留余量。duration从 paper 表读取，单位分钟。服务端校验通过后才允许写 exam_record，这样即使前端倒计时被绕过，超时提交也会被记录为异常。
4.2 自动判分的核心逻辑与多选处理
判分要区分题型。单选和判断直接比对，多选需要集合比较。
public int judge(Question q, String userAnswer) { if (userAnswer == null || userAnswer.isEmpty()) return 0; if (q.getType() == 1 || q.getType() == 3) { return q.getAnswer().equalsIgnoreCase(userAnswer) ? q.getScore() : 0; } // 多选：排序后比较，避免顺序影响 char[] ua = userAnswer.toCharArray(); char[] ca = q.getAnswer().toCharArray(); Arrays.sort(ua); Arrays.sort(ca); return Arrays.equals(ua, ca) ? q.getScore() : 0; }多选答案在数据库里存成"ACD"这种形式，用户提交的也是拼接字符串。排序后比较能避免「ACD」和「CAD」被判错。这里没有做「少选给一半分」的规则，如果说明书要体现复杂度，可以加一个部分得分逻辑，但要写清楚规则来源。
判分结果要同时写两张表：exam_record 存总分，answer_detail 存每题对错。这样后面做错题统计和试卷分析才有数据。
4.3 防止刷新导致答案丢失的三种做法
考试中途刷新页面是常见操作，答案不能丢。三种做法按复杂度递增：
- 每次选项变化就 AJAX 提交到服务端暂存，存进一个
temp_answer表或 session。 - 用 localStorage 在前端暂存，提交时一起带上。
- 整卷用 form 提交，刷新前提示确认。
课程设计里我一般用第二种，实现简单且不增加服务端压力：
// 选项变化时暂存 document.querySelectorAll('input[type=radio]').forEach(el => { el.addEventListener('change', () => { const answers = JSON.parse(localStorage.getItem('exam_answers') || '{}'); answers[el.name] = el.value; localStorage.setItem('exam_answers', JSON.stringify(answers)); }); });页面加载时反向回填，提交成功后清空 localStorage。el.name用题目 ID，保证一题一个键。这个方案在答辩时容易被问「换台电脑怎么办」，回答「换设备属于异常场景，由监考处理」即可。
5. 说明书撰写、源码整理与答辩追问的应对技巧
5.1 说明书里必须出现的四类图
课程设计说明书的评分点里，图比文字值钱。至少要有：系统功能结构图、E-R 图、核心业务流程图（组卷和判分各一张）、关键类图。E-R 图用 Visio 或 draw.io 画，实体和联系要标基数。业务流程图不要画成代码流程，要画成「教师发起组卷 → 系统抽题 → 写入试卷 → 学生作答 → 系统判分 → 生成成绩」这种业务视角。
源码整理时，把db.properties里的密码改成占位符，说明书附录里贴关键类而不是全部源码。答辩老师翻附录时看的是 DAO 和 Service 的写法，不会逐行读 JSP。
5.2 答辩高频追问与回答边界
几个几乎必问的问题：为什么用 JDBC 不用连接池、判分逻辑放哪一层、多选答案怎么存、超时提交怎么处理、SQL 注入怎么防。回答时守住一个原则：说清楚当前实现，再补一句「如果数据量增大，我会怎么改」。比如连接池问题，答「当前并发低，直接连接够用；如果上生产，会换成 HikariCP 并配置最大连接数」。
不要主动提自己没实现的功能。说明书里写了「支持多选部分得分」但代码没写，被要求演示时会很被动。热词里的 Java 面试八股文、Java 基础面试题，其实和答辩追问高度重合，提前把 JDBC 流程、Servlet 生命周期、session 与 cookie 区别过一遍，能覆盖大半问题。
5.3 一个能加分的细节：判分结果的幂等处理
最后说一个容易被忽略但很能体现工程意识的点。学生重复点击提交按钮，或者网络重试，可能导致同一份试卷被判分两次，exam_record 出现两条记录。处理办法是在提交时先查是否已有该用户该试卷的记录：
SELECT id FROM exam_record WHERE user_id = ? AND paper_id = ? AND status = 1;如果已存在，直接返回已有成绩，不再重新判分。status字段标记 1 为已交卷。这个判断放在 service 层，和判分逻辑同一个事务里。答辩时主动提这一点，比背十道八股文更能说明你真的跑过这套系统。
本文还有配套的精品资源，点击获取
