springboot高校毕业生档案管理系统97116-计算机课程设计、毕业设计

第一章 绪论

1.1 研究背景与意义

　　高校毕业生数量不断上升给传统的档案管理方式造成了巨大的压力。每年各个高校要对毕业生档案进行整理、转递、核验等几十万份，纸质档案传递慢、信息滞后、查询统计难等现象一直存在。档案转递环节依靠人工登记和邮寄跟踪，档案信息核实要经过多部门的反复沟通，这样的作业方式不能满足信息化时代对数据实时性、准确性的要求。档案管理业务对于数字化处理能力的要求越来越高，建立统一的档案管理平台成了解决问题的唯一途径[1]。很多高校开始尝试用信息技术改造传统的档案业务流程，采用系统化的办法来达到档案信息集中存储、快速检索的目的[2]。钉钉在学生宿舍考勤系统中取得的成功说明，以移动端为基础的管理系统可以大大提高信息处理的速度，该思路同样适用于档案管理[3]。

　　系统实施之后，档案业务处理方式将会发生根本性的改变。档案申请、审核、核验全流程在线完成，档案信息产生时就进入数字化流转通道。管理人员不用再一遍遍地核对纸质材料，档案转递情况可以随时查看，数据错误率大大降低。系统自动完成重复性的工作任务，人力资源被释放到更有价值的工作中去。从行业角度来讲，该系统推广有利于形成统一的档案管理规范，提高高校档案工作整体信息化水平。档案数据经过系统沉淀之后，可以给就业趋势分析、人才培养质量评价赋予决策支撑。该模式的成功运用可以给其他种类的档案管理系统搭建提供参照，助力档案管理朝着标准化、智能化的方向发展。

1.2 国内外研究现状

　　国内档案管理系统研究是从单机版发展到网络版的过程。早期的研究主要是对档案信息的数字化存储进行研究，以解决纸质档案易损毁、难检索的问题。伴随着互联网技术的发展，研究方向也由原来的基于本地的档案管理系统向基于Web的档案管理系统转变，重视信息的远程访问和共享能力。目前的研究热点主要集中在业务流程再造和智能化处理方面，研究怎样用技术手段来改善档案流转各个环节。研究者普遍认为档案管理不只是数据存储的问题，更是多角色协同的业务流程问题。

　　闫杨洋于2026年提出了基于电子信息技术的档案智能管理系统，该系统利用射频识别技术实现了档案实物的自动盘点和定位，给档案物理载体和数字信息之间的关联提供了一种思路[4]。该种方法给系统设计带来启示，档案信息同实体档案之间的对应关系应当在数据模型里表现出来。李淑娴对高校会展档案的数字化管理进行研究，创建起涵盖档案收集、整理、利用全过程的业务平台，认为档案管理系统要同具体的业务场景深度融合起来[5]。由此可以看出，在设计档案核验功能的时候，必须考虑到毕业生的就业、升学等实际去向。廖亚风等利用钉钉创建学生宿舍考勤系统，证明了移动端和后台服务可以协同工作[6]。该系统所用到的前后端分离架构以及轻量化的业务流程设计，给档案业务管理模块的用户体验改善给予了参照。梁明对事业单位档案管理与业务系统一体化的设计进行了研究，认为档案数据应该成为业务系统的一部分而不是孤立存在的[7]。该观点支持本系统把档案业务同用户管理、学院分类这些基本的数据模块打通起来所作出的架构决定。倪斌在高校实验室信息管理系统的设计中使用了角色权限分层的方法，不同的身份用户登录后所看到的操作界面和功能范围也各不相同[8]。该种权限控制模式直接应用到本系统多角色管理体系的建立上。

　　从以上研究可以看出，国内档案管理系统正在向业务融合、智能辅助、权限精细这三个方面不断前进。现有的成果大多集中于某个业务环节的改进上，缺少对档案整个生命周期进行考虑，并且还要包含多角色协同的全部方案。本系统设计上把档案业务申请、审核、核验、转递各个阶段融合起来，把学生、院系、档案管理部门归入同一个工作流之中，这是对已有研究业务完整性的补充。

