第1章 绪论
1.1 研究背景及意义
1.1.1 研究背景
学前教育信息化的发展正在改变家庭和教育机构之间合作的方式。伴随着移动互联网技术的迅速发展,家长对子女在园期间的成长状况越来越关注,但是现有的纸质档案、口头传达、微信群消息等碎片化的信息传递方式已经不能满足系统性成长数据管理的要求。儿童语言、运动、认知、情感等各方面的成长轨迹要持续记载并加以阶段性的回顾,这就对信息系统具备结构化的存储能力提出要求[1]。国内许多研究认为,目前学前教育机构在数据的沉淀和家园之间的互通上没有有效的技术支持,造成宝贵的成长数据分散在各种非结构化的载体中,不能形成完整的个体成长画像[2]。与此同时,微信小程序凭借不需要安装、跨平台运行、用户获取门槛低等特点,给家长群体创建轻量化应用赋予了成熟的技术途径[3]。在这种情况下,设计一个以儿童成长档案为中心、整合教师记录、机构课程、家长互动等各方面的业务流的数字化系统,有实际的应用价值。
1.1.2 研究意义
儿童成长档案系统创建具有诸多方面的实践意义,从多个方面来说都是如此。从效率角度来讲,系统把分散在教师手册、家园联系本、口头沟通这些地方的信息集中到结构化数据库当中,大大缩减了信息传递的路径,削减了教师在记录和汇总时的重复工作量。从用户体验的角度来讲,家长可以利用微信小程序随时随地了解子女的健康数据、成长轨迹、活动内容,不用等到定期的家长会或者书面报告才能知晓子女在校情况。就数据价值而言,系统积累下来的多方面成长数据可以给机构实施儿童发展评价赋予客观支撑,从而达成阶段性的横向比较以及个体的纵向追踪。从行业示范角度来说,本系统依靠主流开源技术栈搭建而成,部署和维持的门槛不高,具备向中小规模学前教育机构推广的实际可能性,可以为类似系统的创建和实现给予参照样本。
1.2 研究现状
1.2.1 国内研究现状
国内学前教育信息化领域系统建设始于教务管理软件的推广阶段,早期主要是考勤、收费等行政功能,后来才逐渐发展到家园互动、成长档案、课程管理等业务的纵深。近些年来,由于移动端技术日渐成熟,小程序同App并存的双端架构渐渐成为学前教育信息平台的主流形式,系统功能范围也由原先的单个机构管理发展为如今的家园协同生态。
谢志勋于2025年就高校人事档案管理系统进行研究,提出了一种基于大数据技术的系统架构方案,用模块化的设计方法来达到数据智能查询和权限控制的目的[4],档案分类管理、权限分层设计思路直接为本系统角色权限设置提供参考。邾强在2025年设计并实现了一个基于人工智能技术的电子档案系统,主要研究智能检索和内容挖掘在档案管理中的应用途径[5],该研究中档案数据结构化存储、多维度检索的设计方法给本系统成长记录模块的数据组织方式提供了一定的借鉴。张浩于2025年研究了档案管理数字化系统的设计和实现过程,使用模块化设计思想来创建包含数据采集、存储、检索等全部功能的系统[6],其对于系统检索响应时间优化的考虑给本系统在数据查询性能方面的设计取向提供了一些启示。
1.2.2 国外研究现状
国外对于儿童教育信息管理以及文档数字化方面的研究开始得比较早,大体上表现出智能化、去中心化、数据安全并重的发展趋向。相关研究的技术路径已经由传统的集中式存储发展到区块链分布式架构,安全性、透明度成了近几年来研究的主要问题,数据驱动的个性化服务理念也逐渐渗入到教育类系统功能的设计当中。
Marian于2026年提出利用低代码平台创建文档管理系统以及审批系统的方案,并且采用Power Apps、Power Automate等组件创建出能够跟踪工作流的系统[7],其在工作流自动化以及审批逻辑设计上的经验对于本系统的通知管理以及订单售后流程的设计有着借鉴意义。Sun在2022年对基于移动应用的学前教育系统进行设计,分析了游戏化课程和新媒体资源在幼儿教学中应用的方式[8],移动端交互设计的思想给本系统的微信小程序端用户界面规划提供借鉴。Li于2021年对基于区块链技术的档案管理系统进行研究,采用区块链的不可篡改性、可追溯性来解决传统集中式档案管理中数据共享和安全方面的问题[9],其分布式权限控制的思想给本系统多角色数据访问边界划定提供理论参考。2025年Han等人提出了一种去中心化的文档管理系统,使用Shamir的秘密共享方案和IPFS的存储机制来提高数字文档的完整性、安全性[10],其在多用户权限分发、文档访问控制方面的设计可以给本系统课程资料、成长记录的访问权限管理提供一定的参考。Wang2023年对基于Hadoop的高校图书档案管理信息系统进行了研究,采用Lucene检索引擎和JavaWeb技术完成了分布式档案数据的存储和检索[11],其系统架构分层设计和检索功能实现方案对本系统后端服务层的设计有借鉴意义。
国外研究在安全性保障、工作流自动化、移动端适配等方面取得了丰富的成果,但是大部分系统是面向企业级或者高校场景的,对于学前教育场景下多角色协同、儿童个体数据管理等方面的专项设计考虑较少。本系统在吸收以上研究中模块化设计、权限分层控制、移动端交互等主要思想的基础上,根据学前教育机构实际业务场景,创建起面向家长、教师、机构、管理员的多角色协同档案管理平台。
第2章 需求及可行性分析
2.1 需求分析
2.1.1 管理员角色功能需求
管理员对系统的整体内容进行控制,可以对活动信息进行添加、修改、查看、删除和发布操作,可以上传、编辑、查看和删除课程资料,可以查看、删除和评论家长提交的成长记录,可以查看、删除和回复用户的留言,可以删除用户的留言。管理员拥有最高级的操作权限,各个模块的数据都在他的控制范围内,保证平台内容的合法性以及信息的质量。如图图2.1。
图2.1管理员用例图
2.1.2 教师角色功能需求
教师在系统中负责儿童日常管理和信息录入工作,可以对日程进行添加、修改、查看、删除,可以对班级儿童信息进行新增、修改、查看、删除,可以发布、修改、查看、删除通知记录,可以记录、查看、修改、删除儿童健康能力数据。教师操作的对象是其管辖的班级内儿童以及相关的家长,数据权限同班级归属挂钩。如图图2.2。
图2.2教师用例图
2.1.3 机构角色功能需求
机构用户负责课程内容发布及售后管理,可以上传、编辑、查看、删除课程资料,可以查看、回复、删除家长提交的答疑提问,可以发布、编辑、查看、下架课程信息,可以查看订单详情并处理家长提交的售后申请。机构操作的范围只限于本机构发布过的课程以及相应的订单数据,与其它机构的数据相隔离。如图2.3所示。
图2.3机构用例图
2.1.4 家长角色功能需求
家长属于系统的终端用户,借助微信小程序来进行日常的互动。家长可以看到活动列表和详情,可以报名活动并取消报名,可以查看订单列表和详情,可以取消订单,可以申请售后,可以增加、修改、查看和删除子女成长记录,可以浏览知识资源列表和详情,下载资源,收藏资源。家长所有操作都是以子女成长数据和课程服务为对象,数据范围只包括本账号关联的儿童信息。如图图2.4。
图2.4家长用例图
2.2 可行性分析
2.2.1 技术可行性
本系统使用Spring Boot作为后端框架,Vue作为管理端前端框架,微信小程序作为用户端入口,MySQL作为关系型数据库,以上技术都是目前主流的成熟的开发技术,有完善官方文档和活跃的社区生态支持。经过大量的项目验证之后发现,前后端分离架构各层次的技术之间协同关系清楚,接口规范明确,开发环境的搭建也比较方便。系统结构合理、技术选型之间不存在兼容性矛盾,能完成本科毕业设计阶段的任务。
2.2.2 经济可行性
本系统所用到的所有技术框架都是开源免费的,没有商业授权费用。开发阶段用本地计算机做编码和调试,运行环境部署到通用服务器上,硬件投资在可接受范围内。系统建成之后,日常维护主要是数据备份和功能升级,维护成本小。就经济上而言,整体开发资源投入与预期功能产出相比要经济一些,适合于中小型学前教育机构做为信息化建设的起步方案。
2.2.3 操作可行性
系统管理端用Vue创建,界面布局清晰,各个功能模块通过侧边导航直接到达,操作路径短、逻辑连贯。微信小程序端面向家长用户,交互方式按照微信平台标准设计规范进行,家长在使用微信的过程中可以很快掌握主要功能。教师和机构用户的功能操作只在自己的权限范围内进行,界面中没有无关的内容,从而有效地降低了操作误判的风险。系统的整体交互复杂度比较适中,各个用户群体在较短的时间内可以学会大部分的操作。
第3章 开发环境及相关技术介绍
3.1 开发环境
本系统开发环境按照前端、后端以及数据库的职责不同分别进行配置,各个端开发工具的选择以技术栈兼容性以及开发效率为先决条件,具体的环境参数见表3.1。
表3.1系统开发环境配置表
| 环境类别 | 工具/技术 | 版本/说明 |
|---|---|---|
| 后端开发框架 | Spring Boot | 2.x 版本 |
| 后端开发语言 | Java | JDK 8 |
| 管理端前端框架 | Vue | Vue 2.x |
| 用户端小程序框架 | UniApp | 基于 Vue 的跨端框架 |
| 集成开发环境 | IntelliJ IDEA | Ultimate 版本 |
| 微信开发者工具 | 微信官方IDE | 稳定版 |
| 数据库管理系统 | MySQL | 5.7 版本 |
| 数据库管理工具 | Navicat | Premium 版本 |
| 后端构建工具 | Maven | 3.6 版本 |
| 接口调试工具 | Apifox/Postman | 最新稳定版 |
| 浏览器 | Google Chrome | 最新稳定版 |
| 本地服务器 | Apache Tomcat | Spring Boot 内嵌 |
| 操作系统 | Windows 10/11 | 64位 |
后端开发使用的是IntelliJ IDEA集成开发环境,该环境对Spring Boot项目有完善的构建支持和代码提示功能,可以大大提高业务逻辑层的编码效率。项目使用Maven工具,用pom.xml文件统一声明Spring Boot、MyBatis、MySQL驱动等组件的依赖版本,保证本地开发环境和生产部署环境的依赖一致。后端应用使用Spring Boot内嵌的Tomcat容器来运行,不需要另外配置外部的Web服务器,使开发环境的搭建变得简单。
管理端前端开发在IntelliJ IDEA中同步完成,Vue项目使用Vue CLI脚手架工具进行初始化构建,开发阶段用Webpack Dev Server提供的热重载功能实现代码变更即时页面渲染反馈,提高界面联调效率。
用户端小程序用UniApp框架开发,用微信官方提供的微信开发者工具进行本地编译、调试和真机预览。uniapp项目使用HBuilderX或者命令行工具创建,编译后的代码可以直接导入到微信开发者工具中运行,开发阶段的数据交互是在开发环境内通过局域网接口调用实现的。
数据库使用的是MySQL 5.7关系型数据库,用NavicatPremium图形化管理工具设计表结构、录入测试数据、做SQL查询验证。Navicat数据建模、导入导出功能给开发初期测试数据准备提供方便的操作入口,SQL预览功能也帮助开发人员在使用MyBatis映射语句时进行正确的校验。
各个开发工具都是目前业内主流版本,开发环境总体上已经经过了实践检验,可以满足本科毕业设计阶段的编码、调试、测试等需要。
3.2 相关技术介绍
3.2.1 Spring Boot框架
Spring Boot是在Spring框架的基础上发展起来的快速开发框架,它的主要设计理念就是用自动配置的方式消除传统Spring项目中大量的繁琐XML配置工作。开发者只需要引入对应的Starter依赖,框架就会根据类路径中包含的组件来自动完成Bean的装配和初始化,从而把开发精力放在业务逻辑的实现上。Spring Boot内嵌Tomcat等Web容器,打包好的应用是以可执行JAR的形式独立运行的,不需要部署到外部的应用服务器上,大大简化了环境的配置工作[12]。
本系统中Spring Boot完成后端服务全部的运行支持。各个业务模块的控制层、服务层、数据访问层都在Spring Boot的IoC容器中进行统一管理,使用依赖注入的方式实现模块之间的低耦合合作。系统利用Spring Boot的RESTful接口规范向前端、小程序端提供数据服务,成长记录、课程信息、订单处理等主要业务的数据流转都是经过该层完成的[13]。Spring Boot统一异常处理机制保证了接口响应格式的一致性,给前后端分离架构下稳定的通信打下了基础。
3.2.2 Vue框架
Vue.js是一个渐进式的JavaScript框架,它使用基于组件的方式构建用户界面,把界面拆分成可以被复用的独立单元,每一个组件都包含有自己的模板、逻辑和样式[14]。Vue的响应式数据绑定系统利用数据劫持和依赖追踪来实现数据状态变化引起视图更新,省去了手动操作DOM的开销,使界面和数据一直保持同步。
本系统管理端使用Vue构建单页面应用,管理员对于活动信息、课程资料、成长记录、留言等各方面的管理操作都在此界面上完成。Vue Router完成页面路由切换,Vuex处理跨组件共享的用户状态和权限。组件化开发模式使不同的角色功能页面可以共享基础组件来实现独立扩展,大大提高界面开发效率[15]。Vue同Spring Boot的后端利用Axios进行异步HTTP请求,对数据实行按需加载,从而削减了非必要的页面刷新行为。
3.2.3 微信小程序
微信小程序是运行在微信客户端内部的轻量级应用形态,用WXML、WXSS、JavaScript技术组合来创建页面结构和交互逻辑,不需要用户单独下载安装就可以直接使用[16]。小程序利用微信提供的原生API来访问设备的各种能力,比如相机拍照、文件读写、位置获取等等,并且依靠微信账号系统完成用户的快速登录和认证。
微信小程序为本系统家长用户的使用端口,即前端展示与交互。家长在小程序上完成活动报名、成长记录的添加、查看、成长资源浏览下载、订单管理等日常操作,小程序端使用HTTPS请求同Spring Boot后端数据交互。小程序天生嵌入到微信生态中,大大降低了家长用户使用的门槛,对于习惯了用微信通讯的用户来说不需要额外的学习成本[17]。
3.2.4 MySQL数据库
MySQL是开源的关系型数据库管理系统,用结构化查询语言作为操作接口,用表、行、列的方式组织数据,支持事务管理和外键约束,可以保证数据的一致性和完整性[18]。MySQL使用基于索引的查询优化机制,在数据量比较小的业务场景下有较好的查询响应性能,是Web应用领域最常用的一种数据库系统。
本系统只使用了MySQL一个持久化存储引擎,管理员、教师、机构、家长等角色的业务数据都存放在对应的数据库表里。成长记录、健康能力、课程信息、订单等核心业务表之间用外键关联来保证数据完整性,后端使用MyBatis框架把Java对象和数据库表联系起来,完成增删改查的操作[19]。数据库层面字段类型规划和索引设计可以保证系统多用户并发访问的时候数据读写的速度。
第4章 系统设计
4.1 系统架构设计
儿童成长档案系统采用B/S架构,整体分为用户界面层、应用服务层、数据持久层三个主要层级,各层职责明确,层间通过标准协议进行数据交换。用户界面层由Vue管理端与微信小程序两个前端入口构成,分别服务于管理人员与家长用户群体,界面交互通过HTTP请求向后端发起数据操作。应用服务层以Spring Boot框架为核心,承载业务逻辑的全部处理工作,涵盖用户认证、权限拦截、业务规则校验、数据组装等环节,RESTful风格的接口设计保证了前后端的解耦协作。数据持久层由MySQL数据库提供关系型数据存储服务,通过MyBatis框架完成对象关系映射,各业务实体的增删改查操作均经由此层落库。系统支持层提供文件存储、日志记录等辅助能力,保障系统运行的基础条件。系统架构图如图4.1所示。
图4.1系统架构图
4.2 系统功能设计
儿童成长档案系统围绕管理员、教师、机构、家长四类角色构建功能体系。管理员模块涵盖活动信息管理、课程资料管理、成长记录管理、留言管理四个方向,负责平台内容的整体维护。教师模块包含日程管理、班级儿童管理、通知记录管理、健康能力管理,以班级为操作粒度记录儿童日常信息。机构模块包括课程资料管理、答疑提问管理、课程信息管理、订单售后管理,支持机构完成课程发布与服务闭环。家长模块涵盖活动信息、我的订单、成长记录、知识资源四个功能方向,家长通过微信小程序完成子女成长数据的记录与查阅。该系统功能结构如图4.2所示。
图4.2系统功能结构图
4.3 业务流程设计
4.3.1 活动报名流程设计
家长通过微信小程序进入活动列表页面后,系统加载当前已发布的活动数据并展示给用户。家长选择目标活动查看详情,系统判断当前用户是否已完成登录认证,未认证用户跳转至登录页面,已认证用户继续查看报名条件。系统检测该活动是否仍处于可报名状态,如活动名额已满或报名截止则提示家长无法操作,否则允许提交报名申请。报名成功后系统更新活动参与人数并向家长返回确认信息,家长可在个人中心查看报名记录并选择取消报名。活动报名流程图如图4.3所示。

