springboot高校财务报账系统13745-计算机课程设计、毕业设计

第一章 绪论

1.1 研究背景与意义

　　高校财务报账一直依靠线下填单和人工传递，教职工拿着纸质单据多次往返财务部门，财务人员面对堆积的报销凭证一个一个地审核。由于单向滞后造成的报账周期变长、经费使用状态不能及时同步、信息不对称现象明显[1]。部分高校采用电脑化记账或者早期的财务系统之后，报账申请由线下转移到线上，信息获取的速度有所提高。但是碎片化的操作体验仍然存在，报账指南分布在不同的页面上，审批进度的反馈较晚，教职工不能及时了解复审的情况。经费额度和报销记录没有形成联动关系，财务人员对预算执行情况的把控存在滞后性。现有的模式不能满足教职工对于报账透明度、审批速度和经费实时查询的要求[2]。开发出一套专门的财务报账系统，可以整合报账申请、审批流转和经费管理的过程，减少人工干预环节，提高信息传递的速度。系统对于高校财务流程的规范化起到直接的推动作用，也给同类行政服务系统的建设提供了一个可以借鉴的范例。

1.2 国内外研究现状

　　国内高校财务信息化建设由最初的单机记账发展到现在的网络化报销。早期的校园财务系统是以会计核算为主，报账业务仍然需要线下提交纸质单据。部分高校建立了网上预约报账平台，教职工线上填报申请之后打印报销单，财务人员通过扫描凭证进入到工作流。该类系统虽然可以一定程度上缩短排队等候时间，但是审批节点之间数据同步仍然依靠人工操作[3]。随着业务流程管理技术被引入到高校当中，报销申请和经费控制就变成了一个系统，可以检测预算余额并发出警报提醒。但是不同的高校财务规范存在较大的差异，现有的产品无法形成统一的模板，定制开发的成本很高[4]。移动端报账应用渐渐普及，教职工通过微信或者专用的APP提交申请，财务人员在手机端进行初审。但是移动端的功能主要是申请提交和状态查看，复杂的审批逻辑和经费调整还要回到PC端来处理[5]。部分高校用工作流引擎来重新设计报销流程，使得多级复审可以自动流转，并且有退回重审的机制。减少了由于人为干预造成的延误，但是系统和财务核算软件之间的接口标准还没有统一，数据孤岛问题仍然存在[6]。国内研究大多集中于报账效率的提高、用户体验的改善，但是对于经费预算实时控制、多角色协同审批深度整合等还没有达到要求[7]。

　　国外的高校财务管理系统大多会把成熟的商业ERP系统嵌入其中，报销流程同采购、预算、总账等模块相联系[8]。教职工通过统一门户提交报销申请，系统根据经费类型自动分派到相应的审批人手中。审批通过之后报销数据就会直接写入财务模块，不需要人工再录入一次。部分高校实行无纸化报销，发票用OCR技术识别后与电子凭证关联起来，系统内置的规则引擎可以对重复报销、超预算申请进行检测。该模式大大减轻了财务审核的工作量，但是系统的实施成本很高，中小规模的院校无法承担[9]。社区开源财务系统在一些国外高校中得到了应用，学校按照自身需要来制定报销流程和审批层次。开源方案优点是灵活可控，但是长期维护依靠校内技术团队，功能更新速度慢[10]。国外的研究还对报销行为的分析进行研究，从历史的报销记录中找出异常的支出模式来辅助财务部门改进经费的分配方式。数据驱动的管理方式还没有在国内高校大范围地推行[11]。国外高校的移动报销也已经普及，部分系统可以实现拍照上传票据并自动提取信息，审批人可以通过邮件或者应用内通知完成远程签批。国外系统对于报销流程的自动化以及财务数据的集成比较成熟，但是针对中国高校特有的科研经费管理和政府会计制度的匹配度不高[12]。

1.3 主要研究内容

　　本课题设计并实现高校财务报账系统，面向教职工、财务人员、管理员这三个角色，包括报账申请、审批流转、经费控制和信息发布等各个环节。系统采用前后端分离架构，前端用Vue框架，后端用SpringBoot，数据库用MySQL。研究内容有需求分析、总体架构设计、功能模块划分、数据库设计、系统实现、测试。主要解决报账进度实时追踪、经费额度自动核对、复审意见及时反馈、打款状况公开等实际问题，最终得到一个功能完备、流程明晰的财务报账管理平台。

