基于SpringBoot 的羽毛球俱乐部管理系统

admin 管理员组

文章数量: 1088120

1.1 研究背景及意义 

1.2 研究现状 

1.3 发展趋势 

1.4 研究内容 

1.5 论文结构 

1.6 本章小结 

2 相关技术介绍 

2.1 Spring Boot框架 

2.2 Vue架构 

2.3 MySQL数据库 

2.4 本章小结 

3 系统分析 

3.1 可行性分析 

3.2 功能需求分析 

3.3 非功能需求分析 

3.4 本章小结 

4 系统设计 

4.1 系统功能设计 

4.2 系统流程设计 

4.3 数据库设计 

5 系统实现

5.1 登录功能 

5.2 注册功能 

5.3 管理员功能 

5.4 用户功能 

5.5 本章小结 

6 系统测试 

6.1 功能测试 

6.2 测试结果 

1.  绪论

1.  研究背景及意义

1.  研究背景

在“十四五”体育发展规划推动下，羽毛球运动因兼具竞技性与大众参与度，成为全民健身产业的重要增长点[1]。据《2024年中国体育服务业发展报告》显示，近三年国内羽毛球俱乐部数量年复合增长率达18%，但传统管理模式的低效性逐渐凸显：超60%的俱乐部仍依赖纸质登记处理场地预约，导致时段冲突率高达25%；会员信息管理分散于Excel表格，数据更新滞后问题引发的服务失误占比达30%；商品库存与订单脱节现象普遍，库存周转率较数字化管理模式低。随着计算机技术在体育领域的渗透，构建集预约管理、会员服务、商品运营于一体的智能化系统，成为破解行业管理痛点、提升服务质量的关键路径。然而，现有解决方案多侧重单一功能模块，缺乏针对羽毛球俱乐部业务特性的全流程数字化整合方案，亟需结合行业场景需求进行技术创新与系统重构。

1.  研究意义

本项目立足羽毛球俱乐部实际运营需求，构建基于Spring Boot框架的轻量化管理系统，通过Java后端与MySQL数据库的深度耦合，实现“管理员-用户”双角色业务闭环[2]。通过双角色架构，管理员可在线管理用户信息、动态调度场地资源、实时跟踪商品库存与订单，显著减少人工记录错误，提升场地利用率、提高库存盘点效率；用户端实现场地预约、商品选购及订单管理全流程线上化，缩短平均预约耗时，避免线下往返与时段冲突。系统采用开源技术栈降低开发成本，适配中小型俱乐部数字化需求，为其提供了易上手、高性价比的管理工具，助力解决日常运营中的实际痛点，提升服务效率与用户体验。

1.  研究现状

在国内研究现状显示，羽毛球俱乐部管理相关研究与实践不断发展，但仍存在诸多局限。目前，多数羽毛球俱乐部的管理方式较为传统，大量工作依赖人工完成。尤其是在信息管理方面，很多俱乐部仍采用纸质登记或简单的Excel表格记录，不仅效率低下，还容易出现信息更新不及时、数据丢失等问题[3]。场地预约管理也缺乏智能化手段，大多数的俱乐部依靠人工登记处理场地预约，这使得时段冲突率居高不下，极大地影响了场地的有效利用和预约冲突。在商品管理上，库存与销售数据无法实时同步，导致库存积压或缺货现象频发，库存周转率远低于数字化管理的俱乐部。

而国外研究现状虽然在体育俱乐部的管理系统方面研究和应用起步较早，技术也相对成熟。一些知名的体育俱乐部管理系统，具备较为完善的会员管理、场地预订和赛事组织功能[4]。然而，这些国外系统也并非尽善尽美。一方面，系统的功能定制性较差，难以完全适配国内羽毛球俱乐部的特殊运营模式和市场环境。另一方面，国外系统的使用和维护成本较高，对于国内众多中小型羽毛球俱乐部来说，经济负担较重。此外，在数据安全和隐私保护方面，由于国内外法规政策不同，国外系统在国内使用时可能存在合规风险，这也限制了其在国内的广泛应用。

1.  发展趋势

随着数字技术与体育产业融合的深度演进，羽毛球俱乐部管理系统的技术架构与应用模式正呈现多维度创新趋势，具体体现在以下方面：

（1）后端架构的轻量化与分布式演进，Spring Boot 框架的持续迭代将推动系统从单体架构向“微服务+容器化”模式转型[5]。结合Docker容器化部署，能将服务启动时间压缩至更短，提高故障恢复效率，为俱乐部业务规模扩张提供弹性技术支撑。

（2）前端交互的场景化与智能化升级，Vue生态的不断完善将催生更贴合运动场景的交互创新：在场地预约模块，通过Three.js实现 3D 场地建模与实时视角切换，用户可通过拖拽操作直观查看场地布局及设施细节[6]；引入WebRTC技术开发实时客服弹窗，在用户选购商品时主动推送装备搭配建议，使交互转化率提升25%。移动端适配方面，基于Vue3的响应式布局引擎可自动识别设备类型，在手机端将预约流程简化为“日历选择-时间锁定-扫码支付”3步操作，配合手势滑动切换场地类型，显著优化碎片化时间场景下的使用体验[7]。

（3）业务场景的跨界融合与生态延伸，未来系统将突破单一管理工具定位，向“运动生态服务平台”进化：通过开放API接口对接智能硬件[8]（如羽毛球拍传感器、运动手环），自动采集用户运动数据并生成技术分析报告；整合第三方赛事平台实现报名缴费、赛程提醒全流程贯通，构建“技能提升-赛事参与-社交分享”的闭环生态。在商业化拓展方面，基于用户消费画像开发动态定价引擎，结合实时场地占用率与周边竞品价格，自动生成差异化收费方案，助力俱乐部营收效率提升。

1.  研究内容

本系统采用Java语言和Spring Boot框架，前端使用Vue技术，以及MySQL数据库等技术设计与实现羽毛球俱乐部管理系统。本系统是管理员和用户双角色，管理员具有最高权限，能管理用户以及对场地、场地订单、商品、和商品订单等功能进行管理；用户可以在系统进行场地预约、赛事预约和商品购买等功能。

1.  论文结构

本论文的结构设计如下：

第1章绪论，依次描述了研究背景和意义、研究现状、研究内容和论文结构，以及小结。在全民健身政策推动下，针对传统羽毛球俱乐部存在的预约效率低下、商品管理混乱等问题，本研究设计基于Spring Boot的管理系统，通过整合场地预约与电商服务，提升运营效率与用户体验，具有显著的商业应用价值。

第2章关键技术，Spring Boot简化后端开发，Vue实现前端响应式交互，MySQL 保障数据存储安全。技术选型贴合中小型俱乐部轻量化需求，为系统开发提供支撑。

