基于SpringBoot的网上花店管理系统的设计与实现-计算机毕设 附源码89600

基于SpringBoot的网上花店管理系统的设计与实现

第一章 相关技术介绍

1.1 SpringBoot框架

　　Spring Boot是Spring生态系统中用来简化应用开发和部署的框架。它的主要价值就是用自动配置的方式减少传统Spring项目里繁杂的XML配置工作，使开发者可以迅速地创建出独立运行的应用程序。该框架自带嵌入式Web容器，打包好的应用可以直接用Java命令启动，不需要再部署WAR文件。Spring Boot提供了很多起步依赖，开发者只需要在项目中引入对应场景的启动器，框架就会自动管理相关的依赖版本以及默认配置。鲜花销售系统后端开发时用到Spring Boot来处理业务逻辑、提供持久化支持、暴露RESTful接口等。依靠它所具备的Spring Data JPA或者MyBatis整合功能，系统可以以对象化的方式对数据库进行操作，从而减小了数据访问层的开发难度。黑马程序员认为Spring Boot简化了后端服务搭建的复杂程度，使用较少的配置和依赖管理[11]。该系统采用Spring Boot的自动配置功能，把鲜花商品信息、订单数据、用户状态等主要业务实体转换成数据模型，然后经由控制器层对外输出统一接口，从而保证前端可以顺利得到想要的数据。框架自带的异常处理和监控功能给系统稳定运行打下了基础。

1.2 Vue.js框架

　　Vue.js是基于JavaScript的一种渐进式用户界面构建工具，它的思想是以视图层声明式渲染、组件化开发为特点。该框架使用基于虚拟DOM的响应式数据绑定，当数据状态发生改变的时候，视图可以自动地进行高效的更新，从而大大简化了前端交互逻辑的编写。Vue.js的核心库只关注视图层，容易和其他库或者现有的项目进行整合，而且它也有着完善的路由、状态管理以及构建工具等配套方案。在鲜花销售系统前端部分，Vue.js负责创建商品展示页面、购物车界面、订单管理面板等交互模块。使用单文件组件可以将页面结构、样式和行为逻辑打包在一起，提高代码的可维护性以及复用性。潘涛等用Vue.js和Spring Boot创建网上商城管理系统，用前后端分离的方式实现业务模块的解耦。使用Vue Router管理页面的导航，用Vuex来集中管理用户的登录状态、购物车数据等全局信息，使多页面之间的数据同步变得简单可靠[12]。前端界面使用Axios库同后端API执行异步通信，在浏览鲜花商品、提交订单或者查看物流信息的时候可以得到良好的交互体验。

1.3 MySQL数据库

　　MySQL是目前应用最广的关系型数据库管理系统，凭借性能稳定、查询高效、部署方便等特性被很多互联网应用所使用。该数据库支持标准的SQL语言，具有事务处理、多版本并发控制、存储过程、触发器等企业级的功能，可以满足电商系统对于数据一致性和并发操作的需求。MySQL的存储引擎架构可以根据不同的业务场景来选择合适的引擎，InnoDB引擎具有行级锁和外键约束的特点，适合于需要高并发读写和数据完整性要求的交易型应用。MySQL对鲜花销售系统中的用户信息、商品数据、订单记录、优惠券配置等全部业务数据都进行了持久化存储。通过对表结构进行合理的设置，对索引进行建立，并且对查询语句进行优化，系统可以有效地响应用户的商品检索请求和订单提交操作。郑晓霞等人的研究认为MySQL数据库对于Web应用来说是重要的，合理的设计可以提高系统的性能[13]。使用MySQL事务来保证订单生成和库存扣减的操作是原子的，不会出现超卖或者数据不一致的情况。数据库的备份和恢复机制给系统的数据安全提供了一个基本的保障。

1.4 前后端分离架构