第二章 相关技术介绍

2.1 Spring Boot框架

　　Spring Boot作为基于Spring生态的快速应用开发框架，采用“约定优于配置”的设计理念，内置Tomcat、Jetty等嵌入式Servlet容器。开发者不需要手动部署WAR文件，只需要在主类上加上SpringBootApplication注解就可以启动独立的应用。框架自动配置机制根据项目依赖的JAR包推断默认行为，例如检测到spring-webmvc依赖后自动注册DispatcherServlet与相关Bean。启动过程中，Spring Boot通过SpringFactoriesLoader机制加载各模块下的META-INF/spring.factories文件，完成自动配置类的条件化装配。条件注解如ConditionalOnClass、ConditionalOnMissingBean控制配置类生效时机，允许开发者通过配置文件或自定义Bean覆盖默认设定[13]。该框架在本系统中担负业务逻辑处理和请求响应控制的任务，接收前端Vue发出的HTTP请求之后，控制器层对参数进行解析并调用服务层来执行报账申请校验、经费额度计算以及审批状态更新等任务，最后将结果以JSON格式返回给前端展示。

2.2 Vue.js框架

　　Vue.js是基于虚拟DOM的渐进式JavaScript框架，主要的库集中在视图层上，用响应式数据绑定和组件化的方式来达到用户界面的快速更新。每个Vue实例初始化时遍历data对象属性，使用Object.defineProperty方法为每个属性添加getter与setter。数据变化触发setter通知依赖收集器，框架异步执行视图更新队列，把真实的DOM操作批量转换成不同的补丁应用。组件系统可以将页面拆分成独立的、可以复用的模块，每个组件都有自己的模板、逻辑和样式，父组件通过props向下传递数据，子组件通过自定义事件向上发送消息。生命周期钩子函数可以在组件创建、挂载、更新、销毁的时候对组件进行拦截[14]。本系统中，Vue主要完成报账申请表单渲染、审批进度实时更新、经费信息动态显示等前端交互工作，使用axios库和后端Spring Boot接口进行异步数据交换，防止整个页面重载。

2.3 MySQL数据库

　　MySQL使用的是客户端/服务器架构，服务进程对SQL语句进行解析、优化查询计划，并管理底层的存储引擎。InnoDB为默认的存储引擎，可以实现事务的ACID特性，依靠重做日志、回滚日志来达到数据持久性以及一致性。查询处理阶段解析器产生抽象语法树，优化器根据统计信息和代价模型来选择索引扫描或者全表扫描的执行方式。缓冲池机制把经常被访问的数据页和索引页存放在内存里，从而降低磁盘I/O的开销。行级锁机制可以多个会话同时对不同的记录进行修改，从而提高写操作的吞吐量[15]。本系统用MySQL存储教职工信息、报账申请记录、审批意见、经费预算额度、打款状态等业务数据，用主外键约束保证数据的完整性，给报账金额汇总和经费余额校验提供可靠的持久化支持。

2.4 前后端分离架构

　　前后端分离架构把前端展示层和后端服务层分离开来，用HTTP协议交换JSON格式的数据。前端应用运行在浏览器中，主要完成页面路由的控制以及视图的渲染工作；后端服务主要是提供RESTful API接口，只做业务逻辑和数据持久化的处理。交互流程中，前端根据用户的操作来构造请求，带上认证令牌发往指定的API端点，后端对数据进行校验和处理之后给出标准化的响应体，前端按照状态码和数据内容来更新界面。这样的架构使得开发过程可以同时进行，前端人员只做交互设计，后端人员只做业务逻辑和性能测试。部署阶段前端静态资源可以托管到Nginx服务器上，后端服务部署到独立的应用服务器上，用跨域资源共享来解决域名不同造成的访问问题[16]。本系统采用该架构，教职工在前端填写报账申请之后，系统把表单数据发往Spring Boot搭建的后端接口，财务人员审批操作所引起的状态变化通过API反馈给前端，从而达到报账全流程的无缝数据流转。

第三章 系统分析

3.1 功能需求分析

3.1.1 教职工功能

