「课设设计」springboot校园超市助购系统26449 （附源码）

摘要

校园超市传统运营模式存在高峰期排队严重、商品信息不对称、库存管理滞后等主要问题。移动互联网技术的发展给校园零售场景的改善赋予了新的解决办法。微信小程序因为轻量化、即用即走的特点，是连接学生用户和校园服务的绝佳载体。本文用springboot框架和微信小程序相结合的方式，创建出一个适合校园环境的助购系统。该系统把商品浏览、在线下单、订单配送、售后管理这些主要部分融合起来，试图改善校园超市高峰期的拥挤状况，加快商品流转速度。系统使用前后端分离架构，后端给数据接口服务提供稳定的环境，前端实现方便的交互体验。

通过普通用户、商家用户、骑手用户、管理员四个角色功能的划分，实现了商品上架到订单完成整个业务流程。普通用户可以对商品进行选择、购买购物车、支付下单、订单查询和售后服务申请等操作。商家用户可以对商品进行管理、订单处理、配送调度和统计分析。骑手用户主要对订单的配送环节有状态改变和路径确认两种关注。管理员做系统配置、用户管理、数据监控等工作。系统使用关系型数据库来存储用户信息、商品数据、订单记录等主要业务数据，并且用规范化的结构来保证数据的完整性和一致性。经过功能测试和流程验证，系统可以满足校园超市日常运营的基本要求，为类似场景提供设计参考。

关键词：校园超市；助购系统；springboot；微信小程序；订单管理

Abstract

There are many problems with the current operating mode of the campus supermarket, such as long queues during peak hours, one-sided product information and slow inventory management. New ways have been found to optimise the campus retail model with the development of mobile internet technology. WeChat Mini Programs are light in weight and convenient to use, so they have been used to connect college students with various services on campus. Spring Boot and WeChat Mini Programs will be employed to build a shopping assistant system for the campus in this paper. The four main parts of the system are product display, online ordering, order delivery and after-sales service, etc., which will help reduce congestion in campus supermarkets during peak times and improve product turnover rate. The architecture of the system has two parts, a front end and a back end; that is to say, the back end will provide a stable data service for the front end to use.

Four roles have been set up to cover all links in the business, from listing products by regular users, merchant users, rider users, administrators, etc. Ordinary users can select products, manage their shopping cart, pay for purchases, track orders and use after-sales services, etc. New features for the merchant are the management of products, orders and delivery schedules, etc. Rider users only need to know that the order has been completed and confirmed. The club's management and operation are handled by the administrators. The main business data in the system, such as user information, product information and order information, are all in a relational database and need to be well-organised. After the function test and process verification, it has met the basic operating requirements of the campus supermarket and can be used as a reference design solution for other similar projects.

Keywords: Campus supermarket; Shopping assistance system; springboot; WeChat mini-program; Order management

1绪论

1.1研究背景与意义

1.1.1研究背景

校园超市是高校后勤服务体系的重要组成，主要起到满足师生日常消费需求的作用。传统的校园超市运营模式存在着诸多问题。营业时间集中造成午间、傍晚时段收银台排队现象严重，占用学生大量的课余时间。商品库存信息不透明，学生经常碰到目标商品缺货却不知道的原因。小型校园超市由于场地面积的限制，商品陈列的空间很小，热门的商品容易出现断货的情况，冷门的商品长时间处于堆积状态。张永宾认为基于图神经网络的商品推荐系统可以很好地解决信息过载的问题，通过对用户行为数据的分析来实现精准推送 $1$ 。姜微、任燕、薄喜柱等人的智能购物车项目式教学模式，显示了移动终端在购物场景中所具有的创新应用价值 $2$ 。这些研究结果给解决校园超市运营的痛点赋予了新的想法。移动互联网技术的发展给校园零售场景的改善带来新的力量。微信小程序凭借轻量化、即用即走的特点，很好地满足了校园场景下用户对于便捷性的需求。将线上购物流程同线下超市资源对接起来，创建出专为校园环境设计的助购系统，可以有效地减轻排队的压力，加快购物的速度。

1.1.2研究意义

研究意义有诸多方面的提高。系统把传统的线下选购排队方式变为线上浏览下单、线下配送的方式，大大缩减了学生在购物环节上所花费的时间。学生可以在课间浏览商品并下单，返回宿舍后就可以收到商品，这种改变从根本上改变了校园购物的时空限制条件。从成本控制角度来说，系统使商家可以准确地把握商品销售情况，从而避免由于进货量过大而造成的库存积压。商家根据订单数据来改变商品的结构，减少运营成本，从而达到精细化的库存管理的目的。从用户体验的角度出发，系统可以提供商品分类检索、购物车管理、订单跟踪等各方面的功能，使得购物过程更加透明可控，用户再也不需要面对售货员口头询问库存的尴尬情况。就数据价值而言，系统产生的交易数据和用户行为数据可以为校园超市改善商品摆放、制订促销计划赋予决策支撑，促使校园零售由经验引领走向数据主导。该系统给高校后勤服务信息化转型提供了一种可行的技术方案，对其他的校园服务场景线上化改造也有一定的借鉴意义。

1.2国内外研究现状

1.2.1国内现状

国内在线购物系统由最初的资讯展示、交易闭环发展到现在的场景化服务。早期的电商平台主要做商品信息的展示，用户浏览完之后还要到线下进行交易，信息流和资金流是分开的。垂直电商兴起时期，系统才开始整合全部交易功能，用户可以在线完成浏览、下单到付款的所有步骤。移动互联网普及之后，购物系统朝着场景化方向发展，以某一类用户群体和某一场景为对象的垂直购物平台不断出现。郭一凡、田佳卉用实证研究的方法得出结论，个性化推荐系统可以提高消费者的购买决策速度，减少用户在商品选择时所花费的时间 $3$ 。章裔杰、张璐、陈晓丰从技术架构角度出发，将区块链技术应用到在线购物系统上，探究用户隐私保护与交易匿名化的途径 $4$ 。熊晨惠博士论文从在线购物店铺视觉设计要素入手，得出结论界面色彩搭配、布局结构等都会对顾客忠诚度造成影响 $5$ 。殷继旺对AI个性化推荐体验对于消费者在线购物行为意向的影响机制做了详细的分析，发现推荐透明度和用户信任之间存在一定的关系 $6$ 。刘子锐、朱雯以家庭助购APP为例，研究了购物UI界面设计和应急场景下硬件设备交互逻辑 $7$ 。这些研究从推荐算法、隐私保护、视觉设计、行为分析、人机交互等各个方面丰富了国内购物系统理论。

1.2.2国外现状