　　国外档案管理系统研究更加强调数据驱动和智能化。王C在2026年提出的基于云服务的无人实验室设备管理系统，使用物联网技术对设备状态进行实时监测和自动记录[9]。其主要思想就是把物理实体状态的变化自动同步到数字平台上，该机制对于档案转递过程中状态跟踪功能有借鉴意义。Tang H等设计出的基于B/S模式的高校化学管理平台，主要解决了多源异构数据的整合问题。平台使用统一的数据接口与不同的业务系统相接，从而保证信息一致。这样的数据整合思路可以用来处理档案信息和学籍系统、就业系统之间的数据交换[10]。林玉认为数据中心技术可以支持数字大学档案管理系统的建设，把档案数据当作学校的公共资源来加以全生命周期的管理[11]。研究认为元数据标准对于档案管理来说具有基础性的作用，在本系统数据库设计阶段对命名进行规范化提供理论支持。张文、潘川将机器学习模型应用到高校社团管理系统智能化优化中，通过对用户行为数据进行分析来预测功能使用趋势[12]。虽然档案管理对于预测性需求的预测能力较弱，但是它所提出的以用户反馈为依据不断改进系统功能的迭代思想可以借鉴。GalandeH A M在菲律宾Apayao州立学院创建的认证文档管理系统，主要研究多版本文档的追踪和审批过程的控制[13]。该系统文档版本管理机制同档案核验功能中审核记录追踪要求一致。

　　国外有关数据标准化、流程自动化、系统集成度等各方面比较成熟。相比于国内的研究来说，国外的研究更加重视系统之间数据交换的规范以及跨平台协同的能力。本系统在设计档案核验模块的时候借鉴了国外有关审核流程完整记录的研究成果，又考虑到国内高校档案管理实际业务流程，创建起适合我国国情的审核状态追踪体系。

1.3 研究内容

　　本文主要设计并实现一个高校毕业生档案管理系统，以解决高校毕业生就业信息管理问题。研究工作从目前档案管理流程的痛点入手，整理出学生、院系管理员、档案管理员、系统管理员四个用户在档案业务办理时所处的职责及需求。在此基础上建立基于SpringBoot和Vue.js技术栈的系统架构，把档案业务申请、院系审核、档案核验、学院分类维护、权限动态分配等主要功能模块进行模块化组合。数据库设计阶段以档案业务流转为主线，提炼出毕业用户、院系用户、档案用户、档案业务、档案转递五个主要的实体，用实体关系建模保证数据的一致性和完整性。系统完成之后部署测试环境，对档案申请流程、核验审批路径、权限控制有效性做验证。研究范围只限于档案业务数字化处理方面，不涉及档案物理载体的自动化管理。最终成果为可以运行的系统原型、数据库设计文档、测试报告和用户使用说明书。整个研究按照软件工程规范进行，采用迭代式的开发方法来完成各个阶段的工作。

第二章 相关技术介绍

2.1 Spring Boot框架

　　Spring Boot是基于Java语言的开源微服务开发框架。它利用自动化配置来简化Spring应用的搭建和部署过程，开发者只需要添加相应的依赖就可以快速得到独立运行的应用程序。框架内嵌Tomcat、Jetty等Servlet容器，打包后的应用可直接通过java -jar命令启动，无需额外安装Web服务器。Spring Boot提供生产级的功能模块，即健康检查、指标度量、外部化配置等，可以保证应用在生产环境中稳定运行。框架坚持约定优于配置的设计思想，在降低项目复杂度的同时保留了Spring框架原有的依赖注入和面向切面编程的能力。开发人员可以专注于业务逻辑的实现，而不需要把大量的时间用在处理XML配置文件上。

　　系统后端服务是用Spring Boot框架搭建起来的。控制器层接收到前端发送的HTTP请求之后，会按照路由映射把请求分派给对应的业务处理方法上。服务层把档案申请、审核流转、核验状态变更这些重要业务规则封装起来，事务管理器使多个表更新操作是原子的。持久层使用框架整合的MyBatis框架与数据库交互，数据访问接口只需要定义抽象方法，SQL语句通过注解或者XML文件来完成配置。熊永平对Spring Boot框架快速应用开发的技术优势进行了详细的分析，提出自动配置、Starter依赖等可以提高开发效率的方法[14]。该框架特性被本系统开发过程中的各个功能模块所充分使用，各个功能模块采用不同的Starter依赖来快速实现所需要的能力。

