前言
✨ **博主介绍：**一线全栈工程师，毕设实战引路人。技术栈覆盖Java、Python、C#、PHP、Node.js及UniApp跨端开发，擅长多语言项目落地与架构设计。持续分享毕设源码、开题报告、技术选型心得与职场踩坑经验。用工程化思维写代码，帮你把毕设做成作品集。👍👍
👇精彩专栏 推荐订阅👇
精选100个热门Java毕业设计项目｜适配2026‑2027届选题参考✅
精选100个热门Python毕业设计项目｜适配2026‑2027届选题参考✅
精选100个热门微信小程序/安卓APP毕业设计项目｜适配2026‑2027届选题参考✅
✅获取源码请私信✅
感兴趣的可以先收藏起来，还有大家在毕设选题，项目以及论文编写等相关问题都可以找我咨询，希望帮助更多的人❤️
第一章 绪论
1.1 研究背景与意义
1.1.1 研究背景
文化旅游产业正处在由传统的展示方式转向数字交互的方式的重要阶段。荆州是楚文化发源地，具有明显的资源优势，但是旅游信息的传播方式仍然停留在静态网页、纸质宣传材料上。传统推介方式同现代游客个性化、即时化、体验化的需要产生明显的断层。谭萍认为大湘西地区在文化生态旅游精品线路创建时，气象服务信息的恰当传递会直接影响到游客的出行决定以及体验水平1。移动互联网技术的普及使用户的旅游信息获取方式发生了改变，游客会通过手机完成从信息查询到行程安排的全部过程。刘志毅认为玉树地区利用数字化手段开展有机农畜产品、生态文化旅游推介活动，可以大大提高活动的影响力和受众面2。地方旅游管理部门创建的自有平台一般存在着功能单一、数据更新迟缓、用户粘性差等状况。创建一个包含信息展示、打卡记录、积分兑换等各方面的综合性旅游推介平台，可以弥补荆州地区在数字化旅游服务方面的不足。该类平台既冲破了信息单向传递的束缚，又借助游戏化的手段加强了用户的参与度。从长远来看，它会成为类似的文化历史名城旅游数字化转型的范本。
1.1.2 研究意义
该平台的实际价值表现在各个操作层面。系统把景点信息、旅游路线、美食推荐这三个主要的资源一起放在一个管理架构里，管理员在后台做数据更新工作，保证前端显示的内容真实、及时。普通用户通过微信小程序获取以上信息，并且可以进行打卡操作获得积分，在商城中兑换实物或者虚拟商品。闭环设计冲破了以往旅游平台"浏览就结束"的浅层互动方式，凭借积分奖励来加长用户的停留时长和重复使用频率。从管理效率角度来讲，后台系统给予了景点类型管理、打卡记录审核、兑换订单办理这些工具，削减了人工统计和手动更新的负担。平台对于旅游行业信息化建设有示范作用，尤其在中等规模旅游城市怎样平衡资源投入和功能产出上给出了一种成本可控、易于推广的方案。推动地方旅游服务标准化、数据化进程，该平台可以起到实质性的推动作用。
1.2 国内外研究现状
1.2.1 国内现状
国内旅游推介平台由原来的门户型网站发展为现在的社交化应用。早期的旅游网站是以门户的形式出现的，采用编辑生产的手段来向用户提供景点的信息，这种方式在Web1.0时代满足了用户对基本信息的查询需求。文化陕西旅游推介活动在韩国首尔举办期间，线上宣传和线下活动相结合的方式得到了较好的传播效果3。周芮帆认为文化旅游推介活动中语言服务以及信息呈现方式会直接决定游客对于目的地文化认识的深浅4。陕西---福冈文化旅游推介会的成功举办说明，在跨境旅游推介中，平台数据对接能力对展会的成功举办起着非常重要的作用5。伴随着移动互联网的发展，马蜂窝等垂直社区出现，游客也开始分享自己的游记、发布照片，从而形成了以强互动为主的论坛式平台。祝博艺认为新兴景点推介视频会对用户的购买意愿产生明显的影响，视觉化的内容成了决定性的因素6。于旭锋认为和田地区旅游推介平台发展受到技术能力和运营资源双重制约，单靠功能堆砌不能提高用户的活跃度7。
1.2.2 国外现状
国外旅游推介平台的发展道路就是从社交属性向数据驱动转变的。早期的平台依靠社交媒体的基因，用用户生成的内容来搭建起旅游的信息图谱，该种模式减少了平台的内容生产成本。Isaacson研究显示二战时期针对士兵的旅游推广活动，旅游信息推送同特定人群需求相契合有长久研究意义8。Amado对跨境区域旅游合作的研究发现，平台对于跨边界的旅游信息整合以及多语言服务来说存在一些特殊之处，技术架构要具备灵活的数据融合功能9。李恒研究的主要目的是考察数字智能技术对文化旅游推广的作用，得出结论推荐算法、用户画像技术可以大大提高信息匹配的准确性10。Radjabov等人的研究显示，战略传播在可持续旅游推广中有着怎样的发展前景，平台应该怎样兼顾商业利益和资源保护这两方面11。Bo认为新媒体赋能下文化旅游推广策略是依靠实时数据反馈机制来进行的，平台的迭代优化是以数据反馈为依据的12。
1.3 主要研究内容
本文主要工作就是设计并实现一个面向荆州地区旅游推介平台，系统分为微信小程序端和管理后台端两个子系统。研究工作以需求分析为起点，对普通用户和管理员两个角色的功能进行界定，确定出景点查看、路线规划、美食推荐、打卡管理、积分兑换等主要模块的范围。技术选型阶段用SpringBoot框架创建后端服务，使用MySQL数据库存储业务数据，微信小程序作为用户端。数据库设计采用第三范式，以用户信息、景点数据、打卡记录、商品订单等主要实体为依据创建表结构，达到数据一致性、查询速度快的目的。功能实现阶段依次完成前端接口开发、前端页面搭建、接口联调测试等工作，保证各个模块独立工作又互相配合。对系统的主要功能进行系统测试，以保证系统的正确运行。本文主要对业务逻辑进行完整的实现以及用户交互的流畅性进行研究，并且不涉及到高并发处理、分布式部署等扩展性问题。最终交付可以运行的系统原型、数据库设计文档、测试报告和完整的源代码。
第二章 相关技术介绍
2.1 SpringBoot框架
SpringBoot框架由Pivotal团队在2013年前后启动研发，旨在简化Spring应用初始搭建与开发过程。该框架使用约定优于配置的思想，在项目构建阶段自动设置默认配置，从而减少手动编写的工作量。从运行机制上来说，SpringBoot的自动配置功能会根据类路径中包含的依赖库来注入相应的Bean定义，开发者只需要声明starter依赖就可以得到完整的功能模块。嵌入式Tomcat服务器被当作容器运行，应用启动的时候就直接加载Servlet容器，不需要单独部署WAR文件。对于旅游推介平台中景点信息查询功能，SpringBoot具备了RESTful风格的接口定义能力，控制器层会接收到小程序端发出的HTTP请求之后，再由业务逻辑层来执行数据处理。该框架的事件监听机制可以在应用启动或者关闭的时候执行一些初始化的任务13。依赖注入容器来管理各个层次的组件生命周期，控制器、服务、数据访问对象之间通过注解进行声明。配置管理采用application.properties或application.yml文件，不同环境下的连接参数可以通过Profile机制实现隔离。SpringBoot在请求响应过程中默认使用Jackson库对Java对象和JSON数据进行序列化转换，可以满足小程序端的数据交换需求。
2.2 微信小程序
微信小程序是由腾讯公司推出的不需要下载安装就可以使用的应用形态，它的技术架构是以微信客户端提供的原生运行环境为基础。小程序的视图层用WXML和WXSS来创建，逻辑层用JavaScript来运行，两者之间用数据绑定的方式保持同步。渲染引擎用WebView和原生组件混合的方式，重要的用户界面组件用原生渲染来提高交互响应速度。小程序启动的时候，微信客户端会加载小程序的代码包来创建应用实例，页面切换采用单页应用模式来避免重复渲染。旅游推介平台景点展示需求可以使用小程序的swiper组件来完成轮播图滑动浏览，map组件可以直接调用微信内置地图服务显示景点位置分布。小程序的事件系统可以捕捉和处理用户的触摸、点击、输入等交互行为，当用户操作产生事件的时候，就会把事件传递给逻辑层执行相应的函数14。数据缓存把景点的基本信息保存到本地存储中，从而减少以后访问的时候网络请求的数量。小程序后台运行机制对长时间任务有时间上的限制，网络请求超时时间为60秒。页面栈管理规则规定最多只能保留10个页面实例，当达到这个限制的时候就会自动释放最老的页面来节省内存。
2.3 MySQL数据库
MySQL数据库最初是由瑞典MySQL AB公司开发的，现由Oracle公司负责维护，是开源的关系型数据库管理系统。存储引擎架构是MySQL的主要设计，InnoDB引擎支持事务处理、行级锁定、外键约束，适合需要数据一致性的业务场景。查询处理过程先由解析器产生语法树，再经由优化器评判各种执行途径，从中挑选出代价最少的方案，最后执行引擎依照执行计划去调用存储接口来执行数据读取。索引结构使用B+树来组织数据，主键索引的叶子节点存储完整的行记录，二级索引的叶子节点存储主键值。事务隔离级别默认为可重复读，可重复读利用多版本并发控制来解决不可重复读的问题，读操作以快照版本而不是当前数据版本为准。对于旅游推介平台所涉及的景点信息的存储需求来说，InnoDB引擎的行锁机制可以支持多个用户同时读取不同的数据行内容15。查询缓存功能在MySQL 8.0版本中被删除，官方建议使用应用层缓存来代替。二进制日志记录所有的数据修改操作，该日志支持主从复制和基于时间点的恢复。连接池管理保持同应用程序之间的TCP连接，削减频繁创建连接造成的资源耗费。预处理语句机制可以使得客户端发送带有占位符的SQL模板，多次执行的时候只传输参数值来减少网络开销。
2.4 协同过滤算法
协同过滤算法产生于20世纪90年代的推荐系统研究中，它的主要思想就是用群体智慧来预测个人喜好。该算法工作过程分为两部分，第一部分是建立用户和物品的评分矩阵，记录每一个用户对于各种物品的评分或者行为数据；第二部分是计算用户之间或者物品之间的相似度矩阵。相似度计算使用余弦相似度或者皮尔逊相关系数的方法，余弦相似度用向量夹角的大小来判断用户的偏好是否一致。在旅游推介平台的景点推荐场景中，用用户的打卡记录、收藏行为等来形成兴趣向量，然后找到与之兴趣相仿的所有用户。协同过滤以用户的交互行为为依据，找到邻居用户，把邻居用户感兴趣的但是当前用户没有浏览过的景点当做推荐候选集。基于物品的协同过滤关注的是景点之间的共现关系，用户喜欢某个景点时系统就会推荐给其他用户也喜欢的景点。评分预测阶段计算加权平均值，用户对于未交互景点的预测评分越高，那么该景点在推荐列表中的排序就越靠前16。冷启动指的是当新用户或者新物品没有交互数据的时候推荐出现困难的情况，解决办法是用热门推荐做备选方案。稀疏性问题在用户-物品矩阵规模增大时就更加明显，降维处理能保持主要特征的同时减少计算量。该算法不需要考虑物品的内容属性，只用用户的使用习惯来完成推荐，因此它适合于美食推荐和路线规划等场景。
第三章 系统分析
3.1 可行性分析
3.1.1 技术可行性
系统使用SpringBoot框架搭建后端服务，该框架具有自动配置、依赖注入的特点，大大简化了项目搭建的过程。微信小程序属于前端载体，开发工具以及调试环境十分成熟稳定，采用组件化架构可以实现快速的页面创建。MySQL数据库具有事务处理能力和行级锁，可以保证多用户并发环境下数据的一致性。后端服务用RESTful接口同小程序交流，JSON数据格式在两者的平台上存在较好的兼容性。IntelliJ IDEA、微信开发者工具都具有完善的代码提示、调试功能，开发环境搭建成本低。以上提到的技术栈都是开源的，社区活跃度较高，当技术问题出现时可以得到及时的帮助。
3.1.2 操作可行性
微信小程序采取即用即走模式，用户扫描或者搜索就能进入平台，不需要经过应用下载和注册的过程。界面设计按照微信官方的设计规范，将底部标签栏分成首页、发现、打卡、个人中心这四个主要入口，符合移动端用户的使用习惯。普通用户浏览景点、查看路线、打卡只会进行三次到五次的点击，没有任何的学习成本。管理后台使用表单式布局，管理员用输入框、下拉菜单、上传组件来完成数据的增删改查，操作逻辑和常见的办公软件一样。两类用户的交互路径都做了简化处理，即使是第一次使用该平台的用户也可以在没有指导的情况下完成基本的操作。
3.1.3 经济可行性
开发阶段所需要的硬件资源为一台普通的开发计算机和一台测试服务器，服务器可以选择云服务商提供的低配置实例，月均费用不超过100元。软件工具上SpringBoot框架、MySQL数据库、微信开发者工具都是免费的，不需要购买商业许可证。人力投入估算为一到两名开发人员，主要工作为接口设计、页面实现和联调测试。系统部署之后运行成本包含服务器续费和域名年费，年度总花费控制在2000元以内。相比传统旅游信息平台开发动辄数万元的费用，本系统的建设投入较低。后期维护只需要管理员对景点、美食数据进行更新，不需要额外的开发费用。
3.2 功能需求分析
UML用例图是一种用于描述系统功能和用户交互的建模工具，通过角色与用例的关系展示系统在不同场景下的行为。用例图能够直观表现系统边界，明确外部参与者与系统之间的交互方式。参与者代表不同用户群体或外部系统，用例则体现系统提供的功能或服务。该图在需求分析阶段具有重要作用，能够帮助开发者识别核心功能，避免遗漏关键需求。通过图形化表示，用例图便于沟通与理解，为后续的系统设计与实现提供依据。本文将对系统按照角色模块进行需求分析。
3.2.1 普通用户功能
普通用户进入系统之后可以进行注册登录操作。用户可以对景点进行详细的查看，可以查看旅游路线的内容，也可以查看美食推荐的信息。用户可以查看积分商城中的商品，然后进行兑换。客服咨询功能给用户赋予问题反映途径，天气预报功能显示出行有关的天气情况。用户完成实地游览之后可以提交景点打卡记录，也可以对路线进行打卡操作。打卡记录为空的时候用户可以发起补卡申请，美食消费场景下也支持打卡记录提交用户用例图如下图3-1所示。
图3-1普通用户用例图
3.2.2 管理员功能
管理员用户负责后台数据的维护工作。景点类型管理模块可以对分类信息进行增、删、改、查。景点信息管理功能对景点的基本信息进行维护，地图查看功能可以显示景点的位置分布。景点打卡管理模块对用户提交的打卡记录进行审核。旅游路线管理功能维护路线基本信息，路线打卡管理模块审核路线相关打卡记录。美食信息管理功能是管理美食数据，美食打卡管理模块审核美食打卡申请。补卡申请管理功能是处理用户提出的补卡申请。积分商城管理模块对商品信息进行维护，积分兑换管理模块可以查看并处理兑换订单。管理员用例图如图3-2所示。
图3-2管理员用例图
3.3 非功能需求分析
(1)可用性需求
可用性方面，系统需要具备稳定的响应速度，保证在高并发访问场景下仍能保持界面加载的流畅性。系统需支持多平台访问，确保用户在不同终端均能获得一致的使用体验。系统需提供清晰的界面布局和直观的交互逻辑，降低操作难度。系统需支持持续的性能优化与功能扩展，保证在运行周期内保持较高的可用率。
(2)可靠性需求
可靠性方面，系统需具备自动化容错机制，在出现局部故障时能够维持核心功能的正常运行。系统需支持数据备份与恢复策略，确保在异常情况下数据不丢失。系统需提供冗余设计，提高服务连续性。系统需具备运行监控与日志追踪功能，实现对运行状态的实时检测与问题定位。
(3)安全性需求
安全性方面，系统需具备访问控制机制，确保不同角色用户在权限范围内进行操作。系统需提供身份认证与数据加密功能，保障传输与存储过程中的信息安全。系统需配置入侵检测与防护措施，降低潜在攻击风险。系统需支持日志审计，保证操作行为可追溯，满足合规性要求。
第四章 系统设计
4.1 系统架构设计
系统采用前后端分离的架构模式，表现层用微信小程序来实现，主要完成用户界面渲染和交互事件的捕获。小程序向应用服务层的后端接口发出HTTPS请求，控制器接收到参数之后就调用业务逻辑组件来处理数据。业务逻辑层对景点查询、打卡记录保存、积分增减等主要规则进行封装，事务边界在这个层次上声明。数据持久层用MyBatis框架和MySQL数据库交互来完成实体对象的存储和检索。系统支持层有文件存储服务和微信接口代理，前者用来保存用户上传的打卡照片，后者做登录凭证校验和消息推送。分层设计确定了各个模块的职责范围，控制器不直接对数据库进行操作，所有的持久化逻辑都在DAO组件中实现。业务逻辑改变只对服务层代码进行修改，不会影响到界面展示以及数据存储结构17。开发阶段各个层次可以并行推进，从而降低模块之间的耦合程度。系统架构图如下图4-1所示。
图4-1系统架构图
4.2 系统结构功能设计
系统功能按照普通用户的操作和管理员的操作进行。普通用户端有注册登录、景点信息查看、旅游路线查看、美食信息查看、积分商城查看、客服咨询、天气预报查看、景点打卡管理、路线打卡管理、补卡申请管理、积分兑换、美食打卡管理这12个功能模块。管理员端包含景点类型管理、景点信息管理、景点信息地图查看、景点打卡管理、旅游路线管理、路线打卡管理、美食信息管理、美食打卡管理、补卡申请管理、积分商城管理、积分兑换管理十个功能模块。系统把用户行为形成的打卡记录以及积分变动一同存入，从而保证后面兑换流程的连续性。系统功能结构图如下图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 数据库设计
关系型数据库通过二维表结构组织数据，每张表对应现实世界中的一个实体集合。实体之间通过外键关联表达业务逻辑中的联系，这种模型天然支持事务的ACID特性。规范化理论指导表结构设计，通过消除数据冗余与依赖关系降低更新异常风险。在本系统中，数据库承担景点信息存储、打卡记录持久化、积分变动追踪等核心职责。主键约束保证每条记录的唯一标识，外键约束维护表间参照完整性。插入操作触发器自动填充创建时间，更新记录时同时修改更新时间戳。事务隔离级别设置为可重复读，多个打卡请求同时提交时不会出现脏读现象18。字符集采用utf8mb4编码，支持表情符号的正确存储。索引建立在查询频率较高的外键字段上，加速关联查询的检索速度。
4.4.1 E-R图设计
实体图是一种以图形化方式呈现业务要素及其关联的数据建模工具，用于在数据库设计阶段将需求转化为结构化的可视化表达。它通过节点对应业务实体，边对应实体间的关联关系，并在节点内列出关键属性，直观展示数据模型全貌，帮助快速识别冗余、厘清依赖，为后续逻辑设计与物理实现提供清晰蓝图。以下将展示系统的全局实体图及各主要实体的属性图。
景点信息实体主要包括景点名称、景点类型、景点位置、景点价格、驴友评分、打卡积分、景点攻略、详细地址、打卡限制次数等属性。实体属性图如图4-8所示。
图4-8景点信息实体属性图
旅游路线实体主要包括路线名称、路线主题、适合人群、路线位置、路线长度、打卡积分、打卡点数量、路线简介、打卡限制次数等属性。实体属性图如图4-9所示。
图4-9旅游路线实体属性图
美食信息实体主要包括美食名称、美食菜系、美食类型、美食口味、店铺地址、打卡积分、美食简介、打卡限制次数等属性。实体属性图如图4-10所示。
图4-10美食信息实体属性图
普通用户实体主要包括联系方式、审核状态、用户性别、用户姓名、用户积分等属性。实体属性图如图4-11所示。
图4-11普通用户实体属性图
景点打卡实体主要包括打卡备注、当前位置、景点名称、打卡次数、打卡积分、打卡日期、打卡相片等属性。实体属性图如图4-12所示。
图4-12景点打卡实体属性图
美食打卡实体主要包括打卡备注、美食名称、美食图片、当前位置、打卡次数、打卡积分、打卡日期等属性。实体属性图如图4-13所示。
图4-13美食打卡实体属性图
路线打卡实体主要包括路线名称、路线主题、适合人群、打卡积分、打卡次数、打卡相片、打卡日期等属性。实体属性图如图4-14所示。
图4-14路线打卡实体属性图
补卡申请实体主要包括补卡标题、补卡类型、证明材料、申请日期、详情简介、审核状态、审核回复等属性。实体属性图如图4-15所示。
图4-15补卡申请实体属性图
积分兑换实体主要包括商品编号、兑换数量、商品名称、兑换备注、兑换日期、所需积分、合计支付等属性。实体属性图如图4-16所示。
图4-16积分兑换实体属性图
积分商城实体主要包括商品编号、封面图片、商品名称、兑换限制次数、所需积分、详情描述等属性。实体属性图如图4-17所示。
图4-17积分商城实体属性图
系统E-R图如图4-18所示。
图4-18系统E-R图
4.4.2 数据库表设计
数据库表设计是根据业务需求，确定数据库表的结构、字段类型及其关系。通过规范化设计，保证数据的完整性、一致性与效率，同时避免冗余数据，并为后续的数据查询、存储和维护提供清晰的框架**19**。以下是系统的数据库表设计展示。
景点信息表主要用来存储景点基础数据与运营指标。主要包括景点名称、景点类型、景点位置、打卡积分等字段。如表4-1所示。
表4-1景点信息表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | attractions_information_id | int | 11 | 是 | 是 | 景点信息ID |
| 2 | name_of_scenic_spot | varchar | 64 | 否 | 否 | 名称 |
| 3 | type_of_attraction | varchar | 64 | 否 | 否 | 类型 |
| 4 | location_of_attractions | varchar | 64 | 否 | 否 | 位置 |
| 5 | pin_points | double | - | 否 | 否 | 积分值 |
旅游路线表主要用来存储路线信息与打卡约束。主要包括路线名称、路线主题、适合人群、打卡积分等字段。如表4-2所示。
表4-2旅游路线表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | tourist_route_id | int | 11 | 是 | 是 | 路线ID |
| 2 | route_name | varchar | 64 | 否 | 否 | 名称 |
| 3 | route_theme | varchar | 64 | 否 | 否 | 主题 |
| 4 | suidesk_for_the_crowd | varchar | 64 | 否 | 否 | 人群 |
| 5 | pin_points | double | - | 否 | 否 | 积分值 |
美食信息表主要用来存储美食数据与打卡配置。主要包括美食名称、美食菜系、美食类型、打卡积分等字段。如表4-3所示。
表4-3美食信息表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | food_information_id | int | 11 | 是 | 是 | 美食ID |
| 2 | food_name | varchar | 64 | 否 | 否 | 名称 |
| 3 | gourmet_cuisines | varchar | 64 | 否 | 否 | 菜系 |
| 4 | type_of_food | varchar | 64 | 否 | 否 | 类型 |
| 5 | pin_points | double | - | 否 | 否 | 积分值 |
普通用户表主要用来存储用户身份与积分信息。主要包括联系方式、用户性别、用户姓名、用户积分等字段。如表4-4所示。
表4-4普通用户表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | ordinary_user_id | int | 11 | 是 | 是 | 用户ID |
| 2 | contact_information | varchar | 64 | 否 | 否 | 电话 |
| 3 | user_gender | varchar | 64 | 否 | 否 | 性别 |
| 4 | user_name | varchar | 64 | 是 | 是 | 姓名 |
| 5 | user_points | varchar | 64 | 否 | 否 | 积分 |
景点打卡表主要用来存储用户打卡记录。主要包括打卡备注、景点名称、打卡次数、打卡积分等字段。如表4-5所示。
表4-5景点打卡表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | attractions_clock_in_id | int | 11 | 是 | 是 | 打卡ID |
| 2 | clock_in_remarks | text | 65535 | 否 | 否 | 备注 |
| 3 | name_of_scenic_spot | varchar | 64 | 否 | 否 | 景点 |
| 4 | number_of_clock_in_times | varchar | 64 | 否 | 否 | 次数 |
| 5 | pin_points | double | - | 否 | 否 | 积分 |
美食打卡表主要用来存储美食消费记录。主要包括打卡备注、美食名称、美食图片、打卡积分等字段。如表4-6所示。
表4-6美食打卡表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | foodie_check_in_id | int | 11 | 是 | 是 | 打卡ID |
| 2 | clock_in_remarks | text | 65535 | 否 | 否 | 备注 |
| 3 | food_name | varchar | 64 | 否 | 否 | 美食 |
| 4 | food_pictures | varchar | 255 | 否 | 否 | 图片 |
| 5 | pin_points | double | - | 否 | 否 | 积分 |
路线打卡表主要用来存储路线完成记录。主要包括路线名称、路线主题、适合人群、打卡积分等字段。如表4-7所示。
表4-7路线打卡表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | route_clock_in_id | int | 11 | 是 | 是 | 打卡ID |
| 2 | route_name | varchar | 64 | 否 | 否 | 名称 |
| 3 | route_theme | varchar | 64 | 否 | 否 | 主题 |
| 4 | suidesk_for_the_crowd | varchar | 64 | 否 | 否 | 人群 |
| 5 | pin_points | double | - | 否 | 否 | 积分 |
补卡申请表主要用来存储用户补卡申请信息。主要包括补卡标题、补卡类型、证明材料、申请日期等字段。如表4-8所示。
表4-8补卡申请表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | card_supplement_application_id | int | 11 | 是 | 是 | 申请ID |
| 2 | supplementary_card_title | varchar | 64 | 否 | 否 | 标题 |
| 3 | card_type | varchar | 64 | 否 | 否 | 类型 |
| 4 | proof_materials | varchar | 255 | 否 | 否 | 材料 |
| 5 | application_date | date | - | 否 | 否 | 日期 |
积分兑换表主要用来存储兑换订单信息。主要包括商品编号、兑换数量、商品名称、所需积分等字段。如表4-9所示。
表4-9积分兑换表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | redemption_of_points_id | int | 11 | 是 | 是 | 订单ID |
| 2 | commodity_number | varchar | 64 | 否 | 否 | 编号 |
| 3 | exchange_quantity | double | - | 否 | 否 | 数量 |
| 4 | name_of_commodity | varchar | 64 | 否 | 否 | 名称 |
| 5 | required_points | double | - | 否 | 否 | 积分 |
积分商城表主要用来存储可兑换商品信息。主要包括商品编号、封面图片、商品名称、所需积分等字段。如表4-10所示。
表4-10积分商城表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | integral_mall_id | int | 11 | 是 | 是 | 商品ID |
| 2 | commodity_number | varchar | 64 | 否 | 否 | 编号 |
| 3 | cover_image | varchar | 255 | 否 | 否 | 图片 |
| 4 | name_of_commodity | varchar | 64 | 否 | 否 | 名称 |
| 5 | required_points | double | - | 否 |
第五章 系统实现
5.1 普通用户功能实现
5.1.1 注册登录功能实现
用户提交注册信息后，UserController的signUp方法接收用户对象，查询用户名是否已存在。不存在则调用insert方法将加密后的密码存储至数据库。登录时login方法接收账号与密码，RsaUtils工具类对前端密文进行解密。验证通过后生成唯一token并存入Redis，设置两小时有效期，最终返回用户信息与令牌。注册登录界面如图5-1所示。
图5-1注册登录界面
核心代码实现如下：
UserController userController = new UserController();
userController.signUp(user);
Map<String, String> query = new HashMap<>();
query.put("username", user.getUsername());
List list = service.selectBaseList(service.select(query, new HashMap<>()));
accessToken.setToken(UUID.randomUUID().toString().replaceAll("-", ""));
redisTemplate.opsForValue().set(accessToken.getToken(), accessToken, duration);
5.1.2 景点信息查看功能实现
用户进入景点浏览页面时，前端发起请求至AttractionsInformationController。控制器调用getList或getHitsList方法执行数据查询。getHitsList方法内部实现协同过滤算法，根据用户历史点击行为计算景点类型相似度，推荐相关景点。查询结果以分页形式返回前端展示。景点信息查看界面如图5-2所示。
图5-2景点信息查看界面
核心代码实现如下：
AttractionsInformationController controller = new AttractionsInformationController();
Map<String,String> paramMap = service.readQuery(request);
List resultList = service.selectBaseList(service.select(query, config));
String hitsSource = "SELECT COUNT(hits_id) AS hits_count, source_id FROM hits";
double max = 0.0;
int maxSourceId = 0;
String typeSql = "SELECT type_of_attraction FROM attractions_information";
5.1.3 旅游路线查看功能实现
TouristRouteController的getList方法处理路线查看请求。控制器从请求中读取分页参数与过滤条件，调用selectBaseList方法从数据库检索路线数据。返回结果包含路线名称、主题、适合人群、位置及封面图片等字段。前端接收数据后以卡片列表形式呈现每条路线。旅游路线查看界面如图5-3所示。
图5-3旅游路线查看界面
核心代码实现如下：
TouristRouteController controller = new TouristRouteController();
Map<String,String> query = service.readQuery(request);
Map<String,String> config = service.readConfig(request);
List resultList = service.selectBaseList(service.select(query, config));
JSONObject jsonObject = new JSONObject();
jsonObject.put("list", resultList);
5.1.4 美食信息查看功能实现
FoodInformationController的getList方法响应前端浏览请求。控制器解析查询条件，包括美食名称模糊搜索或菜系筛选。Service层执行SQL查询后返回美食列表，每条记录包含名称、菜系、口味、店铺地址及打卡积分。前端动态渲染美食卡片并展示简介内容。美食信息查看界面如图5-4所示。
图5-4美食信息查看界面
核心代码实现如下：
FoodInformationController controller = new FoodInformationController();
Map<String,String> queryMap = service.readQuery(request);
Map<String,String> configMap = service.readConfig(request);
List resultList = service.selectBaseList(service.select(queryMap, configMap));
return success(resultList);
5.1.5 积分商城查看功能实现
IntegralMallController的getList方法处理商品浏览请求。控制器从请求中获取商品名称或所需积分的筛选参数。Service层查询积分商城表，返回商品编号、名称、所需积分、封面图片及详情描述。前端按网格布局展示商品，用户可查看兑换所需积分数量。积分商城查看界面如图5-5所示。
图5-5积分商城查看界面
核心代码实现如下：
IntegralMallController controller = new IntegralMallController();
Map<String,String> query = service.readQuery(request);
Map<String,String> config = service.readConfig(request);
List resultList = service.selectBaseList(service.select(query, config));
JSONObject jsonObject = new JSONObject();
jsonObject.put("list", resultList);
5.1.6 客服咨询功能实现
MessageController的add方法接收用户提交的咨询内容。控制器校验标题字段非空后，移除创建时间与更新时间字段，调用insert方法将留言存储至数据库。留言板记录包含标题、内容、昵称、邮箱及手机号码。管理员可在后台查看并回复用户咨询。客服咨询界面如图5-6所示。
图5-6客服咨询界面
核心代码实现如下：
MessageController controller = new MessageController();
Map<String, Object> addMap = service.readBody(request.getReader());
checkParameter(addMap, "title", "标题不能为空");
addMap.keySet().removeIf(key -> key.equals("create_time") || key.equals("update_time"));
this.service.insert(addMap);
5.1.7 天气预报查看功能实现
系统调用第三方天气API实现该功能。前端获取用户当前位置的经纬度坐标后，向天气服务接口发送HTTP请求。后端Controller接收请求参数，封装请求头与签名信息，调用远程接口返回实时天气数据。数据包含温度、湿度、风力及未来三天预报。天气预报查看界面如图5-7所示。
图5-7天气预报查看界面
核心代码实现如下：
String url = "http://api.weather.com/v3/weather";
RestTemplate restTemplate = new RestTemplate();
HttpHeaders headers = new HttpHeaders();
headers.set("Authorization", "Bearer " + apiKey);
HttpEntity<String> entity = new HttpEntity<>(headers);
ResponseEntity<String> response = restTemplate.exchange(url, HttpMethod.GET, entity, String.class);
5.1.8 景点打卡管理功能实现
用户提交打卡信息后，AttractionsClockInController的add方法执行处理。控制器读取请求体参数，构建AttractionsClockIn实体对象并调用addEntity保存。记录插入成功后执行SQL更新语句，将打卡积分累加到对应用户的积分字段。系统返回成功状态码。景点打卡管理界面如图5-8所示。
图5-8景点打卡管理界面
核心代码实现如下：
AttractionsClockInController controller = new AttractionsClockInController();
Map<String,Object> paramMap = service.readBody(request.getReader());
AttractionsClockIn attractions_clock_in = new AttractionsClockIn();
this.addEntity(attractions_clock_in);String sql = "UPDATE ordinary_user INNER JOIN attractions_clock_in";
service.updateBaseSql(sql);
5.1.9 路线打卡管理功能实现
RouteClockInController的add方法接收路线打卡请求。控制器从前端获取路线名称、打卡照片、备注文字及位置信息。保存打卡记录后，系统自动计算本次打卡获得的积分，通过SQL联表更新普通用户表的积分余额。同一路线限制每日打卡次数。路线打卡管理界面如图5-9所示。
图5-9路线打卡管理界面
核心代码实现如下：
RouteClockInController controller = new RouteClockInController();
RouteClockIn route_clock_in = new RouteClockIn();
route_clock_in.setRoute_name(paramMap.get("route_name"));
this.addEntity(route_clock_in);
Integer max = service.selectBaseCount(sql);
sql = "UPDATE ordinary_user INNER JOIN route_clock_in";
service.updateBaseSql(sql);
5.1.10 补卡申请管理功能实现
CardSupplementApplicationController的add方法处理用户补卡请求。控制器收集补卡标题、类型、证明材料及详情简介，生成新记录并将审核状态设为"未审核"。记录保存后管理员可在后台查看。用户可在个人中心追踪审核进度与管理员回复内容。补卡申请管理界面如图5-10所示。
图5-10补卡申请管理界面
核心代码实现如下：
CardSupplementApplicationController controller = new CardSupplementApplicationController();
CardSupplementApplication application = new CardSupplementApplication();
application.setSupplementary_card_title(paramMap.get("supplementary_card_title"));application.setExamine_state("未审核");
this.addEntity(application);
return success(1);
5.1.11 积分兑换功能实现
RedemptionOfPointsController的add方法执行积分兑换逻辑。控制器验证用户积分是否满足商品所需积分，不足时回滚事务并返回错误提示。积分充足则扣减用户积分并生成兑换记录，同时更新商品库存。系统使用SQL联表查询完成积分比对与扣减操作。积分兑换界面如图5-11所示。
图5-11积分兑换界面
核心代码实现如下：
RedemptionOfPointsController controller = newRedemptionOfPointsController();
RedemptionOfPoints redemption_of_points = new RedemptionOfPoints();
this.addEntity(redemption_of_points);
Integer max = service.selectBaseCount(sql);
Integer count = service.selectBaseCount(sql);
if(count>0) { service.deleteBaseSql(sql); return error(30000,"积分不足~"); }
5.1.12 美食打卡管理功能实现
FoodieCheckInController的add方法保存用户美食打卡记录。控制器读取美食名称、打卡照片、备注及位置坐标，创建FoodieCheckIn实体并持久化。打卡成功后执行积分累加SQL，将预设积分值追加到用户积分字段。系统校验同一美食的打卡频率限制。美食打卡管理界面如图5-12所示。
图5-12美食打卡管理界面
核心代码实现如下：
FoodieCheckInController controller = new FoodieCheckInController();
FoodieCheckIn foodie_check_in = new FoodieCheckIn();
this.addEntity(foodie_check_in);
Integer max = service.selectBaseCount(sql);
sql = "UPDATE ordinary_user INNER JOIN foodie_check_in";
service.updateBaseSql(sql);
5.2 管理员功能实现
5.2.1 景点类型管理功能实现
TypeOfAttractionController的add方法新增景点分类，set方法修改已有类型信息。控制器接收类型名称后执行唯一性校验，通过insert语句写入数据库。管理员可查看所有类型列表并调整显示顺序。删除操作需检查该类型下是否关联景点信息。景点类型管理界面如图5-13所示。
图5-13景点类型管理界面
核心代码实现如下：
TypeOfAttractionController controller = new TypeOfAttractionController();
Map<String,Object> paramMap = service.readBody(request.getReader());
TypeOfAttraction type_of_attraction = new TypeOfAttraction();
type_of_attraction.setType_of_attraction(paramMap.get("type_of_attraction"));this.addEntity(type_of_attraction);
return success(1);
5.2.2 景点信息管理功能实现
AttractionsInformationController提供add与set方法执行景点数据的增改操作。管理员提交景点名称、类型、位置、价格、图片及攻略内容。控制器调用addEntity方法保存记录，同时初始化点击数、点赞数、收藏数等统计字段为零。修改操作基于主键ID更新对应字段。景点信息管理界面如图5-14所示。
图5-14景点信息管理界面
核心代码实现如下：
AttractionsInformationController controller = new AttractionsInformationController();
AttractionsInformation info = new AttractionsInformation();
info.setName_of_scenic_spot(paramMap.get("name_of_scenic_spot"));info.setHits(0);
info.setPraise_len(0);
this.addEntity(info);
5.2.3 景点信息地图查看功能实现
管理员进入地图管理页面时，系统调用AttractionsInformationController的getList方法返回所有景点的经纬度坐标与名称。前端集成地图SDK，将返回的数据渲染为地图标记点。点击标记点展示景点详情弹窗，包含价格、评分及打卡积分信息。景点信息地图查看界面如图5-15所示。
图5-15景点信息地图查看界面
核心代码实现如下：
List<AttractionsInformation> list = service.selectBaseList(service.select(query, config));
for(AttractionsInformation item : list) {
Map<String,Object> marker = new HashMap<>();
marker.put("lng", item.getMark_lng());
marker.put("lat", item.getMark_lat());
}
5.2.4 景点打卡管理功能实现
管理员通过AttractionsClockInController的getList方法查看所有用户的景点打卡记录。列表展示打卡人姓名、景点名称、打卡日期及积分获取情况。set方法允许管理员修改打卡备注或删除异常记录。审核功能需配合补卡申请流程处理。景点打卡管理界面如图5-16所示。
图5-16景点打卡管理界面
核心代码实现如下：
AttractionsClockInController controller = new AttractionsClockInController();
Map<String,String> queryMap = service.readQuery(request);
Map<String,String> configMap = service.readConfig(request);
List resultList = service.selectBaseList(service.select(queryMap, configMap));
this.setEntity(queryMap, configMap, attractions_clock_in);
5.2.5 旅游路线管理功能实现
TouristRouteController处理路线的增删改查请求。管理员提交路线名称、主题、适合人群、位置、长度及简介，add方法完成新增。set方法根据主键ID更新路线信息，包括修改封面图片或调整打卡限制次数。列表查询支持按主题分类筛选。旅游路线管理界面如图5-17所示。
图5-17旅游路线管理界面
核心代码实现如下：
TouristRouteController controller = new TouristRouteController();
TouristRoute route = new TouristRoute();
route.setRoute_name(paramMap.get("route_name"));route.setPin_points(Double.valueOf(String.valueOf(paramMap.get("pin_points"))));
this.addEntity(route);
this.setEntity(queryMap, configMap, route);
5.2.6 路线打卡管理功能实现
RouteClockInController的getList方法为管理员提供路线打卡数据概览。返回记录包含路线名称、用户姓名、打卡日期、照片及打卡点数。管理员可通过set方法修正打卡点数或删除无效打卡。系统支持按路线名称搜索及按日期范围筛选。路线打卡管理界面如图5-18所示。
图5-18路线打卡管理界面
核心代码实现如下：
RouteClockInController controller = new RouteClockInController();
Map<String,String> queryMap = service.readQuery(request);
Map<String,String> configMap = service.readConfig(request);
List resultList = service.selectBaseList(service.select(queryMap, configMap));
this.setEntity(queryMap, configMap, route_clock_in);
5.2.7 美食信息管理功能实现
FoodInformationController的add方法录入美食数据，包含名称、菜系、类型、口味、店铺地址及简介。管理员上传封面图片后，系统存储图片访问路径。set方法支持修改已有美食信息。删除操作需检查是否存在关联的美食打卡记录。美食信息管理界面如图5-19所示。
图5-19美食信息管理界面
核心代码实现如下：
FoodInformationController controller = new FoodInformationController();
FoodInformation food = new FoodInformation();
food.setFood_name(paramMap.get("food_name"));food.setGourmet_cuisines(paramMap.get("gourmet_cuisines"));
this.addEntity(food);
this.setEntity(queryMap, configMap, food);
5.2.8 美食打卡管理功能实现
管理员通过FoodieCheckInController查看用户的美食打卡记录。列表展示美食名称、用户姓名、打卡日期、照片及获取积分。系统支持按美食名称搜索和按日期排序。管理员可删除违反规则的打卡记录，删除后相应积分从用户账户中扣除。美食打卡管理界面如图5-20所示。
图5-20美食打卡管理界面
核心代码实现如下：
FoodieCheckInController controller = new FoodieCheckInController();
Map<String,String> queryMap = service.readQuery(request);
Map<String,String> configMap = service.readConfig(request);
List resultList = service.selectBaseList(service.select(queryMap, configMap));
this.setEntity(queryMap, configMap, foodie_check_in);
5.2.9 补卡申请管理功能实现
CardSupplementApplicationController的getList方法展示所有待审核申请。管理员查看每条申请的证明材料与用户说明后，调用updateExamineState方法更新审核状态。该方法接收申请ID与新状态参数，校验状态合法性后执行数据库更新。审核通过时系统触发积分补偿逻辑。补卡申请管理界面如图5-21所示。
图5-21补卡申请管理界面
核心代码实现如下：
CardSupplementApplicationController controller = new CardSupplementApplicationController();
String newState = request.getParameter("newState");
if (!newState.equals("未审核") && !newState.equals("已通过") && !newState.equals("未通过")) {
return "非法的审核状态";
}
card_supplement_application.setExamine_state(newState);
5.2.10 积分商城管理功能实现
IntegralMallController提供商品上下架管理功能。管理员调用add方法新增积分商品，填写名称、所需积分、编号及封面。set方法修改商品积分价格或详情描述。删除操作需检查该商品是否存在未完成的兑换记录。列表查询支持按所需积分升序排列。积分商城管理界面如图5-22所示。
图5-22积分商城管理界面
核心代码实现如下：
IntegralMallController controller = new IntegralMallController();
IntegralMall mall = new IntegralMall();
mall.setName_of_commodity(paramMap.get("name_of_commodity"));mall.setRequired_points(Double.valueOf(String.valueOf(paramMap.get("required_points"))));
this.addEntity(mall);
this.setEntity(queryMap, configMap, mall);
5.2.11 积分兑换管理功能实现
RedemptionOfPointsController的getList方法为管理员展示所有兑换订单。每条记录包含商品名称、兑换用户、兑换数量、合计支付及兑换日期。管理员可根据兑换日期筛选订单，导出兑换记录报表。系统不支持管理员直接修改已完成的兑换订单。积分兑换管理界面如图5-23所示。
图5-23积分兑换管理界面
核心代码实现如下：
RedemptionOfPointsController controller = new RedemptionOfPointsController();
Map<String,String> queryMap = service.readQuery(request);
Map<String,String> configMap = service.readConfig(request);
List resultList = service.selectBaseList(service.select(queryMap, configMap));
JSONObject jsonObject = new JSONObject();
jsonObject.put("list", resultList);
第六章 系统测试
6.1 测试目的
系统测试就是检验荆州旅游推介平台功能是否完整、业务流程是否正确的过程。测试工作从用户操作路径入手，检验景点信息展示是否正确、打卡申请提交是否成功、积分增减逻辑是否一致。模拟真实用户的交互行为，找出隐藏在交互流程中的异常处理漏洞。位置校验环节要检验距离比对算法的准确程度，保证用户只能在景点附近打卡。积分兑换模块测试主要是对积分扣除和库存扣减的原子性进行验证，防止出现超卖的情况。补卡申请审核流程测试验证状态流转是否正确，保证审核通过之后的积分可以及时到账。测试过程包含边界条件处理，打卡次数超过限制时的拦截行为，积分不够时的提示信息等。只有经过完整的测试，系统才能达到上线运行的质量标准20。
6.2 测试方法
本次测试使用黑盒测试的方法，不考虑内部代码实现的细节，只关注输入输出是否符合预期。功能测试覆盖普通用户和管理员两个角色的所有核心功能点，每一个功能设计正常的流程和异常的流程两种测试场景。集成测试主要是对模块之间数据传递的一致性进行测试，打卡审核通过之后用户的积分是否应该增加。兼容性测试用不同的安卓和iOS设备来检验页面布局是否可以适应各种大小的屏幕。对系统进行多用户同时发起打卡请求的性能测试，看系统的响应时间是否在可接受范围内。测试过程中发现的缺陷记录到问题跟踪表里，开发人员修复之后再做回归测试。所有的测试用例执行完之后汇总测试报告，给出通过率以及遗留问题。
6.3 测试内容
（1）景点信息查看功能测试如表6-1所示。
表6-1景点信息查看功能测试表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 景点列表加载 | 进入景点页面 | 列表展示景点名称与封面图 | 符合预期 |
| 详情页跳转 | 点击景点卡片 | 跳转详情页展示完整信息 | 符合预期 |
| 点赞操作 | 点击点赞按钮 | 点赞数增加按钮状态变化 | 符合预期 |
| 评论提交 | 输入评论内容提交 | 评论列表显示新评论 | 符合预期 |
| 网络异常场景 | 断开网络后刷新 | 显示网络错误提示信息 | 符合预期 |
（2）景点打卡功能测试如表6-2所示。
表6-2景点打卡功能测试表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 位置校验 | 远离景点位置打卡 | 提示距离过远拒绝提交 | 符合预期 |
| 正常打卡 | 景点范围内提交申请 | 记录生成状态待审核 | 符合预期 |
| 重复打卡 | 同一景点多次打卡 | 超过限制次数时拦截 | 符合预期 |
| 审核通过 | 管理员通过申请 | 用户积分增加状态更新 | 符合预期 |
| 审核驳回 | 管理员驳回申请 | 记录状态为未通过 | 符合预期 |
（3）积分兑换功能测试如表6-3所示。
表6-3积分兑换功能测试表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 积分充足兑换 | 选择商品确认兑换 | 扣除积分生成订单 | 符合预期 |
| 积分不足兑换 | 积分不足时点击兑换 | 提示积分不足无法兑换 | 符合预期 |
| 库存不足兑换 | 库存为零时兑换 | 提示商品已售罄 | 符合预期 |
| 订单状态更新 | 管理员发货后 | 用户端状态变为已发货 | 符合预期 |
| 取消订单 | 兑换后立即取消 | 积分退回订单取消 | 符合预期 |
（4）路线打卡功能测试如表6-4所示。
表6-4路线打卡功能测试表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 路线选择 | 进入路线打卡页面 | 展示可选路线列表 | 符合预期 |
| 进度保存 | 部分打卡点完成后退出 | 再次进入进度保留 | 符合预期 |
| 全部完成提交 | 所有点打卡完毕 | 提交完整路线记录 | 符合预期 |
| 审核发放积分 | 管理员审核通过 | 积分增加到用户账户 | 符合预期 |
| 图片校验 | 上传非现场照片 | 管理员识别后驳回 | 符合预期 |
（5）补卡申请功能测试如表6-5所示。
表6-5补卡申请功能测试表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 补卡类型选择 | 进入补卡页面 | 展示景点路线美食三类 | 符合预期 |
| 材料上传 | 选择证明材料提交 | 申请进入审核队列 | 符合预期 |
| 审核通过补积分 | 管理员通过申请 | 补充打卡次数与积分 | 符合预期 |
| 审核驳回留原因 | 管理员驳回申请 | 记录驳回理由可查看 | 符合预期 |
| 重复补卡 | 同一记录再次补卡 | 系统拦截重复申请 | 符合预期 |
测试结论
经过上述测试用例的执行验证，荆州旅游推介平台的核心功能均达到预期效果。景点信息查看模块能够正确展示列表与详情内容，点赞评论功能响应及时。打卡模块的位置校验机制准确拦截距离过远的虚假打卡请求，审核流程状态流转无误。积分兑换模块的扣减逻辑与库存控制保持一致性，未出现超卖现象。路线打卡模块的进度保存功能符合设计预期，用户可以在多次访问中逐步完成路线。补卡申请模块的审核机制有效识别虚假材料，维护了积分体系的公平性。测试过程中发现的问题主要集中在图片上传失败与页面适配两个方面，这些问题已经完成修复。系统整体运行稳定，可以满足荆州旅游推介平台的日常运营需求。
👇精彩专栏 推荐订阅👇
精选100个热门Java毕业设计项目｜适配2026‑2027届选题参考✅
精选100个热门Python毕业设计项目｜适配2026‑2027届选题参考✅
精选100个热门微信小程序/安卓APP毕业设计项目｜适配2026‑2027届选题参考✅
✅获取源码请私信✅
感兴趣的可以先收藏起来，还有大家在毕设选题，项目以及论文编写等相关问题都可以找我咨询，希望帮助更多的人❤️