　　前后端分离是把前端界面和后端服务分别开发、分别部署的一种架构模式。在这种模式之下，前端会借助HTTP请求去调用后端所给出的API接口来获取数据，而后端则不会参与到视图层的渲染任务当中，而是将主要精力放在业务逻辑处理以及数据服务上。这样就使得前后端开发团队可以同时进行开发工作，前端可以自由选择技术框架，后端可以对服务进行更好的管理以及性能的提升。鲜花销售系统创建时采用前后端分离的方式。后端采用Spring Boot搭建RESTful风格的API接口，用JSON格式来传递数据，前端使用Vue.js框架开发单页应用，用户访问时只会加载一次页面，之后的操作都是异步请求来完成数据的更新。十三和尼克陈用大型项目实践来证明前后端分离模式可以提高系统的可维护性和扩展性[14]。该模式的应用使系统可以独立发展，将来如果需要增加移动端App或者小程序，只需要复用后端接口就可以快速实现。前后端采用统一接口规范合作，降低系统耦合度，便于对接口进行版本管理以及权限控制。

第二章 系统分析

2.1 可行性分析

2.1.1 技术可行性

　　系统采用Spring Boot和Vue.js的前后端分离架构，数据层用MySQL数据库，这些技术已经发展成熟，并且有完善的社区支持。Spring Boot框架可以简化项目的配置以及依赖的管理，从而快速地搭建起一个稳定可靠的后端服务。Vue.js采用高效的组件化开发模式，可以创建出交互丰富的用户界面。MySQL数据库对于高并发的读写情况具有较好的稳定性能，事务可以保证订单以及库存操作的一致性。开发环境方面，IntelliJ IDEA与Visual Studio Code等工具链完备，调试与部署流程清晰。以上技术栈在大量的商业项目上得到了验证，并且没有出现无法跨越的技术壁垒。

2.1.2 操作可行性

　　系统根据用户、商家、管理员三个角色的不同，设计出不同的操作界面和功能入口。普通用户只需进行商品列表浏览、购物车添加操作即可完成购买，界面设计符合主流电商平台的交互方式，学习成本较低。商家用户可以借助后台管理模块来完成商品信息的录入、订单配送以及售后审核这些工作，并且操作过程比较清晰。管理员用户可以在统一面板上进行用户管理、分类维护和投诉回复等工作。整体交互流程经过抽象设计，各个角色无需接受专门的培训就可以很快地适应并开始使用，能满足日常业务操作的需求。

2.1.3 经济可行性

　　系统开发所用到的技术框架以及标准开发工具都是开源的，并且不需要购买商业软件或者授权许可，大部分开发成本来自于人力与服务器。项目运行阶段可以采用云服务器进行部署，按需付费模式可以有效地控制初期投入。系统上线之后通过线上销售鲜花商品获得收益，平台运营所产生出来的服务器维护费用和销售额相比处在合理的范围之内。系统设计充分考虑了模块化的特点，后续功能的增加或者业务的改变都不会造成高昂的重构成本，从长远的角度看具有较好的投入产出比。

2.2 功能需求分析

2.2.1 用户角色功能需求

　　用户角色主要是对鲜花商品进行浏览、在线购买、订单管理、售后申请等操作。用户可以查看商品详情，可以将商品添加到购物车中，可以直接下单，提交订单的时候选择收货地址，使用优惠券，填写备注信息。订单生成之后用户可以追踪订单的状态，对已完结的订单做出确认收货或者发起售后申请。用户可以自行修改自己的收货地址信息，提出自己的投诉意见，并收藏自己喜欢的商品。用户用例图如图3-1所示。

图3-1用户用例图

2.2.2 商家角色功能需求

　　商家角色主要是对鲜花商品信息进行维护，对订单进行配送，对售后申诉进行审核，并对优惠券进行管理。商家可以新增鲜花商品，设置名称、封面、分类、价格、库存和详情内容，对已有的商品进行修改、删除或者查看评论。订单管理模块可以商家查看订单详情、录入配送单号进行发货操作。售后申诉模块商家可以查看售后申请并进行审核，选择通过或者拒绝并填写回复内容。优惠券管理模块具有新增、修改和删除优惠券的功能，设置优惠券名称、优惠金额、满减条件以及有效期。商家用例图如图3-2所示。

图3-2商家用例图

2.2.3 管理员角色功能需求

　　管理员是系统层面的用户管理、鲜花分类维护、商品监管、投诉建议处理、系统配置管理的负责人。用户管理模块可以实现对平台用户增删改查的功能。鲜花分类管理模块可以对管理员进行新增、修改或者删除商品分类的操作。鲜花信息管理模块有商品详情查看、评论查阅和违规商品删除这三个功能。投诉建议管理模块可以供管理员查看投诉详情，也可以填写回复内容。系统管理模块有轮播图设置、会员等级管理等。管理员图如图3-3所示。