第3章系统分析，可行性分析包括技术上采用成熟栈，经济上开源降低成本，社会上符合全民健身政策。功能需求包括管理员端涵盖用户、场地、商品管理。用户端实现预约、购买、个人中心等功能，兼顾安全性与易用性。

第4章系统设计，主要包括系统整体功能设计、系统流程设计（登录、场地预约、赛事预约、商品购买流程）、数据库设计、（实体属性图、E-R图和表结构）。此部分详细的描述了管理员与用户的功能以及实体之间的关系和数据表的设计。

第5章系统实现，展示各个功能模块的界面和关键代码，比如登录模块、预约模块、支付模块等。需要强调Spring Boot的优势，如自动配置、简化开发等。

第6章系统测试，是对主要功能的测试，比如登录注册功能、场地预约功能和商品购买测试，以及结果分析，最终确保测试覆盖所有主要功能。

第7章总结与展望，总结系统提升管理效率与用户体验的成果，提出未来优化方向：微服务化、移动端适配、智能推荐，助力俱乐部数字化转型。

1.  本章小结

本章作为绪论部分，首先阐述了研究背景与意义，结合健康中国2030规划及羽毛球俱乐部传统管理模式的低效问题，说明构建管理系统的必要性。其次分析了国内外研究现状，指出现有方案在功能整合、本土化适配及成本效益上的不足，明确本系统的创新方向。最后介绍研究内容与论文结构，从技术选型、系统分析到功能实现与测试，逐层梳理研究脉络，为后续章节的具体展开奠定逻辑基础。

1.  相关技术介绍

1.  Spring Boot框架

本系统选用Java生态中的Spring Boot作为核心开发框架，该框架通过创新设计理念大幅简化企业级Web应用开发流程[9]。其核心优势体现在“约定优先”的配置策略，通过预设项目结构与依赖管理规则，将传统Spring框架中繁琐的XML配置转化为简洁的注解与属性文件，仅需在application.properties中定义数据库连接参数，即可自动完成JPA持久层初始化，减少 90% 以上的冗余配置代码。框架内置Tomcat、Jetty等Servlet容器，支持将应用打包为独立可执行JAR文件，实现“一键启动”的跨平台部署能力，配合spring-boot-maven-plugin插件，显著提升开发阶段的环境适配效率，是一个非常优秀的JavaEE开发框架。

1.  Vue架构

Vue（读作“view”）也是一个非常好用的前端小能手，专门负责把数据和网页界面“粘”在一起，使在开发的时候，不用手动改代码就能自动更新页面内容[10]。比如用户预约了羽毛球场地，页面上的“预定次数”数字能自动加1，这就是Vue的功劳。用.vue文件把HTML、CSS、JS打包成一个个组件，比如预约按钮或购物车图标，哪里需要往哪搬，代码复用率比较高。想简单就只用Vue核心库，想玩大的就加“插件”。Vue Router：管理页面跳转（比如从首页跳到预约页）Pinia：全局共享数据（比如用户的购物车信息）Vite：超快的项目打包工具，非常的实用。

1.  MySQL数据库

MySQL作为一款基于开源架构的关系型数据管理系统，采用标准化SQL语言实现数据交互，具备跨平台部署能力与高并发场景支撑特性。其通过ACID事务机制确保数据一致性[11]，内置InnoDB等多种存储引擎以适配不同业务场景的读写需求与事务处理，同时集成了完善的权限控制体系与数据加密功能保障数据安全[12]。该数据库系统凭借轻量高效的优势，广泛应用于Web开发、企业级信息系统及中小型项目的数据存储与管理场景，为各类业务提供稳定可靠的数据支撑。

1.  本章小结

本章围绕系统开发技术展开，选用Spring Boot框架构建后端，以“约定优先”策略简化开发流程，实现高效部署。前端采用Vue架构，借助响应式组件化模式提升动态交互体验。数据库选用 MySQL，依托其事务机制与权限控制保障数据安全。三者协同作用，为系统提供了轻量化、高可靠性的技术支撑，适配中小型俱乐部数字化管理需求。

1.  系统分析

1.  可行性分析

1.  技术可行性

本系统采用成熟的技术栈保障开发与运行，核心技术包括Spring Boot、Vue及MySQL。后端基于Spring Boot框架构建，利用其“约定大于配置”理念简化开发流程，通过自动装配机制减少冗余代码，也可打包为独立JAR包实现“一键启动”。前端采用Vue.js框架，借助响应式组件化开发模式，实现页面动态渲染与无刷新交互，提升用户端操作流畅度。数据库选用MySQL，其作为开源关系型数据库，支持ACID事务确保数据一致性，内置完善的权限控制与加密机制保障数据安全，能够稳定支撑用户、场地、商品等多维度数据的高效存储与查询，满足中小型俱乐部的业务数据管理需求。

1.  经济可行性

系统在经济层面具备显著可行性，主要体现在开发成本可控、运维效益提升和长期收益保障方面，系统采用Spring Boot框架与MySQL数据库构建，二者均为开源技术，无需支付软件授权费用。开发工具选用IntelliJ IDEA（免费）及Tomcat服务器，硬件配置仅需普通计算机（Windows 10及以上系统），大幅降低技术采购成本相较于传统C/S架构，B/S模式无需开发客户端程序[13]。

1.  社会可行性

本系统在社会可行性层面具有显著优势，其设计与实施精准响应全民健身国家战略及体育场馆数字化升级需求[14]。通过线上预约能有效缓解传统场馆高峰期人工登记效率低下、场地资源错配等问题，降低用户时间成本并提升运动体验；系统严格遵循《个人信息保护法》等法规要求，采用数据加密机制保障用户隐私安全[15]。另外通过举办各种类型的比赛促进体育消费生态良性发展，助力优化公共体育资源配置并推动群众性羽毛球运动普及，符合智慧城市公共服务体系建设导向与社会可持续发展目标。

1.  功能需求分析

1.  需求背景

传统管理方式在羽毛球俱乐部运营中逐渐暴露出效率低下且易出错的问题，难以满足现代用户的需求[16]。从市场环境来看，随着全民健身意识的提升，参与羽毛球运动的人群持续扩大，而传统管理方法在用户信息管理、场地调度、订单处理等方面的滞后性，导致俱乐部出现客户流失、资源调配混乱等现象。在技术应用层面，移动互联网普及，用户习惯通过手机预约和支付，传统管理方式缺乏便捷的移动端交互功能，线下往返操作流程比较繁琐，导致用户体验差。另外，电商整合也是一个点，传统的俱乐部可能只做场地租赁，现在结合商品销售和赛事服务可以增加收入来源。政策方面，国家鼓励全民健身，体育产业发展迅速，需要数字化管理提升效率。同时，数据化管理可以帮助俱乐部更好地分析用户行为，优化资源配置，比如热门时段定价策略，库存管理等。