　　教职工进入系统之后可以查看报账指南，了解报账流程和材料要求。教职工在线发起报账申请，填写申请信息后提交。提交之后，教职工可以查看报账信息并跟踪申请处在什么阶段。财务人员完成复审之后，教职工可以查看到复审信息，了解审批通过或者驳回的原因。打款完成之后，教职工会收到打款信息并核对款项是否到账。教职工可以查看自己名下的经费项目可用余额和使用情况。教职工角色用例图如下图3-1所示。

图3-1教职工用例图

3.1.2 财务人员功能

　　财务人员管理报账指南内容，根据政策变化更新指南说明。财务人员对教职工提交的申请进行初审，处理报账信息。初审通过后，财务人员在复审信息栏中填写申请，提交给复审环节。复审通过之后，财务人员核对打款信息，确认金额和收款账户没有错误之后再发起打款。财务人员查看咨询信息，解答教职工提出的问题。财务角色用例图如下图3-2所示。

图3-2财务用例图

3.1.3 管理员功能

　　管理员对报账分类进行管理，设置不同的报销类别及相应的规则。管理员维护报账指南，发布、修改或者删除指南条目。管理员管理全系统报账信息，对异常申请进行干预处理。管理员管理复审信息，监控各个环节的审批进度。管理员对打款信息进行管理，核对打款记录，处理异常情况。管理员对经费信息进行管理，负责各个院系或者项目经费额度的分配。管理员角色用例图如下图3-3所示。

图3-3管理员用例图

3.2 可行性分析

3.2.1 技术可行性

　　系统采用前后端分离的架构，前端用Vue框架来搭建用户界面，后端用Spring Boot框架来实现业务逻辑，MySQL数据库做数据持久化存储。经过大量的项目验证，社区活跃度高、开发资料多的三个技术。开发人员已经对Spring Boot框架的核心注解以及自动配置有系统的了解，能够使用Vue的组件化开发和响应式数据绑定的方法，熟悉MySQL的SQL语句编写和事务控制的操作。系统在本地开发环境中可以直接运行，不需要使用其他的中间件。可能会出现的性能问题主要集中在数据库查询效率上，合理的设计索引以及避免全表扫描可以解决。数据安全上用参数化查询来防止SQL注入攻击。因此该系统技术上是可以的。

3.2.2 操作可行性

　　目标用户为高校的教职工和财务人员，两类用户都具有使用计算机办公系统的基础。教职工原来的报账流程是线下填单再送交财务处，新的系统把填单和提交环节迁移到了线上，用户只需要按照表单提示填写报销信息就可以完成申请。财务人员原来的审核模式是逐份翻阅纸质单据，新系统把单据电子化展示出来，审批操作简化成点击按钮和填写意见。系统上线初期可以保留一些线下通道作为过渡，待用户熟悉操作之后再全部切换。后续的维护工作由校内的信息技术部门来完成，系统功能模块划分清楚，维护人员可以很快找到问题所在。因此系统在操作上是可以的。

3.2.3 市场可行性

　　高校财务报账周期长、流程繁杂的现象普遍存在，教职工报销难问题在各个高校都有出现。现有的解决办法有自行开发财务系统或者购买商业报销软件，自行开发受学校技术力量所限，系统功能一般都不完善。商业软件价格昂贵、个性化程度低，不能满足各高校不同的经费管理要求。本系统定位为面向中小型高校的专用报账平台，可以对申请、审批、打款等各个环节进行管理，经费控制和报销业务互相配合。相比于通用的报销软件来说，本系统对经费额度的实时校验更加有针对性。因此系统在市场方面是可行的。

第四章 系统设计

4.1 系统架构设计