图3-3管理员用例图

第三章 系统设计

3.1 系统架构设计

　　系统采用前后端分离的架构模式，将用户界面与业务逻辑解耦，便于独立开发与部署。前端部分基于Vue框架构建，负责页面渲染与用户交互，通过HTTP协议与后端API进行数据交换。后端部分基于Spring Boot框架，按照分层思想划分为控制器层、服务层与数据访问层，控制器层接收前端请求并返回响应数据，服务层封装业务逻辑，数据访问层通过MyBatis与MySQL数据库交互。系统整体遵循MVC设计模式，视图层由前端Vue组件承担，模型层对应数据库实体，控制器层负责协调二者之间的数据流转。系统架构图如图4-1所示。

图4-1系统架构图

3.2 系统结构功能设计

　　系统围绕用户、商家、管理员三类核心角色构建功能模块。用户角色可进行鲜花浏览、购物车管理、订单处理、地址维护以及投诉建议等操作。其中鲜花浏览模块支持查看商品详情；购物车管理模块允许调整商品数量与下单结算；订单管理模块提供订单状态跟踪、支付处理与售后申请入口；地址管理模块支持收货地址的增删改查与默认设置；投诉建议模块允许用户提交反馈并查看回复。商家角色负责鲜花商品信息管理、订单配送处理、售后申诉审核以及优惠券配置。管理员角色承担用户管理、鲜花分类维护、商品监管、投诉建议回复以及系统轮播图与会员配置等任务。各模块之间通过清晰的数据流与权限控制实现协同运作，确保不同角色在各自权限范围内完成业务操作。该系统功能结构如图4-2所示。

图4-2系统功能结构图

3.3 业务流程设计

3.3.1 商品下单流程设计

　　用户将商品加入购物车后，进入购物车页面确认商品信息，点击下单进入订单确认环节。系统校验商品库存与优惠券有效性，用户选择收货地址并提交订单，系统生成订单记录并跳转至支付页面。该流程包含库存校验与订单生成两个关键判断节点。商品下单流程图如图4-3所示。

图4-3商品下单流程图

3.3.2 订单支付流程设计

　　用户在订单确认页面提交订单后进入支付页面，选择支付方式并确认支付。系统校验账户余额或积分是否充足，根据校验结果更新订单状态并扣减相应资源。支付成功后订单状态变更为待发货，用户可在订单列表中查看支付结果。订单支付流程图如图4-4所示。

图4-4订单支付流程图

3.3.3 商家发货流程设计

　　商家在订单管理模块查看待发货订单，点击配送操作进入发货页面。商家填写配送单号并提交，系统将订单状态更新为已发货，同时记录物流信息。该流程包含配送单号校验与状态更新两个核心操作。商家发货流程图如图4-5所示。

​编辑 图4-5商家发货流程图

3.3.4 售后申请流程设计

　　用户在订单详情页面发起售后申请，填写售后原因并上传凭证图片后提交。系统生成售后申请记录，通知商家审核。商家查看申请详情后选择通过或拒绝并填写回复，系统根据审核结果更新订单状态或返还款项。售后申请流程图如图4-6所示。

图4-6售后申请流程图

3.3.5 优惠券新增流程设计

　　商家在优惠券管理页面点击新增，进入新增操作页面填写优惠券名称、满减金额、使用门槛与有效期等配置信息。提交后系统校验参数完整性，通过后生成优惠券记录并发布。优惠券新增流程图如图4-7所示。

图4-7优惠券新增流程图

3.4 数据库设计

3.4.1 概念模型设计