1.  管理员功能

管理员功能包括了用户管理、场地管理、场地预约管理、赛事管理、赛事订单管理、商品管理、商品订单、轮播图管理，具体功能需求如下：

（1）用户管理：管理员可以管理用户的个人信息，包括头像、昵称、联系方式等，可以修改管理员密码。

（2）场地管理：管理员可以管理羽毛球场地的使用情况，包括场地状态是否启用、更改场地的图片、当日价格的定价等信息。

（3）场地预约管理：当用户预定场地之后，管理员可以在后台看到场地预约的订单信息。可以对预约订单进行管理，是否接受预定，是否删除订单信息也可以根据订单号查找订单记录。

（4）赛事管理：俱乐部内可以举办一些锦标赛、争霸赛，可以进行售票，管理员可以管理赛事的举办信息，包括赛事的名称、场次、类型等各种信息。

（5）赛事预约管理：管理员可以在后端接受到用户预约赛事的订单信息，可以对其给予回复，是否同意预约信息。

（6）商品管理：管理员在后台可以对商品进行有序的分类管理，可以根据库存的数量及时补充商品，以及对商品的状态信息的更改。

（7）商品订单管理：管理员可以查看所有的订单信息，也可以通过用户的订单号和姓名进行模糊查询。管理员还可以管理商品的发货，以及查看用户购买订单的详细信息。

（8）轮播图管理：管理员在后台页面进行对前台轮播图的显示进行管理，可以将热门赛事、促销商品或者羽毛球类新闻展示在前端界面中。

管理员用例图如图1所示。

图1  管理员用例图

1.  用户功能

用户的主要功能是预约场地、赛事预约、购买商品和购物车，详细的主要功能模块如下：

（1）首页：用户登录之后，在首页可以查看羽毛球俱乐部的最新公告、通知、促销活动等信息，保持对俱乐部动态的及时了解。提供便捷的导航菜单，用户可以轻松访问其他功能模块，如场地预约、商品购买和个人中心等。

（2）场地预约：用户可以在线浏览羽毛球场地的可用情况，包括场地类别、场地状态、价格等信息。还可以通过系统在线预约场地，选择时间和支付方式，避免排队等待和场地冲突。

（3）购买商品：用户在首页可以看到商品的展示信息，也可进入商品页进行挑选自己想要的商品。点击自己喜欢的商品，会进入到商品的详情页，这里展示了商品的详细信息，用户可以选择加入购物车或者直接购买商品。在支付时，通过自己的余额进行支付。

（4）赛事预约：系统首页的赛事页面，需要展示一些赛事，包括赛事的名称和图片，作为用户可以在线上预约赛事，例如举办的锦标赛和杯赛，通过售票也可以让俱乐部多一笔收入。

（5）购物车：用户可以将想购买的物品先加进自己的购物车，购物车的基本功能通常包括添加商品、查看商品、修改数量、删除商品、计算总价、库存校验和结算流程。

（6）个人中心：用户可以查看自己的场地、赛事预约订单和商品购物订单，以及查看自己的购物车。用户还可以编辑和管理个人信息，包括头像信息、个人昵称、联系电话和身份证号等，确保信息的准确性和安全性。

用户用例图如图2所示。

图2  用户用例图

1.  非功能需求分析

1.  安全性分析

本系统构建多层次安全防护体系，保障数据传输与操作安全。用户端通过HTTPS加密敏感数据，结合Token令牌验证机制防止会话劫持，确保身份认证安全。管理员端关键操作，如订单删除和价格修改。实施双因素认证，并记录详细操作日志，支持操作行为回溯与责任追踪。数据存储层面，用户密码、身份证号等敏感信息采用国密算法加密后存储于MySQL数据库，前端输入字段通过过滤机制防止SQL注入。

1.  易用性分析

本系统从用户与管理员双角色需求出发，通过界面交互优化提升操作便捷性。用户端采用响应式布局适配多终端，借助Vue.js实现动态数据加载与无刷新跳转，用户可通过直观图标导航在三步内完成场地预约或商品购买；管理员端以模块化表格展示用户、场地、商品等数据，支持快速检索与CRUD操作，预设业务模板降低配置难度，结合操作日志回溯功能减少误操作风险，实现“零培训”上手，用户满意度预期达90%以上。

1.  本章小结

本章从技术、经济、社会三方面论证系统可行性，确认了Spring Boot等成熟技术栈适配需求。梳理双角色功能边界，管理员端实现用户、场地、赛事、商品及订单的全流程管理。用户端则支持预约、购买等核心操作线上化。同时关注安全性与易用性，通过加密认证、响应式设计提升系统可靠性与操作体验，为系统设计与开发明确需求框架。

1.  系统设计

1.  系统功能设计

本系统是基于Spring Boot的管理系统，角色分为管理员和用户。其管理员所包括的功能模有用户管理、场地管理、场地预约管理、赛事管理、赛事预约管理、商品管理、商品订单管理、公告管理和轮播图管理；用户所包括的功能模块有个人中心、首页、场地预约、购买商品、赛事预约还有收货地址和商品订单的管理，系统功能模块图如图3所示。

图3  系统功能模块图

1.  系统流程设计

系统流程涵盖登录认证、业务操作与数据交互：用户登录时通过数据库校验账号密码，生成令牌实现权限控制。场地预约流程中，用户选择时段后系统实时校验场地状态与时间冲突，确认后生成订单并触发支付，管理员可在后台处理订单状态，可以同意或者取消订单，同步更新场地占用信息，全流程通过Spring Boot事件机制保障数据一致性。管理系统的设计将按照以下流程进行：开始要对本系统进行需求的分析，同时需要对本系统模块进行划分、系统功能进行设计和规划，做好本系统的各个模块与相匹配的数据库的挑选，本系统的研究开发如图4所示。

图4  系统流程图

1.   登录流程

进入系统后首先进入登录的页面，当用户输入账号和密码后点击登录按钮。本系统会将输入的其账号和密码的信息在数据库进行校验。如为空的情况下会弹出相应的提示框。如不为空的情况本系统会进行下一步账号或密码在其数据库表中是否有存在的状态进行判断。正确会成功登录本系统反之登录失败。登录流程图如图5所示。

图5  登录流程图

1.   场地预约流程

用户登录后可查看场地信息，选择要预约的场地，选择预约的时间，若当前时间显示已预约，则需重新预约场地，提交预约请求进行支付。如果余额不足，则会提示请充值并进行支付操作，提示预约成功。场地预约流程图如图6所示。

