宅急送新BOS系统的设计与实现
摘 要
物流配送行业迅速发展,传统的业务管理模式存在着信息流转速度慢、多角色协同难等问题。宅急送属于典型的物流企业,业务受理、库存调度、返货处理等环节依靠人工操作,很容易出现数据不一致、响应迟缓的情况。创建起一个多角色权限、包含主要业务链条的信息化系统,就成了改善运营效率的重要途径。
本系统使用SSM框架和Vue前端技术进行开发,用MySQL数据库存储业务数据。操作人员可以进行返货申请、库存管理、异常录入等工作,运营主管在操作人员的基础上增加了签单管理、合作网点维护、大物流信息监控的权限,管理员具有全部的功能并且可以进行业务受理和报表分析。系统用角色分离来达成职责界限的明确,把入库、出库、库存查询、调度申请等操作集中到一个管理平台当中。数据库设计使用了第三范式,主要业务表有入库信息表、库存信息表、出库信息表、返货申请表、返货订单表等,保证数据一致性以及可追溯性。测试阶段有五个主要的功能,经过测试可知系统运行正常,业务逻辑满足设计需求。
系统给中小型物流企业提供了一个可以参照的数字化转型方案,对物流业务全流程的信息化支撑起到了重要的作用。
关键词: 物流管理系统,SSM框架,Vue技术,权限控制,库存管理
ABSTRACT
The logistics and delivery industry is developing very quickly; traditional business management methods have issues like poor information circulation and hard multi role cooperation. JH Express is an ordinary logistics company which depends on manpower in the business acceptance, inventory arrangement and return processing, so it brings about data disaccord and response delay. Building an information system with multiple role permission and covering the main part of business is becoming a major way to improve operation.
The system is written by SSM and vue for the front end, it use mysql to storage the business data. Operators can do the daily job like returns application, stock keeping, exceptions entering. Operations supervisers get more permission such as sign management , cooperate network maintenance and large logistics information watch. Besides their operators. Administrators have all the functions and can also do business reception and reports analysis. It has clear responsibilities due to role separation, all inbound and outbound, inventory inquiry, dispatch applications etc., are managed from one place. Design is based on 3NF database, core business table such as inbound info table,inventory info table,outbound info table,return appl table,return order table etc.,to ensure the correctness of data operation and its trackability. In terms of the testing section, there are 5 key functions which were verified to have stable operation and correct business logic.
It provides full information to all processes of the logistics company. It's a fine example showing how we can digitalize a small logiics company.
Keywords: Logistics Management System; SSM Framework; Vue.js; Permission Control; Inventory Management
目 录
1绪论
1.1选题背景
物流行业在电商经济快速发展的大环境下,正处在前所未有的经营压力之下。传统的物流管理依靠人工录入和纸质单据流转,返货申请要经过许多部门的层层审批,库存信息更新迟缓造成物资积压或者短缺的现象时有发生。调度申请没有统一的信息归集渠道,运营主管不能及时掌握业务的进展情况,异常情况处理响应慢。刘万森和杨显洁[1]对基于AGV的自动配送系统的设计思路进行了研究,给物流自动化提供了一些技术上的借鉴。郭光明、庞建军、孙健[2]就危险废物泵送系统给出了专门的物流场景的技术方案。覃晓丽、钟锴炫、郑贤[3]认为实时的信息推送对于提高业务的效率有很重要的作用。虽然上述研究各有侧重,但是对于综合物流业务管理平台的系统性设计还存在着空白。宅急送新BOS系统开发就是弥补上述空白,把返货处理、库存管理、调度申请等分散环节整合成一个信息化平台。
1.2国内外研究现状
国内物流管理信息系统发展是从单机软件向Web平台转变的过程。早期物流企业大多用Excel加Access数据库的方式处理业务单据,返货申请和库存记录互不关联,数据一致性很难得到保证。韦燚、余丹炯[4]认为信息同步对于港口实时消息推送系统来说十分重要。刘勋[5]就根据需求预测建立即时配送系统进行了设计,显示了依靠数据做决策的一种可能性。李永强、樊青波和刘绍楠在对卫星遥测数据推送系统进行研究的时候,就对实时信息传输技术的可行性进行了验证[6]。丁博[7]对分段直送系统的配送环节进行设计研究。以上研究给物流各个环节的信息化打下了技术基础,但是针对中小物流企业综合管理平台还比较缺乏。近些年来,Spring Boot同Vue技术栈的成熟使得Web系统开发门槛降低,一批以SSM架构为基础的物流管理系统开始涌现,这些系统在返货处理、库存盘点等模块上渐渐形成起比较规范的设计模式。
国外物流信息化起步较早,第三方物流企业已经建立起了比较完善的管理系统。Bhairam、Shukla和Pandey[8]就药物递送系统的复杂流程管理提出了信息化的思想。Shen、Yang和Xu[9]对于淀粉基递送系统研制的思路可类比于物流环节之间的衔接情况。Trucillo、Avallone和Maio[10]对梯度泡沫递送系统的工艺控制进行了细致的研究。郑、林、周[11]关于口服蛋白质药物递送系统设计中提出,多阶段协调运行逻辑是口服蛋白质药物递送系统设计的关键。Zhu、Zhang和Tang[12]在阴离子多糖纳米组装的研究中使用了多因素协同控制的方法论。国外主要物流平台C.H.Robinson的Navisphere系统实现了运输全过程的可视化管理,XPO Logistics的Connect平台把返货处理和库存管理放在同一个数据模型里。这些系统大多采用微服务架构和云端部署的方式,但是高昂的实施成本以及复杂的运维要求给中小物流企业造成了进入的障碍。
1.3课题研究的主要内容
本文以宅急送新BOS系统的设计和实现为研究对象,主要从业务需求出发,建立包含返货申请、库存管理、调度协调等各项功能的综合物流管理系统。研究内容按照软件工程生命周期分为五个连续的阶段。需求分析阶段发现操作人员、运营主管、管理员三种角色的需求,确定返货申请管理、入库出库操作、报表生成等主要用例的业务规则。系统设计阶段完成B/S架构整体规划,确定SSM框架整合方案,划分前端展示层、业务逻辑层、数据访问层职责边界。数据库设计符合规范化原则,把access_token、auth、user等基础表和业务表分开,用外键来保证数据的一致性。模块实现阶段完成各个功能接口的编码工作,前端页面采用Vue组件化开发的方式降低代码耦合度。测试验证阶段编写测试用例,正常的流程和异常的分支都包含在内。本文主要对业务流程的信息化再造进行研究,不涉及路径规划、需求预测等高级物流模型。预期成果有可以运行的Web系统、数据库设计文档、测试报告和用户操作手册。整体方法采取敏捷开发的思想,用迭代的方式逐步完善各个模块的功能。
1.4项目开发的意义
宅急送新BOS系统开发直接解决了中小物流企业日常运营中出现的效率问题。传统的管理模式依靠人工录入、纸质单据的流转来实现返货申请从提交到最后的审核时间,一般要经过很多部门的沟通才能完成。系统采用电子化的流程将申请提交、状态跟踪、结果反馈放在同一个平台上完成,操作人员提交之后运营主管的工作台上会马上出现待办提醒,审核通过之后订单就会自动产生,整个链条的等待时间也从数天缩短到了几分钟。库存管理环节明显改善,人工盘点模式下物资进出逐条登记后汇总计算,数据滞后性大。新系统把入库和出库操作直接关联到库存余额的实时更新上,每次物资变动都会引起数据库字段的原子性修改,彻底解决了由于统计口径不同造成的账实不符问题。该种设计可以减轻操作人员的重复劳动负担,而且从根本上减少人为计算错误的发生概率。
从行业推广的角度来说,本文所建立的系统为其他类似物流企业提供可以复用的功能模块划分模式。业务受理、返货处理、签单确认等主要环节都被系统抽象成一个个相对独立但是又相互联系的模块,各个模块之间数据传递依靠标准接口来实现。该种设计思路可以供其它开发团队借鉴,对于每一个项目来说都不需要再进行业务建模。系统积累的异常录入记录、报表统计数据给管理决策提供量化的依据,运营主管可以利用异常类型分布来发现流程中的薄弱环节,管理员可以从入库出库趋势中看出物资采购的节奏。数据驱动的管理方式正在取代经验主义的粗放模式,本系统对这种转型在中小物流企业中是否可行进行了验证。其它行业的信息化改造项目可以参照本系统权限分层设计和流程编排逻辑来提高自主开发的技术门槛、试错成本。
2相关技术介绍
2.1SSM框架
S SM框架组合是由Spring、Spring MVC、MyBatis这三个开源框架组成,该技术栈在Java企业级应用开发中被广泛使用。Spring框架采用控制反转和依赖注入容器来管理业务对象之间的引用关系。Spring MVC模块负责HTTP请求的接收和响应分发,控制器层接收到前端传来的参数之后就会调用相应的服务组件。MyBatis是持久层框架,把Java对象和SQL语句进行映射绑定。在业务受理模块开发时,Spring对业务受理Service对象和DAO对象进行依赖注入,Spring MVC接收前端提交的工单信息后转发给业务受理控制器。MyBatis用XML配置文件或者注解方式来定义业务受理表和Java实体类字段之间的映射关系,执行插入工单记录或者查询工单列表等数据库操作。该框架组合具有分层的特点,控制器、业务逻辑、数据访问这三个层次的代码互相独立,修改某一层次的实现细节不会影响到其他层次。在返货申请处理场景中,控制器收到申请数据之后会调用业务层来检验申请是否合理,业务层接着会利用数据访问层去操作返货申请表和返货订单表。框架内部事务管理机制保证返货申请插入和订单生成两个操作要么都成功,要么都回滚,防止出现申请没有订单或者订单没有申请的异常情况[13]。
2.2Vue框架
Vue是用于构建用户界面的渐进式JavaScript框架,它的主要库只负责视图层的渲染和更新。该框架用依赖追踪的方式来实现响应式系统,数据模型发生变化的时候视图层就会自动重绘。组件化开发模式把页面拆分成可以独立使用的各个组件单元,每一个组件都有模板、逻辑和样式等。库存信息管理界面开发时,使用Vue实例的data属性来存放物资名称、物资编号、当前库存量等数据对象,使用methods属性定义查询库存、修改库存等交互方法。用户触发搜索按钮之后,methods中定义的方法使用axios库向后端发起异步请求,后端返回的库存数据会直接赋值给data属性,页面绑定的表格区域就会显示最新的库存记录。双向数据绑定特性使得我们不用手工去操作DOM节点了。组件化设计将入库表单、库存列表、出库按钮等界面元素分别封装成独立的组件,运营主管权限下库存管理页面和操作人员权限下库存管理页面可以复用相同的库存列表组件,只是通过props传递不同的数据源。虚拟DOM机制在组件重新渲染的时候只更新变化的部分而不是整个页面,异常录入页面的频繁数据提交操作不会造成界面卡顿[14]。
2.3MySQL数据库
MySQL是关系型数据库管理系统,用结构化查询语言来操作数据。数据库内部把数据存放在行和列构成的二维表里,表之间用外键约束来建立关联关系。存储引擎层支持使用InnoDB和MyISAM等各种引擎。InnoDB引擎支持事务以及行级锁。宅急送系统数据库中入库信息表保存物资名称、入库数量、操作人员等信息,库存信息表保存物资编号、当前库存量、入库限制次数等信息。操作人员执行入库操作的时候,数据库事务被打开,INSERT语句向入库信息表添加一条记录,UPDATE语句修改库存信息表中库存数量,COMMIT语句提交事务使两个修改永久生效。入库过程中如果发生断电或者网络中断,ROLLBACK语句就会回滚此次事务中所有的修改,保证入库信息表和库存信息表数据一直一致。MySQL的索引机制给频繁查询的字段创建B+树结构,物资编号字段作为查询条件的时候,数据库用索引快速找到目标记录的位置。在库存盘点场景下,运营主管根据物资种类选择要查的库存信息,数据库优化器用物资种类字段上的索引来执行查询,减少磁盘I/O次数[15]。
2.4Vue Router
Vue Router 是 Vue.js 官方提供的路由管理库,用以实现单页面应用中导航的逻辑。该库利用监听浏览器URL变化来动态加载对应的组件,页面切换的时候不需要重新加载整个文档。路由配置表定义出路径和组件的映射关系,当用户访问不同的URL的时候,路由就会去匹配相应的组件并渲染到视图容器上。在宅急送BOS系统前端架构里,路由模块会依照用户的角色来动态产生可以被访问的路由列表。操作人员登录之后路由表只包含返货申请、库存查询、入库登记等菜单所对应路径,运营主管登录之后签单管理、合作网点、大物流信息等路由也被加入到路由表当中。导航守卫功能在路由跳转之前对用户的权限标识进行检查,没有权限的用户访问受限路径会被重定向到首页或者提示页面。路由懒加载机制把每一个组件打包成一个单独的JavaScript文件,用户第一次访问包装信息管理页面的时候,浏览器只会下载该页面所用到的组件代码,其它没有访问过的页面的代码不会被加载。按需加载的方式可以减少初始页面的加载时间,对于很少使用的异常录入、报表信息等模块也不会影响系统的启动速度[16]。
3系统需求分析
3.1可行性分析
3.1.1技术可行性
本系统使用SSM框架作为后端技术栈,Spring管理业务对象之间的依赖关系,Spring MVC处理请求分发,MyBatis完成数据库操作。该框架组合经过大量的Java Web项目测试,各个组件之间版本兼容性好,社区文档资源丰富。前端使用Vue框架来创建用户界面,采用组件化开发模式可以提高代码的可复用性以及可维护性。MySQL数据库支持事务处理以及并发访问,可以满足物流业务对于数据一致性的要求。开发工具IntelliJ IDEA具有代码补全、调试的功能,可以降低编码过程中技术的门槛。后端和前端分离的架构使得开发工作可以同时进行,接口联调有具体的规范可以遵循。以上技术条件可以满足宅急送新BOS系统开发工作。
3.1.2经济可行性
系统开发所需的软件工具均为开源或社区版本,IntelliJ IDEA社区版、MySQL Community Server、Node.js运行环境无需购买商业授权。开发所用的硬件资源为普通个人计算机,内存容量8GB以上就可以满足开发环境的运行需求。系统部署阶段采用单机运行模式,一台具有4核CPU和16GB内存的服务器就可以同时满足操作人员、运营主管、管理员这三种角色的并发访问。后续维护工作主要有数据库备份和异常日志排查,一人就可以完成日常运维工作。投入主要在初期的开发人力成本上,后期运行维护的费用比较低,系统建设的经济负担处在合理范围之内。
3.1.3操作可行性
系统界面用角色化菜单设计,操作人员登录之后只显示返货申请、库存管理、入库出库等与日常工作有关的功能入口。运营主管在操作人员功能的基础上增加签单管理、合作网点、大物流信息等扩展模块,管理员有业务受理和报表分析的权限。每一个功能页面的操作流程都经过简化处理,入库登记页面有物资选择和数量填写两个主要步骤,库存查询页面有按物资名称或者编号进行筛选的搜索框。用户不需要接受复杂的培训就可以完成日常的操作,新员工只需要十分钟左右的引导演示就可以学会基本的使用方法。系统交互逻辑符合物流业务实际工作习惯,操作人员在纸质单据时代积累下来的业务经验可以迁移到电子化操作当中。
3.2功能需求分析
3.2.1操作人员功能需求
操作人员在系统中完成返货业务和库存操作的基本执行工作。该角色可以发起返货申请,填写申请标题、申请原因、申请详情等信息后提交系统。返货申请通过审核之后产生返货订单,操作人员可以查看订单的状态以及处理的进度。包装信息管理功能可以录入包装环节的全部信息,包括信息标题、信息详情。异常录入功能用来上报业务处理过程中出现的异常情况,填写异常标题和异常详情之后保存到系统中。库存信息查询功能可以实现物资库存数量的实时查看。入库信息管理、出库信息管理分别记载物资的入库数量、出库数量,操作完毕后会立刻更新对应物资的库存余额。调度申请功能是对运输资源调配请求进行发起,填写申请标题和申请详情后提交给运营主管审核。操作人员角色用例图如图3-1所示。