2.2 Vue.js框架

　　Vue.js是一个用来构建用户界面的渐进式JavaScript框架。它使用自底向上增量开发的设计，主要库只做视图层的处理，容易学习，可以和现有的项目进行整合。框架使用虚拟DOM技术提高页面渲染速度，数据发生变化的时候只重新计算并渲染出改变的部分，不会对整个DOM进行修改。Vue.js有响应式数据绑定，模型和视图之间可以自动同步，开发者只需要操作数据状态就可以驱动界面的更新。组件化开发模式把页面分成独立可以复用的模块，每一个组件都包含模板、脚本和样式这三个部分，从而降低代码耦合度以及提高维护性。

　　前端界面全部用Vue.js框架来实现。页面布局使用Element UI组件库快速搭建，表格、表单、对话框等常用元素用引入组件标签直接使用。路由层面用Vue Router来管理页面间的导航关系，不同的功能模块对应不同的路径以及视图组件。状态管理使用VueVuex来集中保存用户会话信息、全局配置等共享的数据给各个组件使用。季甜甜和刘冬冬在研究中对Vue框架的前端性能做了系统的分析，提出过关于组件复用度、渲染效率优化的策略，给本系统的前端架构设计提供一定的理论依据[15]。档案业务列表的筛选条件和表格数据分离设计，就是依靠框架响应式特性来实现条件变化后自动调取数据。

2.3 MySQL数据库

　　MySQL是目前使用最广的开源关系型数据库管理系统之一。它用结构化查询语言作为数据操作接口，可以实现多用户并发访问以及事务处理。数据库采用客户端/服务器结构，应用用连接池和数据库实例进行通信，对数据进行定义、操纵、控制等各方面的操作。InnoDB存储引擎为MySQL的默认事务型存储引擎，支持行级锁和外键约束，在高并发写入情况下可以保证数据的一致性、完整性。数据库提供了多种数据类型，如整数、浮点数、字符串、日期时间、大文本、二进制等，可以满足不同的业务字段存储要求。备份恢复机制可以实现在线热备以及时间点恢复，给数据安全赋予多种保障。

　　系统使用MySQL做数据持久化存储。档案业务信息、用户账户数据、学院分类记录都存放在数据库实例当中。表结构设计遵守第三范式准则，削减数据冗余并维持更新异常。关键业务表档案业务表和档案转递表之间用外键建立联系，保证引用数据的正确性。方玲玲在数据库应用技术教材里详细阐述了MySQL在实际项目中使用的规范，其关于索引优化和查询性能调优的论述给系统数据访问层的设计带来了积极的影响[16]。档案核验管理模块根据申请时间和有效时间组合来筛选数据，对这些字段建立复合索引之后查询响应时间明显变短。

2.4 前后端分离架构

　　前后端分离是Web应用架构的一种。它把前端界面和后端服务分开成两个独立的软件程序，用HTTP协议来交流数据。前端应用做用户交互和界面渲染，后端应用做业务逻辑处理和数据存取。两者之间用标准的接口进行通信，接口一般使用JSON格式传输数据。该架构模式中前端和后端可以同时进行开发，不会互相影响。部署时各自独立运行，前端资源用Web服务器分发，后端服务运行在应用服务器上。职责划分清楚之后，团队分工也变得清晰起来，前端工程师主要做用户体验的优化工作，后端工程师主要负责业务稳定性以及数据处理效率。

　　系统整体用前后端分离的结构来构建。前端Vue应用运行在浏览器上，给后端的SpringBoot应用发送异步请求来获取数据，然后动态地更新页面的内容。后端不会去管前端展示的逻辑，只给符合REST风格的API接口。客户端和服务端之间用Axios库做HTTP通信，请求拦截器统一添加身份验证令牌，响应拦截器处理异常状态码。孙鑫在Spring Boot技术专著里对前后端分离模式下的接口设计和会话管理进行了详细的探究[17]。该种架构的选择使得系统具有较好的横向扩展性，如果以后需要接入移动端应用，只需要复用现有的API接口就可以快速地实现。

