企业官网建设流程全解析

简介：面向软件工程课程设计或期末大作业的网上考试系统完整项目包，提供可运行的JavaEE源码、配套设计报告与使用说明，适合需要快速完成课题或理解JavaEE分层开发的初学者。资源为rar压缩包，共74个文件，主要包含16个Java核心类、16个JSP页面及对应字节码文件，以及样式表、图片等前端资源；同时带齐项目配置、数据库元数据、依赖jar包，整体仅6.75MB，导入工作区即可查看运行，难度适中且注释详细。整个工程目录包含src源码、WebRoot页面资源及MyEclipse项目配置，便于按模块查阅。使用说明中明确了修改姓名、学号等信息的方法，设计报告则梳理了系统模块与关键代码逻辑，方便课程答辩与文档撰写。目前已有3475人学习下载，是考前演练、课程设计参考和项目复现的实用资料。

1. 为什么这套网上考试系统值得作为你的 JavaEE 大作业

大部分同学在选 JavaEE 大作业题目时都会想到“网上考试系统”，但真正把它做完、做完整的人并不多。最常见的翻车场景是：功能看着齐全——登录、题库、试卷、考试页面都有，可一到联调就发现学生交不了卷、老师看不到成绩、数据库表之间对不上，最后只能对着崩溃的页面熬夜改代码。这套网上考试系统设计的价值不在于“功能多”，而在于它是一个能跑通的完整闭环：管理员维护题库、教师组卷并发布考试、学生在线答题、系统自动判分并生成成绩统计，连报告和使用说明都一并配齐，拿来就能作为 JavaEE 大作业或课程设计的交付物。

如果你正在做毕设或课设，需要一份代码结构清晰、报告能直接梳理成文档、使用说明能应对老师现场验收的完整方案，这套系统就是一个稳妥的参考蓝本。它既不需要你去啃 Spring Cloud 那套微服务架构，也不用纠结前后端分离的工程化流程，而是老老实实地用 JavaEE 传统技术栈把业务做扎实——Servlet 控制请求、JSP 渲染页面、JDBC 操作数据库。这种选型恰恰是课程考核最认可的方向，因为它能清楚展示你对 JavaEE 核心机制的理解，每一处请求流转和数据操作都能在答辩时讲明白。

2. 需求分析与技术选型：先立住业务再选工具

2.1 三层角色与核心业务用例

网上考试系统要解决的业务问题非常明确：替代纸质考试的组织流程，把「出题 → 组卷 → 发布 → 答题 → 判分 → 成绩统计」整条链路搬到线上。按用户角色划分，系统涉及三类用户，每类用户的使用场景必须一开始就理清，否则后期实现容易乱套。

• 管理员：负责基础数据维护，包括科目管理、教师账号管理、题库的最终审核与清理。在实际使用中，管理员不直接参与出题和阅卷，但需要对全系统的运行状态有可见性，比如每个科目的题目数量、每次考试的学生参与情况。
• 教师：核心业务操作者。教师可以维护自己的题库（判断题、单选题、多选题三种题型）、手动或自动组卷、发布考试、查看考试结果、对主观题进行复核判分。教师最关心的是组卷规则是否灵活、判分是否准确、成绩导出是否方便。
• 学生：考试参与者和成绩查询者。学生需要查看待参加的考试列表、在规定时间内进入考试并答题、交卷后立即看到客观题得分、随时查看历史考试成绩和试卷详情。

在需求优先级上，自动判分是网上考试系统的核心差异化能力。客观题（判断、单选、多选）交卷后由系统按标准答案比对判分，主观题（简答、论述）先由系统按关键词做预评分，再交给教师人工复核。这道流程设计要把业务闭环讲清楚：考试不是学生点交卷就结束了，教师端还需要有「待复核试卷」的提醒和处理入口，才算完整的业务流程。做需求分析时应该绘制的用例图也以此为主干，而不是把增删改查的底层操作铺满整个用例表。

2.2 技术栈选型：为什么是 JSP + Servlet + JDBC 而不是赶时髦上框架