图6  场地预约流程图

1.   赛事预约流程

用户登录后进入赛事页面，浏览系统展示的赛事信息，包括赛事名称、类型、时间、座位数、价格等。用户选择感兴趣的赛事，点击进入赛事详情页，可以查看赛事信息的介绍、座位的布局等详细信息。在详情页中选择预约的日期和座位，系统实时校验该座位是否可预约。若选择座位已被预约，提示用户该座位已被预约，请重新选择座位；若可预约，用户可确认预约信息后提交预约请求，系统则会生成赛事订单，显示应付金额，用户选择支付方式进行支付。若余额不足，提示用户先充值再支付；若支付成功，系统更新赛事座位库存，标记该座位为已预约，并向用户反馈预约成功信息，同时生成订单记录。用户可在个人中心的赛事订单中查看预约详情，管理员在后台赛事订单管理模块可同步获取该订单信息并进行后续处理。赛事预约流程图如图7所示。

图7  赛事预约流程图

1.   商品购买流程

用户登录后进入商品页面后，浏览系统分类展示的羽毛球相关商品。点击想要购买的商品进入商品的详情页，可以查看商品的样式、规格、价格、库存等信息。用户可选择“加入购物车”将商品暂存或者“立即购买”直接进入结算流程。若选择加入购物车，系统将商品信息存入用户购物车，并提示添加成功；若选择立即购买，或从购物车中勾选商品进行结算，系统跳转至结算页面，用户需选择收货地址、确认购买数量及应付金额。提交结算前，系统校验商品库存是否充足及用户余额是否足够支付订单金额。若库存不足或余额不足，分别提示用户“库存不足”或“余额不足请充值”；若校验通过，系统生成商品订单，用户完成支付后，系统扣除对应商品库存，更新订单状态为 “已支付”，并向用户反馈购买成功信息。同时，管理员在商品订单管理模块可查看该订单详情，进行发货、售后等操作，用户可在个人中心的商品订单中跟踪订单状态（如待发货、已发货、已完成）。商品购买流程图如图8所示。

图8  商品购买流程图

1.  数据库设计

1.  数据库概念结构设计

（1）管理员实体，包含了管理员账号、密码、唯一标识符、创建时间等属性，管理员实体属性图如图9所示。

 

图9  管理员实体属性图

（2）用户实体，包含了ID、用户名、密码、姓名、手机号、身份证号、邮箱和年龄等属性，用户实体属性图如图10所示。

图10  用户实体属性图

（3）场地实体，包含了场地名称、场地照片、场地类型、预约原价格、现价、场地介绍、创建时间、是否上架和浏览量等属性，场地实体属性图如图11所示。

图11  场地实体属性图

（4）场地订单实体，有主键，预约单号，场地，用户，实付价格，创建时间，预约日期，支付类型，订单类型实体属性图如图12所示。

图12  场地订单实体属性图

（5）商品实体，包含了主键、商品名称、商品照片、创建时间、商品类型、商品库存、商品原价、商品简介、是否商家和点击次数等实体属性图如图13所示。

图13  商品实体属性图

（6）商品订单实体，包含了收货地址、商品、用户名、购买数量、创建时间、订单创建时间、支付类型、订单类型和实付价格等属性，商品订单实体属性图如图14所示。

图14  商品订单实体属性图

（7）购物车实体，包含了所属用户、商品、创建时间、更新时间、添加时间和购买数量等属性，购物车实体属性图如图15所示。

图15  购物车实体属性图

（8）赛事实体，包含了赛事名称、赛事照片、赛事管理、赛事类型、赛事原价、现价、创建时间、赛事介绍、是否上架、座位和浏览量等属性，赛事实体属性图如图16所示。

图16  赛事实体属性图

（9）赛事订单实体，包含了订单号、赛事、用户、实付价格、订单类型、创建时间、订购日期、和购买的座位等属性，赛事订单实体属性图如图17所示。

图17  赛事订单实体属性图

（10）赛事收藏实体，包含了赛事、用户、创建时间、收藏时间和类型等属性，赛事收藏实体属性图如图18所示。

图18  赛事收藏实体属性图

（11）收货地址实体，包含了主键、用户、收货人、电话、地址、创建时间、修改时间、添加时间、是否默认属性等属性，收货地址实体属性图如图19所示。

图19  收货地址实体属性图

（12）本系统包含了管理员和用户两个角色。其用户可对购物车执行“添加”操作（1对多），并查看购物车内容；管理员可对购物车进行“管理”（1对多）。能“购买”商品（1对多），产生商品订单（用户查看、管理员管理，均为1对多）。可“预定”场地（1对多），场地使用产生场地订单（用户查看、管理员管理，均为1对多）。能“预约”赛事（1对多），生成赛事订单（用户查看、管理员管理，均为1对多）。还可对自身相关内容进行“管理”（1对1）。而统一管理购物车、商品订单、商品、场地、场地订单、赛事订单、赛事等实体（均为1对多关系）。整体E-R图，如图20所示。

图20  系统整体E-R图

1.  数据库表设计

已确立数据库系统，要根据程序的系统要求，在数据库中建立数据库文件，并且建立表与表之间的关系。数据库表的设计是系统的核心基础，它决定了数据的存储结构和关联关系还有操作效率。良好的数据库表的设计能确保数据一致性，并且减少代码的冗余，并提高查询效率，从而提高系统性能的可维护性。本系统包含的数据库表具体内容如下：

（1）address，收货地址表。该表用来保存用户添加的收货地址，包含字段名称、类型、说明及是否允许为空的信息。主要字段包括用户ID、收货人姓名、联系电话、收货地址和是否默认地址等，用于存储和管理用户的收货信息。收货地址表如表1所示。

表1  收货地址表

列名	数据类型	说明	允许空
id	int	主键，唯一标识收货地址记录	否
user_id	int	用户ID，关联用户表主键
consignee	varchar(50)	收货人姓名
phone	char(11)	联系电话（11位手机号）
is_default	tinyint(1)	是否默认地址（1=是，0=否）	否
address	varchar(200)	收货地址（包含省市区及详细信息）
create_time	datetime	记录创建时间	否
update_time	datetime	记录最后更新时间

（2）shopcart，购物车表。该表用来保存用户执行添加商品功能后，主要字段包括用户ID、商品ID、购买数量、添加时间和最后更新时间等，用于存储和管理用户添加的购物车信息。购物车表如表2所示。

表2  购物车表

列名	数据类型	说明	允许空
id	int	主键，唯一标识购物车记录	否
user_id	int	用户ID，关联用户表主键
product_id	int	商品ID，关联商品表主键
quantity	int	购买数量
create_time	datetime	记录添加时间（格式：YYYY-MM-DD HH:MM:SS）	否
update_time	datetime	记录最后更新时间