国外购物系统研究开始得比较早，其发展脉络是社交购物向数据驱动转变的过程。早期的国外购物平台主要是社交属性的加入，用户可以在购物的过程中和朋友一起分享购物过程中的感受，把购物的过程变成一种社交体验。大数据技术成熟之后，购物系统就加强了对数据的采集分析能力，用用户行为数据来改进商品排序和推荐策略。Rizomyliotis认为消费者信任机制，用大样本调查数据分析在线购物平台中用户信任建立的影响因素，得出平台透明度和第三方认证会起到正向调节作用 $8$ 。在奢侈零售领域出现了一个个人导购转变为全球品牌转型的典型事例，Camila Cecilio建立的Naise Shopper重新构建了高端零售的线上接入方式，该模式证明个性化购物助手可以大大提高高端用户的消费转化率 $9$ 。2018年黑色星期五购物指南的作者Jullie Hair提出了把季节性促销和内容营销结合起来的做法 $10$ 。Haibo L创建了焦虑心理效应模型，剖析人性化在线导购系统里界面友好度同用户情绪状态之间的联系机制，得出结论显示适度的交互反馈可以减轻用户在决策过程中产生的焦虑情绪 $11$ 。Duan和Cui把UWB技术应用到智能超市导购系统当中，可以实现用户在店内厘米级的定位以及商品路径的导航 $12$ 。国外的研究更多地从跨学科理论融合的角度出发，把心理学、行为经济学的研究成果运用到购物系统的设计中，形成了以技术驱动和理论驱动为主的研究局面。

1.3主要研究内容

本文主要的工作就是设计并实现一个基于springboot和微信小程序的校园超市助购系统。系统开发按照软件工程的标准流程进行。需求分析阶段确定普通用户、商家用户、骑手用户、管理员这四个角色的功能界限以及交互关系。架构设计阶段采用前后端分离模式，后端用springboot框架搭建RESTful API接口，前端用微信小程序原生框架开发用户界面。根据需求分析结果创建关系型数据库，用MySQL存储用户的个人信息、商品信息、订单信息等主要业务数据。系统实现阶段将用户认证、商品管理、购物车、订单处理、配送追踪、售后管理等各个功能模块的编码任务分别完成。测试验证阶段根据各个功能模块编写测试用例，进行功能测试和流程测试。研究侧重点是订单全流程状态管理机制和多角色协同业务闭环的设计。系统中没有复杂的推荐算法实现，也没有与第三方支付接口的深度对接，支付环节使用模拟支付的方式进行流程验证。最终交付的产品是可运行的系统原型、数据库的设计文档和完整的测试报告。系统采用前后端分离的技术路线，前端发出请求，后端处理业务逻辑并返回数据，该模式给后续功能的扩展留有余地。

2相关技术介绍

2.1SpringBoot框架

springboot框架是基于spring生态体系发展起来的。该框架利用自动化的配置机制，把传统spring应用开发中繁杂的配置工作简化了。项目构建阶段springboot提供起步依赖机制，开发者只需要在配置文件中声明需要的依赖，框架就会自动引入相关的依赖库并完成默认配置。嵌入式容器设计让应用可以独立运行，不需要放到外部容器里。在运行的时候，springboot框架内部会有一个IoC容器来管理应用中对象的实例以及它们之间的依赖关系。Springboot框架的主要机制就是条件化的配置，在系统启动的时候会按照当前类路径下依赖情况来决定是否加载某个配置。在请求响应机制中 $13$ springboot通过DispatcherServlet接收前端请求，将请求分发给对应的控制器方法处理。控制器方法执行业务逻辑之后返回数据，然后由框架把数据转换成JSON格式的响应发送给客户端。springboot可以集成多种数据访问技术来简化数据库操作的过程。

2.2微信小程序

微信小程序是不需要下载安装就可以使用的应用形态。小程序运行环境依靠微信客户端，用户通过扫码或者搜索名称就可以进入应用界面。小程序的架构是分逻辑层和视图层两大部分的。逻辑层是处理业务逻辑和数据管理的，运行在独立的JavaScript引擎上。视图层主要是对页面进行渲染以及事件的处理，使用WebView来完成。两层之间用事件和数据绑定的方式进行通信。小程序启动的时候，框架会加载应用的配置信息，按照页面路径来渲染对应的界面。小程序开发使用MVVM模式，数据发生变化的时候会自动同步到视图层，视图层的事件也会反向触发逻辑层的函数执行。对于校园超市助购系统来说，小程序端要完成用户的登录、商品展示、下单支付等一系列的交互操作。小程序框架具有很多原生组件和API接口，表单组件、媒体组件、开放能力接口等都是其中的。可以直接调用微信客户端底层功能，不需要开发者自己实现。小程序的更新方式为异步下载，用户下一次打开的时候会自动加载最新的版本 $14$ 。

2.3MySQL数据库

MySQL属于关系型数据库管理系统。该数据库用表格的形式来存储数据，表和表之间通过主键外键来建立关联关系。MySQL把数据保存在磁盘文件里，并且利用缓冲池来提升读写速度。在查询处理的过程中，MySQL的解析器会对SQL语句进行词法分析和语法分析，得到执行计划。优化器按照表的索引信息来统计信息，然后选择合适的执行路径。存储引擎层完成数据的真正读写工作，InnoDB是MySQL的默认存储引擎。该引擎支持事务处理，用redo日志保证数据的持久性，用undo日志支持事务回滚。并发控制上 $15$ InnoDB用的是行级锁，不同的事务可以同时对不同的行进行修改。对校园超市助购系统数据存储需求而言，MySQL可以保存用户的账号信息、商品基础数据、订单记录、购物车内容等结构化数据。数据库设计要遵照范式规范，削减数据冗余。MySQL支持主从复制架构，可以把主数据库的数据变更同步到从数据库。

2.4JSON数据交换格式

JSON是轻量级的数据交换格式。该格式用完全不用编程语言的方式表达数据结构。JSON的数据结构有对象和数组两种形式。对象是由键值对组成的集合，键名用双引号括起来，值可以是字符串、数字、布尔值、对象数组或者空值。数组是有序的值组成的集合，用逗号分隔。前后端分离架构中JSON起数据传输载体的作用。前端发送请求的时候，把参数组装成JSON字符串放到请求体里。后端收到请求之后，框架就会自动把JSON字符串解析成Java对象。控制器方法返回数据的时候，框架会把数据序列化成JSON字符串然后返回给前端。这就使得不同的编程语言编写的模块可以互相交流。对于校园超市助购系统接口设计来说，商品信息查询接口返回的JSON对象里有商品标识、商品名称、商品价格、库存数量这些字段。订单提交接口接收到的JSON对象里有用户标识、商品列表、收货地址这些信息。JSON格式的可读性较好，在开发调试时可以人工查看数据内容。与XML格式相比，JSON的数据量小、传输快 $16$ 。

