基于微信小程序的校园智能请假和销假系统设计与实现摘要校园请假管理存在流程繁杂、信息传递迟缓、纸质审批低效等主要问题。本文根据高校请假、销假业务的实际需要设计并实现了一个基于微信小程序的校园智能请假、销假系统。系统用Spring Boot搭建后端服务Vue框架做管理端前端交互UniApp做移动端小程序开发MySQL做数据持久化存储形成前后端分离的技术体系。系统包含学生、教师、管理员三种角色对请假申请、销假申请、补课补考、计划安排、通知发布等主要业务模块进行了覆盖。学生可以利用微信小程序完成请假申请的全过程并且可以对申请的状态进行跟踪教师端可以对申请进行在线审批和回复管理员端具有全局数据管理以及通知发布的功能。本文从需求分析入手依次完成系统架构设计、数据库建模、功能模块实现和系统测试最后交付一个可以运行的系统原型。经过研究发现此系统可以很好地取代传统的纸质请假流程提高了校园请假业务的数字化管理水平对于其他类似的高校信息化建设也有一定的借鉴意义。关键词 微信小程序Spring BootVueUniApp请假管理销假管理AbstractThe campus leave management field faces prominent challenges including cumbersome procedures, delayed information transmission, and low efficiency in paper-based approval workflows. This paper designs and implements an intelligent campus leave and cancellation system based on WeChat Mini Program, targeting the practical needs of leave and cancellation business in universities.The system employs Spring Boot for backend service construction, Vue framework for management-side frontend interaction, UniApp for mobile mini program development, and MySQL for data persistent storage, forming a complete front-end and back-end separated technical architecture. The system covers three types of roles: students, teachers, and administrators, implementing core business modules including leave applications, cancellation applications, make-up classes and examinations, schedule arrangements, and notification publishing.Starting from requirements analysis, this paper sequentially completes system architecture design, database modeling, functional module implementation, and system testing, ultimately delivering a runnable system prototype. Research demonstrates that the system effectively replaces traditional paper-based leave procedures and improves the digital management level of campus leave business.Key words: WeChat Mini Program; Spring Boot; Vue; UniApp; Leave Management; Cancellation Management目录摘要 IAbstract II1 绪论 11.1 研究背景与意义 11.1.1 背景 11.1.2 意义 11.2 国内外研究现状 11.2.1 国内研究现状 11.2.2 国外研究现状 22 相关技术介绍 42.1 Spring Boot框架 42.2 Vue前端框架 42.3 UniApp跨平台框架 42.4 MySQL数据库 53 系统需求分析 63.1 可行性分析 63.1.1 技术可行性 63.1.2 经济可行性 63.1.3 操作可行性 63.2 功能需求分析 63.2.1 学生角色功能需求 63.2.2 教师角色功能需求 73.2.3 管理员角色功能需求 84 系统设计 104.1 系统架构设计 104.2 功能结构设计 104.3 业务流程设计 114.4 数据库设计 184.4.1 概念模型设计 184.4.2 数据库逻辑设计 245 系统详细设计与实现 305.1 学生角色功能实现 305.1.1 请假申请 305.1.2 销假申请 315.1.3 补课补考 315.1.4 通知中心 325.1.5 计划安排列表 335.2 教师角色功能实现 345.2.1 请假申请管理 345.2.2 销假申请管理 355.2.3 补课补考管理 355.2.4 计划安排管理 365.3 管理员角色功能实现 375.3.1 请假申请管理 375.3.2 销假申请管理 385.3.3 补课补考管理 385.3.4 计划安排管理 395.3.5 通知发布 396 系统测试 416.1 测试目的 416.2 测试方法 416.3 测试用例 41总结 45参考文献 46致谢 481绪论1.1研究背景与意义1.1.1背景传统的校园请假方式同现代高校精细化管理的要求相脱离。长期以来高校请假流程依靠纸质表单逐级签字学生要从宿舍到学院办公室再到教务处来回跑手续繁杂耗时很长。审批信息不能及时同步到教师端教师一般要等到课后才知道学生的请假情况销假凭证的真实性核验也没有有效的办法。移动互联网技术迅速发展给重新构建该业务流程提供现实基础。由于智能手机的高渗透率以及微信平台的广大用户基数因此以小程序为基础来创建轻量级管理工具是可行的。已有研究表明以移动端为基础的校园智能配送系统可以明显提高校园内部的配送管理效率。在校园智能化建设的大环境下把请假、销假、补课补考这些分散业务归入到同一个数字化平台当中既是技术发展的必然趋势也是高校改善治理水平的一种实际需求。创建起包含申请、审批、销假全部流程的智能管理系统已经成为高校信息化建设当中急需解决的问题。1.1.2意义本系统建设对校园管理效率的提高有直接的价值。学生使用微信小程序提交请假申请教师在移动端进行实时审批该过程时间成本比传统的审批方式要小得多审批结果可以即时发送给申请人消除由于信息滞后造成的管理盲区。系统把请假记录、销假凭证、补课安排等数据全部存入到数据库中给学院了解学生出勤情况、改善教学安排给予数据支持。从用户体验角度来讲界面以微信生态为基础进行设计不需要额外安装应用操作路径符合学生日常使用习惯学习成本极低。从社会效益角度来说系统的数字化闭环管理可以减少人为操作失误降低审批流程的人力成本对于同类规模高校的请假管理信息化改造有示范和推广的意义推动高校治理向数据驱动的精细化方向发展。1.2国内外研究现状1.2.1国内研究现状国内高校信息化管理系统研究始于20世纪末经历了从单机桌面应用到B/S架构Web系统的发展近些年来由于移动互联网技术的成熟系统形态渐渐转向了小程序、混合App等轻量级的形态。请假管理属于高校教务系统的重要组成研究重心由原来的单个流程电子化转变为多角色协同、智能审批、数据统计等综合化的方向。张淋星等2025针对校园智能问答场景展开研究创建起以ChatGLM为基础的校园智能问答系统用大语言模型处理用户的提问并给出结构化的回答多角色交互的设计思路以及知识库动态更新的机制给本系统里教师审批和学生查询模块的交互逻辑设计给予了参照[1]。严清虎等2025年设计出校园智能巡检机器人系统用传感器融合和任务调度算法来完成对校园环境的自动巡检模块化的任务分发机制以及状态实时反馈的设计给本系统的申请状态追踪和审批流推进的架构设计提供了一些思路[2]。顾晨悦等2025年设计出基于无人快递车的校园智能配送系统主要是对任务调度、路径规划算法进行研究前后端分离的系统架构模式以及移动端轻量化的交互设计给本系统技术选型提供直接的参照[3]。1.2.2国外研究现状国外关于校园信息化和智能管理的研究开始得比较早研究取向也更加重视数据驱动以及用户自适应体验。从系统设计理念来看国外的研究者更加重视把机器学习、知识图谱等人工智能的方法运用到校园的管理当中去希望系统具有自我优化的能力就技术实现而言RESTful API的设计规范、微服务架构的拆分、跨平台的前端框架等成熟的工程实践被广泛应用形成了比较完整的理论体系。2026年Ongondza等人提出了一种基于认知安全和物联网的校园智能监控系统设计方案以可疑行为检测场景为研究对象构建了一个多传感器数据融合、实时告警的技术框架安全策略的设计以及用户权限分层管理模型给本系统的管理员权限控制机制设计提供了一些思路[4]。Lili等2025年提出了面向自适应个性化教育的智能学习系统的设计方法根据学习者的个人行为数据来动态地调整内容推送的方式其多角色权限和个性化的数据反馈机制给本系统的学生端计划安排列表个性化展示逻辑提供了一些思路[5]。2024年Feng利用知识可视化技术开发了以高校创新创业为对象的智能学习系统主要研究知识结构的图谱化展现和学习路径的推荐其系统模块解耦以及知识关联建模的方法对于本系统补课补考模块与计划安排模块之间的数据关联设计有着一定的借鉴价值[6]。综上所述国外对于校园智能管理系统的探索已经由原来的单一功能向多模态数据融合、智能决策支持转变。本系统以国内高校请假业务实际场景为基础以微信生态为载体对请假申请、销假核验、补课补考和计划安排全流程进行数字化闭环设计在功能完整性、业务契合度方面有很强的实用导向。1.3 研究内容本文的主要工作就是设计并实现一个基于微信小程序的校园智能请假、销假系统。本研究从业务需求出发从学生、教师、管理员三个用户角度出发对校园请假和销假场景进行调研整理出学生、教师、管理员三类用户的使用需求给出完整的系统需求规格说明书确定系统的功能范围以及非功能要求。在此基础上按照软件工程的方法论来完成系统的架构设计确定前后端分离的整体结构划分各个功能模块的职责范围建立数据库的概念模型和逻辑模型。编码实现阶段根据架构设计分层进行后端使用Spring Boot搭建RESTful服务接口前端管理端使用Vue框架创建交互界面移动端使用UniApp实现微信小程序跨平台适配MySQL对所有的业务数据进行持久化存储。功能实现包括请假申请提交与审批、销假申请关联核验、补课补考流程管理、计划安排制定与查看、管理员通知发布等模块。系统测试阶段对重要的业务路径设计测试用例检验功能逻辑是否正确模块间的数据交互是否一致。本文的研究重点是完整业务流程的工程化实现不会涉及到复杂的智能算法训练和部署。最终成果为可以部署运行的系统原型系统设计文档和测试报告也一并给出为以后的功能扩展打下基础。2相关技术介绍2.1Spring Boot框架Spring Boot是Pivotal团队为Spring Framework打造的一款快速开发框架它的主要思想就是“约定优于配置”依靠自动配置来大幅度减少项目启动时环境搭建的工作量。开发者不需要手工编写繁杂的XML配置文件框架会根据类路径中的依赖来自动完成Bean的装配和组件的注册整个项目可以在极短的时间内达到可以运行的状态[7]。本系统中Spring Boot全部后端业务逻辑的承载以及对外接口的提供。请假申请提交、审批状态变更、销假记录写入等全部操作都由Spring Boot搭建的RESTful API层来接受前端请求经过Service层的业务规则校验之后再存入到数据库中。Spring Boot内置的安全扩展点可以对不同的角色的接口访问做细致的控制很好地实现了学生端、教师端和管理员端数据操作权限的隔离。由于它内置了Tomcat容器所以系统部署时不需要额外配置外部的应用服务器从而简化了运维工作。完善的异常处理机制以及统一的响应封装保证各个业务模块在出现异常时可以有相同的行为从而提高整个系统的健壮性[8]。2.2Vue前端框架Vue.js 是一个渐进式的 JavaScript 框架以数据驱动视图更新为核心机制使用组件化开发模式把界面拆分成独立可复用的功能单元。响应式数据绑定系统可以使得数据状态发生改变的时候自动触发视图刷新开发者只需要关注数据变化的逻辑不需要手动操作DOM元素[9]。本系统管理端前端全部使用Vue框架来实现。教师端请假申请审批列表、管理员端通知发布表单、补课补考审核状态展示等都用Vue组件来封装各个组件之间使用Vuex状态管理机制共享重要的业务数据防止出现跨组件数据传递的混乱情况。Vue Router是负责管理多页面之间路由跳转的可以保证不同的角色登录之后可以正确地导航到对应的功能模块。使用axios和Spring Boot后端接口来实现异步通信管理端数据请求和界面渲染一起构成了一个前后端协作闭环[10]。2.3UniApp跨平台框架UniApp是DCloud推出的一种基于Vue语法的跨平台前端开发框架开发者编写一份代码就可以生成出微信小程序、H5、App等各个平台的版本。其底层用条件编译的方式处理各个平台不同的能力开发者可以在统一的代码库中为不同的平台编写不同的逻辑而不需要维护多个独立的项目[11]。本系统学生端移动应用采用UniApp开发然后编译成微信小程序。学生在微信客户端中可以直接进行请假申请表单填写、佐证材料图片上传、申请状态实时查看和销假申请提交等操作不需要安装其他的原生App。UniApp对微信小程序原生API进行封装后页面生命周期管理、本地缓存操作、网络请求调用等底层能力都可以用Vue风格的语法来实现从而降低了移动端的开发门槛。框架内置的uView UI组件库提供了丰富的表单、列表、弹窗等组件保证了学生端界面的一致性和交互规范性[12]。2.4MySQL数据库MySQL是一款开源的关系型数据库管理系统主要被用在互联网应用上以InnoDB存储引擎为主支持完整的ACID事务行级锁和外键约束。结构化查询语言标准兼容性好、丰富的索引种类给复杂业务查询性能优化提供足够的技术手段[13]。本系统的全部业务数据存放在MySQL数据库里。请假申请表、销假申请表、补课补考表、计划安排表、学生用户表、教师用户表等核心业务表之间用外键关联来保证数据的完整性审批状态字段采用枚举约束来保证状态流转的合法。事务机制可以保证审批过程中申请记录和审批回复一起保存到数据库中时是原子的不会因为网络突然断开而产生数据混乱。MySQL的慢查询日志以及EXPLAIN执行计划分析工具给后面系统性能优化提供了一条可行的诊断途径[14]。3系统需求分析3.1可行性分析3.1.1技术可行性本系统使用Spring Boot、Vue、UniApp、MySQL等主流开源技术构建而成各个部分都是目前较为成熟的开源框架社区活跃度高、文档齐全、版本稳定。Spring Boot与MySQL之间通过MyBatis-Plus完成持久层对接Vue与UniApp均基于Vue语法体系前后端通过RESTful接口协议交互技术栈之间的适配关系清晰不存在兼容性隐患。微信小程序生态逐渐成熟官方开发者工具及调试功能齐全技术环境可以支撑系统正常运行。3.1.2经济可行性本系统所用到的所有技术框架都是开源免费的产品不会产生商业授权费用。服务器可以部署到学校已经有的云主机或者本地服务器资源上不需要另外购置硬件设备。数据库运行在MySQL社区版上免费的。开发阶段的人力成本占比较大但是资源消耗在合理的范围内。系统上线之后的运行维护成本较低数据库备份、版本更新等可以由少数几名运维人员完成建设经济。3.1.3操作可行性系统学生端采用微信小程序开发用户不需要下载安装就可以直接使用符合目前大学生的日常使用习惯。管理端和教师端使用Web浏览器访问界面布局参照主流管理系统的设计规范菜单结构清楚操作路径简单。三种用户角色所对应的各个功能模块是彼此独立的它们之间不会互相干扰不同的文化程度和技术背景的用户在短时间内都可以完成基本的操作认知负担小。3.2功能需求分析3.2.1学生角色功能需求学生用户在系统中承担业务发起的核心角色。学生可在微信小程序端提交请假申请填写请假类型、请假时间、请假事由并上传相关材料申请审批通过后学生可发起对应的销假申请上传返校佐证。补课补考模块允许学生查看和提交补课补考申请并跟踪审批进度。通知中心负责汇聚管理员发布的各类通知消息学生可实时查阅。计划安排列表展示与该学生关联的补课、补考等日程安排信息供学生查看时间节点。如图3-1所示。图3-1 学生用例图3.2.2 教师角色功能需求教师用户在系统中承担审批与管理的职能。教师可查看名下学生提交的请假申请进行审核操作并填写审核回复意见销假申请模块允许教师对学生的销假记录进行确认与核验。补课补考管理模块支持教师对学生的补课补考申请进行审批并制定对应的计划安排。计划安排管理模块允许教师创建、修改、查看与该教师关联的学生学习计划形成完整的教学管理闭环。如图3-2所示。图3-2 教师用例图3.2.3管理员角色功能需求管理员用户具备系统全局数据管理权限。管理员可对全体学生的请假申请进行统一查看与干预处理销假申请管理模块支持对销假记录的全量审核。补课补考管理模块允许管理员对所有补课补考申请进行汇总管理计划安排管理模块支持全局计划数据的维护与调整。通知发布模块是管理员独有的功能支持创建通知内容、设置通知方式并向全体用户推送确保校园事务信息的有效触达。如图3-3所示。图3-3 管理员用例图4系统设计4.1系统架构设计本系统整体架构遵循前后端分离的设计原则依据各层职责划分为用户界面层、应用服务层、数据持久层三个主要层级并辅以系统支持层提供基础运行环境保障。用户界面层由两类客户端组成管理端与教师端采用Vue框架构建的Web界面学生端基于UniApp开发并编译为微信小程序两类客户端均通过HTTP协议与后端进行数据交互实现界面渲染与业务逻辑的完全解耦。应用服务层以Spring Boot为核心承载负责接收前端请求、执行业务规则校验、协调各功能模块的数据处理并返回标准化响应请假申请审批、销假记录核验、补课补考流程推进等核心业务均在此层完成。数据持久层由MySQL数据库承担存储学生用户、教师用户、请假申请、销假申请、补课补考、计划安排等全部业务数据MyBatis-Plus作为持久化框架在应用层与数据库之间完成对象关系映射。系统支持层提供本地化开发环境、JDK运行时与基础Web服务器支持保障各层组件稳定协作运行。系统架构图如图4-1所示。图4-1 系统架构图4.2功能结构设计本系统围绕校园请假与销假核心业务构建覆盖学生、教师、管理员三类用户角色各角色对应功能模块相互独立又存在业务关联。学生端提供请假申请、销假申请、补课补考、通知中心、计划安排列表五个功能模块支撑学生完成从请假发起到销假归校的完整业务链路。教师端具备请假申请管理、销假申请管理、补课补考管理、计划安排管理四个模块支持教师对学生申请的在线审批与日程安排维护。管理员端在教师端功能基础上增加通知发布模块实现对全局业务数据的统筹管理与校园通知的推送发布。各功能模块均与后端Spring Boot服务接口对接数据统一存储于MySQL数据库中。该系统功能结构如图4-2所示。图4-2 系统功能结构图4.3业务流程设计1请假申请功能流程设计学生发起请假申请填写请假类型、请假日期、请假事由上传佐证材料后提交。系统校验申请数据完整性若校验不通过则提示学生补充信息并返回填写界面校验通过后申请记录写入数据库并推送至对应教师审批队列。教师查看申请详情判断是否批准若批准则更新审核状态为通过若不批准则填写驳回原因并更新状态。学生在通知中心收到审批结果推送请假申请流程结束。请假申请流程图如图4-3所示。图4-3 请假申请流程图2销假申请功能流程设计学生返校后在小程序端发起销假申请系统关联对应请假申请记录要求学生上传返校佐证材料。系统验证销假申请次数是否超出限制若已达上限则提示无法提交并结束流程若未超限则记录销假信息并推送至教师端。教师核验返校情况确认真实有效后审批通过更新销假申请审核状态。学生收到销假审批结果通知请假与销假业务形成完整闭环。销假申请流程图如图4-4所示。图4-4 销假申请流程图3补课补考功能流程设计学生在补课补考模块填写申请标题与申请内容后提交补课补考申请。系统判断是否已存在关联的计划安排记录若存在则直接关联并更新计划安排限制次数若不存在则创建新的关联计划。申请进入教师审批环节教师查看申请内容后作出审批决定审批通过后系统自动生成对应的计划安排条目并推送提醒学生在计划安排列表中可查看最终安排详情。补课补考流程图如图4-5所示。图4-5 补课补考流程图4通知发布功能流程设计管理员在通知发布模块填写通知标题、通知内容并选择通知方式后提交发布请求。系统写入通知记录至数据库依据所选通知方式判断推送范围若为全体通知则遍历全量用户写入通知记录若为定向通知则按条件筛选目标用户群体。推送操作完成后通知状态更新为已发布。学生端通知中心刷新后展示最新通知条目管理员可在通知发布管理列表中查看已发布通知的状态记录。通知发布流程图如图4-6所示。图4-6 通知发布流程图5计划安排功能流程设计教师在计划安排管理模块创建计划安排填写申请标题、计划安排内容、通知提醒信息指定关联学生后保存。系统检验计划安排是否与已有补课补考申请存在关联若存在关联则同步更新补课补考模块中的计划状态若不存在则单独创建独立计划记录。学生端登录后在计划安排列表中可查看与本人关联的全部计划条目列表按时间顺序排列展示。学生可对已查阅的计划进行确认操作系统记录确认状态并更新计划安排的额外信息字段。计划安排流程图如图4-7所示。图4-7 计划安排流程图4.4数据库设计4.4.1概念模型设计数据库概念模型的构建是将现实业务场景抽象为信息世界结构表达的第一步。本系统涉及学生请假、教师审批、销假核验、补课补考、计划安排等多条业务线各业务线之间存在复杂的数据依赖关系单纯依赖经验进行表结构设计极易造成数据冗余与关联逻辑混乱。通过识别系统中的核心实体、定义各实体的属性集合再依据业务规则建立实体之间的联系能够将这些隐性的业务约束转化为显式的数据模型结构。联系类型涵盖一对一、一对多、多对多三种基本形式学生与请假申请之间构成一对多关系教师与审批记录之间同样呈一对多关系补课补考申请与计划安排之间存在多对多的关联可能。E-R图作为概念模型的标准可视化工具能够以图形化方式清晰呈现实体、属性与联系的全貌便于开发团队在设计阶段对业务数据结构达成共识。在数据库技术的支撑下概念模型的完整性直接决定了后续逻辑模型转换的准确性为物理表结构设计提供了不可替代的理论依据。基于以上分析将绘制反映本系统全域数据结构的E-R图为后续逻辑模型设计提供依据。全局E-R模型如图4-8所示。图4-8 全局ER图根据系统分析系统的主要实体有学生用户、教师用户、请假申请、销假申请、补课补考、计划安排、通知发布、班级信息、学院信息、用户账户各个实体具体的属性如下图所示。1学生用户实体主要包括学生用户ID、学生姓名、学生性别、班级名称、学院名称、审核状态等属性。如图4-9所示。图4-9 学生用户实体属性图2教师用户实体主要包括教师用户ID、教师姓名、教师性别、审核状态、用户ID等属性。如图4-10所示。图4-10 教师用户实体属性图3请假申请实体主要包括请假申请ID、学生姓名、请假类型、请假日期、请假天数、审核状态等属性。如图4-11所示。图4-11 请假申请实体属性图4销假申请实体主要包括销假申请ID、学生姓名、请假类型、返校情况、审核状态、审核回复等属性。如图4-12所示。图4-12 销假申请实体属性图5补课补考实体主要包括补课补考ID、申请标题、申请内容、学生姓名、班级名称、审核状态等属性。如图4-13所示。图4-13 补课补考实体属性图6计划安排实体主要包括计划安排ID、申请标题、计划安排、通知提醒、学生姓名、审批教师等属性。如图4-14所示。图4-14 计划安排实体属性图7通知发布实体主要包括通知ID、通知标题、通知内容、通知方式、创建时间等属性。如图4-15所示。图4-15 通知发布实体属性图8班级信息实体主要包括班级信息ID、班级名称、创建用户ID、创建时间等属性。如图4-16所示。图4-16 班级信息实体属性图9学院信息实体主要包括学院信息ID、学院名称、创建用户ID、创建时间等属性。如图4-17所示。图4-17 学院信息实体属性图10用户账户实体主要包括用户ID、用户名、密码、昵称、手机号码、账户状态等属性。如图4-18所示。图4-18 用户账户实体属性图4.4.2数据库逻辑设计数据库逻辑设计是在概念模型基础上将实体与联系转换为关系型数据库可直接描述的表结构与约束规则的过程。本系统依据全局E-R图中识别的十个核心实体逐一映射为对应的数据库关系表实体属性转化为字段定义实体之间的联系通过外键字段加以体现。每张表均设置整型自增主键作为唯一标识确保记录的可追溯性。请假申请表通过学生用户字段与学生用户表建立关联销假申请表通过来源ID字段与请假申请表形成业务追溯链路补课补考表与计划安排表之间通过计划安排限制次数字段控制关联记录的数量上限。审核状态字段在请假申请、销假申请、补课补考、学生用户、教师用户等多张表中统一采用varchar类型存储枚举值保持字段语义的一致性。创建时间、更新时间字段在各业务表中统一设置为数据变更审计提供时间依据整体表结构设计满足第三范式要求有效控制数据冗余。1学生用户表主要是用来存储学生用户的基本信息。主要包括学生用户ID、学生姓名、学生性别、班级名称等字段。如表4-1所示。表4-1 学生用户表序号 字段名 类型 长度 备注1 student_user_id int 11 主键2 student_name varchar 64 学生姓名3 student_gender varchar 2 学生性别4 class_name_name varchar 64 班级名称5 college_name varchar 64 学院名称6 examine_state varchar 16 审核状态7 user_id int 11 用户ID8 create_time datetime - 创建时间9 update_time timestamp - 更新时间2教师用户表主要是用来存储教师用户的基本信息。主要包括教师用户ID、教师姓名、教师性别、审核状态等字段。如表4-2所示。表4-2 教师用户表序号 字段名 类型 长度 备注1 teacher_user_id int 11 主键2 teachers_name varchar 64 教师姓名3 gender_of_teachers varchar 2 教师性别4 examine_state varchar 16 审核状态5 user_id int 11 用户ID6 create_by int 11 创建用户ID7 create_time datetime - 创建时间8 update_time timestamp - 更新时间3请假申请表主要是用来记录学生提交的请假申请信息。主要包括请假申请ID、学生姓名、请假类型、审核状态等字段。如表4-3所示。表4-3 请假申请表序号 字段名 类型 长度 备注1 leave_request_id int 11 主键2 student_name varchar 64 学生姓名3 student_user int 11 学生用户4 approve_teachers int 11 审批教师5 leave_type varchar 64 请假类型6 leave_date date - 请假日期7 number_of_days_off double - 请假天数8 reason_for_leave varchar 255 请假事由9 examine_state varchar 16 审核状态10 examine_reply varchar 255 审核回复11 upload_materials varchar 255 上传材料12 create_time datetime - 创建时间4销假申请表主要是用来记录学生提交的销假申请信息。主要包括销假申请ID、学生姓名、返校情况、审核状态等字段。如表4-4所示。表4-4 销假申请表序号 字段名 类型 长度 备注1 leave_cancellation_request_id int 11 主键2 student_name varchar 64 学生姓名3 student_user int 11 学生用户4 approve_teachers int 11 审批教师5 leave_type varchar 64 请假类型6 leave_date date - 请假日期7 number_of_days_off double - 请假天数8 return_to_school_status varchar 255 返校情况9 examine_state varchar 16 审核状态10 examine_reply varchar 255 审核回复11 source_id int 11 来源ID12 create_time datetime - 创建时间5补课补考表主要是用来存储学生提交的补课补考申请记录。主要包括补课补考ID、申请标题、申请内容、审核状态等字段。如表4-5所示。表4-5 补课补考表序号 字段名 类型 长度 备注1 make_up_class_name_make_up_exam_id int 11 主键2 application_title varchar 64 申请标题3 application_content varchar 255 申请内容4 student_name varchar 64 学生姓名5 student_user int 11 学生用户6 approve_teachers int 11 审批教师7 class_name_name varchar 64 班级名称8 examine_state varchar 16 审核状态9 examine_reply varchar 255 审核回复10 plan_arrangement_limit_times int 11 计划安排限制次数11 create_time datetime - 创建时间12 update_time timestamp - 更新时间6计划安排表主要是用来记录教师为学生制定的学习计划安排。主要包括计划安排ID、申请标题、计划安排内容、通知提醒等字段。如表4-6所示。表4-6 计划安排表序号 字段名 类型 长度 备注1 plan_arrangement_id int 11 主键2 application_title varchar 64 申请标题3 plan_arrangement varchar 255 计划安排4 notification_reminder varchar 255 通知提醒5 student_name varchar 64 学生姓名6 student_user int 11 学生用户7 approve_teachers int 11 审批教师8 source_id int 11 来源ID9 create_by int 11 创建用户ID10 create_time datetime - 创建时间11 update_time timestamp - 更新时间7通知发布表主要是用来存储管理员发布的系统通知信息。主要包括通知ID、通知标题、通知内容、通知方式等字段。如表4-7所示。表4-7 通知发布表序号 字段名 类型 长度 备注1 releasing_notices_id int 11 主键2 title varchar 255 通知标题3 content varchar 255 通知内容4 type varchar 64 通知方式5 create_time timestamp - 创建时间6 update_time timestamp - 更新时间8班级信息表主要是用来维护校园班级基础数据。主要包括班级信息ID、班级名称、创建用户ID、创建时间等字段。如表4-8所示。表4-8 班级信息表序号 字段名 类型 长度 备注1 class_name_information_id int 11 主键2 class_name_name varchar 64 班级名称3 create_by int 11 创建用户ID4 create_time datetime - 创建时间5 update_time timestamp - 更新时间9学院信息表主要是用来维护学院基础信息数据。主要包括学院信息ID、学院名称、创建用户ID、创建时间等字段。如表4-9所示。表4-9 学院信息表序号 字段名 类型 长度 备注1 college_information_id int 11 主键2 college_name varchar 64 学院名称3 create_by int 11 创建用户ID4 create_time datetime - 创建时间5 update_time timestamp - 更新时间10用户账户表主要是用来存储系统全体用户的登录账户信息。主要包括用户ID、用户名、密码、手机号码、账户状态等字段。如表4-10所示。表4-10 用户账户表序号 字段名 类型 长度 备注1 user_id int 11 主键2 username varchar 30 用户名3 password varchar 64 密码4 nickname varchar 50 昵称5 phone varchar 20 手机号码6 email varchar 64 邮箱7 avatar varchar 255 头像地址8 state smallint 10 账户状态9 user_group varchar 32 所在用户组10 create_time timestamp - 创建时间5系统详细设计与实现5.1学生角色功能实现5.1.1请假申请请假申请功能主要是对学生发起的请假业务进行全流程处理。学生进入请假申请页面后选择请假类型填写请假日期与请假天数录入请假事由完成材料图片上传后提交申请。系统接收到提交请求后对必填项进行完整性校验校验未通过时在对应表单项下方给出提示信息并阻止提交。校验通过后申请记录写入数据库页面跳转至申请列表申请状态显示为待审核。学生可在申请列表中点击具体记录查看申请详情包含当前审核状态与教师的审核回复内容状态变更后列表自动刷新展示最新结果。请假申请界面如图5-1所示。图5-1 请假申请界面5.1.2销假申请销假申请功能主要是对学生返校后的销假凭证提交进行管理。学生在返校后进入销假申请模块系统自动关联该学生已通过审批的请假申请记录展示可发起销假的申请列表。学生选择对应的请假记录后进入销假申请填写页上传返校佐证图片填写返校情况说明后提交。系统校验销假申请次数是否超出限制超出则拒绝提交并给出提示。未超出限制时销假申请记录写入数据库推送至教师端待处理队列。申请提交成功后学生在销假申请列表中可查看审核进度与教师回复。销假申请界面如图5-2所示。图5-2 销假申请界面5.1.3补课补考补课补考功能主要是对学生发起的补课补考申请进行提交与状态查看。学生进入补课补考模块点击新建申请按钮填写申请标题与申请内容确认关联的班级与学院信息选择审批教师后提交。系统将申请记录存入数据库并推送至对应教师的审批队列。学生在补课补考列表中可查看申请的当前审核状态状态分为待审核、已通过、已驳回三类。教师审批通过后系统自动生成关联的计划安排记录学生在计划安排列表中可同步查看补课或补考的时间安排与通知提醒信息。补课补考界面如图5-3所示。图5-3 补课补考界面5.1.4通知中心通知中心功能主要是对管理员发布的各类系统通知进行汇聚展示。学生进入通知中心后页面以列表形式展示全部通知条目每条通知显示标题、通知方式与发布时间。学生点击具体通知条目后进入通知详情页展示完整的通知内容。通知列表按发布时间倒序排列新通知显示在列表顶部。列表支持下拉刷新操作学生执行下拉动作后系统重新请求后端接口获取最新通知数据更新列表展示内容确保学生能够及时获取校园最新公告与事务通知。通知中心界面如图5-4所示。图5-4 通知中心界面5.1.5计划安排列表计划安排列表功能主要是对与当前学生关联的全部计划安排记录进行展示。学生进入计划安排列表页系统依据学生用户ID查询数据库中归属该学生的全部计划安排记录按创建时间排列展示申请标题、计划内容摘要与通知提醒信息。学生点击具体计划条目后进入详情页展示完整的计划安排内容、通知提醒详情及关联的补课补考申请信息。详情页提供确认操作按钮学生确认后系统更新该计划安排记录的额外信息字段记录确认状态。教师在计划安排管理端新增或修改计划后学生端列表刷新时自动同步最新数据。计划安排列表界面如图5-5所示。图5-5 计划安排列表界面5.2教师角色功能实现5.2.1请假申请管理请假申请管理功能主要是对学生提交的请假申请进行审批处理。教师登录系统后进入请假申请管理列表页面展示所有指定该教师为审批人的请假申请列表字段包含学生姓名、请假类型、请假日期、请假天数及当前审核状态。教师点击具体申请记录后进入审批详情页可查看学生上传的请假材料图片填写审核回复意见选择审批通过或驳回后提交。提交完成后系统更新对应申请记录的审核状态字段已处理的申请在列表中状态自动变更。列表支持按审核状态筛选方便教师快速定位待处理记录。请假申请管理界面如图5-6所示。图5-6 请假申请管理界面5.2.2销假申请管理销假申请管理功能主要是对学生提交的销假申请进行核验审批。教师在销假申请管理列表中查看归属本人审批的销假申请记录列表展示学生姓名、关联请假类型、请假日期、返校情况摘要及审核状态。点击具体记录进入审批详情页教师可查看学生上传的返校佐证材料核对返校情况说明是否属实填写审核回复后提交审批决定。审批通过后系统更新销假申请记录的审核状态请假与销假形成完整的业务关联链路。教师可通过列表筛选功能区分待处理与已处理的销假申请记录。销假申请管理界面如图5-7所示。图5-7 销假申请管理界面5.2.3补课补考管理补课补考管理功能主要是对学生提交的补课补考申请进行审核与跟进。教师在补课补考管理列表中查看分配至本人的申请记录列表展示申请标题、学生姓名、班级名称及审核状态。点击具体申请记录后进入详情页教师查阅申请内容后填写审核回复选择审批通过或驳回并提交。审批通过后系统检查该申请是否已关联计划安排若未关联则自动创建计划安排条目。教师在审批完成后可跳转至计划安排管理模块为该学生制定具体的补课或补考时间安排完成从申请审批到计划落实的完整业务流程。补课补考管理界面如图5-8所示。图5-8 补课补考管理界面5.2.4计划安排管理计划安排管理功能主要是对与本教师关联的学生学习计划进行创建与维护。教师在计划安排管理列表中查看已创建的全部计划安排记录列表展示申请标题、学生姓名、计划内容摘要与通知提醒信息。点击新建按钮后进入创建页教师填写申请标题、计划安排详细内容、通知提醒文字指定关联学生后保存提交。系统将计划安排记录写入数据库关联学生的计划安排列表自动同步展示新记录。教师可对已创建的计划安排进行编辑修改或删除操作修改后学生端列表实时更新额外信息字段支持补充说明性备注。计划安排管理界面如图5-9所示。图5-9 计划安排管理界面5.3管理员角色功能实现5.3.1请假申请管理请假申请管理功能主要是对全体学生的请假申请进行全局查看与管理。管理员在请假申请管理列表中可查看系统内所有学生的请假申请记录不受教师账号归属限制列表展示学生姓名、学院名称、班级名称、请假类型、审核状态等信息。管理员可对任意申请记录进行详情查看必要时可干预修改审核状态。列表支持按审核状态、班级、学院等维度进行筛选管理员通过搜索功能快速定位特定学生的请假记录。全局数据视角使管理员能够掌握各班级请假情况的整体分布为教务统计提供数据支撑。请假申请管理界面如图5-10所示。图5-10 请假申请管理界面5.3.2销假申请管理销假申请管理功能主要是对全体学生销假申请记录进行统一管理。管理员在销假申请管理列表中查看系统内所有销假申请每条记录展示学生姓名、关联请假类型、请假日期、返校情况及当前审核状态。管理员可对具体记录进行详情查看与状态干预操作在教师审批出现异常时可介入调整审核结论。列表提供按学院、班级、审核状态的多维筛选功能支持按提交时间范围进行数据过滤。管理员通过该模块掌握各学生销假到位情况配合请假申请管理模块实现对学生出勤数据的完整追踪。销假申请管理界面如图5-11所示。图5-11 销假申请管理界面5.3.3补课补考管理补课补考管理功能主要是对全系统补课补考申请进行汇总管理。管理员在补课补考管理列表中查看所有学生提交的补课补考申请列表字段包含申请标题、学生姓名、班级名称、学院名称、审批教师及审核状态。管理员可对具体申请进行详情查看与审核状态调整在审批流异常时介入处理。列表支持按审核状态与班级信息进行筛选管理员通过搜索输入学生姓名快速定位相关申请记录。数据统计视角使管理员能够了解各班级补课补考申请的频次分布为教学管理决策提供参考依据。补课补考管理界面如图5-12所示。图5-12 补课补考管理界面5.3.4计划安排管理计划安排管理功能主要是对全局计划安排数据进行统筹维护。管理员在计划安排管理列表中查看系统内全体学生的计划安排记录不区分教师归属展示申请标题、学生姓名、计划内容摘要、通知提醒及审批教师信息。管理员可对具体计划安排记录进行详情查看、编辑修改与删除操作确保计划数据的准确性。列表支持按学生姓名、班级、审批教师进行筛选管理员通过该模块掌握学生补课补考计划的执行情况对未落实的计划安排进行督促与调整保障教学补救措施的有效推进。计划安排管理界面如图5-13所示。图5-13 计划安排管理界面5.3.5通知发布通知发布功能主要是对校园事务通知的创建、发布与管理进行操作。管理员进入通知发布模块后点击新建通知按钮在发布表单中填写通知标题、通知内容选择通知方式后提交发布。系统将通知记录写入数据库并依据通知方式向目标用户群体推送消息学生端通知中心同步展示新通知条目。管理员在通知发布列表中可查看已发布通知的标题、通知方式与发布时间对存在错误的通知进行编辑修改或删除操作。列表按发布时间倒序排列支持按通知方式筛选方便管理员追踪特定类型通知的发布记录。通知发布界面如图5-14所示。图5-14 通知发布界面6系统测试6.1测试目的软件测试是保障系统交付质量的关键环节。本系统的测试目标聚焦于业务逻辑与设计规格的拟合度验证重点检验请假申请审批流、销假申请关联核验、补课补考状态流转等核心业务链路在不同输入条件下的处理结果是否与需求规格一致。在全链路数据一致性层面测试需验证跨模块数据写入的原子性确保申请状态变更、审批回复写入、计划安排创建等操作在边界条件下不出现数据割裂。通过系统性的功能验证与边界容错测试识别并修正实现过程中存在的逻辑偏差为系统上线提供质量保障依据[15]。6.2测试方法本次测试主要采用黑盒测试方法依据功能需求规格说明设计测试用例从用户操作视角出发验证各功能模块的输入输出行为是否符合预期不关注底层代码实现细节。测试用例覆盖正常业务流程、边界值输入与异常数据输入三类场景针对请假申请、销假申请、补课补考、计划安排、通知发布等核心业务模块逐一执行。测试过程中对发现的功能缺陷进行记录与复现定位问题后反馈至开发阶段修复修复完成后执行回归测试验证修复效果确保修复操作未引入新的异常行为形成完整的缺陷闭环管理。6.3测试用例本小节选取系统中七个核心业务模块设计测试用例对各模块的主要业务逻辑、边界处理能力与异常响应行为进行验证全面评估系统功能的正确性与稳定性。请假申请模块的测试目标在于验证学生提交请假申请的全流程处理是否符合业务规则重点关注必填项校验、申请状态初始化及审批流推进的正确性。如表6-1所示。表6-1 请假申请测试用例表测试内容 测试步骤 预期结果 实际结果正常提交请假申请 填写完整请假信息并上传材料后提交 申请记录写入成功状态显示待审核 符合预期必填项缺失提交 未填写请假事由直接提交 页面给出提示信息阻止提交 符合预期查看申请详情 在申请列表点击具体申请记录 展示完整申请信息与当前审核状态 符合预期销假申请模块的测试重点在于验证销假申请与请假申请的关联逻辑以及销假次数限制规则的执行准确性。如表6-2所示。表6-2 销假申请测试用例表测试内容 测试步骤 预期结果 实际结果正常提交销假申请 选择已通过的请假记录上传佐证并提交 销假记录写入成功推送至教师端 符合预期超出销假次数限制 对同一请假记录多次发起销假申请 系统拒绝提交并提示次数超限 符合预期查看销假审核结果 审批完成后在销假列表查看状态 审核状态与教师回复正确展示 符合预期补课补考模块的测试目标在于验证申请提交与计划安排自动关联逻辑的正确性重点检验审批通过后计划安排记录的自动生成行为。如表6-3所示。表6-3 补课补考测试用例表测试内容 测试步骤 预期结果 实际结果正常提交补课补考申请 填写申请标题与内容后提交 申请记录创建成功状态为待审核 符合预期审批通过后计划自动生成 教师审批通过后检查计划安排列表 自动生成关联计划安排条目 符合预期驳回后申请状态更新 教师填写驳回原因并提交 申请状态变更为已驳回回复内容展示 符合预期计划安排模块的测试重点在于验证教师创建计划后学生端的同步展示准确性以及计划编辑后数据更新的一致性。如表6-4所示。表6-4 计划安排测试用例表测试内容 测试步骤 预期结果 实际结果教师创建计划安排 填写完整计划信息并指定学生后保存 计划记录写入成功学生端列表同步展示 符合预期编辑已有计划安排 修改计划内容并保存 学生端对应记录同步更新至最新内容 符合预期学生确认计划 学生在详情页点击确认按钮 确认状态记录写入额外信息字段更新 符合预期通知发布模块的测试目标在于验证通知创建、发布与学生端展示的完整业务链路重点检验通知方式选择对推送范围的影响。如表6-5所示。表6-5 通知发布测试用例表测试内容 测试步骤 预期结果 实际结果正常发布通知 填写标题与内容选择通知方式后提交 通知记录写入学生端通知中心展示 符合预期编辑已发布通知 修改通知内容并保存 学生端展示更新后的通知内容 符合预期用户账户模块的测试重点在于验证不同角色账户的登录权限隔离确保各角色只能访问权限范围内的功能模块。如表6-6所示。表6-6 用户账户测试用例表测试内容 测试步骤 预期结果 实际结果学生账户登录 使用学生账户登录系统 进入学生端功能界面无管理端权限 符合预期错误密码登录 输入错误密码尝试登录 系统拒绝登录并给出提示 符合预期教师账户权限验证 教师账户访问管理员专属功能 系统拒绝访问并提示权限不足 符合预期教师审批流程模块的测试目标在于验证教师对请假申请的审批操作是否准确触发状态变更与数据更新重点关注审批通过与驳回两条路径的数据处理正确性。如表6-7所示。表6-7 教师审批流程测试用例表测试内容 测试步骤 预期结果 实际结果审批通过请假申请 教师查看申请详情填写回复后选择通过 申请状态更新为已通过学生端同步变更 符合预期驳回请假申请 教师填写驳回原因后选择驳回 申请状态更新为已驳回回复内容推送 符合预期查看待处理申请列表 教师登录后进入请假申请管理模块 仅展示指定该教师审批的待处理申请 符合预期总结校园请假管理数字化转型成了高校信息化建设的一部分。本系统以解决传统纸质请假过程中信息滞后、审批复杂、管理分散等为问题为基础对校园智能请假与销假系统进行设计和开发完成请假申请到销假归校全过程闭环满足了预期的设计要求。本次的研究内容分为需求调研、系统设计、编码实现、测试验证这四个部分完成了整个开发过程。需求分析阶段确定了学生、教师、管理员这三个角色的功能边界系统设计阶段完成架构规划、数据库概念模型和逻辑模型的建立编码实现阶段利用Spring Boot、Vue、UniApp、MySQL技术体系实现了请假申请、销假申请、补课补考、计划安排、通知发布等全部核心功能模块测试阶段用黑盒测试的方法对关键业务路径进行验证各个模块的功能运行正常数据交互一致。前后端分离架构使得系统的维护更容易UniApp支持移动端以及移动端的跨平台应用从而可以降低移动端开发的成本。目前系统已经可以满足大部分的业务需求但是还存在着一些细节上的不足。通知推送目前依靠用户主动刷新缺少真正的实时消息机制请假数据的统计分析功能比较简单没有提供可视化的报表销假凭证的真实性核验全部依靠教师人工判断缺少辅助校验手段。就以上不足而言之后可以采用微信订阅消息的方式进行真正的消息实时推送完善数据统计模块来支持出勤率的可视化分析探索将图像识别技术应用于销假佐证材料的辅助核验中从而提高系统的智能化程度。伴随着高校信息化管理需求的不断加深本系统有进一步推广到同规模院校的可能性。参考文献[1] 张淋星, 黄毅琛, 项凌涵, 等. 基于ChatGLM的校园智能问答系统设计与实现[J]. 现代信息科技, 2025, 9(14): 66-71.[2] 严清虎, 刘海龙, 汪雪涛, 等. 校园智能巡检机器人系统设计[J]. 湖北汽车工业学院学报, 2025, 39(02): 61-67.[3] 顾晨悦, 冯紫茹, 张昱. 基于无人快递车的校园智能配送系统设计与实现[J]. 科技视界, 2025, 15(26): 30-32.[4] Ongondza C, Eyangolo A V, Kafunda P K. Design of an Intelligent Campus Surveillance System, Based on Cognitive Security and the Internet of Things, for the Detection of Suspicious Activities[J]. Open Journal of Applied Sciences, 2026, 16(03): 832-853.[5] Lili H, Yanjun W. Designing Intelligent Learning Systems for Adaptive and Personalized Education in Universities[J]. International Journal of High Speed Electronics and Systems, 2025, (prepublish): 1-18.[6] Feng B. Design and Development of Intelligent Learning System for University Innovation and Entrepreneurship Based on Knowledge Visualisation[J]. Journal of Information Knowledge Management, 2024, 23(03): 1-24.[7]王志亮,纪松波.基于SpringBoot的Web前端与数据库的接口设计[J].工业控制计算机,2023,36(03):51-53.[8]熊永平.基于SpringBoot框架应用开发技术的分析与研究[J].电脑知识与技术,2021,15(36):76-77.[9]赵媛.基于Vue的Web系统前端性能优化分析[J].电脑编程技巧与维护,2024,(09):44-46.[10]秦冬.浅析Vue框架在前端开发中的应用[J].信息与电脑(理论版),2024,36(13):61-63.[11] 吴迁. 基于uni-app与Spring Boot框架的Web应用开发平台的设计与实现[D]. 西安: 西安石油大学, 2025: 1-120.[12] 张玮, 廖若飞. 基于uni-App的小程序开发技术路线及系统研究[J]. 无线互联科技, 2024, 21(22): 41-44.[13]李艳杰.MySQL数据库下存储过程的综合运用研究[J].现代信息科技,2023,7(11):80-8288.[14]周晓玉,崔文超.基于Web技术的数据库应用系统设计[J].信息与电脑(理论版),2023,35(09):189-191.[15]李俊萌.计算机软件测试技术与开发应用策略分析[J].信息记录材料,2023,24(03):50-52.致谢这篇论文的完成背后牵涉到的人和事远远不止文字所表现出来的那么少。写作过程最煎熬的是不能打开代码、反复推翻自己已经有的设计方案。每次重新整理需求、重新修改数据库结构都是在检验自己对系统有否真正了解。导师的意见一直克制而准确从不替我做出决定只是在某个节点上轻声地指明方向的错误之处然后让作者自己走回来。该种方式曾经让人抓狂但是从长远来看却是行之有效的培养方式。家人这段时间内对我的支持是无声的。他们不问进度不催交报告只在晚上我回家的时候做好饭在我深夜还在开灯的时候来打扰。默契要经过很长时间才会被感觉到这段文字中才意识到那份安静有多重。同学之间相互的帮助是另一种形式的支撑。当接口联调卡住了的时候和同学坐下来一起商量半个多小时要比自己对着电脑干上两个小时更有成效。彼此间的打气方式很随意有时只是一句“你这个思路其实没有问题”就能使别人继续下去。能力有边界本次研究的范围和深度受到限制系统还有很多需要改进的地方。但是能够在有限的条件下完成一个可以运行的完整系统本身就是一件值得认真对待的事情。请关注点赞私信博主免费领取项目源码