第三章 系统分析

3.1 可行性分析

3.1.1 技术可行性

　　系统所使用的技术方案已经通过了实际项目验证。SpringBoot是一个成熟的路由控制、依赖注入和事务管理的后端开发框架，可以保证业务逻辑的正常运行。Vue.js前端框架同Element UI组件库相结合，能快速搭建起符合用户操作习惯的交互界面。MySQL数据库具有很好的数据持久化能力，事务机制可以保证档案业务申请和审核过程中的数据一致。开发工具方面，IntelliJ IDEA与Visual Studio Code均提供对相关框架的完善支持。该种技术组合结构清楚，各个层次的职责也十分明确，可以满足系统功能扩充以及性能改善的要求。

3.1.2 操作可行性

　　系统界面的设计符合用户日常使用习惯。档案业务列表页可以对学院名称、申请时间、审核状态等进行多维筛选，从而找到想要的记录。表格展示主要的信息字段，操作区域集中放置审核、详情、核验等常用功能入口。学生用户登录之后只看到本人的档案申请记录，操作路径简单明了。院系管理员与档案管理员界面布局一致，功能按钮位置合理，学习成本较低。系统对于各类用户所拥有的计算机操作水平要求不高，有基本网页浏览经验的人员都可以完成日常业务的处理。

3.1.3 经济可行性

　　系统建设所消耗的资源在可以控制的范围内。开发阶段的主要成本是人力投入，所用的开源技术框架不需要支付授权费用。部署运行阶段可以复用学校已有的服务器资源，数据库和Web应用都部署在同一台物理机或者虚拟机里，不需要另外购买高性能的硬件。日常维护工作由学校信息技术部门现有的人员来完成，系统上线以后只需要定期备份数据、查看服务状态即可。档案业务由纸质化转向数字化流转之后，纸质打印、文件邮寄、人工跟踪这些显性的费用都会大幅度减少。从长远来看，系统所造成的效率提高和管理成本下降可以弥补初期的建设投资。

3.2 功能需求分析

　　学生登录系统之后进入到个人工作台界面。档案业务管理模块有档案转递申请发起功能，学生填写毕业去向、档案信息、补充材料等信息后提交。档案核验管理模块可以上传核验材料文件，记录核验请求，生成待审核记录。学生可以随时查询业务办理进程及核验结果反馈。学生角色用例图如图3-1所示。

图3-1学生用例图

　　院系管理员登录系统之后就会进入到待办事项列表界面。档案业务管理模块显示本学院学生提交的待审核申请记录。院系管理员查看申请材料详细信息，对符合规范的材料进行审核通过，对材料不完整的申请填写退回意见并打回。院系管理员角色用例图如图3-2所示。

图3-2院系管理员用例图

　　档案管理员登录系统后进入档案业务办理工作台。档案业务管理模块提供待办理业务列表查阅功能，档案管理员核实档案信息与系统记录一致性，办理档案转递并填写转递信息。档案核验管理模块展示学生提交的核验申请，档案管理员审核证明材料真实性，作出核验通过或不通过决定并填写审核回复。档案管理员角色用例图如图3-3所示。

图3-3档案管理员用例图

　　系统管理员登录系统之后就进入到系统的管理控制台。学院分类管理模块有学院名称的增加、修改和删除。档案业务管理模块可以查看所有的业务记录以及业务的办理状态。档案核验管理模块可以查看所有的核验申请历史以及审核结果。权限管理模块完成用户组权限的配置工作，即给各个角色赋予可以访问哪些模块、可以执行哪些操作的权限。系统管理员角色用例图如图3-4所示。

图3-4系统管理员用例图

第四章 系统设计

4.1 系统架构设计