图4.3活动报名流程图
4.3.2 成长记录新增流程设计
家长在微信小程序端进入成长记录模块,选择新增操作后系统呈现记录填写页面。家长录入儿童姓名、记录日期、记录类型等基本信息,并可上传相关图片、视频或文件附件。提交前系统对必填字段进行完整性校验,校验未通过则提示家长补全信息,校验通过则将记录数据写入数据库并关联至对应家长账号。记录保存成功后,管理员可在后台查看该记录并进行评论或管理操作,家长亦可随时对已提交记录进行编辑或删除。成长记录流程图如图4.4所示。
图4.4成长记录流程图
4.3.3 课程购买订单流程设计
家长在小程序端浏览机构发布的课程信息,选定目标课程后查看价格与课程详情。系统判断当前课程是否处于上架状态,下架课程不允许购买,上架课程允许家长加入购物车或直接提交订单。订单生成时系统记录课程信息、购买数量、联系人信息及订单总价,初始状态设为待付款。付款完成后订单流转至待发货状态,机构处理后更新发货状态,家长确认收货后订单完成。如家长对订单有异议,可在订单管理中发起售后申请,机构审核后作出处理决定。课程订单流程图如图4.5所示。

图4.5课程订单流程图
4.3.4 答疑提问流程设计
家长在小程序端选择课程后进入答疑区域,提交针对该课程的提问内容,系统记录提问日期与关联课程名称并将数据存储至答疑提问表。机构用户登录管理端后,在答疑提问管理模块查看待回复列表,系统判断当前提问是否已有回复,未回复的提问优先展示。机构选择提问条目后录入回复内容并提交,系统更新对应记录的机构回复字段。家长刷新答疑页面后即可看到机构的回复内容,若机构认为提问内容不合规,可选择直接删除该记录。答疑提问流程图如图4.6所示。
图4.6答疑提问流程图
4.3.5 健康能力记录流程设计
教师登录系统后进入健康能力管理模块,选择新增操作后系统展示记录填写界面。教师选择对应儿童的班级归属,录入儿童姓名、记录日期、记录类型、记录内容等字段,并可上传附件文件。系统提交前校验儿童姓名是否存在于班级儿童表中,匹配失败则提示教师确认儿童信息,匹配成功则将健康记录写入数据库并与教师账号及家长账号建立关联。关联家长可在小程序端的对应模块中查阅子女的健康能力记录,教师可对已录入数据进行编辑或删除操作。健康能力记录流程图如图4.7所示。