（3）changdi，场地表。该表用来保存用户执行添加商品功能后，数据信息存储的表，包含字段名称、类型、说明及是否允许为空的信息。主要字段包括所场地名称、场地类型、场地地址、联系电话、租赁价格、场地状态、记录创建时间和最后更新时间等，用于存储和管理场地的信息。场地表如表3所示。

表3  场地表

列名	数据类型	说明	允许空
id	int	主键，唯一标识场地记录	否
name	varchar(100)	场地名称
type_id	int	场地类型ID，关联场地类型表主键
address	varchar(200)	场地地址（含省市区及详细位置）
contact_phone	char(11)	联系电话（11位手机号）
price_per_hour	decimal(10,2)	每天租赁价格（单位：元）
status	tinyint(1)	场地状态（0=空闲，1=已预约，2=维护中）	否
create_time	datetime	记录创建时间（格式：YYYY-MM-DD HH:MM:SS）	否
update_time	datetime	记录最后更新时间

（4）changdi_order，场地订单表。该表用来保存用户执行预定场地之后，在管理员后端会产生一个订单表，包含字段预约单号、实付价格、订单类型、字符类型、预约日期和预约时间等，用于存储和管理用户的场地订单信息。场地订单表如表4所示。

表4  场地订单表

列名	数据类型	说明	允许空
id	int	主键，唯一标识订单记录	否
order_number	varchar(32)	订单编号（唯一）
user_id	int	用户ID，关联用户表主键

续表4  场地订单表

列名	数据类型	说明	允许空
venue_id	int	场地ID，关联场地表主键
start_time	datetime	预约开始时间（格式：YYYY-MM-DD HH:MM:SS）	否
end_time	datetime	预约结束时间（同上）	否
total_amount	decimal(10,2)	订单总金额（单位：元）
payment_status	tinyint(1)	支付状态（0=未支付，1=已支付，2=已取消）	否
create_time	datetime	订单创建时间	否
update_time	datetime	订单最后更新时间

（5）dictionary，字典表。该表包含字段唯一标识字典记录、字典类型、字典项编码、字典项名称、显示排序号、状态、记录创建时间和最后的更新时间等，用于存储和管理字典信息。字典表如表5所示。

表5  字典表

列名	数据类型	说明	允许空
id	int	主键，唯一标识字典记录	否
dict_type	varchar(50)	字典类型（如 “场地类型”“订单状态”）
dict_code	varchar(50)	字典项编码（唯一）
dict_name	varchar(100)	字典项名称
sort_order	int	显示排序号	否
status	tinyint(1)	状态（0=禁用，1=启用）	否
create_time	datetime	记录创建时间	否
update_time	datetime	记录最后更新时间

（6）saishi，赛事表。该表包含赛事名称、赛事照片、赛事类型、门票原价、现价、座次和赛事介绍等，用于存储和管理赛事信息。赛事表如表6所示。

表6  赛事表

列名	数据类型	说明	允许空
id	int	主键，唯一标识赛事记录	否
name	varchar(100)	赛事名称
type_id	int	赛事类型ID，关联字典表（赛事类型）
price	decimal(10,2)	赛事票价（单位：元）
seat_count	int	总座位数
status	tinyint(1)	赛事状态（0 =未开始，1=进行中，2=已结束）	否
start_time	datetime	赛事开始时间（格式：YYYY-MM-DD HH:MM:SS）	否
end_time	datetime	赛事结束时间（同上）	否
create_time	datetime	记录创建时间（同上）	否
update_time	datetime	记录最后更新时间

（7）saishi_collection，赛事收藏表。该表包含赛事名称、用户名、类型、创建时间和收藏时间等，用于存储和管理用户收藏赛事的信息。赛事收藏表如表7所示。

表7  赛事收藏表

列名	数据类型	说明	允许空
id	int	主键，唯一标识收藏记录	否
user_id	int	用户ID，关联用户表主键
event_id	int	赛事ID，关联赛事表主键
type	tinyint(1)	收藏类型（1=普通收藏，2=关注赛事）	否
create_time	datetime	收藏时间	否

（8）saishi_commentback，赛事评价表。该表包含赛事名称、用户、评价内容、回复时间和创建时间等，用于存储用户对赛事的评价信息。赛事评价表如表8所示。

表8  赛事评价表

列名	数据类型	说明	允许空
id	int	主键，唯一标识评价记录	否
event_id	int	赛事ID，关联赛事表主键
user_id	int	用户ID，关联用户表主键
comment_content	varchar(500)	评价内容
reply_content	varchar(500)	回复内容（管理员填写）	否
create_time	datetime	评价时间	否
update_time	datetime	最后更新时间

（9）saishi_order,，赛事订单表。用来记录用户预定的赛事信息，订单编号是唯一的，有赛事ID和用户ID两个外键。赛事订单表包含订单号、用户名、订单类型、支付类型、购买的座位和实付价格，用于存储和管理赛事订单信息。赛事订单表如表9所示。

表9  赛事订单表

列名	数据类型	说明	允许空
id	int	主键，唯一标识订单记录	否
order_number	char(32)	订单编号（唯一）
event_id	int	赛事ID，关联赛事表主键
user_id	int	用户ID，关联用户表主键
seat_number	varchar(50)	购买座位号
total_amount	decimal(10,2)	订单总金额（单位：元）
payment_status	tinint(1)	支付状态（0 =未支付，1=已支付，2=已取消）	否
create_time	datetime	订单创建时间	否
update_time	datetime	订单最后更新时间

（10）shangpin,，商品表。该表包含商品名称、照片、类型、库存、现价、是否上架、商品简介和创建时间，用于存储和管理用户购买商品的信息。商品表如表10所示。

表10  商品表

列名	数据类型	说明	允许空
id	int	主键，唯一标识商品记录	否
name	varchar(100)	商品名称
category_id	int	商品分类 ID，关联字典表（商品类型）
price	decimal(10,2)	商品现价（单位：元）
stock	int	库存数量
status	tinyint(1)	商品状态（0=下架，1=上架）	否
description	varchar(500)	商品简介	否
create_time	datetime	记录创建时间	否
update_time	datetime	记录最后更新时间

（11）shangpin_collection，商品收藏表。该收藏表包含了唯一表示收藏记录商品ID、用户ID和收藏时间等，用于存储和管理不同用户收藏商品的数据信息。商品收藏表如表11所示。

表11  商品收藏表

列名	数据类型	说明	允许空
id	int	主键，唯一标识收藏记录	否
user_id	int	用户ID，关联用户表主键
product_id	int	商品ID，关联商品表主键
create_time	datetime	收藏时间	否

