第一章 绪论
1.1 研究背景与意义
高校志愿服务活动中的传统模式依靠线下海报通知、纸质表格登记和人工汇总工时，组织者花费大量的时间去处理报名信息和考勤记录，信息传递是单向的，并且数据分散在各个部门里，志愿者不能及时得到活动变更的通知，工时统计容易出现错误并且难以追溯，低效的运作限制了志愿服务规模的扩大以及质量的提高1。随着校园信息化建设的不断推进，部分高校开始使用办公软件或者简单的网站发布活动信息，信息获取的速度得到了一定的提高，但是活动报名、签到签退、工时认定等主要环节仍然处在半手工的状态中，数据孤岛现象严重，各个环节之间没有形成有效的联动，现有的方式不能满足学生群体对于便捷参与、透明记录和即时反馈的要求2。开发出一个包含活动发布、在线报名、签到签退和工时管理等功能的志愿者系统，可以将组织者从繁杂的事务性工作当中解放出来，提高信息传递的效率和数据的准确性，促进志愿服务流程的规范化，也可以为校园其他社团活动的信息化管理提供一定的参考路径。
1.2 国内外研究现状
国内志愿服务管理平台发展是由信息化萌芽到移动端普及的过程。早期的高校主要依靠校园BBS或者二级网站发布志愿活动的通知，志愿者通过电子邮件或者线下提交报名表的方式进行报名，系统功能简单、互动性差3。伴随着互联网技术进入校园，一些高校开始创建独立的学生工作管理系统，把志愿服务当作子系统嵌入其中，从而达成报名信息的电子化记载，不过各个模块之间数据无法互相共享，活动种类管理、签到签退功能欠缺，实际使用时操作繁杂且响应迟缓4。2010年以前，以志愿北京、志愿深圳等为代表的区域性志愿服务平台相继建立起来，集活动发布、志愿者注册、工时认证等功能于一身，促进了志愿服务管理的规范化5。移动互联网时代，以微信公众号、小程序为主的轻量化应用为主流，活动推送、报名更加方便，但是签到、签退环节仍然需要人工核验，不能有效地防止代签、漏签的现象，工时记录的透明性也面临着挑战6。目前我国校园志愿服务管理正向全流程闭环发展，怎样把活动发布、在线报名、地理位置签到、签退审核和工时统计等环节有机结合起来，就成为相关系统设计和优化的主要方向7。
国外志愿服务平台发展较早就形成了社区化、数据化的特征。以VolunteerMatch、Idealist为代表的综合性平台，给志愿者提供按照地理位置和兴趣爱好来搜索活动的便捷服务，用户可以在线完成注册和参与记录，平台拥有大量的非营利组织合作经验8。部分高校采用了专门为教育机构设计的志愿服务管理工具GivePulse，可以对活动进行发布、团队合作、工时认证以及数据报告的生成，并且可以和学校教务系统、学生事务系统无缝对接，使志愿者经历同学分认定、评优评奖自动挂钩9。欧洲国家对于志愿服务信息化的建设更加重视数据隐私保护以及流程的标准化，在相关的系统当中，大多会采取严格的认证手段来保证签到签退的真实性，而且会依照ISO国际标准来规定工时记录的格式10。近些年来，以区块链技术为基础的志愿服务记录系统开始出现，用去中心化的存储以及时间戳技术来保证服务数据的不可篡改和永久可追溯11。国外的研究还关注到志愿服务同社区可持续发展相结合，系统的设计不只是为了提高管理效率，而且重视对志愿者参与动机的激发以及社群归属感的培养，这种理念给国内同类系统改进给予了参照12。
1.3 主要研究内容
本课题主要研究开发一个面向高校的志愿者管理系统，该系统主要针对高校内服务的两种主要角色即志愿者和管理员。研究内容就是对系统的整体需求进行分析，给出系统的总体架构，按照功能模块进行分块，完成数据库的设计工作，最终进行系统的实现，并做系统测试。技术路线为前后端分离的B/S架构，前端用Vue框架实现交互界面，后端用Spring Boot框架提供RESTful API服务，MySQL数据库做数据持久化存储。志愿者端具有浏览活动、在线报名、签到签退三个主要功能，管理员端可以对志愿活动进行管理、活动类型进行管理、报名审核进行管理、签到记录进行管理、签退记录进行管理。系统重点解决传统模式下信息传递迟缓、考勤数据容易出错、工时统计不明等问题，用二维码扫码加地理位置双重核验来保证签到签退的真实性，从而达到志愿服务全过程闭环管理的目的。
第二章 相关技术介绍
2.1 Spring Boot框架
Spring Boot框架是基于Spring生态系统创建的，依靠自动化的配置以及起步依赖来大大减少传统Spring应用搭建的复杂程度。该框架采用的是约定优于配置的设计理念，开发者只需要引入相应的场景starter依赖，框架就会自动装配出所需要的Bean实例以及基础配置，使得开发者可以专注于业务逻辑的实现，而不会被繁杂的XML配置文件所困扰13。从运行机制上讲，Spring Boot内建有Tomcat、Jetty这些Servlet容器，应用打包成可独立运行的JAR文件之后就可以直接启动，省去外部应用服务器的部署工作。框架核心包含自动配置模块、启动器模块、Actuator监控模块和CLI命令行工具，自动配置模块根据扫描到的类路径下的依赖库以及条件注解来决定配置类是否被加载，从而达到按需装配的效果。Spring Boot框架是本系统后端服务的主要支撑，它创建了RESTful接口层、数据访问层和业务逻辑层的整合，使用声明式的事务管理和依赖注入，有效地降低模块之间的耦合度，使代码结构清晰，容易维护。
2.2 Vue.js框架
Vue.js是渐进式的JavaScript框架，它的主要作用就是视图层的构建，使用响应式数据绑定和组件化开发来提高前端开发效率。框架内部使用虚拟DOM技术来提高真实DOM操作的性能，当数据发生变化的时候，Vue的响应式系统会收集依赖并执行异步更新队列，只对变化的部分进行最小化重绘和重新渲染。组件系统把页面拆分成独立的、可以复用的单元，每个组件都包含自己的模板、样式和逻辑，父子组件之间使用props属性传递数据，使用自定义事件进行子父组件之间的通信，单向数据流模式使得状态的变化具有可预见性。开发者工具中包含的扩展程序可以给用户提供组件树的查看功能，状态追踪以及性能分析等，进而帮助用户调试并改善。本系统前端界面使用Vue框架搭建单页应用，页面路由使用Vue Router进行管理，状态管理使用Vuex实现多组件间数据共享，志愿者端和管理员端分别建立独立模块，用户操作不需要频繁刷新页面就能得到即时响应体验14。
2.3 MySQL数据库
MySQL属于关系型数据库管理系统，用多线程架构来处理客户端的连接请求，每一个连接都会得到一个独立的线程去执行SQL语句，并且会得到结果集。存储引擎方面，InnoDB引擎具有事务ACID特性、行级锁和外键约束，用聚簇索引来组织数据存储，主键索引的叶子节点直接存放完整的行记录，辅助索引只存储主键值，这样的索引结构在范围查询和写入操作中比较高效。查询优化器接收到SQL语句之后，就会对它展开语法解析、语义检查以及执行计划的产生工作，然后依据表统计信息以及索引的选择方式来选定最合适的访问途径，从而保证数据被检索的速度。日志系统包含二进制日志、错误日志、慢查询日志和中继日志，二进制日志保存所有的数据变更操作，为主从复制以及数据恢复奠定基础15。本系统中志愿者信息、活动记录、报名申请、签到签退数据都保存在MySQL数据库里，采用合理的表结构和索引来保证多用户并发操作下数据的一致性、完整性。
2.4 前后端分离架构
前后端分离架构把用户界面和业务逻辑分成两个独立的部署单元，前端应用负责界面呈现和用户交互，后端服务用RESTful接口暴露数据操作能力，两者之间用JSON格式进行数据交换。该架构中前端应用运行在浏览器环境中，使用Ajax或者Fetch API发起异步请求，不需要重新加载整个页面就可以获取或者提交数据，后端服务收到请求之后完成业务处理并返回结构化的响应，双方只通过接口契约进行通信。部署上，前端静态资源可以托管在Nginx服务器或者对象存储服务上，后端应用独立运行在应用服务器上，两者可以根据访问压力进行水平扩展。此种分离模式使得前后端的开发工作可以同时进行，前端开发人员完成交互逻辑和视觉展示，而后端开发人员实现业务规则和数据安全的技术选择具有灵活性。本系统采用这种架构组织，前端Vue应用和后端Spring Boot服务通过定义明确的API接口来实现数据交互，前端界面独立构建和部署，后端服务集中处理业务逻辑和数据存取，系统整体具有较好的可维护性和扩展性16。
第三章 系统分析
3.1 功能需求分析
3.1.1 志愿者功能
志愿者在系统中可以执行的活动有浏览志愿活动列表、根据类型筛选活动、查看活动详细信息、提交活动报名申请、在活动时间段内签到、在活动结束后签退、查看个人已报名活动记录、查询个人历史参与活动和累计工时。志愿者角色用例图如下图3-1所示。
图3-1志愿者用例图
3.1.2 管理员功能
管理员在系统中可以执行的操作有新增志愿活动、修改已发布的活动信息、取消或停用活动、管理活动类型目录、审核志愿者报名申请、处理报名退回、查看签到记录列表、为异常情况手动补录签到数据、查看签退记录列表、为异常情况手动补录签退数据、导出各活动参与名单和工时统计报表。管理员角色用例图如图3-2所示。
图3-2管理员用例图
3.2 可行性分析
3.2.1 市场可行性
高校志愿服务组织过程中，活动发布不及时、报名信息分散、工时统计容易出错等现象，在各个高校社团的管理实践当中普遍存在。目前大部分校园社团仍然依靠QQ群、微信群发布通知，用在线文档或者纸质表格收集报名信息，签到环节由现场工作人员手工核对名单，这种方式效率低、易出错。部分高校虽然引进了学生工作管理系统，但是志愿服务模块的功能比较基础，缺少签到签退的验证以及工时的自动统计。本系统把活动发布、在线报名、签到签退、工时记录等环节整合成一个完整的闭环，针对目前存在的管理方式的痛点进行有针对性的解决，在高校社团信息化方面有应用前景。因此系统在市场方面是可行的。
3.2.2 社会可行性
系统设计和开发过程中严格遵守《中华人民共和国网络安全法》以及有关个人信息保护的规定，所有的用户数据只在系统内部使用，不会向第三方传输。志愿者姓名、学号、联系方式等个人信息只用作身份认证和工时记录，系统管理员根据业务需要可以访问有关数据，操作日志记录重要的操作行为以便审计。系统投入使用以后，志愿活动组织效率提高，志愿者参与体验改善，工时记录透明度提高，有利于营造公平、规范的志愿服务环境。签到签退环节的地理位置验证会引发部分用户对于位置信息隐私的担忧，系统在第一次调用定位功能的时候向用户做出提示并得到用户的同意，用户也可以选择关闭定位后由管理员手动补录。因此系统在社会上是可行的。
3.2.3 经济可行性
项目投入主要是开发阶段的人力成本，开发人员使用现有的个人计算机设备来完成编码、测试、部署等工作所必需的专用服务器或者开发硬件。后端框架和前端框架都是开源的，数据库使用的是社区版MySQL，开发工具使用的是免费的集成开发环境。系统运行过程中只占用本地计算机的资源，不需要支付云服务器租赁费用或者域名年费。系统投入使用以后，缩减管理人员参加活动组织和工时统计所耗费的时间，削减纸质表格印刷和人工核验的成本，投入和价值存在正相关关系。因此系统在经济上是可行的。
第四章 系统设计
4.1 系统架构设计
系统使用前后端分离的模块化设计，把界面展示、业务逻辑和数据存储分开。用户通过浏览器访问前端页面，Vue框架渲染视图，捕捉用户的交互行为，交互数据使用Axios库异步请求到后端接口。Spring Boot框架搭建的RESTful API接收到请求之后，Controller层执行参数校验和路由分发，Service层封装核心业务规则，对活动发布、报名审核、签到签退等操作进行处理，数据访问层使用MyBatis与MySQL数据库交互，对志愿者信息、活动记录、考勤数据进行持久化存储。各个层次之间通过接口契约进行通信，上层调用下层提供的服务，下层不知道上层具体的实现，分层结构可以降低代码耦合度，方便以后的功能扩展和维护17。系统整体架构由交互入口到数据落地形成闭环，组织形式如图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 数据库设计
数据库使用关系型数据模型，用规范的第三范式对数据表结构进行规范化处理，防止出现数据重复、更新不一致等现象18。系统开发过程中用主键、外键约束来保证数据的完整性，用事务机制保证多表操作的一致性。志愿者信息、活动记录、报名申请、签到签退数据分别存放在对应表里，表之间通过关联字段来建立逻辑联系，查询的时候用索引来提高检索速度，数据存储结构既保证业务操作方便又保证数据维护可靠19。
4.4.1 概念设计
志愿者实体有志愿者姓名、志愿者手机、审核状态等属性。志愿者实体属性图如图4-8所示。
图4-8志愿者实体属性图
用户账户实体主要是用户名、密码、手机号码、用户状态等属性。用户账户实体属性图如下图4-9所示。
图4-9用户账户实体属性图
志愿活动实体由活动标题、活动类型、活动时间、活动地点、负责人等组成。志愿活动实体属性图如下图4-10所示。
图4-10志愿活动实体属性图
活动类型实体主要是类型名称属性。活动类型实体属性图如图4-11所示。
图4-11活动类型实体属性图
活动报名实体主要是包含报名编号、活动标题、志愿者姓名、志愿者手机、审核状态等属性。活动报名实体属性图如图4-12所示。
图4-12活动报名实体属性图
活动签到实体主要是包含活动标题、志愿者姓名、签到时间、签到备注等属性的结构。活动签到实体属性图如图4-13所示。
图4-13活动签到实体属性图
活动签退实体包含活动标题、志愿者姓名、签退时间、活动时长、活动心得等属性。活动签退实体属性图如图4-14所示。
图4-14活动签退实体属性图
系统E-R图如图4-18所示。
图4-18系统E-R图
4.4.2 数据库表设计
用户账户表主要是用来存储系统用户的登录凭证和基本信息。用户名、密码、手机号码、用户状态等。如表4-1所示。
表4-1用户账户表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | user_id | int | 11 | 是 | 是 | 用户ID |
| 2 | username | varchar | 16 | 是 | 否 | 用户名 |
| 3 | password | varchar | 64 | 是 | 否 | 密码 |
| 4 | phone | varchar | 11 | 否 | 否 | 手机号码 |
| 5 | state | smallint | - | 是 | 否 | 账户状态 |
志愿者表主要用来存储志愿者个人的详细信息。主要包含志愿者姓名、志愿者手机号码、审核状态、关联用户ID等字段。如表4-2所示。
表4-2志愿者表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | volunteers_id | int | 11 | 是 | 是 | 志愿者ID |
| 2 | name_of_volunteer | varchar | 64 | 否 | 否 | 志愿者姓名 |
| 3 | volunteer_mobile_phone | varchar | 16 | 否 | 否 | 志愿者手机 |
| 4 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 5 | user_id | int | 11 | 是 | 否 | 用户ID |
志愿活动表主要是用来保存志愿活动的详细情况以及发布信息。主要是活动名称、活动类别、活动时间、活动地点、负责人等。表4-3为数据。
表4-3志愿活动表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | voluntary_activities_id | int | 11 | 是 | 是 | 志愿活动ID |
| 2 | activity_title | varchar | 64 | 是 | 是 | 活动标题 |
| 3 | activity_type | varchar | 64 | 否 | 否 | 活动类型 |
| 4 | activity_time | varchar | 64 | 否 | 否 | 活动时间 |
| 5 | activity_location | varchar | 64 | 否 | 否 | 活动地点 |
活动类型表主要用以维护志愿活动的分类目录。主要由类型名称、分类等组成。见表4-4。
表4-4活动类型表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | activity_type_id | int | 11 | 是 | 是 | 活动类型ID |
| 2 | activity_type | varchar | 64 | 否 | 否 | 活动类型 |
活动报名表是记录志愿者提交的报名申请以及审核结果的表格。主要是报名编号、活动名称、志愿者姓名、志愿者手机、审核状态等。表4-5为结果。
表4-5活动报名表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | event_registration_id | int | 11 | 是 | 是 | 活动报名ID |
| 2 | registration_number | varchar | 64 | 否 | 否 | 报名编号 |
| 3 | activity_title | varchar | 64 | 否 | 否 | 活动标题 |
| 4 | name_of_volunteer | varchar | 64 | 否 | 否 | 志愿者姓名 |
| 5 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
活动签到表主要是用来保存志愿者参加活动时签到的详细信息。主要包含活动标题、志愿者姓名、签到时间、签到备注等内容。表4-6为数据。
表4-6活动签到表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | event_check_in_id | int | 11 | 是 | 是 | 活动签到ID |
| 2 | activity_title | varchar | 64 | 否 | 否 | 活动标题 |
| 3 | name_of_volunteer | varchar | 64 | 否 | 否 | 志愿者姓名 |
| 4 | check_in_time | datetime | - | 否 | 否 | 签到时间 |
| 5 | sign_in_remarks | text | 65535 | 否 | 否 | 签到备注 |
活动签退表主要用来保存志愿者的签退操作以及工时计算的结果。主要包含活动标题、志愿者姓名、签退时间、活动时长、活动心得等字段。见表4-7。
表4-7活动签退表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | activity_check_in_id | int | 11 | 是 | 是 | 活动签退ID |
| 2 | activity_title | varchar | 64 | 否 | 否 | 活动标题 |
| 3 | name_of_volunteer | varchar | 64 | 否 | 否 | 志愿者姓名 |
| 4 | sign_off_time | datetime | - | 否 | 否 | 签退时间 |
| 5 | activity_duration | double | - | 否 | 否 | 活动时长 |
第五章 系统实现
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.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.2.5 活动签退管理功能实现
签退管理模块显示志愿者的签退记录以及工时计算的结果，管理员可以查看各个活动的签退完成情况。对没有在签退时间段内完成操作的志愿者，管理员可以根据实际参与情况进行手动补录签退数据。活动签退管理界面如图5-9所示。
图5-9活动签退管理界面
第六章 系统测试
6.1 测试目的
系统测试是对校园志愿者管理系统进行测试，检验校园志愿者管理系统的设计是否合理、正确，各个功能模块是否能够正常工作。测试过程中主要对志愿者端的活动浏览、报名申请、签到签退等操作是否顺畅进行考察，管理员端的活动管理、报名审核、数据管控等功能是否稳定可靠。通过测试发现潜在的缺陷并及时进行修复，保证系统上线之后可以支撑真实的业务场景，给用户带来稳定的使用体验。
6.2 测试方法
本次测试使用黑盒测试法，按照系统功能需求设计测试用例，主要对志愿者和管理员两个角色的关键业务操作进行测试20。测试人员以真实的用户为角色，模拟用户在活动浏览、报名提交、签到签退、审核管理等各个功能上的行为，对系统的响应情况进行验证，看是否符合要求。根据异常输入、边界条件设计负向测试用例，考察系统的容错能力，保证错误出现时给出合理的提示。
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签到签退记录管理测试用例表
| 测试项 | 测试目的 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| 签到记录查询 | 验证按条件筛选签到记录 | 按活动或志愿者查询签到 | 显示符合条件的签到记录 | 符合预期 |
| 签到手动补录 | 验证异常情况下补录功能 | 对未签到志愿者手动补录 | 新增签到记录，状态正常 | 符合预期 |
| 签退记录导出 | 验证工时数据导出功能 | 选择活动后导出签退记录 | 生成包含工时数据的文件 | 符合预期 |
测试结论
经过系统的功能测试，所选的7个主要业务模块的测试用例全部通过。活动浏览模块可以正确显示活动列表并支持类型筛选，活动报名过程中申请提交、审核反馈功能均能正常工作。活动签到、签退模块对于时段校验、工时计算逻辑处理无误，没有出现异常操作绕过验证的情况。志愿活动管理模块中信息发布和修改操作后数据同步准确，报名管理模块审核结果可以实时反馈给志愿者端。签到签退记录管理的查询和补录功能符合预期，各个模块的结果与预期结果一致。