　　鲜花销售系统的概念模型设计需要准确把握用户、商家、管理员、商品、订单五类核心实体之间复杂的业务关联。用户与订单之间存在一对多的关系，一个用户可以提交多笔订单，每笔订单归属于唯一用户。订单与商品之间形成多对多的联系，一笔订单可包含多种商品，一种商品也可出现在多笔订单中，这种关系通过订单明细实体进行分解。商家与商品之间为一对多关系，一个商家可管理多种鲜花商品。管理员与用户之间为一对多关系，管理员负责审核与管理平台注册用户。管理员与商家之间也构成一对多关系，管理员负责审核商家入驻申请并监管商家经营行为。管理员与商品之间同样存在管理关系，可对违规商品进行下架或删除处理。管理员与投诉建议之间为一对多关系，负责回复用户提交的各类投诉。用户与收藏之间为一对多关系，用户可收藏多个商品。用户与收货地址之间也构成一对多关系，方便用户在订单中选择不同配送地点。用户与优惠券之间为多对多关系，用户可领取多张优惠券，一张优惠券可被多个用户领取。用户与售后申请之间为一对多关系，每个用户可发起多次售后申请，每笔申请对应一笔订单。商家与售后申请之间也为一对多关系，商家负责审核归属于本店铺的售后申请。通过抽取用户、商家、管理员、商品、订单、购物车、收藏、收货地址、优惠券、售后申请等核心实体，并明确它们之间的关联约束，能够完整刻画系统的数据结构。概念模型作为现实世界到信息世界的第一次抽象，为后续逻辑模型设计奠定了基础。全局E-R模型如图4-8所示。

图4-8E-R图

　　根据系统分析，系统的主要实体有用户、商家、管理员、商品、订单、购物车、收藏、收货地址、优惠券、售后申请，各个实体具体的属性如以下图所示。

　　用户实体主要包括用户标识、用户名、密码、昵称、手机号码、邮箱、头像地址、会员等级、会员折扣、积分、账户状态、创建时间、上次登录时间等属性。如图4-9所示。

图4-9用户实体属性图

　　商家实体主要包括商家标识、店铺名称、商家姓名、商家电话、商家资质、审核状态、用户标识、创建时间等属性。如图4-10所示。

图4-10商家实体属性图

　　管理员实体主要包括用户标识、用户名、密码、用户组、创建时间等属性。如图4-11所示。

图4-11管理员实体属性图

　　商品实体主要包括商品标识、商家用户、店铺名称、鲜花华语、花卉分类、适用场景、配送规则、标题、封面图、描述、原价、卖价、商品库存、商品分类、正文、主图1至主图5、积分、上架状态、创建时间等属性。如图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售后申请实体属性图

3.4.2 数据库表设计

　　数据库逻辑设计阶段将概念模型中的实体与关系转换为MySQL数据库支持的表结构。依据E-R图中定义的实体属性与联系类型，为每个实体建立对应的数据表，并明确主键与外键约束。用户表与订单表通过用户标识建立关联，订单表与商品表通过订单明细表实现多对多关系。商家表与商品表通过商家标识建立关联，确保每个商品归属唯一商家。系统共设计约20张数据表，涵盖用户信息、商品数据、交易记录、售后流程等业务环节。通过合理设置字段类型与长度，并针对高频查询字段建立索引，能够在保障数据完整性的同时提升检索效率。周晓玉等人[15]指出数据库概念模型向逻辑结构的转换需要遵循规范化理论，合理的表结构设计能够有效减少数据冗余并提高查询性能。

　　（1）用户表主要是用来存储平台注册用户的基本信息。主要包括用户标识、用户名、密码、昵称、手机号码、会员等级、积分等字段。如表4-1所示。

表4-1用户表

序号	字段名	类型	长度	备注
1	user_id	bigint	20	用户标识
2	username	varchar	16	用户名
3	password	varchar	64	密码
4	nickname	varchar	16	昵称
5	phone	varchar	11	手机号码
6	avatar	varchar	255	头像地址
7	vip_level	varchar	255	会员等级
8	integral	int	11	积分
9	state	smallint	6	账户状态
10	create_time	timestamp	-	创建时间

　　（2）商家表主要是用来存储入驻平台的商家信息。主要包括商家标识、店铺名称、商家姓名、商家电话、商家资质、审核状态、用户标识等字段。如表4-2所示。

表4-2商家表

序号	字段名	类型	长度	备注
1	merchant_user_id	int	11	商家标识
2	store_name	varchar	64	店铺名称
3	business_name	varchar	64	商家姓名
4	business_phone	varchar	16	商家电话
5	merchant_qualification	varchar	255	商家资质
6	examine_state	varchar	16	审核状态
7	user_id	int	11	用户标识
8	create_time	datetime	-	创建时间

