springboot古城景区管理系统88564-计算机课程设计、毕业设计

第一章 绪论

1.1 研究背景与意义

1.1.1 研究背景

　　文化旅游产业的持续扩张推动着景区信息化建设进入加速阶段。古城景区因兼具文化传承与旅游消费的双重属性，管理业务链条远比普通自然景区复杂。现有古城景区的运营模式大量依赖人工操作：购票窗口排队等候时间长，商铺信息分散无法在线查询，导览资料以纸质形式发放且更新滞后，景点打卡活动缺乏有效的数字记录手段。这些问题在节假日高峰期被集中放大，严重制约游客体验的整体质量1。国内相关研究表明，数字化管理平台的建设能够系统性地改善景区服务效率，实现业务数据的集中管控与实时分析2。与此同时，非物质文化遗产数字化展示的实践也为古城景区引入多媒体互动、在线预约等功能模块提供了成熟的参考路径3。当前，Java Web技术体系已发展为国内景区信息系统建设的主流技术选型，Spring Boot框架凭借其轻量化配置、模块解耦清晰、接口开发效率高等特点，在中小型景区管理系统的落地实践中展现出显著优势。面向古城景区多角色、多业务场景的管理需求，构建一套功能完整、架构清晰的综合性管理系统，既是技术发展趋势的必然导向，也是景区数字化运营的现实迫切需求。

1.1.2 研究意义

　　本系统的建设对古城景区的运营管理具有切实的改进价值。系统将购票预约、导航地图、景区商城、打卡互动等核心业务集成至统一平台，显著缩短游客在各业务环节的等待时间，降低景区工作人员在重复性事务上的人工成本。多角色权限体系的引入使景区管理者、商家、管理员各自在授权范围内完成操作，减少跨部门协调摩擦，提升整体管理精度。订单数据、游客行为数据的系统性积累为景区经营决策提供可量化的数据依据，改变依赖经验判断的粗放管理方式。在示范效应层面，本系统的设计思路与技术实践路径可为同类型文化旅游景区开展数字化转型提供参照，具备一定的行业推广价值。

1.2 国内外研究现状

1.2.1 国内现状

　　国内景区信息化管理的研究起步于二十一世纪初，早期研究集中于景区票务系统的电子化改造，技术形态以C/S架构的单机管理软件为主。进入移动互联网时代后，研究方向逐步向B/S架构的综合管理平台迁移，景区商城、在线预约、游客互动等功能模块相继被纳入研究视野。近年来，大数据分析、GIS地理信息、小程序开发等技术方向持续融入景区管理系统的研究议题，系统形态从单一票务管理演进为覆盖游前、游中、游后全流程的综合服务平台。

　　宁毅等人于2024年基于智能化技术构建了智慧景区应用系统，系统采用Flask Web框架、Vue前端框架与MySQL数据库的技术组合，实现了景点管理、用户管理、订单管理及门票管理等核心功能模块，其多角色权限划分的设计思路对本系统的角色体系构建具有直接借鉴价值4。王育英于2024年完成了基于GIS二次开发的旅游规划信息系统研究，该研究将地理信息技术深度整合至景区服务体系，为游客提供精准的空间定位与路线规划功能，本系统导航地图模块的功能设计从中获得了重要的方法论启示5。和娴等人于2024年设计并实现了旅游景区游客信息系统，系统基于移动定位技术对游客行为数据进行系统性采集与分析，涵盖热门景点识别、游客类型判断、消费数据统计等功能，其数据驱动的运营分析理念对本系统订单数据模块的设计产生了参考意义6。

1.2.2 国外现状

　　国外在景区管理与文化旅游信息系统领域的研究具有明显的智能化导向，研究成果集中于大数据驱动的游客行为分析、虚拟现实技术在文化遗产展示中的应用，以及基于物联网感知的景区实时监控系统。总体而言，国外研究更注重用户体验的系统性评估与多技术手段的融合创新，技术方案成熟度高，但部分成果的落地场景与国内古城景区的运营现实存在一定差距。

　　Rong等人于2024年提出了基于异常行为识别的大数据智慧旅游管理平台，将区域卷积3D网络模型与轨迹分析方法相结合，实现景区内异常行为的实时识别，研究表明该方法在准确率和召回率上均显著优于传统双流模型，其平台的多模块协同架构设计对本系统功能分层的思路形成了参考7。Teeng等人于2021年对虚拟现实技术在文化遗产实践中的可用性进行系统性综述，识别出系统设计、开发过程、技术实现、评估方式、知识传递五个维度的挑战，并提出58条改进建议，其关于用户体验系统性评估的研究框架对本系统界面交互设计具有方法论层面的借鉴意义8。Shi等人于2021年完成了泉州新型智慧旅游管理平台的设计与实现，平台围绕景点信息管理、酒店信息管理等核心功能模块展开设计，响应国家"互联网+旅游"政策导向，其功能模块的划分逻辑与本系统的模块结构设计具有较强的参照关系9。

　　国外研究在技术深度与智能化程度上具备明显优势，但其系统设计多面向大规模景区或特定技术场景，与国内古城景区多角色、轻量化、强业务融合的实际需求存在落差。本系统在吸收国外研究关于用户体验评估、平台功能分层、多模块协同等核心设计思想的基础上，结合古城景区商城购物、互动打卡、预约购票等本地化业务场景，形成更贴合实际运营需求的系统设计方案。

1.3 研究内容

　　本文的核心工作是面向古城景区多元业务场景，完成基于Spring Boot框架的古城景区管理系统的设计与实现。研究从需求分析阶段出发，通过对用户、景区管理者、商家、管理员四类角色的业务需求进行系统性梳理，明确各角色的功能边界与交互关系，为后续设计工作奠定需求基础。需求分析完成后，研究进入系统设计阶段，依次完成系统整体架构设计、功能结构划分、核心业务流程建模，以及数据库概念模型与逻辑模型的构建，形成覆盖系统全貌的设计文档。在模块实现阶段，研究按照角色维度逐一推进各功能模块的编码工作，重点完成景区商城、订单管理、预约购票、退票申请、导航地图、互动打卡、优惠券管理、通知公告等核心业务模块的开发。数据设计贯穿系统实现的全过程，通过对数据库表结构的精细化设计保障业务数据的完整性与一致性。研究的最终交付物为可完整运行的系统原型，并配套功能测试报告。本研究不涉及系统的高并发性能调优、分布式部署方案，以及移动端原生应用开发等相关内容。整体研究遵循软件工程的生命周期方法论，按照需求---设计---实现---测试的工作流顺序推进各阶段任务。

第二章 相关技术介绍

2.1 Spring Boot框架