图4.7健康能力记录流程图
4.4 数据库设计
4.4.1 E-R图设计
数据库概念模型设计是将现实业务世界转换为信息化描述的第一次抽象,其目标在于识别系统中的核心数据对象并明确这些对象之间的语义关联,为后续的物理数据库结构提供稳定的逻辑依据。儿童成长档案系统的业务数据关系较为复杂,家长、教师、机构三类角色围绕儿童个体形成多条业务主线,各主线之间在数据层面存在交叉引用。针对这一特点,概念模型设计过程重点关注实体的精确抽象与联系类型的准确判定:用户账户与各角色信息之间存在一对一关联;家长与成长记录、成长追踪之间呈现一对多联系;机构与课程信息、课程资料之间同样为一对多联系;课程信息与订单之间形成一对多的购买关系;订单与订单售后之间存在一对一的售后处理联系;班级儿童与健康能力记录之间构成一对多的管理关系。实体属性的抽取遵循字段完整性原则,确保每个实体的关键业务字段均得到充分体现。综合上述分析,系统共识别出10个核心业务实体,基于这10个实体绘制全局E-R模型,为逻辑模型的转换提供完整的概念依据[20]。全局E-R模型如图4.8所示。
图4.8全局ER图
根据系统分析,系统的主要实体有:用户账户、家长用户、教师用户、机构用户、活动信息、成长记录、健康能力、课程信息、订单、订单售后,各个实体具体的属性如下图所示。
(1)用户账户实体主要包括用户id、账户状态、所在用户组、上次登录时间、手机号码等。如图4.9所示。
图4.9用户账户实体属性图
(2)家长用户实体主要包括家长用户id、儿童性别、儿童生日、儿童姓名、审核状态等。如图4.10所示。
图4.10家长用户实体属性图
(3)教师用户实体主要包括教师用户id、老师姓名、老师性别、老师电话、老师工号等。如图4.11所示。
图4.11教师用户实体属性图
(4)机构用户实体主要包括机构用户id、机构名称、机构电话、审核状态、用户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、课程标题、课程描述、卖价、原价等。如图4.16所示。
图4.16课程信息实体属性图
(9)订单实体主要包括订单id、订单号、商品id、买家id、商家id等。如图4.17所示。
图4.17订单实体属性图
(10)订单售后实体主要包括订单售后id、订单id、订单号、商品id、售后状态等。如图4.18所示。
图4.18订单售后实体属性图
4.4.2 数据库表设计
逻辑设计阶段的任务是将概念模型中的实体、属性与联系转换为关系数据库所支持的表结构形式,完成从抽象模型到可实施数据方案的跨越[21]。在转换过程中,每个实体对应一张数据表,实体的属性映射为表的字段,实体之间的关联通过外键字段在表之间建立引用关系。一对多联系在"多"方表中添加外键字段,指向"一"方的主键;一对一联系在从属方表中添加外键字段。用户账户表作为系统的核心认证基表,家长用户、教师用户、机构用户三张扩展表分别通过user_id字段与其建立关联,实现角色信息与账户信息的分层存储。成长记录、健康能力、活动信息等业务表通过parent_user、teacher_user等外键字段建立角色归属关系,订单表通过goods_id关联课程信息表,订单售后表通过order_id关联订单表,形成完整的业务数据关系网络。本系统数据库中的10张核心业务表的字段设计说明如下。
(1)用户账户表主要是用来存储系统所有用户的登录认证信息。主要包括用户id、账户状态、所在用户组、手机号码等字段。如表4.1所示。
表4.1用户账户表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | user_id | int | 11 | 主键 |
| 2 | state | smallint | 11 | 账户状态 |
| 3 | user_group | varchar | 32 | 所在用户组 |
| 4 | login_time | timestamp | - | 上次登录时间 |
| 5 | phone | varchar | 20 | 手机号码 |
| 6 | username | varchar | 50 | 用户名 |
| 7 | nickname | varchar | 50 | 昵称 |
| 8 | password | varchar | 64 | 密码 |
| 9 | varchar | 100 | 邮箱 | |
| 10 | avatar | varchar | 200 | 头像地址 |
| 11 | create_time | timestamp | - | 创建时间 |
(2)家长用户表主要是用来存储家长的基本信息及其关联儿童信息。主要包括家长用户id、儿童姓名、儿童性别、审核状态等字段。如表4.2所示。
表4.2家长用户表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | parent_user_id | int | 11 | 主键 |
| 2 | child_gender | varchar | 10 | 儿童性别 |
| 3 | childrens_birthday | varchar | 50 | 儿童生日 |
| 4 | childs_name | varchar | 50 | 儿童姓名 |
| 5 | examine_state | varchar | 16 | 审核状态 |
| 6 | user_id | int | 11 | 用户id |
| 7 | create_time | datetime | - | 创建时间 |
| 8 | update_time | timestamp | - | 更新时间 |
(3)教师用户表主要是用来存储教师的基本信息与工号信息。主要包括教师用户id、老师姓名、老师性别、老师电话等字段。如表4.3所示。
表4.3教师用户表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | teacher_user_id | int | 11 | 主键 |
| 2 | teachers_name | varchar | 100 | 老师姓名 |
| 3 | teacher_gender | varchar | 10 | 老师性别 |
| 4 | teacher_telephone | varchar | 20 | 老师电话 |
| 5 | teachers_work_number | varchar | 50 | 老师工号 |
| 6 | examine_state | varchar | 16 | 审核状态 |
| 7 | user_id | int | 11 | 用户id |
| 8 | create_time | datetime | - | 创建时间 |
| 9 | update_time | timestamp | - | 更新时间 |
(4)机构用户表主要是用来存储机构账号的基本信息与审核状态。主要包括机构用户id、机构名称、机构电话、审核状态等字段。如表4.4所示。
表4.4机构用户表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | institutional_users_id | int | 11 | 主键 |
| 2 | name_of_institution | varchar | 100 | 机构名称 |
| 3 | agency_telephone | varchar | 20 | 机构电话 |
| 4 | examine_state | varchar | 16 | 审核状态 |
| 5 | user_id | int | 11 | 用户id |
| 6 | create_time | datetime | - | 创建时间 |
| 7 | update_time | timestamp | - | 更新时间 |
(5)活动信息表主要是用来存储管理员发布的各类活动的详细信息。主要包括活动信息id、活动名称、活动日期、活动地点等字段。如表4.5所示。
表4.5活动信息表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | activity_information_id | int | 11 | 主键 |
| 2 | activity_name | varchar | 100 | 活动名称 |
| 3 | activity_date | date | - | 活动日期 |
| 4 | event_location | varchar | 100 | 活动地点 |
| 5 | activity_description | text | 500 | 活动描述 |
| 6 | cover_image | varchar | 200 | 封面图片 |
| 7 | create_by | int | 11 | 创建用户id |
| 8 | create_time | datetime | - | 创建时间 |
| 9 | update_time | timestamp | - | 更新时间 |
(6)成长记录表主要是用来存储家长为子女录入的成长过程数据。主要包括成长记录id、儿童姓名、记录日期、记录类型等字段。如表4.6所示。
表4.6成长记录表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | growth_record_id | int | 11 | 主键 |
| 2 | parent_user | int | 11 | 家长用户 |
| 3 | childs_name | varchar | 50 | 儿童姓名 |
| 4 | record_date | date | - | 记录日期 |
| 5 | record_type | varchar | 50 | 记录类型 |
| 6 | record_content | text | 500 | 记录内容 |
| 7 | growth_analysis | varchar | 255 | 成长分析 |
| 8 | record_file | varchar | 200 | 记录文件 |
| 9 | create_time | datetime | - | 创建时间 |
| 10 | update_time | timestamp | - | 更新时间 |
(7)健康能力表主要是用来存储教师为儿童录入的健康与能力评估数据。主要包括健康能力id、儿童姓名、记录日期、记录类型等字段。如表4.7所示。
表4.7健康能力表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | health_ability_id | int | 11 | 主键 |
| 2 | teacher_user | int | 11 | 老师用户 |
| 3 | parent_user | int | 11 | 家长用户 |
| 4 | childs_name | varchar | 50 | 儿童姓名 |
| 5 | record_date | date | - | 记录日期 |
| 6 | record_type | varchar | 50 | 记录类型 |
| 7 | record_content | text | 500 | 记录内容 |
| 8 | record_attachments | varchar | 200 | 记录附件 |
| 9 | create_time | datetime | - | 创建时间 |
| 10 | update_time | timestamp | - | 更新时间 |
(8)课程信息表主要是用来存储机构发布的课程商品详情与上架状态。主要包括课程信息id、课程标题、课程描述、卖价等字段。如表4.8所示。
表4.8课程信息表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | course_information_id | int | 11 | 主键 |
| 2 | cart_title | varchar | 125 | 课程标题 |
| 3 | cart_description | varchar | 255 | 课程描述 |
| 4 | cart_price | double | - | 卖价 |
| 5 | cart_price_ago | double | - | 原价 |
| 6 | cart_inventory | int | 11 | 商品库存 |
| 7 | list_status | smallint | 11 | 上架状态 |
| 8 | institutional_users | int | 11 | 机构用户 |
| 9 | create_time | datetime | - | 创建时间 |
| 10 | update_time | timestamp | - | 更新时间 |
(9)订单表主要是用来存储家长购买课程后生成的订单信息。主要包括订单id、订单号、商品id、买家id等字段。如表4.9所示。
表4.9订单表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | order_id | int | 11 | 主键 |
| 2 | order_number | varchar | 50 | 订单号 |
| 3 | goods_id | mediumint | 20 | 商品id |
| 4 | user_id | int | 11 | 买家id |
| 5 | merchant_id | mediumint | 20 | 商家id |
| 6 | price | double | - | 价格 |
| 7 | price_count | double | - | 总价 |
| 8 | num | int | 11 | 数量 |
| 9 | state | varchar | 16 | 订单状态 |
| 10 | delivery_state | varchar | 16 | 发货状态 |
| 11 | create_time | timestamp | - | 创建时间 |
| 12 | update_time | timestamp | - | 更新时间 |
(10)订单售后表主要是用来存储家长提交的售后申请及机构处理结果。主要包括订单售后id、订单id、售后状态、售后类型等字段。如表4.10所示。
表4.10订单售后表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | order_after_sale_id | int | 11 | 主键 |
| 2 | order_id | int | 11 | 订单id |
| 3 | order_number | varchar | 50 | 订单号 |
| 4 | goods_id | mediumint | 20 | 商品id |
| 5 | user_id | int | 11 | 买家id |
| 6 | merchant_id | mediumint | 20 | 商家id |
| 7 | state | varchar | 16 | 订单状态 |
| 8 | after_state | varchar | 16 | 售后状态 |
| 9 | after_state_reply | varchar | 255 | 售后回复 |
| 10 | type | varchar | 255 | 售后类型 |
| 11 | content_desc | varchar | 255 | 售后内容 |
| 12 | create_time | timestamp | - | 创建时间 |
第5章 系统实现效果
5.1 管理员角色功能实现
5.1.1 活动信息管理
活动信息管理模块主要是对平台内所有活动数据进行发布与维护管理。管理员进入该模块后,系统以列表形式加载全部活动记录,每条记录展示活动基本概况,管理员可通过关键词对活动数据进行筛选检索。针对单条活动记录,管理员可选择编辑操作进入详情表单,修改活动相关信息后提交,系统完成数据更新并刷新列表。管理员亦可通过新增按钮进入创建页面,填写活动各项信息后保存,系统将新记录写入数据库。对于需要下线的活动,管理员执行删除操作,系统在二次确认后完成记录移除。活动正式对外展示前,管理员需执行发布操作,系统将活动状态切换为已发布,家长端随即可见该活动。活动信息管理界面如图5.1所示。
图5.1活动信息管理界面
5.3.1 课程资料管理
课程资料管理模块主要是对平台内课程配套资料文件进行统一管理。管理员进入该模块后,系统列表展示已上传的全部课程资料记录,支持按课程名称或机构名称进行条件过滤。管理员可通过上传入口将新的资料文件提交至系统,填写资料基本信息后确认保存,系统完成文件关联与记录写入。对于已上传资料,管理员可进入编辑页面调整资料信息字段并保存变更。查看操作允许管理员浏览资料详情,包括文件链接与课程内容描述。对于不再需要保留的资料记录,管理员执行删除操作,系统在确认后移除该条记录及关联信息。课程资料管理界面如图5.2所示。
图5.2课程资料管理界面
5.1.3 成长记录管理
成长记录管理模块主要是对家长提交的儿童成长记录进行审核与互动管理。管理员进入该模块后,系统以时间倒序方式加载全部成长记录,管理员可按儿童姓名或记录类型对数据进行筛选。针对具体记录,管理员可查看记录完整内容,包括文字描述、附件资料等信息。系统提供评论功能,管理员可针对记录内容提交评论,评论保存后在对应记录下方显示,家长端同步可见。对于内容不符合规范的成长记录,管理员可执行删除操作,系统在确认后清除该记录。该模块的操作结果直接影响家长在小程序端所见的记录状态。成长记录管理界面如图5.3所示。
图5.3成长记录管理界面
5.1.4 留言管理
留言管理模块主要是对用户在平台留言板提交的留言信息进行处理与维护。管理员进入该模块后,系统展示全部用户留言列表,每条留言显示发布者信息与提交时间,管理员可通过关键词检索定位特定留言内容。针对待回复留言,管理员在详情页输入回复内容并提交,系统将回复内容写入对应留言记录,留言状态更新为已回复。对于已处理或内容违规的留言,管理员执行删除操作,系统确认后移除该条记录。管理员的回复内容在前台留言板中对所有用户公开展示,体现平台对用户反馈的响应态度。留言管理界面如图5.4所示。
图5.4留言管理界面
5.2 教师角色功能实现
5.2.1 日程管理
日程管理模块主要是对教师个人工作计划进行记录与维护。教师进入该模块后,系统以列表形式展示当前账号下的全部日程记录,显示计划时间与日程内容摘要。教师可通过新增操作打开日程创建表单,录入日程内容与计划执行时间后保存,系统将记录与当前教师账号关联写入数据库。对于需要调整的日程,教师进入编辑页面修改字段内容并提交,系统完成数据更新。查看操作允许教师浏览日程的完整内容描述。对于已完成或作废的日程记录,教师执行删除操作,系统在二次确认后完成清除。日程管理界面如图5.5所示。
图5.5日程管理界面
5.2.2 班级儿童管理
班级儿童管理模块主要是对教师所管辖班级内的儿童档案信息进行维护。教师进入该模块后,系统加载当前教师账号关联班级的全部儿童记录,可按儿童姓名或班级名称进行筛选查询。教师通过新增操作录入儿童基本信息,包括儿童姓名、班级归属、座位编号及关联家长账号,提交后系统完成记录创建。对于已有儿童记录,教师可进入编辑页面调整信息字段,确认后系统更新对应数据。查看操作支持教师浏览儿童的详细档案与备注内容。对于需要从班级移除的儿童,教师执行删除操作,系统确认后清除该条班级记录。班级儿童管理界面如图5.6所示。
图5.6班级儿童管理界面
5.2.3 通知记录管理
通知记录管理模块主要是对教师面向家长发布的通知信息进行发布与跟踪管理。教师进入该模块后,系统展示当前账号下已发布的全部通知列表,按通知日期倒序排列。教师通过发布操作填写通知标题、内容及通知日期,提交后系统将通知记录写入数据库并与关联家长建立推送关系。对于发布后需要调整的通知,教师进入编辑页面修改内容后保存,系统更新对应记录字段。查看操作允许教师查阅通知详情与发送对象信息。对于已过期或错误发布的通知,教师执行删除操作,系统在确认后移除该记录。通知记录管理界面如图5.7所示。
图5.7通知记录管理界面
5.2.4 健康能力管理
健康能力管理模块主要是对儿童的健康状态与能力发展数据进行记录与管理。教师进入该模块后,系统以列表形式展示当前账号下已录入的全部健康能力记录,支持按儿童姓名或记录类型筛选。教师通过记录操作进入填写页面,选择儿童姓名并录入记录日期、记录类型、评估内容,可附加相关文件,提交后系统完成数据写入并关联至对应儿童与家长账号。对于已录入的数据,教师可进入编辑页面调整评估内容并保存更新。查看操作支持浏览完整评估记录,教师可对不准确的记录执行删除操作。健康能力管理界面如图5.8所示。
图5.8健康能力管理界面
5.3 机构角色功能实现
5.3.1 课程资料管理
机构端课程资料管理模块主要是对机构自有课程配套资料进行发布与维护。机构用户登录后进入该模块,系统展示本机构已上传的全部课程资料记录,可按课程名称筛选。机构通过上传操作提交资料文件,填写课程名称、资料描述及文件链接后确认保存,系统完成记录创建并关联至机构账号。已上传资料支持通过编辑操作调整关联课程名称与资料内容描述,修改后系统更新对应字段。机构可通过查看操作浏览资料详情,包括关联课程与文件访问链接。对于不再使用的资料,机构执行删除操作,系统在确认后清除记录。机构课程资料管理界面如图5.9所示。
图5.9机构课程资料管理界面
5.3.2 答疑提问管理
答疑提问管理模块主要是对家长针对机构课程提交的提问进行回复与处理。机构用户进入该模块后,系统展示全部待回复与已回复的提问列表,按提问日期倒序排列。机构在查看提问详情后,通过回复操作录入回复内容并提交,系统将回复写入对应提问记录并更新回复状态。已回复的提问在列表中以标识区分显示,家长可在小程序端查看机构的回复内容。对于内容不当的提问,机构执行删除操作,系统在确认后移除该条记录。该模块支持机构与家长之间围绕课程内容进行有效的双向信息传递。答疑提问管理界面如图5.10所示。
图5.10答疑提问管理界面
5.3.3 课程信息管理
课程信息管理模块主要是对机构发布的在售课程进行生命周期管理。机构用户进入该模块后,系统展示本机构下所有课程记录,包含上架状态标识,支持按课程标题筛选查询。机构通过发布操作填写课程标题、描述、价格、库存等信息并上传封面图,提交后系统将课程状态设为已上架,家长端随即可见该课程。对于需要调整的课程,机构进入编辑页面修改课程信息后保存更新。查看操作支持机构预览课程在家长端的展示效果。对于需要临时停止销售的课程,机构执行下架操作,系统将课程状态切换为下架,家长端不再展示该课程。课程信息管理界面如图5.11所示。
图5.11课程信息管理界面
5.3.4 订单售后管理
订单售后管理模块主要是对家长提交的售后申请进行审核与处理。机构用户进入该模块后,系统展示本机构商品所产生的全部订单列表,机构可查看订单的基本信息与当前状态。当家长提交售后申请后,对应订单在列表中以售后标识显示,机构进入售后详情页查看申请内容与凭证图片。机构在审核后选择通过或拒绝操作,录入处理意见并提交,系统更新订单售后表中的售后状态字段与回复内容。处理结果同步至家长的小程序订单页面,家长可查看机构的审核意见与处理结论。订单售后管理界面如图5.12所示。
图5.12订单售后管理界面
5.4 家长角色功能实现
5.4.1 活动信息
活动信息模块主要是为家长提供活动浏览与报名操作的完整服务入口。家长在微信小程序端进入活动页面后,系统加载当前全部已发布活动并以卡片列表形式展示。家长点击目标活动卡片后进入详情页面,查看活动日期、地点、描述等完整信息。详情页提供报名入口,家长提交报名后系统记录报名关系并向家长返回操作结果。对于已报名的活动,家长可在同一入口取消报名,系统在收到取消请求后更新报名状态。活动的展示数据来源于管理员后台的发布操作,家长端实时同步最新活动信息。活动信息界面如图5.13所示。