图3-1 操作人员用例图
3.2.2运营主管功能需求
运营主管是在操作员基础上加上了审核权以及较重大的业务管理权限的人员。该角色对操作人员提交的返货申请进行审核,决定是否通过或者驳回,审核通过的申请就会自动生成返货订单。签单信息管理功能是对签单标题、签单详情进行记录,确认业务环节是否已经完成。合作网点管理可以允许运营主管对网点名称、所在地址、网点详情等信息进行修改,建立企业之间的合作关系。大物流信息管理功能收集物流标题、物流详情、发货详情等信息,整合运输环节的关键节点信息。运营主管可以查看所有的返货订单、包装信息、异常录入、库存变动、入库出库记录和调度申请,具有对这些业务数据进行修改的权限。运营主管角色的用例图如图3-2所示。

图3-2 运营主管用例图
3.2.3管理员功能需求
管理员有系统的全部操作权限。业务受理管理可以创建业务工单、工单编号和业务类型。返货申请管理模块管理员可以查看所有的申请记录并进行最终的审核。返货订单管理可以进行订单创建、修改和删除操作。包装信息管理可以管理员对包装信息的数据字典进行修改。签单信息管理模块管理员可以对签单记录进行补录或者修正。异常录入管理中管理员对异常数据进行归档和统计分析。报表信息管理功能可以生成报表内容和报表简介,并根据报表类型导出统计数据。合作网点管理可以对网点进行信息的增删改查。库存信息管理模块管理员可以对物资库存初始值进行修改。入库、出库信息管理可以让管理员查看全部的操作日志。大物流信息管理中管理员主要是对物流信息的完整性进行维护。管理员角色用例图如图3-3所示。

