第一章 绪论
1.1 研究背景与意义
传统鲜花零售模式受实体门店的地理限制和营业时间的约束，消费者要到现场去选择品种、付款。随着城市化的发展，通勤时间成本越来越高，线上购花的需求也由原来的节日礼品扩展到了日常的悦己消费。现有的电商平台虽然可以进行商品的展示和在线支付，但是鲜花属于非标品，新鲜度的保证以及即时配送的要求对于库存管理系统来说提出了更高的要求1。部分小型花店使用社交软件接单，手工填写订单信息造成错单、漏单现象时有发生，售后服务的追溯工作比较困难。鲜花销售领域存在技术工具和业务流程相脱离的状况，创建起包含商品管理、订单流转、物流跟踪等环节的垂直系统，便成了改善行业经营效能的迫切要求2。移动互联网的普及使得消费场景发生了迁移，用户希望可以随时随地地了解自己所购买的商品库存和配送情况，这就需要系统有数据同步以及状态反馈的功能3。
系统用标准化的订单处理流程缩短了人工核单的时间，减少了由于信息传递错误造成的交易纠纷。管理员通过销售数据统计模块迅速找到热销品类和滞销库存，给采购计划的调整提供客观依据。用户端集成地址管理、支付接口，在下单之后自动生成配送任务推送到后台，物流状态变化立即同步到用户界面上。闭环的设计能削减门店运营中依靠个人经验开展的工作，推进鲜花零售向着数字化发展。系统沉淀下来的消费行为数据可以为行业供应链的改善给予支持，有利于供应商对区域需求变动作出提前预估，并且削减产地到销地环节的浪费。同类中小型电商系统可以按照本文的架构快速搭建业务原型，其模块化的设计思路对于农产品线上销售场景有迁移的价值。系统上线运行之后，验证了技术方案在真实的业务环境中是稳定的，为以后的功能迭代积累了实践数据。
1.2 国内外研究现状
国内对于鲜花销售开展的数字化研究起步较早，技术路线也一直在变化，从最初的动态网页到现在的小型轻量级框架。早期的研究主要是信息的基本展示、交易的功能，随着电商模式的发展，学者们也研究了营销策略优化、企业风险控制、系统管理效率的提高。研究视角由原来的单一的技术创建变为技术同商业场景的融合，目的在于解决传统鲜花零售信息不对称、库存管理迟缓等难题。
何彪（2023）以JSP技术为基础设计出一个网上花店系统，可以完成商品展示和在线订购的功能，该系统对于会话跟踪技术的应用为之后的开发工作打下了基础4。董彬(2021)以R花店为例，研究了社群营销策略对于鲜花销售的促进作用，从用户黏性培养的角度给本系统收货地址管理以及订单配送环节的用户体验提供了一些思路5。张语涵(2021)就爱尚鲜花企业的风险展开分析，阐明了供应链以及资金链对鲜花电商的冲击，从而使得本系统在订单支付和订单列表管理时更加重视状态跟踪的精确性6。乔楠（2020）利用ASP.NET技术创建了网上花店销售管理系统，主要研究了后台订单处理流程的规范性，分层设计思想给管理员端实现订单列表管理和分类列表管理提供借鉴7。
综上所述，国内有关研究成果涉及技术实现和运营策略等各个方面，但是在数据驱动决策方面还有待进一步的拓展。现有的系统对于订单配送环节的实时监控功能比较粗略，并且鲜少会把销售数据同库存管理展开深入联系剖析。本系统在前人的基础上又增加了一个数据分析模块，把普通的用户购物车管理变为订单配送的全过程跟踪，从而提高系统的数据整合程度和经营透明度。
国外对于花卉以及相关电商的研究，更多是把注意力放在消费者行为分析、供应链改善以及智能算法的应用上。研究大多认为数据对于营销决策和物流效率的改善起着关键的作用，用建立定量模型、优化算法的方式来挖掘市场潜力。技术发展趋向是朝着数据驱动型智能系统转变的，即由原来的单一交易平台转向数据驱动型智能系统。
Jahan等(2025)用孟加拉国芒果电商为案例，通过实证数据研究数字营销系统对消费者满意度的影响，得出支付流程的便捷性和配送时效对用户的复购率起着关键的作用8。该结论说明本系统设计支付订单和订单配送管理功能时应该使流程简单、状态清晰。Huang和Wu（2025）提出了一个改进双狼群算法的营销数据查询方法，该模型在提高海量数据检索效率方面效果明显，给系统后台实现高效的分析和订单检索提供了一个算法上的启示9。针对干花市场行业报告（2024），对全球花卉消费新动向进行了描绘，突出个性化展示、品类细分等重要性，这给本系统在鲜花商城管理上提供了参考，即分类列表要灵活设置、商品展示要多样化10。T.R.等（2023）针对中国花卉市场拍卖物流中心收益优化问题，建立的物流协同模型表明，配送节点规划可以有效地降低损耗、提高客户满意度，直接映射到本系统订单配送管理的物流状态设计中11。刘（2021）从文化消费的角度出发，对中国的新兴花卉市场以及日常消费行为进行了分析，认为线上平台应该适应本土化的消费习惯，这也提示本系统在建立收货地址管理、商城查看等模块的时候，需要考虑界面交互的本地化体验12。
综合国外研究，其在消费者行为量化、物流算法优化、数据处理模型等方面已经取得了比较丰富的成果，但是大部分研究都偏向于理论模型或者某一个品类的分析，和综合型鲜花销售平台的实际应用还有一定的差距。本系统吸取国外有关数据查询效率和物流协同的思想，结合国内用户的操作习惯，在管理员数据分析模块中加入基本统计模型，在用户端加强订单配送的实时反馈，使理论方法同应用场景相融合。
1.3 主要研究内容
本文以设计和实现一个基于SpringBoot和Vue.js的鲜花销售系统为研究对象，用前后端分离的方式来解决传统零售模式下订单信息分散、库存同步滞后的问题。从业务需求调研入手，对普通用户和管理员两种角色的业务操作场景进行梳理，从中提炼出商品浏览、购物车管理、地址维护、订单支付、配送追踪、后台数据分析、商品配置、订单核验等主要功能点。在此基础上确定系统的分层结构，把用户界面层、业务逻辑层和数据持久层分离出来，保证各个模块可以独立地进行开发和维护。数据库设计阶段根据实体关系模型创建用户表、商品表、订单表、物流表等主要数据表，并且用主外键关联来保证数据的一致性。编码实现阶段用Spring Boot创建RESTful接口来处理前端请求，Vue.js动态渲染页面组件，前后端用JSON格式交换数据。对测试验证覆盖功能的完整程度、并发响应和异常输入场景进行测试，保证系统在真实环境下正常工作。研究重点放在业务闭环的完整性上而不是底层算法的创新上，最后得到可以部署的系统原型和配套的设计文档，给小型电商提供从需求分析到上线部署的完整参照方案。
第二章 相关技术介绍
2.1 Spring Boot框架
Spring Boot是一个基于Java语言的开源微服务开发框架，它的主要目的是简化Spring应用的初始搭建和配置。传统的Spring项目要手动去管理大量的XML配置文件，而且会存在版本冲突的问题，从而影响到构建的效率。Spring Boot采用约定优于配置的思想，用自动配置的方式减少开发者重复劳动，内嵌的Tomcat服务器使应用可以打包成独立的JAR文件直接运行13。该框架给出了起步依赖模块，开发者只需要导入相应的场景启动器就可以快速地把数据访问、安全控制等加入到项目中。在鲜花销售系统当中，Spring Boot担当起后端业务逻辑处理的主要工作。控制器层收到前端的HTTP请求之后，就会根据路由映射找到对应的处理方法。服务层对商品检索、订单生成、库存扣减等业务规则进行封装，保证数据在持久化之前已经过合法性校验。数据访问层使用Spring Data JPA操作MySQL数据库，把实体对象和数据表的记录进行映射转换。框架的事务管理机制可以保证所有的数据库操作要么全部成功，要么全部回滚，从而防止由于网络中断或者异常造成订单数据不一致的情况发生。自动配置特性大大缩减了环境搭建的时间，开发团队可以把更多的精力放在业务代码的编写上，而不是去处理底层基础设施。
2.2 Vue框架
Vue.js是一个用于构建用户界面的渐进式JavaScript框架，它的核心库主要负责视图层的渲染，可以与其它第三方库或者现有的项目进行整合14。框架使用虚拟DOM技术提高页面更新效率，当数据发生改变的时候，Vue会计算出最小的差异量并进行批量的DOM操作，从而减少重绘造成的性能损失。组件化开发模式可以把页面分成一个个可以被复用的模块，每一个模块里包含模板、样式和逻辑，从而减少模块间之间的耦合。在鲜花销售系统前端实现的时候，Vue.js会创建商品列表、购物车、订单详情等交互界面。双向数据绑定机制使模型数据和页面展示同步，用户更改收货地址的时候，界面显示的内容马上变。路由管理器控制页面跳转逻辑，当URL发生变化时就会自动渲染对应组件，达到单页应用无刷新切换的效果。使用axios库进行和后端服务器的异步通信，把用户的操作转化为HTTP请求发送到Spring Boot接口，接收到返回的数据之后再重新渲染视图区域。框架提供的生命周期钩子函数可以供开发者在组件挂载、更新或者销毁的时候执行某些操作，比如进入商品详情页的时候就自动发起数据请求来填充页面内容。
2.3 MySQL数据库技术
MySQL是被广泛使用的、在各种应用场合中使用的、关系型数据库管理系统，由于其稳定性能好、跨平台支持以及低使用成本而得到开发社区的认可15。数据库用表格形式来组织数据，用结构化查询语言做数据的增删改查操作。在鲜花销售系统当中，MySQL用来保存用户的资讯、商品信息、订单信息以及物流状况这些业务数据。根据实体关系模型创建多个数据表，用户表和订单表之间用用户编号字段建立一对多的关系，保证一个用户可以查询到自己名下的全部历史订单。事务处理机制保证并发环境下数据的一致性，当多个用户同时下单同一款库存少的鲜花的时候，数据库行级锁防止出现超卖的情况。索引技术给高频查询字段创建快速的检索路径，将商品名称或者分类字段加入到索引当中，用户的搜索响应时间就会变得更快。定期备份策略把数据存入到安全的地方，硬件故障或者误操作的时候，系统管理员可以依靠备份文件来恢复到最近的状态。MySQL和Spring Boot的整合采用连接池的方式，应用程序启动时会创建多个数据库连接存入到池中，当请求到来的时候会直接从池中取出一个连接使用，而不会像传统方式那样反复地创建和关闭连接，从而减少了资源的浪费。
2.4 前后端分离架构
前后端分离架构把用户界面和业务逻辑分成两个独立部署的应用程序，用标准接口协议进行数据交换16。前端主要负责页面渲染和用户交互，后端主要处理数据以及执行业务规则，两者同时开发互相不影响。部署阶段前端代码放在Nginx或者Apache服务器上，后端应用运行在独立的进程中，用域名和端口号来实现跨域通信。鲜花销售系统使用该种架构模式来组织代码结构。Vue.js项目运行在浏览器端，用户浏览商品或者提交订单的时候，前端会把操作封装成HTTP请求发给后端接口。Spring Boot应用解析请求参数，调用服务层的方法进行数据校验和持久化操作，最后以JSON格式返回给前端。前端解析返回的数据之后动态更新DOM节点，用户不需要刷新整个页面就可以看到操作的反馈。由于职责分工明确，所以系统具有较好的扩展性，可以方便地在系统中加入新的移动端应用，只需要复用后端接口即可，不需要重新开发业务逻辑。接口文档用Swagger工具自动生成，给出每一个接口的请求方式、参数类型以及返回格式等信息，从而减少前后端联调过程中沟通的成本。部署环境分离之后，把数据库连接信息、业务密钥存放到后端服务器里，从而避免敏感数据被暴露在浏览器端，安全等级得以提升。
第三章 系统分析
3.1 功能需求分析
3.1.1 普通用户角色功能需求
普通用户在鲜花销售系统中可以浏览商城商品，通过关键词搜索或分类筛选快速定位目标商品。系统支持用户管理个人收货地址，新增或编辑地址信息并设置默认选项。用户将商品加入购物车后可调整购买数量或移除商品，提交订单前选择支付方式完成交易。订单生成后用户可在个人中心查看订单状态，物流信息更新时系统同步显示配送进度。普通用户用例图如图3-1所示。
图3-1普通用户用例图
3.1.2 管理员角色功能需求
管理员登录后台可查看销售数据可视化看板，分析商品销售金额与数量趋势。系统提供商品管理功能，管理员能够添加或编辑鲜花信息，配置分类与上架状态。订单列表支持按订单号与联系人查询，管理员可导出数据或修改订单状态。物流配送模块记录配送单号与配送员信息，管理员核验签收状态后完成订单闭环。普通用户用例图如图3-2所示。
图3-2管理员用例图
3.2 可行性分析
3.2.1 技术可行性
系统采用Spring Boot框架创建后端服务，Spring Boot内置了嵌入式Web服务器以及自动配置的功能，可以迅速搭建起独立运行的应用实例。Vue.js是前端的选型方案，它的组件化开发模式可以实现界面模块的复用，虚拟DOM机制保证页面渲染性能。MySQL数据库有稳定可靠的事务处理能力，行级锁可以防止高并发时出现的库存被超卖的情况。前后端之间用RESTful接口进行JSON数据的交换，各个层次的职责明确，有利于后期的维护。开发环境采用IntelliJ IDEA与Visual Studio Code，调试工具链成熟完整。以上技术组件都经过了大量的项目验证，社区文档齐全，技术整合没有遇到无法克服的困难。
3.2.2 经济可行性
系统开发阶段所用到的软件都是开源或者社区免费的版本，Spring Boot、Vue.js和MySQL不需要支付授权费用。硬件上只用普通的开发用计算机和部署用的云服务器，根据需要选择基本配置即可满足初期用户的访问需求。运行阶段成本主要是服务器租赁、域名续费等，属于月租制的范围内。系统上线之后可以缩减人工记载订单、核对库存的工作量，削减由于信息错漏引发的退款和客诉费用。数据分析功能可以辅助管理者改善采购计划，削减滞销鲜花的损耗，长期运作所形成的收益可以抵消初期的投资。
3.2.3 操作可行性
系统界面采用简洁的布局和清晰的导航，顶部菜单分为首页、系统公告、商城入口三个部分，用户可以快速找到想要的功能。商品列表有分类筛选、价格排序控件，购物车、提交订单按钮在视觉焦点区域。收货地址管理用列表展示和表单编辑两种方式，默认地址明显。管理员后台按照数据看板、商品配置、订单处理等模块划分，列表页可以做条件查询、状态筛选，批量操作可以减少重复劳动。用户不需要专业的培训就可以完成日常的操作，交互逻辑符合大多数电商平台的使用习惯。
第四章 系统设计
4.1 系统架构设计
鲜花销售系统用前后端分离的方式组织代码结构，把用户界面、业务逻辑和数据存储三个层次分清楚。前端采用Vue.js框架构建单页应用，采用组件化开发模式把商品列表、购物车、订单详情等模块做成独立单元，用路由管理器控制页面的切换逻辑。后端使用Spring Boot框架创建RESTful接口，控制器层接收到HTTP请求之后调用服务层的方法来处理具体的业务。服务层对商品库存校验、订单金额计算、支付状态更新等进行封装，数据访问层使用Spring Data JPA操作MySQL数据库。浏览器和服务器之间用JSON格式来交换数据，跨域问题通过后端配置来解决。部署时将前端代码放在Nginx容器中，后端应用打包成JAR文件运行在独立进程中，两者用域名和端口号进行通信。分层设计使各个模块职责单一，后续增加移动端应用可以使用现有的接口，系统扩展性得到保证。系统架构图如图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 销售数据分析流程设计
管理员进入数据分析模块，系统默认展示最近七天的销售金额与数量趋势图。管理员可筛选日期范围或商品分类，图表根据筛选条件重新渲染。点击导出按钮可将当前图表数据导出为Excel文件，用于线下汇报与存档。销售数据分析流程如图4-7所示。
图4-7销售数据分析流程图
4.4 数据库设计
4.4.1 概念模型设计
概念模型设计是从系统业务规则、数据关系入手的。鲜花销售系统中，用户和订单之间是一对多的关系，一个用户可以生成多笔订单，但是每笔订单都必须属于某个唯一的用户。商品和订单条目之间存在多对多的关系，一个订单可以包含多种商品，同一种商品也可以出现在不同的订单里。地址信息是用户属性单独保存的，用户和地址之间也是单向的，即一个用户可以有多个收货点。物流配送记录和订单是一一对应的，每一个订单最后都会产生一条物流追踪信息。这些实体以及它们之间的联系就构成了系统的主体数据骨架，用E-R图可以清楚地表现出现实业务在信息世界中的映射关系17。全局E-R模型如下图4-8所示。
图4-8全局ER图
根据系统分析，系统的主要实体有：用户账户、普通用户、收货地址、订单、购物车、商品信息、鲜花商城、物流配送。各个实体具体的属性如下图所示。
用户账户实体主要包括用户id、用户名、密码、昵称等。如图4-9所示。
图4-9用户账户实体属性图
普通用户实体主要包括普通用户id、用户姓名、用户手机等。如图4-10所示。
图4-10普通用户实体属性图
收货地址实体主要包括收货地址id、姓名、手机、地址等。如图4-11所示。
图4-11收货地址实体属性图
订单实体主要包括订单id、订单号、商品标题、价格、数量等。如图4-12所示。
图4-12订单实体属性图
购物车实体主要包括购物车id、标题、图片、用户id等。如图4-13所示。
图4-13购物车实体属性图
商品信息实体主要包括商品id、标题、卖价、原价、库存等。如图4-14所示。
图4-14商品信息实体属性图
鲜花商城实体主要包括鲜花商城id、品牌名称、适用节日、卖价等。如图4-15所示。
图4-15鲜花商城实体属性图
物流配送实体主要包括物流配送id、订单号、商品名称、交易总额等。如图4-16所示。
图4-16物流配送实体属性图
4.4.2 数据库表设计
数据库逻辑设计阶段把概念模型中的实体和联系转换成MySQL支持的数据表结构，根据关系规范化理论减少数据冗余，防止更新异常18。各个表用主键和外键来建立联系，用户表和订单表以用户编号字段进行连接，保证查询效率的同时也保持了数据的完整性。字段类型和长度根据业务实际情况来定，手机号用varchar类型留出国际号码扩展的空间，金额字段用double保证小数的精度。索引策略针对高频查询字段做优化，商品名称、订单号加索引之后检索速度得到明显提高。字符集设置为utf8mb4来支持特殊字符和表情的存储，事务隔离级别设置为可重复读以保证并发下的数据一致性。
用户账户表主要是用来存储系统用户的登录凭证与基础信息。主要包括用户名、密码、昵称、手机号码等字段。如表4-1所示。
表4-1用户账户表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 用户id | int | 11 | 主键 |
| 2 | 用户名 | varchar | 30 | 登录账号 |
| 3 | 密码 | varchar | 64 | 加密存储 |
| 4 | 昵称 | varchar | 50 | 显示名称 |
| 5 | 手机号码 | varchar | 20 | 联系方式 |
| 6 | 邮箱 | varchar | 50 | 备用联系 |
| 7 | 头像地址 | varchar | 200 | 图片路径 |
| 8 | 创建时间 | timestamp | - | 注册时间 |
收货地址表主要是用来存储用户设置的多个收货点信息。主要包括姓名、手机、地址、默认判断等字段。如表4-2所示。
表4-2收货地址表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 收货地址id | int | 11 | 主键 |
| 2 | 姓名 | varchar | 50 | 收货人 |
| 3 | 手机 | varchar | 20 | 联系电话 |
| 4 | 邮编 | varchar | 10 | 邮政编码 |
| 5 | 地址 | varchar | 200 | 详细地址 |
| 6 | 用户id | int | 11 | 所属用户 |
| 7 | 默认判断 | tinyint | 4 | 是否默认 |
| 8 | 创建时间 | timestamp | - | 添加时间 |
订单表主要是用来记录用户提交的每笔交易信息。主要包括订单号、商品标题、价格、数量、订单状态等字段。如表4-3所示。
表4-3订单表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 订单id | int | 11 | 主键 |
| 2 | 订单号 | varchar | 50 | 唯一编号 |
| 3 | 商品标题 | varchar | 200 | 商品名称 |
| 4 | 价格 | double | - | 成交单价 |
| 5 | 数量 | int | 11 | 购买数量 |
| 6 | 总价 | double | - | 订单总额 |
| 7 | 联系人姓名 | varchar | 50 | 收货人 |
| 8 | 联系人地址 | varchar | 200 | 收货地址 |
| 9 | 订单状态 | varchar | 20 | 待付款等 |
| 10 | 创建时间 | timestamp | - | 下单时间 |
购物车表主要是用来暂存用户选中的商品信息。主要包括标题、图片、用户id、单价、数量等字段。如表4-4所示。
表4-4购物车表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 购物车id | int | 11 | 主键 |
| 2 | 标题 | varchar | 200 | 商品名称 |
| 3 | 图片 | varchar | 200 | 封面路径 |
| 4 | 用户id | int | 11 | 所属用户 |
| 5 | 单价 | double | - | 当前售价 |
| 6 | 数量 | int | 11 | 选择数量 |
| 7 | 商品id | int | 11 | 关联商品 |
| 8 | 创建时间 | timestamp | - | 加入时间 |
商品信息表主要是用来存储系统中所有可销售商品的基础数据。主要包括标题、卖价、原价、库存、商品分类等字段。如表4-5所示。
表4-5商品信息表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 商品id | int | 11 | 主键 |
| 2 | 标题 | varchar | 200 | 商品名称 |
| 3 | 卖价 | double | - | 销售价格 |
| 4 | 原价 | double | - | 市场参考价 |
| 5 | 销量 | int | 11 | 累计销量 |
| 6 | 库存 | int | 11 | 剩余数量 |
| 7 | 商品分类 | varchar | 50 | 所属类别 |
| 8 | 上架状态 | smallint | 6 | 上下架标识 |
| 9 | 创建时间 | timestamp | - | 录入时间 |
鲜花商城表主要是用来扩展商品维度的属性信息。主要包括品牌名称、适用节日、适用场景、卖价等字段。如表4-6所示。
表4-6鲜花商城表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 鲜花商城id | int | 11 | 主键 |
| 2 | 品牌名称 | varchar | 50 | 所属品牌 |
| 3 | 适用节日 | varchar | 50 | 推荐场景 |
| 4 | 适用场景 | varchar | 50 | 使用场合 |
| 5 | 卖价 | double | - | 当前售价 |
| 6 | 商品库存 | int | 11 | 剩余数量 |
| 7 | 商品分类 | varchar | 50 | 类别标识 |
| 8 | 创建时间 | datetime | - | 添加时间 |
物流配送表主要是用来记录订单发货后的物流轨迹与签收状态。主要包括订单号、商品名称、交易总额、配送状态等字段。如表4-7所示。
表4-7物流配送表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 物流配送id | int | 11 | 主键 |
| 2 | 订单号 | varchar | 50 | 关联订单 |
| 3 | 商品名称 | varchar | 200 | 商品信息 |
| 4 | 购买数量 | varchar | 20 | 数量描述 |
| 5 | 交易总额 | double | - | 订单金额 |
| 6 | 发货日期 | date | - | 发货时间 |
| 7 | 配送订单号 | varchar | 30 | 物流单号 |
| 8 | 收货地址 | varchar | 200 | 目的地 |
| 9 | 配送状态 | varchar | 20 | 配送进度 |
| 10 | 签收状态 | varchar | 20 | 是否签收 |
第五章 系统实现
5.1 普通用户角色功能实现
5.1.1 鲜花商城查看
用户在鲜花商城模块浏览商品列表，页面默认展示全部商品并支持按分类快速筛选。输入关键词后系统向后端发送搜索请求，匹配商品标题或描述字段后刷新列表区域。商品卡片包含图片、名称、价格与库存状态，点击卡片跳转至详情页展示更完整的图文介绍与规格参数。用户可在详情页查看销量数据与用户评价，决定是否将商品加入购物车或直接购买。鲜花商城查看界面如图5-1所示。
图5-1鲜花商城查看界面
5.1.2 收货地址管理
用户进入收货地址列表页查看已保存的地址信息，默认地址带有特殊标识便于识别。新增地址时弹窗表单收集姓名、联系电话与详细地址，保存后数据提交至后端存储。编辑功能允许用户修改现有地址信息，删除操作需二次确认避免误触。用户可切换默认地址选项，下次下单时系统自动填充该地址简化操作步骤。收货地址管理界面如图5-2所示。
图5-2收货地址管理界面
5.1.3 支付订单
用户在订单确认页核对商品清单与收货地址后提交订单，系统生成待支付记录并跳转至支付选择页。支付方式包括微信扫码、支付宝与网银选项，用户选定后页面展示对应二维码。手机端用户可长按识别二维码完成支付，PC端用户使用手机扫描后支付平台异步通知后端更新订单状态。支付成功页面提示交易完成并提供查看订单入口。支付订单界面如图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 数据分析
管理员登录后台进入数据分析首页，页面顶部展示轮播图数量与公告数量统计卡片。折线图区域呈现选定日期范围内的销售金额趋势，柱状图对比不同商品的销量分布。管理员可点击筛选控件调整时间范围或商品分类，图表数据实时刷新。导出按钮将当前图表数据保存为Excel文件，供线下会议使用。数据分析界面如图5-7所示。
图5-7数据分析界面
5.2.2 鲜花商城管理
管理员进入商品列表页查看所有商品记录，表格展示商品标题、分类、卖价、库存与上架状态。顶部提供标题搜索与分类筛选控件，支持按上架状态过滤商品。点击新增按钮跳转至表单页填写品牌名称、适用节日、场景描述与多张商品图片。编辑功能修改现有商品信息，下架操作将商品状态更新为0使其在前端隐藏。鲜花商城管理界面如图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订单配送管理界面
第六章 系统测试
6.1 测试目的
系统测试是对鲜花销售系统功能实现和需求规格说明书是否符合的一种检验过程，模拟真实的用户操作来发现业务逻辑上的缺陷以及数据一致性问题。测试过程中主要关注订单状态流转是否完整，即从用户提交订单、管理员发货、用户确认收货等全流程的数据不能出现丢失或者状态跳跃的情况。库存扣减机制要保证在并发下单的时候不出现超卖的情况，造成实际库存和数据库中记录的不一致。支付回调接口的异常处理能力也被包含在内，模拟网络延迟或者支付平台返回错误的时候，系统应该给出明确的提示而不是陷入未知状态19。
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订单状态流转测试表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 支付后状态 | 用户完成扫码支付 | 订单状态变已付款 | 符合预期 |
| 发货后状态 | 管理员点击发货 | 状态变已发货 | 符合预期 |
| 收货后状态 | 用户确认收货 | 状态变已完成 | 符合预期 |
| 取消未支付订单 | 用户点击取消按钮 | 状态变已取消 | 符合预期 |
测试结论
所有的测试用例都通过了执行，用户登录、商品搜索、购物车添加、订单提交、状态流转这五个主要的功能模块都是稳定的。异常输入场景下系统可以给出明确的提示，不会造成界面卡死或者数据写入错误。并发测试中库存扣减逻辑正确，没有出现超卖的情况。支付回调模拟网络延迟时订单状态为待支付，用户刷新后可以完成支付，业务数据保持最后一致。浏览器兼容性测试使用的是最新的Chrome和Edge版本，移动端页面也正常。系统达到预期功能完整性要求，可以上线运行。