　　系统使用前后端分离的模块化设计，前端用Vue框架渲染用户界面和处理交互，后端用Spring Boot框架处理业务逻辑和请求路由。用户操作触发axios异步请求，请求包含认证令牌，发往后端控制器。控制器解析参数之后调用服务层组件，服务层执行报账申请校验、经费额度计算、审批状态更新等主要逻辑。数据持久化操作是由MyBatis映射器来完成的，MySQL数据库保存着报账指南、申请记录、经费信息等业务数据。本地缓存机制存储用户会话以及临时令牌，减小数据库的访问量。该架构把界面展示和业务处理分离开来，前端单独部署到静态资源服务器上，后端运行在应用服务器上，两者之间用JSON格式进行交互。王伟认为Spring Boot企业级开发中分层设计可以提高代码的可维护性以及系统的响应速度[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财务用户实体属性图

　　咨询信息实体有咨询标题、咨询内容、回复内容等属性。实体属性图如下图4-15所示。

图4-15咨询信息实体属性图

　　报账分类实体主要是报账类型属性。实体属性图如下图4-16所示。

图4-16报账分类实体属性图

　　系统全局E-R图如图4-17所示。

图4-17系统E-R图

4.4.2 数据库表设计

　　报账指南表主要是用来存放报账流程说明和材料规范的。主要内容为指南标题、报账类型、流程说明、材料规范等。表4-1所示。

表4-1报账指南表

　　注册用户表主要保存教职工的基本信息和收款账户。主要是用户姓名、学工号、手机号码、收款账户等信息。表4-2为数据结果。

表4-2注册用户表

　　报账信息表主要用来存放教职工提交的报销申请记录。主要包含报账单号、报账标题、报账金额、报账事由等字段。表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报账分类表

第五章 系统实现

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 打款信息功能实现

　　复审通过的报销申请进入打款环节，教职工在打款信息模块中查看打款状态。系统显示打款时间、打款金额和收款账户信息。用户确认到账情况之后完成整个报账流程。打款信息界面如图5-5所示。

图5-5打款信息界面

5.1.6 经费信息功能实现

　　教职工进入经费信息模块查看本人名下各个经费项目可用余额。系统显示经费标题、经费类型、剩余金额，报账一次扣一次经费余额。用户根据实际情况来安排报销顺序。经费信息界面如下图5-6所示。

图5-6经费信息界面

5.2 财务功能实现

5.2.1 报账指南功能实现

　　财务人员进入到报账指南管理模块，对政策变动后的内容进行修改。系统可以对指南条目进行编辑和发布，更新后所有教职工都可以看到。报账指南界面如图5-7所示。

图5-7报账指南界面

5.2.2 报账信息功能实现

　　财务人员在报账信息模块中可以查看到所有的待处理报销申请列表。系统按照提交时间顺序排列，财务人员逐张审核票据和经费额度后作出初审意见。报账信息界面如图5-8所示。

图5-8报账信息界面

5.2.3 复审信息功能实现

　　财务主管在复审信息模块上再次审核初审通过的申请。系统显示报账事由及有关凭证，主管作出通过或者驳回决定时填写复审说明。复审信息界面如图5-9所示。

图5-9复审信息界面

5.2.4 打款信息功能实现

　　财务人员在打款信息模块中查看已经过复审的申请列表。系统中显示出收款账户、报账金额，财务人员核对无误之后进行转账并记入打款时间。打款信息界面如下图5-10所示。

图5-10打款信息界面

5.2.5 咨询信息功能实现

　　财务人员在咨询信息模块中查看教职工提交的财务问题。系统以提交时间来排列咨询条目，财务人员一一回答回复内容并保存，教职工可查看回复。咨询信息界面图5-11。

图5-11咨询信息界面

5.3 管理员功能实现

5.3.1 报账分类管理功能实现

　　管理员登陆报账分类管理模块设置报销类别名称和适用条件。系统可以新增、修改和删除分类，分类调整之后报账申请页面会同步更新选项列表。报账分类管理界面如下图5-12所示。

图5-12报账分类管理界面

5.3.2 报账指南管理功能实现

　　管理员对全系统所有的指南条目进行报账指南管理模块的维护。系统有发布、编辑、下架功能，管理员根据政策变化随时对指南内容进行修改。报账指南管理界面如图5-13所示。

图5-13报账指南管理界面

5.3.3 报账信息管理功能实现

　　管理员进入报账信息管理模块查看整个系统的报销申请。展示所有用户报销记录，管理员可以查看异常申请并作出干预。报账信息管理界面如图5-14所示。

图5-14报账信息管理界面

5.3.4 复审信息管理功能实现

　　管理员对复审信息管理模块中的各个环节的审批进度进行查看。系统展示每一份申请的复审记录以及操作人的信息，管理员发现审批有误的时候可以进行调整。复审信息管理界面如图5-15所示。

图5-15复审信息管理界面

5.3.5 打款信息管理功能实现

　　管理员进入打款信息管理模块之后可以查看整个系统打款记录。系统可显示出每一笔转账的详细信息，管理员可以处理打款失败的情况。打款信息管理界面如下图5-16所示。

图5-16打款信息管理界面

5.3.6 经费信息管理功能实现

　　管理员对各个学院、项目经费进行预算额度的维护。系统支持额度调整和结余结转的操作，每次调整都会记录操作人以及变更的时间。经费信息管理界面如图5-17所示。

图5-17经费信息管理界面

第六章 系统测试

6.1 测试目的

　　系统测试就是检验高校财务报账系统是否符合设计要求。对测试过程中报账申请、审批流转、打款处理等主要功能进行检查。对系统中隐藏的错误和逻辑问题进行测试，可以评价出系统的功能是否完整，数据是否准确，操作是否方便等各个方面的情况。测试结果是系统能否投入使用的一个判断标准，也是以后维护的参考。

6.2 测试方法

　　本系统用黑盒测试的方法来考察各个功能模块的外部行为。测试人员根据需求文档设计出测试用例，测试流程有报账指南查询、申请提交、审批、打款确认等[20]。不看内部代码实现细节，只验证输入和输出的关系。功能测试之后再做简单的界面兼容性测试，保证前端页面在不同的分辨率下可以正常显示。

6.3 测试用例

6.3.1 报账申请功能测试

　　报账申请模块测试验证教职工提交报销单据的全部业务流程。测试关注申请信息是否可以正确提交，系统是否可以根据报账类型自动关联经费项目。校验规则对于必填项为空或者经费余额不够的都会给出提示。报账申请测试结果见表6-1。

表6-1报账申请测试用例表

6.3.2 报账审批功能测试

　　报账审批模块的测试，主要是检验财务人员对申请进行初审、复审的过程。测试主要看审批状态是否可以正确变更，驳回时是否记录驳回理由。经过审批的申请自动转到下一个环节，驳回的申请退回给教职工修改。报账审批测试见表6-2。

表6-2报账审批测试用例表

6.3.3 打款处理功能测试

　　打款处理模块测试来检验财务人员转账操作以及状态更新是否一致。测试打款信息是否可以正确地被记录下来，教职工端能否及时地查看到打款的状态。账户信息有误时系统会给出退回修改的途径。打款处理测试见表6-3。

表6-3打款处理测试用例表

6.3.4 经费余额扣减功能测试

　　经费余额扣减模块测试验证报账申请通过之后经费额度自动更新的逻辑。测试扣减金额是否正确，扣减后余额是否可以实时反映到经费信息里。超出余额的申请被拦在了审批环节。经费余额扣减测试见表6-4。

表6-4经费余额扣减测试用例表

6.3.5 复审信息管理功能测试

　　复审信息管理模块的测试主要是对财务主管提交审核意见和查询历史记录功能的测试。测试复审内容是否可以正确保存，驳回申请时教职工是否能看到具体的说明。已经过复审的记录不能重复操作。复审信息管理测试结果如表6-5所示。

表6-5复审信息管理测试用例表

6.3.6 咨询信息回复功能测试

　　咨询信息回复模块测试验证财务人员对教职工提出的问题做出答复的过程。测试主要考察回复内容是否可以被保存，教职工能否在咨询信息中查看到回复。未回复的咨询条目用红色字体标出。咨询信息回复测试见表6-6。

表6-6咨询信息回复测试用例表

6.3.7 经费信息管理功能测试

　　经费信息管理模块测试验证管理员对于经费额度进行调整、分配的操作。测试额度调整之后是否可以正确生效，调整记录是否可以追溯。结余结转操作把剩余额度转到下一个周期。经费信息管理测试结果如表6-7所示。

表6-7经费信息管理测试用例表

测试结论

　　经过系统的功能测试，七大部分的测试用例全部通过。报账申请模块对于完整填写信息、缺少必填项、经费余额不足这三种情况，都能按照预期做出响应。报账审批模块初审、复审的通过和驳回操作状态变更正确。打款处理模块完成正常转账和异常退回两种流程的验证。经费余额扣减模块对于单次扣减、多次累加以及余额不足拦截的场景下计算正确。复审信息管理模块的审核意见存档和记录锁定功能是正常的。咨询信息回复模块的答复保存和状态同步机制一样。经费信息管理模块中有关额度分配、调整、结余结转的操作都会被执行。所有测试项实际结果与预期结果相符。

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