3系统分析

3.1可行性分析

3.1.1技术可行性

系统使用springboot框架搭建后端服务，springboot提供完整的web开发方案。springboot的自动配置机制简化了项目搭建的过程，内嵌的Tomcat容器使应用可以独立运行。微信小程序前端框架已经比较成熟稳定，组件库比较丰富，可以满足校园超市购物场景下交互的需求。MySQL数据库和springboot框架集成度高，使用JPA或者MyBatis等持久层框架可以简化数据库操作的代码。开发工具方面使用的是IntelliJ IDEA以及微信开发者工具这两个成熟的、可靠的开发环境。前后端分离的架构模式可以使开发工作可以并行进行，降低模块间耦合的程度。系统使用用户认证、数据存储、接口通信等技术都有成熟的实现方案。就技术储备来说，现有的技术体系完全可以支撑本系统开发。

3.1.2操作可行性

系统主要面向的是在校学生，该群体对于智能手机的操作比较熟练，具有使用微信小程序的基础能力。小程序界面采用的是卡片式的布局方式以及底部导航栏的形式，符合移动端应用的主流交互方式。商品浏览模块有两种查找方式，即分类筛选和关键词检索。购物车功能可以对商品的数量进行调节，并能即时看到价格的变化，和大多数电商平台的操作逻辑一样。商家用户通过后台管理系统对商品进行上架、下架以及订单的处理，界面采用表单的形式，信息填写和确认的过程一目了然。骑手用户主要对订单列表、状态更新按钮进行操作，学习成本小。四种角色的界面是相互独立的，用户只能访问自己有权限的模块，从而降低误操作的风险。

3.1.3经济可行性

系统开发所需的软件工具均为免费或社区版本，包括IntelliJ IDEA社区版、微信开发者工具、MySQL Community Server。开发过程中所用到的依赖库、框架都是开源的，不需要支付授权费用。系统部署阶段可以选择云服务商提供的学生优惠套餐，初期的运营成本较低。校园超市作为运营主体，不需要采购额外的硬件设备，商家使用现有的电脑就可以完成商品管理和订单处理。系统上线之后所产生的一些维护费用主要是对服务器续费以及一些小的人员维护工作。由于系统可以带来效率的提高和排队问题的缓解，所以投入产出比是合理的。项目经济合理性的基础是低开发成本和明显的运营效益改善。

3.2功能需求分析

UML用例图是用以描述系统功能以及用户交互的一种建模工具，它用角色和用例之间的关系来表现系统在各种情况下所表现出来的行为。用例图可以直观地表现系统的边界，清楚地表示出外部的参与者和系统之间怎样进行交互。参与者代表不同的用户群体或者外部系统，用例体现系统提供的功能或者服务。该图在需求分析阶段起着重要的作用，可以使得开发者发现主要的功能，不会出现遗漏重要需求的情况。用图形化的方式表示用例图可以方便地沟通和理解，为后面系统的设计和实现提供依据。本文会就系统按角色模块做需求分析。

3.2.1普通用户角色功能需求

普通用户进入系统之后要经过注册登录的过程，才能使用购物功能。商城中心展示商品列表，用户可以按照分类筛选商品或者使用搜索功能查找特定的商品。用户在添加商品到购物车的时候可以调节购买的数量，在购物车页面上显示商品的图片、单价、数量以及总价的信息。收货地址模块可以新增地址、编辑地址、删除地址以及设置默认地址。用户提交订单之后进入支付环节，系统产生订单记录。我的订单模块显示不同的状态下的订单列表，即待付款订单、待发货订单、待签收订单、已完成订单。用户可以对还未完成的订单进行取消。订单配送模块显示配送状态，显示配送员及配送进度。通知中心接收系统发出的订单状态变动提醒。售后申请模块可以实现用户对已经签收的商品进行售后申请，填写售后原因并上传凭证。普通用户用例图如图3-1所示。

3.2.2商家用户角色功能需求

商家用户登录系统之后就可以进入商城中心管理界面，新增商品、编辑商品信息、上下架商品。商品信息有标题、价格、库存、商品图片、详情描述等。商城分类管理模块对商品所处的分类进行维护，可以新增分类也可以调整分类层级。订单管理模块可以显示所有的用户订单，商家可以根据订单的状态对订单进行筛选和处理。待发货订单要进行发货确认和配送员的指派。订单配送管理模块可以跟踪已经发出的订单的配送情况，可以查看配送员上报的位置信息。订单售后管理模块对用户提交的售后申请进行审核，判断申请内容是否符合要求，并做出通过或者拒绝的决定。后台首页会展示今日订单量、待处理订单量、商品库存警报等主要的经营数据。商家用户用例图如下图3-2所示。

3.2.3骑手用户角色功能需求

骑手用户登录之后的主要操作就是订单配送管理模块。系统根据用户订单信息进行配送分配，骑手看到订单详情，包含收货地址、联系方式和商品信息。骑手接单之后把订单状态从待处理变为配送中，系统保存接单时间和预计送达时间。配送时骑手上报位置信息，用户可以查看骑手实时位置。商品送达后，骑手完成签收确认，订单状态变更为已完成。骑手在遇到异常情况时可以向系统报备，例如不能联系到收货人或者收货地址有误。骑手用户完成订单配送之后会得到配送记录，在个人中心可以查看历史配送订单。骑手用户用例图如图3-3所示。

3.2.4管理员角色功能需求

管理员承担系统全局配置与监管职责。通知中心模块向所有用户或者指定用户群发公告。网站公告管理模块发布系统维护通知、活动公告等信息，可以设置公告的置顶和过期时间。新闻资讯管理模块发布校园超市促销信息或者新品推荐内容。资讯分类管理模块对新闻资讯进行分类整理。商城中心管理模块审核商家提交的商品信息，对违规商品进行下架处理。订单管理模块可以显示所有的订单信息，并对超时未付款的异常订单进行自动取消。订单配送管理模块对配送效率进行监控，统计骑手的配送时长。订单售后管理模块对商家处理结果进行复核，保障用户的权益。管理员用例图如图3-4所示。

3.3非功能需求分析

(1)可用性需求

可用性方面系统要有稳定的响应速度，在高并发访问的时候保证界面加载的流畅性。系统应该可以支持多平台访问，保证用户无论用什么终端都可以获得相同的使用体验。系统应该具有明显的界面结构以及简单的交互方式，以减小用户使用时的操作负担。系统需要可以持续的进行性能改善以及功能添加，在整个运行周期中维持很高的可用性。