　　Spring Boot是由Pivotal团队在Spring框架基础上进一步封装而成的快速开发框架，其核心设计理念是"约定优于配置"。开发者无需编写大量的XML配置文件，框架通过自动配置机制在应用启动时依据类路径中的依赖自动完成组件装配，大幅降低项目初始化的复杂度。Spring Boot内嵌Tomcat等Servlet容器，使得应用可以以独立JAR包的形式直接运行，免除了传统Java Web项目必须依赖外部容器部署的约束10。

　　在本系统中，Spring Boot承担后端业务逻辑的核心运行容器职责。景区商城的商品查询、订单状态流转、预约购票的库存扣减、退票申请的审核流程，均通过Spring Boot构建的RESTful接口对外暴露服务。Spring Boot的分层架构设计使Controller层、Service层、Repository层之间的职责边界清晰，不同角色的业务逻辑得以在各自的Service模块中独立维护，系统整体的可维护性显著提升11。

2.2 Vue前端框架

　　Vue是一套以数据驱动视图为核心设计哲学的渐进式JavaScript前端框架，由尤雨溪主导开发并持续演进至当前的Vue 3版本。Vue采用组件化开发模式，每个页面功能单元被封装为独立的单文件组件，组件内部集中管理模板、逻辑与样式，模块边界清晰，复用粒度精细。响应式数据系统是Vue的核心机制，当数据状态发生变化时，视图层自动完成局部更新，无需开发者手动操作DOM节点12。

　　Vue在本系统的前端开发中负责构建用户与系统交互的完整界面层。景点信息的列表渲染、导航地图的组件嵌入、景区商城的商品展示、互动打卡的状态反馈，均依托Vue的响应式机制实现数据与界面的同步更新。Vue Router负责管理前端的路由跳转，不同角色登录后自动导航至对应的功能模块，Vuex或Pinia状态管理工具则用于维护用户登录态与购物车等全局数据，构成前端业务逻辑的完整支撑体系13。

2.3 MySQL数据库

　　MySQL是目前使用最为广泛的开源关系型数据库管理系统，以其稳定的事务处理能力、成熟的索引优化机制、灵活的存储引擎选择成为中小型应用系统的首选数据层解决方案。MySQL支持SQL标准的完整子集，InnoDB存储引擎提供行级锁定与外键约束，保障高并发写入场景下的数据一致性14。

　　本系统所有核心业务数据均存储于MySQL数据库。用户信息、景点数据、商品目录、订单记录、预约信息、打卡记录等业务实体以关系型表结构组织，实体间的关联关系通过外键约束与联合查询实现。Spring Boot通过MyBatis-Plus框架与MySQL建立数据访问通道，业务层对数据库的增删改查操作被封装为类型安全的Mapper接口，降低了SQL编写错误的风险，同时保持了查询逻辑的可扩展性15。

2.4 B/S架构

　　B/S架构即浏览器-服务器架构，是相对于C/S架构演进而来的一种软件系统部署模式。在B/S架构下，客户端仅需标准浏览器即可访问系统全部功能，无需在用户终端安装专属客户端软件。业务逻辑集中部署于服务器端，系统维护与功能升级只需在服务器侧完成，更新结果即时对所有用户生效，大幅降低运维管理成本16。

　　古城景区管理系统采用B/S架构，使得游客、景区管理者、商家、管理员四类角色均可通过浏览器直接访问系统对应功能模块，无需针对不同操作系统分别开发客户端应用。景区商城的商品浏览、订单提交、预约购票的座位选择等面向游客的功能，景点信息的发布与打卡管理等面向景区管理者的功能，均在同一套B/S架构下统一承载。前端Vue应用与后端Spring Boot服务通过HTTP协议完成数据交互，架构层次分明，部署结构简洁17。

第三章 系统分析

3.1 可行性分析

3.1.1 技术可行性

　　Spring Boot框架在国内中小型Web系统开发中已积累了大量成熟实践，其与Vue前端框架、MySQL数据库的技术组合具备明确的社区支持与文档保障。B/S架构下的前后端分离开发模式已成为业界主流，各技术组件之间的接口规范成熟、兼容性稳定。系统所涉及的订单管理、预约购票、权限控制等业务模块均属常规Web系统功能范畴，现有技术栈完全具备支撑其完整实现的能力，技术风险处于可控范围之内。

3.1.2 经济可行性

　　本系统采用全开源技术栈，Spring Boot、Vue、MySQL均为免费使用的开源框架，无需承担商业软件授权费用。开发环境基于标准PC硬件与本地数据库部署，硬件投入成本有限。系统建成后的日常运维主要依赖服务器的基础托管费用，维护操作集中于服务器侧，无需向终端用户推送更新，长期运营成本处于合理区间，整体建设投入具备经济上的合理性。

3.1.3 操作可行性

　　系统前端基于Vue框架构建响应式界面，页面布局遵循常见Web应用的交互规范，功能入口层级清晰，操作路径短。游客角色的主要操作集中于景区商城浏览、购票预约、打卡签到等高频场景，交互步骤精简。景区管理者与商家的后台管理界面采用表格式数据展示与表单提交的标准模式，用户无需经过专项培训即可完成日常操作任务，学习成本处于较低水平。

3.2 功能需求分析

3.2.1 用户角色功能需求

　　用户角色是古城景区管理系统面向游客群体开放的核心使用端。该角色可在景区商城中浏览商品、完成下单操作，并查看对应的订单详情记录。导航地图模块为用户提供景区内的位置定向与路线浏览功能。景点信息模块支持用户查看各景点的基础资料。互动打卡模块允许用户在抵达指定景点后完成签到操作，触发系统记录并生成打卡轨迹。如图3-1所示。

图3-1用户用例图

3.2.2 景区管理者角色功能需求

　　景区管理者角色承担景区日常运营数据的维护与审核职责。该角色可对景点基础信息进行录入、修改与查询操作。预约购票管理模块支持对游客预约记录的查看与状态调整。退票申请模块允许景区管理者对游客提交的退款请求进行审核处理。景点打卡模块支持管理者对打卡记录数据进行统计浏览。如图3-2所示。

图3-2景区管理者用例图

3.2.3 商家角色功能需求

　　商家角色对应入驻古城景区的店铺经营主体。该角色可在景区商城模块中管理店铺商品的上架与下架操作。添加优惠券模块支持商家创建面向游客的折扣券数据。订单列表模块提供商家对自身店铺订单记录的查询功能。订单售后模块允许商家处理游客的售后请求。分类列表模块支持商家对商品分类目录进行维护操作。如图3-3所示。

图3-3商家用例图

3.2.4 管理员角色功能需求