（12）shangpin_commentback，商品评价表。该评价表包含商品ID、用户ID、回复内容、评价创建时间和最后更新时间等，用来存储和管理用户对商品的评价信息。商品评价表如表12所示。

表12  商品评价表

列名	数据类型	说明	允许空
id	int	主键，唯一标识评价记录	否
product_id	int	商品ID，关联商品表主键
user_id	int	用户ID，关联用户表主键
comment_text	varchar(500)	评价内容
reply_text	varchar(500)	回复内容（管理员填写）	否
create_time	datetime	评价创建时间（格式：YYYY-MM-DD HH:MM:SS）	否
update_time	datetime	最后更新时间

（13）shangpin_order，商品订单表。该订单表包含订单编号、收货地址、商品ID、用户ID、购买数量、订单总金额、支付状态、订单创建时间和订单最后更新时间，用于存储和管理商品订单信息。商品订单表如表13所示。

表13  商品订单表

列名	数据类型	说明	允许空
id	int	主键，唯一标识订单记录	否
order_number	char(32)	订单编号（唯一）
address_id	int	收货地址ID，关联收货地址表主键	否
product_id	int	商品ID，关联商品表主键
user_id	int	用户ID，关联用户表主键
quantity	int	购买数量
total_amount	decimal(10,2)	订单总金额（单位：元）
payment_status	tinyint(1)	支付状态（0 =未支付，1=已支付）	否
create_time	datetime	订单创建时间	否
update_time	datetime	订单最后更新时间

（14）yonghu，用户表。该表包含用户账户、用户姓名、联系电话、身份证号、头像、电子邮箱和余额等，用于存储和管理用户信息。用户表如表14所示。

表14  用户表

列名	数据类型	说明	允许空
id	int	主键，唯一标识用户记录	否
username	varchar(50)	用户账号（唯一）
name	varchar(20)	用户姓名
phone	char(11)	联系电话（11位手机号）
id_number	char(18)	身份证号（18位）	否
avatar	varchar(200)	头像图片URL	否
balance	decimal(10,2)	账户余额（单位：元）

（15）user，管理员表。当注册了新的管理员时，新增管理员的信息会添加到数据的user表，该表包含唯一主键id、管理员账户、登录密码、和角色管理以及账号的创建时间。管理员表如表15所示。

表15  管理员表

列名	数据类型	说明	允许空
id	int	主键，唯一标识管理员记录	否
username	char(50)	管理员账号（唯一）
password	char(64)	登录密码
role	char(20)	角色管理
create_time	datetime	账号创建时间	否

1.  本章小结

第4章主要围绕羽毛球俱乐部管理系统展开了详细的设计，构建了双角色功能架构与流程逻辑。在功能设计上，明确管理员端的核心模块，包括用户管理、场地调度、商品运营及用户端的预约购买等。流程设计包括登录认证、预约支付、订单处理等流程图，数据库设计基于E-R模型完成15张数据表的结构定义。

1.  系统实现

1.  登录功能

管理员在登录页面输入账号密码并点击登录后，前端通过HTTP协议向服务器发送POST请求。后端控制器层的UserLoginController接收到请求后，调用服务层UserService的getInfoByName(username)方法，该方法进一步调用持久层AdminMapper，在数据库中根据输入的账号和密码查询对应用户信息，并将查询结果封装为User对象返回至服务层。控制器层对返回数据进行逻辑判断：若用户名不存在，向前端返回错误码“e1”及提示信息“用户名不存在”；若密码不匹配，返回错误码“e2”及提示信息 “密码不正确”；若验证通过，则返回“success”及 “登录成功”提示。整个流程通过分层架构实现前后端解耦，利用Spring Boot的依赖注入机制简化组件间调用，确保登录验证的高效性与安全性。登录页面如图21所示。

图21  登录页面

1.  注册功能

注册功能涉及后端处理请求、数据验证、数据库操作，以及前端表单提交和路由。另外，权限控制是关键，确保注册接口可以被公开访问。注册功能通过三层架构实现：Controller层接收/register请求并调用UsersService进行业务处理→Service层通过MyBatis-Plus封装的selectOne方法校验用户名唯一性，调用insert执行插入→Mapper层由MyBatis-Plus自动生成SQL语句（SELECT COUNT查询和INSERT操作）完成数据库交互。

总结来说，注册功能的实现涉及多个部分：控制层处理请求和逻辑，服务层操作数据库，实体类映射数据结构，拦截器配置确保接口可访问，前端提交表单并处理响应。注册界面如图22所示。

图22  注册界面

1.  管理员功能

1.  用户管理

用户信息列表中，展示了用户的姓名，身份证号和头像等信息，当用户比较多的时候，可以通过上面的查找功能进行对某个用户的查找。管理员可以管理所有用户的信息，可以查看用户的详细的个人信息，同时也可以对用户的信息进行修改，包括用户的密码。在用户管理功能实现中，后端通过YonghuController接收前端请求，调用服务层YonghuService完成业务逻辑处理。以用户列表查询为例，控制器通过@GetMapping("/list")接口接收查询参数（如用户名模糊查询字段usernameLike），服务层利用 MyBatis-Plus 的LambdaQueryWrapper构建查询条件，实现对用户表yonghu的分页查询与模糊匹配。通过分页插件实现数据分批次加载，利用like条件实现用户名模糊搜索，返回结果包含用户记录列表及总条数，满足管理员高效查询与管理用户信息的需求。用户信息列表如图23所示。

图23  用户管理

1.  场地管理

场地管理里边包含了场地的各种信息，具体的功能的实现如下，用于接收前端传参的实体模型是ChangdiModel.java，包含场地的基本信息，如名称、照片、类型、价格、已售数量（changdiClicknum）、上下架状态（shangxiaTypes）等。已售数量和上下架状态的存在表明系统可能通过这两个字段来管理场地的可用性。例如，当用户预约时，changdiClicknum会增加，而shangxiaTypes用于控制场地是否可被预约。场地上下架控制，通过shangxiaTypes字段实现场地可用性控制（1=上架可预约，0=下架不可预约），在创建订单前会校验该状态。库存动态管理，利用changdiClicknum字段记录已预约数量，每次成功预约执行+1操作，取消预约则-1。配合场地最大容量设置（需在数据库表中添加max_capacity字段）实现库存控制。三重校验机制，前置校验：检查场地是否上架（shangxiaTypes==1）库存校验：当前预约数 < 最大容量（changdiClicknum<maxCapacity）。时间校验：通过SQL查询验证预约时间段是否已被占用如图24所示。

图24  场地管理

1.  场地预约管理