(2)可靠性需求

从可靠性上来说，系统要有自动容错的功能，在局部故障的时候仍然可以保证主要功能的正常运转。系统要具备数据备份和恢复的策略，在出现异常的时候不会造成数据的丢失。系统要有冗余设计，保证服务不会中断。系统应该具有运行监控、日志跟踪的功能，可以对运行状况进行及时的检测和问题的定位。

(3)安全性需求

安全性上需要有访问控制机制，保证不同的用户在自己的权限范围之内进行操作。系统应该有身份认证和数据加密的功能来保证传输和存储过程中信息安全。系统要设置入侵检测和防护手段来削减可能的攻击风险。系统要具备日志审计功能，保证操作行为可以追踪到，符合合规性要求。

4系统设计

4.1系统架构设计

系统使用前后端分离的架构模式。前端使用微信小程序框架来搭建用户界面，实现数据展示和用户交互。后端基于springboot框架提供RESTful API接口，处理业务逻辑与数据存取。前后端之间用HTTP协议来传输JSON格式的数据。该种架构设计使得前端和后端开发可以同时进行，减小了模块之间的耦合度。后端应用又被分成了控制器层、服务层和数据访问层这三个层次。控制器层接收前端请求并返回响应数据。服务层对主要的业务规则进行封装，也就是订单金额的计算、库存的减去等。数据访问层是对数据库进行读写操作的 $17$ 。MySQL数据库用来存储用户的资料，商品的信息以及订单的信息。系统架构图如下图4-1所示。

4.2系统结构功能设计

系统依靠这四种用户角色来创建功能模块。普通用户可以使用注册登录、商城中心、购物车管理、收货地址管理、订单支付、我的订单、订单配送、通知中心、售后申请等。商家用户拥有商城中心管理、商城分类管理、订单管理、订单配送管理、订单售后管理、通知中心查看、后台首页访问权限。骑手用户主要用到的是订单配送管理的功能。管理员有通知中心、网站公告管理、新闻资讯管理、资讯分类管理、商城中心管理、商城分类管理、订单管理、订单配送管理、订单售后管理等权限。系统功能结构图如下图4-2所示。

4.3系统流程设计

4.3.1系统总体业务流程设计

用户进入系统之后首先要进行登录认证。普通用户浏览商品并将其添加到购物车中。用户在购物车页面确认商品数量之后提交订单。系统自动生成待支付订单，然后跳转到支付页面。用户完成支付之后，订单状态就变成了待发货。商家在后台查看待发货的订单后进行发货，系统把订单的状态变为待签收，并且给它分派了配送的任务。骑手接单后上门取货，开始配送。用户确认收货之后，订单状态就变为已完成。用户若对商品不满意可在规定时间内发起售后申请。商家对售后请求进行审核，做出处理决定。系统总体业务流程图见图4-3。

4.3.2用户下单流程设计

用户在商城中心浏览商品时可以查看商品详情页获取全部信息。确认购买意向之后用户就会把商品添加到购物车里。购物车页面汇总已经选择的商品，计算总价。用户填写收货地址，核对好商品信息之后再提交订单。系统检验商品库存是否足够。库存不足的时候提示用户调节数量。库存充足时创建订单记录并把订单状态设为待付款。系统启动支付倒计时，用户需要在规定的时间内完成支付。逾期未付款的订单会被系统自动取消。用户下单流程图如图4-4所示。

4.3.3商家发货流程设计

商家登录之后就会进入到订单管理页面。待发货订单列表显示所有的没有发货的订单。商家点击订单查看详情分为商品清单和收货信息。商家确认订单信息无误之后，就会在系统里选择配送方式。系统有商家自配送和第三方配送两种方式。选择商家自配送时需要指定一名骑手来承接该订单。指派操作完成之后，订单的状态变为待签收，并且配送信息会同步到骑手端。系统对发货时间做出记载，给用户发出发货通知。商家发货流程图4-5。

4.3.4订单配送流程设计

骑手接到系统分配的配送任务之后查看订单详情。骑手确认可以配送时点击接单按钮，订单状态变更为配送中。配送过程中骑手会定时更新位置信息，系统把位置信息发送到用户端。骑手到达收货地址后与用户取得联系取货。用户收到商品之后，骑手点击确认送达。订单状态变为已完成之后，系统对配送完成时间进行记录。若用户长时间未取货，骑手可通过系统上报异常情况。订单配送流程如图4-6所示。

4.3.5售后申请流程设计

用户登录之后就进入了我的订单页面，选择了已经签收的订单之后就可以进行售后申请。用户选择售后类型，分为退货退款和仅退款。用户填写售后原因并上传凭证图片之后提交申请。系统创建售后记录，状态设为待审核。商家在售后管理页面查看待审核的申请。商家审核申请内容，作出是否通过或拒绝的决定。审核通过之后系统按照售后类型启动退款流程。退款后售后状态变更为已完结。审核拒绝时系统会提示用户并告知拒绝的原因。售后服务申请流程图4-7如下图所示。

4.4数据库设计

数据库设计属于系统开发的基础性工作。关系型数据库用表格的方式组织数据，表之间用主键和外键来建立关联关系。数据规范化设计把信息拆分成不同的表中，防止因为数据冗余造成更新异常。数据库完成用户身份信息、商品基础数据、订单交易记录这些业务数据的持久化保存工作。数据一致性依靠事务来保证，多个数据操作要么全部成功，要么全部回滚。数据库中设置了外键约束和检查约束，不能输入非法的数据到系统中。按照数据库设计规范 $18$ ，本系统对用户表、商品表、订单表等主要表进行范式化处理，保证数据存取的合理。

4.4.1E-R图设计

实体图是用图形化的方式表现业务要素及其相关数据的建模工具，在数据库设计阶段把需求转化为结构化的可视化表达。它用节点代表业务实体，边代表实体间的关联关系，在节点内列出关键属性，直观地表现出数据模型的全部面貌，有利于快速发现冗余之处并理清依赖，给之后的逻辑设计和物理实现赋予清晰的蓝图。下面将给出系统的全局实体图以及各个主要实体的属性图。

商品信息实体主要包括商品编号、标题、封面图、描述、原价、卖价、销量、库存、商品分类、点击量、正文、主图1、主图2、主图3、主图4、主图5、创建时间、更新时间、来源表、来源字段、来源编号、添加人、上架状态。实体属性图如图4-8所示。

订单实体主要包括订单编号、收件地址、联系人邮箱、联系人姓名、联系人手机、创建时间、发货状态、取消原因、描述、商品编号、商品图片、商家编号、规格、数量、订单号、邮政编码、价格、原价、总价、备注、订单状态、商品标题、商品分类、更新时间、买家编号。实体属性图如图4-9所示。