图3-3 管理员用例图
系统在多用户并发访问的时候要保证有稳定的响应速度。操作人员提交返货申请的时候,从点击提交按钮开始到页面返回成功提示结束的时间应该在两秒之内。库存信息查询操作属于数据库检索并封装结果集,页面加载时间不应大于3秒。入库、出库操作的库存余额更新要保证原子性完成,事务提交时间不能超过毫秒。报表信息模块产生统计报表的时候会牵涉到很多数据的汇总运算,系统要在五秒之内结束处理并给出结果。调度申请提交之后,需要将消息传递到运营主管的工作台,其消息传递的延迟时间不能大于一秒。系统应该能够支持五十个以上的用户同时在线操作,而且不会造成明显的响应延迟或者请求阻塞。
系统要对用户的登录信息加以严格的审核,不同的角色只能访问到自己所拥有的权限范围内的功能模块。操作人员登录之后只能查看自己提交的返货申请和入库出库记录,不能访问运营主管的审核界面。用户密码在传输过程中要使用加密的方式进行处理,数据库中存储的密码字段不能用明文的形式保存。防跨站脚本攻击机制要对用户输入的特殊字符实施过滤或者转义操作,从而阻止恶意代码被注入。会话超时机制应该在用户长时间没有操作之后自动退出登录状态,防止别人未经授权使用已经登录的账号。操作日志记录下发生的行为的时间以及操作人员,给安全审计提供追溯的依据。
系统正常工作时要保证较高的可用性,计划外停机时间不能多于每月八小时。数据库事务机制要保证返货申请提交和订单生成这两个操作的统一性,任何一个环节出错,整个事务都会回滚到操作之前的状况。入库操作造成库存余额增加时,系统断电或者网络中断不能造成库存数据部分更新。服务器出现异常重启之后,系统应该可以自动恢复运行,没有完成的操作请求不会产生错误数据。系统要有数据备份和恢复功能,每天定时把业务数据存到另外的存储中。硬件出现故障或者数据库连接断开的时候,系统应该给用户发出明确的错误提示而不是直接崩溃。
4系统设计
4.1系统架构设计
系统使用B/S架构模式,浏览器作为客户端展示界面,服务器端处理业务逻辑和数据存储。表现层采用Vue框架搭建的单页面应用,用户和后端通过HTTP协议进行数据交互。应用服务层使用Spring MVC控制器接收前端请求,调用业务接口完成具体功能。业务逻辑层把返货申请审核、库存数量变动、调度资源调配这些主要规则进行封装。数据持久层使用MyBatis框架把对象的操作转化为SQL语句,MySQL数据库存储业务数据。分层设计使各个层次之间的职责界限分明,表现层的改变不会对业务规则的准确性造成影响。朱书彪[17]对JavaWeb项目课程开发进行了SSM架构的研究,证明了SSM架构在教学和实践场景中是可行的。系统运行在Tomcat容器里,Maven管理项目构建过程。前端使用Vite的热重载功能,后端用IntelliJ IDEA进行编码调试。系统架构图如下图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数据库设计
数据库设计用关系型模型来组织业务数据,用规范化的方法减少数据冗余,保证一致性。实体间用主外键来建立完整的数据链路,用户表的user_id为外键出现在access_token、auth等表中。事务机制保证了返货申请的提交和订单的产生二者不能同时完成,也不能同时失败。索引策略是对频繁查询的字段建立快速检索路径,用户名字段和申请状态字段分别创建普通索引。外键约束保证子表记录指向的父表主键存在,入库信息中的物资编号必须在库存信息表中有对应的记录。吴迁[18]对于跨平台应用开发研究当中,数据库设计在Web系统里所起的关键作用进行了论述。
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 库存信息实体属性图
入库信息实体主要包括物资编号、物资名称、物资类型、入库数量、入库备注、操作人员等属性。实体属性图如图4-17所示。

