據(jù)庫設(shè)計到自動判分的完整實踐)
在線考試平臺這個題在Spring Boot相關(guān)的課程設(shè)計和畢業(yè)設(shè)計里出現(xiàn)頻率真的非常高。它表面上是一個“系統(tǒng)開發(fā)”題目實際做起來卻要覆蓋多角色權(quán)限、題庫組織、組卷策略、考試狀態(tài)流轉(zhuǎn)、自動判分、成績統(tǒng)計這一整條業(yè)務(wù)鏈路。相比單純的增刪改查這類項目更考驗?zāi)銓I(yè)務(wù)流程的理解以及碰到邊界情況時能不能把邏輯做嚴(yán)謹(jǐn)。我當(dāng)時做這個項目時花了大量時間在數(shù)據(jù)庫設(shè)計和判分一致性上后期反而很輕松。今天就把完整的設(shè)計思路、核心表結(jié)構(gòu)、關(guān)鍵代碼邏輯以及那些在調(diào)試中踩過的坑一次說清楚。無論你是準(zhǔn)備做課程設(shè)計還是想拿一個完整的Spring Boot練手項目這篇文章都能直接參考。1. 項目整體設(shè)計與技術(shù)選型1.1 為什么在線考試平臺用Spring Boot最合適先說實話課設(shè)和畢設(shè)階段完全不需要上微服務(wù)那一套。在線考試平臺的用戶量和使用場景很集中業(yè)務(wù)邊界也很清楚本質(zhì)上就是一個標(biāo)準(zhǔn)的單體Web系統(tǒng)。Spring Boot在這種場景下簡直是量身定做的自帶內(nèi)嵌Tomcat打包成jar文件就能跑把“本地起服務(wù)”的成本降到極低。同學(xué)拿到源碼后裝好JDK、MySQL、Maven改一下數(shù)據(jù)庫連接就能把項目跑起來這在后期答辯演示時優(yōu)勢很大。Spring Boot還有一個實際好處生態(tài)對這類系統(tǒng)覆蓋得很好。登錄鑒權(quán)有Spring Security或JWT持久層用MyBatis-PlusExcel導(dǎo)入用POI或EasyExcel統(tǒng)計圖表直接前端引入ECharts每個環(huán)節(jié)都有大量可查的資料。相比SSM要手動配置一大堆XMLSpring Boot用起步依賴把常見的配置都收攏了新手只需要關(guān)注自己代碼的部分即可。我試過很多次對時間緊的同學(xué)來說Spring Boot確實是性價比最高的選擇。從答辯角度講Spring Boot還能引出“自動配置”“內(nèi)嵌容器”“起步依賴”“約定優(yōu)于配置”這些高頻面試點。你只要在項目里把JWT鑒權(quán)、攔截器、全局異常處理、事務(wù)控制都用上面試官問起來就有具體案例可以講而不是停留在“我調(diào)用過某個接口”這種層面。1.2 角色與權(quán)限設(shè)計三類角色是考試平臺的標(biāo)配學(xué)生、教師、管理員。我建議把它們放在同一張用戶表里用role字段區(qū)分不要拆成三張表。原因是登錄入口只有一個所有角色的校驗邏輯可以統(tǒng)一走同一套JWT鑒權(quán)后續(xù)擴展角色也很方便。學(xué)生查看考試列表、開始考試、交卷后查看分?jǐn)?shù)和答卷解析、查看個人成績曲線。教師維護題庫、創(chuàng)建試卷、手動選題或隨機組卷、在線閱卷、查看所授課程的成績統(tǒng)計。管理員管理系統(tǒng)基礎(chǔ)數(shù)據(jù)比如課程、班級、用戶賬號重置密碼查看全站統(tǒng)計。權(quán)限控制在課設(shè)階段最實用的方案是攔截器加注解不需要把Spring Security整個搬進來。實現(xiàn)方式是這樣的定義一個RequireRole注解標(biāo)注在Controller方法上攔截器里解析當(dāng)前登錄用戶的角色角色不匹配就返回統(tǒng)一格式的錯誤信息。這種方式代碼量不大而且很好講清楚權(quán)限設(shè)計的思路。1.3 核心模塊劃分整個系統(tǒng)按功能拆成六大模塊系統(tǒng)管理、用戶認證、題庫管理、試卷管理、在線考試、成績統(tǒng)計。其中組卷和在線考試是這個項目區(qū)別于普通管理系統(tǒng)的核心也是設(shè)計文檔里最值得展開寫的內(nèi)容。動手寫代碼之前建議先把業(yè)務(wù)狀態(tài)線畫出來教師創(chuàng)建試卷并發(fā)布考試 - 學(xué)生進入考試生成試卷快照 - 學(xué)生答題并提交 - 客觀題自動判分 - 主觀題進入人工閱卷 - 成績發(fā)布 - 學(xué)生查看成績和解析。這個流程里每個節(jié)點都有自己獨立的表結(jié)構(gòu)和狀態(tài)字段理清了后面寫代碼會順很多。2. 數(shù)據(jù)庫設(shè)計考試系統(tǒng)的地基考試平臺的大部分邏輯問題根源在表結(jié)構(gòu)上。表關(guān)系設(shè)計好了業(yè)務(wù)代碼只是蓋樓表關(guān)系設(shè)計亂了后面所有模塊都會跟著打補丁。下面按模塊拆開講。2.1 用戶與課程模塊用戶表是最基礎(chǔ)的表我一般在user表之外還會設(shè)計課程表和學(xué)生選課表這樣學(xué)生和教師的關(guān)系不會綁死在一個字段里。用戶表字段大概是這樣id、username、password、real_name、role、student_no、class_name、status、create_time。注意密碼不能存明文建議用BCrypt加密。很多同學(xué)喜歡用MD5但實際項目里BCrypt在每次加密時生成不同的鹽相同密碼加密后的結(jié)果都不一樣安全性明顯更好。課程表字段比較簡單id、course_name、teacher_id、class_name、create_time。選課表把學(xué)生和課程關(guān)聯(lián)起來id、student_id、course_id。為什么要單獨設(shè)計選課表因為一個學(xué)生可以選多門課一門課也有多個學(xué)生典型的多對多關(guān)系必須用中間表承接。2.2 題庫與試卷模塊題庫表是整個系統(tǒng)的核心資產(chǎn)。我常用的字段是id、course_id、type、title、options、answer、analysis、score、difficulty、create_time。type字段區(qū)分單選、多選、判斷、簡答四種題型。options字段的存儲方式我用的是“A.xxx|B.xxx|C.xxx|D.xxx”這種字符串格式簡單直觀。你當(dāng)然也可以用JSON格式更規(guī)范。但對課設(shè)而言字符串足夠只要寫入時做好格式校驗后面判分就不會出問題。判斷題答案我喜歡存“T”和“F”不存漢字的“正確/錯誤”。這樣判分就是簡單的字符串比較省去各種編碼和空格問題。試卷表字段可以設(shè)計成id、paper_name、course_id、total_score、duration、start_time、end_time、status、create_by。考試時間范圍、考試時長、總分這些關(guān)鍵業(yè)務(wù)屬性都放在這里。另外需要單獨建一張試卷題目關(guān)聯(lián)表paper_question字段包括id、paper_id、question_id、sort。這里有個細節(jié)組卷時生成的題目順序要固化成sort字段不要讓學(xué)生每次刷新看到的題目順序都不一樣否則考試體驗很差。下面是一張核心建表SQL示例CREATE TABLE question ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id BIGINT NOT NULL COMMENT 所屬課程, type TINYINT NOT NULL COMMENT 1單選 2多選 3判斷 4簡答, title VARCHAR(500) NOT NULL COMMENT 題干, options VARCHAR(1000) DEFAULT NULL COMMENT 選項用|分隔, answer VARCHAR(255) NOT NULL COMMENT 標(biāo)準(zhǔn)答案, analysis VARCHAR(1000) DEFAULT NULL COMMENT 解析, score INT NOT NULL DEFAULT 5 COMMENT 分值, difficulty TINYINT DEFAULT 1 COMMENT 1簡單 2中等 3困難, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;2.3 考試記錄與快照設(shè)計考試記錄表exam_record跟蹤每一次考試實例id、paper_id、student_id、start_time、submit_time、status、objective_score、subjective_score、total_score。status字段標(biāo)記考試狀態(tài)比如ongoing、submitted、graded這是整個考試流程的狀態(tài)機核心。學(xué)生每次作答的明細放在answer_record表id、exam_record_id、question_id、student_answer、is_correct、score。考生提交一道題就保存一道題交卷時再統(tǒng)一判分。這里特別想強調(diào)“快照”這個設(shè)計。學(xué)生在進入考試那一刻系統(tǒng)要把試卷題目、題目分?jǐn)?shù)、標(biāo)準(zhǔn)答案一起復(fù)制到考試記錄里而不是交卷時再去題庫實時讀數(shù)據(jù)。我第一次做的時候沒有快照結(jié)果老師考試中途改了一道題的答案之前已經(jīng)交卷學(xué)生的成績?nèi)兞?。這個教訓(xùn)讓我意識到考試系統(tǒng)的一致性不能依賴“隨時可變的業(yè)務(wù)數(shù)據(jù)”?？煺兆侄螘嗾家稽c存儲空間但換來的是極高的數(shù)據(jù)穩(wěn)定性這個交易完全值得。3. 核心功能模塊實現(xiàn)與實操拆解3.1 登錄鑒權(quán)與全局用戶態(tài)登錄模塊我推薦用JWT方案。用戶登錄成功后后端把用戶id、角色、用戶名放進token的claims里前端后續(xù)請求在Authorization頭帶上token后端配置攔截器統(tǒng)一解析。為什么不用傳統(tǒng)的Session課設(shè)階段用Session其實也沒問題但JWT更接近現(xiàn)在主流的接口風(fēng)格代碼寫出來也更好講。用jjwt庫代碼量不大String token Jwts.builder() .setSubject(userId.toString()) .claim(role, user.getRole()) .claim(username, user.getUsername()) .setExpiration(new Date(System.currentTimeMillis() 1000 * 60 * 60 * 12)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();密鑰放在application.yml里不要硬編碼。攔截器里解析token失敗就返回401成功就把用戶信息放進ThreadLocalService層需要當(dāng)前用戶時直接取。這個方案對前端也很友好后面如果想把頁面升級成Vue分離版接口可以原封不動地復(fù)用。3.2 題庫管理與Excel批量導(dǎo)入錄入題目是最耗時的工作所以題庫模塊一定要支持Excel批量導(dǎo)入。Apache POI是常用方案讀取xlsx文件后遍歷每一行解析出題型、題干、選項、答案、解析、分值然后批量寫入數(shù)據(jù)庫。批量導(dǎo)入最常見的坑有幾個xls和xlsx格式兼容問題建議統(tǒng)一使用xlsx讀取方式不一樣?？招泻涂諉卧駮馕龀鰊ull需要判空處理否則入庫時報錯。答案格式不規(guī)范比如多選題寫成“A,B,C ”帶空格或“ABC”不帶逗號。導(dǎo)入時最好統(tǒng)一清洗成規(guī)范格式。導(dǎo)入完成要給教師明確的反饋成功多少條、失敗多少條、哪一行哪一列格式有問題。不要悶頭導(dǎo)入完就什么都不提示。這里可以寫一個導(dǎo)入結(jié)果對象包含成功數(shù)量和失敗原因列表。3.3 手動/自動組卷邏輯組卷是考試平臺最有“業(yè)務(wù)味”的模塊。手動組卷比較好理解教師從題目列表里勾選題目加入試卷設(shè)置分值保存時校驗總分。自動組卷我建議做成“按題型設(shè)置數(shù)量按難度分布抽題”。核心是隨機抽題SQLListLong questionIds questionMapper.selectList( new LambdaQueryWrapperQuestion() .eq(Question::getCourseId, courseId) .eq(Question::getType, type) .eq(Question::getDifficulty, difficulty) .last(ORDER BY RAND() LIMIT count) ).stream().map(Question::getId).collect(Collectors.toList());MySQL的ORDER BY RAND()在幾十萬級數(shù)據(jù)量的場景下會有性能問題但課設(shè)階段的題庫規(guī)模小直接使用完全沒問題。如果你想把項目做得更亮眼可以在設(shè)計文檔里專門提一句這個方法的適用邊界再引出其他更優(yōu)的隨機方案面試時這是加分點。組卷保存前一定要校驗總分。比如試卷設(shè)置了100分但勾選的題目加起來只有90分必須給出提示。我見過不少項目這里沒有校驗學(xué)生考完成績統(tǒng)計總是對不上后來查原因就是總分虛標(biāo)。3.4 在線考試、自動判分與成績統(tǒng)計在線考試模塊是整個系統(tǒng)最需要謹(jǐn)慎的地方核心在狀態(tài)管理。學(xué)生點擊“開始考試”后后端先創(chuàng)建一條exam_record狀態(tài)設(shè)為ongoing記錄start_time。答題時前端每保存一題就調(diào)用一次接口后端把答案寫入answer_record。交卷有兩種入口學(xué)生主動點擊交卷或考試時間到觸發(fā)自動交卷。前端倒計時只是體驗優(yōu)化負責(zé)在最后一秒提醒用戶真正的超時兜底邏輯必須在后端。后端交卷方法要做的事檢查exam_record當(dāng)前狀態(tài)如果已提交直接拒絕防止重復(fù)提交。遍歷所有answer_record對客觀題自動判分。累加客觀題得分主觀題標(biāo)記為待閱卷。更新exam_record狀態(tài)和成績字段。客觀題判分邏輯很直接String correct question.getAnswer(); String studentAnswer answerRecord.getStudentAnswer(); if (single.equals(question.getType()) || judge.equals(question.getType())) { boolean isCorrect correct.equalsIgnoreCase(studentAnswer.trim()); answerRecord.setCorrect(isCorrect); if (isCorrect) { answerRecord.setScore(question.getScore()); } }多選題的判分規(guī)則可以根據(jù)需要定義。常用的有“全對才得分”和“多選/漏選得一半分”兩種。實際項目里規(guī)則的定義應(yīng)放在單獨的類里通過一個接口類定義判分策略不同的題型用不同的實現(xiàn)。這樣做的好處是后續(xù)如果要加不定項選擇這類新題型直接擴展實現(xiàn)類就行不需要改動判分主流程。成績統(tǒng)計建議做三個維度班級平均分、分?jǐn)?shù)段分布、每題正確率。前端用ECharts展示柱狀圖和折線圖底部數(shù)據(jù)從后端統(tǒng)計接口讀。統(tǒng)計SQL會有一些連表查詢建議用注解SQL或XML寫清楚別在Java代碼里拼字符串SQL。4. 開發(fā)過程中的那些坑與解決方法4.1 時間與時區(qū)時區(qū)問題幾乎每個項目都會遇到。癥狀很典型數(shù)據(jù)庫存的時間比實際時間少8小時或者前端拿到的時間是一個數(shù)組而不是字符串。解決辦法分三部分MySQL連接串加上serverTimezoneAsia/Shanghai。實體類時間字段統(tǒng)一用LocalDateTime不要Date和LocalDateTime混用。在application.yml里配置Jackson格式化讓LocalDateTime輸出成字符串。配置Jackson的寫法spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8這三個配置都設(shè)置好后時間問題基本能一次性解決。4.2 試卷快照與答案一致性前面說快照設(shè)計專門打了一個伏筆這里再展開。考試系統(tǒng)不能因為后臺改題影響已經(jīng)產(chǎn)生的成績。我最初做的時候answer_record里只存了question_id交卷后從題庫實時讀題目解析和答案。后來老師考完修改了一道題的答案“歷史考試”的解析頁面也跟著變了數(shù)據(jù)完全對不上。正確做法是在answer_record表里冗余存儲題目內(nèi)容、標(biāo)準(zhǔn)答案、題目分?jǐn)?shù)。也就是快照。作答明細里看到的就是考試那一刻的試卷跟題庫里后來怎么改都無關(guān)。這是考試系統(tǒng)最核心的數(shù)據(jù)一致性設(shè)計寫文檔時要著重講。4.3 POI的版本沖突POI的版本沖突是導(dǎo)入功能最常見的報錯源頭。表現(xiàn)是運行時拋出NoSuchMethodError排查起來比較費勁。原因通常是項目里同時存在多個org.apache.poi的間接依賴版本不一致。我的建議是能用EasyExcel就盡量用EasyExcel它內(nèi)部把poi版本統(tǒng)一管理了少操很多心。如果必須直接用POI那就檢查所有pom依賴?yán)镉袥]有引入多個不同版本的poi和poi-ooxml只保留一個統(tǒng)一的版本。4.4 分頁插件與事務(wù)控制MyBatis-Plus分頁必須配置PaginationInnerInterceptor否則page方法返回的數(shù)據(jù)不對這是最常見的問題之一。很多同學(xué)寫了分頁代碼但忘了注冊插件查出來的total永遠是0還以為是SQL寫錯了。配置方式很簡單在MyBatis配置類里添加一個MybatisPlusInterceptor Bean即可。事務(wù)控制要重點放在交卷接口上。交卷和判分是一個整體操作任何一步報錯都必須回滾不能讓學(xué)生交了卷但成績沒有生成。方法上加上Transactional同時注意不要把耗時操作放在事務(wù)里。比如自動判分時循環(huán)里一條條更新數(shù)據(jù)庫整個事務(wù)時間會拉長。更優(yōu)的做法是先循環(huán)判斷結(jié)果收集要更新的對象最后統(tǒng)一調(diào)用updateBatchById批量更新能明顯縮短事務(wù)耗時。5. 常見問題排查速查與項目擴展方向5.1 常見問題速查表現(xiàn)象可能原因解決方案啟動報數(shù)據(jù)庫連接失敗連接URL、用戶名、密碼配置錯誤檢查jdbc地址確認MySQL服務(wù)已啟動核對用戶權(quán)限時間輸出為數(shù)組格式Jackson不支持LocalDateTime默認序列化配置JavaTimeModule或統(tǒng)一時間戳格式列表接口返回總數(shù)為0MyBatis-Plus分頁插件未注冊添加PaginationInnerInterceptor上傳Excel后中文亂碼文件流解析未指定字符集正確設(shè)置讀取編碼處理后統(tǒng)一UTF-8入庫交卷后成績沒生成判分邏輯異常或事務(wù)未提交查看日志檢查是否有未處理的簡答題導(dǎo)致流程中斷前端跨域報錯后端未配置CORS配置WebMvcConfigurer添加跨域規(guī)則頁面刷新后題目順序變化隨機抽題結(jié)果未保存sort字段組卷時固化paper_question中的順序5.2 生產(chǎn)級擴展方向如果時間允許這幾個方向特別適合作為答辯和面試亮點防切屏功能監(jiān)聽瀏覽器頁面可見性變化切屏超過設(shè)定次數(shù)后自動交卷或在后臺標(biāo)記異常記錄。題目順序和選項隨機學(xué)生進入考試時把試卷快照里的題目順序、選項順序打亂。這個功能做起來不復(fù)雜但能從“防作弊”角度展示思考深度。Redis緩存熱點試卷把經(jīng)常被學(xué)生同時訪問的試卷緩存起來減少數(shù)據(jù)庫壓力。在線閱卷頁面為簡答題提供評分界面支持按得分點關(guān)鍵詞快速給分。WebSocket強制收卷教師可以實時推送收卷指令到在線考試的學(xué)生端。這些擴展每一個都足夠在答辯證里單獨講兩分鐘而且實現(xiàn)難度可控。不要一上來就全部鋪開選一個做透就行。我個人在實際操作中的體會是做這類項目最重要的一步是把數(shù)據(jù)庫設(shè)計想清楚特別是快照和狀態(tài)字段。代碼本身大多是對表數(shù)據(jù)的流轉(zhuǎn)和加工但如果你在設(shè)計階段就預(yù)留好冗余字段、狀態(tài)字段、時間字段后面會遇到的問題至少減少一半。還有一點最終交付時源碼、數(shù)據(jù)庫腳本和一份能按步驟跑起來的說明文檔都要齊全。課程設(shè)計和畢業(yè)設(shè)計考察的恰恰是你把完整流程想清楚并交付清楚的能力。如果你正卡在某個模塊上優(yōu)先看數(shù)據(jù)庫設(shè)計和判分邏輯這兩塊它們是最容易出現(xiàn)隱性bug、也最值得花時間打磨的地方。把這條主線跑通之后這個項目能做到的深度遠不止一個普通的“系統(tǒng)開發(fā)”課設(shè)那么簡單。 Spring Boot在線考試平臺從數(shù)據(jù)庫設(shè)計到自動判分的完整實踐
在線考試平臺這個題在Spring Boot相關(guān)的課程設(shè)計和畢業(yè)設(shè)計里出現(xiàn)頻率真的非常高。它表面上是一個“系統(tǒng)開發(fā)”題目實際做起來卻要覆蓋多角色權(quán)限、題庫組織、組卷策略、考試狀態(tài)流轉(zhuǎn)、自動判分、成績統(tǒng)計這一整條業(yè)務(wù)鏈路。相比單純的增刪改查這類項目更考驗?zāi)銓I(yè)務(wù)流程的理解以及碰到邊界情況時能不能把邏輯做嚴(yán)謹(jǐn)。我當(dāng)時做這個項目時花了大量時間在數(shù)據(jù)庫設(shè)計和判分一致性上后期反而很輕松。今天就把完整的設(shè)計思路、核心表結(jié)構(gòu)、關(guān)鍵代碼邏輯以及那些在調(diào)試中踩過的坑一次說清楚。無論你是準(zhǔn)備做課程設(shè)計還是想拿一個完整的Spring Boot練手項目這篇文章都能直接參考。1. 項目整體設(shè)計與技術(shù)選型1.1 為什么在線考試平臺用Spring Boot最合適先說實話課設(shè)和畢設(shè)階段完全不需要上微服務(wù)那一套。在線考試平臺的用戶量和使用場景很集中業(yè)務(wù)邊界也很清楚本質(zhì)上就是一個標(biāo)準(zhǔn)的單體Web系統(tǒng)。Spring Boot在這種場景下簡直是量身定做的自帶內(nèi)嵌Tomcat打包成jar文件就能跑把“本地起服務(wù)”的成本降到極低。同學(xué)拿到源碼后裝好JDK、MySQL、Maven改一下數(shù)據(jù)庫連接就能把項目跑起來這在后期答辯演示時優(yōu)勢很大。Spring Boot還有一個實際好處生態(tài)對這類系統(tǒng)覆蓋得很好。登錄鑒權(quán)有Spring Security或JWT持久層用MyBatis-PlusExcel導(dǎo)入用POI或EasyExcel統(tǒng)計圖表直接前端引入ECharts每個環(huán)節(jié)都有大量可查的資料。相比SSM要手動配置一大堆XMLSpring Boot用起步依賴把常見的配置都收攏了新手只需要關(guān)注自己代碼的部分即可。我試過很多次對時間緊的同學(xué)來說Spring Boot確實是性價比最高的選擇。從答辯角度講Spring Boot還能引出“自動配置”“內(nèi)嵌容器”“起步依賴”“約定優(yōu)于配置”這些高頻面試點。你只要在項目里把JWT鑒權(quán)、攔截器、全局異常處理、事務(wù)控制都用上面試官問起來就有具體案例可以講而不是停留在“我調(diào)用過某個接口”這種層面。1.2 角色與權(quán)限設(shè)計三類角色是考試平臺的標(biāo)配學(xué)生、教師、管理員。我建議把它們放在同一張用戶表里用role字段區(qū)分不要拆成三張表。原因是登錄入口只有一個所有角色的校驗邏輯可以統(tǒng)一走同一套JWT鑒權(quán)后續(xù)擴展角色也很方便。學(xué)生查看考試列表、開始考試、交卷后查看分?jǐn)?shù)和答卷解析、查看個人成績曲線。教師維護題庫、創(chuàng)建試卷、手動選題或隨機組卷、在線閱卷、查看所授課程的成績統(tǒng)計。管理員管理系統(tǒng)基礎(chǔ)數(shù)據(jù)比如課程、班級、用戶賬號重置密碼查看全站統(tǒng)計。權(quán)限控制在課設(shè)階段最實用的方案是攔截器加注解不需要把Spring Security整個搬進來。實現(xiàn)方式是這樣的定義一個RequireRole注解標(biāo)注在Controller方法上攔截器里解析當(dāng)前登錄用戶的角色角色不匹配就返回統(tǒng)一格式的錯誤信息。這種方式代碼量不大而且很好講清楚權(quán)限設(shè)計的思路。1.3 核心模塊劃分整個系統(tǒng)按功能拆成六大模塊系統(tǒng)管理、用戶認證、題庫管理、試卷管理、在線考試、成績統(tǒng)計。其中組卷和在線考試是這個項目區(qū)別于普通管理系統(tǒng)的核心也是設(shè)計文檔里最值得展開寫的內(nèi)容。動手寫代碼之前建議先把業(yè)務(wù)狀態(tài)線畫出來教師創(chuàng)建試卷并發(fā)布考試 - 學(xué)生進入考試生成試卷快照 - 學(xué)生答題并提交 - 客觀題自動判分 - 主觀題進入人工閱卷 - 成績發(fā)布 - 學(xué)生查看成績和解析。這個流程里每個節(jié)點都有自己獨立的表結(jié)構(gòu)和狀態(tài)字段理清了后面寫代碼會順很多。2. 數(shù)據(jù)庫設(shè)計考試系統(tǒng)的地基考試平臺的大部分邏輯問題根源在表結(jié)構(gòu)上。表關(guān)系設(shè)計好了業(yè)務(wù)代碼只是蓋樓表關(guān)系設(shè)計亂了后面所有模塊都會跟著打補丁。下面按模塊拆開講。2.1 用戶與課程模塊用戶表是最基礎(chǔ)的表我一般在user表之外還會設(shè)計課程表和學(xué)生選課表這樣學(xué)生和教師的關(guān)系不會綁死在一個字段里。用戶表字段大概是這樣id、username、password、real_name、role、student_no、class_name、status、create_time。注意密碼不能存明文建議用BCrypt加密。很多同學(xué)喜歡用MD5但實際項目里BCrypt在每次加密時生成不同的鹽相同密碼加密后的結(jié)果都不一樣安全性明顯更好。課程表字段比較簡單id、course_name、teacher_id、class_name、create_time。選課表把學(xué)生和課程關(guān)聯(lián)起來id、student_id、course_id。為什么要單獨設(shè)計選課表因為一個學(xué)生可以選多門課一門課也有多個學(xué)生典型的多對多關(guān)系必須用中間表承接。2.2 題庫與試卷模塊題庫表是整個系統(tǒng)的核心資產(chǎn)。我常用的字段是id、course_id、type、title、options、answer、analysis、score、difficulty、create_time。type字段區(qū)分單選、多選、判斷、簡答四種題型。options字段的存儲方式我用的是“A.xxx|B.xxx|C.xxx|D.xxx”這種字符串格式簡單直觀。你當(dāng)然也可以用JSON格式更規(guī)范。但對課設(shè)而言字符串足夠只要寫入時做好格式校驗后面判分就不會出問題。判斷題答案我喜歡存“T”和“F”不存漢字的“正確/錯誤”。這樣判分就是簡單的字符串比較省去各種編碼和空格問題。試卷表字段可以設(shè)計成id、paper_name、course_id、total_score、duration、start_time、end_time、status、create_by。考試時間范圍、考試時長、總分這些關(guān)鍵業(yè)務(wù)屬性都放在這里。另外需要單獨建一張試卷題目關(guān)聯(lián)表paper_question字段包括id、paper_id、question_id、sort。這里有個細節(jié)組卷時生成的題目順序要固化成sort字段不要讓學(xué)生每次刷新看到的題目順序都不一樣否則考試體驗很差。下面是一張核心建表SQL示例CREATE TABLE question ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id BIGINT NOT NULL COMMENT 所屬課程, type TINYINT NOT NULL COMMENT 1單選 2多選 3判斷 4簡答, title VARCHAR(500) NOT NULL COMMENT 題干, options VARCHAR(1000) DEFAULT NULL COMMENT 選項用|分隔, answer VARCHAR(255) NOT NULL COMMENT 標(biāo)準(zhǔn)答案, analysis VARCHAR(1000) DEFAULT NULL COMMENT 解析, score INT NOT NULL DEFAULT 5 COMMENT 分值, difficulty TINYINT DEFAULT 1 COMMENT 1簡單 2中等 3困難, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;2.3 考試記錄與快照設(shè)計考試記錄表exam_record跟蹤每一次考試實例id、paper_id、student_id、start_time、submit_time、status、objective_score、subjective_score、total_score。status字段標(biāo)記考試狀態(tài)比如ongoing、submitted、graded這是整個考試流程的狀態(tài)機核心。學(xué)生每次作答的明細放在answer_record表id、exam_record_id、question_id、student_answer、is_correct、score。考生提交一道題就保存一道題交卷時再統(tǒng)一判分。這里特別想強調(diào)“快照”這個設(shè)計。學(xué)生在進入考試那一刻系統(tǒng)要把試卷題目、題目分?jǐn)?shù)、標(biāo)準(zhǔn)答案一起復(fù)制到考試記錄里而不是交卷時再去題庫實時讀數(shù)據(jù)。我第一次做的時候沒有快照結(jié)果老師考試中途改了一道題的答案之前已經(jīng)交卷學(xué)生的成績?nèi)兞?。這個教訓(xùn)讓我意識到考試系統(tǒng)的一致性不能依賴“隨時可變的業(yè)務(wù)數(shù)據(jù)”?？煺兆侄螘嗾家稽c存儲空間但換來的是極高的數(shù)據(jù)穩(wěn)定性這個交易完全值得。3. 核心功能模塊實現(xiàn)與實操拆解3.1 登錄鑒權(quán)與全局用戶態(tài)登錄模塊我推薦用JWT方案。用戶登錄成功后后端把用戶id、角色、用戶名放進token的claims里前端后續(xù)請求在Authorization頭帶上token后端配置攔截器統(tǒng)一解析。為什么不用傳統(tǒng)的Session課設(shè)階段用Session其實也沒問題但JWT更接近現(xiàn)在主流的接口風(fēng)格代碼寫出來也更好講。用jjwt庫代碼量不大String token Jwts.builder() .setSubject(userId.toString()) .claim(role, user.getRole()) .claim(username, user.getUsername()) .setExpiration(new Date(System.currentTimeMillis() 1000 * 60 * 60 * 12)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();密鑰放在application.yml里不要硬編碼。攔截器里解析token失敗就返回401成功就把用戶信息放進ThreadLocalService層需要當(dāng)前用戶時直接取。這個方案對前端也很友好后面如果想把頁面升級成Vue分離版接口可以原封不動地復(fù)用。3.2 題庫管理與Excel批量導(dǎo)入錄入題目是最耗時的工作所以題庫模塊一定要支持Excel批量導(dǎo)入。Apache POI是常用方案讀取xlsx文件后遍歷每一行解析出題型、題干、選項、答案、解析、分值然后批量寫入數(shù)據(jù)庫。批量導(dǎo)入最常見的坑有幾個xls和xlsx格式兼容問題建議統(tǒng)一使用xlsx讀取方式不一樣?？招泻涂諉卧駮馕龀鰊ull需要判空處理否則入庫時報錯。答案格式不規(guī)范比如多選題寫成“A,B,C ”帶空格或“ABC”不帶逗號。導(dǎo)入時最好統(tǒng)一清洗成規(guī)范格式。導(dǎo)入完成要給教師明確的反饋成功多少條、失敗多少條、哪一行哪一列格式有問題。不要悶頭導(dǎo)入完就什么都不提示。這里可以寫一個導(dǎo)入結(jié)果對象包含成功數(shù)量和失敗原因列表。3.3 手動/自動組卷邏輯組卷是考試平臺最有“業(yè)務(wù)味”的模塊。手動組卷比較好理解教師從題目列表里勾選題目加入試卷設(shè)置分值保存時校驗總分。自動組卷我建議做成“按題型設(shè)置數(shù)量按難度分布抽題”。核心是隨機抽題SQLListLong questionIds questionMapper.selectList( new LambdaQueryWrapperQuestion() .eq(Question::getCourseId, courseId) .eq(Question::getType, type) .eq(Question::getDifficulty, difficulty) .last(ORDER BY RAND() LIMIT count) ).stream().map(Question::getId).collect(Collectors.toList());MySQL的ORDER BY RAND()在幾十萬級數(shù)據(jù)量的場景下會有性能問題但課設(shè)階段的題庫規(guī)模小直接使用完全沒問題。如果你想把項目做得更亮眼可以在設(shè)計文檔里專門提一句這個方法的適用邊界再引出其他更優(yōu)的隨機方案面試時這是加分點。組卷保存前一定要校驗總分。比如試卷設(shè)置了100分但勾選的題目加起來只有90分必須給出提示。我見過不少項目這里沒有校驗學(xué)生考完成績統(tǒng)計總是對不上后來查原因就是總分虛標(biāo)。3.4 在線考試、自動判分與成績統(tǒng)計在線考試模塊是整個系統(tǒng)最需要謹(jǐn)慎的地方核心在狀態(tài)管理。學(xué)生點擊“開始考試”后后端先創(chuàng)建一條exam_record狀態(tài)設(shè)為ongoing記錄start_time。答題時前端每保存一題就調(diào)用一次接口后端把答案寫入answer_record。交卷有兩種入口學(xué)生主動點擊交卷或考試時間到觸發(fā)自動交卷。前端倒計時只是體驗優(yōu)化負責(zé)在最后一秒提醒用戶真正的超時兜底邏輯必須在后端。后端交卷方法要做的事檢查exam_record當(dāng)前狀態(tài)如果已提交直接拒絕防止重復(fù)提交。遍歷所有answer_record對客觀題自動判分。累加客觀題得分主觀題標(biāo)記為待閱卷。更新exam_record狀態(tài)和成績字段。客觀題判分邏輯很直接String correct question.getAnswer(); String studentAnswer answerRecord.getStudentAnswer(); if (single.equals(question.getType()) || judge.equals(question.getType())) { boolean isCorrect correct.equalsIgnoreCase(studentAnswer.trim()); answerRecord.setCorrect(isCorrect); if (isCorrect) { answerRecord.setScore(question.getScore()); } }多選題的判分規(guī)則可以根據(jù)需要定義。常用的有“全對才得分”和“多選/漏選得一半分”兩種。實際項目里規(guī)則的定義應(yīng)放在單獨的類里通過一個接口類定義判分策略不同的題型用不同的實現(xiàn)。這樣做的好處是后續(xù)如果要加不定項選擇這類新題型直接擴展實現(xiàn)類就行不需要改動判分主流程。成績統(tǒng)計建議做三個維度班級平均分、分?jǐn)?shù)段分布、每題正確率。前端用ECharts展示柱狀圖和折線圖底部數(shù)據(jù)從后端統(tǒng)計接口讀。統(tǒng)計SQL會有一些連表查詢建議用注解SQL或XML寫清楚別在Java代碼里拼字符串SQL。4. 開發(fā)過程中的那些坑與解決方法4.1 時間與時區(qū)時區(qū)問題幾乎每個項目都會遇到。癥狀很典型數(shù)據(jù)庫存的時間比實際時間少8小時或者前端拿到的時間是一個數(shù)組而不是字符串。解決辦法分三部分MySQL連接串加上serverTimezoneAsia/Shanghai。實體類時間字段統(tǒng)一用LocalDateTime不要Date和LocalDateTime混用。在application.yml里配置Jackson格式化讓LocalDateTime輸出成字符串。配置Jackson的寫法spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8這三個配置都設(shè)置好后時間問題基本能一次性解決。4.2 試卷快照與答案一致性前面說快照設(shè)計專門打了一個伏筆這里再展開。考試系統(tǒng)不能因為后臺改題影響已經(jīng)產(chǎn)生的成績。我最初做的時候answer_record里只存了question_id交卷后從題庫實時讀題目解析和答案。后來老師考完修改了一道題的答案“歷史考試”的解析頁面也跟著變了數(shù)據(jù)完全對不上。正確做法是在answer_record表里冗余存儲題目內(nèi)容、標(biāo)準(zhǔn)答案、題目分?jǐn)?shù)。也就是快照。作答明細里看到的就是考試那一刻的試卷跟題庫里后來怎么改都無關(guān)。這是考試系統(tǒng)最核心的數(shù)據(jù)一致性設(shè)計寫文檔時要著重講。4.3 POI的版本沖突POI的版本沖突是導(dǎo)入功能最常見的報錯源頭。表現(xiàn)是運行時拋出NoSuchMethodError排查起來比較費勁。原因通常是項目里同時存在多個org.apache.poi的間接依賴版本不一致。我的建議是能用EasyExcel就盡量用EasyExcel它內(nèi)部把poi版本統(tǒng)一管理了少操很多心。如果必須直接用POI那就檢查所有pom依賴?yán)镉袥]有引入多個不同版本的poi和poi-ooxml只保留一個統(tǒng)一的版本。4.4 分頁插件與事務(wù)控制MyBatis-Plus分頁必須配置PaginationInnerInterceptor否則page方法返回的數(shù)據(jù)不對這是最常見的問題之一。很多同學(xué)寫了分頁代碼但忘了注冊插件查出來的total永遠是0還以為是SQL寫錯了。配置方式很簡單在MyBatis配置類里添加一個MybatisPlusInterceptor Bean即可。事務(wù)控制要重點放在交卷接口上。交卷和判分是一個整體操作任何一步報錯都必須回滾不能讓學(xué)生交了卷但成績沒有生成。方法上加上Transactional同時注意不要把耗時操作放在事務(wù)里。比如自動判分時循環(huán)里一條條更新數(shù)據(jù)庫整個事務(wù)時間會拉長。更優(yōu)的做法是先循環(huán)判斷結(jié)果收集要更新的對象最后統(tǒng)一調(diào)用updateBatchById批量更新能明顯縮短事務(wù)耗時。5. 常見問題排查速查與項目擴展方向5.1 常見問題速查表現(xiàn)象可能原因解決方案啟動報數(shù)據(jù)庫連接失敗連接URL、用戶名、密碼配置錯誤檢查jdbc地址確認MySQL服務(wù)已啟動核對用戶權(quán)限時間輸出為數(shù)組格式Jackson不支持LocalDateTime默認序列化配置JavaTimeModule或統(tǒng)一時間戳格式列表接口返回總數(shù)為0MyBatis-Plus分頁插件未注冊添加PaginationInnerInterceptor上傳Excel后中文亂碼文件流解析未指定字符集正確設(shè)置讀取編碼處理后統(tǒng)一UTF-8入庫交卷后成績沒生成判分邏輯異常或事務(wù)未提交查看日志檢查是否有未處理的簡答題導(dǎo)致流程中斷前端跨域報錯后端未配置CORS配置WebMvcConfigurer添加跨域規(guī)則頁面刷新后題目順序變化隨機抽題結(jié)果未保存sort字段組卷時固化paper_question中的順序5.2 生產(chǎn)級擴展方向如果時間允許這幾個方向特別適合作為答辯和面試亮點防切屏功能監(jiān)聽瀏覽器頁面可見性變化切屏超過設(shè)定次數(shù)后自動交卷或在后臺標(biāo)記異常記錄。題目順序和選項隨機學(xué)生進入考試時把試卷快照里的題目順序、選項順序打亂。這個功能做起來不復(fù)雜但能從“防作弊”角度展示思考深度。Redis緩存熱點試卷把經(jīng)常被學(xué)生同時訪問的試卷緩存起來減少數(shù)據(jù)庫壓力。在線閱卷頁面為簡答題提供評分界面支持按得分點關(guān)鍵詞快速給分。WebSocket強制收卷教師可以實時推送收卷指令到在線考試的學(xué)生端。這些擴展每一個都足夠在答辯證里單獨講兩分鐘而且實現(xiàn)難度可控。不要一上來就全部鋪開選一個做透就行。我個人在實際操作中的體會是做這類項目最重要的一步是把數(shù)據(jù)庫設(shè)計想清楚特別是快照和狀態(tài)字段。代碼本身大多是對表數(shù)據(jù)的流轉(zhuǎn)和加工但如果你在設(shè)計階段就預(yù)留好冗余字段、狀態(tài)字段、時間字段后面會遇到的問題至少減少一半。還有一點最終交付時源碼、數(shù)據(jù)庫腳本和一份能按步驟跑起來的說明文檔都要齊全。課程設(shè)計和畢業(yè)設(shè)計考察的恰恰是你把完整流程想清楚并交付清楚的能力。如果你正卡在某個模塊上優(yōu)先看數(shù)據(jù)庫設(shè)計和判分邏輯這兩塊它們是最容易出現(xiàn)隱性bug、也最值得花時間打磨的地方。把這條主線跑通之后這個項目能做到的深度遠不止一個普通的“系統(tǒng)開發(fā)”課設(shè)那么簡單。