场地预约订单管理涉及订单列表展示，显示所有预约记录，包括用户信息、场地、时间、状态等。订单状态管理：如手动取消订单、标记为已完成等操作。数据统计：根据时间、场地类型等维度统计预约情况。管理员需要能够查看所有用户的预约记录，处理订单状态，查看销售统计，以及管理场地的可用性。场地预约订单处理流程：用户提交场地预约请求后，前端通过Ajax将预约信息（场地ID、时间、用户ID等）发送至后端ChangdiOrderController的/create接口。后端首先调用ChangdiService校验场地状态（是否上架、是否空闲）及时间冲突（通过SQL查询该时段是否已生成订单），若校验通过则开启数据库事务，生成场地订单记录（插入changdi_order表）并更新场地状态为“已预约”（修改changdi表的status字段为1）。管理员通过后台订单列表页查看预约记录时，可点击“同意”或“取消”按钮触发状态变更。同意预约之后，后端更新订单状态为 “已支付”（payment_status=1），场地状态保持 “已预约”。取消预约操作之后，回滚场地状态为“空闲”（status=0），并删除或标记订单为“已取消”（payment_status=2）。同时通过前端Layui表格的实时刷新机制，使管理员操作结果即时同步至页面。场地预约管理的效果图如图25所示。

图25  场地预约订单管理

1.  商品管理

商品管理则是用到数据库表来存储商品信息，包括商品ID、名称、描述、价格、库存等字段。然后在控制层编写一个API接口，用来接收前端传递的商品信息，将其保存到数据库中。页面中的数据展示则是，编写在同一个控制层中编写API接口，根据查询条件（如商品ID、名称等）从数据库中检索商品信息，并返回给前端。接收前端传递的商品信息，更新数据库中对应的商品记录。删除操作则是根据前端请求中传来的当前行的商品ID，然后根据商品ID，删除数据库中的商品记录，并将删除的结果返回给前端用户界面。提供表单界面，用户可以输入商品信息，点击提交后调用后端的创建API。商品管理如图26所示。

图26  商品管理

1.  商品订单管理

商品订单管理模块实现对用户商品购买订单的全流程管控，涵盖订单查询、状态更新及物流跟踪等核心功能。管理员可通过后台界面查看所有商品订单，支持按订单号、用户姓名、商品名称等字段进行模糊搜索，快速定位目标订单。订单列表直观展示订单编号、商品信息、用户详情、支付状态及创建时间，系统同步更新数据库中订单状态字段（payment_status），并通过消息推送告知用户状态变更。后端通过ShangpinOrderController接收前端请求，调用服务层ShangpinOrderService处理业务逻辑，利用MyBatis-Plus操作商品订单表（shangpin_order）。发货操作对应服务层方法updateOrderStatus(Integer orderId, Integer status)，通过数据库事务确保订单状态与库存数据的一致性。前端采用Vue组件结合Layui表格渲染订单数据，提供“发货”“取消”等操作按钮，点击后触发Ajax请求调用后端接口，实现无刷新状态更新。商品订单管理界面如图27所示。

图27  商品订单管理

1.  轮播图管理

轮播图管理模块通过构建专用数据库表实现结构化存储，包含图片URL、链接地址、显示顺序及启用状态等字段。轮播图管理模块通过扩展数据库结构与交互逻辑实现功能强化，新增group_type字段区分应用场景，引入display_time与expire_time实现定时上下架；前端集成分组下拉菜单与时间选择组件，支持可视化分组管理与实时预览，通过鼠标拖拽调整显示顺序；后端基于Spring Security 实现权限粒度控制，利用Thumbnailator压缩图片，并通过点击事件监听接口统计点击量（click_count），最终形成场景化分组、自动化定时与数据化评估的完整运营体系，提升首页流量利用率与用户转化率。轮播图的实现效果如图28所示。

图28  轮播图管理

1.  用户功能

1.  场地预约

用户需要登录后才能预约，前端通过localStorage保存用户信息，每个请求携带token。如果用户未登录时点击预约，会跳转到登录页面。登录后，可以继续预约流程。用户首先进入场地列表，选择某个场地，进入详情页，选择时间，提交预约。前端会收集这些信息，通过ajax发送到后端的预约接口。后端处理验证，创建订单，更新库存，返回结果给前端。时间选择用到了layui的日期时间组件，前端需要确保用户选择的时间段有效，在开放时间内，没有冲突。前端和后端的交互功能通过RESTful API，数据的传递参数的格式则使用JSON数据格式。提交预约时，POST /api/yuyue/create，携带用户ID、场地ID、时间等参数。后端返回成功或错误信息。总结来说，用户端的场地预约功能包括前端的页面展示、数据表格的表单提交更新、后端验证和库存数量的管理。需要前后端协作，确保数据的一致性和正确性，实现效果如图29、30所示。

图29  用户场地预约首页

图30  用户场地预约详情页

1.  购买商品

用户登录成功之后，在商品界面进行购物，购买商品的流程包括以下几个步骤：浏览商品、加入购物车、确认订单信息、支付和订单查看。前端可以通过不同的页面来实现这些步骤。在商品列表页会展示所有商品，当用户点击商品时进入商品详情页，可以选择加入购物车，然后在购物车页面选择商品去结算，也可直接进行购买。点击提交，生成订单，最后支付。用户需要登录才能访问购物车和个人中心。在JavaScript部分，有检查用户是否登录的逻辑，如果用户未登录，会跳转到登录页面。前端使用了Ajax与后端交互，当系统启动时，会自动向后端发送请求接口，获取商品列表、加入购物车、创建订单等信息，展示在前端供用户查看。实现效果如图31、32所示。

图31  商品首页页面

图32  购买商品详情页

1.  购物车功能

当用户进入商品购买界面之后，在进行商品购买时，可以选择加入购物车，当点击加入购物车时，前端发送POST请求到后端的购物车接口，携带商品ID和数量。后端验证用户身份，处理请求，返回结果。购物车页面可能显示用户已选商品，允许调整数量，然后跳转到结算页面。结算页面需要选择收货地址，随即选择提交订单，当提交后生成订单。本系统的支付集成了第三方支付接口，支付宝、微信支付和银行卡支付，但在本系统中只是模拟支付流程。当订单生成后，用户可以在个人中心查看订单状态，有待支付、已发货、已完成等状态。订单状态的变化可能由后端服务更新，前端定时查询或通过WebSocket实时通知。安全方面，用户的购物车和订单数据需要与用户账户关联，确保数据隔离。后端使用了session来管理用户身份，每个请求都携带认证信息。库存管理也是重要的一环。当用户下单时，后端需要检查商品库存，避免超卖。这可能需要使用数据库的事务或乐观锁机制，保证在高并发下库存的准确性。购物车的功能实现，如图33所示。