很多同学一上来就想用 Spring Boot + MyBatis，觉得这样显得水平高。但作为 JavaEE 大作业，技术选型的第一原则是：能够展示课程所学，并且能应对答辩提问。JSP + Servlet + JDBC + MySQL + Tomcat 这套组合，是 JavaEE 课程的核心教学内容，用它能清晰呈现 MVC 分层结构——JSP 承担视图层，Servlet 承担控制层，JavaBean + DAO 承担模型层。答辩时老师最常问的问题就是「一个请求从前端到数据库的完整流转过程」，用这套基础技术栈反而更容易讲透彻。

当然，这套方案并不排斥增强。如果课程到了后期引入了框架教学，或者你想在报告中展示工程化意识，可以引入三层架构 + DAO 设计模式的组织方式，把 Presentation Layer、Business Layer、Data Access Layer 的职责边界在代码里严格划分。这样既保持了考试系统本身功能的聚焦，又让代码结构具备可扩展性——将来要替换成 Spring 实现，只需替换各层的具体类，接口和业务逻辑可以保留。

数据库选型上使用 MySQL 5.7 即可，对应 Java 版本用 JDK 8，部署容器用 Tomcat 9。这三者的兼容性经过大量项目验证，不会出现环境配置层面的版本坑。关于 JDBC 连接，建议使用连接池思路——虽然标准 JDBC 也能跑通，但用 DBCP 或 C3P0 连接池能避免高并发考试场景下频繁创建连接的资源开销，这一设计在答辩时可以作为一个优化亮点来介绍。

2.3 跑步进入实现前的「验收预演」

做任何课设或大作业，我都建议先想清楚验收标准再动手写代码，不要等项目写完了才回头补文档。这套网上考试系统的验收通常围绕四个维度展开：功能完整性（核心业务链路可走通）、健壮性（异常输入不崩溃、非法访问被拦截）、界面友好度（操作路径清晰、提示明确）、文档齐全度（报告能说明设计思路、使用说明能让新用户直接上手）。

这四点是写 PPT 和报告时的骨架，也决定了你在开发阶段的优先级安排。比如功能完整性要求「自动判分」必须精准，那就得在题目表设计时就把正确答案字段和分值字段设计到位；健壮性要求「不允许重复交卷」，那就得在考试记录表上设计唯一约束，同时在 Servlet 代码里做二次校验。带着验收标准去设计数据表和接口，比写完再修补省力得多。

3. 总体架构设计：MVC 分层结构与核心数据表规划

3.1 系统分层与包结构设计

网上考试系统的代码组织采用经典的分层包结构，它让代码从第一行开始就有清晰的归属，不会出现「一个 Servlet 干完全部事情」的坏味道。我建议这样划分包结构：com.exam.servlet存放所有控制层 Servlet；com.exam.service存放业务逻辑接口和实现类；com.exam.dao存放数据库访问对象；com.exam.entity存放与数据库表对应的实体类；com.exam.util存放公共工具类，比如 JDBC 连接、字符串校验、分页组件等。

这种结构最大的好处是：答辩时你可以直接画一张架构图，从浏览器请求开始，依次经过 Servlet → Service → DAO → 数据库，再反向把结果渲染到 JSP。每一层都能举出具体的类名和业务对应关系。比如学生交卷的请求会到达SubmitExamServlet，它调用ExamService.submitExam()方法，该方法内部逐题调用ExamRecordDao.insertRecord()写入答题明细，再调用ExamResultDao计算并保存总分——整个过程分层清晰，每一层你都能指着代码讲明白职责。

3.2 核心数据表设计：字段设计和关系说明

数据库是考试系统最容易埋坑的地方。设计不合理的表结构会在后期让你付出惨痛代价：想统计某次考试的平均分时发现成绩表缺少科目关联，想导出班级成绩时发现学生表和班级表没有建立关系。这套方案采用 8 张核心数据表的模型，这里重点介绍最关键的 5 张。

用户表（t_user）：包含用户ID、用户名、密码（MD5加密）、角色（1管理员、2教师、3学生）、姓名、学号/工号、班级等字段。注意角色字段用 int 不用 varchar，方便程序里做判断，也方便将来扩展更多角色。

科目表（t_subject）：科目ID、科目名称、任课教师ID、考试时长（默认分钟数）。科目和教师是多对一关系，设计外键关联到用户表，但要加索引以提升组卷和查成绩时的联表查询效率。

题库表（t_question）：这是整个系统的核心表。字段包括题目ID、科目ID、题型（1判断、2单选、3多选、4主观题）、题目内容、选项A/B/C/D（判断题和主观题为空）、正确答案、分值、难度系数、创建教师ID。多选题目在存正确答案时用逗号分隔，比如「A,B,C」，判分时先分割字符串再比对集合。

