第一章 绪论
1.1 研究背景与意义
传统家政服务业一直采用拨打电话进行预定，再到线下的实体中介去寻找信息，信息传递具有单向性，滞后性严重，供求双方的匹配速度低，社区居民和服务人员之间的信息不对称问题比较严重1。虽然互联网早期有出现一些分类信息网及论坛，一定程度上解决了信息查询难的问题，但是在服务的过程中还是一段一段的服务体验。服务项目更新慢，缺乏有效的信用保障体系支撑，用户的评论不能沉淀下来等，这些都无法满足市场需求对于服务时效性、透明性和规范化的需求2。构建一体化的线上平台，可以有效提高家政服务行业的资源配置效率，降低由于信息封锁造成的不必要的错误发生率，系统的业务流程重造使服务过程更规范、标准3。保障了客户以及服务工作人员的双方利益，是建立良性市场环境的基础。也为其他的生活类服务的网络化整合提供了技术支持和运营经验借鉴。
1.2 国内外研究现状
国内家政服务平台线上化进程经过了多个阶段，初期的门户网站仅仅是对基础的分类信息进行呈现，服务互动性较差。之后随着移动互联网的发展，家政领域的垂直型应用逐渐出现，"58到家"、"天鹅到家"等平台集成了信息展示及线上预约服务，实现了服务平台化4。在初期他们更多的是充当一个供需对接的角色5。后来又添加了服务员工的审核认证体系和服务的好评评级制度作为信任背书6。近一两年的发展方向是打造服务闭环系统，部分平台会加入服务调度系统及征信管理系统模块来提高服务匹配准确率和服务体验7。但是在家政服务全流程信息化及不同平台间的信息打通上还有很长的一段距离8。
国外家政服务平台起步相对较早，种类也较为丰富。其中Taskrabbit就属于典型的按需服务平台，以地理位置为基础对工作需求进行及时匹配和即时雇用9。Handy则依靠标准化的服务产品套餐和公司化雇佣服务员工两种方式保证服务的质量标准10。而欧洲市场中还存在着不少以专项高端家政服务或者区域式家政服务为主的平台。而这些国外家政服务平台都十分注重数据支撑下的数据分析，利用算法优化派单规则11。同时充分接入第三方支付，背景审查和保险环节形成了相对完整的商业闭环12。这也反映了技术和服务的高度融合，以及平台的信任保障体系对于整个家政平台发展的重要性13。
1.3 主要研究内容
本文的研究目标是设计并开发一个基于浏览器/服务器架构的家政服务系统平台。论文主要内容包括系统的总体需求分析和定位以及居民客户、服务人员和管理员三个主要角色的功能分配和交互环节的设计。在软件工程的标准指导下，先后对系统的总体架构进行设计；前后台的各项细粒度的功能模块进行设计；数据库的概念结构和逻辑结构进行了设计。技术方案采取了前后端分离的架构方式。前端通过Vue.js框架进行开发，后端以SpringBoot框架为基础开发RESTful架构的数据接口。数据存储层选用MySQL数据库。经过开发所完成的系统主要包括家政服务的发布、预定；服务日志管理和服务评价管理；后台的数据汇总和各类资源管理等主要系统功能模块，致力于解决家政服务行业存在的信息不对称、流程不规范和管理效率低下等问题。
第二章 相关技术介绍
2.1 SpringBoot框架
这个框架基于Spring生态体系之上，目的是为了方便开发者减少传统的Spring应用项目的初始化及开发难度。它的主要原理就是自动配置、起步依赖。自动配置是根据项目类路径所存在的库来进行自动推测以及自动配置相应的Spring组件14。起步依赖则是预先定义好的一组依赖描述符，可以将常见的一系列所需库整合起来进行导入，在整个系统开发中，后端服务模块的搭建快速便捷就是得益于此类框架。框架内置了web容器，使应用能被打包成可执行的jar文件独自启动运行15。使用了基于java注解的方式去代替了大量的xml文件配置。在应用程序主类上添加的@SpringBootApplication注解开启组件扫描及自动配置，框架内部通过条件化配置类确定哪些bean才会最后被实例化。此方式让开发者更加关注业务层面而不是基础设施的组合配置。
2.2 Vue框架
Vue.js是一款可以用来创建UI的渐进式JavaScript框架，它的核心是一个响应式数据绑定系统，用数据劫持结合发布者-订阅者模式的方式实现了数据与视图之间的双向绑定，当一个组件的状态数据发生改变的时候，对应的视图会自动更新，以展现最新的数据状态16。它采用了以html为基础的模板语法，允许开发者声明式的将组件实例的数据绑定到渲染成的dom上去，在编译阶段，模板会被编译为渲染函数，最终生成虚拟dom树。在系统前端界面当中，服务列表卡片的生成便是依靠此原理进行的。虚拟DOM是一种轻量级的真实DOM的javascript对象表达式。状态的变更引起新的虚拟DOM树产生，框架用高效的算法来计算新老两棵DOM树的区别。计算出最小化的更新操作集之后再批量性的施加到真实的DOM上17。这一过程避免了频繁直接接触真实DOM带来性能损失。组件是构成Vue应用程序的基本单位，每个组件都包含自身专属的模板、逻辑以及样式，父组件通过props向下传值，子组件通过events向上传递事件信息。而全局状态下，跨组件间的通信则是由特定的库来进行管理的。这样的组件化结构使得大型单页面应用程序也可以方便地切分为一个个相对独立的小型模块进行组合。
2.3 MySQL数据库
MySQL是一个开放源码的关系型数据库管理系统，遵循客户机/服务器体系结构。它使用标准的SQL语句来进行数据定义、数据操以及查询等操作，数据库的逻辑结构分为数据库、表、行、列等多个层次。数据以二维表格形式组织起来，表与表之间通过主键、外键相联系18。在本系统里面的服务信息以及用户的预约记录都存放在这样的关系表里头。数据库引擎用于存储、查询和管理数据，其常用的存储引擎InnoDB就具有事务和外键的功能。事务是一个不可再分的工作单位，包括原子性、一致性、隔离性和持久性四个性质。事务的隔离级决定了多个事务如何相互影响，事务的并发控制就是以此为基础来防止可能出现的数据问题。为了使数据查询的效率更高，数据库允许我们在表的一列或多列上建立索引。索引是一种特殊的文件，通常以B+树的形式存储，以便对表中的特定行进行快速访问。在处理复杂的涉及许多表的SELECT语句时，查询优化器会评估不同可能的处理方法，并确定最优的执行方案。安全性则有用户账户管理和权限控制系统提供保护，系统赋予不同角色的数据库操作者不同的权限对数据库对象进行不同的操作19。系统持久化的数据都是靠这一系列的机制实现。
2.4 MyBatis
MyBatis是基于java的持久化层框架，其封装了对JDBC的操作过程，在核心设计思想上是将SQL语句与java代码分离，统一存放在XML文件或者注解当中加以管理配置，从而使得业务逻辑与数据库访问逻辑相互独立。开发人员只需定义表示数据库操作的映射接口，运行时框架将会为此类接口创建一个代理实例对象。SQL映射文件或者注解将会把接口的方法映射成对应的SQL语句。应用程序调用接口方法时，框架将会执行相应的SQL指令。在数据处理的过程中，服务记录查询请求的映射就是由该框架实现的。它可以自动处理java对象和sql参数间的类型转化，还能将sql查询结果集转化为java对象或对象列表20。结果映射规则明确地写入配置文件。针对动态SQL的构造，提供了标签元素，可以在运行时环境下根据不同条件来构造出不同内容的SQL片段，以此来适应多变的数据库查询要求。并且还可以很好地同Spring等容器框架相整合，会话工厂以及会话对象均由容器创建并管理，而数据处理过程中的各种事务操作则交给容器统一管控，简化了持久层相关代码的开发和维护任务。
第三章 系统需求分析
3.1 功能需求分析
居民用户可以在家政服务平台上，查阅家政类的最新消息并对新闻内容进行编辑处理。系统提供了家政服务的浏览模块，居民用户可浏览服务项目，也可浏览指定服务项目的具体内容。预约服务作为一项主要操作，居民在确定了服务类别和服务内容以及服务人员并核实相关价格之后，可以提出某一特定时间的服务申请，之后再进行预约情况的查询、修改或者清空，待服务结束之后，居民可以查看以往服务记录，查阅记录详情。针对已经发生过的服务记录，居民对其服务项目、类别、费用以及完成时刻可以做出评判，输入评分级别。
居民角色用例图如图3-1所示。
图3-1居民用例图
管理员管理整体后台。后台首页显示平台总体运行的数据情况，如访问总次数，各种资源的数量统计等。管理员还管理着系统内所有的用户账号，包括管理员账号、居民用户账号和服务员账号，可以对账号进行增加、删除、查看详情、重置的信息的操作。服务类型管理和家政业务管理对整个平台的基本服务数据进行管理；服务预订管理对预定的订单的状态进行审核、跟踪支付、生成服务记录。服务记录管理和服务评述管理对服务记录及其完成订单后的反馈进行监督。家政新闻模块管理对新闻的发布、类别维护、内容维护。
管理员角色用例图如图3-2所示。
图3-2管理员用例图
服务员在平台上管理自己发布的家政服务项目，能够查看、修改自己的服务信息，处理服务预定是他们的重要工作，服务员要查看指派给自己的预订单据，审核单据，检查付款状况，期间可以更改预定信息。服务结束后要由服务员核实并形成服务记录表，里面的服务内容包括：服务项目、类别、服务人员、金额、结束时间等内容。
服务人员角色用例图如图3-3所示。
图3-3服务人员用例图
3.2 可行性分析
（1）技术可行性：系统基于B/S模式，前后端分离式的开发方式具有广泛的工业应用基础，后台选用Spring Boot框架，可以减少繁琐的配置过程，快速实现一个RESTful风格API的服务提供者，前端界面用Vue.js框架实现，具有良好的响应式页面特点，适用于实时性强的数据更新显示，数据库采用的是关系型数据库MySQL用来保存结构化的数据信息。开发人员掌握Java web技术和JavaScript相关知识，可独立编写代码，系统部署在一个本地服务器环境上，主要的硬件设备就是一台普通配置的电脑，可能存在的安全威胁就是用户的隐私信息泄漏问题，可通过增加权限认证模块与参数拦截的方式进行防范，所以系统从技术的角度来说是可行的。
（2）操作可行性：系统界面布局采用普通的web应用程序布局方式，层次分明易于查找，居民用户使用浏览器进行操作，流程简单明确，查看服务--预约--确认--评价一目了然，服务者和管理者也都是通过web进行自己相关事务的管理，之前线下的联系协调变为线上程序化的流程处理，该系统上线之后应能正常运行，平时只需要定时做数据备份和日志查看之类的维护工作。这些维护工作对于掌握基本计算机技术的人来说都不难学会，不需要太复杂的培训学习过程。所以系统从操作上来看具有可行性。
（3）经济可行性：项目开发过程中费用主要用于人力资源上，主要是系统的分析设计、编程以及调试等工作。开发所需要的硬件条件基于现有的个人电脑。开发工具IntelliJ IDEA、MySQL等都可以采用免费开源的版本。项目上线及试运营无需花费过多资金租赁云服务器或专用服务器，借助学校和实验室内部的局域网环境即可构建。完成系统开发后可以提高家庭服务业供需匹配的管理水平，该系统的应用价值远远大于少量的开发成本。因此，该系统从经济角度来讲是可行的。
第四章 系统设计
4.1 系统架构设计
家政服务平台以模块化的思想搭建，各模块分工明确。前端UI层使用Vue.js框架编写，主要承担服务信息显示以及与用户的交互逻辑。用户的操作指令以HTTP的形式交给后台的服务端，后台服务端使用的是Spring Boot框架。服务逻辑主要集中在Service层，主要处理从前端接收请求，完成诸如审核、支付状态更新等具体服务操作以及一些统计计算等工作。在进行数据处理的过程中涉及的数据传输都借助于MySQL数据库进行持久化，服务信息，订单，评论等主要业务数据都保存在该数据库当中。这样的层次结构保证了数据流向的一致性和逻辑的明了性。前端渲染、后端计算和数据存储之间通过定义好的接口相互协作，形成了整个应用程序的运作链路。总体架构图描述了整个应用程序的数据流转路线，系统总体架构如下图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 数据库设计
数据库设计是软件系统构建的核心环节，它为数据的存储、检索与管理提供了结构化基础。本系统采用关系型数据库模型，利用其严格的表结构定义与丰富的关系约束来组织数据。关系模型通过实体与联系将现实业务抽象为二维表，有效避免了数据冗余并保证了数据的一致性21。规范化设计原则指导了表结构分解，使得每个数据项依赖其主键22。在平台中，数据库承担着存储用户信息、服务目录、交易订单与交互评价等核心业务数据的职责。通过定义主键、外键约束以及各类索引，数据库确保了数据的实体完整性与参照完整性，为上层应用提供了可靠、高效的数据访问服务。
用户实体主要由用户id,用户名,手机号，密码等属性构成。实体属性图如图4-8所示。
图4-8用户实体属性图
居民用户实体主要是由居民用户id、居民姓名、居民手机、审核状态属性组成。实体属性图如下图4-9所示。
图4-9居民用户实体属性图
服务人员实体主要有服务人员id、人员工号、人员姓名、审核状态等属性。实体属性图如图4-10所示。
图4-10服务人员实体属性图
服务类别实体主要有服务类别id，服务种类，创建日期等属性。实体属性关系图如下图4-11所示。
图4-11服务分类实体属性图
家政服务实体主要有家政服务id,服务项目，服务类型，服务价格等属性。实体属性图见图4-12。
图4-12家政服务实体属性图
服务预约实体主要包含了服务预约标识符，服务项目，服务类型，审批状态等属性。实体属性图如图4-13所示。
图4-13服务预约实体属性图
服务记录实体主要是由服务记录id，服务项目，服务类型，完成时间这几个属性构成。实体属性图如图4-14所示。
图4-14服务记录实体属性图
服务评价实体主要有服务评价ID，服务项目，评价等级，评价内容等属性。实体属性图如图4-15所示。
图4-15服务评价实体属性图
文章实体主要包含文章id，标题，文章类型，封面图片等属性。实体属性图如下图4-16所示。
图4-16文章实体属性图 
图4-17系统E-R图
4.4.1 数据库表设计
数用户表主要用于存放整个系统的全部用户账号基本信息。主要包括用户id、用户名、手机号码、密码等等字段。如表4-1所示。
表4-1用户表系统实现
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | user_id | int | 11 | 是 | 是 | 用户ID |
| 2 | username | varchar | 16 | 是 | 否 | 用户名 |
| 3 | phone | varchar | 11 | 否 | 否 | 手机号码 |
| 4 | password | varchar | 64 | 是 | 否 | 密码 |
| 5 | avatar | varchar | 255 | 否 | 否 | 头像地址 |
| 6 | create_time | timestamp | - | 是 | 否 |
居民用户表主要是用于存放居民用户的身份信息详情。主要包含居民用户id，居民姓名，居民电话，审核状态等字段。如表4-2所示。
表4-2居民用户表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | resuser_ident_user_id | int | 11 | 是 | 是 | 居民用户ID |
| 2 | name_of_resuser_ident | varchar | 64 | 否 | 否 | 居民姓名 |
| 3 | resuser_ident_mobile_phone | varchar | 16 | 是 | 否 | 居民手机 |
| 4 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 5 | user_id | int | 11 | 是 | 否 | 用户ID |
| 6 | create_time | datetime | - | 是 | 否 |
服务员表主要是用来存储家政服务员的相关信息。主要包含服务员id，人员工号、人员姓名等字段，以及审核状态字段。如表4-3所示。
表4-3服务人员表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | service_personnel_id | int | 11 | 是 | 是 | 服务人员ID |
| 2 | personnel_work_number | varchar | 64 | 是 | 否 | 人员工号 |
| 3 | name_of_personnel | varchar | 64 | 否 | 否 | 人员姓名 |
| 4 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 5 | user_id | int | 11 | 是 | 否 | 用户ID |
| 6 | create_time | datetime | - | 是 | 否 |
服务分类表主要是用于家政服务类型的划分。包括服务分类id，服务类型，创建时间等属性，如表4-4所示。
表4-4服务分类表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | service_class_nameification_id | int | 11 | 是 | 是 | 服务分类ID |
| 2 | service_type | varchar | 64 | 否 | 否 | 服务类型 |
| 3 | create_time | datetime | - | 是 | 否 |
家政服务表主要为了记录平台发布上线的家政服务项目信息。包括了家政服务id、服务项目、服务类型、服务价格等相关字段。如下表4-5所示。
表4-5家政服务表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | housekeeping_service_id | int | 11 | 是 | 是 | 家政服务ID |
| 2 | service_item | varchar | 64 | 否 | 否 | 服务项目 |
| 3 | service_type | varchar | 64 | 否 | 否 | 服务类型 |
| 4 | service_personnel | int | 11 | 否 | 否 | 服务人员 |
| 5 | service_price | double | - | 否 | 否 | 服务价格 |
| 6 | service_picture | varchar | 255 | 否 | 否 | 服务图片 |
| 7 | service_content | text | 65535 | 否 | 否 | 服务内容 |
| 8 | create_time | datetime | - | 是 | 否 |
服务预约单主要的作用是用于记录居民用户的提交的服务预约请求单。包含服务预约编号、服务内容、服务类别、审批情况等信息。如表4-6所示。
表4-6服务预约表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | service_reservation_id | int | 11 | 是 | 是 | 服务预约ID |
| 2 | service_item | varchar | 64 | 否 | 否 | 服务项目 |
| 3 | service_type | varchar | 64 | 否 | 否 | 服务类型 |
| 4 | service_personnel | int | 11 | 否 | 否 | 服务人员 |
| 5 | service_price | double | - | 否 | 否 | 服务价格 |
| 6 | resuser_ident_user | int | 11 | 否 | 否 | 居民用户 |
| 7 | appointment_time | datetime | - | 否 | 否 | 预约时间 |
| 8 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 9 | pay_state | varchar | 16 | 是 | 否 | 支付状态 |
| 10 | create_time | datetime | - | 是 | 否 |
服务记录表主要是用于存放完成的服务相关记录信息。包括有服务记录id、服务项目、服务类型、完成时间等属性。如下表4-7所示：
表4-7服务记录表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | service_records_id | int | 11 | 是 | 是 | 服务记录ID |
| 2 | service_item | varchar | 64 | 否 | 否 | 服务项目 |
| 3 | service_type | varchar | 64 | 否 | 否 | 服务类型 |
| 4 | service_personnel | int | 11 | 否 | 否 | 服务人员 |
| 5 | service_price | double | - | 否 | 否 | 服务价格 |
| 6 | resuser_ident_user | int | 11 | 否 | 否 | 居民用户 |
| 7 | appointment_time | datetime | - | 否 | 否 | 预约时间 |
| 8 | completion_time | datetime | - | 否 | 否 | 完成时间 |
| 9 | service_records | text | 65535 | 否 | 否 | 服务记录内容 |
| 10 | create_time | datetime | - | 是 | 否 |
服务评价表主要用于存放社区居民对于已完成的服务进行评价的相关信息数据。主要包含服务评价id、服务事项、评价星级、评价详情等字段。如下表4-8所示。
表4-8服务评价表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | service_evaluation_id | int | 11 | 是 | 是 | 服务评价ID |
| 2 | service_item | varchar | 64 | 否 | 否 | 服务项目 |
| 3 | service_type | varchar | 64 | 否 | 否 | 服务类型 |
| 4 | service_personnel | int | 11 | 否 | 否 | 服务人员 |
| 5 | service_price | double | - | 否 | 否 | 服务价格 |
| 6 | resuser_ident_user | int | 11 | 否 | 否 | 居民用户 |
| 7 | completion_time | datetime | - | 否 | 否 | 完成时间 |
| 8 | evaluation_grade | varchar | 64 | 否 | 否 | 评价等级 |
| 9 | evaluation_content | text | 65535 | 否 | 否 | 评价内容 |
| 10 | create_time | datetime | - | 是 | 否 |
文章表主要用于保存平台上发布的一些家政新闻类的文章。主要有文章id、标题、文章分类、封面图等属性。如下表4-9所示。
表4-9文章表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | article_id | mediumint | 8 | 是 | 是 | 文章id |
| 2 | title | varchar | 125 | 是 | 否 | 标题 |
| 3 | type | varchar | 64 | 是 | 否 | 文章分类 |
| 4 | img | varchar | 255 | 否 | 否 | 封面图 |
| 5 | description | text | 65535 | 否 | 否 | 文章描述 |
| 6 | create_time | timestamp | - | 是 | 否 |
第五章 系统实现
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.2 管理员功能实现
5.2.1 后台首页功能实现
该界面是管理员把控平台运行情况的整体视屏。首页实时显示各项重要指标统计数据，包括平台总浏览量、各类型资源数量等等。统计图表直观呈现了家政服务、预约服务、用户打分等主要模块的实时信息。管理员可由此对平台活跃程度以及业务活力一目了然，便于进行判断分析。后台首页面板如下图5-6：
编辑 图5-6后台首页界面
5.2.2 系统用户管理功能实现
管理员在此模块中对网站的所有账号进行统一管理。用户列表明确划分出管理员、居民用户用户和服务人员三种角色，管理员可执行搜索操作查找某一具体用户并能查看其账号信息，系统提供新增用户账号或者注销坏账号的功能，对于已注册用户的资料，管理员可以执行清空处理，比如清空密码或者更新状态等。系统用户管理页面如图5-7所示：
图5-7系统用户管理界面
5.2.3 服务分类管理功能实现
该功能用于维护家庭服务平台的服务分类体系，管理人员可以通过服务分类列表页面查看到目前所有的分类项，当有新的类型需要增加的时候，点击增加按钮跳转到对应的表单填写页面进行增加操作，同时管理人员还可以对具体的分类项进行检索并可以查看详细信息，对一些不再使用的分类项，管理员也可以将其在列表内删除掉，使分类结构一目了然。服务分类管理界面见图5-8所示。
图5-8服务分类管理界面
5.2.4 家政服务管理功能实现
管理员在此对所有上线的服务进行管理。页面展示的是每一个服务的服务项目名称和服务类型以及所对应的服务员工。管理员根据查询和重置按钮来对服务进行筛选。新增服务要填写详细的关于该服务的服务信息表单。点击详情可显示关于这个服务的更详细的内容及其和用户的交互情况。管理员对服务的信息进行管理和审核。家政服务管理界面见图5-9。
图5-9家政服务管理界面
5.2.5 服务预约管理功能实现
模块集对全部居民用户上报的预约订单进行处理。管理人员可以通过筛选条件来查找订单，浏览每一个预约的信息详情，对未审批的订单进行审核操作来确认是否通过，系统会监测订单的缴费情况，管理人员可以对订单进行备注或者创建相关的服务工单，针对一些无效、违反规定的预约管理人员有权将订单删除，服务预约管理页面如下图5-10所示：
图5-10服务预约管理界面
5.2.6 服务记录管理功能实现
管理员在这里模块监管所有的已经结束的服务记录，记录清单显示服务的种类以及与之相关的预约单编号。管理员可以通过查询功能寻找对应的服务记录，点击详尽了解该次服务的具体内容比如服务的人员，服务结束的时间等等。为了保证数据的真实有效，管理员可以对有误或者多余的记录进行删除操作。服务记录管理界面如图5-11所示。
图5-11服务记录管理界面
5.2.7 服务评价管理功能实现
该模块主要实现对居民所发布的所有服务评进行管理。管理员查阅评列表，掌握社区工作者的声誉及服务水平。利用查询、重新输入等功能对指定的服务评价进行筛选，点击详细可以阅读具体的服务评价星级及评价用语，对于不合理、不真实的评价信息，管理员在审核确认之后可以进行删除的操作，使服务的考评更加公平合理等。服务评价管理界面如图5-12所示。
图5-12服务评价管理界面
5.2.8 家政新闻功能实现
管理员经由此模块担任网站信息发布员及编辑的角色，在新闻列表中显示当前发布的所有文章标题、类型及发布时间，管理员可在此发布新的家政新闻文章并修改现有新闻信息，经搜索快速查找所需文章，了解其详述及相关读者留言，对一些已经到期或者是不符合规范的文章予以清除，家政新闻页面如图5-13所示。
图5-13家政新闻界面
5.3 服务人员功能实现
5.3.1 家政服务功能实现
服务员在此管理其所拥有的家政服务。页面展示了其拥有的一切家政服务，并展示所拥有的服务的服务名称和服务种类。服务员能够找到其下所拥有的具体服务。在编辑里对服务的内容、价格或是可接受的时间进行更改，而重置是清空查询条件的意思。点击详细的链接可看到这个服务具体的信息还有顾客评论。家政服务界面如图5-14所示。
图5-14家政服务界面
5.3.2 服务预约功能实现
模块是为服务人员处理订单的操作平台，列表显示的是分派到这个人员的所有预约，明确标识审核情况、支付情况；服务人员通过查询功能筛选出待处理订单；对于新的预约，服务人员需要审核预约的合理性并作出通过或者拒绝的选择，在服务进行之前，服务人员还可以对预约的信息备注进行修改。服务预约页面如图5-15所示。
图5-15服务预约界面
5.3.3 服务记录功能实现
服务完成后，服务人员需要在该模块进行确认并形成服务单据。网页相关联已经审批的预约订单。服务人员录入此次服务实际结束的时间，可以对服务过程的内容做进一步登记记录。系统根据预约和服务人员填写的信息自动生成由服务项目、类别、金额等组成的正式的服务记录。该服务记录是进行结算和服务满意度打分的依据。服务单记录页面如下图5-16所示。
图5-16服务记录界面
第六章 系统测试
6.1 测试目的
测试目标主要是通过对系统进行测试验证，从而使得软件或者系统满足设计要求以及功能标准，可以长期安全稳定地进行运行。从具体的层面来说其测试的目标就是为了找出软件可能存在的问题隐患，并对其进行修复，优化增强系统质量及性能，降低实际应用中出现的问题概率。通过对不同类型的测试方法进行运用，例如单测，联调，功能测试，性能测试等一系列方式来对软件是否可以在不同的环境中正常运行并正常使用。同时测试也起到了验证系统安全性的效果，避免出现信息泄漏或者是系统崩溃等风险事故，通过对各个层面进行充分的测试，使得软件的流畅度得到提升，提高了客户的满意程度以及减少了后期的维护费用23。所以测试的过程既是软件开发的一部分，又是保证软件产品质量与客户需求的重要环节。
6.2 测试方法
测试技术是对软件或者系统进行质量保证的一个重要途径，在很多情况下依据测试的目的及要求不同，采取不同的测试方式。常用的测试技术有黑盒测试、白盒测试、灰盒测试、回归测试和性能测试。
黑箱测试关心的是软件的功能表现，而不是软件的内部组成。测试人员输入数据并查看输出的数据结果，确定程序是否满足规格要求，适合做功能测试和接口测试，白箱测试检查的是程序内部的组成状况，测试工程师通过阅读源代码来进行细致的逻辑结构、控制流及数据流的检测，代码中的每一条路径以及每一段代码都得到了充分的测试，有助于找出隐藏的逻辑缺陷或者性能问题。灰盒测试综合了黑盒测试和白盒测试的优点，测试工程师部分理解系统的内部逻辑结构，在一定程度上既注重功能执行又注意安全性与集成性。
回归测试是指软件被修改或更新之后再次去测试之前的已经完成的功能，新版本没有增加新的错误或问题。性能测试是对系统在不同的负载下及不同的压力情况下系统的表现如何，测试它的响应速度、并发处理的能力等等一系列重要的性能参数。
应用这些测试技术能够检测并提高软件的功能性，可靠性以及稳定性，最后提供的系统符合用户的需求，提高了软件质量。
6.3 测试用例
服务预约模块测试主要检查自居民进行预约直到产生订单这一系列完整过程，测试主要检查预约信息填写无误，时间选取合理及订单状态初始是否正常。通过对不同的服务种类和服务预约时间等不同排列组合的方式，对系统后台数据的可靠性和前端后端数据同步一致性进行了验证。服务预约测试见表6-1。
表6-1服务预约测试用例表
| 序号 | 测试功能 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| 1 | 预约信息提交 | 选择有效服务项目，填写完整的预约信息并提交。 | 系统成功创建预约订单，状态显示为待审核，并生成唯一订单号。 | 符合预期 |
| 2 | 预约信息校验 | 提交预约时不选择服务项目或必填信息缺失。 | 系统提示信息不完整，阻止表单提交，高亮显示必填项。 | 符合预期 |
| 3 | 服务类型与项目联动 | 先选择一种服务类型，再查看可选的服务项目列表。 | 服务项目列表动态更新，仅显示属于所选类型的项目。 | 符合预期 |
服务评价模块测试用于验证评价过程能否顺利进行以及相关联的数据是否能成功建立联系。测试主要是为了检验已经完成的服务事项能否被成功识别从而进行评价，对评价等级的提交和保存等功能能否实现，服务评价信息是否能够与相应的服务和人员之间形成关联关系并得到保持。服务评价测试如下表6-2所示。
表6-2服务评价测试用例表
| 序号 | 测试功能 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| 1 | 评价提交 | 对已完成的服务记录选择评价等级并填写内容后提交。 | 评价信息成功保存，并在服务人员详情和该服务历史评价中可见。 | 符合预期 |
| 2 | 评价限制验证 | 尝试对未完成或已评价过的服务记录再次提交评价。 | 系统阻止评价提交，并提示"无法评价"或"已评价"。 | 符合预期 |
| 3 | 评价内容边界 | 提交极短或极长的评价内容文本。 | 系统能正常处理并保存，前端显示无异常，内容完整。 | 符合预期 |
后台首页统计模块测试主要关注数据汇总统计及可视化结果正确性，测试验证了对访问次数、服务申请数、点评次数等各项关键业务指标统计数据计算规则是否合理，数据仪表盘能否实时动态地呈现系统当前的业务处理情况，为管理人员进行管理决策给予有力的支持。后台首页数据统计测试如表6-3所示。
表6-3后台首页统计测试用例表
| 序号 | 测试功能 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| 1 | 核心指标统计 | 在产生新的预约、评价等业务数据后，刷新后台首页。 | 首页各项统计图表和数据面板的数字实时更新，与数据库记录一致。 | 符合预期 |
| 2 | 数据范围筛选 | 检查统计图表是否支持按时间范围（如本日、本周）进行筛选查看。 | 更换不同的时间段过滤器，图中显示的数据也将发生改变，相对应所选取的时间段。 | 符合预期 |
| 3 | 统计数据准确性 | 将后台首页显示的某项统计总数与数据库聚合查询结果进行比对。 | 两者显示的数值完全一致，无统计误差。 | 符合预期 |
系统用户管理模块测试针对不同的角色用户的账号添加删除更新查看以及状态管控等功能进行测试。测试验证管理员是否可以正确查看指定账户、查看详情等信息，进行添加新用户账户或者暂停使用账户，同时保证权限设置和身份标签正确无误。系统用户管理测试如下表6-4所示。
表6-4系统用户管理测试用例表
| 序号 | 测试功能 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| 1 | 用户信息查询与详情查看 | 在用户管理列表中使用查询条件筛选，并点击某用户详情。 | 列表正常显示满足条件的用户，详情页完整展示该用户的注册信息及角色。 | 符合预期 |
| 2 | 新增用户账户 | 通过添加功能，填写新用户信息并指定角色后保存。 | 新用户账号建立完成，可以利用此账号进行登录系统并且具有相应的角色权利。 | 符合预期 |
| 3 | 用户角色与权限验证 | 以新创建的不同角色账户登录系统。 | 登录之后显示的菜单、能够使用的功能模块完全与其身份相匹配，无违规访问操作。 | 符合预期 |
服务预约审核子模块测试验证管理员审批辖区居民的服务预约申请单。测试重点为审批行为触发的订单状态变化，验证审核通过/驳回之后，订单状态及关联的通知消息、后继环节（如允许付款等）是否按照逻辑进行流转。服务预约审核子模块测试见表6-5。
表6-5服务预约审核测试用例表
| 序号 | 测试功能 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| 1 | 审核通过操作 | 管理员对一条"待审核"状态的预约订单执行"通过"操作。 | 此订单的状态就变成了'已审批'，相关联的居民用户方会收到消息提示可以缴费了。 | 符合预期 |
| 2 | 审核拒绝操作 | 管理员对订单执行"拒绝"操作，并填写拒绝理由。 | 订单状态变为"已拒绝"，居民用户端收到包含拒绝理由的通知。 | 符合预期 |
| 3 | 批量审核操作 | 管理员同时勾选多条"待审核"订单进行批量通过或拒绝操作。 | 所有被选的订单的状态都进行批量更新，相对应的信息通知到相关的居民用户客户。 | 符合预期 |
服务档案管理模块测试主要针对服务结束后档案建立以及对档案的管理情况，测试通过服务人员的服务完成确认、填写档案后，在管理列表中是否可以正确找到并浏览该档案信息，同时也测试了管理员对于档案的删除等一系列管理功能是否可行。服务档案管理测试见表6-6。
表6-6服务记录管理测试用例表
| 序号 | 测试功能 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| 1 | 记录生成与查询 | 服务员提供完服务上交了记录之后，管理者可以在记录管理列表中根据相关的条件进行检索。 | 新生成的服务记录出现在查询结果中，详情信息完整准确。 | 符合预期 |
| 2 | 记录删除管理 | 管理员选择一条服务记录执行删除操作。 | 这个服务信息就会从管理列表中删除，同时也不再会在居民与服务人员关联视图显示。 | 符合预期 |
| 3 | 记录信息编辑 | 服务人员在生成记录后，对记录中的非关键信息进行补充编辑。 | 编辑后的信息成功保存，并在所有相关视图同步更新。 | 符合预期 |
服务评价管理模块测试用于保证管理者可以及时监管到平台中客户对于商家的服务评价。重点关注评价列表查询、筛选功能，详细信息显示情况以及删除操作是否可成功将对应的评论信息处理掉，保障评价氛围的真实性和公平公正性。服务评价管理测试如表6-7所示。
表6-7服务评价管理测试用例表
| 序号 | 测试功能 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| 1 | 评价内容审查 | 管理员通过查询功能定位特定服务或人员的评价，并查看评价详情。 | 系统正确列举出相应评价，在详情页显示完整的评分情况，评论内容以及时间。 | 符合预期 |
| 2 | 不当评价处理 | 管理员对一条被判定为不当的评价执行删除操作。 | 此条评论会被从公开榜单和详情页里删除掉，不影响对服务人员的整体评分。 | 符合预期 |
| 3 | 多维度筛选功能 | 管理人员综合运用服务项、评分星级、时间段等多种条件对信息进行检索。 | 列表展示的评价结果精确匹配所有设定的筛选条件。 | 符合预期 |
测试结论
本次系统功能测试针对平台主要业务流程进行，包括服务预定、服务评分、后台报表汇总、用户账号管理、预定单审核、服务记录管理以及评分审核等功能模块共七个部分，在功能测试中严格按照事先设定好的测试用例来进行，逐一对各个模块的业务逻辑及功能进行了测试。测试结果显示：服务预订流程无缺漏，并且能够对输入的信息进行校验并能正常更新服务订单状态；服务评分提交正常并且能够建立对应的关系以及相应的限制措施。后台报表汇总模块能够实时的计算并且准确地展示出核心经营指标。系统用户管理完善，做到了对各类别账号的精确管理。预定审核流程推动了订单的状态变化和通知的下发。服务记录的产生和查看查询管理都达到预期的要求。评分审核模块可以提供多种角度的审核和处理方式。所有测试用例执行的结果均满足要求，测试通过率百分之一百，系统主要功能模块工作稳定，逻辑实现准确。