　　系统用分层架构思想来组织各个功能模块。用户界面层是操作界面和用户输入的接收者，使用Vue.js框架创建的单页应用运行在浏览器中。应用服务层对档案业务申请、审核流转、核验处理等关键逻辑进行封装，用RESTful接口的形式对外提供服务。数据持久层用MyBatis框架和MySQL数据库进行交互，完成业务数据的增删改查。系统支持层提供跨域配置、拦截器认证、异常统一处理等基础能力，保证各个层之间可以顺利地配合工作。分层的设计使系统有较好的可维护性，某一层的修改不会波及到其他的层次。系统架构图如图4-1所示。

　　图4-1系统架构图

4.2 系统结构功能设计

　　系统按照四类用户角色来搭建功能布局。学生角色可以访问档案业务管理、档案核验管理这两个模块，用以提出个人申请并跟踪核验进程。院系管理员负责审核本院系学生申请。档案管理员同时对档案业务管理和档案核验管理进行操作，既处理业务申请又审核核验请求。系统管理员拥有最高的权限，可以对学院分类、档案业务、档案核验、权限分配等进行管理。各个功能模块之间用统一的数据模型和流程定义相连接，档案业务申请经过审核之后可以进入到核验环节，核验结果反馈到业务记录当中形成闭环。该系统功能结构如图4-2所示。

图4-2系统功能结构图

4.3 系统流程设计

　　档案业务申请流程设计，学生用户在档案业务管理模块中填写申请信息并上传相关材料，系统保存申请记录，并将状态设置为待审核。院系管理员登录后可以看到待处理申请列表，点击审核按钮进入审核页面填写意见并指定下一级审核人。如果审核通过就进入档案管理员处理环节，如果不通过则退回给学生用户修改。档案业务流程图如图4-3所示。

图4-3档案业务流程图

　　档案核验申请流程的设计，档案管理员在档案业务列表里选择需要核验的记录后进行核验，系统产生核验记录并赋予唯一的核验码。用人单位或者学生本人使用核验码查询档案的真实性。档案管理员在核验管理页面中输入审核意见之后，系统会自动更新核验状态，并把审核结果告诉学生用户。档案核验流程图如图4-4所示。

图4-4档案核验流程图

　　学院分类维护流程设计，系统管理员进入学院分类管理页面，查看已有的学院列表。新增学院时输入学院名称并提交，系统校验名称唯一性后保存记录。修改学院信息要先查到目标记录，编辑完后提交更新。删除操作要先查看该学院是否与其它档案业务数据存在关联关系，没有关联关系才可以删除。学院分类维护流程图如图4-5所示。

图4-5学院分类维护流程图

　　权限分配流程设计，系统管理员进入权限管理页面，选择需要的用户组。页面展示出该用户组目前拥有哪些权限。勾选或者取消勾选具体的权限项之后提交，系统更新用户组和权限的关联关系。用户重新登录之后会得到最新的权限设置，界面的菜单以及操作按钮会根据权限的变化而变化。权限分配流程图如图4-6所示。

图4-6权限分配流程图

　　档案转递状态追踪流程设计，档案管理员发起转递操作之后系统就会产生转递记录并记载当前状态。物流信息更新时可以同步到系统，状态由待发出变为运输中。毕业生或者接收单位用核验码查询实时位置。到达目的地后档案管理员进行签收，系统把状态变为完成。档案转递流程图如图4-7所示。

图4-7档案转递流程图

4.4 数据库设计

4.4.1 概念模型设计

　　设计高校毕业生档案管理系统概念模型时，首先要明确毕业用户、院系用户、档案用户这三类人员以及档案业务、档案转递这两个主要业务过程之间动态的联系。毕业用户提交档案业务申请，院系用户进行审核，档案用户核验、转递，各个角色之间存在多对多的协作关系[18]。概念模型是对现实世界和信息世界之间进行一次抽象，把业务规则转为实体和联系。实体是系统中用来存储信息的事物，属性是事物的特征，联系是实体之间存在的关系。使用实体-联系图可以清楚地看到数据结构的总体情况。根据以上分析，绘制反映系统全域数据结构的E-R图，为后面逻辑模型的设计提供依据。全局E-R模型如图4-8所