　　（3）管理员表主要是用来存储系统管理员的账户信息。主要包括管理员标识、用户名、密码、用户组、创建时间等字段。如表4-3所示。

表4-3管理员表

序号	字段名	类型	长度	备注
1	admin_id	int	11	管理员标识
2	username	varchar	16	用户名
3	password	varchar	64	密码
4	user_group	varchar	32	用户组
5	create_time	timestamp	-	创建时间

　　（4）商品表主要是用来存储鲜花商品的具体信息。主要包括商品标识、商家用户、店铺名称、标题、封面图、描述、原价、卖价、商品库存、商品分类、正文、上架状态等字段。如表4-4所示。

表4-4商品表

序号	字段名	类型	长度	备注
1	flower_mall_id	int	11	商品标识
2	merchant_user	int	11	商家用户
3	store_name	varchar	64	店铺名称
4	cart_title	varchar	125	标题
5	cart_img	text	65535	封面图
6	cart_description	varchar	255	描述
7	cart_price_ago	double	-	原价
8	cart_price	double	-	卖价
9	cart_inventory	int	11	商品库存
10	cart_type	varchar	64	商品分类
11	list_status	smallint	6	上架状态
12	create_time	datetime	-	创建时间

　　（5）订单表主要是用来存储用户提交的订单记录。主要包括订单标识、订单号、商品标识、商品标题、数量、价格、总价、买家标识、商家标识、订单状态、发货状态、收件地址、联系人姓名、联系人手机、订单备注等字段。如表4-5所示。

表4-5订单表

序号	字段名	类型	长度	备注
1	order_id	int	11	订单标识
2	order_number	varchar	64	订单号
3	goods_id	mediumint	9	商品标识
4	title	varchar	255	商品标题
5	num	int	11	数量
6	price	double	-	价格
7	price_count	double	-	总价
8	user_id	int	11	买家标识
9	merchant_id	mediumint	9	商家标识
10	state	varchar	16	订单状态
11	delivery_state	varchar	16	发货状态
12	contact_address	varchar	255	收件地址
13	contact_name	varchar	32	联系人姓名
14	contact_phone	varchar	11	联系人手机
15	remark	text	65535	订单备注
16	create_time	timestamp	-	创建时间

　　（6）购物车表主要是用来暂存用户选中的商品信息。主要包括购物车标识、商品标识、标题、图片、数量、单价、总价、用户标识、状态等字段。如表4-6所示。

表4-6购物车表

序号	字段名	类型	长度	备注
1	cart_id	int	11	购物车标识
2	goods_id	mediumint	9	商品标识
3	title	varchar	64	标题
4	img	varchar	255	图片
5	num	int	11	数量
6	price	double	-	单价
7	price_count	double	-	总价
8	user_id	int	11	用户标识
9	state	int	11	状态
10	create_time	timestamp	-	创建时间

　　（7）收藏表主要是用来记录用户收藏的商品信息。主要包括收藏标识、收藏人标识、标题、封面、来源标识、来源表、创建时间等字段。如表4-7所示。

表4-7收藏表

序号	字段名	类型	长度	备注
1	collect_id	int	11	收藏标识
2	user_id	int	11	收藏人标识
3	title	varchar	255	标题
4	img	varchar	255	封面
5	source_id	int	11	来源标识
6	source_table	varchar	255	来源表
7	create_time	timestamp	-	创建时间

　　（8）收货地址表主要是用来存储用户的收货地址信息。主要包括地址标识、地址、姓名、手机、邮编、用户标识、默认判断、创建时间等字段。如表4-8所示。

表4-8收货地址表

序号	字段名	类型	长度	备注
1	address_id	int	11	地址标识
2	address	varchar	255	地址
3	name	varchar	32	姓名
4	phone	varchar	13	手机
5	postcode	varchar	8	邮编
6	user_id	mediumint	9	用户标识
7	default	tinyint	4	默认判断
8	create_time	timestamp	-	创建时间

　　（9）优惠券表主要是用来存储平台发放的优惠券信息。主要包括优惠券标识、优惠券名称、优惠券价格、优惠券券后价格、优惠券时间、优惠券类型、优惠券用户标识、创建时间等字段。如表4-9所示。

