簡介這是一份基于微信小程序與SSM框架的在線考試系統(tǒng)完整源碼包主要面向高校學(xué)生、課程設(shè)計及畢業(yè)設(shè)計開發(fā)者。系統(tǒng)已實現(xiàn)管理員端與用戶端管理員可維護用戶、考試資料、試題試卷、留言板及系統(tǒng)公告用戶可注冊登錄、瀏覽資料、在線參加考試并查看成績覆蓋常見考試業(yè)務(wù)閉環(huán)。后端使用Java SSMSpringSpringMVCMyBatis搭配MySQL數(shù)據(jù)庫小程序端采用微信原生框架開發(fā)前后端職責(zé)劃分清晰。壓縮包共1107個文件包含Java、Vue、JS等程序源碼WXML/WXSS小程序頁面PNG/SVG界面資源以及SQL建表腳本與項目配置文件合計16.19MB結(jié)構(gòu)完整便于本地導(dǎo)入運行。已有343人學(xué)習(xí)下載資源內(nèi)附完整工程與配置說明可輔助在本地配置運行適合參考其權(quán)限控制、組卷邏輯與考試狀態(tài)流轉(zhuǎn)等內(nèi)容能有效縮短畢業(yè)設(shè)計或課程項目的開發(fā)周期。1. 考試系統(tǒng)難的不是答題頁而是交卷那三秒這是一套什么方案拿到「基于微信小程序的考試系統(tǒng)設(shè)計與實現(xiàn)」這個題目時很多人的第一反應(yīng)是「做個答題頁面還不簡單」。但真正跑過一遍完整流程后你會發(fā)現(xiàn)這個系統(tǒng)最容易被演示環(huán)節(jié)擊穿的恰好是交卷那一刻網(wǎng)絡(luò)閃斷導(dǎo)致成績丟、倒計時被切后臺坑掉、題目亂序后答案對不上、重復(fù)提交產(chǎn)生兩條成績。這套基于微信小程序的考試系統(tǒng)設(shè)計方案解決的正是「題目展示、計時作答、交卷判分、成績留存」這條完整鏈路并且把微信生態(tài)的登錄能力直接復(fù)用省去了傳統(tǒng)網(wǎng)頁考試系統(tǒng)最麻煩的賬號注冊與找回密碼環(huán)節(jié)。它適合三類人拿它當(dāng)畢業(yè)設(shè)計選題、需要在答辯現(xiàn)場完整演示業(yè)務(wù)閉環(huán)的學(xué)生想為內(nèi)部培訓(xùn)、社團招新、課程測驗快速搭一套輕量考試工具的中小團隊以及準(zhǔn)備做考試類產(chǎn)品原型驗證的開發(fā)者。2. 選型與數(shù)據(jù)設(shè)計考試小程序為什么用云函數(shù)加文檔庫就夠2.1 三種落地方案的對比云開發(fā)、自建接口、第三方 BaaS考試系統(tǒng)的技術(shù)選型本質(zhì)上是「服務(wù)器誰養(yǎng)、鑒權(quán)怎么做、數(shù)據(jù)放哪里」三個問題的權(quán)衡。目前最常見的做法有三種小程序云開發(fā)、自建后端接口、接入第三方 BaaS 平臺。很多人一上來就選自建接口覺得這樣顯得技術(shù)含量高但如果你是做畢設(shè)或者小范圍內(nèi)部考試云開發(fā)反而是性價比最高的選擇。方案部署成本開發(fā)量鑒權(quán)實現(xiàn)適合場景小程序云開發(fā)低無需買服務(wù)器和域名中前端 云函數(shù) 云數(shù)據(jù)庫云函數(shù)上下文直接拿 openid畢設(shè)、小規(guī)模內(nèi)部考試、快速原型自建后端接口高需要服務(wù)器、域名備案、HTTPS高需要寫完整的用戶體系和接口層wx.login 拿 code 換 openid再自簽 token對數(shù)據(jù)安全、性能有強要求的生產(chǎn)系統(tǒng)第三方 BaaS低接入即用低但業(yè)務(wù)邏輯受平臺限制使用平臺賬號體系原型驗證、非核心業(yè)務(wù)我一般會建議多數(shù)讀者優(yōu)先選云開發(fā)。原因很直接考試系統(tǒng)的核心業(yè)務(wù)是「題庫、試卷、答卷、成績」這四類數(shù)據(jù)的關(guān)系維護而不是服務(wù)器運維。云開發(fā)天然解決了 openid 獲取、鑒權(quán)、數(shù)據(jù)庫讀寫這三個最耗時的問題而且微信開發(fā)者工具里可以一鍵部署云函數(shù)調(diào)試起來非常順。自建接口適合的場景是你需要對成績做防篡改審計、需要對接學(xué)?，F(xiàn)有統(tǒng)一身份認(rèn)證、或者預(yù)估同時在線考試人數(shù)超過千人。如果只是演示閉環(huán)和應(yīng)對幾十人同時考云開發(fā)完全夠用。2.2 數(shù)據(jù)表怎么定題目、試卷、答題記錄、成績的四種關(guān)系考試系統(tǒng)的數(shù)據(jù)設(shè)計是整個項目的骨架。很多人在寫代碼前不畫數(shù)據(jù)關(guān)系結(jié)果做到答題記錄時發(fā)現(xiàn)「試卷里的題目」和「題庫里的題目」混在一起改題庫會把歷史試卷也改掉。這里給出的是一套以文檔型數(shù)據(jù)庫為例的集合劃分換成 MySQL 等關(guān)系型數(shù)據(jù)庫同樣可以按這個思路建表。集合/表核心字段作用usersopenid、nickname、avatarUrl、createdAt用戶基礎(chǔ)信息openid 是微信生態(tài)唯一標(biāo)識questionssubjectId、type、content、options、answerIndex、analysis題庫題目與答案分離paperssubjectId、title、questions 快照、durationSeconds、createdAt試卷存的是組卷時刻的題目快照answersopenid、paperId、questionId、type、value、spendSeconds、submitAt逐題答題記錄用于錯題回看和行為分析scoresopenid、paperId、score、totalScore、submitAt成績單一次考試一條記錄這里最關(guān)鍵的設(shè)計決策是「試卷題目用快照不用關(guān)聯(lián)查詢」。組卷時把選中題目完整拷貝進 papers 集合的 questions 字段而不是存題目 ID 數(shù)組、每次考試時再去題庫里聯(lián)表查。這樣做的直接好處是如果考試進行到一半管理員修改了題庫里的某道題已開始考試的學(xué)生拿到的題目不會變成績也不會被題庫改動污染。代價是同一道題在數(shù)據(jù)庫里可能有多份拷貝但對于考試系統(tǒng)這個體量這點存儲成本完全可接受。2.3 考試狀態(tài)機從「未開始」到「已交卷」的六個狀態(tài)考試流程不能只靠前端頁面控制服務(wù)端必須維護一份狀態(tài)機否則學(xué)生可以繞過頁面直接調(diào)接口交卷或者重復(fù)交卷刷成績。我在設(shè)計時會把試卷狀態(tài)拆成以下六種前端的按鈕展示和后端的接口校驗都圍繞這套狀態(tài)來做。狀態(tài)值含義前端表現(xiàn)draft草稿組卷未完成不可見published已發(fā)布等待開考顯示「開始考試」按鈕ongoing進行中有考生正在作答顯示倒計時與答題卡submitted已交卷等待批閱等待成績graded已出分顯示成績與錯題回顧closed已關(guān)閉只讀狀態(tài)可查看歷史成績狀態(tài)機的核心價值在于「交卷接口的冪等性」。當(dāng)同一個學(xué)生重復(fù)提交試卷時后端只需要判斷 paperId 對應(yīng)的狀態(tài)是否已經(jīng)是 submitted 或 graded是就直接返回第一次的成績而不是重新判分、重新寫一條成績記錄。這個設(shè)計在弱網(wǎng)環(huán)境下非常重要因為客戶端可能發(fā)起了請求、服務(wù)端已經(jīng)處理成功但響應(yīng)包沒回到客戶端學(xué)生以為沒交上又點了一次交卷。沒有狀態(tài)機做兜底就會出現(xiàn)「一次考試兩條成績」的翻車現(xiàn)場。3. 小程序端核心實現(xiàn)倒計時、答題卡、交卷的最小可跑代碼3.1 答題頁的數(shù)據(jù)結(jié)構(gòu)與題型歸一化考試系統(tǒng)最常見的題型是單選、多選、判斷、填空。如果為每一種題型單獨寫一套頁面邏輯代碼會非常臃腫。我一般會做一層「題型歸一化」把四種題型統(tǒng)一成一個答題數(shù)據(jù)結(jié)構(gòu)頁面只負(fù)責(zé)渲染提交時一律按這個結(jié)構(gòu)走。// questionTypes.js 題型常量與答題結(jié)構(gòu)歸一化 const QUESTION_TYPES { RADIO: radio, // 單選value 存選中項下標(biāo)如 2 CHECKBOX: checkbox, // 多選value 存選中項下標(biāo)數(shù)組如 [0, 2] JUDGE: judge, // 判斷value 存 0 或 1 FILL: fill // 填空value 存用戶輸入的字符串 } // 每道題的答題結(jié)果統(tǒng)一為以下對象 // 記錄 spendSeconds 可以用于后續(xù)的答題行為分析也可以在成績頁展示用時 const answerItem { questionId: q_1024, type: QUESTION_TYPES.RADIO, value: 2, spendSeconds: 12 }這里要注意一個高頻翻車點多選題的 value 必須是數(shù)組且數(shù)組里存的是選項下標(biāo)而不是選項文本。因為前端展示時可能會做題目亂序一旦亂序選項下標(biāo)對應(yīng)的文本就變了如果你存的是文本后續(xù)判分和題目快照對照時非常容易錯位。判分時用「題目快照里的 answerIndex 數(shù)組」和「用戶提交的 value 數(shù)組」做集合比較兩個數(shù)組排序后相等才算對。填空則要注意去除首尾空格再比對避免學(xué)生多打一個空格被判錯。3.2 倒計時與切后臺為什么 setInterval 會「自己停下」倒計時是考試小程序里遇到坑最多的模塊。很多初學(xué)者的第一版是用 setInterval 每秒遞減一個剩余秒數(shù)變量真機一測就翻車把小程序切到后臺回個微信消息再切回來倒計時還在走但已經(jīng)比真實時間慢了十幾秒。原因是小程序在后臺運行時JS 定時器會被系統(tǒng)掛起等回到前臺才繼續(xù)執(zhí)行。解法很簡單不要累減變量而是用「絕對截止時間戳」做差值。// countdown.js 基于時間戳的倒計時封裝 const DEFAULT_DURATION 1800 // 考試時長單位秒30分鐘 const GRACE_SECONDS 5 // 寬限秒數(shù)防止用戶在最后一刻誤觸交卷 function startCountdown(deadlineTs, onTick, onTimeout) { const timer setInterval(() { const remainMs deadlineTs - Date.now() const remainSec Math.ceil(remainMs / 1000) if (remainSec 0) { clearInterval(timer) onTick(0) onTimeout() return } onTick(remainSec) }, 500) // 每500ms刷新一次避免每秒一次的視覺卡頓 }這個封裝的要點是deadlineTs 不是「剩余多少秒」而是「開考時間 考試時長」得到的絕對時間戳。開考時間由服務(wù)端下發(fā)的serverTime計算不能用本地時間因為考生手機的系統(tǒng)時間可能不準(zhǔn)。切后臺再回來時只需要在頁面的 onShow 生命周期里重新執(zhí)行一次Date.now()與 deadlineTs 的差值計算倒計時自然就校準(zhǔn)了。GRACE_SECONDS 的作用是倒計時歸零時先不強殺進入一個 5 秒的寬限期這 5 秒內(nèi)學(xué)生如果正在點交卷按鈕仍然視為有效提交超過寬限期則強制提交當(dāng)前已答內(nèi)容。3.3 交卷的本地緩存與服務(wù)端判分邊界交卷是整個系統(tǒng)里最不能出錯的環(huán)節(jié)因為網(wǎng)絡(luò)不可靠是常態(tài)但學(xué)生的答題結(jié)果必須可靠。我推薦的做法是「先寫本地緩存再請求服務(wù)端請求成功才清緩存失敗則保留待重試」。這樣即使學(xué)生在考試結(jié)束那一刻斷網(wǎng)成績也不會靜默丟失。// submitExam.js 交卷核心流程 async function submitExam(paperId, answers) { // 第1步先把答卷寫入本地緩存作為斷網(wǎng)兜底 wx.setStorageSync(pending_${paperId}, { answers, submitAt: Date.now() }) // 第2步調(diào)用云函數(shù)或自建后端接口 try { const res await wx.cloud.callFunction({ name: submitExam, data: { paperId, answers } }) const result res.result if (result.code 0) { // 服務(wù)端確認(rèn)接收后才清理本地緩存 wx.removeStorageSync(pending_${paperId}) wx.redirectTo({ url: /pages/result/result?paperId${paperId}score${result.score} }) } else { wx.showToast({ title: result.msg || 提交失敗, icon: none }) } } catch (err) { // 網(wǎng)絡(luò)異常時保留緩存回到頁面提示用戶重試 wx.showToast({ title: 提交失敗已暫存本地待重試, icon: none }) } }交卷后判分放在哪一端取決于你更看重「響應(yīng)速度」還是「結(jié)果可信」。純前端判分的好處是秒出成績演示效果好但如果學(xué)生用抓包工具改了答題數(shù)據(jù)前端判分的結(jié)果就不具備公信力。我在實際項目中采用的折中方案是前端先本地判分用于秒開成績頁同時把答案原樣提交給服務(wù)端服務(wù)端異步重新判分并覆蓋成績前端頁面展示的成績以服務(wù)端最終結(jié)果為準(zhǔn)。這樣兼顧了體驗和可信度。云函數(shù)的超時時間默認(rèn)只有 3 秒如果試卷題量大判分邏輯放在云函數(shù)里很容易超時這也是為什么把判分拆到客戶端會更穩(wěn)的原因之一。4. 后端鑒權(quán)與題庫接入從登錄到組卷的完整鏈路4.1 登錄鑒權(quán)wx.login 換 openid 后為什么要再簽一層 token微信小程序的登錄體系已經(jīng)相當(dāng)成熟但很多初學(xué)者容易犯一個錯誤把前端拿到的 openid 當(dāng)成唯一憑證到處用。openid 是用戶的弱隱私標(biāo)識它出現(xiàn)在前端代碼和請求參數(shù)里一旦被別人截獲就可以偽造身份提交答卷。正確做法是用 openid 換一個后端簽發(fā)的臨時 token后續(xù)所有接口都校驗 token。// 云函數(shù) login/index.js登錄并簽發(fā) token const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() exports.main async (event) { // 云函數(shù)上下文里直接拿 openid不需要前端傳 const { OPENID } cloud.getWXContext() const users db.collection(users) // 用戶不存在時自動注冊 const existed await users.where({ openid: OPENID }).get() if (existed.data.length 0) { await users.add({ data: { openid: OPENID, nickname: 考生, createdAt: Date.now() } }) } // 簽發(fā)臨時 token2小時過期 const token t_ Date.now() _ Math.random().toString(36).slice(2, 10) await db.collection(sessions).add({ data: { token, openid: OPENID, expiresAt: Date.now() 7200 * 1000 } }) return { code: 0, token, expiresIn: 7200 } }這個云函數(shù)的邏輯說明小程序端先通過wx.login()拿到 code但云開發(fā)場景下前端不需要傳 code云函數(shù)調(diào)用時微信會自動注入 openid。sessions 集合用來存有效 token前端每次請求把 token 放在 header 或 data 里后端校驗時去 sessions 集合查這個 token 是否存在且未過期。expiresIn 的單位是秒7200 表示兩小時實際項目中可以根據(jù)考試時長調(diào)整一般設(shè)為考試時長的 1.5 倍即可。如果自建后端流程是前端用 code 調(diào)微信接口換 openid后端再簽發(fā) token邏輯等價。4.2 題庫導(dǎo)入Excel 轉(zhuǎn) JSON 時最容易破壞的三個字段題庫數(shù)據(jù)是整個系統(tǒng)的心臟。很多人在搭建題庫時選擇了人工一條條往數(shù)據(jù)庫里錄入效率極低且容易錯。常見做法是用 Excel 維護題庫再通過腳本批量轉(zhuǎn)成 JSON 導(dǎo)入。這個轉(zhuǎn)換過程有三個字段非常容易出錯。{ subject: 計算機網(wǎng)絡(luò), questions: [ { id: q_1001, type: radio, content: OSI 參考模型共有幾層, options: [4, 5, 6, 7], answerIndex: 3, analysis: OSI 分為物理、數(shù)據(jù)鏈路、網(wǎng)絡(luò)、傳輸、會話、表示、應(yīng)用七層。 }, { id: q_1002, type: checkbox, content: 以下屬于傳輸層協(xié)議的是, options: [TCP, UDP, IP, HTTP], answerIndex: [0, 1] } ] }第一個易錯字段是 options 的排列順序。Excel 導(dǎo)入時如果選項列被排序工具重排過前端展示的順序和后端 answerIndex 的對應(yīng)關(guān)系就會被打破。第二個易錯字段是答案索引單選用數(shù)字下標(biāo)多選必須用數(shù)組判斷題的 answerIndex 建議統(tǒng)一用 1 表示正確、0 表示錯誤不要混用 true/false 和「對/錯」文本。第三個易錯點是題干中的特殊字符比如答案里的英文雙引號、換行符如果不做轉(zhuǎn)義JSON.parse 會直接報錯導(dǎo)入腳本必須對這類字符做預(yù)處理。4.3 組卷策略固定抽題、隨機抽題、試卷快照組卷是考試系統(tǒng)區(qū)別于普通答題工具的關(guān)鍵功能。一套題庫要能生成多套試卷每套試卷又能被多次考試使用這需要把「組卷」和「考試」做成兩個獨立環(huán)節(jié)。// buildPaper.js 組卷函數(shù)固定概率抽題并生成試卷快照 function buildPaper(subjectId, countPerType, shuffle) { // countPerType 示例{ radio: 10, checkbox: 5, judge: 5, fill: 3 } const snapshotQuestions pickQuestions(subjectId, countPerType, shuffle) // 把題目快照整體寫入 paper 記錄 // 后續(xù)修改題庫不影響已生成的試卷 const paper { subjectId, title: subjectId 標(biāo)準(zhǔn)模擬卷, questions: snapshotQuestions, durationSeconds: 1800, createdAt: Date.now() } return db.collection(papers).add({ data: paper }) } // pickQuestions 內(nèi)部邏輯按題型分組后從題庫里隨機取指定數(shù)量 // shuffle 為 true 時同時對題目順序和每道題的選項順序做亂序 function pickQuestions(subjectId, countPerType, shuffle) { // 從題庫按 subjectId type 過濾每組隨機取 count 道 // 若題庫題量不足需要提前做完整性校驗避免組出一張不夠題的試卷 }組卷的核心邏輯理解countPerType是各題型的題目數(shù)量比如單選題 10 道、多選題 5 道、判斷題 5 道、填空題 3 道。shuffle開關(guān)控制是否亂序亂序時必須把題目的 answerIndex 一起重新映射這就是前面章節(jié)反復(fù)強調(diào)的坑——洗牌只洗了 options 數(shù)組沒有同步更新答案下標(biāo)判斷題和多選題就會大面積誤判。試卷快照的意義前面已經(jīng)說過是為了保證成績可復(fù)現(xiàn)。另外還有一個實用習(xí)慣組卷時生成一張考試說明頁把題型分布、每題分值、考試時長一起展示給學(xué)生這套數(shù)據(jù)也一起寫進 paper 記錄避免前端寫死。5. 避坑手冊考試小程序最容易翻車的六個現(xiàn)場5.1 倒計時切后臺回來后還在走但交卷時間已超現(xiàn)象考生把小程序切到后臺回微信消息再切回來頁面倒計時顯示還剩 10 分鐘但服務(wù)端校驗時發(fā)現(xiàn)考試已經(jīng)超時拒絕接收答卷。 原因setInterval 在小程序后臺被系統(tǒng)掛起回到前臺才恢復(fù)而且代碼里用的是遞減變量而不是絕對時間戳差值。 解決倒計時一律基于deadlineTs - Date.now()計算deadlineTs 存在全局變量或 storage 中頁面的 onShow 生命周期里重新計算一次剩余時間并刷新 UI。服務(wù)端同步校驗收卷時間以服務(wù)端時間為準(zhǔn)絕不信任客戶端上報的本地時間。5.2 真機預(yù)覽請求失敗開發(fā)者工具卻一切正常現(xiàn)象在微信開發(fā)者工具里點擊交卷、加載題庫都正常一換成真機預(yù)覽接口請求全部報request:fail url not in domain list。 原因開發(fā)者工具默認(rèn)關(guān)閉了合法域名校驗而真機上微信強制校驗 request 請求的域名必須在小程序后臺配置過云開發(fā)調(diào)用走 wx.cloud 系列接口不受此限制自建接口則必須配置合法域名。 解決云開發(fā)場景直接用wx.cloud.callFunction不要手動拼 URL。自建接口場景在小程序管理后臺配置 request 合法域名域名必須備案并支持 HTTPS。開發(fā)者工具里關(guān)閉校驗只能用于本地調(diào)試不能作為真機方案。5.3 主包超過 2MB代碼上傳一直失敗現(xiàn)象代碼寫完后上傳提示主包體積超過 2MB無法提交審核。 原因最常見的體積殺手是題庫數(shù)據(jù)被直接寫在代碼里一個包含幾百道題帶圖片的 JSON 文件就能占掉大幾百 KB如果還塞了教材配套音頻、圖片素材超限是必然的。 解決題庫數(shù)據(jù)移入云數(shù)據(jù)庫或后端小程序端按需拉取題目不要整個文件打進包里。大體積的靜態(tài)資源用小程序的運行時分包加載或者放到云存儲后按需下載。注意主包體積限制是 2MB整個小程序總包上限是 20MB分包不是萬能藥資源能走后端就走后端。5.4 交卷時網(wǎng)絡(luò)閃斷成績靜默丟失現(xiàn)象學(xué)生在考試結(jié)束前最后 10 秒點了交卷頁面一直轉(zhuǎn)圈最后提示網(wǎng)絡(luò)錯誤學(xué)生刷新后重新進入發(fā)現(xiàn)沒有成績于是又做了一遍數(shù)據(jù)庫里出現(xiàn)兩條答卷記錄。 原因前端直接請求后端斷網(wǎng)時請求失敗且沒有重試機制后端接口沒有做冪等同一學(xué)生同一試卷提交多次會生成多條成績。 解決前端在發(fā)起請求前先把答卷寫入本地緩存請求成功后才清理緩存失敗時保留緩存并提示用戶重試后端對openid paperId做唯一約束或重復(fù)提交檢測已經(jīng)交過卷的請求直接返回第一次成績。兩個措施缺一不可只做前端的緩存換一臺設(shè)備成績依然會丟。5.5 題目亂序后答案對不上多選題翻車最嚴(yán)重現(xiàn)象開啟題目亂序和選項亂序后學(xué)生反饋「我明明選了對的卻給我判錯」其中多選題錯得最多。 原因亂序函數(shù)只打亂了 options 數(shù)組的順序沒有同步更新題目的 answerIndex。單選題碰巧首選項相同的還能對上多選題本身答案就是多個下標(biāo)錯位后幾乎不可能蒙對。 解決洗牌時用一個映射數(shù)組把舊下標(biāo)和新下標(biāo)的關(guān)系保留下來答題和判分時統(tǒng)一使用「新下標(biāo)」體系。前端 value 永遠存選項下標(biāo)不存選項文本判分前用題目快照中的 answerIndex 和用戶提交的 value 做排序后比較。5.6 云函數(shù)默認(rèn)超時太短判分跑到一半被掐斷現(xiàn)象本地調(diào)試云函數(shù)時一切正常真機上交卷后頻繁提示「云函數(shù)調(diào)用超時」考試成績偶爾能存上、偶爾存不上。 原因云函數(shù)的默認(rèn)超時時間只有 3 秒。一張卷子 30 道題判分邏輯加寫庫操作在弱網(wǎng)環(huán)境下很容易超過 3 秒而且每次調(diào)用都會冷啟動首次調(diào)用耗時更高。 解決把耗時的判分邏輯移到客戶端本地執(zhí)行云函數(shù)只做簡單的數(shù)據(jù)校驗和成績落庫或者在小程序云開發(fā)控制臺把該云函數(shù)的超時時間調(diào)大到 10~20 秒如果題目量特別大就改成異步任務(wù)交卷接口先返回「已受理」判分完成后通過訂閱消息或手動刷新獲取成績。6. 讓系統(tǒng)經(jīng)得起演示并發(fā)交卷與弱網(wǎng)聯(lián)調(diào)的驗證習(xí)慣答辯現(xiàn)場最怕的不是功能沒做完而是演示到交卷那一步突然翻車。我的習(xí)慣是每次改動代碼后都按一套標(biāo)準(zhǔn)的測試矩陣在真機上完整走一遍而不是只在開發(fā)者工具里點兩下就收工。測試場景操作方式通過標(biāo)準(zhǔn)正常交卷完整答完一張卷點擊交卷成績頁秒開數(shù)據(jù)庫成績記錄唯一弱網(wǎng)交卷開發(fā)者工具開啟弱網(wǎng)模擬再點交卷前端提示暫存本地網(wǎng)絡(luò)恢復(fù)后重試成功切后臺再交卷答到一半切后臺等 30 秒再回來立即交卷倒計時校準(zhǔn)后扣除后臺時長交卷正常重復(fù)提交交卷成功后返回頁面再次點交卷后端返回第一次成績不產(chǎn)生新記錄亂序判分開啟亂序后用已知答案的測試賬號作答得分與人工判卷完全一致驗證弱網(wǎng)時微信開發(fā)者工具的「模擬弱網(wǎng)」只是低配方案真機 4G 網(wǎng)絡(luò)信號弱的環(huán)境更容易暴露問題。我在封裝交卷模塊時習(xí)慣在日志里打印每一步的耗時如果從點擊交卷到看到成績頁超過 5 秒就說明判分或?qū)憥戽溌酚袃?yōu)化空間。并發(fā)聯(lián)動在考試小程序里不好用 curl 直接壓測更實際的做法是準(zhǔn)備三五個測試賬號在同一臺路由器下同時交卷看成績是否全部落庫。最后說一個我自己的教訓(xùn)最初我把判分邏輯完整地寫在云函數(shù)里真機演示時連續(xù)三次超時一度懷疑是網(wǎng)絡(luò)問題后來才發(fā)現(xiàn)是默認(rèn)超時只有 3 秒冷啟動再加幾十道題的判分循環(huán)根本跑不完。把判分挪回客戶端本地執(zhí)行、云函數(shù)只做校驗和存儲之后交卷體驗才真正穩(wěn)定下來。考試系統(tǒng)這類項目前端交互做得再花哨都不如「倒計時不漂移、交卷不丟數(shù)據(jù)、重復(fù)提交不出錯」這三個底線來得實在。希望你做完這套系統(tǒng)后能在演示現(xiàn)場從容地說一句「你們隨便考我先交卷」這比任何花哨的功能都更能打動評委希望幫到你。本文還有配套的精品資源點擊獲取