图4-8全局ER图

　　根据系统分析，系统的主要实体有：毕业用户、院系用户、档案用户、档案业务、档案转递、学院分类、用户账户、用户组、权限管理、通知记录，各个实体具体的属性如下图所示。

图4-9毕业用户属性图 图4-10院系用户属性图 图4-11档案用户属性图 图4-12档案业务属性图 图4-13档案转递属性图 图4-14学院分类属性图 图4-15用户账户属性图 图4-16用户组属性图 图4-17权限管理属性图 图4-18通知记录属性图

4.4.2 数据库逻辑设计

　　逻辑模型设计阶段把概念模型中的实体和联系转化为具体的数据库表结构。每一个实体对应一张数据表，实体属性对应表的字段，实体间的关系用主外键约束来实现。该过程要确定各个字段的数据类型、长度和是否可以为空，并且还要考虑索引的创建来提高查询效率。规范化的建立可以减少数据的重复录入，保证更新不会出错。钟林森在分布式中间件技术应用中提出的关系型数据库表结构设计基本准则，给本系统数据库的设计提供一定的参考[19]。档案业务表和档案转递表用外键来建立联系，保证引用数据的完整性。

　　毕业用户表主要是用来存储毕业生的基本身份信息与学籍数据。主要包括学生学号、学生姓名、手机号码、学院名称等字段。如表4-1所示。

表4-1毕业用户表

　　院系用户表主要是用来存储院系管理人员的身份信息与联系方式。主要包括院系姓名、联系号码、审核状态、用户ID等字段。如表4-2所示。

表4-2院系用户表

　　档案用户表主要是用来存储档案管理人员的姓名与联系方式。主要包括用户姓名、手机号码、审核状态、用户ID等字段。如表4-3所示。

表4-3档案用户表

　　档案业务表主要是用来存储学生提交的档案申请记录与审核过程信息。主要包括毕业用户、学生姓名、学院名称、审核状态等字段。如表4-4所示。

表4-4档案业务表

　　档案转递表主要是用来存储档案从学校寄出到接收单位签收的全过程记录。主要包括毕业用户、档案用户、申请时间、审核状态等字段。如表4-5所示。

表4-5档案转递表

　　学院分类表主要是用来存储学校各二级学院的名称信息。主要包括学院名称、创建时间、更新时间等字段。如表4-6所示。

表4-6学院分类表

　　用户账户表主要是用来存储系统登录账户的认证信息与基本资料。主要包括用户名、密码、用户组、手机号码等字段。如表4-7所示。

表4-7用户账户表

　　用户组表主要是用来存储不同角色群体的定义与基本属性。主要包括名称、描述、注册位置等字段。如表4-8所示。

表4-8用户组表

　　权限管理表主要是用来存储各用户组对不同功能模块的操作权限配置。主要包括用户组、模块名、页面标题、路由路径等字段。如表4-9所示。

表4-9权限管理表

　　通知记录表主要是用来存储系统向用户推送的消息内容与状态。主要包括通知人ID、标题、状态、内容等字段。如表4-10所示。

表4-10通知记录表

第五章 系统实现

5.1 学生角色功能实现

5.1.1 档案业务管理

　　档案业务管理功能是对毕业生提交的档案申请记录做全流程跟踪。学生用户登录系统之后会进入到档案业务列表页面，该页面会显示本人所提交过的所有申请记录。用户点击新增申请按钮填写毕业去向、申请备注等信息，上传档案信息和补充材料文件后提交保存。申请提交之后状态变更为待审核，用户可以在列表里随时查看当前的审核进度。审核过程中如果院系管理员或者档案管理员退回申请，用户会收到退回通知并可以进入详情页查看审核回复意见，根据意见修改后重新提交。档案业务管理界面如图5-1所示。

图5-1档案业务管理界面

5.1.2 档案核验管理