表4-9优惠券表

序号	字段名	类型	长度	备注
1	coupon_id	int	11	优惠券标识
2	coupon_name	varchar	255	优惠券名称
3	coupon_price	int	11	优惠券价格
4	coupon_price1	int	11	优惠券券后价格
5	coupon_time	varchar	255	优惠券时间
6	coupon_type	varchar	255	优惠券类型
7	coupon_user_id	int	11	优惠券用户标识
8	create_time	timestamp	-	创建时间

　　（10）售后申请表主要是用来记录用户发起的售后申请信息。主要包括售后申请标识、订单标识、订单号、商品标识、商品标题、数量、价格、总价、买家标识、商家标识、售后状态、售后回复、售后类型、售后内容、售后凭证、创建时间等字段。如表4-10所示。

表4-10售后申请表

序号	字段名	类型	长度	备注
1	order_after_sale_id	int	11	售后申请标识
2	order_id	int	11	订单标识
3	order_number	varchar	64	订单号
4	goods_id	mediumint	9	商品标识
5	title	varchar	255	商品标题
6	num	int	11	数量
7	price	double	-	价格
8	price_count	double	-	总价
9	user_id	int	11	买家标识
10	merchant_id	mediumint	9	商家标识
11	after_state	varchar	16	售后状态
12	after_state_reply	varchar	255	售后回复
13	type	varchar	255	售后类型
14	content_desc	varchar	255	售后内容
15	imgs	varchar	1000	售后凭证
16	create_time	timestamp	-	创建时间

第四章 系统实现

4.1 用户角色功能实现

4.1.1 商品浏览

　　商品浏览模块主要是向用户展示鲜花商品列表与详细信息。用户进入系统首页后，系统加载商品数据并以网格形式呈现。用户点击商品卡片可跳转至详情页面，查看商品图文描述、价格信息、收藏商品、库存状态以及用户评价等内容。用户可根据分类标签或搜索关键词筛选商品，系统根据筛选条件返回匹配结果。商品浏览界面如图5-1所示。

图5-1商品浏览界面

4.1.2 购物车管理

　　购物车管理模块主要是对用户选中的商品进行临时存储与数量调整。用户将商品加入购物车后，可在购物车页面查看已选商品列表。用户修改商品数量时，系统实时更新该商品的小计金额并重新计算总价。用户勾选待结算商品后点击下单，系统将所选商品信息传递至订单确认页面。购物车管理界面如图5-2所示。

图5-2购物车管理界面

4.1.3 订单管理

　　订单管理模块主要是对用户已提交的订单进行状态跟踪与操作处理。用户在订单列表页面可查看不同状态下的订单，包括待付款、待发货、待收货、已完成等分类。用户对未支付订单可执行取消或继续支付操作，对已签收订单可发起售后申请。系统在订单状态变更时及时更新前端显示。订单管理界面如图5-3所示。

图5-3订单管理界面

4.1.4 地址管理

　　地址管理模块主要是对用户的收货地址进行维护。用户可新增收货地址，填写收件人姓名、联系电话、详细地址等信息。系统支持用户设置默认地址，下单时自动填充默认地址信息。用户可对已有地址进行修改或删除操作，所有变更实时同步至数据库。地址管理界面如图5-4所示。

图5-4地址管理界面

4.1.5 投诉建议

　　投诉建议模块主要是收集用户对平台或商家的反馈意见。用户在投诉建议页面选择投诉对象，填写问题描述后提交。系统记录投诉内容并推送至管理员后台。用户提交后可查看管理员回复内容，了解处理进展。投诉建议界面如图5-5所示。

图5-5投诉建议界面

4.2 商家角色功能实现

4.2.1 鲜花信息管理

　　鲜花信息管理模块主要是对商家所售商品进行维护。商家可新增鲜花商品，填写商品名称、选择分类、上传封面图片、设置价格与库存数量、编辑商品详情内容。商家可对已有商品进行信息修改或下架删除操作。商品列表展示商品基本信息与上架状态，商家可点击查看商品评论。鲜花信息管理界面如图5-6所示。

图5-6鲜花信息管理界面

4.2.2 订单配送管理