　　管理员角色是系统权限层级最高的操作主体，负责全局数据的管控与系统运营的统筹维护。权限管理模块允许管理员对各角色的功能访问范围进行配置操作。操作日志模块提供系统内所有用户操作行为的查询与审计功能。通知发布模块支持管理员向指定角色推送运营通知。公告管理模块允许管理员对全局公告的内容进行增删改维护。用户管理模块支持管理员对注册用户账号的查询、禁用与信息修正操作。如图3-4所示。

图3-4管理员用例图

第四章 系统设计

4.1 系统架构设计

　　古城景区管理系统的整体架构以B/S模式为基础，将系统划分为用户界面层、应用服务层、数据持久层三个核心层次，各层之间职责分明，通过标准HTTP协议与数据访问接口完成跨层通信。用户界面层由Vue框架构建，负责将业务数据渲染为可视化的交互页面，支持四类角色的差异化界面呈现。应用服务层以Spring Boot为运行核心，封装景区商城、订单管理、预约购票、打卡互动等业务逻辑，对外提供统一的RESTful接口规范。数据持久层以MySQL数据库作为数据存储介质，通过MyBatis-Plus框架实现业务实体与数据库表之间的映射关系，保障数据的完整性与一致性。系统支持层涵盖本地开发环境、Maven依赖管理工具，以及Spring Security负责的身份认证与权限拦截机制，为系统稳定运行提供基础保障。系统架构图如图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 数据库设计

4.4.1 概念模型设计

　　业务数据的组织方式决定着系统各功能模块能否在运行时保持逻辑一致性。古城景区管理系统涉及游客购票、商城购物、打卡签到、订单审核、优惠促销等多条业务线，每条业务线背后都存在结构化的数据实体及其相互间的依赖关系。概念模型设计的本质是将现实世界中的业务对象抽象为信息世界中可描述、可操作的实体集合，通过明确实体的属性构成与实体间的联系类型，完成从业务需求到数据结构的第一次形式化转换18。在本系统中，用户、景点、门票、订单、商品、打卡记录、优惠券等核心业务对象均被识别为独立实体，实体之间存在一对多与多对多两类主要联系形态：一个用户可生成多条订单，一条订单对应一件商品或一张门票，一个商家可发布多张优惠券。E-R图作为概念模型的标准可视化表达工具，能够将上述实体、属性及联系以图形化方式清晰呈现。基于以上分析，系统全域数据结构的概念模型以E-R图形式输出，为后续逻辑模型的表结构转换提供设计依据。全局E-R模型如图4-8所示。

图4-8全局ER图

　　根据系统分析，系统的主要实体有：用户、景点、门票订单、商品、商城订单、打卡记录、优惠券、商家、景区管理者、管理员，各个实体具体的属性如下图所示。

　　（1）用户实体主要包括用户id、用户名、密码、手机号、头像、状态、创建时间等属性。如图4-9所示。

图4-9用户实体属性图

　　（2）景点实体主要包括景点id、景点名称、景点描述、景点图片、所在位置、开放时间、门票价格、景区管理者id等属性。如图4-10所示。

图4-10景点实体属性图

　　（3）门票订单实体主要包括门票订单id、用户id、景点id、预约日期、购买数量、实付金额、订单状态、创建时间等属性。如图4-11所示。

图4-11门票订单实体属性图

　　（4）商品实体主要包括商品id、商品名称、商品描述、商品图片、商品价格、库存数量、分类id、商家id等属性。如图4-12所示。

图4-12商品实体属性图

　　（5）商城订单实体主要包括商城订单id、用户id、商品id、购买数量、实付金额、优惠券id、订单状态、创建时间等属性。如图4-13所示。

图4-13商城订单实体属性图

　　（6）打卡记录实体主要包括打卡记录id、用户id、景点id、打卡时间、打卡坐标、打卡状态、创建时间等属性。如图4-14所示。

图4-14打卡记录实体属性图

　　（7）优惠券实体主要包括优惠券id、优惠券名称、折扣面值、有效期开始时间、有效期结束时间、适用范围、商家id、创建时间等属性。如图4-15所示。

图4-15优惠券实体属性图

　　（8）商家实体主要包括商家id、商家名称、联系电话、营业执照、店铺描述、账号、密码、状态等属性。如图4-16所示。

图4-16商家实体属性图

　　（9）景区管理者实体主要包括景区管理者id、姓名、联系电话、账号、密码、所管辖景区、状态、创建时间等属性。如图4-17所示。

图4-17景区管理者实体属性图

　　（10）管理员实体主要包括管理员id、账号、密码、姓名、联系电话、权限级别、最后登录时间、状态等属性。如图4-18所示。

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

4.4.2 数据库逻辑设计

　　关系数据库的逻辑设计是在概念模型确定后，将E-R图中的实体、属性与联系转换为具体数据库表结构的过程19。每个实体对应一张独立的数据库表，实体属性对应表中的字段，实体间的一对多联系通过外键字段在从表侧加以体现，多对多联系则借助中间关联表完成分解。本系统共设计十张核心业务表，涵盖用户、景点、门票订单、商品、商城订单、打卡记录、优惠券、商家、景区管理者、管理员等业务实体。字段的数据类型依据业务语义选取，字符型信息使用varchar存储，时间类信息统一采用datetime类型，金额类数据选用decimal保障精度，状态类标识以int类型记录。各表之间通过合理的主外键关联，构成业务完整、结构清晰的关系型数据库模型，为上层业务逻辑的实现提供稳定的数据访问基础。

　　（1）用户表主要是用来存储系统注册用户的基础账号信息。主要包括用户id、用户名、密码、手机号等字段。如表4-1所示。

表4-1用户表

序号	字段名	类型	长度	备注
1	user_id	bigint	20	主键
2	username	varchar	50	用户名
3	password	varchar	100	密码
4	phone	varchar	20	手机号
5	avatar	varchar	200	头像地址
6	status	int	11	账号状态
7	create_time	datetime	-	创建时间
8	update_time	datetime	-	更新时间

　　（2）景点表主要是用来存储古城景区内各景点的基础信息数据。主要包括景点id、景点名称、所在位置、门票价格等字段。如表4-2所示。

表4-2景点表

序号	字段名	类型	长度	备注
1	spot_id	bigint	20	主键
2	spot_name	varchar	100	景点名称
3	spot_desc	varchar	500	景点描述
4	spot_image	varchar	200	景点图片
5	location	varchar	200	所在位置
6	open_time	varchar	50	开放时间
7	ticket_price	decimal	-	门票价格
8	manager_id	bigint	20	景区管理者id
9	create_time	datetime	-	创建时间

　　（3）门票订单表主要是用来记录游客预约购票的完整订单数据。主要包括门票订单id、用户id、景点id、订单状态等字段。如表4-3所示。