　　档案核验管理功能是对档案真实性核验申请的跟踪。学生用户在档案业务列表里选中已经审核通过的记录之后，就可以发起核验请求了，系统会生成相应的核验记录以及核验码。核验管理列表显示所有核验申请，每一条记录包含申请时间、有效时间、用人单位和当前审核状态。档案管理员对核验申请进行审核后，审核状态变为已通过或者未通过，学生用户可以点击详情查看审核回复的内容。核验通过后用人单位可凭核验码查询档案信息，学生可在系统中查看核验记录的使用情况。档案核验管理界面如图5-2所示。

图5-2档案核验管理界面

5.2 院系管理员角色功能实现

5.2.1 档案业务管理

　　院系管理员角色档案业务管理功能，是对本学院学生提交的档案申请进行审核处理。管理员登录档案业务列表页面，表格以申请时间倒序的方式显示待审核、已审核的档案。筛选条件可以按照学院名称和审核状态一起进行查询，从而找到需要的记录。点击审核按钮进入审核页面，页面上显示学生填写的申请信息、档案信息附件和补充材料下载链接。管理员填写审核意见，选择下一级审核人之后提交。若选择不通过则申请退回学生用户，系统自动发送通知告知退回原因。经过审核的申请流转到档案管理员处理环节。档案业务管理界面如图5-3所示。

图5-3院系管理员档案业务管理界面

5.3 档案管理员角色功能实现

5.3.1 档案业务管理

　　档案管理员档案业务管理功能就是对院系审核通过的档案申请进行最后的核验和转递。管理员进入档案业务列表页面，表格显示所有待处理和已处理的申请记录。点击详情可以查看完整的申请信息以及历次审核意见。档案信息以及补充材料可以在线预览、下载。确认无误后管理员可以发起档案核验操作，系统进入核验管理模块生成核验记录。需要转递纸质档案时，管理员录入快递单号并更新转递状态，学生用户可以实时查询物流信息。档案业务管理界面如图5-4所示。

图5-4档案管理员档案业务管理界面

5.3.2 档案核验管理

　　档案核验管理功能是对学生提出核验申请后的审核和回复。管理员进入档案核验列表页面，表格按照申请时间排序显示所有的核验记录。每一条记录都包含毕业用户、档案用户、申请时间、有效时间以及用人单位的信息。未审核状态的记录操作列上会显示审核按钮，点击后进入审核页面填写审核意见。审核通过之后核验状态变为已通过，系统给学生用户发送审核结果通知。已审核记录操作列有详情按钮，点击可以查看完整的审核过程信息。批量审核功能可以同时对多条核验请求进行审核，提高操作效率。档案核验管理界面如图5-5所示。

图5-5档案管理员档案核验管理界面

5.4 系统管理员角色功能实现

5.4.1 学院分类管理

　　学院分类管理功能是对学校各个二级学院的基本信息进行维护。系统管理员进入学院分类列表页面，表格显示已有的学院名称、创建时间、更新时间。新增学院时点击添加按钮出现表单，输入学院名称后提交，系统会检验名称是否唯一后保存记录。修改学院信息需要先选择目标记录点击修改按钮，编辑完成后提交更新。删除操作之前系统会先检查该学院是否有毕业生或者档案业务数据关联，如果有则会提示不能删除，并给出具体的禁止原因。列表可以按照学院名称模糊查询，方便快速定位。学院分类管理界面如图5-6所示。

图5-6学院分类管理界面

5.4.2 档案业务管理

　　系统管理员档案业务管理功能是从全局角度对所有的档案申请记录进行查看和处理。管理员进入档案业务列表页面，表格显示全校各个学院学生提交的申请数据。筛选条件可以按照学院名称、申请时间范围、审核状态进行组合查询，从而对各个阶段的业务量进行统计分析。详情页可以查看完整的申请信息和审核链路，即院系管理员的审核意见、档案管理员核验记录。批量删除功能可以清除掉过期或者无效的测试数据。导出功能可以把筛选的结果导出成Excel文件，供线下存档和数据分析使用。档案业务管理界面如图5-7所示。

图5-7系统管理员档案业务管理界面

5.4.3 档案核验管理