　　订单配送管理模块主要是对商家接收的订单进行处理。商家在待发货订单列表中查看订单详情，包括商品信息、买家地址、联系方式等内容。商家完成商品打包后，点击配送操作录入快递单号，系统将订单状态更新为已发货。商家可查看历史发货记录，追溯物流信息。订单配送管理界面如图5-7所示。

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

4.2.3 售后申诉管理

　　售后申诉管理模块主要是对用户提交的售后申请进行审核。商家在售后列表中查看待审核申请，点击详情查看用户填写的售后原因与凭证图片。商家根据实际情况选择通过或拒绝申请，填写审核回复后提交。系统根据审核结果更新订单状态，通过申请则发起退款流程。售后申诉管理界面如图5-8所示。

图5-8售后申诉管理界面

4.2.4 优惠券管理

　　优惠券管理模块主要是对店铺优惠券进行配置。商家可新增优惠券，设置优惠券名称、优惠金额、使用门槛、有效期范围等参数。商家可对已发放优惠券进行修改或删除操作。优惠券列表展示每张券的使用状态与发放记录。优惠券管理界面如图5-9所示。

图5-9优惠券管理界面

4.3 管理员角色功能实现

4.3.1 用户管理

　　用户管理模块主要是对平台注册用户进行统一管理。管理员可在用户列表中查看所有用户的基本信息，包括用户名、会员等级、注册时间、账户状态等。管理员可对异常账户进行状态修改或账户删除操作。用户管理界面如图5-10所示。

图5-10用户管理界面

4.3.2 鲜花分类管理

　　鲜花分类管理模块主要是对商品分类体系进行维护。管理员可新增商品分类，设置分类名称与显示顺序。管理员可对现有分类进行修改或删除操作，分类变更后商品关联信息自动更新。鲜花分类管理界面如图5-11所示。

图5-11鲜花分类管理界面

4.3.3 鲜花信息监管

　　鲜花信息监管模块主要是对平台所有商品进行合规性审查。管理员在商品列表中可浏览商家发布的鲜花商品，点击商品条目查看详情信息，包括商品图文描述、价格库存、商家信息等内容。对于涉及违规内容或不符合平台规定的商品，管理员可执行下架操作，商品状态变更为不可见，商家端同步收到下架通知。管理员还可查看商品评价内容，对不当评论进行处理。鲜花信息监管界面如图5-12所示。

图5-12鲜花信息监管界面

4.3.4 投诉建议管理

　　投诉建议管理模块主要是对用户提交的反馈进行处理。管理员在投诉列表中查看投诉详情，包括投诉用户、投诉商家、问题描述与图片附件。管理员填写回复内容后提交，系统将回复信息推送至用户端。投诉建议管理界面如图5-13所示。

图5-13投诉建议管理界面

4.3.5 系统管理

　　系统管理模块主要是对平台基础配置进行维护。管理员可管理首页轮播图，上传图片、设置跳转链接与显示顺序。管理员可配置会员等级与对应折扣权益，调整会员升级规则。系统管理界面如图5-14所示。

图5-14系统管理界面

第五章 系统测试

5.1 测试目的

　　系统测试旨在验证鲜花销售系统在功能实现、业务流程、数据一致性以及异常处理等方面的表现是否符合设计预期。通过测试检验各功能模块在不同操作路径下的响应准确性，确保用户、商家、管理员三类角色能够在各自权限范围内顺利完成业务操作。重点关注商品浏览与下单流程的完整性、订单状态流转的正确性、库存扣减与支付操作的原子性、售后审核与优惠券使用的逻辑一致性。代晓倩等人[16]指出软件测试是保障系统质量的关键环节，通过回归测试与边界条件验证能够有效降低上线风险。测试工作覆盖功能正确性、系统稳定性与交互友好性三个层面，为系统正式上线运行提供质量保障。

5.2 测试方法

　　系统测试采用黑盒测试为主、白盒测试为辅的策略。功能测试方面，依据需求分析文档设计测试用例，覆盖正常业务流程与异常边界条件。对商品下单、订单支付、商家发货、售后申请等核心流程进行全链路验证，确保各环节数据流转准确。集成测试方面，检查前后端接口通信的稳定性，验证API在参数缺失、权限不足等情况下的错误处理机制。回归测试方面，在修复缺陷后重新执行相关用例，确保修改未引入新的问题。性能测试方面，模拟多用户并发访问场景，监测系统响应时间与服务器资源占用情况。

