第一章 绪论
1.1 研究背景与意义
1.1.1 研究背景
随着城市中宠物数量不断增加，由于搬家、过敏、经济原因等造成的宠物遗弃事件时有发生。流浪动物救助工作一直依靠民间爱心人士的自发组织来完成，救助的信息主要是通过社交平台的朋友圈、线下传单或者口头传播的方式进行传播。救助站工作人员要手工填写待领养宠物基本信息的纸质表格，对领养申请人的资料进行登记管理，领养协议签订之后没有建立有效的跟踪回访制度。传统处理方式存在明显的不足，信息发布范围小使领养人无法获得全部的救助信息，手工记录容易造成数据丢失或者更新滞后，申请人和救助站之间的沟通渠道不通畅会增加领养周期。伴随着计算机技术的不断发展，移动互联网的应用越来越普遍，行业规范化的要求也越来越高1。社会对于流浪动物福利的关注度越来越高，潜在的领养人数量也越来越多，对信息获取的便利性有更高的要求。救助站存在着由于手工作业不能满足日益增多的救助任务而产生的管理效率问题。市场竞争压力并没有直接影响到公益领域，但是公众对于救助工作的透明度要求促使救助机构去寻找技术上的改善途径来提高工作效率。多样化客户需求表现为领养人想要获取宠物的健康情况、疫苗接种记录以及性格特征等详细的信息，在传统的模式之下很难得到全面的满足2。技术的发展给问题的解决提供了一条可行之路，微信小程序属于轻量级的应用载体，可以将信息发布、在线交流、申请审批等各项功能集成到一个平台上，从而彻底改变救助工作的信息处理方式3。
1.1.2 研究意义
平台投入使用之后，救助信息的传播速度会大大提高，救助站发布出来的宠物信息可以迅速到达可能的领养人手中，使信息覆盖范围由原来的线下局部区域扩大到现在的线上广大用户。人工操作部分大大降低，救助站工作人员不再需要反复回答一些常见的咨询问题，可以利用在线沟通功能把标准的信息快速地传递出去。领养申请处理流程由原来的纸质表单手动填写改为线上提交系统审核，使申请信息更加完整，数据存储也更加规范方便以后的查询统计。审核状态实时更新使申请人可以随时知道申请的进展情况，减少由于打电话造成的沟通费用。救助捐赠功能把物资需求信息精确地推送给有意帮忙的人，捐赠纪录可以追踪查询，从而加强救助工作的透明程度。有偿领养模块给救助站开辟了新的资金筹措途径，部分救助物资的采购有了稳定的经费支持。管理员后台统一管理可以保证平台的正常运转，信息审核可以有效地排除虚假的内容。平台对于行业的健康发展起到积极的作用，标准化的领养程序可以形成行业规范，领养反馈机制促使领养人尽到自己的责任，减少二次遗弃的风险。从社会层面来说，流浪动物的数量会有所减少，人和动物之间和谐共处的环境正在形成。平台的设计理念可以应用到其它的公益领域中去，比如困难群众帮扶、失物招领、志愿者招募等等，用技术手段把信息流和业务流结合起来，给公益事业信息化提供一个可以借鉴的模式。长期运行中产生的救助数据可以反映出流浪动物的分布情况以及领养的需求特点，给政府制订动物管理政策给予数据支持。
1.2 国内外研究现状
1.2.1 国内现状
国内关于宠物领养和救助的信息化研究开始得比较晚，早期的研究主要是对宠物的信息展示以及论坛式的交流。近些年来伴随着移动互联网技术的普及，研究重点也慢慢转向了以微信小程序为基础的应用系统上，技术路线由原来的只做信息发布向带有在线沟通、申请审核、数据管理等各方面内容的综合平台转变，系统的功能也越来越全面，涵盖领养前的信息获取、领养中的流程跟踪以及领养后的反馈追踪等方面。
梁会成、王黎光利用JSP和SSM框架创建在线领养猫咪系统，搭建起前后端分离的架构来达成猫咪发布信息及领养申请处理的目的，他们的用户角色分配以及权限管控方案给本系统的角色管理部分给予了借鉴4。赵亚洲、杨晓冬在动物领养管理系统中使用分层架构完成领养信息的录入和审核过程，审核状态追踪机制可以给救助站处理领养申请的业务流程提供参考5。安琪从服务设计思维角度对城市流浪动物助养系统展开研究，提出了以用户触达和反馈闭环为设计理念的思考，在领养反馈模块上也创建起了完整的用户回访体系6。笪伟瀚把AI宠物技术运用到宠物领养APP的设计上，探究图像识别怎样在宠物信息管理中起到作用，他的技术想法给后来的宠物资讯模块内容分类赋予了参照7。金馨利用SSM框架创建了宠物店的线上运营系统，实现了商品管理、订单处理以及用户互动等各个方面的功能整合，该系统的多角色协作操作模式会对本系统管理员后台的功能设计造成影响8。
国内有关宠物信息展示及申请审核方面的研究成果较为丰富，不过，在线沟通、救助捐赠、有偿领养等模块的整合还存在进一步发展的余地。本系统在功能设计上弥补了已有研究的不足，把宠物信息浏览、领养申请、在线交流、救助捐款、领养评价这些业务流程连接起来，创建起普通用户、救助站、管理员三者互相配合的完整闭环，是对于已有的研究成果的一种功能性拓展和改进。
1.2.2 国外现状
国外宠物领养领域的研究较早地进入了信息化阶段，研究的重点也由最初的简单的信息登记管理转变为现在的以数据为驱动的决策和智能化的匹配。研究者大多重视用户体验改善和跨平台数据融合，创建起统一的数据库来加强信息传递速度，把社交媒体互动要素融入到领养过程里，塑造出信息发布、用户接触、交流互动、进程追踪的技术线路。
王Q针对基于微信小程序的社区便民服务平台进行研究，其模块化的设计以及用户分层的思想给平台的整体架构打下了基础，而小程序入口的便利性以及信息推送的方式又会对用户的获取救助信息的方式产生积极的影响9。爱尔兰家庭转向在线平台进行宠物领养研究显示，线上渠道可以大大提高领养匹配的成功率，用户通过平台获取到宠物的背景信息之后再做决定，这为本系统在宠物信息详情页加强健康档案和领养事项展示提供了支持10。ConnectPosts发起的宠物领养活动表明社交媒体互动可以扩大信息传播范围，其用户参与方式给本系统的设计提供了一些思路，例如点赞、收藏、评论等互动功能可以提高用户的粘性11。宠物领养简化研究中的中央数据库方案显示了数据整合对于救助效率的提高，多个救助站信息集中管理的思路也直接应用到了本系统管理员后台统一管理模块上12。Cai S等人的研究以中国的宠物托运情况为基础来创建智能宠物托运系统，他们的流程状态追踪和用户通知机制给宠物领养模块的审核进度查询赋予了技术参照，用户的随时查阅申请状况的想法被延续到了本系统当中13。
国外的研究成果对于数据整合以及用户互动都有系统的成果，可以给本系统多救助站信息的统一管理和用户互动的设计提供借鉴。本系统借鉴国外的研究成果，并联系我国实际情况，在用户中心的设计理念的基础上，把在线交流、审核监督、捐赠登记等全部纳入到一个完整的业务体系当中来构建起具有中国特色的救助服务平台。
第二章 相关技术介绍
2.1 微信小程序
微信小程序是由腾讯公司推出的一种轻量级应用形式，用户不需要下载安装就可以直接使用微信客户端来打开它。小程序依托于微信生态系统，开发者利用微信所提供的开发框架以及组件库来创建应用的界面，而它的底层使用的是JavaScript、WXML和WXSS这些技术进行页面展示和逻辑交互。微信小程序具有丰富多样的原生能力接口，可以调用摄像头、地理位置、用户登录等手机系统功能。宠物领养和救助平台普通用户进入小程序后可以迅速浏览待领养宠物信息，救助站工作人员用小程序发布救助任务，平台利用小程序用户的授权来获取用户的基本信息，简化注册过程。小程序具有即用即走的特点，使用户的使用门槛降低，潜在的领养人不需要复杂的下载安装过程就可以参与救助活动。由于拥有大量的用户，微信的平台可以利用社交网络来达到宣传救助信息的目的，从而提高社会上的知晓率。小程序开发文档齐全、社区资源丰富，可以很快解决遇到的技术问题来提高平台的建设速度和稳定性14。
2.2 UniAPP
uniapp是基于vue.js开发的所有前端应用的跨平台框架，开发者只需写一份代码就可以发布到iOS、安卓、web和各种小程序上。UniAPP保留了Vue.js开发体验的同时，用编译器把代码转化为各个平台可以识别的程序文件。框架自带许多原生的组件和API，并且可以使用条件编译的方式进行平台差异化的处理。在宠物领养和救助平台的开发中，使用UniAPP可以实现微信小程序版和H5版同步产生，从而减少各个平台的维护工作量。救助站管理员采用后台管理功能，在编写好的uniapp编译出的web页面上进行操作，普通用户则在微信端使用小程序功能，系统中相同的业务逻辑代码会在不同的终端上呈现出一样的表现15。uniapp所具有的热更新特性，可以让平台无需再次提交审核就可以对紧急问题进行修改，从而保证宠物信息展示以及领养申请等功能的正常运行。框架模块化的设计可以按需加载，平台启动时间变快，用户浏览宠物列表的时候有良好的体验。uniapp活跃的插件市场给平台集成第三方功能提供方便，减少开发时间。
2.3 Spring Boot
Spring Boot是由Pivotal团队以Spring为基础开发出来的新的微服务框架，它的主要目的就是简化Spring应用的初始化和开发。框架使用约定优先于配置的思想，用自动配置来减轻开发人员手动配置的工作量。Spring Boot自带的嵌入式Web服务器，项目可以单独打包成一个JAR文件来运行，不需要放到其他容器里去。宠物领养与救助平台的后端使用Spring Boot来完成所有的业务逻辑请求，即用户登录验证、宠物信息增删改查、领养申请状态流转、救助捐赠记录保存等等。框架所具有的事务管理特性保证了数据库操作的完整性，当用户提交领养申请的时候，系统会将申请信息以及宠物的状态一起保存到数据库中，并且对每一步骤的操作都进行回滚处理16。Spring Boot的starter模块简化了和MySQL数据库的集成过程，开发者只需要简单的配置就可以完成数据源的设置。框架安全机制和拦截器功能给平台赋予了权限控制根基，管理员同普通用户的访问接口被很好地分开。
2.4 MySQL
MySQL是由Oracle公司开发的一款开源的关系型数据库管理系统，它以体积小、速度快、成本低为特点，在中小型项目中得到了广泛的应用。数据库用结构化查询语言来操作数据，具有事务处理、ACID特性以及多用户并发访问的功能。MySQL使用InnoDB存储引擎来保证数据的完整性以及一致性，可以进行行级锁和外键约束。MySQL对宠物领养和救助平台所有的业务数据进行持久化存储，即普通用户的个人信息、救助站的资质证明、宠物的档案资料、领养申请表、救助捐赠的明细账、宠物的相关资讯文章等都由它来处理。救助站发布有偿领养信息的时候，系统会把宠物编号、领养价格、审核状态这些字段存入相应的数据表当中。管理员在后台执行批量审核的时候，利用MySQL的事务来保证多条记录的审核状态一起被修改。数据库利用索引来提高查询的效率，用户可以在搜索宠物品种的时候得到迅速的结果。建立定期备份制度来保证平台的数据安全，防止由于硬件故障造成救助信息的丢失17。
第三章 系统分析
3.1 可行性分析
3.1.1 技术可行性
技术可行性的分析。系统前端使用的是微信小程序和UniAPP框架相结合的方式进行实现，UniAPP可以将一套代码编译成多个版本，发布到不同的平台，具有很好的跨平台开发性，可以提高代码的重复利用率以及开发效率。微信小程序依靠微信生态系统，有着诸多的原生组件以及API接口，可以达成宠物信息展示、即时交流、申请填报等互动任务。后端使用SpringBoot框架搭建业务逻辑层，SpringBoot是用Java语言开发的，具有自动配置、依赖注入和事务管理的能力，可以稳定地处理前端请求，并对数据进行校验以及业务处理。数据存储使用的是MySQL关系型数据库，可以对宠物信息、用户信息、申请记录、捐赠记录等结构化的数据进行持久化存储和高效的查询。开发组对于uniapp跨端开发、springboot框架使用方法、MySQL数据库设计与优化这些相关的知识有已有的工作经验。系统运行时出现的压力可以借助数据库连接池和合理的索引来减轻，数据安全方面用输入校验、权限控制来规避常见的安全问题。因此该系统的技术上是可行的。
3.1.2 操作可行性
操作可行性的分析。平台面向普通用户、救助站工作人员和管理员三个角色，操作设计符合各方面的使用习惯。普通用户一般用手机来浏览信息、办理事务，微信小程序不需要下载安装就可以直接扫描或者搜索打开，降低了使用的难度。用户可以在宠物信息列表中使用品种搜索和状态筛选来找到自己想要的宠物，详情页布局清楚，点赞、收藏、申请等操作按钮的位置也很明显。救助站工作人员日常需要处理宠物的信息以及审核申请，在系统中提供了列表显示和条件筛选的功能，把线下纸质的记录和分散的信息集中到一个统一的界面当中，简化了工作的程序。管理员在后台管理系统中对各种审核和查询的任务进行处理，页面使用表格形式展示并带有筛选条件的组合方式。系统上线之后可以持续稳定的运行下去，在以后的维护中主要以数据备份和功能更新为主，一般不会出现复杂的技术问题。因此系统在操作上是可以实现的。
3.1.3 经济可行性
经济可行分析。项目开发阶段的主要投入为人力成本，即需求调研、系统设计、编码实现和测试调试等各个环节的人力成本。硬件上利用已有的开发设备和服务器资源，不需要另外购买专用的硬件设备。软件选择采用开源技术栈和免费开发工具，微信小程序开发不需要支付平台使用费，UniAPP是开源的框架，SpringBoot是基于Java开源生态的，MySQL社区版可以满足系统的数据库存储要求。系统部署之后可以依靠现有的服务器来运行，在日常的维护方面所花费的成本也比较低。平台依靠有偿领养模块为救助站创建出一条合理的资金流动渠道，捐赠功能能调动起广大群众的热情参与来资助救助工作，长期运作具备较强的资金自我保障能力。系统上线之后所带来的人力资源、信息匹配方面的改进等各方面效益都大于开发和维护的投入。所以该系统从经济上是可行的。
3.2 功能需求分析
UML用例图是用来描述系统功能需求的图形化工具，用例图通过显示系统和外部参与者之间交互的关系来说明系统的功能。用例图用用例来表示系统可以完成的特定功能，参与者是和系统进行交互的各种用户或者外部系统。用例图在分析和设计阶段可以使用，保证系统功能完整、正确，使开发人员与客户之间有一个共同的语言。用直观的图示，UML用例图给出系统功能和角色之间的关系。本文会按照角色模块来完成系统的功能需求分析。
3.2.1 用户功能
用户可以在平台上看到宠物的信息列表，在搜索栏输入品种或者筛选出领养的状态之后再进行查询，进入到宠物的详情页面之后可以看到该宠物的年龄、健康状况以及领养事宜，并且可以选择点赞或者收藏。用户在在线沟通模块上同救助站进行实时交流，从领养申请页面输入个人资料后提出领养请求。有偿领养模块展示需要付费的宠物，用户可以查看价格之后申请领养。救助信息模块显示需要救助的任务，用户查看详情之后可以进行捐助。宠物资讯模块给用户提供有关宠物的文章，用户可以按照分类浏览或者搜索文章来阅读。领养反馈模块给用户提供在领养之后可以上传宠物的生活照片以及反馈的内容。宠物领养模块让用户查看申请审核状态及救助站回复。用户角色用例图如图3-1所示。
图3-1用户用例图
3.2.2 救助站功能
救助站可以对本救助站发布过的宠物进行查询，在查询到的宠物中选择需要修改或添加的信息进行修改或者新增。有偿领养模块是救助站对外提供需要收费的宠物信息登记服务，用户可填写宠物品种、年龄、健康情况、领养价格以及领养注意事项等信息并提交审核。救助信息模块是救助站发布需要物资或者资金援助的救助任务，输入救助标题、地点、所需物资和描述之后，在用户端展示出来。救助捐赠模块可以查看用户对于救助任务的捐款情况，支持按支付状态查询。领养申请模块是显示用户提交的申请详情，救助站按照申请人信息进行审核。宠物领养模块可以让救助站查看用户领养申请的审核进度，也可以填写审核回复。救助站角色用例图如图3-2所示。
图3-2救助站用例图
3.2.3 管理员功能
管理员可以查看所有的宠物信息，在这个模块下可以按照品种、领养情况以及审核情况来筛选查询，并且支持对这些数据进行批量的审核、删除或者查看评价的操作。领养申请管理模块显示所有的用户领养申请记录，管理员可以按照品种、状态进行查询和查看用户提交的领养反馈。有偿领养管理模块使管理员可以查看有偿领养信息，并且可以通过品种、状态等进行筛选，还可以对有偿领养进行批量的审核、删除以及查看评论。宠物领养管理模块可以显示所有的领养申请审核进度，可以根据领养状态、用户姓名、审核状态、支付状态进行查询，对领养申请进行批量审核、删除以及查看反馈。领养反馈管理模块是给管理员提供查看用户提交的领养反馈的功能，可以按照品种、用户姓名等条件查询并查看完整的反馈内容以及生活照。救助信息管理模块显示所有的救助任务，管理员可以按照救助标题、宠物状态进行查询，也可以对救助信息进行删除以及查看评论。救助捐赠管理模块可展示全部的捐款记录，按照救助标题、宠物状况及支付状况等要素展开筛选并加以展示，还能对已有的付款情形予以查询。管理员角色用例图如图3-3所示。
图3-3管理员用例图
第四章 系统设计
4.1 系统架构设计
系统采用经典的单体应用分层架构设计，整体划分为前端展示层、后端业务层、数据持久层与开发支撑层四个部分。前端基于微信小程序与UniAPP框架构建，利用Vue.js实现界面交互与数据渲染。后端基于Spring Boot框架集中处理所有业务逻辑，控制器层接收用户请求后调用Service组件完成具体操作。MySQL数据库承担数据持久化任务，通过合理的数据表设计与索引配置保障查询效率。开发阶段使用IntelliJ IDEA作为集成开发环境，Maven管理项目依赖，Git进行代码版本控制。各层之间通过定义良好的接口进行通信，形成职责清晰、耦合度低的单体应用架构。整个系统架构如图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 数据库设计
数据库设计属于系统开发的基础工作，关系型数据库利用二维表的形式来组织数据，可以很好地保证数据的正确性和完整。规范化设计原则把数据冗余控制在合理的范围之内，用主键和外键约束来保持表之间的联系。本系统用MySQL数据库来存储所有的业务数据，即用户信息、宠物信息、申请记录、捐赠记录等主要的数据。数据库的设计要符合第三范式的规则，保证每一个非主键的字段都是完全依赖于主键的，并且在考虑查询效率的基础上做适当的冗余设计。合理的数据类型选取和索引设置给系统高效运转赋予了保障18。
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救助捐赠实体属性图
系统ER图如图4-17所示。
图4-17系统ER图
4.4.2 数据库表设计
数据库表设计就是按照业务需求确定数据库表的结构、字段类型以及关系。经由规范化的创建，保证数据的完备性、统一性、高效性，防止出现重复的数据，给之后的数据查询、保存、保养赋予明晰的架构。以下为系统的数据库表设计。
普通用户表主要用于存储平台中注册的普通用户基本信息。主要包括用户姓名、用户手机、审核状态等字段。如表4-1所示。
表4-1普通用户表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | ordinary_user_id | int | 11 | 是 | 是 | 普通用户ID |
| 2 | user_name | varchar | 64 | 否 | 否 | 用户姓名 |
| 3 | users_mobile_phone | varchar | 16 | 否 | 否 | 用户手机 |
| 4 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 5 | user_id | int | 11 | 是 | 否 | 用户ID |
救助站表主要用于存储救助机构的注册信息与资质材料。主要包括救助站名称、联系手机、资质证明、审核状态等字段。如表4-2所示。
表4-2救助站表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | rescue_station_id | int | 11 | 是 | 是 | 救助站ID |
| 2 | name_of_rescue_station | varchar | 64 | 否 | 否 | 救助站名称 |
| 3 | contact_phone | varchar | 16 | 否 | 否 | 联系手机 |
| 4 | qualification_certificate | varchar | 255 | 否 | 否 | 资质证明 |
| 5 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
宠物信息表主要用于记录救助站发布的待领养宠物详细资料。主要包括宠物编号、宠物品种、宠物年龄、健康状况、领养状态等字段。如表4-3所示。
表4-3宠物信息表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | pet_information_id | int | 11 | 是 | 是 | 宠物信息ID |
| 2 | pet_number | varchar | 64 | 是 | 是 | 宠物编号 |
| 3 | pet_breed | varchar | 64 | 否 | 否 | 宠物品种 |
| 4 | pet_age | varchar | 64 | 否 | 否 | 宠物年龄 |
| 5 | health_status | varchar | 64 | 否 | 否 | 健康状况 |
| 6 | adoption_status | varchar | 64 | 否 | 否 | 领养状态 |
有偿领养表主要用于存储需要支付费用的领养宠物信息。主要包括宠物编号、领养价格、领养状态、审核状态等字段。如表4-4所示。
表4-4有偿领养表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | pauser_id_adoption_id | int | 11 | 是 | 是 | 有偿领养ID |
| 2 | pet_number | varchar | 64 | 是 | 是 | 宠物编号 |
| 3 | adoption_price | double | - | 否 | 否 | 领养价格 |
| 4 | adoption_status | varchar | 64 | 否 | 否 | 领养状态 |
| 5 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
领养申请表主要用于记录用户提交的领养请求信息。主要包括宠物编号、用户姓名、用户手机、审核状态等字段。如表4-5所示。
表4-5领养申请表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | application_for_adoption_id | int | 11 | 是 | 是 | 领养申请ID |
| 2 | pet_number | varchar | 64 | 否 | 否 | 宠物编号 |
| 3 | user_name | varchar | 64 | 否 | 否 | 用户姓名 |
| 4 | users_mobile_phone | varchar | 64 | 否 | 否 | 用户手机 |
| 5 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
宠物领养表主要用于存储审核通过的领养记录及后续状态。主要包括宠物编号、用户姓名、审核状态、支付状态等字段。如表4-6所示。
表4-6宠物领养表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | pet_adoption_id | int | 11 | 是 | 是 | 宠物领养ID |
| 2 | pet_number | varchar | 64 | 否 | 否 | 宠物编号 |
| 3 | user_name | varchar | 64 | 否 | 否 | 用户姓名 |
| 4 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 5 | pay_state | varchar | 16 | 是 | 否 | 支付状态 |
领养反馈表主要用于记录用户领养后提交的宠物生活情况。主要包括宠物编号、反馈内容、反馈时间、用户姓名等字段。如表4-7所示。
表4-7领养反馈表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | adoption_feedback_id | int | 11 | 是 | 是 | 领养反馈ID |
| 2 | pet_number | varchar | 64 | 否 | 否 | 宠物编号 |
| 3 | feedback_content | text | 65535 | 否 | 否 | 反馈内容 |
| 4 | feedback_time | datetime | - | 否 | 否 | 反馈时间 |
| 5 | user_name | varchar | 64 | 否 | 否 | 用户姓名 |
救助信息表主要用于存储救助站发布的需援助任务详情。主要包括救助编号、救助标题、宠物品种、所需物资等字段。如表4-8所示。
表4-8救助信息表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | rescue_information_id | int | 11 | 是 | 是 | 救助信息ID |
| 2 | rescue_number | varchar | 64 | 否 | 否 | 救助编号 |
| 3 | rescue_title | varchar | 64 | 否 | 否 | 救助标题 |
| 4 | pet_breed | varchar | 64 | 否 | 否 | 宠物品种 |
| 5 | materials_required | varchar | 64 | 否 | 否 | 所需物资 |
救助捐赠表主要用于记录用户对救助任务的捐赠信息。主要包括救助编号、捐赠金额、支付状态、用户姓名等字段。如表4-9所示。
表4-9救助捐赠表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | relief_donations_id | int | 11 | 是 | 是 | 救助捐赠ID |
| 2 | rescue_number | varchar | 64 | 否 | 否 | 救助编号 |
| 3 | amount_of_donation | double | - | 否 | 否 | 捐赠金额 |
| 4 | pay_state | varchar | 16 | 是 | 否 | 支付状态 |
| 5 | user_name | varchar | 64 | 否 | 否 | 用户姓名 |
第五章 系统实现
5.1 用户功能实现
5.1.1 宠物信息功能实现
用户在宠物信息列表页面可以通过搜索宠物品种或选择领养状态筛选符合条件的宠物。列表展示宠物照片、品种、救助站名称、领养状态及互动数据，点击可进入详情页查看宠物年龄、健康状况、领养事项等详细信息。宠物信息界面如图5-1所示。
图5-1宠物信息界面
5.1.2 在线沟通功能实现
用户可在宠物详情页发起在线沟通，进入对话界面后与救助站进行实时文字交流。系统记录对话时间并展示双方身份，便于领养相关事项的咨询与确认。在线沟通界面如图5-2所示。
图5-2在线沟通界面
5.1.3 领养申请功能实现
用户提交领养申请时需填写个人姓名、手机号码及身份信息，系统将申请数据推送至对应救助站。页面同时展示宠物基本信息与申请人资料，形成完整的申请记录。领养申请界面如图5-3所示。
图5-3领养申请界面
5.1.4 有偿领养功能实现
有偿领养列表展示标价宠物信息，包含救助站名称、宠物品种、领养状态及价格标签。用户可通过搜索和状态筛选查找宠物，点击进入详情查看领养价格、事项并执行申请或沟通操作。有偿领养界面如图5-4所示。
图5-4有偿领养界面
5.1.5 救助信息功能实现
用户浏览救助信息时可查看救助站发布的求助内容，包括救助标题、时间、地点、所需物资及宠物状态。页面提供点赞和捐赠入口，支持用户对救助行动进行关注与支持。救助信息界面如图5-5所示。
图5-5救助信息界面
5.1.6 宠物资讯功能实现
宠物资讯模块为用户提供文章列表，涵盖宠物养护、行业新闻及健康知识等内容。支持按最新、热度、点赞最高排序，用户可点击阅读资讯详情。宠物资讯界面如图5-6所示。
图5-6宠物资讯界面
5.1.7 领养反馈功能实现
领养反馈页面允许用户提交领养后的宠物生活照及文字反馈内容。系统展示原领养申请信息，用户填写后提交至平台，便于救助站了解领养状况。领养反馈界面如图5-7所示。
图5-7领养反馈界面
5.1.8 宠物领养功能实现
用户在宠物领养详情页可查看领养申请的处理结果，包括审核状态、审核回复及领养价格。页面整合用户信息与审核意见，帮助用户了解申请进展。宠物领养界面如图5-8所示。
图5-8宠物领养界面
5.2 救助站功能实现
5.2.1 宠物信息功能实现
救助站可在宠物信息列表查看本机构发布的宠物，并根据领养状态筛选管理。列表展示宠物品种、救助站名称及互动数据，便于救助站掌握宠物被关注情况。宠物信息界面如图5-9所示。
图5-9宠物信息界面
5.2.2 有偿领养功能实现
救助站通过有偿领养模块发布标价宠物，填写宠物品种、年龄、健康状况、领养价格及领养事项。系统记录审核状态，支持救助站对发布内容进行管理。有偿领养界面如图5-10所示。
图5-10有偿领养界面
5.2.3 救助信息功能实现
救助站可发布救助信息，填写救助标题、地点、宠物品种、状态、所需物资及描述。提交后信息展示在用户端救助信息列表，便于向社会寻求帮助。救助信息界面如图5-11所示。
图5-11救助信息界面
5.2.4 救助捐赠功能实现
救助站通过救助捐赠模块查看用户对救助信息的捐赠记录。页面展示救助标题、宠物状态及支付状态，支持按条件查询并核对捐赠情况。救助捐赠界面如图5-12所示。
图5-12救助捐赠界面
5.2.5 领养申请功能实现
救助站在领养申请详情页查看用户提交的申请资料，包括用户身份信息、居住环境及领养次数。页面提供审核状态设置与提交入口，便于救助站处理领养请求。领养申请界面如图5-13所示。
图5-13领养申请界面
5.2.6 宠物领养功能实现
救助站可查阅用户领养申请的审核结果，页面展示宠物信息、用户资料及审核状态与回复。救助站可对申请执行提交或取消操作，完善领养流程管理。宠物领养界面如图5-14所示。
图5-14宠物领养界面
5.3 管理员功能实现
5.3.1 宠物信息管理功能实现
管理员在宠物信息列表页面可按宠物品种、领养状态、审核状态筛选数据。列表展示救助站、宠物编号、健康状况等信息，支持批量审核、删除及查看评论操作。宠物信息管理界面如图5-15所示。
图5-15宠物信息管理界面
5.3.2 领养申请管理功能实现
领养申请管理模块提供按宠物品种、领养状态、审核状态查询功能。管理员可查看申请人信息与申请详情，执行反馈查看及申请处理操作。领养申请管理界面如图5-16所示。
图5-16领养申请管理界面
5.3.3 有偿领养管理功能实现
管理员通过有偿领养列表管理所有标价宠物信息，支持按品种、领养状态、审核状态筛选。列表展示救助站、宠物编号、价格及健康状况，可批量审核、删除及查看评论。有偿领养管理界面如图5-17所示。
图5-17有偿领养管理界面
5.3.4 宠物领养管理功能实现
宠物领养管理模块允许管理员按领养状态、用户姓名、审核状态、支付状态查询记录。列表整合救助站、宠物信息及用户资料，支持详情查看与反馈处理。宠物领养管理界面如图5-18所示。
图5-18宠物领养管理界面
5.3.5 领养反馈管理功能实现
管理员可在领养反馈列表查看用户提交的反馈记录，包含救助站名称、宠物品种、用户姓名及手机号。支持按宠物品种和用户姓名查询，点击详情可查阅完整反馈内容。领养反馈管理界面如图5-19所示。
图5-19领养反馈管理界面
5.3.6 救助信息管理功能实现
救助信息管理模块展示救助站发布的救助信息，包括救助编号、标题、时间、地点及宠物品种。管理员可通过救助标题和宠物状态查询，执行详情查看与评论管理。救助信息管理界面如图5-20所示。
图5-20救助信息管理界面
5.3.7 救助捐赠管理功能实现
管理员通过救助捐赠列表查看用户捐赠记录，支持按救助标题、宠物状态、支付状态筛选。列表展示救助站、救助编号、宠物品种及用户信息，可执行详情查看与支付操作。救助捐赠管理界面如图5-21所示。
图5-21救助捐赠管理界面
第六章 系统测试
6.1 测试目的
系统功能测试使用黑盒测试的方法，把软件系统看作是不透明的黑盒子，只对输入和输出之间是否符合需求规格说明书进行验证。测试过程中完全忽略了系统内部数据处理的逻辑、代码实现的过程以及程序运行的原理，只从用户的操作角度出发，设计出有效的测试用例来覆盖平台的主要业务流程。对宠物领养和救助平台的三种用户角色进行测试，分别模拟普通用户的领养申请、救助站发布救助信息、管理员审核管理的操作流程，检验各个模块对于合法的数据是否可以做出正确的反应，在非法输入的情况下是否能够给出相应的提示。测试用例的设计采用等价类划分和边界值分析的方法，对表单必填项、数据格式校验、状态流转节点等重要的控制点做了全面的覆盖，保证了业务流程中的每一个环节都可以顺利地被执行19。同时用场景法创建起完整的业务操作链条，从用户提交领养申请开始，经过救助站审核、管理员确认，直到领养反馈提交的全部过程都做贯通性测试，检查数据在不同角色之间传递是否一致完整。测试执行阶段把实际输出结果和预期结果的契合情况记入其中，针对出现的缺陷展开定位并加以复现，最后形成功能测试报告成为系统交付时所依赖的凭证。
6.2 测试方法
系统功能测试的主要目的就是检验宠物领养和救助平台能否正确地实现需求分析阶段所确定的所有业务功能，保证平台上线之后可以稳定地支撑起用户、救助站和管理员这三个角色的日常操作需求。测试工作先对各个功能模块进行完整性、正确性的检验，即宠物信息展示是否齐全、领养申请提交是否成功、救助信息发布是否及时、审核状态变更是否正确等基本业务操作，保证每一个功能点都能按照设计要求正常运行20。其次对业务逻辑是否严谨、数据流转是否准确进行验证，即用户提交领养申请之后救助站能否正确接收和处理，救助站发布有偿领养信息之后管理员能否有效地审核并控制展示状态，用户提交领养反馈之后管理员能否查阅并跟进，用全流程的数据跟踪来检验跨模块交互的可靠性。测试的同时还要对系统的容错能力和异常处理机制进行考察，即查看在用户输入不完整的数据或者执行非法操作的时候，系统能否给出清楚的提示信息，并且能够阻止错误的操作继续下去，防止因为操作失误造成数据污染或者业务中断的情况出现。另外通过功能测试发现隐藏的界面显示错误、状态更新慢、权限控制漏洞等问题，给系统的改进指明了方向，保证系统在实际运行中可以高效、准确、稳定的为宠物领养和救助公益服务。
6.3 测试内容
领养申请功能测试验证用户提交领养资料至救助站接收的全过程。领养申请测试如表6-1所示。
表6-1领养申请测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 领养申请 | 提交完整申请信息 | 用户填写姓名、手机、身份信息后点击提交 | 系统提示申请成功并推送至对应救助站 | 申请数据存入数据库，救助站端可见 | 符合预期 |
| 领养申请 | 提交必填项缺失的申请 | 用户未填写身份信息直接提交 | 系统提示必填项不能为空 | 页面提示身份信息为必填项 | 符合预期 |
| 领养申请 | 查看已提交的申请 | 用户在申请记录中点击已提交申请 | 页面展示申请详情及当前状态 | 显示申请人信息与待审核状态 | 符合预期 |
救助信息发布功能测试检查救助站发布求助内容后用户端的展示效果。救助信息发布测试如表6-2所示。
表6-2救助信息发布测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 救助信息 | 发布完整救助信息 | 救助站填写标题、地点、品种、物资后提交 | 信息成功发布并在用户端救助列表显示 | 用户端可见新发布的救助信息 | 符合预期 |
| 救助信息 | 发布必填项缺失的信息 | 救助站未填写救助地点直接提交 | 系统提示必填字段未填写 | 页面标红缺失项并阻止提交 | 符合预期 |
| 救助信息 | 用户查看救助详情 | 用户在列表点击某条救助信息 | 跳转至详情页显示完整救助内容 | 展示标题、时间、物资及宠物状态 | 符合预期 |
有偿领养管理功能测试验证管理员对有偿领养信息的审核与控制能力。有偿领养管理测试如表6-3所示。
表6-3有偿领养管理测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 有偿领养管理 | 筛选待审核的有偿领养信息 | 管理员选择审核状态为未审核后点击查询 | 列表仅显示未审核的有偿领养记录 | 展示待审核的宠物信息 | 符合预期 |
| 有偿领养管理 | 批量审核通过多条记录 | 管理员勾选多条记录后点击批量审核 | 所选记录审核状态统一变更为已通过 | 列表状态更新为已通过 | 符合预期 |
| 有偿领养管理 | 删除违规有偿领养信息 | 管理员点击某条记录的删除按钮并确认 | 该条信息从列表移除且用户端不可见 | 用户端不再显示该宠物 | 符合预期 |
领养反馈管理功能测试验证用户提交领养反馈后管理员端的查阅与处理能力。领养反馈管理测试如表6-4所示。
表6-4领养反馈管理测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 领养反馈管理 | 按宠物品种查询反馈 | 管理员输入宠物品种后点击查询 | 列表显示该品种相关的领养反馈记录 | 反馈列表按品种筛选成功 | 符合预期 |
| 领养反馈管理 | 按用户姓名查询反馈 | 管理员输入用户姓名后点击查询 | 列表显示该用户提交的领养反馈 | 反馈记录与用户匹配正确 | 符合预期 |
| 领养反馈管理 | 查看反馈详情 | 管理员点击某条反馈的详情按钮 | 跳转至详情页显示反馈内容与照片 | 完整展示用户提交的信息 | 符合预期 |
救助捐赠管理功能测试验证捐赠记录的查询与支付状态跟踪能力。救助捐赠管理测试如表6-5所示。
表6-5救助捐赠管理测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 救助捐赠管理 | 按救助标题查询捐赠记录 | 管理员输入救助标题后点击查询 | 列表显示该救助信息对应的捐赠记录 | 捐赠记录与救助标题匹配 | 符合预期 |
| 救助捐赠管理 | 按支付状态筛选捐赠 | 管理员选择已支付状态后点击查询 | 列表仅显示已支付的捐赠记录 | 筛选结果与支付状态一致 | 符合预期 |
| 救助捐赠管理 | 查看捐赠详情并确认支付 | 管理员点击某条记录的支付按钮 | 系统记录支付确认并更新状态 | 捐赠状态变更为已支付 | 符合预期 |
宠物领养管理功能测试验证管理员对领养申请及支付状态的综合管理能力。宠物领养管理测试如表6-6所示。
表6-6宠物领养管理测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 宠物领养管理 | 按审核状态查询领养记录 | 管理员选择已通过状态后点击查询 | 列表显示审核通过的领养申请 | 展示状态为已通过的记录 | 符合预期 |
| 宠物领养管理 | 按支付状态查询领养记录 | 管理员选择未支付状态后点击查询 | 列表显示未完成支付的领养记录 | 筛选结果与支付状态相符 | 符合预期 |
| 宠物领养管理 | 查看领养详情并处理反馈 | 管理员点击某条记录的反馈按钮 | 跳转至反馈页面可查看用户提交内容 | 反馈信息完整展示 | 符合预期 |
宠物信息管理功能测试验证管理员对全平台宠物信息的审核与维护能力。宠物信息管理测试如表6-7所示。
表6-7宠物信息管理测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 宠物信息管理 | 按领养状态筛选宠物 | 管理员选择已领养状态后点击查询 | 列表仅显示已领养的宠物记录 | 筛选结果与领养状态一致 | 符合预期 |
| 宠物信息管理 | 批量审核多条宠物信息 | 管理员勾选多条记录后点击批量审核 | 所选记录审核状态统一更新 | 列表状态变更为已审核 | 符合预期 |
| 宠物信息管理 | 查看宠物详情及评论 | 管理员点击某条记录的查看评论按钮 | 跳转至评论列表页面 | 展示用户对该宠物的评论 | 符合预期 |
测试结论
本次系统功能测试对宠物领养和救助平台的主要业务模块进行全方位的检验，包含用户端的领养申请、救助信息浏览，救助站端的信息发布、申请处理，管理员端的数据审核、状态管理等功能。测试使用黑盒测试的方法，根据设计的测试用例逐个执行，实际输出的结果和预期的结果完全一致，所有的测试用例都成功地通过了。在测试过程中系统界面跳转正确、数据提交和保存完整、状态变化及时同步，没有出现功能缺失或者逻辑错误的情况。跨角色业务流转环节验证效果较好，用户提交的领养申请可以正确地推送到对应的救助站，救助站发布出来的救助信息可以在用户的端口上进行正常的展示，管理员发起的审核操作会及时对数据的状态做出调整，并且会影响前端的显示情况。系统对于异常输入做出的反应是符合预期的，当用户没有填写必填项或者提交格式有误的时候，页面会给出明显的提示并且阻止错误的流程继续进行。测试结果显示，宠物领养和救助平台的功能全部实现，业务流程顺畅，交互逻辑清楚，可以满足普通用户、救助站管理员以及系统管理员这三种角色日常使用的需要，具备了上线运行的所有条件。根据实际使用的反馈来不断改进界面的细节以及操作的便利性，从而提高用户的体验感。