表4-3门票订单表

序号	字段名	类型	长度	备注
1	ticket_order_id	bigint	20	主键
2	user_id	bigint	20	用户id
3	spot_id	bigint	20	景点id
4	visit_date	date	-	预约日期
5	buy_num	int	11	购买数量
6	pay_amount	decimal	-	实付金额
7	order_status	int	11	订单状态
8	create_time	datetime	-	创建时间

　　（4）商品表主要是用来存储景区商城内上架商品的详细信息。主要包括商品id、商品名称、商品价格、商家id等字段。如表4-4所示。

表4-4商品表

序号	字段名	类型	长度	备注
1	goods_id	bigint	20	主键
2	goods_name	varchar	100	商品名称
3	goods_desc	varchar	500	商品描述
4	goods_image	varchar	200	商品图片
5	price	decimal	-	商品价格
6	stock	int	11	库存数量
7	category_id	bigint	20	分类id
8	merchant_id	bigint	20	商家id
9	create_time	datetime	-	创建时间

　　（5）商城订单表主要是用来记录游客在景区商城完成购物的订单数据。主要包括商城订单id、用户id、商品id、订单状态等字段。如表4-5所示。

表4-5商城订单表

序号	字段名	类型	长度	备注
1	mall_order_id	bigint	20	主键
2	user_id	bigint	20	用户id
3	goods_id	bigint	20	商品id
4	buy_num	int	11	购买数量
5	pay_amount	decimal	-	实付金额
6	coupon_id	bigint	20	优惠券id
7	order_status	int	11	订单状态
8	create_time	datetime	-	创建时间

　　（6）打卡记录表主要是用来存储游客在各景点完成签到的行为记录数据。主要包括打卡记录id、用户id、景点id、打卡时间等字段。如表4-6所示。

表4-6打卡记录表

序号	字段名	类型	长度	备注
1	checkin_id	bigint	20	主键
2	user_id	bigint	20	用户id
3	spot_id	bigint	20	景点id
4	checkin_time	datetime	-	打卡时间
5	checkin_location	varchar	200	打卡坐标
6	checkin_status	int	11	打卡状态
7	create_time	datetime	-	创建时间

　　（7）优惠券表主要是用来存储商家创建的各类优惠折扣券信息。主要包括优惠券id、优惠券名称、折扣面值、商家id等字段。如表4-7所示。

表4-7优惠券表

序号	字段名	类型	长度	备注
1	coupon_id	bigint	20	主键
2	coupon_name	varchar	100	优惠券名称
3	discount_value	decimal	-	折扣面值
4	start_time	datetime	-	有效期开始时间
5	end_time	datetime	-	有效期结束时间
6	apply_scope	varchar	200	适用范围
7	merchant_id	bigint	20	商家id
8	create_time	datetime	-	创建时间

　　（8）商家表主要是用来存储入驻景区商城的商家账号与店铺基础信息。主要包括商家id、商家名称、联系电话、账号等字段。如表4-8所示。

表4-8商家表

序号	字段名	类型	长度	备注
1	merchant_id	bigint	20	主键
2	merchant_name	varchar	100	商家名称
3	phone	varchar	20	联系电话
4	license	varchar	200	营业执照
5	shop_desc	varchar	500	店铺描述
6	account	varchar	50	账号
7	password	varchar	100	密码
8	status	int	11	账号状态

　　（9）景区管理者表主要是用来存储负责景区日常运营管理人员的账号与职责信息。主要包括景区管理者id、姓名、联系电话、所管辖景区等字段。如表4-9所示。

表4-9景区管理者表

序号	字段名	类型	长度	备注
1	manager_id	bigint	20	主键
2	manager_name	varchar	100	姓名
3	phone	varchar	20	联系电话
4	account	varchar	50	账号
5	password	varchar	100	密码
6	manage_area	varchar	200	所管辖景区
7	status	int	11	账号状态
8	create_time	datetime	-	创建时间

　　（10）管理员表主要是用来存储系统最高权限管理账号的身份与操作权限信息。主要包括管理员id、账号、姓名、权限级别等字段。如表4-10所示。

表4-10管理员表

序号	字段名	类型	长度	备注
1	admin_id	bigint	20	主键
2	account	varchar	50	账号
3	password	varchar	100	密码
4	admin_name	varchar	100	姓名
5	phone	varchar	20	联系电话
6	permission_level	int	11	权限级别
7	last_login_time	datetime	-	最后登录时间
8	status	int	11	账号状态

第五章 系统实现

5.1 用户角色功能实现

5.1.1 景区商城

　　景区商城模块主要是对用户在景区商城内浏览、筛选、购买商品的全流程操作进行支撑。用户进入商城页面后，系统加载商品列表并按分类展示，页面数据随用户的分类切换操作实时刷新。用户点击目标商品后，系统跳转至商品详情页，展示该商品的完整数据信息。用户在详情页选择购买数量并点击确认购买后，若账号处于已登录状态，系统自动跳转至订单确认页面；若账号未登录，系统跳转至登录页并在登录完成后自动返回原流程。用户在订单确认页选择可用优惠券并提交订单，系统完成库存校验后写入订单记录，向用户返回下单成功的页面响应。景区商城界面如图5-1所示。

图5-1景区商城界面 代码：

@RequestMapping("/get_hits_list") public Map<String, Object> getHits(HttpServletRequest request) { Map<String,String> paramMap = service.readQuery(request); if (paramMap.get("user_id")==null		paramMap.get("user_id").equals("")) { Map<String,String> configMap = service.readConfig(request); configMap.computeIfAbsent(FindConfig.PAGE, k -> String.valueOf(1)); configMap.computeIfAbsent(FindConfig.SIZE, k -> String.valueOf(1)); configMap.put(FindConfig.ORDER_BY, "goods_id asc"); List goodsList = goodsService.selectBaseList(goodsService.select(paramMap, configMap)); Map<String, Object> map = new HashMap<>(); map.put("list", goodsList); map.put("count", goodsList.size()); return success(map); } String hitsSource = buildCartWeightedSql(paramMap.get("user_id")); List<Map<String,Object>> hitsSourceList = goodsService.selectMapBaseList(hitsSource); return success(hitsSourceList); }

5.1.2 订单详情

　　订单详情模块主要是对用户在景区商城及门票预约中产生的历史订单记录进行查询与管理。用户进入订单详情页后，系统按时间倒序加载该账号名下的全部订单列表。用户点击任意订单条目后，系统展示该订单的完整状态数据，包含当前所处的业务节点信息。对于处于可申请退款状态的订单，页面同步展示退款入口，用户触发退款申请后，系统将申请数据推送至对应景区管理者或商家的审核队列，并将订单状态更新为审核中。订单详情界面如图5-2所示。