收货地址实体主要包括地址编号、姓名、手机、邮编、地址、用户编号、创建时间、更新时间、默认判断。实体属性图如图4-10所示。

购物车实体主要包括购物车编号、标题、图片、用户编号、创建时间、更新时间、状态、单价、原价、总价、数量、商品编号、商品分类、描述、规格。实体属性图如图4-11所示。

订单售后实体主要包括订单售后编号、订单编号、订单号、商品编号、商品标题、价格、原价、数量、总价、买家编号、商家编号、订单状态、售后状态、售后回复、售后类型、售后内容、售后凭证、创建时间、更新时间。实体属性图如图4-12所示。

普通用户实体主要包括普通用户编号、用户姓名、用户年龄、用户性别、审核状态、用户编号、创建时间、创建用户编号、更新时间。实体属性图如图4-13所示。

商家用户实体主要包括商家用户编号、商家名称、商家地址、负责人员、资质证明、审核状态、用户编号、创建时间、创建用户编号、更新时间。实体属性图如图4-14所示。

骑手用户实体主要包括骑手用户编号、骑手年龄、创建用户编号、创建时间、审核状态、手机号码、资质材料、骑手性别、骑手姓名、更新时间、用户编号。实体属性图如图4-15所示。

用户账户实体主要包括头像地址、创建时间、邮箱、邮箱认证状态、上次登录时间、昵称、openid、密码、手机号码、手机认证状态、账户状态、用户组、用户编号、用户名。实体属性图如图4-16所示。

4.4.2数据库表设计

数据库表设计就是按照业务需求来确定数据库表的结构、字段类型和关系。经过规范化的设计之后，可以保证数据的完整、一致以及高效，而且不会产生重复的数据，并且可以给之后的数据查询、存储以及维护工作提供一个清晰的框架**** $19$ ****。以下是系统的数据库表设计展示。

商品信息表主要用于存储商品的详细信息。主要包括商品编号、标题、卖价、库存等字段。如表4-1所示。

表4-1 商品信息表

|----|-------------|-----------|------------|------|------|-------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | goods_id | mediumint | - | 是 | 是 | 产品ID |
| 2 | title | varchar | 125 | 否 | 否 | 商品标题 |
| 3 | img | text | 65535 | 否 | 否 | 列表页显示 |
| 4 | description | varchar | 255 | 否 | 否 | 商品描述 |
| 5 | price_ago | double | - | 是 | 否 | 商品原价 |
| 6 | price | double | - | 是 | 否 | 销售价格 |
| 7 | sales | int | - | 是 | 否 | 累计销量 |
| 8 | inventory | int | - | 是 | 否 | 商品库存 |
| 9 | type | varchar | 64 | 是 | 否 | 分类名称 |
| 10 | hits | int | - | 是 | 否 | 浏览次数 |
| 11 | content | longtext | 4294967295 | 否 | 否 | 详情内容 |
| 12 | create_time | timestamp | - | 是 | 否 | 录入时间 |
| 13 | update_time | timestamp | - | 是 | 否 | 修改时间 |
| 14 | list_status | smallint | - | 否 | 否 | 下架或上架 |
| 15 | user_id | int | - | 否 | 否 | 商家编号 |

订单表主要用于存储用户提交的订单信息。主要包括订单编号、订单号、订单状态、总价等字段。如表4-2所示。

表4-2 订单表

|----|-----------------|-----------|-----|------|------|---------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | order_id | int | - | 是 | 是 | 订单ID |
| 2 | order_number | varchar | 64 | 否 | 否 | 业务订单号 |
| 3 | state | varchar | 16 | 是 | 否 | 待付款待发货等 |
| 4 | price_count | double | - | 是 | 否 | 订单总金额 |
| 5 | num | int | - | 是 | 否 | 商品总数 |
| 6 | title | varchar | 255 | 否 | 否 | 商品名称 |
| 7 | goods_id | mediumint | - | 是 | 否 | 关联商品 |
| 8 | merchant_id | mediumint | - | 是 | 否 | 关联商家 |
| 9 | user_id | int | - | 是 | 否 | 关联用户 |
| 10 | contact_address | varchar | 255 | 否 | 否 | 配送地址 |
| 11 | contact_name | varchar | 32 | 否 | 否 | 收货人 |
| 12 | contact_phone | varchar | 11 | 否 | 否 | 联系电话 |
| 13 | create_time | timestamp | - | 是 | 否 | 下单时间 |
| 14 | update_time | timestamp | - | 是 | 否 | 状态变更时间 |
| 15 | delivery_state | varchar | 16 | 否 | 否 | 未配送或已配送 |

收货地址表主要用于存储用户的收货地址信息。主要包括收货地址编号、姓名、手机、地址等字段。如表4-3所示。

表4-3 收货地址表

|----|-------------|-----------|-----|------|------|-------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | address_id | int | - | 是 | 是 | 地址ID |
| 2 | name | varchar | 32 | 否 | 否 | 收货人姓名 |
| 3 | phone | varchar | 13 | 否 | 否 | 联系电话 |
| 4 | address | varchar | 255 | 是 | 否 | 详细地址 |
| 5 | postcode | varchar | 8 | 否 | 否 | 邮政编码 |
| 6 | user_id | mediumint | - | 是 | 否 | 所属用户 |
| 7 | default | tinyint | - | 是 | 否 | 是否为默认 |
| 8 | create_time | timestamp | - | 是 | 否 | 添加时间 |

购物车表主要用于临时存储用户选中的商品。主要包括购物车编号、用户编号、商品编号、数量等字段。如表4-4所示。

表4-4 购物车表

|----|-------------|-----------|----|------|------|--------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | cart_id | int | - | 是 | 是 | 购物车ID |
| 2 | user_id | int | - | 是 | 否 | 所属用户 |
| 3 | goods_id | mediumint | - | 是 | 否 | 关联商品 |
| 4 | num | int | - | 是 | 否 | 购买数量 |
| 5 | price | double | - | 是 | 否 | 商品单价 |
| 6 | price_count | double | - | 是 | 否 | 小计金额 |
| 7 | title | varchar | 64 | 否 | 否 | 商品标题 |
| 8 | norms | varchar | 64 | 否 | 否 | 商品规格 |
| 9 | state | int | - | 是 | 否 | 使用中或失效 |
| 10 | create_time | timestamp | - | 是 | 否 | 添加时间 |

订单售后表主要用于存储用户发起的售后申请。主要包括订单售后编号、订单编号、售后状态、售后类型等字段。如表4-5所示。

表4-5 订单售后表