试卷表（t_paper）：试卷ID、试卷名称、科目ID、总分、题目总数、组卷方式（1手工选题、2随机抽题）、考试开始时间、考试结束时间、创建教师ID。试卷本身不直接存储题目明细，而是通过一张中间表t_paper_question维护试卷和题目的多对多关系，中间表额外记录每道题在该试卷中的分值——这样可以实现同一道题在不同试卷里设置不同分值。

考试记录表（t_exam_record）：记录ID、试卷ID、学生ID、开始时间、交卷时间、客观题得分、主观题得分、总分、状态（1考试中、2已交卷待复核、3已完成）、是否异常交卷。这张表加上「(试卷ID, 学生ID)」的唯一索引就能防止重复考试。

3.3 数据库脚本与初始化数据

交付完整的数据库脚本是报告和代码之外最有说服力的部分。资源中会附带完整的exam_system.sql建库建表脚本，包括上述所有表结构、外键关系、核心索引以及初始账号数据（一个管理员账号、一个教师账号、一个学生账号，方便你启动后直接登录演示）。

我建议在初始化脚本里插入 20 道左右的示例题目，覆盖四种题型，并且分值总和等于 100，方便演示总分计算逻辑。这个细节看起来很不起眼，但实际项目中有相当多同学初始数据里各题分值加起来根本不是 100 分，导致每次考试成绩都「满分不是 100」，答辩时被问得哑口无言。血泪经验：写初始化数据前先在纸上算一遍总分。

4. 模块实现：从组卷算法到自动判分的核心代码

4.1 登录与权限拦截：用过滤器拦住所有未授权访问

登录模块看起来简单，但要从一开始就做对，不能只写一个登录处的密码校验。考虑一个基本场景：学生直接在浏览器地址栏输入/admin/managerPage.jsp，如果系统没有权限拦截，他就能看到管理页面；甚至可以通过 URL 猜测 Servlet 路径直接操作数据。所以这套方案里使用一个过滤器AuthFilter统一处理登录状态和角色权限校验。

// com.exam.filter.AuthFilter.java public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) { HttpServletRequest req = (HttpServletRequest) request; HttpServletResponse resp = (HttpServletResponse) response; HttpSession session = req.getSession(false); Object user = session == null ? null : session.getAttribute("loginUser"); String path = req.getRequestURI(); // 放行登录相关的路径和静态资源 if (path.endsWith("login.jsp") || path.endsWith("LoginServlet") || path.contains("/static/") || path.endsWith("register.jsp")) { chain.doFilter(request, response); return; } // 未登录一律重定向到登录页 if (user == null) { resp.sendRedirect(req.getContextPath() + "/login.jsp"); return; } // 管理员路径只能 admin 角色访问 if (path.contains("/admin/") && !"1".equals(user.getRole())) { resp.sendError(HttpServletResponse.SC_FORBIDDEN); return; } chain.doFilter(request, response); }

这段代码的核心作用是提供一道全局防线。注意getSession(false)的写法——它会避免为一个非法请求强制创建 Session，减少服务器资源浪费。角色校验的力度要结合实际情况调整：这里做了两个层次的拦截，第一层拦截未登录用户，第二层按 URL 前缀限制管理员功能。这能在答辩时作为安全设计的一个亮点说明。在配置方面，要在web.xml里为过滤器配置合适的 URL 映射，通常写/全路径映射，然后在过滤器内部放行特定路径。

4.2 组卷模块：随机抽题的去重算法与参数封装

组卷是考试系统中业务逻辑最密集的功能，也是答辩时最容易被深入追问的模块。手动组卷就是教师逐题选择并设置分值，逻辑简单。随机组卷则要处理好三个问题：抽题范围的过滤、题目去重、总分的精确控制。下面的代码展示了随机抽题的核心算法。