图5.13活动信息界面
5.4.2 我的订单
我的订单模块主要是对家长在平台购买课程后产生的订单记录进行查阅与管理。家长进入该模块后,系统展示当前账号下的全部订单列表,按创建时间倒序排列,各订单显示当前所处的状态节点。家长点击订单条目进入详情页,可查看课程信息、价格明细、联系人信息及物流状态等完整内容。对于尚未付款的订单,家长可执行取消操作并填写取消原因,系统更新订单状态。对于已签收但存在问题的订单,家长通过申请售后入口填写售后类型、问题描述并上传凭证,系统将申请数据写入订单售后表并通知机构侧处理。我的订单界面如图5.14所示。

图5.14我的订单界面
5.4.3 成长记录
成长记录模块主要是对家长记录子女日常成长过程数据提供完整的操作支持。家长进入该模块后,系统展示当前账号下已提交的全部成长记录列表,支持按记录类型或时间段过滤查看。家长通过新增操作进入记录填写页面,录入儿童姓名、记录日期、记录类型与记录内容,并可上传视频或文件附件,提交后系统完成数据写入。已有记录支持通过编辑操作调整内容字段,修改后系统更新对应记录。查看操作支持家长浏览记录完整内容及管理员评论。对于不需要保留的记录,家长执行删除操作,系统在确认后清除该条数据。成长记录界面如图5.15所示。