图4-17 入库信息实体属性图
出库信息实体主要包括物资编号、物资名称、物资类型、出库数量、出库备注、操作人员等属性。实体属性图如图4-18所示。

图4-18 出库信息实体属性图
大物流信息实体主要包括物流标题、物流详情、物流备注、发货详情、录入时间、录入用户等属性。实体属性图如图4-19所示。

图4-19 大物流信息实体属性图
调度申请实体主要包括申请编号、申请标题、申请详情、申请备注、申请时间、申请用户等属性。实体属性图如图4-20所示。

图4-20 调度申请实体属性图
用户账户实体主要包括用户组、账户状态、手机号码等属性。实体属性图如图4-21所示。

图4-21用户账户实体属性图
系统E-R图如图4-21所示。

图4-21 系统E-R图
4.4.2数据库逻辑结构设计
数据库表设计是根据业务需求,确定数据库表的结构、字段类型及其关系。通过规范化设计,保证数据的完整性、一致性与效率,同时避免冗余数据,并为后续的数据查询、存储和维护提供清晰的框架[19]。以下是系统的数据库表设计展示。
用户账户表主要是用来存储系统用户的登录凭证与基本信息。主要包括用户ID、用户名、密码、手机号码等字段。如表4-1所示。
表4-1 用户账户表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | user_id | int | 11 | 是 | 是 | 用户ID |
| 2 | username | varchar | 16 | 是 | 否 | 用户名 |
| 3 | password | varchar | 64 | 是 | 否 | 密码 |
| 4 | phone | varchar | 11 | 否 | 否 | 手机号码 |
| 5 | nickname | varchar | 16 | 否 | 否 | 昵称 |
| 6 | user_group | varchar | 32 | 否 | 否 | 用户组 |
业务受理表主要是用来记录业务工单的创建与分配信息。主要包括工单编号、业务标题、工单类型、工单详情等字段。如表4-2所示。
表4-2 业务受理表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | business_acceptance_id | int | 11 | 是 | 是 | 业务受理ID |
| 2 | work_order_number | varchar | 64 | 否 | 否 | 工单编号 |
| 3 | business_title | varchar | 64 | 否 | 否 | 业务标题 |
| 4 | work_order_type | varchar | 64 | 否 | 否 | 工单类型 |
| 5 | ticket_specificss | text | 65535 | 否 | 否 | 工单详情 |
返货申请表主要是用来存储用户提交的返货请求内容。主要包括返货标题、申请详情、申请原因、审核状态等字段。如表4-3所示。
表4-3 返货申请表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | return_application_id | int | 11 | 是 | 是 | 返货申请ID |
| 2 | return_title | varchar | 64 | 否 | 否 | 返货标题 |
| 3 | application_specificss | text | 65535 | 否 | 否 | 申请详情 |
| 4 | reason_for_application | text | 65535 | 否 | 否 | 申请原因 |
| 5 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
返货订单表主要是用来记录审核通过后生成的订单信息。主要包括返货标题、申请详情、申请原因、申请用户等字段。如表4-4所示。
表4-4 返货订单表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | return_order_id | int | 11 | 是 | 是 | 返货订单ID |
| 2 | return_title | varchar | 64 | 否 | 否 | 返货标题 |
| 3 | application_specificss | text | 65535 | 否 | 否 | 申请详情 |
| 4 | application_remarks | text | 65535 | 否 | 否 | 申请备注 |
| 5 | user_application | int | 11 | 否 | 否 | 申请用户 |
包装信息表主要是用来记录物流包装环节的相关数据。主要包括包装编号、信息标题、信息详情、录入人员等字段。如表4-5所示。
表4-5 包装信息表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | packaging_information_id | int | 11 | 是 | 是 | 包装信息ID |
| 2 | bundle_no | varchar | 64 | 否 | 否 | 包装编号 |
| 3 | message_title | varchar | 64 | 否 | 否 | 信息标题 |
| 4 | information_specificss | text | 65535 | 否 | 否 | 信息详情 |
| 5 | entry_personnel | int | 11 | 否 | 否 | 录入人员 |
签单信息表主要是用来记录业务完成后的签单确认数据。主要包括签单编号、签单标题、签单详情、签单用户等字段。如表4-6所示。
表4-6 签单信息表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | signing_information_id | int | 11 | 是 | 是 | 签单信息ID |
| 2 | signature_no | varchar | 64 | 否 | 否 | 签单编号 |
| 3 | signing_title | varchar | 64 | 否 | 否 | 签单标题 |
| 4 | signing_specificss | text | 65535 | 否 | 否 | 签单详情 |
| 5 | signing_user | int | 11 | 否 | 否 | 签单用户 |
异常录入表主要是用来记录业务处理过程中出现的异常事件。主要包括异常编号、异常标题、异常详情、处理状态等字段。如表4-7所示。
表4-7 异常录入表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | exception_entry_id | int | 11 | 是 | 是 | 异常录入ID |
| 2 | exception_number | varchar | 64 | 否 | 否 | 异常编号 |
| 3 | exception_title | varchar | 64 | 否 | 否 | 异常标题 |
| 4 | exception_specificss | text | 65535 | 否 | 否 | 异常详情 |
| 5 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
报表信息表主要是用来存储系统生成的统计报表数据。主要包括报表编号、报表标题、报表类型、报表内容等字段。如表4-8所示。
表4-8 报表信息表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | report_information_id | int | 11 | 是 | 是 | 报表信息ID |
| 2 | report_no | varchar | 64 | 否 | 否 | 报表编号 |
| 3 | report_title | varchar | 64 | 否 | 否 | 报表标题 |
| 4 | report_type | varchar | 64 | 否 | 否 | 报表类型 |
| 5 | report_contents | text | 65535 | 否 | 否 | 报表内容 |
合作网点表主要是用来维护物流协作网点的基本信息。主要包括网点编号、网点名称、所在地址、网点详情等字段。如表4-9所示。
表4-9 合作网点表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | cooperation_network_id | int | 11 | 是 | 是 | 合作网点ID |
| 2 | point_number | varchar | 64 | 否 | 否 | 网点编号 |
| 3 | network_name | varchar | 64 | 否 | 否 | 网点名称 |
| 4 | address_t | varchar | 255 | 否 | 否 | 所在地址 |
| 5 | outlet_specificss | text | 65535 | 否 | 否 | 网点详情 |
库存信息表主要是用来存储物资的实时库存数量。主要包括物资编号、物资名称、物资类型、物资库存等字段。如表4-10所示。
表4-10 库存信息表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | inventory_information_id | int | 11 | 是 | 是 | 库存信息ID |
| 2 | material_no | varchar | 64 | 否 | 否 | 物资编号 |
| 3 | material_name | varchar | 64 | 否 | 否 | 物资名称 |
| 4 | material_type | varchar | 64 | 否 | 否 | 物资类型 |
| 5 | material_inventory | double | - | 否 | 否 | 物资库存 |
入库信息表主要是用来记录物资入库的操作明细。主要包括物资编号、物资名称、入库数量、操作人员等字段。如表4-11所示。
表4-11 入库信息表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | inbound_information_id | int | 11 | 是 | 是 | 入库信息ID |
| 2 | material_no | varchar | 64 | 否 | 否 | 物资编号 |
| 3 | material_name | varchar | 64 | 否 | 否 | 物资名称 |
| 4 | receipt_quantity | double | - | 否 | 否 | 入库数量 |
| 5 | operator | int | 11 | 否 | 否 | 操作人员 |
出库信息表主要是用来记录物资出库的操作明细。主要包括物资编号、物资名称、出库数量、操作人员等字段。如表4-12所示。
表4-12 出库信息表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | issue_information_id | int | 11 | 是 | 是 | 出库信息ID |
| 2 | material_no | varchar | 64 | 否 | 否 | 物资编号 |
| 3 | material_name | varchar | 64 | 否 | 否 | 物资名称 |
| 4 | quantity_of_issue | double | - | 否 | 否 | 出库数量 |
| 5 | operator | int | 11 | 否 | 否 | 操作人员 |
大物流信息表主要是用来整合运输环节的关键节点数据。主要包括物流标题、物流详情、发货详情、录入用户等字段。如表4-13所示。
表4-13 大物流信息表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | big_logistics_information_id | int | 11 | 是 | 是 | 大物流信息ID |
| 2 | logistics_title | varchar | 64 | 否 | 否 | 物流标题 |
| 3 | logistics_specificss | text | 65535 | 否 | 否 | 物流详情 |
| 4 | shipping_specificss | text | 65535 | 否 | 否 | 发货详情 |
| 5 | enter_user | int | 11 | 否 | 否 | 录入用户 |
调度申请表主要是用来存储运输资源的调配请求信息。主要包括申请编号、申请标题、申请详情、审核状态等字段。如表4-14所示。
表4-14 调度申请表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | dispatch_request_id | int | 11 | 是 | 是 | 调度申请ID |
| 2 | application_number | varchar | 64 | 否 | 否 | 申请编号 |
| 3 | application_title | varchar | 64 | 否 | 否 | 申请标题 |
| 4 | application_specificss | text | 65535 | 否 | 否 | 申请详情 |
| 5 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
5系统实现
5.1操作人员功能实现
(1)登录注册功能实现
用户在访问系统时首先进入登录页面,输入账号密码后系统向后端发送身份验证请求。验证通过则加载对应角色的功能菜单,验证失败返回错误提示。新用户需要填写账号、密码、昵称、邮箱等必要信息完成注册,注册成功后自动跳转至登录页面。登录注册界面如图5-1所示。
图5-1 登录注册界面
(2)返货申请管理功能实现
操作人员通过此模块提交返货请求,填写返货标题后补充申请原因与申请详情。系统接收提交动作后校验必填字段,校验通过则保存申请记录并将审核状态标记为未审核。该申请随后推送至运营主管的工作台等待审批。返货申请管理界面如图5-2所示。
图5-2 返货申请管理界面
(3)返货订单管理功能实现
返货申请通过审核后自动转入订单列表,操作人员在此模块查看所有已生成的返货订单。列表展示返货标题、申请时间、申请原因等关键信息,支持按条件筛选查询。操作人员点击订单条目可查看完整详情。返货订单管理界面如图5-3所示。
图5-3 返货订单管理界面
(4)包装信息管理功能实现
操作人员录入包装环节的相关数据,填写信息标题与包装编号后补充信息详情与信息备注。系统保存记录时自动捕获录入时间,包装信息存入数据库后可在列表中查看。操作人员对已保存的记录执行编辑或删除操作。包装信息管理界面如图5-4所示。
图5-4 包装信息管理界面
(5)异常录入管理功能实现
业务处理过程中出现异常事件时,操作人员通过此模块上报异常情况。填写异常标题后补充异常详情与异常备注,系统自动生成异常编号并记录录入时间。异常信息保存后状态初始为待处理,运营主管随后介入处理。异常录入管理界面如图5-5所示。
图5-5 异常录入管理界面
(6)库存信息管理功能实现
操作人员查询各类物资的实时库存数量,列表展示物资编号、物资名称、物资类型、当前库存等字段。系统每次加载页面时从数据库获取最新数值,支持按物资名称或物资类型进行筛选。库存变动后列表自动刷新展示更新后的数据。库存信息管理界面如图5-6所示。
图5-6 库存信息管理界面
(7)入库信息管理功能实现
操作人员选择目标物资后填写入库数量与入库备注,系统校验入库数量的合法性。校验通过后执行入库操作,对应物资的库存余额增加相应数量。入库记录同时保存操作人员与操作时间,形成完整的入库台账。入库信息管理界面如图5-7所示。
图5-7 入库信息管理界面
(8)出库信息管理功能实现
操作人员选择目标物资后填写出库数量与出库备注,系统检查出库数量是否超过当前库存。库存充足时执行出库操作,对应物资的库存余额扣减相应数量。出库记录保存操作人员与出库备注,库存不足时系统拒绝操作并提示。出库信息管理界面如图5-8所示。
图5-8 出库信息管理界面
(9)调度申请管理功能实现
操作人员发起运输资源调配请求,填写申请标题与申请详情后提交系统。系统生成申请编号并将状态设置为待处理,申请单推送至运营主管的工作台。操作人员在申请列表中查看每个申请的处理进度与审核结果。调度申请管理界面如图5-9所示。
图5-9 调度申请管理界面
5.2运营主管功能实现
(1)返货申请管理功能实现
运营主管查看所有待审核的返货申请记录,点击条目后展示完整的申请详情与申请原因。根据申请内容决定通过或驳回,通过时系统自动生成返货订单并关联原申请编号。驳回操作需要填写驳回理由,反馈信息返回给申请用户。返货申请管理界面如图5-10所示。
图5-10 返货申请管理界面
(2)返货订单管理功能实现
运营主管查看所有已生成的返货订单,列表展示返货标题、申请时间、申请用户等字段。支持按时间范围与审核状态筛选订单,点击订单条目可查看完整的申请详情与处理记录。运营主管对订单信息进行必要的修改操作。返货订单管理界面如图5-11所示。
图5-11 返货订单管理界面
(3)包装信息管理功能实现
运营主管查看操作人员录入的所有包装信息记录,列表按录入时间倒序排列。支持按信息标题与包装编号进行搜索,快速定位特定包装记录。运营主管对已保存的包装信息执行编辑或删除操作,确保包装数据的准确性。包装信息管理界面如图5-12所示。
图5-12 包装信息管理界面
(4)签单信息管理功能实现
业务完成后的签单确认数据通过此模块进行维护。运营主管填写签单标题与签单编号,补充签单详情与签单备注。系统保存签单记录时自动捕获签单时间与签单用户,已保存的签单信息支持后续编辑更新。签单信息管理界面如图5-13所示。
图5-13 签单信息管理界面
(5)异常录入管理功能实现
运营主管查看所有上报的异常记录,列表展示异常标题、异常编号、录入时间等信息。点击记录后查看完整的异常详情,分析异常原因后填写处理备注。系统将异常状态更新为已解决,保存完整的异常处理轨迹供后续追溯。异常录入管理界面如图5-14所示。
图5-14 异常录入管理界面
(6)合作网点管理功能实现
运营主管维护物流协作单位的基本信息,新增网点时填写网点名称、所在地址、网点详情等字段。系统生成网点编号并将记录保存至数据库。已保存的网点信息支持编辑与删除操作,网点列表按录入时间倒序排列展示。合作网点管理界面如图5-15所示。
图5-15 合作网点管理界面
(7)库存信息管理功能实现
运营主管查看所有物资的库存状况,列表展示物资编号、物资名称、物资类型、当前库存等字段。系统在库存低于设定阈值时显示预警标识,运营主管根据预警信息安排补货或调配。支持按物资名称与物资类型进行筛选查询。库存信息管理界面如图5-16所示。
图5-16 库存信息管理界面
(8)入库信息管理功能实现
运营主管查看所有入库操作记录,列表展示物资名称、物资类型、入库数量、操作人员等信息。支持按物资名称与物资类型筛选入库记录,点击记录可查看完整的入库详情与来源信息。运营主管审核入库记录的正确性。入库信息管理界面如图5-17所示。
图5-17 入库信息管理界面
(9)出库信息管理功能实现
运营主管查看所有出库操作记录,列表展示物资名称、物资类型、出库数量、出库备注等信息。支持按物资名称与物资类型筛选出库记录,系统展示每条出库记录的详细数据。运营主管核对出库记录与实际出库情况的一致性。出库信息管理界面如图5-18所示。
图5-18 出库信息管理界面
(10)大物流信息管理功能实现
运营主管整合运输环节的关键节点数据,填写物流标题后补充物流详情与发货详情。系统保存物流信息时记录录入用户与录入时间,物流信息列表按录入时间倒序排列。运营主管对已保存的物流记录执行编辑或删除操作。大物流信息管理界面如图5-19所示。
图5-19 大物流信息管理界面
(11)调度申请管理功能实现
运营主管查看所有待处理的调度申请,点击申请条目后展示完整的申请详情。评估可用资源情况后做出调度决策,资源充足时分配相应车辆或人员。资源不足时标记为待协调状态,调度结果通过消息反馈给申请用户。调度申请管理界面如图5-20所示。
图5-20 调度申请管理界面
5.3管理员功能实现
(1)业务受理管理功能实现
管理员创建业务工单并指派给处理人员,填写工单编号与业务标题后选择工单类型。补充工单详情与工单备注,系统保存工单信息时记录受理时间与录入人员。已创建的工单支持编辑与删除操作,工单状态跟踪处理进度。业务受理管理界面如图5-21所示。
图5-21 业务受理管理界面
(2)返货申请管理功能实现
管理员查看系统中所有的返货申请记录,不受审核状态与申请用户的限制。列表展示申请标题、申请时间、申请用户、审核状态等字段,支持多条件组合筛选。管理员对异常申请进行干预处理,修改审核状态或删除无效申请。返货申请管理界面如图5-22所示。
图5-22 返货申请管理界面
(3)返货订单管理功能实现
管理员查看所有已生成的返货订单,列表展示返货标题、申请时间、申请原因、申请详情等字段。支持按时间范围与返货标题筛选订单,点击订单条目查看完整的申请信息与处理记录。管理员对错误订单执行删除或状态修正操作。返货订单管理界面如图5-23所示。
图5-23 返货订单管理界面
(4)包装信息管理功能实现
管理员查看系统中所有的包装信息记录,不受录入人员与录入时间的限制。列表展示信息标题、包装编号、录入时间、信息详情等字段,支持按信息标题与包装编号筛选。管理员对重复或错误的包装记录执行删除操作。包装信息管理界面如图5-24所示。
图5-24 包装信息管理界面
(5)签单信息管理功能实现
管理员查看所有的签单确认记录,列表展示签单标题、签单编号、签单时间、签单用户等字段。支持按签单标题与签单编号筛选记录,点击记录查看完整的签单详情与签单备注。管理员对异常签单记录执行编辑或删除操作。签单信息管理界面如图5-25所示。
图5-25 签单信息管理界面
(6)异常录入管理功能实现
管理员查看所有上报的异常记录,不受处理状态与录入用户的限制。列表展示异常标题、异常编号、录入时间、异常详情等字段,支持多条件组合筛选。管理员对长期未处理的异常进行督办,修改异常状态或删除无效记录。异常录入管理界面如图5-26所示。
图5-26 异常录入管理界面
(7)报表信息管理功能实现
管理员生成周期性的业务统计报表,选择报表标题与报表类型后设定统计时间范围。系统根据入库记录、出库记录、返货申请等业务数据自动生成统计报表。报表内容包括各项业务指标的汇总数值,支持报表导出与打印功能。报表信息管理界面如图5-27所示。
图5-27 报表信息管理界面
(8)合作网点管理功能实现
管理员维护所有的合作网点信息,不受录入人员与网点状态的限制。列表展示网点名称、网点编号、所在地址、网点详情等字段,支持按网点名称与网点编号筛选。管理员对不再合作的网点执行删除操作,批量导入网点数据减少录入工作量。合作网点管理界面如图5-28所示。
图5-28 合作网点管理界面
(9)库存信息管理功能实现
管理员查看所有物资的库存状况,列表展示物资编号、物资名称、物资类型、当前库存等字段。支持按物资名称与物资类型筛选,系统在库存低于设定阈值时展示预警标识。管理员对库存数据进行批量调整,修正盘点差异后保存更新。库存信息管理界面如图5-29所示。
图5-29 库存信息管理界面
(10)入库信息管理功能实现
管理员查看所有的入库操作记录,不受操作人员与物资类型的限制。列表展示物资名称、物资类型、入库数量、操作人员等字段,支持多条件组合筛选。管理员对错误入库记录执行删除或数量修正操作,确保入库台账与实际库存一致。入库信息管理界面如图5-30所示。
图5-30 入库信息管理界面
(11)出库信息管理功能实现
管理员查看所有的出库操作记录,列表展示物资名称、物资类型、出库数量、出库备注等字段。支持按物资名称与物资类型筛选记录,系统展示每条出库记录的完整信息。管理员对异常出库记录进行审核与修正,删除重复记录后更新库存数据。出库信息管理界面如图5-31所示。
图5-31 出库信息管理界面
(12)大物流信息管理功能实现
管理员查看所有的大物流信息记录,不受录入用户与录入时间的限制。列表展示物流标题、录入时间、物流详情、发货详情等字段,支持按物流标题筛选。管理员对过时或错误的物流信息执行删除操作,批量导入物流数据提升维护效率。大物流信息管理界面如图5-32所示。
图5-32 大物流信息管理界面
6系统测试
6.1测试目的及意义
系统测试的主要目的就是检验宅急送新BOS系统的功能实现是否满足需求规格说明书的要求。测试工作包含返货申请从提出到审核全部过程,检验入库出库操作引起的库存变化数据是否一致。边界条件测试主要对异常录入时字段校验逻辑进行检验,对调度申请在资源不足情况下的处理分支进行检验。分布式数据库应用研究中,把测试环节当作系统稳定性保障的方面。业务规则匹配度测试检验运营主管审核权限和操作人员提交权限的隔离性,保证不同的角色只能访问被授权的功能模块。测试活动还会对模块间低耦合进行考察,返货订单模块的修改不会影响到库存信息模块的正常工作。
6.2测试方法
系统测试使用黑盒测试法,测试用例按照需求文档中给出的功能描述来设计[20]。功能测试包含操作人员、运营主管、管理员这三个角色所有的核心用例,每一个功能模块设计出正常流程和异常流程两种测试数据。集成测试是对模块之间数据传递是否正确进行的测试,返货申请审核通过之后检验订单模块能否正确接收数据。回归测试是在缺陷修复之后进行的,用来检查修改并没有产生新的问题。测试环境搭建在本地开发机上,所用JDK版本和数据库配置都与实际运行环境相同。测试过程中记录每一个用例实际结果和预期结果之间的差别,把缺陷严重程度分成致命、严重、一般、轻微这四个等级。
6.3测试用例设计
返货申请管理测试用例验证操作人员提交返货请求时系统的处理能力。该模块核心功能包括正常提交、字段校验、审核流转与驳回处理四个测试点。返货申请管理功能测试如表6-1所示。
表6-1 返货申请管理测试用例
| 模块 | 功能点 | 操作 | 预期结果 | 结论 |
| 返货申请管理 | 正常提交申请 | 填写返货标题后补充申请原因与申请详情,点击提交按钮 | 系统保存申请记录,列表中出现新数据且审核状态为未审核 | 符合预期 |
| 返货申请管理 | 必填字段校验 | 不填写返货标题直接点击提交 | 系统弹出提示信息,要求填写返货标题 | 符合预期 |
| 返货申请管理 | 审核通过流转 | 运营主管进入申请列表,选择待审核记录后点击通过 | 系统自动生成返货订单,订单列表中出现对应记录 | 符合预期 |
| 返货申请管理 | 审核驳回处理 | 运营主管选择待审核记录,填写驳回理由后点击驳回 | 申请状态变更为已驳回,驳回理由反馈给申请用户 | 符合预期 |
入库信息管理测试用例验证操作人员执行入库操作时系统的数据一致性保障能力。测试覆盖正常入库、异常输入拦截、重复请求处理与操作日志记录四个场景。入库信息管理功能测试如表6-2所示。
表6-2 入库信息管理测试用例
| 模块 | 功能点 | 操作 | 预期结果 | 结论 |
| 入库信息管理 | 正常执行入库 | 选择目标物资后填写入库数量与入库备注,点击提交 | 对应物资的库存余额增加相应数量,入库记录保存成功 | 符合预期 |
| 入库信息管理 | 负数数量拒绝 | 填写负数入库数量后点击提交 | 系统拒绝操作并提示数量不合法 | 符合预期 |
| 入库信息管理 | 重复提交处理 | 短时间内连续两次提交相同的入库请求 | 系统正确处理两次请求,库存累加两次 | 符合预期 |
| 入库信息管理 | 操作日志记录 | 执行入库操作后查看记录详情 | 入库记录包含操作人员与操作时间字段 | 符合预期 |
返货申请审核测试用例验证运营主管审批权限的执行正确性。测试点包括待审核列表加载、申请详情查看、批量审核操作与审核历史追溯四个方面。返货申请审核测试如表6-3所示。
表6-3 返货申请审核测试用例
| 模块 | 功能点 | 操作 | 预期结果 | 结论 |
| 返货申请审核 | 查看待审核列表 | 运营主管进入返货申请管理页面 | 系统展示所有审核状态为未审核的申请记录 | 符合预期 |
| 返货申请审核 | 申请详情查看 | 点击申请列表中的某条记录 | 系统弹出详情窗口展示完整的申请内容与申请原因 | 符合预期 |
| 返货申请审核 | 批量审核操作 | 勾选多条待审核记录后点击批量审核 | 系统依次处理每条申请,通过后生成对应订单 | 符合预期 |
| 返货申请审核 | 审核历史追溯 | 查看已审核通过的申请记录 | 系统展示审核时间与审核人员信息 | 符合预期 |
调度申请管理测试用例验证从申请提交到资源分配的完整业务链路。测试覆盖申请提交、资源充足分配、资源不足处理与结果反馈通知四个关键节点。调度申请管理测试如表6-4所示。
表6-4 调度申请管理测试用例
| 模块 | 功能点 | 操作 | 预期结果 | 结论 |
| 调度申请管理 | 申请提交 | 操作人员填写调度标题与调度详情后提交 | 系统生成申请编号,状态设置为待处理 | 符合预期 |
| 调度申请管理 | 资源充足分配 | 运营主管评估申请后选择资源充足选项 | 申请状态更新为已调度,分配资源信息保存 | 符合预期 |
| 调度申请管理 | 资源不足处理 | 运营主管评估后选择资源不足选项 | 申请状态变更为待协调,等待资源到位 | 符合预期 |
| 调度申请管理 | 结果反馈通知 | 运营主管完成调度操作后 | 申请用户收到调度结果的消息通知 | 符合预期 |
业务受理管理测试用例验证管理员创建与分配业务工单的操作正确性。测试点包括工单创建、工单指派、工单编辑与工单删除四个核心功能。业务受理管理测试如表6-5所示。
表6-5 业务受理管理测试用例
| 模块 | 功能点 | 操作 | 预期结果 | 结论 |
| 业务受理管理 | 工单创建 | 管理员填写工单编号与业务标题,选择工单类型后提交 | 系统保存工单信息,状态初始设置为待受理 | 符合预期 |
| 业务受理管理 | 工单指派 | 管理员选择已创建的工单后指派给特定处理人员 | 工单记录中包含被指派人员信息 | 符合预期 |
| 业务受理管理 | 工单编辑 | 管理员修改已创建工单的业务标题或工单详情后保存 | 系统更新工单信息并同步修改更新时间戳 | 符合预期 |
| 业务受理管理 | 工单删除 | 管理员选择已完成的工单执行删除操作 | 工单记录从列表中移除,不再显示 | 符合预期 |
6.4测试结论
经过上述五个测试用例的测试之后,返货申请管理的正常提交、审核流转功能均能正常运行,必填字段校验逻辑也能够有效地阻止非法输入。入库信息管理中库存更新、日志记录均符合预期,负数数量被系统拒绝,重复提交也得到了正确的处理。返货申请审核列表加载及批量操作均能正常进行,详情展示以及历史追溯数据也完整。调度申请管理从提交到资源分配的全流程畅通,资源不足的时候,待协调状态会自动转为待处理的状态。业务受理管理创建、指派、编辑、删除操作均满足要求,工单状态流转无误。全部测试用例结果均符合预期,系统主要功能模块运行正常。

174

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