// com.exam.service.impl.PaperServiceImpl.java public List<Question> autoGeneratePaper(int subjectId, int questionCount, int totalScore) { // 设置随机抽题的种子，保证每次组卷结果不同 int seed = (int) (Math.random() * 10000); List<Question> selected = new ArrayList<>(); // 计算平均每题分值，按整数分值分配时先保证总分能被整除的部分 int perScore = totalScore / questionCount; int remainScore = totalScore - perScore * questionCount; String sql = "SELECT * FROM t_question WHERE subject_id = ? ORDER BY RAND(?) LIMIT ?"; // 执行查询得到候选题目列表 candidateList List<Question> candidateList = questionDao.findRandomBySubject(subjectId, seed, questionCount); // 如果候选题目不足，抛出业务异常 if (candidateList.size() < questionCount) { throw new BusinessException("题库中可用题目不足，无法组卷，请先在题库中添加题目"); } for (int i = 0; i < candidateList.size(); i++) { Question q = candidateList.get(i); q.setScore(perScore + (i < remainScore ? 1 : 0)); // 把余数分摊到前面几题 selected.add(q); } return selected; }

这段实现里有两个细节值得在答辩时讲：一是ORDER BY RAND(?)带随机种子，保证每次执行组卷得到不同的题目组合，而种子本身来自当前时间戳或随机数，所以在同一毫秒内多次操作也不会生成完全相同的试卷。二是分值分配策略——总分除以题量得到平均分值，余数按均匀分摊的方式加到前面的题上。这样做避免出现第一题分值和最后一题分值差太多的情况，也确保所有题目分值加起来等于设定的总分。在实际运行中，如果教师设置的总分和题目数量不匹配，系统应给出业务异常提示，而不是默默生成一份分值错误百出的试卷。

4.3 在线答题与防重复提交：时间窗口校验

学生开始考试后，系统会记录开始时间并在交卷时检查考试时长。防重复提交是这个模块最容易翻车的点：如果学生在交卷时手抖点了两次「交卷」按钮，系统就会生成两条考试记录，成绩数据直接乱掉。加固方案是在提交 Servlet 里做两重校验，第一重判断数据库里是否已有状态为考试中或已完成的记录，第二重用一次性令牌控制前端提交。

// com.exam.servlet.SubmitExamServlet.java 关键逻辑 protected void doPost(HttpServletRequest request, HttpServletResponse response) { HttpSession session = request.getSession(); User user = (User) session.getAttribute("loginUser"); int paperId = Integer.parseInt(request.getParameter("paperId")); String submitToken = request.getParameter("submitToken"); // 校验一次性令牌，防止重复提交 String sessionToken = (String) session.getAttribute("submit_token_" + paperId); if (sessionToken == null || !sessionToken.equals(submitToken)) { response.getWriter().write("{\"code\":500,\"msg\":\"重复提交，请勿刷新页面\"}"); return; } session.removeAttribute("submit_token_" + paperId); // 校验是否已有交卷记录 ExamRecord record = examDao.findRecordByPaperAndUser(paperId, user.getId()); if (record != null && record.getStatus() == 2) { response.getWriter().write("{\"code\":500,\"msg\":\"您已交卷，不能重复提交\"}"); return; } // 执行逐题判分逻辑... int objectiveScore = calculateObjectiveScore(paperId, user.getId()); examDao.updateScore(record.getId(), objectiveScore); }

令牌机制的工作原理是：进入考试页面时生成一个随机字符串保存到 Session，同时渲染到页面的隐藏域中；交卷时比对请求携带的令牌与 Session 中保存的令牌是否一致，一旦使用立即清除，第二次请求带着同样的令牌就匹配不上，直接拒绝。这在课设阶段能妥妥地应对大部分误操作。也有一部分同学选择在前端用 JS 变量控制按钮禁用，但那种方式无法防范多标签页提交和异常重发，所以后端必须做校验。

4.4 自动判分核心逻辑：客观题比对与主观题预评分

判分逻辑是整套系统里最需要严谨对待的代码。单选题和判断题直接用字符串比较答案即可；多选题要把用户提交的选项拆分成集合后再与标准答案集合比对，必须保证顺序不同但选项相同也算正确，同时要判断是否多选、漏选。下面展示多选题目判分的核心实现。

// com.exam.util.ScoreCalculator.java public static int judgeMultipleChoice(String userAnswer, String correctAnswer, int score) { if (userAnswer == null || userAnswer.trim().isEmpty()) { return 0; } // 将答案拆分成有序集合，避免顺序干扰 List<String> userList = Arrays.asList(userAnswer.split(",")); List<String> correctList = Arrays.asList(correctAnswer.split(",")); Collections.sort(userList); Collections.sort(correctList); if (userList.equals(correctList)) { return score; // 全部正确，得满分 } // 部分正确但未全对，根据空选情况做策略处理：常见规则是漏选得一半分 boolean missedSome = correctList.containsAll(userList) && userList.size() < correctList.size(); if (missedSome) { return score / 2; } return 0; // 错选或漏选超过范围，不得分 }