图5.15成长记录界面
5.4.4 知识资源
知识资源模块主要是为家长提供课程资料的浏览、下载与收藏服务。家长进入该模块后,系统展示全部可供查阅的知识资源列表,支持按课程名称或机构名称筛选资源内容。家长点击资源条目进入详情页面,查看资源描述与相关课程说明,详情页提供文件下载入口,家长发起下载请求后系统返回文件访问链接。对于希望长期保存的资源,家长可执行收藏操作,系统将该资源记录至家长账号的收藏列表中,方便后续快速检索。收藏数据存储于系统收藏表,与家长账号建立关联关系。知识资源界面如图5.16所示。

图5.16知识资源界面
第6章 系统测试
6.1 测试目的
软件测试是系统上线前保障功能正确性的必要环节,贯穿于功能验证与质量评估的全过程。本系统的测试目标集中于验证各业务模块的功能实现是否与需求分析阶段的规格说明相符,重点检验多角色权限隔离机制的有效性、业务数据在角色间流转的一致性,以及关键操作节点的边界条件容错处理是否达到预期。系统涵盖管理员、教师、机构、家长四类角色,各角色的操作路径相互独立,测试过程需覆盖各角色的典型操作场景,确认数据写入、更新、删除在不同操作序列下均能产生正确的系统响应。对系统交互准确性与功能模块闭环的验证,是降低上线风险的核心手段[22]。
6.2 测试过程及结果
本节针对系统中7个核心业务模块设计测试用例,验证各模块在典型操作场景下的功能正确性与数据处理逻辑的准确性。
活动信息管理模块测试的目标是验证管理员对活动数据的发布与维护操作能否正确执行,重点关注活动状态在新增、发布、删除操作后的数据库变更情况及前台展示的同步响应。如表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+微信小程序技术栈,构建面向学前教育的多角色协同成长档案管理平台。支持管理员、教师、机构和家长四类用户,实现活动管理、成长记录、健康能力评估、课程购买、答疑互动等核心功能。采用前后端分离架构,MySQL存储结构化数据,通过角色权限隔离保障数据安全与业务边界。系统具备良好的可扩展性与部署可行性,适用于中小幼教机构信息化建设。

762

被折叠的 条评论
为什么被折叠?