5.3 测试用例

　　（1）商品下单功能测试

　　商品下单功能主要验证用户从购物车提交订单到生成订单记录的全过程。测试包括正常下单、库存不足时下单失败、未选择地址时提示等场景。商品下单功能测试如表6-1所示。

表6-1商品下单功能测试表

测试项	测试步骤	预期结果	实际结果
正常下单	添加商品至购物车，选择收货地址，点击提交订单	生成订单记录，跳转支付页面	符合预期
库存不足	选择库存为0的商品，点击提交订单	提示库存不足，订单未生成	符合预期
地址未选	不选择收货地址直接提交订单	提示选择收货地址	符合预期

　　（2）订单支付功能测试

　　订单支付功能主要验证用户完成支付后订单状态变更与资源扣减的正确性。测试包括余额充足时支付成功、余额不足时支付失败等场景。订单支付功能测试如表6-2所示。

表6-2订单支付功能测试表

测试项	测试步骤	预期结果	实际结果
支付成功	选择余额支付，账户余额充足，确认支付	扣减余额，订单状态变更为待发货	符合预期
余额不足	选择余额支付，账户余额不足，确认支付	提示余额不足，订单状态不变	符合预期
积分支付	选择积分支付，积分充足，确认支付	扣减积分，订单状态变更为待发货	符合预期

　　（3）商家发货功能测试

　　商家发货功能主要验证商家录入配送单号后订单状态更新的正确性。测试包括单号格式正确时发货成功、单号格式错误时提示重新填写等场景。商家发货功能测试如表6-3所示。

表6-3商家发货功能测试表

测试项	测试步骤	预期结果	实际结果
发货成功	填写正确格式的配送单号，提交发货信息	订单状态更新为已发货	符合预期
单号错误	填写错误格式的配送单号，提交发货信息	提示单号格式错误，状态未更新	符合预期
重复发货	对已发货订单再次提交配送信息	提示订单已发货，禁止重复操作	符合预期

　　（4）售后申请功能测试

　　售后申请功能主要验证用户提交售后申请后商家审核流程的正确性。测试包括审核通过后订单退款、审核拒绝后订单状态不变等场景。售后申请功能测试如表6-4所示。

表6-4售后申请功能测试表

测试项	测试步骤	预期结果	实际结果
申请提交	填写售后原因并上传凭证，提交申请	生成售后记录，状态为待审核	符合预期
审核通过	商家选择通过审核并填写回复	订单状态更新为已退款	符合预期
审核拒绝	商家选择拒绝审核并填写理由	订单状态不变，返回拒绝理由	符合预期

　　（5）优惠券管理功能测试

　　优惠券管理功能主要验证商家新增优惠券后用户能否正常领取与使用。测试包括新增优惠券、用户领取、下单时使用优惠券等场景。优惠券管理功能测试如表6-5所示。

表6-5优惠券管理功能测试表

测试项	测试步骤	预期结果	实际结果
新增优惠券	填写优惠券名称、满减金额、有效期，提交保存	优惠券记录生成，可在列表中查看	符合预期
用户领取	用户进入优惠券页面领取优惠券	优惠券添加到用户账户，显示未使用	符合预期
使用优惠券	下单时选择已领取的优惠券	订单金额扣减优惠额度	符合预期

测试结论

　　经过对鲜花销售系统各个功能模块的全面测试之后可知，在正常业务流程以及异常边界的情况下，该系统的稳定性、准确性都达到了预期的目的。商品下单、订单支付、商家发货、售后申请、优惠券管理等功能都通过了验证，测试用例中预期的结果和实际的结果是一致的，没有出现数据不一致或者业务逻辑错误的情况。系统在用户角色切换、权限控制、接口异常处理等各方面运行正常，前端交互响应及时，后端事务处理符合设计规范。测试中发现部分页面在极端数据量时加载速度稍有迟缓，经过排查是由于前端渲染优化不到位所导致的，后期可以采用分页加载、缓存等方式加以改善。总体上系统功能齐全、运行稳定，满足了设计要求，具备上线运行的条件。