图5-2订单详情界面 代码：

@RequestMapping("/get_obj") public Map<String, Object> obj(HttpServletRequest request) { Map<String, String> config = service.readConfig(request); if (request.getParameter("like") == null		request.getParameter("like").trim().isEmpty()) { config.put("like", "0"); } List resultList = service.selectBaseList(service.select(service.readQuery(request), config)); if (resultList.size() > 0) { JSONObject jsonObject = new JSONObject(); jsonObject.put("obj", resultList.get(0)); return success(jsonObject); } else { return success(null); } }

5.1.3 导航地图

　　导航地图模块主要是对用户在古城景区内的位置定向与路线规划操作进行功能支撑。用户进入导航地图页面后，系统调用地图组件加载景区地图并标注各景点的坐标位置。用户点击目标景点标注点后，系统弹出该景点的简介卡片并提供导航按钮。用户触发导航操作后，系统获取当前设备的定位数据，在地图上绘制从当前位置至目标景点的推荐路线。地图视图支持用户通过手势操作完成缩放与平移，各景点标注随地图比例自适应展示。导航地图界面如图5-3所示。

图5-3导航地图界面 代码：

const getDrivingRoute = async (start, end, mapInstance = null) => { const AMap = await loadAMap('AMap.Driving'); return new Promise((resolve, reject) => { AMap.plugin('AMap.Driving', function(){ const driving = new AMap.Driving({ hideMarkers: true, map: mapInstance }); driving.search(new AMap.LngLat(start.lng, start.lat), new AMap.LngLat(end.lng, end.lat), (status, result) => { if (status === 'complete' && result.routes.length) { const route = result.routes0; resolve({ distance: route.distance, time: route.time, route: route }); } else { reject('驾车路线规划失败'); } }); }); }); };

5.1.4 景点信息

　　景点信息模块主要是对景区内全部景点的基础资料进行结构化展示与检索。系统以列表形式加载所有景点数据，用户可通过输入关键词触发模糊搜索，系统返回名称或描述与关键词匹配的景点结果集。用户点击景点卡片后，系统跳转至景点详情页，呈现该景点的图文信息、开放时段及门票定价数据。详情页底部提供预约购票入口，用户选择参观日期与数量后可直接进入购票流程。景点信息界面如图5-4所示。

图5-4景点信息界面 代码：

@RequestMapping("/get_hits_list") public Map<String, Object> getHits(HttpServletRequest request) { Map<String,String> paramMap = service.readQuery(request); if (paramMap.get("user_id") == null		paramMap.get("user_id").equals("")) { return this.getList(request); } String hitsSource = "SELECT COUNT(collect_id) AS hits_count, source_id " + "FROM collect WHERE source_table = 'attraction_information' " + "AND user_id = " + paramMap.get("user_id") + " GROUP BY source_id ORDER BY create_time desc"; List<Map<String,Object>> hitsSourceList = service.selectMapBaseList(hitsSource); Map<String, Object> map = new HashMap<>(); map.put("list", hitsSourceList); map.put("count", hitsSourceList.size()); return success(map); }

5.1.5 互动打卡

　　互动打卡模块主要是对用户抵达景点后的签到行为进行记录与反馈。用户进入打卡页面后，系统读取当前设备的地理位置数据，并与目标景点的预设坐标范围进行比对。定位数据落在有效范围内时，系统检测该用户当日是否已完成该景点的打卡操作，若无记录则写入新的打卡数据并向用户页面返回打卡成功的提示状态；若当日已存在打卡记录，系统返回重复打卡的提示信息并终止本次写入。用户可在个人中心查看历史打卡轨迹记录。互动打卡界面如图5-5所示。

图5-5互动打卡界面 代码：

@PostMapping("/add") @Transactional public Map<String, Object> add(HttpServletRequest request) throws IOException { Map<String,Object> paramMap = service.readBody(request.getReader()); AttractionsClockIn attractions_clock_in = new AttractionsClockIn(); attractions_clock_in.setName_of_scenic_spot(String.valueOf(paramMap.get("name_of_scenic_spot"))); attractions_clock_in.setType_of_attraction(String.valueOf(paramMap.get("type_of_attraction"))); attractions_clock_in.setAttraction_address(String.valueOf(paramMap.get("attraction_address"))); attractions_clock_in.setTourism_personnel(Integer.valueOf(String.valueOf(paramMap.get("tourism_personnel")))); attractions_clock_in.setUser_name(String.valueOf(paramMap.get("user_name"))); attractions_clock_in.setCheck_in_notes(String.valueOf(paramMap.get("check_in_notes"))); this.addEntity(attractions_clock_in); return success(1); }

5.2 景区管理者角色功能实现

5.2.1 景点信息

　　景点信息模块主要是对景区管理者负责管辖的景点基础数据进行维护管理。景区管理者进入景点信息管理页面后，系统加载其权限范围内的景点列表数据。管理者可新增景点条目，填写景点名称、位置描述、图片、开放时段、门票价格等信息后提交，系统完成数据写入并将新景点呈现至用户侧的景点列表。对于已有景点，管理者可触发编辑操作修正字段数据，修改提交后系统实时更新存储记录。景点信息界面如图5-6所示。

图5-6景点信息界面 代码：

@PostMapping("/add") @Transactional public Map<String, Object> add(HttpServletRequest request) throws IOException { Map<String,Object> paramMap = service.readBody(request.getReader()); AttractionInformation attraction_information = new AttractionInformation(); attraction_information.setName_of_scenic_spot(String.valueOf(paramMap.get("name_of_scenic_spot"))); attraction_information.setType_of_attraction(String.valueOf(paramMap.get("type_of_attraction"))); attraction_information.setAttraction_address(String.valueOf(paramMap.get("attraction_address"))); attraction_information.setTicket_unit_price(Double.valueOf(String.valueOf(paramMap.get("ticket_unit_price")))); attraction_information.setRemaining_votes(Double.valueOf(String.valueOf(paramMap.get("remaining_votes")))); attraction_information.setIntroduction_of_scenic_spots(String.valueOf(paramMap.get("introduction_of_scenic_spots"))); this.addEntity(attraction_information); return success(1); }

5.2.2 预约购票管理

　　预约购票管理模块主要是对游客在景点下产生的购票预约记录进行查询与状态管理。景区管理者进入预约管理页后，系统展示所管辖景点的全部预约订单列表，支持按日期、景点名称、订单状态进行筛选检索。管理者可查看具体订单的完整预约信息，对于异常或超期未支付的订单可手动触发状态更新操作，系统同步修改订单记录并通知对应用户。预约购票管理界面如图5-7所示。

图5-7预约购票管理界面 代码：