漏选给一半分、错选不给分是考试系统里比较通用的规则，和多数在线考试平台的判分策略一致。主观题的预评分采用关键词匹配策略：教师录入题目时设置参考答案的关键词列表，交卷后程序统计学生答案中包含的关键词数量，按比例折算预评分，标记为「待复核」状态，由教师人工确认后覆盖为最终分数。这种设计避免了主观题完全靠人工阅卷的工作量，又保留了教师最终复核的机制，在答辩时可以很自然地引出「系统与人类判断相结合」的讨论。

5. 界面实现与关键流程：从 JSP 页面到考试全流程走通

5.1 三个角色的主要页面设计与交互要点

页面设计不需要追求花哨，但要保证操作路径直观，因为验收时老师会按「管理员 → 教师 → 学生」的顺序实际操作一遍，任何一步流程走不通都会直接影响评分。我的建议是每个角色登录后进入不同的主页，页面上只展示与自己角色相关的功能入口。

• 管理员端：页面包括科目管理（增删科目、查看科目下的题量统计）、教师账号管理（添加教师、重置密码）、考试总览（查看所有考试的状态和参与人数）。管理员的页面要突出「统计」与「监督」属性，不要和教师功能混在一起。
• 教师端：工作台展示今日待复核试卷数量、题库题目数量、进行中的考试数量；题库管理页面支持按科目和题型筛选；组卷页面分两步操作：第一步设定试卷基本信息，第二步选择手动组卷或随机组卷并确认题目列表和分值；试卷发布后可在「考试管理」中修改考试时间或紧急停考。
• 学生端：主页显示「待参加的考试」「已完成的考试」两张卡片；待参加的考试列表显示考试科目、开始时间、结束状态，点击「进入考试」后弹出确认框，提示考试时长和考试规则；答题页面顶部显示倒计时，底部为答题卡，标注已完成和未完成题目；交卷后立刻跳转到成绩页，显示客观题得分和主观题待复核提示。

关键的交互细节是考试倒计时。倒计时数据应该由服务器下发的考试截止时间减去当前时间得出，而不是由前端记录本地时间。否则学生调整本地时间就能无限延长考试时长，这在验收评审时是个严重的功能漏洞。在 JSP 页面实现倒计时可以用 JavaScript 读取服务器渲染的截止时间戳，每秒更新剩余分钟和秒数，时间到自动触发表单提交，把学生的半成品答案先保存下来。

5.2 考试全流程的时序设计与状态流转

要保证系统各模块能串起来，必须把考试状态机的流转设计清楚。一次正常考试的完整流程是这样的：

管理员或教师创建科目并维护题库 → 教师组卷生成试卷 → 试卷状态为「草稿」→ 教师确认发布，系统设置考试开始和结束时间，试卷状态变为「进行中」→ 学生在有效期内进入考试，系统生成考试记录（状态为考试中）→ 考试时间到或学生提前交卷，系统执行自动判分，客观题分数立即写入 → 如果试卷包含主观题，考试记录状态变为「待复核」→ 教师在待复核列表对主观题评分并确认完成，状态变为「已完成」→ 学生端可以查看含主观题得分的最终成绩。

这个流程里有几个容易遗漏的状态点。比如教师发布考试后才发现组卷有问题，需要「撤回」和「归档」的操作；学生考试途中异常退出时，考试记录状态为「考试中」但没有实际交卷，需要提供重新进入机制，并判断是否会覆盖已有答案。测试阶段要逐一核对这些状态的跳转，我在做课设测试时就遇到过非常尴尬的情况：教师发布考试后发现试卷题目有一道分值配错，但考试已经开始，改不了试卷，只能让已经参加考试的学生全部取消，重新组卷再考一次。从那以后我要求每次发布考试前必须进行一次「预览试卷」操作，确认题目、分值和考试时间无误后再点发布按钮。

5.3 报告和使用说明的配套写作思路