|----|---------------------|-----------|------|------|------|---------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | order_after_sale_id | int | - | 是 | 是 | 售后ID |
| 2 | order_id | int | - | 是 | 否 | 关联订单 |
| 3 | after_state | varchar | 16 | 否 | 否 | 未审核已通过等 |
| 4 | type | varchar | 255 | 否 | 否 | 退货退款等 |
| 5 | content_desc | varchar | 255 | 否 | 否 | 申请原因 |
| 6 | imgs | varchar | 1000 | 否 | 否 | 图片证据 |
| 7 | user_id | int | - | 是 | 否 | 申请用户 |
| 8 | merchant_id | mediumint | - | 是 | 否 | 处理商家 |
| 9 | after_state_reply | varchar | 255 | 否 | 否 | 处理意见 |
| 10 | create_time | timestamp | - | 是 | 否 | 申请时间 |

用户账户表主要用于存储系统用户的登录信息。主要包括用户编号、用户名、密码、用户组等字段。如表4-6所示。

表4-6 用户账户表

|----|-------------|-----------|-----|------|------|-------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | user_id | int | - | 是 | 是 | 用户ID |
| 2 | username | varchar | 16 | 是 | 否 | 登录账号 |
| 3 | password | varchar | 64 | 是 | 否 | 加密存储 |
| 4 | user_group | varchar | 32 | 否 | 否 | 角色标识 |
| 5 | nickname | varchar | 16 | 否 | 否 | 显示名称 |
| 6 | avatar | varchar | 255 | 否 | 否 | 头像图片 |
| 7 | phone | varchar | 11 | 否 | 否 | 联系电话 |
| 8 | email | varchar | 64 | 否 | 否 | 电子邮箱 |
| 9 | state | smallint | - | 是 | 否 | 可用或冻结 |
| 10 | create_time | timestamp | - | 是 | 否 | 注册时间 |

普通用户表主要用于存储普通用户的扩展信息。主要包括普通用户编号、用户姓名、用户年龄、用户性别等字段。如表4-7所示。

表4-7 普通用户表

|----|-----------------|-----------|----|------|------|--------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | regular_user_id | int | - | 是 | 是 | 普通用户ID |
| 2 | user_name | varchar | 64 | 否 | 否 | 用户姓名 |
| 3 | user_age | varchar | 64 | 否 | 否 | 用户年龄 |
| 4 | user_gender | varchar | 64 | 否 | 否 | 用户性别 |
| 5 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 6 | user_id | int | - | 是 | 否 | 用户ID |
| 7 | create_time | datetime | - | 是 | 否 | 创建时间 |
| 8 | update_time | timestamp | - | 是 | 否 | 更新时间 |

商家用户表主要用于存储商家用户的扩展信息。主要包括商家用户编号、商家名称、商家地址、负责人员等字段。如表4-8所示。

表4-8 商家用户表

|----|---------------------------|-----------|-----|------|------|--------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | merchant_user_id | int | - | 是 | 是 | 商家用户ID |
| 2 | merchant_name | varchar | 64 | 否 | 否 | 商家名称 |
| 3 | business_address | varchar | 64 | 否 | 否 | 商家地址 |
| 4 | responsible_personnel | varchar | 64 | 否 | 否 | 负责人员 |
| 5 | qualification_certificate | varchar | 255 | 否 | 否 | 资质证明 |
| 6 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 7 | user_id | int | - | 是 | 否 | 用户ID |
| 8 | create_time | datetime | - | 是 | 否 | 创建时间 |
| 9 | update_time | timestamp | - | 是 | 否 | 更新时间 |

骑手用户表主要用于存储骑手用户的扩展信息。主要包括骑手用户编号、骑手姓名、骑手性别、骑手年龄等字段。如表4-9所示。

表4-9 骑手用户表

|----|-------------------------|-----------|-----|------|------|--------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | ruser_ider_user_id | int | - | 是 | 是 | 骑手用户ID |
| 2 | ruser_iders_name | varchar | 64 | 否 | 否 | 骑手姓名 |
| 3 | ruser_iders_gender | varchar | 64 | 否 | 否 | 骑手性别 |
| 4 | age_of_ruser_ider | varchar | 64 | 否 | 否 | 骑手年龄 |
| 5 | mobile_phone_number | varchar | 16 | 否 | 否 | 手机号码 |
| 6 | qualification_materials | varchar | 255 | 否 | 否 | 资质材料 |
| 7 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 8 | user_id | int | - | 是 | 否 | 用户ID |
| 9 | create_time | datetime | - | 是 | 否 | 创建时间 |
| 10 | update_time | timestamp | - | 是 | 否 | |

5系统实现

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.1.7订单配送管理功能实现

用户对已支付未完成的订单可跟踪配送进度。系统展示订单当前所处配送环节，用户能了解预计送达时间，配送完成后订单状态更新为已收货。订单配送管理界面如图5-7所示。

图5-7 订单配送管理界面

5.1.8通知中心查看功能实现

系统向用户推送各类重要消息，包括订单动态、促销活动等内容。通知中心汇集所有未读与已读消息，用户逐条查阅后可根据需要标记已读状态。通知中心查看界面如图5-8所示。

图5-8 通知中心查看界面

5.1.9售后申请功能实现

用户收到商品后发现质量问题可发起售后申请。系统要求用户填写售后原因并上传相关凭证，提交后申请流转至商家审核，审核结果通过通知中心反馈。售后申请界面如图5-9所示。

图5-9 售后申请界面

5.2商家用户功能实现

5.2.1商城中心管理功能实现

商家登录后进入商城中心管理模块，系统展示当前商家上架的所有商品。商家可对商品信息进行日常维护，包括价格调整与库存修改，这些变更即时生效。商城中心管理界面如图5-10所示。

图5-10 商城中心管理界面

5.2.2商城分类管理功能实现

商家根据商品属性创建不同的分类层级。系统允许商家添加新分类、修改分类名称或删除无用的分类，商品与分类的关联关系自动更新。商城分类管理界面如图5-11所示。

图5-11 商城分类管理界面

5.2.3订单管理功能实现

商家查看来自普通用户的所有订单记录。系统按订单状态分组展示，商家可处理待发货订单，确认后转入配送环节，已发货订单不再允许修改。订单管理界面如图5-12所示。

图5-12 订单管理界面

5.2.4订单配送管理功能实现

商家对已确认发货的订单完成配送指派。系统提供骑手分配功能，商家选择空闲骑手进行订单绑定，配送任务随即进入骑手工作列表。订单配送管理界面如图5-13所示。

图5-13 订单配送管理界面

5.2.5订单售后管理功能实现