@PostMapping("/add") @Transactional public Map<String, Object> add(HttpServletRequest request) throws IOException { Map<String,Object> paramMap = service.readBody(request.getReader()); TicketPurchaseReservation t = new TicketPurchaseReservation(); t.setOrder_number(String.valueOf(paramMap.get("order_number"))); t.setName_of_scenic_spot(String.valueOf(paramMap.get("name_of_scenic_spot"))); t.setTicket_unit_price(Double.valueOf(String.valueOf(paramMap.get("ticket_unit_price")))); t.setTourism_personnel(Integer.valueOf(String.valueOf(paramMap.get("tourism_personnel")))); t.setNumber_of_tickets_purchased(Double.valueOf(String.valueOf(paramMap.get("number_of_tickets_purchased")))); this.addEntity(t); String sql = "UPDATE attraction_information INNER JOIN ticket_purchase_reservation " + "ON attraction_information.name_of_scenic_spot=ticket_purchase_reservation.name_of_scenic_spot " + "SET attraction_information.remaining_votes=attraction_information.remaining_votes-ticket_purchase_reservation.number_of_tickets_purchased"; service.updateBaseSql(sql); return success(1); }

5.2.3 退票申请

　　退票申请模块主要是对游客提交的门票退款申请进行审核处理。景区管理者进入退票申请管理页后，系统展示当前待审核的退票申请列表，每条申请记录显示申请用户信息、原订单数据及申请原因描述。管理者逐条对申请进行审核，点击通过时系统自动执行退款金额回退操作并将订单状态修改为已退款，点击驳回时系统提示管理者填写驳回原因后提交，平台将驳回信息推送至对应用户的通知消息中心。退票申请界面如图5-8所示。

图5-8退票申请界面 代码：

@GetMapping("/update_examine_state") @Transactional public String updateExamineState(Long id, String newState) throws IOException { if (!newState.equals("未审核") && !newState.equals("已通过") && !newState.equals("未通过")) { return "非法的审核状态"; } Map<String,String> queryMap = new HashMap<>(); queryMap.put("id", String.valueOf(id)); TicketRefundRequest ticket_refund_request = service.findOne(queryMap); if (ticket_refund_request != null) { ticket_refund_request.setExamine_state(newState); this.setEntity(queryMap, new HashMap<>(), ticket_refund_request); return "审核成功"; } return "审核失败：记录不存在"; }

5.2.4 景点打卡

　　景点打卡模块主要是对各景点下游客的签到打卡数据进行统计查看。景区管理者进入打卡管理页后，系统以景点为维度汇总展示打卡记录数据，支持按日期区间与景点名称进行条件筛选。管理者可查看特定景点在指定时段内的打卡人次趋势变化，以及单条打卡记录的用户身份与打卡时间信息，为评估景点热度与优化游客疏导方案提供数据参考。景点打卡界面如图5-9所示。

图5-9景点打卡界面 代码：

@RequestMapping("/get_list") public Map<String, Object> getList(HttpServletRequest request) { Map<String, Object> map = service.selectToPage( service.readQuery(request), service.readConfig(request) ); return success(map); }

5.3 商家角色功能实现

5.3.1 景区商城

　　景区商城模块主要是对商家在景区商城内的店铺商品进行上架与管理操作。商家进入商城管理页面后，系统展示该店铺当前已上架的全部商品列表数据。商家可新增商品，填写商品名称、描述、价格、库存数量、所属分类及商品图片后提交，系统校验通过后将商品数据写入数据库并同步至用户侧的商城展示列表。已上架商品支持商家触发编辑操作修改字段信息，亦可执行下架操作将商品从用户侧列表中隐藏。景区商城界面如图5-10所示。

图5-10景区商城界面 代码：

@PostMapping("/add") @Transactional public Map<String, Object> add(HttpServletRequest request) throws IOException { Map<String,Object> paramMap = service.readBody(request.getReader()); ScenicShoppingMall mall = new ScenicShoppingMall(); mall.setProduct_source(String.valueOf(paramMap.get("product_source"))); mall.setMerchant_user(Integer.valueOf(String.valueOf(paramMap.get("merchant_user")))); mall.setMerchant_name(String.valueOf(paramMap.get("merchant_name"))); mall.setCart_title(String.valueOf(paramMap.get("cart_title"))); mall.setCart_price(Double.valueOf(String.valueOf(paramMap.get("cart_price")))); mall.setCart_inventory(Double.valueOf(String.valueOf(paramMap.get("cart_inventory")))); mall.setCart_type(String.valueOf(paramMap.get("cart_type"))); this.addEntity(mall); return success(1); }

5.3.2 添加优惠券

　　添加优惠券模块主要是对商家创建面向用户的折扣优惠券信息进行管理。商家进入优惠券管理页后，系统展示当前已创建的优惠券列表，并提供新增入口。商家填写优惠券名称、折扣面值、适用商品范围、有效期起止时间等信息后提交，系统对数据格式进行校验，校验通过后将优惠券记录写入数据库，并在对应商品详情页自动展示优惠标识。已过期的优惠券系统自动标记为失效状态，停止在用户侧展示。添加优惠券界面如图5-11所示。

图5-11添加优惠券界面 代码：

@PostMapping("/add") @Transactional public Map<String, Object> add(HttpServletRequest request) throws IOException { Map<String, Object> addMap = service.readBody(request.getReader()); validateParameters(addMap); removeUnnecessaryFields(addMap); this.service.insert(addMap); System.out.println("优惠券新增成功"); return success(1); } private void validateParameters(Map<String, Object> addMap) { if (addMap.get("coupon_name") == null) { throw new IllegalArgumentException("优惠券名称不能为空"); } if (addMap.get("coupon_price") == null) { throw new IllegalArgumentException("优惠券价格不能为空"); } }

5.3.3 订单列表

　　订单列表模块主要是对商家店铺内产生的全部商城订单记录进行查询管理。商家进入订单列表页后，系统按时间倒序加载该店铺名下的订单数据，支持按订单状态、时间区间进行筛选操作。商家点击具体订单后，系统展示该订单的用户信息、商品明细、支付金额、当前状态等完整数据。对于处于待发货状态的订单，商家可触发发货操作并填写物流单号，系统更新订单状态并通知买家。订单列表界面如图5-12所示。

图5-12订单列表界面 代码：

@RequestMapping("/get_business_order_list") public Map<String, Object> getBusinessOrderList(HttpServletRequest request) { Map<String,String> query = service.readQuery(request); String sql = "SELECT t1.* FROM order t1 " + "LEFT JOIN goods t2 ON t1.goods_id = t2.goods_id " + "WHERE t2.user_id = " + query.get("user_id"); if (!StringUtils.isEmpty(query.get("order_number"))) { sql = sql + " and t1.order_number like '%" + query.get("order_number") + "%'"; } Map<String,Object> map = new HashMap<>(); map.put("list", service.selectBaseList(sql)); map.put("count", service.selectBaseCount(sql)); return success(map); }