这套资源包含完整的设计报告模板和使用说明文档。报告的章节结构建议按照「需求分析 → 系统设计 → 功能实现 → 系统测试 → 总结」这五部分来组织，和大多数高校课程设计要求匹配。在系统设计部分要包含用例图、功能结构图、数据库 E-R 图、核心流程图；在实现部分给出关键代码和截图；在测试部分列出测试用例表，包括正常路径测试、异常输入测试、权限拦截测试三个维度的用例。

使用说明文档则要站在一个完全不熟悉项目的人的角度写。开头写安装部署步骤，包括环境要求、数据库导入、修改数据库连接配置、打包发布到 Tomcat 的具体操作，每一步要写清楚到哪里下载工具、打开哪个文件、修改哪一行；随后按三类角色的身份分别说明登录信息（初始账号密码）和功能操作步骤；最后附上常见问题排查，比如 Tomcat 启动失败、数据库连接报错、端口被占用等。这样做的原因是：保障在演示环境下，现场客户或评阅老师能顺利运行。

6. 常见高频问题排查：部署与运行时最容易翻车的五个点

根据以往带课设项目和学生试用的经验，网上考试系统交付后最容易出现的问题集中在环境配置和细节功能上，这里集中整理，分现象、原因、解决三步说明，能帮你节省大量排查时间。

问题一：Tomcat 启动时报ClassNotFoundException: com.mysql.jdbc.Driver

现象：点击 Tomcat 启动后能在日志中看到驱动类找不到的报错，登录页面完全无法连接数据库。原因一般有两个：一是 JDBC 驱动 jar 包没有放进WEB-INF/lib目录，二是工程构建路径中引用了 jar 包但部署时没有同步到 Tomcat。解决方法是把mysql-connector-java-5.1.x.jar直接复制到项目的WEB-INF/lib下，然后在 IDEA 或 Eclipse 中重新部署并确认构建产物中包含了该 jar 包。这个坑出现的频率极高，每次帮别人排查，十个里有七个是这个问题。

问题二：登录成功后跳转页面 404

现象：登录逻辑正确、数据库记录也能查到，但重定向到主页时报 404 找不到资源。原因通常是 Servlet 的 URL 映射、JSP 文件的物理路径和重定向的路径三者不一致，尤其在 IDEA 中使用虚拟路径部署时容易出现。排查顺序是：先看web.xml或注解里配置的@WebServlet("/admin/home")是否和sendRedirect的路径完全一致（包括项目名），再看 JSP 文件是否放在了webapp/admin/home.jsp对应位置，最后检查浏览器地址栏的项目上下文名称是否和部署名称相符。

问题三：学生交卷后成绩没有写入数据库

现象：答题页面正常，提交后确认框消失，但刷新成绩列表发现没有记录。原因通常不是判分逻辑错误，而是事务没有提交——在逐题判分的过程中一旦某一步抛出异常，整个事务回滚，成绩自然消失。另一个原因是判分代码中更新 SQL 的执行条件写错，比如更新语句的WHERE条件用错了记录 ID。建议在交卷 Servlet 的判分方法上加上事务控制并打印详细日志，至少能区分错误发生在哪一步。我这里一般的做法是把判分离出来做成独立方法，在方法入口和出口各打印一条日志，方便定位。

问题四：随机组卷时提示「题库中可用题目不足」

现象：明明题库里有不少题目，但点自动组卷就是提示题目不足。原因是筛选条件过于严格，或者 SQL 的查询条件写错导致把符合条件的题目都过滤掉了。最常见的反面案例是科目 ID 取错——教师端登录后默认显示的科目 ID 和题库表里的科目 ID 不一致，查询结果自然为空。请检查组卷请求中传给后端的科目 ID 是否来自页面选中项的 value 而不是显示文本。

问题五：学生能直接访问教师在用的管理页面

现象：登录学生账号后，在浏览器地址栏输入管理端的 JSP 路径，发现页面直接打开了。原因是页面没有通过过滤器或 Servlet 转发访问，而是直接访问了 JSP 文件，绕过了权限校验。凡是需要权限控制的页面都不能直接用 JSP 文件路径暴露，必须通过 Servlet 转发进入。建议把所有带管理功能的页面入口全部收口到 Servlet 中，JSP 文件放在WEB-INF/pages目录下，这样用户无法从外部直接请求到 JSP 文件本身——这也是 JavaEE 项目中控制管理端页面入口的标准做法。权限校验不能依赖「隐藏入口」或者「没有人会猜到路径」，要用第 4 章的AuthFilter统一处理。