商家收到用户的售后申请后进行审核处理。系统展示申请详情与用户凭证，商家可选择同意退货或拒绝申请，处理结果同步更新至用户的订单售后状态。订单售后管理界面如图5-14所示。

图5-14 订单售后管理界面

5.2.6通知中心查看功能实现

商家通过通知中心接收系统推送的消息，包括订单异常、售后申请等关键事件。所有消息按时间顺序排列，商家查阅后可以获取最新的业务动态。通知中心查看界面如图5-15所示。

图5-15 通知中心查看界面

5.2.7后台首页查看功能实现

商家进入后台首页后，系统聚合展示店铺的核心经营数据。页面呈现当日订单数量、销售额等关键指标，帮助商家快速掌握店铺运营状况。后台首页查看界面如图5-16所示。

图5-16 后台首页查看界面

5.3 骑手用户功能实现

5.3.1订单配送管理功能实现

骑手登录后查看分配给自己的配送任务。系统展示待配送订单的收货地址与联系方式，骑手完成配送后点击确认送达，订单状态变更为已完成。订单配送管理界面如图5-17所示。

图5-17 订单配送管理界面

5.4 管理员功能实现

5.4.1通知中心查看功能实现

管理员在通知中心查阅系统运行过程中产生的重要消息。这些消息涉及用户反馈、异常操作告警等内容，管理员逐条阅读后可根据情况采取相应措施。通知中心查看界面如图5-18所示。

图5-18 通知中心查看界面

5.4.2网站公告管理功能实现

管理员负责向全体用户发布网站公告。系统提供公告编辑功能，管理员填写标题与正文后提交发布，已发布的公告在用户端首页进行展示。网站公告管理界面如图5-19所示。

图5-19 网站公告管理界面

5.4.3新闻资讯管理功能实现

管理员维护平台内的新闻资讯内容。系统支持资讯的添加、编辑与删除操作，每条资讯包含标题、正文与发布时间，发布后用户可在资讯板块查阅。新闻资讯管理界面如图5-20所示。

图5-20 新闻资讯管理界面

5.4.4资讯分类管理功能实现

管理员对新闻资讯设置不同的分类标签。系统允许新增分类、修改分类名称或删除已有分类，资讯与分类之间的归属关系随分类调整而自动变更。资讯分类管理界面如图5-21所示。

图5-21 资讯分类管理界面

5.4.5商城中心管理功能实现

管理员对整个商城的商品进行统一管理。系统展示所有商家上架的商品列表，管理员有权下架违规商品或调整商品的上架状态，保障商城运营的规范性。商城中心管理界面如图5-22所示。

图5-22 商城中心管理界面

5.4.6商城分类管理功能实现

管理员维护商城的顶层分类结构。系统提供分类的增删改查功能，管理员设定分类层级与顺序，这些分类对所有商家可见并按需挂载商品。商城分类管理界面如图5-23所示。

图5-23 商城分类管理界面

5.4.7订单管理功能实现

管理员查看系统中所有用户的订单记录。系统按订单状态与时间范围提供筛选功能，管理员可追踪异常订单的操作流程，必要时进行人工干预。订单管理界面如图5-24所示。

图5-24 订单管理界面

5.4.8订单配送管理功能实现

管理员监控整个配送环节的运行状态。系统展示所有待配送与配送中的订单，管理员可重新指派配送失败的订单，协调骑手资源完成配送任务。订单配送管理界面如图5-25所示。

图5-25 订单配送管理界面

5.4.9订单售后管理功能实现

管理员对商家处理完成后的售后争议进行最终裁决。系统展示完整的售后申请链与商家处理意见，管理员核实后做出终审决定，该结果不可再次更改。订单售后管理界面如图5-26所示。

图5-26 订单售后管理界面

6系统测试

6.1测试目的

系统测试是检验校园超市助购系统是否达到需求分析阶段所规定功能规格的过程。测试工作主要对业务流程是否完整，数据流转是否正确进行测试。按照用户交互准确性来测试普通用户的下单支付流程、商家用户的发货审核流程、骑手用户的配送状态更新流程。边界容错校验主要是库存不足下单、订单超时未付款自动取消、售后申请缺少凭证等的提示逻辑。全链路数据一致性测试检验订单创建之后库存扣减的原子性，支付之后订单状态改变的可靠性。系统应该保证各个角色在规定的权限内完成规定的操作，非授权的访问请求会被正确地拦截 $20$ 。测试目的还有检验前后端接口的响应时间以及错误处理。

6.2测试方法

系统测试用黑盒测试法，主要对功能模块的输入输出是否满足要求进行检验。功能测试阶段对于每一个用例都写测试用例，包括正常情况和异常情况。集成测试阶段对各个模块之间的协同工作进行检验，即用户下单、商家发货、骑手配送等全部链条。回归测试在缺陷修复之后执行，保证修改不会带来新的问题。测试环境配置同生产环境一致，后端服务部署在本地服务器上，前端小程序运行在微信开发者工具模拟器上。测试数据和生产数据分开，测试执行之前准备好足够的测试账号和商品数据。缺陷管理工具会将每一个找到的问题都登记下来，开发人员修正之后，测试人员才肯认可其被关闭。

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 网站公告管理测试用例表

|------|------|------------|-----------|------|------|
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
| 公告管理 | 公告发布 | 填写公告内容并发布 | 公告出现在公告栏 | 符合预期 | 测试成功 |
| 公告管理 | 置顶设置 | 将公告设置为置顶 | 公告展示在列表顶部 | 符合预期 | 测试成功 |
| 公告管理 | 公告下架 | 对已发布公告执行下架 | 公告不再展示 | 符合预期 | 测试成功 |

6.4测试结论

经过对商城中心查看、购物车管理、支付订单、订单管理、订单配送管理、订单售后管理、网站公告管理七个核心功能模块的测试，所有的测试用例的预期结果和实际结果都是一致的。商品列表加载、分类筛选功能运行正常，购物车里商品数量的增加和减少计算正确。订单创建之后支付状态可以按照业务流程正确流转，超时未支付订单的自动取消机制工作正常。商家对发货订单的发货操作执行之后，订单状态变为待签收，骑手接单配送和送达确认过程全部完成。售后申请提交之后商家审核通过则开始退款流程，审核拒绝之后用户就会收到相应的反馈。公告发布和下架操作在用户端的展示结果符合设置。各个模块的测试结果均合格。

7总结

校园超市传统经营方式一直存在高峰期排长队、商品库存情况不明、购物流程慢等状况。本文以springboot为框架，采用微信小程序技术为基础，设计并实现了校园超市助购系统，把传统的线下购物环境搬到移动端上，使学生可以在线上完成商品的浏览、下单和订单跟踪。商家用户有商品管理、订单处理、售后审核权利，骑手用户从事配送执行工作，管理员做全局设置、信息发布工作。该系统很好地解决了校园超市经营过程中出现的信息不对称问题，减少了学生购物排队的时间，达到了预期的设计目标。