5.3.4 订单售后

　　订单售后模块主要是对用户提交的商品售后申请进行处理响应。商家进入售后管理页后，系统展示当前待处理的售后申请记录，申请内容包含用户提交的问题描述与处理诉求。商家对申请进行查阅后，可选择同意退款、同意换货或驳回申请三种处理方式，填写处理说明后提交，系统根据商家选择执行对应的订单状态更新操作，并将处理结果推送至对应用户的消息通知。订单售后界面如图5-13所示。

图5-13订单售后界面 代码：

@PostMapping("/set") @Transactional public Map<String, Object> set(HttpServletRequest request) throws IOException { Map<String,Object> body = this.service.readBody(request.getReader()); OrderAfterSale order_after_sale = JSON.parseObject( JSON.toJSONString(body), OrderAfterSale.class ); this.service.updateEntity( service.readQuery(request), service.readConfig(request), order_after_sale ); return success(1); }

5.3.5 分类列表

　　分类列表模块主要是对景区商城内的商品分类目录数据进行维护管理。商家进入分类管理页后，系统展示当前已创建的分类条目列表。商家可新增分类，填写分类名称后提交，系统写入新分类记录，该分类即可在商品添加时作为归属选项使用。对于已有分类，商家可触发修改操作调整分类名称，亦可在该分类下无商品绑定的前提下执行删除操作。分类列表界面如图5-14所示。

图5-14分类列表界面 代码：

@RestController @RequestMapping("goods_type") public class GoodsTypeController extends BaseController<GoodsType, GoodsTypeService> { @Autowired public GoodsTypeController(GoodsTypeService service) { setService(service); } } @RequestMapping("/get_list") public Map<String, Object> getList(HttpServletRequest request) { Map<String, Object> map = service.selectToPage(service.readQuery(request), service.readConfig(request)); return success(map); }

5.4 管理员角色功能实现

5.4.1 权限管理

　　权限管理模块主要是对系统内各角色的功能访问权限范围进行配置管控。管理员进入权限管理页后，系统展示当前已配置的角色权限列表，涵盖用户、景区管理者、商家各角色的可访问功能集合。管理员可选择目标角色对其权限项进行调整，勾选或取消对应功能模块的访问授权后提交，系统更新权限配置记录，目标角色的账号在下次请求时自动按新配置进行鉴权拦截。权限管理界面如图5-15所示。

图5-15权限管理界面 代码：

@RestController @RequestMapping("auth") public class AuthController extends BaseController<Auth, AuthService> { @Autowired public AuthController(AuthService service) { setService(service); } } @PostMapping("/set") @Transactional public Map<String, Object> set(HttpServletRequest request) throws IOException { service.update(service.readQuery(request), service.readConfig(request), service.readBody(request.getReader())); return success(1); }

5.4.2 操作日志

　　操作日志模块主要是对系统内全部用户的操作行为记录进行查询与审计管理。管理员进入操作日志页后，系统以时间倒序加载全量日志条目，每条记录包含操作账号、操作类型、操作时间、请求来源等行为标识数据。管理员可通过账号名称、操作类型、时间区间等条件组合进行检索过滤，精准定位目标操作记录。日志数据仅支持查询，不允许进行编辑或删除操作，以保障审计数据的原始完整性。操作日志界面如图5-16所示。

图5-16操作日志界面 代码：

@RestController @RequestMapping("operation_log") public class OperationLogController extends BaseController<OperationLog, OperationLogService> { @Autowired public OperationLogController(OperationLogService service) { setService(service); } } @RequestMapping("/get_list") public Map<String, Object> getList(HttpServletRequest request) { Map<String, Object> map = service.selectToPage(service.readQuery(request), service.readConfig(request)); return success(map); }

5.4.3 通知发布

　　通知发布模块主要是对管理员向指定角色用户群推送运营通知的操作进行管理。管理员进入通知发布页后，填写通知标题、通知内容，并选择目标接收角色范围后提交发布，系统将通知数据写入消息表并在对应角色账号的消息中心展示。已发布的通知支持管理员进行撤回操作，撤回后通知从目标用户的消息列表中隐藏。管理员可查看历史已发布通知的状态记录。通知发布界面如图5-17所示。

图5-17通知发布界面 代码：

@PostMapping("/add") @Transactional public Map<String, Object> add(HttpServletRequest request) throws IOException { Map<String,Object> paramMap = service.readBody(request.getReader()); this.addMap(paramMap); return success(1); }

5.4.4 公告管理

　　公告管理模块主要是对全平台公开展示的公告内容进行增删改操作管理。管理员进入公告管理页后，系统展示当前已创建的全部公告列表及各公告的发布状态。管理员可新增公告，填写公告标题与正文内容后保存，系统将公告写入数据库并在前台公告展示区同步呈现。对于需要修改的公告，管理员可触发编辑操作更新内容字段；对于已过期或不再需要的公告，管理员可执行删除操作，删除后公告从前台列表中移除。公告管理界面如图5-18所示。

图5-18公告管理界面 代码：

@PostMapping("/add") @Transactional public Map<String, Object> add(HttpServletRequest request) throws IOException { Map<String, Object> addMap = service.readBody(request.getReader()); validateParameters(addMap); removeUnnecessaryFields(addMap); this.service.insert(addMap); System.out.println("公告新增成功"); return success(1); } private void validateParameters(Map<String, Object> addMap) { if (addMap.get("title") == null) { throw new IllegalArgumentException("标题不能为空"); } }

5.4.5 用户管理

　　用户管理模块主要是对系统内注册用户的账号信息进行全量查询与状态维护操作。管理员进入用户管理页后，系统以分页形式加载全部注册用户列表，支持通过用户名、手机号进行精准检索。管理员可针对具体用户执行账号禁用操作，被禁用账号在发起登录请求时系统返回禁止访问的响应；管理员亦可对已禁用账号执行恢复操作，账号恢复正常可用状态。用户基础信息字段支持管理员触发修正操作进行更新维护。用户管理界面如图5-19所示。

图5-19用户管理界面 代码：

@PostMapping("/add") @Transactional public Map<String, Object> add(HttpServletRequest request) throws IOException { Map<String,Object> paramMap = service.readBody(request.getReader()); User user = new User(); user.setUsername(String.valueOf(paramMap.get("username"))); user.setNickname(String.valueOf(paramMap.get("nickname"))); user.setPassword(String.valueOf(paramMap.get("password"))); user.setPhone(String.valueOf(paramMap.get("phone"))); user.setEmail(String.valueOf(paramMap.get("email"))); service.insert(user); return success(1); }