图33  购物车

1.  个人中心

用户端个人中心模块包括账户信息管理、订单查询及购物车操作等核心功能，基于 Vue 组件化开发实现模块间无刷新切换，通过Axios与后端 Spring Boot 接口交互完成数据加载与更新。其中，个人信息管理支持非敏感字段编辑与实时校验，订单管理分类展示场地和商品订单详情并提供退款、评价等操作入口，购物车功能实现商品数量调整、库存校验及一键结算。系统采用响应式布局优化多端显示，集成 Layui 表格组件提升数据浏览效率，方便实时展示订单的详细信息。用户端个人中心中的场地订单、商品订单、购物车以及个人信息管理等功能的实现效果图如图34、35所示。

图34  场地订单页面

图35  我的商品订单

1.  系统测试

本次功能测试聚焦于验证羽毛球俱乐部管理系统各模块的完整性与准确性，确保系统在多元操作场景下稳定运行，充分满足用户与管理员的业务需求。测试环境配置为Chrome110及以上版本浏览器，采用apifox进行接口测试，并借助MySQL Workbench校验数据交互的准确性。

管理员角色测试：进入用户管理模块，输入用户名执行搜索操作，系统应准确展示对应用户信息；尝试删除无效用户，系统提示“无此用户”，数据校验无误。在场地管理中调整场地状态为“维护”，前台页面应即时显示该场地不可预约；处理商品订单时，确认发货操作后，用户端同步显示物流信息更新。

1. 1.  功能测试

用户端功能测试主要从登录注册测试、场地模块测试、赛事预约和商品模块测试四大功能分别进行测试。

1. 1. 1.  登录注册测试

（1）用户角色测试，在注册页面录入有效手机号及密码，点击“注册”按钮，预期系统提示“注册成功”并跳转至登录页面，实测结果与预期相符；登录后选取场地及时间提交预约，系统应反馈“预约成功”，经检验功能运行正常。在商品模块选购物品加入购物车并完成结算，预期订单生成同时库存数据同步减少，查看订单列表可查见新生成订单，各项表现均符合预期。测登录测试用例如表16所示。

表16  登录注册测试用例

测试模块	测试用例	预期结果	实际结果	测试结果
登录模块	用户名：123111    密码：123456	弹出错误提示，提示用户名错误	弹出错误提示，提示用户名错误	通过
登录模块	用户名：songlukang 密码：	弹出错误提示，提示输入密码	弹出错误提示，请输入密码	通过
登录模块	用户名：songlukang 密码：666666	用户登录成功	用户登录成功	通过
注册模块	重复用户名注册	已有用户名：songlukang 新加用户名：songlukang	弹出错误提示，提示用户名重复	弹出错误提示，提示用户名重复
注册模块	正常注册	用户名：songlukang 密码：zhangsan	用户注册成功	用户注册成功

1. 1. 1. 场地模块测试

场地预约功能的测试需要考虑多种情况，首先如果没有登录就进行场地预约，会提示请用户先登录。当用户登录之后，首先进行选定场地，场地选定之后，需要选择时间，当场地已经被预约了之后，会提示用户场地已被预约，重新选择日期进行预约。场地预约也是需要付钱，当余额不足的时候，也应该会提示用户余额不足，应进行充值，充值之后再进行场地的预约，当场地预约成功之后，在个人中心能查到自己的预约信息，管理员是否受理。场地预约测试如表17所示。

表17  场地模块测试表

模块名称	测试项	测试操作	预期结果	实际结果	测试结果
场地预约模块	时间冲突预约	同一账户重复预约同一时间	预约失败，提示该场次已被预约	提示已被预约	通过
场地预约模块	余额不足预约	余额小于预约场次的价格	弹出错误提示，余额不足，请充值	弹出错误提示，余额不足，请充值	通过

1. 1. 1.  商品购买测试

商品购买功能的设计同样需要考虑多种情况，首先没有登录便进行购买商品，会被拦截，然后提示用户先登录，用户登录之后，首先进行选择商品，商品选定之后，可以根据自己的情况选择是否加入购物车，当商品的库存小于购买量时，应当提示用户库存不足。若是库存充足，进行支付操作，当余额不足的时候，也应该会提示用户余额不足，应进行充值，充值之后再进行商品的购买，当商品购买成功之后，在个人中心的个人场地商品订单里面能查到自己的订单信息。商品购买测试如表18所示。

表18  购买商品测试表

测试模块	测试项	测试操作	预期结果	实际结果	测试结果
商品购买模块	库存不足购买	将目标商品库存设为0	弹出错误提示，提示用户库存不足	弹出错误提示，提示用户库存不足	通过
商品购买模块	余额不足购买	将余额设为0	弹出错误提示，余额不足，请充值	弹出错误提示，余额不足，请充值	通过
商品购买模块	正常购买	库存充足，余额充足	成功购买，提示购买成功	提示购买成功	通过

1. 1. 1.  赛事预约测试

赛事预约功能需验证用户在不同场景下的预约操作是否符合预期，包括正常预约流程及异常情况处理。测试覆盖未登录预约、座位冲突、余额不足等场景，确保系统反馈准确且数据更新正确。赛事预约测试如表19所示。

表19  购买商品测试表

测试模块	测试项	测试操作	预期结果	实际结果	测试结果
赛事预约模块	未登录预约	未登录状态下点击赛事预约	跳转至登录页面，提示 “请先登录”	跳转登录页并提示	通过
赛事预约模块	座位冲突预约	同一账户重复选择已被预约的座位	提示 “该座位已被预约，请重新选择”	弹出座位已被预约提示	通过
赛事预约模块	余额不足预约	用户余额小于赛事票价	弹出错误提示 “余额不足，请充值”	提示余额不足需充值	通过
赛事预约模块	正常预约	选择可预约座位，余额充足	生成赛事订单，提示 “预约成功”，个人中心订单列表显示该订单	订单生成且状态正确	通过
赛事预约模块	下架赛事预约	预约状态为 “下架” 的赛事	提示 “该赛事暂未开放预约”	系统拒绝预约并提示	通过

1. 1.  测试结果

功能测试全面覆盖用户与管理员双角色核心操作，涵盖登录注册、场地预约、商品购买及赛事预约四大模块。登录注册验证了账号密码校验、唯一性检查等逻辑；场地预约与赛事预约准确处理时间/座位冲突、余额不足等异常场景；商品购买实现库存与余额的实时校验。经测试，系统在用户权限控制、数据交互准确性及异常处理机制上表现稳定，核心功能均成功通过测试，满足羽毛球俱乐部日常运营需求。

本文标签： 管理系统 俱乐部 羽毛球 SpringBoot