前言
✨ **博主介绍：**一线全栈工程师，毕设实战引路人。技术栈覆盖Java、Python、C#、PHP、Node.js及UniApp跨端开发，擅长多语言项目落地与架构设计。持续分享毕设源码、开题报告、技术选型心得与职场踩坑经验。用工程化思维写代码，帮你把毕设做成作品集。👍👍
👇精彩专栏 推荐订阅👇
精选100个热门Java毕业设计项目｜适配2026‑2027届选题参考✅
精选100个热门Python毕业设计项目｜适配2026‑2027届选题参考✅
精选100个热门微信小程序/安卓APP毕业设计项目｜适配2026‑2027届选题参考✅
✅获取源码请私信✅
感兴趣的可以先收藏起来，还有大家在毕设选题，项目以及论文编写等相关问题都可以找我咨询，希望帮助更多的人❤️
第一章 绪论
1.1 研究背景与意义
1.1.1 研究背景
城市社区旧物资源处置问题一直存在着信息断层的困境。大量的居民手中存在着闲置物品，但是缺少了便捷的流转渠道，而回收站点的分布情况、开放时间、收购种类等重要信息也很难被居民所掌握，造成供需双方严重脱节。传统的旧物回收依靠口耳相传或者张贴纸质通告，不能覆盖所有的居民群体，也无法对回收过程中交易的数据和用户的行为主动进行记录。伴随着社区信息化建设在全国范围内不断推进，依靠互联网技术创建线上化旧物回收平台的需求也越来越迫切车辉.湖州市吴兴区智慧社区系统方案设计与应用J.广播电视信息, 2021, 28(08): 105-108.。从国内的研究来看，采用前后端分离架构的社区服务平台可以很好地控制功能的增加和系统的维护赵志文,孙云海.基于云技术的农村社区废品管理系统设计与开发J.电脑编程技巧与维护, 2022,(02): 104-106+149.。旧物回收和积分激励机制相结合，已经得到国内外多个城市社区实践的证明，对居民参与度起着积极的作用林昌蕃,黄修谱,杨才龙,等.基于BIM的绿色建筑水资源回收利用体系集成J.给水排水, 2023, 59(S1): 329-335.。在这样的背景下，开发出一套适合于社区场景的旧物回收管理系统，打通居民、回收用户和管理方之间信息的壁垒，就成为推进社区绿色循环经济落地的现实途径。
1.1.2 研究意义
该系统的落地将在多个层面产生实质性价值。就效率而言，系统把回收申请、审核、评价等环节全部搬到线上，回收站点信息的即时更新代替了人工通知，整个流程的反应速度得到明显改善。从用户体验的角度来说，居民可以在移动端随时查看站点分布、提交申请、跟踪进度，积分商城的兑换机制也进一步提高了用户持续参与的意愿。就数据价值而言，系统对各种业务数据进行结构化存储，给之后的回收量分析、资源调度优化打下了数据基础。从行业示范角度来讲，本文以Spring Boot为技术核心，采用成熟的B/S架构和前后端分离的方式，具有较好的可复制性，可以给同类社区旧物回收平台的建设提供一个范本，促进社区绿色服务信息化水平的总体提高。
1.2 国内外研究现状
1.2.1 国内现状
国内社区旧物回收信息化领域研究起步较早，早期系统主要是简单地进行信息发布、用户注册等基本操作，功能比较简单。伴随着移动互联网的普及和社区治理数字化转型的推进，有关研究开始向前后端分离架构、多角色权限管理、在线交易闭环等方向发展，系统的形态也由原来的静态展示页面发展为具有完整业务流程的综合性平台。积分激励机制同回收流程管理的融合，成了近些年来国内研究的一个重要趋向。
胡佳静等2026年就大学校园闲置物品处理问题，创建了以uni-app为基础的旧物回收微信小程序，前端采取跨平台兼容办法，后端依靠Node.js和egg.js搭建起来，把MySQL和Redis当作主要的数据库体系，创建起包含用户管理、回收交易以及积分商城这三个重要模块的系统，积分商城的设计思想给本系统的积分兑换功能的实现给予了直接的参照意义胡佳静,赵丙秀.基于uni-app的旧物回收微信小程序的设计与实现J.电脑编程技巧与维护, 2026,(02): 65-68.。包添文在2023年利用Spring Boot框架创建了社区管理系统，并且采用B/S架构加上前后端分离技术的方式，从而达到居民管理、房屋管理、车位管理、缴费、社区服务等各个功能模块的实现，其多模块协同的设计思路给本系统角色权限划分提供了一定的参考包添文.基于Spring Boot框架的社区管理系统设计与实现D.中国地质大学(北京), 2023: 64.。银莉等人的2022年基于Spring Boot和Vue的社区服务平台，包含商户管理、社区用户管理、商品管理、订单管理等功能，技术选型与本系统非常接近，商品管理、订单流程的设计思路给本系统的积分商城模块数据结构设计提供了一些参考银莉,杜啸楠.基于SpringBoot和Vue的社区服务平台设计与实现J.电子技术, 2022, 51(12): 182-183.。
1.2.2 国外现状
国外关于社区信息化服务的研究大体上表现出数据驱动化、服务精准化的特点，早期的研究主要是对社区设施的空间分析以及服务可及性的评价，近些年来开始向着居民参与机制、平台架构改善、废弃物智能分类推荐等方向发展，信息系统的设计越发重视模块解耦和用户体验的协调统一。
Sun Yuhui在2021年用Spring Cloud框架搭建了社区微服务平台，完成了平台功能需求分析、总体设计和详细设计，并且对各个功能模块做了补充完善，微服务化模块拆分的思想可以给本系统的功能边界划分提供一定的参考SunYuhui. Research on the design of community micro service platformJ. Academic Journal of Computing & Information Science, 2021, 4(4): 12-18.。MaYuanhong等在2021年使用GIS和嵌套生态模型的方法对哈尔滨市社区综合服务设施的空间分布需求进行了分析，研究结果表明步行可达性和公共服务可及性是决定社区服务覆盖率的因素，该研究的服务覆盖思想为本系统回收站点查询和排序功能的设计提供场景支持MaYuanhong, ZouGuangtian, ShinJunghye, et al. Locating Community-Based Comprehensive Service Facilities for Older Adults Using the GIS-NEMA Method in Harbin, ChinaJ. Journal of Urban Planning and Development, 2021, 147(2): 04021007.。vanCapelleveen等人在2021年就循环经济背景下的推荐系统创建问题展开研究，采用自然语言处理手段对欧洲废物目录的标签推荐展开探究，其废弃物分类及推荐逻辑同本系统回收种类管理模块的功能规划存在一些理论上的参照意义vanCapelleveenGuido, Amrit Chintan, Zijm Henk, et al. Toward building recommender systems for the circular economy: Exploring the perils of the European Waste CatalogueJ. Journal of Environmental Management, 2021, 277: 111430.。
就国外研究而言，社区服务平台的设计重视数据结构的合理、用户交互的方便，关于废弃物分类推荐和居民参与激励机制的研究已经有了一定的理论依据。在此基础上，本系统根据国内社区旧物回收业务实际情况，把回收申请、评估、评价、积分兑换等环节整合成完整的业务闭环，提高系统的实用性、可落地性。
1.3 主要研究内容
本文主要工作是利用Spring Boot框架设计并实现一个以社区旧物回收为场景的综合管理系统。研究工作按照软件工程标准开发流程进行，先对系统的应用背景和用户群体进行详细的调查，从技术可行性、经济可行性、操作可行性三个方面来论证系统建设的合理性，再整理出居民用户、回收用户、管理员三种角色的功能需求，形成完整的功能规格说明书。在架构设计阶段确定B/S架构和前后端分离的总体方案，后端用Spring Boot做核心，前端用Vue框架实现用户的交互，MySQL负责数据的持久化，各个层的职责清楚、边界分明。数据库设计环节包含概念模型的实体关系抽象以及逻辑模型的表结构转换，给后面模块的实现赋予稳固的数据支撑。功能模块实现部分围绕回收信息管理、回收申请与审核、回收评估、积分商城、留言反馈、交流论坛等主要业务分别展开，主要保证各个角色的操作流程完整、数据一致。测试阶段根据主要业务场景设计功能测试用例，检验系统正常操作以及边界情况下的响应是否准确。本文的研究重点是业务逻辑的完整实现以及各个模块的协同工作，不包括系统部署优化、高并发处理等非核心内容。最终的交付成果是稳定运行的系统原型，设计文档和测试报告一起构成研究成果的一部分。
第二章 相关技术介绍
2.1 Spring Boot框架
Spring Boot是基于Spring框架开发的一种快速开发脚手架，它的主要设计理念就是用约定优于配置的方式来降低企业级Java应用的开发门槛。传统的Spring项目要开发者手动配置大量的XML文件，繁杂的依赖管理也容易造成很多工作。Spring Boot依靠自动配置机制，在应用启动的时候，依照类路径里已有的依赖来推断并执行相应的Bean注册工作，从而让开发者可以把重点放在业务逻辑上。内嵌的Tomcat服务器又使部署过程更加简单，打包好的可执行JAR文件就可以独立运行，不需要额外的应用服务器支持黑马程序员.Spring Boot企业级开发教程M.北京:人民邮电出版社, 2024: 258.。
Spring Boot负责本系统后端服务全部的运行工作。系统请求路由、数据校验、业务逻辑处理、异常统一拦截都在Spring Boot搭建好的应用层里完成。Spring MVC模块对前端传来的HTTP请求进行路由解析，把路由解析之后的请求分发到相应的控制器方法中，控制器调用服务层来处理数据，然后通过持久层和MySQL数据库交互，最后将结果以JSON格式返回给Vue前端。Spring Boot把MyBatis持久层框架同Java实体类进行无缝整合之后，让SQL映射的设定同Java实体类间的联系变得更清晰，数据访问层的创建速度加快了闾枫.Spring Boot项目开发教程M.北京:人民邮电出版社, 2022: 264.。整个后端体系结构层次清楚，各个层的职责明确，为系统长期维护打下了良好的基础。
2.2 Vue框架
Vue是一个渐进式的JavaScript前端框架，它的核心思想就是用数据驱动视图，利用响应式数据绑定来达到界面和数据自动同步的效果。数据状态发生改变的时候，框架内部的依赖追踪系统可以精确找到受到影响的DOM节点，并且触发局部更新，从而减少全量页面刷新造成的性能损失。组件化开发模式把页面分成相互独立的功能单元，每一个组件都包含有模板、逻辑和样式这些内容，各个组件之间依靠明确规定的接口来互相交流，从而有效地削减了大项目前端开发时的维护工作量赵媛.基于Vue的Web系统前端性能优化分析J.电脑编程技巧与维护, 2024, 45(9): 44-46.。
本系统前端全部使用Vue框架构建，居民用户端、回收用户端、管理员端的各个页面都是以单文件组件形式组织起来的。回收信息查询、回收申请提交、积分商城浏览、留言反馈等交互场景利用Vue响应式绑定的能力来达到即时反馈的效果。路由管理使用Vue Router来完成不同的角色登录后页面跳转以及权限控制等全部工作都在前端路由层完成。前后端用Axios做异步HTTP请求来交换数据，Vue的数据绑定机制在接收到后端的JSON响应之后就会自动驱动页面视图的更新，整个交互链路流畅、结构清晰秦冬.浅析Vue框架在前端开发中的应用J.信息与电脑(理论版), 2024, 36(13): 61-63.。
2.3 MySQL数据库
MySQL属于当下使用最广的开源关系型数据库管理系统，以稳定、高性能、易部署而闻名。关系模型用二维表格来组织数据，表和表之间用外键建立联系，严格遵守ACID事务特性，在并发写入和数据一致性方面有成熟的技术积累。InnoDB存储引擎可以实现行级锁以及外键约束，在多用户并发访问的时候可以有效地控制数据的竞争风险郑晓霞,张艳艳,刘超. MySQL数据库原理及应用M.北京:人民邮电出版社, 2024: 302.。
本系统采用MySQL作为数据持久层的存储引擎，主要有用户账户表、居民用户表、回收用户表、回收信息表、回收申请表、回收评估表、回收评价表、积分商城表、兑换记录表等主要业务表。各业务实体间的关联关系用外键字段来维护，回收申请和回收评估之间的关联、积分商城商品和兑换记录之间的关联都依靠MySQL的关系完整性约束来保证。索引机制对于用户查询回收信息、检索申请记录等高频读操作起到了重要的作用，可以保证查询响应性能周德伟.MySQL数据库基础实例教程M.北京:人民邮电出版社, 2024: 222.。MyBatis完成SQL语句的映射执行，MySQL连接池复用数据库连接，整个数据访问层运行效率和资源利用率都在合理的范围内。
2.4 B/S架
B/S架构就是浏览器/服务器架构，是目前Web应用系统的主要部署方式。该架构模式中客户端只需要使用标准的浏览器就可以访问到系统的全部功能，业务逻辑和数据处理都在服务器端完成，客户端不需要安装任何专用软件。该模式大大减少了终端设备的配置要求，系统功能的更新和迭代只需要在服务器端完成，客户端会自动下载最新的版本，维护成本低程煌.基于B/S架构的网上招聘系统的设计与研究C.武汉:武汉市创读时代出版策划有限公司, 2020: 10-22.。
本系统全部采用B/S架构来创建，居民用户、回收用户以及管理员都可以通过浏览器去访问相应的功能界面。Vue框架产生的静态资源由服务器托管，用户第一次访问的时候加载页面资产，之后的交互是异步请求和Spring Boot后端通信，不需要整页刷新就可以完成数据的读取和写入。前后端分离的B/S实现方式使得前端界面的调整和后端业务逻辑的修改可以相互独立地进行，开发协作效率得到提高，系统的整体可扩展性也随之增强柳伟卫.Vue.js+SpringBoot全栈开发实战M.北京:人民邮电出版社, 2023: 484.。
第三章 系统分析
3.1 可行性分析
3.1.1 技术可行性
本系统使用Spring Boot、Vue和MySQL组成的标准前后端分离技术栈，各个框架都经过了大量生产环境的验证，社区文档完备、版本稳定。B/S架构下前后端职责分明，接口用RESTful规范约定，三层之间的依赖关系清楚，没有技术路线上的根本矛盾。开发所需的各种集成开发环境、数据库工具和浏览器调试工具都可以在本地环境中完全搭建起来，整个技术条件比较成熟，系统开发在现有的技术体系中具有足够的可行性。
3.1.2 操作可行性
系统前端使用Vue框架进行开发，各个功能页面具有相同的视觉风格和交互方式，表单操作、列表筛选、详情查看等常见的操作都被设计成直观的方式。居民用户不需要有专业知识背景，只需要简单熟悉就可以完成申请提交、积分兑换等主要操作。回收用户和管理员所面对的功能模块在结构上与一般的后台管理系统非常接近，学习迁移成本低，日常使用不会造成太大的认知负担。
3.1.3 经济可行性
本系统所用的所有技术组件都是开源软件，没有商业授权费用，开发阶段直接成本主要是人员投入和本地开发设备使用。系统部署在普通的服务器或者本地机上，满足运行需求，不需要购买专门的硬件。运行阶段的维护工作量小，主要是数据备份和一般的故障处理。从综合开发成本、运行成本和维护成本来分析，总体投入处于学生毕设或者小型社区应用项目合理范围之内，经济上具有可行性。
3.2 功能需求分析
3.2.1 居民用户功能需求
居民用户属于系统面向社区普通居民开放的主体角色，其功能需求以旧物回收的完整参与路径为出发点。该角色可以在回收信息模块中获得社区各个站点服务的详细信息，站点位置分布、开放时间等重要信息可以利用查询和排序的方式迅速找到。提交回收需求之后，居民用户可以随时查看申请审核的进度，在申请状态允许的情况下，对已经提交的内容进行修改或者撤回。回收完毕之后，该角色可以对本次服务过程进行评价，记载实物交付的相关状况。积分是居民用户参与回收后得到的激励凭证，积分商城模块包含商品浏览、标签筛选、兑换等操作功能，兑换产生的流水可以在兑换记录模块里随时查看核对。如图3-1所示。
图3-1居民用户用例图
3.2.2 管理员功能需求
管理员是系统内容、业务数据的统一管理者，具有最广泛的权限，可以对系统内的所有内容进行维护，也可以对用户的反馈进行处理。管理员负责站点数据的发布、更新和下架，对居民用户关于站点的评论进行审查。积分商城的商品目录由管理员统一维护，商品上架录入、信息修改、库存调整和兑换记录查询都在此模块内完成。居民用户留言意见和问题由管理员进行回复处理，无效或者违规的内容可以删除。资源模块内容发布和评论监管、社区交流论坛帖子管理及置顶操作，也是管理员的日常工作内容。如图3-2所示。
图3-2管理员用例图
3.2.3 回收用户功能需求
回收用户是承接居民回收需求、完成线下实物处理的服务执行角色，其功能需求主要集中在申请处理和服务记录维护两个方面。该角色可以自主发布、维护本站点的基本服务信息，保证居民端展示的站点信息的准确性、时效性。居民提交的回收申请流转到回收用户端之后，该角色可以逐条审核并填写处理意见，批量审核功能适用于集中处理大批量待审申请的场景。实物回收结束之后，回收的用户会在评估管理模块里输入本次回收的详细信息，提交时也同时更新了居民积分。用户在居民用户界面里可以查看具体的评价内容，并进行文字回复，达到双向沟通的目的。如图3-3所示。
图3-3回收用户用例图
第四章 系统设计
4.1 系统架构设计
本系统采用B/S架构，把整个系统结构分成用户界面层、应用服务层和数据持久层这三个纵向分层，各个层次之间使用标准接口协议进行通信，职责分明。用户界面层使用Vue框架进行页面渲染、路由跳转以及用户交互逻辑的前端处理，应用服务层用Spring Boot来实现业务逻辑运算、请求路由分发和异常统一处理，Spring MVC模块对HTTP请求的生命周期进行管理，MyBatis框架用来做数据访问对象的SQL映射及执行，数据持久层用MySQL数据库保存所有的业务数据，利用索引和事务来保证数据读写速度和一致性。Java开发运行时环境为后端服务提供底层支持，Maven构建工具进行项目依赖和打包，本地部署方案使系统可以在标准的硬件环境里稳定运行。各个技术组件都是从成熟的开源生态系统中获得的，并且已经对它们之间是如何集成过进行了广泛的测试，没有出现兼容性问题。系统架构图如图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 概念模型设计
根据需求分析阶段得到的业务规则可知，本系统所涉及的数据关系比较复杂，居民用户、回收用户、回收信息、申请、评估、评价、积分商城、兑换记录等主要业务实体之间存在着多维联系，仅仅依靠文字描述很难全面地呈现出来。概念模型设计本质就是完成现实业务世界到信息模型世界的第一次抽象，把业务中客观存在的事物映射成实体，把事物之间业务联系映射成实体间的关系，给每一个实体赋予能够刻画其核心特征的属性集合。实体间的关系依照业务规则表现成一对一、一对多、多对多等形态，一个居民用户能有多条回收申请，这就构成了一个居民用户的若干个回收申请；一条回收申请可牵涉到诸多的评价记录，评价记录同积分兑换之间存在着间接的业务关联，积分商城里的商品与兑换记录间的业务联系也是这种一对多的关系。E-R图属于概念模型的可视化展现手段，可以借助图形化的形式把上述的实体、属性以及联系关系全部表现出来，给之后逻辑模型的推导赋予明确的参照曾辉.关系数据库技术在计算机网络设计中的应用J.信息与电脑(理论版), 2023, 35(14): 206-208.。根据上述分析，绘制反映本系统全域数据结构的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、回收姓名、回收性别、回收电话、审核状态等属性。如图4-11所示。
图4-11回收用户实体属性图
（4）回收信息实体主要包括回收信息id、回收站点、站点位置、开放时间、回收介绍、封面图片、回收用户、创建用户id等属性。如图4-12所示。
图4-12回收信息实体属性图
（5）回收申请实体主要包括回收申请id、居民姓名、居民电话、回收站点、回收种类、回收数量、回收日期、审核状态、审核回复、回收用户、居民用户等属性。如图4-13所示。
图4-13回收申请实体属性图
（6）回收评估实体主要包括回收评估id、居民姓名、居民电话、回收站点、回收种类、回收数量、回收日期、评估内容、回收用户、居民用户等属性。如图4-14所示。
图4-14回收评估实体属性图
（7）回收评价实体主要包括回收评价id、居民姓名、回收站点、评价内容、评价日期、回收用户、居民用户等属性。如图4-15所示。
图4-15回收评价实体属性图
（8）积分商城实体主要包括积分商城id、物品名称、物品图片、物品标签、兑换积分、物品库存、兑换须知、兑换限制次数等属性。如图4-16所示。
图4-16积分商城实体属性图
（9）兑换记录实体主要包括兑换记录id、居民姓名、居民电话、物品名称、兑换积分、需求积分、兑换数量、兑换日期、居民用户等属性。如图4-17所示。
图4-17兑换记录实体属性图
（10）论坛实体主要包括论坛id、标题、正文、描述、标签、发帖人头像、昵称、论坛分类、是否置顶、访问数、用户id等属性。如图4-18所示。
图4-18论坛实体属性图
4.4.2 数据库表设计
数据库逻辑设计是在概念模型的基础上，将E-R图中的实体、属性及联系转换为关系数据库所支持的具体表结构的过程。每个实体对应一张独立的数据表，实体的属性映射为表中的字段，实体间的关联关系通过外键字段在相关表之间建立引用约束胡劲.数据库信息管理系统的逻辑架构与功能设计探析J.电脑知识与技术, 2023, 19(19): 96-98.。本系统共设计十张核心业务表，各表的字段类型依据业务语义合理选定，主键统一采用自增整型字段以保证记录的唯一标识性，时间类字段采用datetime或timestamp类型以满足创建与更新时间的精确记录需求。针对高频查询场景中涉及的关键字段，结合业务查询条件为相应字段添加索引，在保证数据完整性的前提下提升检索效率。各表的字段定义、数据类型、长度约束均经过统一规范处理，确保整个数据层在结构上保持一致性与可维护性。
（1）用户账户表主要是用来存储系统所有注册用户的基础账户信息。主要包括用户id、用户名、密码、昵称等字段。如表4-1所示。
表4-1用户账户表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | user_id | int | 11 | 主键 |
| 2 | username | varchar | 30 | 用户名 |
| 3 | password | varchar | 64 | 密码 |
| 4 | nickname | varchar | 50 | 昵称 |
| 5 | avatar | varchar | 255 | 头像地址 |
| 6 | varchar | 100 | 邮箱 | |
| 7 | phone | varchar | 20 | 手机号码 |
| 8 | state | smallint | 11 | 账户状态 |
| 9 | user_group | varchar | 50 | 所在用户组 |
| 10 | create_time | timestamp | - | 创建时间 |
| 11 | login_time | timestamp | - | 上次登录时间 |
（2）居民用户表主要是用来存储通过审核的居民用户详细信息与积分数据。主要包括居民用户id、用户id、居民姓名、居民电话等字段。如表4-2所示。
表4-2居民用户表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | resuser_idential_users_id | int | 11 | 主键 |
| 2 | user_id | int | 11 | 用户id |
| 3 | name_of_resuser_ident | varchar | 50 | 居民姓名 |
| 4 | telephone_of_resuser_idents | varchar | 20 | 居民电话 |
| 5 | resuser_ident_gender | varchar | 10 | 居民性别 |
| 6 | examine_state | varchar | 30 | 审核状态 |
| 7 | user_points | double | - | 用户积分 |
| 8 | create_time | datetime | - | 创建时间 |
| 9 | update_time | timestamp | - | 更新时间 |
（3）回收用户表主要是用来存储注册为回收服务方的用户身份信息与审核状态。主要包括回收用户id、用户id、回收姓名、回收电话等字段。如表4-3所示。
表4-3回收用户表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | recycle_users_id | int | 11 | 主键 |
| 2 | user_id | int | 11 | 用户id |
| 3 | recovery_name | varchar | 50 | 回收姓名 |
| 4 | recycling_the_phone | varchar | 20 | 回收电话 |
| 5 | recycling_gender | varchar | 10 | 回收性别 |
| 6 | examine_state | varchar | 30 | 审核状态 |
| 7 | create_time | datetime | - | 创建时间 |
| 8 | update_time | timestamp | - | 更新时间 |
（4）回收信息表主要是用来存储回收站点的基本信息与服务描述内容。主要包括回收信息id、回收站点、站点位置、开放时间等字段。如表4-4所示。
表4-4回收信息表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | recycling_information_id | int | 11 | 主键 |
| 2 | recycle_bin | varchar | 100 | 回收站点 |
| 3 | site_location | varchar | 150 | 站点位置 |
| 4 | opening_hours | varchar | 100 | 开放时间 |
| 5 | cover_image | varchar | 255 | 封面图片 |
| 6 | recycling_introduction | varchar | 500 | 回收介绍 |
| 7 | recycle_users | int | 11 | 回收用户 |
| 8 | create_by | int | 11 | 创建用户id |
| 9 | create_time | datetime | - | 创建时间 |
| 10 | update_time | timestamp | - | 更新时间 |
（5）回收申请表主要是用来记录居民用户提交的旧物回收申请及审核处理结果。主要包括回收申请id、居民姓名、回收站点、审核状态等字段。如表4-5所示。
表4-5回收申请表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | recycling_application_id | int | 11 | 主键 |
| 2 | name_of_resuser_ident | varchar | 50 | 居民姓名 |
| 3 | telephone_of_resuser_idents | varchar | 20 | 居民电话 |
| 4 | recycle_bin | varchar | 100 | 回收站点 |
| 5 | recycling_categories | varchar | 100 | 回收种类 |
| 6 | recycling_quantity | double | - | 回收数量 |
| 7 | recycling_date | date | - | 回收日期 |
| 8 | examine_state | varchar | 30 | 审核状态 |
| 9 | examine_reply | varchar | 255 | 审核回复 |
| 10 | recycle_users | int | 11 | 回收用户 |
| 11 | resuser_idential_users | int | 11 | 居民用户 |
| 12 | create_time | datetime | - | 创建时间 |
（6）回收评估表主要是用来记录回收用户对旧物实物的评估详情与数量确认信息。主要包括回收评估id、居民姓名、回收站点、评估内容等字段。如表4-6所示。
表4-6回收评估表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | recovery_assessment_id | int | 11 | 主键 |
| 2 | name_of_resuser_ident | varchar | 50 | 居民姓名 |
| 3 | telephone_of_resuser_idents | varchar | 20 | 居民电话 |
| 4 | recycle_bin | varchar | 100 | 回收站点 |
| 5 | recycling_categories | varchar | 100 | 回收种类 |
| 6 | recycling_quantity | double | - | 回收数量 |
| 7 | recycling_date | date | - | 回收日期 |
| 8 | assessment_content | varchar | 500 | 评估内容 |
| 9 | recycle_users | int | 11 | 回收用户 |
| 10 | resuser_idential_users | int | 11 | 居民用户 |
| 11 | create_time | datetime | - | 创建时间 |
| 12 | update_time | timestamp | - | 更新时间 |
（7）回收评价表主要是用来存储居民用户对回收服务过程的满意度评价信息。主要包括回收评价id、居民姓名、回收站点、评价内容等字段。如表4-7所示。
表4-7回收评价表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | recovery_evaluation_id | int | 11 | 主键 |
| 2 | name_of_resuser_ident | varchar | 50 | 居民姓名 |
| 3 | recycle_bin | varchar | 100 | 回收站点 |
| 4 | resight_content | varchar | 500 | 评价内容 |
| 5 | resight_date | date | - | 评价日期 |
| 6 | recycle_users | int | 11 | 回收用户 |
| 7 | resuser_idential_users | int | 11 | 居民用户 |
| 8 | create_by | int | 11 | 创建用户id |
| 9 | create_time | datetime | - | 创建时间 |
| 10 | update_time | timestamp | - | 更新时间 |
（8）积分商城表主要是用来存储可供居民积分兑换的商品信息与库存状态。主要包括积分商城id、物品名称、兑换积分、物品库存等字段。如表4-8所示。
表4-8积分商城表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | points_mall_id | int | 11 | 主键 |
| 2 | item_name | varchar | 100 | 物品名称 |
| 3 | item_picture | varchar | 255 | 物品图片 |
| 4 | item_label | varchar | 100 | 物品标签 |
| 5 | redeem_points | double | - | 兑换积分 |
| 6 | item_inventory | double | - | 物品库存 |
| 7 | exchange_instructions | varchar | 500 | 兑换须知 |
| 8 | redemption_history_limit_times | int | 11 | 兑换限制次数 |
| 9 | create_by | int | 11 | 创建用户id |
| 10 | create_time | datetime | - | 创建时间 |
| 11 | update_time | timestamp | - | 更新时间 |
（9）兑换记录表主要是用来记录居民用户每次积分兑换商品的详细流水信息。主要包括兑换记录id、物品名称、兑换积分、兑换数量等字段。如表4-9所示。
表4-9兑换记录表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | redemption_history_id | int | 11 | 主键 |
| 2 | name_of_resuser_ident | varchar | 50 | 居民姓名 |
| 3 | telephone_of_resuser_idents | varchar | 20 | 居民电话 |
| 4 | item_name | varchar | 100 | 物品名称 |
| 5 | redeem_points | double | - | 兑换积分 |
| 6 | demand_points | double | - | 需求积分 |
| 7 | redemption_quantity | double | - | 兑换数量 |
| 8 | redemption_date | date | - | 兑换日期 |
| 9 | resuser_idential_users | int | 11 | 居民用户 |
| 10 | create_time | datetime | - | 创建时间 |
| 11 | update_time | timestamp | - | 更新时间 |
（10）论坛表主要是用来存储社区居民发布的交流帖子与互动内容信息。主要包括论坛id、标题、正文、论坛分类、是否置顶等字段。如表4-10所示。
表4-10论坛表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | forum_id | int | 11 | 主键 |
| 2 | title | varchar | 150 | 标题 |
| 3 | content | varchar | 500 | 正文 |
| 4 | description | varchar | 200 | 描述 |
| 5 | tag | varchar | 100 | 标签 |
| 6 | type | varchar | 100 | 论坛分类 |
| 7 | istop | int | 11 | 是否置顶 |
| 8 | hits | int | 11 | 访问数 |
| 9 | nickname | varchar | 50 | 昵称 |
| 10 | user_id | int | 11 | 用户id |
| 11 | create_time | timestamp | - | 创建时间 |
| 12 | update_time | timestamp | - | 更新时间 |
第五章 系统实现
5.1 居民用户角色功能实现
5.1.1 回收信息
回收信息功能模块主要是对社区内各回收站点的基本信息进行展示与检索。居民用户进入该模块后，系统从数据库加载全部回收站点记录并以列表形式呈现，用户可通过排序操作调整列表展示顺序，按距离、评分等维度重新排列结果。对感兴趣的站点，用户点击进入详情页面，系统加载该站点的完整信息，包括位置描述、开放时段、回收服务介绍等内容，详情页同时展示其他用户对该站点的评论信息供参考。回收信息界面如图5-1所示。
图5-1回收信息界面
核心代码如下：
| @RequestMapping("/get_list") public Map<String, Object> getList(HttpServletRequest request) { Map<String, String> query = service.readQuery(request); Map<String, String> config = service.readConfig(request); List list = this.service.selectBaseList(this.service.select(query, config)); map.put("list", list); return success(map); } |
|---|
5.1.2 积分商城
积分商城功能模块主要是对可供居民积分兑换的商品进行浏览与兑换操作。用户进入商城页面后可在搜索框输入关键词检索目标商品，也可通过标签筛选功能按商品分类缩小展示范围，排序功能支持按兑换积分高低重新排列商品列表。用户进入商品详情页后系统展示完整的商品信息及兑换须知，确认兑换操作时系统读取当前积分余额并与所需积分比对，通过后完成扣减与记录写入，向用户返回兑换结果。积分商城界面如图5-2所示。
图5-2积分商城界面
核心代码如下：
| RedemptionHistory redemption_history = new RedemptionHistory(); redemption_history.setItem_name(paramMap.get("item_name").toString()); redemption_history.setDemand_points(Double.valueOf(paramMap.get("demand_points").toString())); this.addEntity(redemption_history); Integer count = service.selectBaseCount(sql); if(count>0){ return error(30000,"库存不足!"); } |
|---|
5.1.3 回收申请
回收申请功能模块主要是对居民用户主动发起的旧物回收需求进行提交与管理。用户新增申请时填写回收相关信息，提交后系统完成数据写入并进入待审核状态。在申请列表页面，用户可通过查询条件筛选历史申请记录，重置按钮可清除当前筛选条件恢复默认视图。用户选择具体申请后可查看完整的申请详情，对于处于待审核状态的申请，用户还可发起修改操作更新申请内容，或通过取消操作撤回该申请。回收申请界面如图5-3所示。
图5-3回收申请界面
核心代码如下：
| RecyclingApplication recycling_application = new RecyclingApplication(); recycling_application.setRecycling_categories(paramMap.get("recycling_categories").toString()); recycling_application.setRecycling_quantity(Double.valueOf(paramMap.get("recycling_quantity").toString())); recycling_application.setExamine_state("未审核"); this.addEntity(recycling_application); |
|---|
5.1.4 回收评估
回收评估功能模块主要是对回收服务完成后的实物评估记录进行提交与查询。用户完成一次回收交付后可在该模块新增评估记录，填写评估相关内容并提交，系统将记录与对应的申请关联存储。在评估列表页面，用户可按条件查询历史评估记录，选择具体记录后进入详情页查看该次评估的全部字段信息。回收评估界面如图5-4所示。
图5-4回收评估界面
核心代码如下：
| RecoveryAssessment recovery_assessment = new RecoveryAssessment(); recovery_assessment.setRecycling_categories(paramMap.get("recycling_categories").toString()); recovery_assessment.setAssessment_content(paramMap.get("assessment_content").toString()); recovery_assessment.setSource_id(Integer.valueOf(paramMap.get("source_id").toString())); this.addEntity(recovery_assessment); |
|---|
5.1.5 兑换记录
兑换记录功能模块主要是对居民用户历次积分兑换操作的流水信息进行查询与核对。用户进入该模块后，系统加载当前账户下的全部兑换历史并以时间倒序排列展示，用户可按日期范围或商品名称等条件筛选目标记录。选定具体记录后，系统加载该笔兑换的完整详情，包括兑换日期、商品名称、消耗积分、兑换数量等核心字段，供用户核对兑换情况。兑换记录界面如图5-5所示。
图5-5兑换记录界面
核心代码如下：
| redemption_history.setRedemption_quantity(Double.valueOf(paramMap.get("redemption_quantity").toString())); this.addEntity(redemption_history); String sql = "UPDATE points_mall SET item_inventory = item_inventory - " + redemption_history.getRedemption_quantity(); service.updateBaseSql(sql); sql = "UPDATE resuser_idential_users SET user_points = user_points - " + redemption_history.getDemand_points(); |
|---|
5.2 管理员角色功能实现
5.2.1 回收信息管理
回收信息管理功能模块主要是对系统内全部回收站点信息进行维护与内容审核。管理员进入该模块后可查看所有回收站点的汇总列表，通过关键词查询快速定位目标记录。新增操作将打开信息填写表单，提交后记录入库；选定已有记录后可执行编辑操作更新站点信息，或通过删除操作将不再使用的记录移除。详情查看功能展示该站点的完整数据，评论查看功能加载居民用户对该站点发表的全部评论内容供管理员审查。回收信息管理界面如图5-6所示。
图5-6回收信息管理界面
核心代码如下：
| RecyclingInformation recycling_information = new RecyclingInformation(); recycling_information.setSite_location(paramMap.get("site_location").toString()); recycling_information.setOpening_hours(paramMap.get("opening_hours").toString()); this.addEntity(recycling_information); this.setEntity(queryMap, configMap, recycling_information); this.service.delete(query, config); |
|---|
5.2.2 积分商城管理
积分商城管理功能模块主要是对积分商城内商品信息与兑换数据进行统一管控。管理员可通过新增操作录入新商品信息，编辑操作修改已有商品的属性字段，删除操作下架不再供应的商品。商品列表支持多条件查询，管理员可快速定位目标商品并查看其完整详情。针对每件商品，管理员还可单独查看该商品的全部兑换记录，掌握各商品的消耗流水与库存消耗情况。积分商城管理界面如图5-7所示。
图5-7积分商城管理界面
核心代码如下：
| PointsMall points_mall = new PointsMall(); points_mall.setItem_name(paramMap.get("item_name").toString()); points_mall.setRedeem_points(Double.valueOf(paramMap.get("redeem_points").toString())); points_mall.setItem_inventory(Double.valueOf(paramMap.get("item_inventory").toString())); this.addEntity(points_mall); |
|---|
5.2.3 留言反馈管理
留言反馈管理功能模块主要是对居民用户提交的留言信息进行处理与回应。管理员进入该模块后可按时间、关键词等条件查询全部留言记录，筛选出需要处理的条目。对于内容违规或无效的留言，管理员可执行删除操作将其移除。对于需要正式回应的留言，管理员在留言详情页填写回复内容后提交，系统更新留言记录的回复状态，居民用户在前端界面即可看到管理员的反馈。留言反馈管理界面如图5-8所示。
图5-8留言反馈管理界面
核心代码如下：
| @RequestMapping("/get_list") public Map<String, Object> getList(HttpServletRequest request) { Map<String, String> query = service.readQuery(request); List list = this.service.selectBaseList(this.service.select(query, new HashMap<>())); map.put("list", list); return success(map); } |
|---|
5.2.4 资源管理
资源管理功能模块主要是对系统内的资源内容进行发布、维护与评论监管。管理员可通过新增操作发布新的资源内容，编辑操作修改已发布资源的信息字段，删除操作移除失效资源。资源列表支持多条件检索，管理员选定记录后可进入详情页查看完整内容。评论查看功能加载该资源下居民用户发表的所有评论，供管理员掌握用户反馈情况并进行必要的内容管理。资源管理界面如图5-9所示。
图5-9资源管理界面
核心代码如下：
| Article article = new Article(); article.setTitle(paramMap.get("title").toString()); article.setType(paramMap.get("type").toString()); article.setContent(paramMap.get("content").toString()); this.service.insert(article); this.service.delete(query, config); |
|---|
5.2.5 交流管理
交流管理功能模块主要是对社区交流论坛内的帖子内容进行发布与秩序管理。管理员可新增帖子向居民发布社区动态，编辑操作修改已有帖子的内容，删除操作移除违规或过时帖子。帖子列表支持关键词查询，管理员可对重要帖子执行置顶操作使其在列表中优先展示。针对每条帖子，管理员可查看居民用户的评论内容，对评论进行必要的审查与处理。交流管理界面如图5-10所示。
图5-10交流管理界面
核心代码如下：
| Forum forum = new Forum(); forum.setTitle(paramMap.get("title").toString()); forum.setContent(paramMap.get("content").toString()); this.service.insert(forum); forum.setTop(1); this.service.updateEntity(query, config, forum); |
|---|
5.3 回收用户角色功能实现
5.3.1 回收信息管理
回收信息管理功能模块主要是对回收用户所负责站点的服务信息进行自主维护。回收用户可通过新增操作录入自身负责站点的基本信息，包括站点名称、位置、开放时段、服务介绍等内容，提交后记录关联至该回收用户账户。编辑操作允许回收用户修改已有站点信息以保持内容的时效性，删除操作可移除无效记录。列表查询功能支持按关键词过滤展示结果，详情查看功能提供该站点的完整信息展示。回收信息管理界面如图5-11所示。
图5-11回收信息管理界面
核心代码如下：
| RecyclingInformation info = new RecyclingInformation(); info.setRecycle_bin(paramMap.get("recycle_bin").toString()); info.setRecycle_users(Integer.valueOf(paramMap.get("recycle_users").toString())); info.setSite_location(paramMap.get("site_location").toString()); this.addEntity(info); this.setEntity(queryMap, configMap, info); |
|---|
5.3.2 回收申请管理
回收申请管理功能模块主要是对居民用户提交至本回收用户名下的申请记录进行审核处理。回收用户进入申请列表后可按状态、日期等条件查询待处理申请，选定记录后进入详情页查看申请的完整信息。单条审核操作允许回收用户填写审核意见后选择通过或驳回，系统更新申请记录的审核状态字段。批量审核功能支持对多条申请同时执行通过操作，提升日常处理效率，操作完成后系统批量更新对应记录状态。回收申请管理界面如图5-12所示。
图5-12回收申请管理界面
核心代码如下：
| @GetMapping("/update_examine_state") public String updateExamineState(Long id, String newState) { RecyclingApplication app = service.findOne(queryMap); app.setExamine_state(newState); this.setEntity(queryMap, new HashMap<>(), app); return "审核成功"; } |
|---|
5.3.3 回收评估管理
回收评估管理功能模块主要是对已完成实物交付后的旧物评估记录进行录入与维护。回收用户完成实物核查后新增评估记录，填写回收数量、种类、评估内容等核心字段，提交后系统将评估记录与对应申请关联存储，并触发居民积分的同步更新。编辑操作允许回收用户对已录入的评估记录进行修正，删除操作移除错误记录。列表查询支持多条件过滤，详情查看展示该评估的全部字段信息。回收评估管理界面如图5-13所示。
图5-13回收评估管理界面
核心代码如下：
| RecoveryAssessment assessment = new RecoveryAssessment(); assessment.setRecycling_quantity(Double.valueOf(paramMap.get("recycling_quantity").toString())); assessment.setAssessment_content(paramMap.get("assessment_content").toString()); this.addEntity(assessment); this.setEntity(queryMap, configMap, assessment); |
|---|
5.3.4 回收评价管理
回收评价管理功能模块主要是对居民用户提交的服务评价进行查看与回应处理。回收用户进入评价列表后可按日期或站点名称查询历史评价记录，选定记录后系统展示该评价的完整内容，包括评价时间、评分情况、文字描述等信息。针对需要回应的评价，回收用户填写回复内容后提交，系统将回复内容写入评价记录，居民用户在前端查询时可看到对应的服务方回复。回收评价管理界面如图5-14所示。
图5-14回收评价管理界面
核心代码如下：
| RecoveryEvaluation evaluation = new RecoveryEvaluation(); evaluation.setResight_content(paramMap.get("resight_content").toString()); evaluation.setResight_date(parseToTimestamp(paramMap.get("resight_date").toString())); this.addEntity(evaluation); evaluation.setReply(paramMap.get("reply").toString()); this.setEntity(queryMap, configMap, evaluation); |
|---|
第六章 系统测试
6.1 测试目的
系统测试的目的就是对各个功能模块在实际运行环境中业务逻辑是否符合设计规格进行验证，并且检验系统在边界条件以及异常输入下是否具备容错能力。本系统包含居民用户、回收用户、管理员三个角色的多条业务链路，任何一个环节的数据处理出现偏差都会造成积分计算错误或者申请状态失真，测试工作要覆盖全链路的数据一致性验证代晓倩,丁翠玲,高赛军.基于需求和源代码分析的软件回归测试技术J.工业控制计算机, 2026, 39(1): 45-46.。对回收申请状态流转、积分兑换余额扣减、评估记录与申请记录关联写入等关键节点进行重点校验，保证操作前后数据库状态变化符合业务规则，在系统正式使用之前发现并消除功能缺陷。
6.2 测试方法
本系统主要使用黑盒测试法进行测试，测试过程不依赖于代码内部结构的了解，完全根据功能规格说明书中对系统输入输出行为的描述来进行验证。测试人员使用模拟用户的身份，按照预定的业务场景顺序进行功能用例的测试，查看系统响应是否符合预期的结果。
等价类划分法用来设计测试数据，把输入域分成有效等价类和无效等价类，针对正常数据、边界数据、非法数据这三种情况来创建测试输入，在有限的用例数目之下达成对功能覆盖的最大化。对申请审核、积分兑换等需要进行状态流转的主要流程增加场景测试用例，检验多步操作序列最终数据状态是否符合预期。
6.3 测试用例
本节根据系统七个主要业务模块来设计功能测试用例，检验各个模块在标准的操作路径以及异常的输入条件下是否可以得到正确的响应。
回收信息模块测试站点列表加载是否完整，排序结果是否正确，详情页数据和数据库记录是否一致。表6-1为数据结果。
表6-1回收信息测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 查询回收站点列表 | 进入回收信息页面，加载默认列表 | 站点列表正常展示，数据完整 | 符合预期 |
| 站点排序功能 | 选择排序条件，触发排序操作 | 列表按所选条件重新排列 | 符合预期 |
| 查看站点详情 | 点击任意站点，进入详情页 | 详情页完整展示站点信息 | 符合预期 |
积分商城模块的测试验证商品搜索的准确性、标签筛选的过滤逻辑，以及积分余额不足时兑换操作的拦截机制。如表6-2所示。
表6-2积分商城测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 商品搜索功能 | 输入关键词，提交搜索 | 返回包含关键词的商品列表 | 符合预期 |
| 积分不足拦截 | 选择兑换积分超出余额的商品 | 系统提示积分不足，终止兑换 | 符合预期 |
| 兑换成功记录写入 | 积分充足时确认兑换操作 | 积分扣减，兑换记录生成 | 符合预期 |
回收申请模块的测试关注申请提交的数据完整性校验、申请状态变更的正确性，以及取消操作的有效性。如表6-3所示。
表6-3回收申请测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 新增申请提交 | 填写申请信息并提交 | 申请记录入库，状态为待审核 | 符合预期 |
| 必填项为空校验 | 不填写必填字段直接提交 | 系统提示字段不可为空 | 符合预期 |
| 取消申请操作 | 选择待审核申请，执行取消 | 申请状态更新为已取消 | 符合预期 |
审核申请模块的测试验证单条审核与批量审核的状态更新准确性，以及审核意见的正确写入。如表6-4所示。
表6-4审核申请测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 单条审核通过 | 选择申请，填写意见，选择通过 | 申请状态更新为已通过 | 符合预期 |
| 单条审核驳回 | 选择申请，填写意见，选择驳回 | 申请状态更新为已驳回 | 符合预期 |
| 批量审核操作 | 勾选多条申请，执行批量审核 | 所选申请状态批量更新 | 符合预期 |
回收评估模块的测试关注评估记录的正确关联写入，以及重复评估的拦截逻辑与积分同步更新的准确性。如表6-5所示。
表6-5回收评估测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 新增评估提交 | 填写评估内容并提交 | 评估记录入库，居民积分同步更新 | 符合预期 |
| 重复评估拦截 | 对已有评估的申请再次提交评估 | 系统提示不可重复评估 | 符合预期 |
| 查看评估详情 | 选择评估记录，进入详情页 | 详情页正确展示评估数据 | 符合预期 |
留言反馈管理模块的测试验证留言查询过滤的准确性、回复内容的写入正确性，以及删除操作的有效性。如表6-6所示。
表6-6留言反馈管理测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 留言列表查询 | 输入查询条件，提交筛选 | 返回符合条件的留言列表 | 符合预期 |
| 回复留言操作 | 填写回复内容并提交 | 回复写入留言记录，状态更新 | 符合预期 |
| 删除留言操作 | 选择留言，执行删除 | 留言记录从列表中移除 | 符合预期 |
兑换记录模块的测试关注历史记录列表加载的完整性、条件筛选的过滤逻辑，以及详情页数据与数据库记录的一致性。如表6-7所示。
表6-7兑换记录测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 兑换记录列表加载 | 进入兑换记录页面 | 当前账户兑换历史完整展示 | 符合预期 |
| 条件筛选功能 | 输入日期范围或商品名称筛选 | 返回符合条件的记录 | 符合预期 |
| 查看记录详情 | 选择任意兑换记录 | 详情页正确展示兑换数据 | 符合预期 |
测试结论
经过对系统七个核心业务模块功能测试后发现所有的测试用例的预期结果和实际结果完全一致，系统功能实现满足设计要求。回收信息模块站点列表加载、排序和详情查看都正常，积分商城模块商品搜索、积分不足拦截、兑换记录写入都验证通过，回收申请模块新增提交、必填项校验、取消操作都正确执行，审核申请模块单条审核通过、单条审核驳回、批量审核操作都准确更新申请状态，回收评估模块新增评估、重复评估拦截、详情查看都达到预期，留言反馈管理模块留言列表查询、回复留言、删除留言都功能完整，兑换记录模块历史记录加载、条件筛选、详情查看都表现一致。全部测试用例通过，系统主要业务流程正常。
👇精彩专栏 推荐订阅👇
精选100个热门Java毕业设计项目｜适配2026‑2027届选题参考✅
精选100个热门Python毕业设计项目｜适配2026‑2027届选题参考✅
精选100个热门微信小程序/安卓APP毕业设计项目｜适配2026‑2027届选题参考✅
✅获取源码请私信✅
感兴趣的可以先收藏起来，还有大家在毕设选题，项目以及论文编写等相关问题都可以找我咨询，希望帮助更多的人❤️