第六章 系统测试

6.1 测试目的

　　软件测试是验证系统业务逻辑与设计规格拟合度的核心手段。古城景区管理系统涉及用户、景区管理者、商家、管理员四类角色的多条业务链路，各模块之间的数据依赖关系较为复杂，任何环节的逻辑偏差都可能引发全链路数据不一致的问题。系统测试通过对功能模块的逐一验证，在系统上线前识别并消除潜在的业务规则错误与边界容错缺陷，保障系统在真实部署环境中的稳定运行状态，降低功能性问题对用户使用体验的影响20。

6.2 测试方法

　　本系统测试采用黑盒测试方法为主、白盒测试方法为辅的组合策略。黑盒测试从用户操作视角出发，针对各功能模块的输入条件与预期输出结果进行验证，重点覆盖正常操作路径、边界值输入、错误数据提交等典型场景，不关注内部代码实现逻辑。

　　白盒测试针对购票库存扣减、退票状态流转等核心业务逻辑进行代码层面的路径覆盖验证，确保分支条件的处理结果符合业务规则定义。测试过程按照功能模块边界划分测试范围，各模块独立验证后进行集成测试，确认跨模块数据流转的正确性。

6.3 测试用例

　　本节针对系统的七个核心业务模块进行功能性测试，验证各模块在正常操作路径与异常输入条件下的业务逻辑正确性。每个测试模块的用例设计围绕该模块的核心业务规则展开，重点关注数据提交校验、状态流转逻辑及系统反馈的准确性。

　　预约购票模块针对用户完成景点门票预约的完整业务流程进行验证，重点检测票量充足与余票不足两种条件下系统的状态处理逻辑，验证订单写入与库存扣减的一致性。

表6-1预约购票测试用例表

测试内容	测试步骤	预期结果	实际结果
正常预约购票	登录账号，选择景点与日期，余票充足，提交购票	生成订单，库存减少，返回购票成功提示	符合预期
余票不足时购票	选择余票为零的景点与日期，提交购票	系统返回余票不足提示，订单未生成	符合预期
未登录状态购票	未登录情况下直接触发购票操作	系统跳转至登录页	符合预期

　　退票申请模块针对游客发起退票及景区管理者审核处理的双向业务流程进行验证，重点检测审核通过与驳回两个分支的订单状态更新逻辑及消息通知的准确性。

表6-2退票申请测试用例表

测试内容	测试步骤	预期结果	实际结果
用户发起退票申请	进入有效订单详情页，触发退票申请提交	申请写入审核队列，订单状态更新为审核中	符合预期
管理者审核通过	管理者进入申请列表，点击通过并提交	订单状态变为已退款，退款金额回退	符合预期
管理者驳回申请	管理者填写驳回原因，提交驳回操作	订单状态恢复，驳回通知推送至用户	符合预期

　　互动打卡模块针对用户的景点签到业务逻辑进行验证，重点检测定位匹配成功、定位超出范围、当日重复打卡三种场景下系统的响应处理结果。

表6-3互动打卡测试用例表

测试内容	测试步骤	预期结果	实际结果
正常位置打卡	用户处于景点有效范围内，触发打卡操作	打卡记录写入，返回打卡成功提示	符合预期
超出位置范围打卡	用户位于景点坐标范围外，触发打卡操作	系统返回位置不符提示，不写入记录	符合预期
当日重复打卡	当日已打卡景点再次触发打卡操作	系统返回重复打卡提示，不重复写入	符合预期

　　添加优惠券模块针对商家创建优惠券的数据提交与校验逻辑进行验证，重点检测合法数据成功写入与非法格式数据校验拦截的处理结果。

表6-4添加优惠券测试用例表

测试内容	测试步骤	预期结果	实际结果
正常添加优惠券	填写完整优惠券信息，提交保存	优惠券记录写入，商品页展示优惠标识	符合预期
有效期格式错误	填写错误格式的有效期数据，提交	系统返回格式校验错误提示，不写入	符合预期

　　订单列表模块针对商家查询与管理店铺订单的业务逻辑进行验证，重点检测列表加载、条件筛选及发货操作的系统响应准确性。

表6-5订单列表测试用例表

测试内容	测试步骤	预期结果	实际结果
订单列表正常加载	商家进入订单列表页	系统按时间倒序加载全部订单数据	符合预期
按状态筛选订单	选择订单状态筛选条件，触发查询	系统返回与筛选条件匹配的订单列表	符合预期
执行发货操作	对待发货订单填写物流单号并提交	订单状态更新为已发货，通知买家	符合预期

　　权限管理模块针对管理员配置角色权限的操作逻辑进行验证，重点检测权限更新后目标角色的访问控制是否即时生效。

表6-6权限管理测试用例表

测试内容	测试步骤	预期结果	实际结果
调整角色权限	管理员取消某角色对特定功能的访问授权，提交	权限配置更新，目标角色账号被拦截	符合预期
恢复角色权限	管理员重新勾选对应功能访问授权，提交	权限配置恢复，目标角色可正常访问	符合预期

　　用户管理模块针对管理员对注册用户账号进行禁用、恢复与信息修正操作的业务逻辑进行验证，检测账号状态变更后系统鉴权拦截的响应准确性。

表6-7用户管理测试用例表

测试内容	测试步骤	预期结果	实际结果
禁用用户账号	管理员选择目标用户，执行禁用操作	账号状态更新为禁用，该账号登录请求被拒绝	符合预期
恢复用户账号	管理员选择已禁用账号，执行恢复操作	账号状态恢复正常，可正常登录	符合预期
修正用户信息	管理员触发编辑，修改用户基础字段并提交	字段数据更新写入，列表数据同步刷新	符合预期

测试结论

　　本轮测试覆盖古城景区管理系统的七个核心业务模块，累计执行测试用例二十余条，涵盖正常操作路径、边界输入验证、异常数据拦截三类测试场景。测试结果表明，系统各功能模块的业务逻辑与设计规格保持一致，数据写入、状态流转、权限拦截等关键操作均返回符合预期的系统响应。跨模块的数据依赖关系在集成测试阶段得到验证，预约购票与库存扣减、退票申请与订单状态联动、权限调整与鉴权拦截等业务链路均表现正常。系统在边界值输入与错误格式数据提交场景下能够正确触发校验机制，有效阻断非法数据写入。整体测试结论为系统功能实现完整、业务逻辑清晰、模块间耦合度低，具备面向古城景区实际运营环境进行部署的基本条件。

项目分享：大家可自取用于参考学习，获取方式可私信哦！