提示：以上五个问题覆盖了测试和验收阶段近七成的高频故障。如果你在做课设时还遇到其他问题，优先查看 Tomcat 的 localhost 日志与数据库执行日志，日志信息是第一排查依据。

7. 验收落地方案：从功能测试到答辩陈述的完整路径

7.1 功能测试清单：按这三步走完才算合格

正式提交前，建议按下面的清单逐项完成走查，确保没有遗漏掉关键流程。

第一步，核心链路走通测试。用管理员账号登录，添加一个科目；切换到教师账号，在题库中添加四道不同类型的题目，分值合计 100；使用自动组卷生成一份试卷，检查分值总和；发布试卷并设置一个未来五分钟内的考试时间；切换到学生账号进入考试并答题，其中一道主观题留白；交卷后验证客观题得分是否正确、主观题是否进入待复核状态；回到教师账号完成主观题评分，再到学生端确认最终成绩。整个流程一次性通过，系统的核心功能就没有大问题。

第二步，异常与边界场景测试。要覆盖以下场景：错误密码能否登录；未登录直接访问 JSP 是否被拦截；交卷后刷新页面和重新打开试卷是否提示重复提交；考试时间截止后系统是否强制交卷；多选题目选错、漏选时的得分是否符合规则；题库题目少于组卷数量时是否报错。每个异常场景下系统都不能抛出 500 错误或白屏，必须给出明确的提示信息。

第三步，多浏览器与兼容性测试。分别在 Chrome、Edge、Firefox 中跑一遍答题流程，重点验证倒计时组件和表单提交。JSP 页面中如果使用了较新的 ES6 语法或 CSS 特性，在老的浏览器内核上可能导致页面错乱，这一点测试时别忽略。

7.2 答辩准备：高频问题与回答口径

答辩环节老师喜欢围绕技术选型、核心算法和部署原理提问。提前准备好下面这些问题的回答素材，能让你在现场不慌。

第一个高频提问：「为什么选择 JSP + Servlet 而不是 Spring Boot？」回答口径：课程教学以 JavaEE 核心技术为主，这套方案要呈现的是自己对这些底层机制的理解，包括请求分发、Session 管理、过滤器等，使用基础技术栈能让这些知识点完整展示。同时系统设计采用分层模式，后续可平滑迁移到 Spring 框架。

第二个高频提问：「随机组卷的时候怎么保证题目不重复？」回答口径：抽题 SQL 基于整表随机抽样，同一份试卷中同一科目下的题目通过查询返回已确保输出不重复；做出的延伸是在数据库表结构里设计了试题唯一编号，组卷过程中以编号集合做去重校验，双重保证。

第三个高频提问：「多选题判分的标准是什么？」回答口径：允许部分给分——全部正确得满分，漏选得一半，错选或含多选不得分。这一规则与多数在线考试系统一致，同时在代码中实现为独立的工具方法，后续修改判分规则时不影响其他逻辑。

第四个高频提问：「系统的缺陷和可扩展方向？」

回答口径：当前系统的并发承载能力有限，考试高峰场景可能出现性能瓶颈；扩展方向是引入 Redis 缓存试卷信息、异步判分提升交卷响应速度，以及用框架化改造替换底层实现，这些回答既承认了局限性，又展示了后续思考能力。

7.3 答辩现场的操作技巧

现场演示时，有几个细节能让答辩过程更顺畅。一条是使用教师账号提前创建好一份试卷，不要把现场演示的重心放在「创建试卷」上，从学生参加考试开始切入，更快通关。第二条是准备好一份测试考试的数据，包括一张已发布但未开始的试卷、一张正在进行中的试卷、一张已完成且有成绩的试卷，展示三种状态的切换。第三条是在演示遇到小故障时不要慌，定位问题后展示排查思路，承认问题并立即解释是环境配置问题，比硬着头皮说「代码没 bug」要可信得多。

我做过不少次这样的项目验收，最大的教训是：把验收当项目中的一个环节去认真对待，从开发第一天起就按验收清单走每一步，这个习惯能让最后冲刺阶段的时间省出一半以上。希望这份网上考试系统的完整方案能帮到你，照着结构走，稳稳交付。

本文还有配套的精品资源，点击获取