　　系统管理员档案核验管理功能主要是对全校所有核验记录进行统一审核与管理。管理员进入档案核验列表页面，表格展示全部核验申请，支持按申请时间、有效时间、审核状态进行筛选。批量审核功能可同时处理多条待审核记录，提高核验效率。审核过程中可填写统一的审核回复内容，系统自动应用到所选记录。删除操作用于清理测试数据或已过期的核验记录。详情页展示完整的核验过程信息，包括历次审核回复与状态变更记录。档案核验管理界面如图5-8所示。

图5-8系统管理员档案核验管理界面

5.4.4 权限管理

　　权限管理功能是对不同的用户组操作权限做精细的配置。管理员进入权限列表页面，表格显示所有已经配置好的权限项，每一行记录包括用户组、权限名称、添加权限、修改权限、删除权限、查询权限的开关状态。新增权限时选择用户组和模块名称，勾选对应操作权限后提交保存。修改权限可以改变已经设置好的配置的开关状态。筛选条件可以按照权限名和用户组进行组合查询，快速找到需要的配置。权限变更之后用户重新登录就会加载最新的配置，界面菜单和操作按钮会根据权限的变化而变化。权限管理界面如图5-9所示。

图5-9权限管理界面

第六章 系统测试

6.1 测试目的

　　系统测试就是检验高校毕业生档案管理系统功能实现是否符合需求规格说明书。测试过程中对业务逻辑和设计规格的符合程度进行关注，保证档案申请、审核、核验等各个环节的操作结果和预期一致。系统鲁棒性测试是对异常输入以及边界情况的处理能力进行考察，防止由于用户的误操作造成数据错误或者程序崩溃。全链路数据一致性测试就是检验档案业务提交、审核到核验全过程信息状态的变化，保证信息流转准确无误。访问安全测试验证不同的用户只可以访问自己权限范围内所拥有的功能模块，防止越权操作。王希、戴靓婕的研究表明，数据库技术在Web动态页面上的应用可以给测试用例的设计提供一些参考[20]。对系统进行测试，在系统上线之前及时发现并修复可能存在的问题，减少系统上线后出现的运行风险。

6.2 测试方法

　　系统主要使用黑盒测试为主、白盒测试为辅的方式来验证。黑盒测试把系统当作不透明的整体，依照需求文档制订测试用例，经由输入数据和操作步骤来考察输出结果是否契合预期。测试用例包含正常的流程以及异常的分支，即必填项为空、文件格式不正确、申请时间跨度太大等等。白盒测试关注程序内部逻辑结构，对核心业务模块的循环和分支路径进行测试数据的设计，保证每一个代码路径都被覆盖。在测试过程中用Postman模拟前端发送HTTP请求，检验接口返回状态码和数据结构是否正确。浏览器开发者工具用来检测前端页面渲染的效果以及异步请求的响应。测试环境部署在本地服务器上，数据库用独立的测试实例来保证不会对真实的数据造成影响。

6.3 测试内容

　　档案业务申请功能测试如表6-1所示。

表6-1档案业务申请功能测试表

　　档案核验功能测试如表6-2所示。

表6-2档案核验功能测试表

　　学院分类管理功能测试如表6-3所示。

表6-3学院分类管理功能测试表

　　权限分配功能测试如表6-4所示。

表6-4权限分配功能测试表

　　档案转递追踪功能测试如表6-5所示。

表6-5档案转递追踪功能测试表

测试结论

　　对高校毕业生档案管理系统进行功能测试，主要对档案业务申请、档案核验、学院分类管理、权限分配、档案转递追踪这五个模块进行了测试。测试用例有正常的流程操作和异常输入的场景，一共执行了二十组测试用例。档案业务申请模块对于必填项的校验和文件格式的限制都进行了正常的处理，重复提交也被系统有效拦截。档案核验模块中核验码的生成和有效期控制是可靠的，当核验码过期时，系统会给出失效提示。学院分类管理模块在新增学院的时候可以检测到重复名称，在删除操作关联检查功能生效之后。权限分配模块修改配置之后，用户重新登录界面的按钮状态就会被同步更新。档案转递追踪模块物流状态同步、学生查询等都返回正确的数据。所有的测试用例实际结果与预期结果一致。

项目分享：大家可自取用于参考学习，获取方式可私信哦！