系统开发严格按照软件工程规范流程来开展工作。需求分析阶段就四种用户角色的功能边界和交互关系做出了决定。系统设计阶段用前后端分离的架构，后端使用springboot框架提供RESTful API接口，前端用微信小程序来搭建用户界面，数据库使用MySQL存储核心业务数据。编码实现阶段按照模块完成用户认证、商品管理、购物车、订单处理、配送追踪、售后管理等各方面的功能开发。测试阶段按照核心业务流程编写测试用例，对功能进行测试。技术架构的前后端分离设计使模块间的耦合度降低，接口的复用性较好。四种角色的协同工作流程为商品上架、用户下单、订单配送、售后处理这四个环节。

目前系统还存在着一些不足。支付模块使用模拟支付方式，没有和真实的第三方支付接口对接，不能处理实际的资金流转。配送环节没有路径规划的功能，骑手的配送路线是由人工来决定的，配送效率存在提高的空间。商品推荐功能没有实现，用户查找商品只能依靠分类筛选和关键词搜索，智能化程度不高。系统没有使用实时消息推送的方式，订单状态变化的提醒存在一定的滞后现象。

后续改进方向是接入微信支付的正式接口，完成真实的资金流转和财务对账。根据地图API开发配送路径规划模块，给骑手提供最合理的配送路线。采用协同过滤推荐算法，根据用户购买历史、浏览行为等对商品做个性化的推荐，以提高商品曝光率、转化率。升级消息推送方式为WebSocket长连接，对订单状态进行实时通知。该系统给高校后勤服务信息化转型提供了一个可以参照的技术方案，在类似的校园服务场景线上化改造中具有推广意义。

参考文献

张永宾. 基于图神经网络的商品在线智能推荐系统设计 $J$ . 电子设计工程, 2026, 34(6): 19-23.
姜微, 任燕, 薄喜柱, 等. 基于鸿蒙生态的智能购物车项目式教学模式创新研究 $J$ . 电脑知识与技术, 2025, 21(34): 162-164.
郭一凡, 田佳卉. 个性化推荐系统对消费者购买决策效率的影响研究 $J$ . 现代营销, 2025, 0(27): 154-156.
章裔杰, 张璐, 陈晓丰. 基于区块链的在线匿名购物系统 $J$ . 信息技术, 2025, 0(8): 64-74.
熊晨惠. 在线购物店铺视觉设计对顾客忠诚的影响研究 $D$ . 西安: 西安理工大学, 2025.
殷继旺. AI个性化推荐体验对消费者在线购物行为意向的影响机理研究 $D$ . 北京: 北京交通大学, 2025.
刘子锐, 朱雯. 网上购物UI界面与紧急遇险下的硬件设备设计------以"家庭助购"APP为例 $J$ . 鞋类工艺与设计, 2025, 5(1): 18-20.
Rizomyliotis I. Consumer Trust and Online Purchase Intention for Sustainable Products $J$ . American Behavioral Scientist, 2026, 70(5): 706-724.
From Personal Shopper to Global Brand: Camila Cecilio's Naise Shopper Redefines Luxury Retail Access $J$ . M2 Presswire, 2025, 0(0): 1-5.
JuliaHair 2023 Black Friday Shopping Guide for the Best Wig Deals $J$ . M2 Presswire, 2023, 0(0): 1-5.
Haibo L. CONSTRUCTION AND APPLICATION OF ANXIETY PSYCHOLOGICAL EFFECT MODEL IN HUMANIZED ONLINE SHOPPING GUIDE SYSTEM $J$ . Psychiatria Danubina, 2022, 34(S5): 32-32.
Duan H, Cui C. Intelligent Supermarket Shopping Guide System Based on UWB $J$ . International Journal of Frontiers in Engineering Technology, 2022, 4(6): 1-10.
李东bbsky.微信小程序·云开发 $M$ .人民邮电出版社:202205:394.
明日科技.Vue.js开发快速入门到精通 $M$ .北京:化学工业出版社,2024:377.
杨芬,宋晓燕.MySQL数据库应用的课程教学分析 $J$ .电子技术,2023,52(10):180-181.
岂超凡.零基础学 $M$ .机械工业出版社:202110:927.
秦长春.微信小程序开发技术 $M$ .人民邮电出版社:202101:485.
庞敏.MySQL数据库的数据安全应用设计技术研究 $J$ .数字通信世界,2024,48(9):25-27.
胡劲.数据库信息管理系统的逻辑架构与功能设计探析 $J$ .电脑知识与技术,2023,19(19):96-98.
刘雄华.软件测试技术 $M$ .武汉:华中科技大学出版社,2023:243.

致谢

时间的流逝，大学四年来的学习生活就要结束。回眸这段求学之路，从一开始选题时的无所适从，到最后系统设计和论文写作过程中一次次的反复思考，每一个阶段的成长都离不开师长们的点拨。在此要感谢在校期间指导我的老师在论文选题、开题论证、系统架构设计、定稿等各个环节中给我的悉心指导，严谨治学的态度以及深厚的学术造诣对我论文的研究起到了极大的作用。向企业提供建议，为企业工程的实施提供技术支持。

毕业设计创作过程很艰难。在需求分析阶段对功能进行梳理，在编码阶段反复调试技术瓶颈，在测试阶段不断修改，经历了迷茫、困惑、最后才得到突破瓶颈的豁然开朗。大学四年所建立起来的知识体系，在此次实践当中得到了全面的检验和有效的运用，把理论所学变成可以实际操作的系统，内心感到非常欣慰。

感谢学院各位任课老师在专业课程中无私的传授，为论文写作打下了良好的理论基础。辅导员老师对学生的关心、帮助使求学之路更加顺畅。感谢同窗好友及实验室各位同学，在平时学习中彼此间互相帮助、互相支持，共同探讨问题、一起分享自己的思路、一起度过了许多美好时光，这些时光将会成为最宝贵的回忆。

还要特别感谢父母、家人养育之恩、默默付出。你们是我最坚强的后盾，也是你们理解、支持使我安心地专心学习。站在人生下一个十字路口，未来的路会怎样，依然会保持求知的热情，将所学的知识应用到实践当中，为社会作出自己的贡献，不辜负师长、家人对我的期望。

全套资源（源码 + 论文 + 部署教程）已经打包好，需要的同学可以私信我！避免找不到，赶紧收藏，后续更新不迷路！你的点赞就是我持续分享的动力，感谢支持～