1绪论
1.1研究背景与意义
当前家电保有量持续攀升，家庭平均拥有家电数量已超过十台。大量电器进入老化周期，故障发生频率显著上升。传统维修服务模式依赖人工经验判断故障原因，缺乏数据支撑的科学决策机制。维修人员上门后往往需要多次往返取配件，单次故障平均处理时间长达三至五天。用户对维修过程缺乏透明化监督渠道，服务结束后也难以对维修质量进行有效追溯1。这种粗放型服务模式与用户日益增长的高效、透明、可预期的服务需求之间形成了明显落差。家电故障预测系统的引入能够改变这一局面。系统通过收集设备运行参数，利用数据分析技术识别异常模式，在故障发生前向用户发送预警信息。这种预测性维护策略将传统的被动响应模式转变为主动干预模式。可视化模块将复杂的数据分析结果转化为直观的图表展示，降低管理者的决策门槛2。维修企业能够依据系统提供的故障案例库快速定位问题，减少现场诊断时间。用户在系统内可以查看完整的维修历史与费用明细，形成对服务过程的全面掌控3。该系统推动了家电后服务市场从经验驱动向数据驱动的转型。
研究的意义主要表现在两个方面，即服务效率的提高和服务资源的合理配置。系统把售后申请、任务分派、维修记载、评价回馈纳入同一个数据链条之中，排除了以往纸质单据流转时信息滞后或者丢失的危险。管理员使用数据概览模块可以对各个售后网点的任务负荷进行实时监控，从而达到维修资源的动态调配的目的。普通用户在系统中完成设备信息绑定之后，每次报修都不需要再输入基础资料，大大缩减了申报时间。故障案例库的创建使得维修人员可以参照以往的解决办法来处理类似的问题，从而减少试错的成本。系统中积累下来的运行数据和维修记录，给家电企业改善产品设计赋予了真实的参照。某些型号的压缩机故障率偏高，可以反馈到生产端进行质量改善。该系统可以为其他垂直领域服务的数字化改造提供可以重复使用的技术框架和业务模式。从社会效益的角度来讲，透明的维修过程和标准化的定价制度可以有效地打击维修市场的不良现象，保障消费者的合法权益。
1.2国内外研究现状
国内家电后服务市场的信息化进程经历了从门户网站到移动应用再到智能平台的演进轨迹。早期阶段，家电企业主要建设品牌官网，提供维修网点查询与产品说明书下载服务。这种单向信息发布模式无法解决用户与服务商之间的实时沟通需求。垂直家电论坛兴起后，用户开始在社区内分享维修经验与投诉不良商家，形成了初步的互助信息网络。这类平台的权威性与专业性不足，信息质量参差不齐。移动互联网时代涌现出一批第三方维修平台，提供在线下单、价格估算与进度跟踪功能。这些平台在服务标准化方面取得了一定进展，但数据积累深度有限，尚未形成有效的故障预测能力4。杨健等人基于Spark构建的电影推荐系统为家电领域的个性化服务提供了技术启发，数据处理架构可以迁移至故障模式识别场景5。闫兴栋等人在电力设备监测领域的研究表明，远程状态监测与故障预测系统的结合能够显著提升设备运维效率，这一思路同样适用于家电管理场景6。张雪等人关于铁路货车轮轴故障预测系统的研究展示了预测模型在实际工业环境中的应用路径7。国内研究在数据采集与基础展示层面已较为成熟，但预测算法与业务系统的深度整合仍处于探索阶段。
国外在家电故障预测领域起步较早，技术路线侧重于传感器数据采集与机器学习模型构建。早期研究主要针对工业设备，将振动分析、温度监测与电流检测等技术应用于故障诊断。消费电子领域的智能家居浪潮推动了预测性维护技术向家用电器迁移8。Feng等人提出的电力系统故障诊断方法通过规则知识嵌入提升了预警准确性，这种混合智能策略对家电故障预测具有参考价值9。Lutong等人开发的人工智能专家系统展示了电动汽车充电故障诊断的技术可行性，其推理机制可以适配家电维修场景10。Zhang等人设计的模糊预测器为处理传感器数据中的不确定性提供了解决方案，家电运行环境复杂多变，该方法具有实际应用潜力11。Zheng等人将知识图谱与长短期记忆网络结合用于继电保护风险识别，这种多技术融合思路启示家电预测系统应整合结构化案例库与非结构化文本记录12。国外研究在算法层面较为深入，但面向终端消费者的完整服务平台相对少见。学术成果与商业应用之间存在转化断层，多数研究停留在实验室验证阶段，缺乏大规模实际部署的检验。
1.3主要研究内容
本文的核心工作是设计与实现一个面向家电维修服务场景的故障预测管理系统。研究从需求分析入手，识别普通用户、售后运维人员与系统管理员三类角色的功能诉求，形成完整的用例模型。系统架构设计采用前后端分离模式，后端基于Flask框架构建RESTful API，前端使用Vue框架开发单页面应用，MySQL数据库承担数据持久化任务。Spark技术被引入用于处理设备上报的运行数据，通过分析历史故障模式建立预警规则。功能模块涵盖用户认证、家电设备绑定、运行状态监测、故障预警推送、报修订单处理、维修记录追踪、设备模型维护与平台数据可视化展示。数据库设计遵循第三范式，确保核心业务表之间形成清晰的外键约束关系。PyCharm作为集成开发环境，提供代码编写、调试与版本管理支持。系统测试阶段采用黑盒测试方法验证各功能模块的正确性，重点关注异常输入处理与边界条件校验。本研究的侧重点在于业务逻辑的完整闭环与预测功能的实际可用性，而非复杂算法的创新。最终交付物包括可运行的系统原型、数据库设计文档、测试报告与用户操作手册。整体技术路径遵循敏捷开发思想，采用迭代方式逐步完善各功能模块。
2相关技术介绍
2.1Flask框架
Flask框架采用微核心设计理念，仅提供路由分发、请求响应与模板渲染等基础功能。框架内部依赖Werkzeug工具库处理WSGI协议层面的通信细节，Jinja2模板引擎负责动态页面生成。开发者可以根据项目需求选择合适的扩展组件，这种模块化设计使应用保持轻量且易于维护13。在构建家电故障预测系统的后端服务时，Flask的路由系统将URL映射到对应的视图函数。接收到家电信息查询请求后，视图函数提取请求参数，调用业务逻辑层完成数据检索，最终将结果集转换为JSON格式返回。Flask的请求钩子机制允许在请求处理前后执行特定代码，用户认证拦截器可以放置于此处进行令牌有效性校验。蓝图功能用于组织大型应用的路由结构，不同业务模块的用户管理、设备管理、订单处理等可以分散到独立的蓝图文件中。
2.2Vue框架
Vue框架使用渐进式的JavaScript架构，根据项目的复杂程度来决定使用程度。核心库主要处理视图层的渲染工作，用声明式的渲染语法把数据状态映射成DOM结构。框架内部使用虚拟DOM来减少直接操作真实DOM造成的性能开销。当数据发生改变的时候，Vue就会创建一个新的虚拟DOM树并和旧的虚拟DOM树做差异比较，只对变化的部分进行更新到实际的页面上。响应式数据绑定机制是Vue的另一个关键特征，组件状态被包装为响应式对象，任何属性的读取或修改都会被拦截并触发依赖收集与更新通知14。在构建家电故障预测系统的前端界面时，Vue Router负责管理页面路由，实现单页面应用内的视图切换。用户从设备信息列表跳转到运行状态详情页，路由系统会根据路径匹配对应的组件进行渲染。Vuex状态管理库集中存储跨组件共享的数据，用户登录凭证与权限标识存放在全局仓库中，各组件通过派发动作与提交变更的方式修改状态。组件化开发模式将界面拆分为可复用的独立单元，售后申请表单组件可以在多个页面中重复使用，减少了重复编码工作。
2.3MySQL数据库技术
MySQL数据库是一种关系型数据库管理系统，数据以二维表格形式组织存储。结构化查询语言被用来执行数据的插入、更新、删除与检索操作。数据库内核包含存储引擎层，InnoDB是默认的事务型存储引擎，支持行级锁定与外键约束15。当执行数据修改操作的时候，InnoDB会先把修改写入日志缓冲区，然后再把数据页刷新到磁盘。预写日志机制可以保证事务持久性，即使系统发生故障而崩溃，在重启后也可以通过重放日志的方式恢复已经提交的事务。查询优化器会分析SQL语句，比较各种执行路径的成本，选择最佳的索引和连接策略来完成数据访问。在家电故障预测系统中，用户表和设备信息表通过外键关联，查询某个用户绑定的所有设备时，数据库会执行等值连接操作把两张表的相关行组合在一起。索引创建在经常用作查询条件的字段上，家电类型、故障类型两个字段被设置为索引列，加快了分类检索的速度。
2.4Spark技术
Spark技术提供了一种统一的数据处理引擎，适用于批处理、流计算与交互式分析等多种场景。该技术的核心数据结构是弹性分布式数据集，一种分布在集群节点内存中的只读对象集合。数据集通过粗粒度变换操作构建出有向无环图执行计划，调度器会根据数据本地性将计算任务分发到最适合的节点执行16。延迟计算机制使Spark可以对整个计算过程进行优化，只有当动作操作被调用的时候才会真正执行计算。家电故障预测系统使用Spark定时处理设备上传的运行参数，从中找出故障发生前的特征模式。当故障预警模块提出分析任务之后，Spark就会从MySQL数据库里提取运行状况记录并展开数据清洗以及特征工程操作。缺失值填充、异常值剔除、归一化处理等工作做完之后，就用分类算法来区分正常和异常状态。计算结果用故障评分的形式写入到数据库中，供前端预警页面查询显示。Spark SQL组件可以使得开发人员用标准的SQL语句来操作分布式的数据集，从而降低从传统的数据库迁移到它的时候的技术难度。
3系统分析
3.1可行性分析
3.1.1技术可行性
延迟计算机制使Spark可以对整个计算过程进行优化，只有当动作操作被调用的时候才会真正执行计算。家电故障预测系统使用Spark定时处理设备上传的运行参数，从中找出故障发生前的特征模式。当故障预警模块提出分析任务之后，Spark就会从MySQL数据库里提取运行状况记录并展开数据清洗以及特征工程操作。缺失值填充、异常值剔除、归一化处理等工作做完之后，就用分类算法来区分正常和异常状态。计算结果用故障评分的形式写入到数据库中，供前端预警页面查询显示。Spark SQL组件可以使得开发人员用标准的SQL语句来操作分布式的数据集，从而降低从传统的数据库迁移到它的时候的技术难度。
3.1.2经济可行性
系统开发阶段的人力成本主要集中在程序编码与测试验证环节，一名开发人员可在三个月内完成全部功能实现。开发工具与软件环境均采用开源或社区版本，Spark、Flask、Vue与MySQL的相关依赖库遵循Apache或MIT协议，可免费用于商业及学术项目。PyCharm提供免费的社区版本，足以满足开发需求。运行阶段，系统可以部署在单台云服务器上，月租成本控制在可接受范围内。后期维护工作主要包括数据备份与简单故障排查，不需要组建专门的技术团队。项目建设的经济投入处于合理区间。
3.1.3操作可行性
系统界面设计遵循通用Web应用的操作习惯，顶部导航栏集中展示主要功能入口，侧边菜单按照角色权限动态显示可用模块。普通用户完成登录后，可以在首页快速绑定家电设备或发起售后申请。表单页面采用下拉选择与输入框组合的方式收集信息，减少了用户手动输入的工作量。售后运维人员进入报修订单管理页面，系统自动展示待处理与进行中的工单。管理员通过平台数据分析页面获取关键业务指标，不需要编写任何查询语句。新用户在短时间浏览后即可掌握基本操作流程，学习成本较低。各功能模块的操作路径符合业务常识。
3.2功能需求分析
3.2.1普通用户功能需求
普通用户通过账号密码完成身份认证后进入系统主页。用户可以浏览网站公告、新闻资讯等有关家电维修政策和技术动态的网页。家电信息模块可以根据品牌、型号或者出厂年份对产品进行筛选查询，查看具体产品的参数和性能指标。故障案例库可提供常见的故障诊断信息及解决办法，用户可直接查找到类似故障的处理方式。设备信息管理功能可以实现用户对家庭中实际拥有的家电设备进行添加，保存购买日期和型号规格。运行状态查询模块可以显示已经绑定的设备的实时运行参数，使用户了解设备目前的工作状况。故障预警页面收到系统推送的风险提示，设备运行数据出现异常时，预警信息会立即显示出来。售后申请功能要求用户输入故障现象及联系信息，系统自动生成唯一的申请编号供以后跟踪使用。维修记录查询可以让用户了解过去的维修情况，即故障原因、维修费用以及维修时间。评价信息管理可以对已经完成的维修服务进行打分和评价。密码修改功能保证账户的安全，用户可以定时更换登录凭证。普通用户用例图如图3-1所示。
图3-1 普通用户用例图
3.2.2售后用户功能需求
售后用户主要负责处理系统分配的维修任务。任务信息管理模块展示待接单与处理中的工单列表，售后用户可以查看申请详情并更新任务进度。维修记录管理功能要求售后用户在完成服务后填写故障原因、维修措施与更换配件等信息，这些记录成为后续评价与追溯的依据。评价信息管理使售后用户能够查看普通用户对自己服务的评价内容，从中发现服务过程中的不足之处。售后用户的操作直接影响维修工单的状态流转，从接单到完工的每个环节都需要在系统内留下记录。售后用户用例图如图3-2所示。
图3-2 售后用户用例图
3.2.3管理员功能需求
管理员拥有系统最高权限，负责基础数据的维护与业务监控。家电信息管理模块支持添加、编辑或下架家电产品信息，包括品牌、型号、规格参数与技术文档。故障案例管理功能维护诊断知识库，管理员可以发布新的故障案例或更新已有案例的解决方案。故障类型管理用于配置系统内的故障分类标签，这些标签在售后申请时供用户选择。设备信息管理与运行状态管理允许管理员查看所有用户绑定的设备及其运行数据，发现异常时可主动联系用户。故障预警管理模块配置预测规则的参数阈值，调整敏感度以平衡漏报与误报率。售后申请管理使管理员能够查看所有申请记录，将任务派发给合适的售后网点。维修记录管理与评价信息管理用于监督服务质量，对投诉较多的售后用户进行提醒。权限管理控制不同角色的菜单访问权限与操作权限。数据概览模块以图表形式展示售后申请趋势、故障类型分布与维修费用统计等关键指标。管理员用例图如图3-3所示。
图3-3 管理员用例图
4系统设计
4.1系统架构设计
系统采用前后端分离的架构模式，将用户界面与业务逻辑解耦。前端部分基于Vue框架构建单页面应用，负责数据展示与用户交互。后端部分基于Flask框架提供RESTful API接口，处理业务逻辑与数据持久化。这种分离模式使前端开发与后端开发可以并行推进。前端通过HTTP协议向服务端发送请求，服务端处理完成后返回JSON格式数据。表现层接收用户输入后将请求转发给业务逻辑层，业务逻辑层执行具体的业务规则校验与计算，数据访问层负责与MySQL数据库进行交互。Spark独立模块定期读取数据库中的运行状态记录，执行故障分析后将预警结果写回。PyCharm作为集成开发环境提供了代码编写、调试运行与版本管理的一体化支持。系统架构图如图4-1所示。耿嘉安在Spark内核设计的艺术一书中详细阐述了弹性分布式数据集的工作原理，为故障分析模块的设计提供了理论支撑17。
图4-1 系统架构图
4.2系统结构功能设计
系统用三种用户角色来创建功能模块体系。普通用户可以进行登录注册、智能推荐查询、家电信息检索、售后申请提交、设备信息维护、密码修改、运行状态查看、故障预警接收、维修记录查阅和评价信息管理。售后用户有任务信息处理、维修记录填写和评价信息浏览的任务。管理员对家电信息进行维护，对故障案例进行管理，对故障类型进行配置，对设备信息总览进行查看，对运行状态进行监控，对故障预警进行管理，对售后申请进行审批，对维修记录进行监督，对评价信息进行审核，对权限进行分配，对数据进行展示。该系统功能结构如图4-2所示。
图4-2 系统功能结构图
4.3系统流程设计
4.3.1系统总体业务流程设计
系统总体业务流程从用户登录开始，完成身份认证后根据角色权限加载对应的功能界面。普通用户可绑定家电设备，系统采集运行数据后由Spark进行分析。当检测到异常时生成故障预警推送至用户。用户提交售后申请后，管理员将订单派发给售后运维人员。运维人员接单后联系用户安排维修，完成后录入维修记录。系统推送评价邀请给用户完成服务评价。整个流程覆盖了从设备绑定、故障预警、报修申请到维修评价的完整闭环。系统总体业务流程如图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故障预警流程设计
故障预警流程由Spark分析模块定期触发。系统读取设备最近一段时间的运行参数，与标准阈值进行对比分析。当检测到异常模式时，系统生成预警记录并推送至对应用户的预警页面。用户查看预警详情后可以主动发起售后申请。故障预警流程如图4-7所示。
图4-7 故障预警流程图
4.4数据库设计
数据库设计采用关系模型组织业务数据，通过预定义的数据类型与约束条件保障存储内容的准确性。规范化理论指导表结构设计，减少数据冗余与更新异常。在本系统中，数据库承担了用户信息、设备档案、售后申请、维修记录等核心业务数据的持久化任务。外键约束用于维护表之间的引用完整性，确保关联数据的一致性。郑阿奇在MySQL数据库教程中详细介绍了InnoDB存储引擎的事务特性，为数据库的可靠性设计提供了参考依据18。
4.4.1E-R图设计
普通用户实体主要包括普通用户ID、用户姓名、用户年龄、用户性别、审核状态、用户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 运行状态实体属性图
故障预警实体主要包括故障预警ID、预警日期、预警原因、故障类型、处理建议、家电型号、家电名称、普通用户、风险评分、家电类型、用户姓名等属性。故障预警实体属性图如图4-13所示。
图4-13 故障预警实体属性图
售后申请实体主要包括售后申请ID、申请日期、申请编号、审核状态、故障现象、故障类型、家庭住址、家电型号、家电名称、普通用户、手机号码、家电类型、用户姓名等属性。售后申请实体属性图如图4-14所示。
图4-14 售后申请实体属性图
任务信息实体主要包括任务信息ID、售后用户、申请编号、审核状态、故障类型、家庭住址、家电型号、家电名称、普通用户、手机号码、任务详情、家电类型、用户姓名等属性。任务信息实体属性图如图4-15所示。
图4-15 任务信息实体属性图
维修记录实体主要包括维修记录ID、申请编号、普通用户、用户姓名、家庭住址、手机号码、家电名称、家电类型、家电型号、故障类型、售后用户、维修状态、维修费用、维修日期、检测结果、故障原因、记录详情、支付状态等属性。维修记录实体属性图如图4-16所示。
图4-16 维修记录实体属性图
评价信息实体主要包括评价信息ID、申请编号、普通用户、用户姓名、售后用户、服务评价、评价日期、评价内容等属性。评价信息实体属性图如图4-17所示。
图4-17 评价信息实体属性图
故障案例实体主要包括故障案例ID、收藏数、评论数、封面图片、诊断信息、故障描述、点赞数、发布日期、解决方案、标题名称、家电类型等属性。故障案例实体属性图如图4-18所示。
图4-18 故障案例实体属性图
故障类型实体主要包括故障类型ID、故障类型、创建时间等属性。故障类型实体属性图如图4-19所示。
图4-19 故障类型实体属性图
类型信息实体主要包括类型信息ID、家电品牌、家电类型、创建时间等属性。类型信息实体属性图如图4-20所示。
图4-20 类型信息实体属性图
系统E-R图如图4-21所示。
图4-21 系统E-R图
4.4.2数据库表设计
普通用户表主要是用来存储注册用户的基本身份信息与审核状态。主要包括普通用户ID、用户姓名、用户年龄、用户性别等字段。如表4-1所示。
表4-1 普通用户表
|----|--------|---------|----|------|------|--------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | 普通用户ID | int | 11 | 是 | 是 | 普通用户ID |
| 2 | 用户姓名 | varchar | 64 | 否 | 否 | 用户姓名 |
| 3 | 用户年龄 | varchar | 64 | 否 | 否 | 用户年龄 |
| 4 | 用户性别 | varchar | 64 | 否 | 否 | 用户性别 |
| 5 | 审核状态 | varchar | 16 | 是 | 否 | 审核状态 |
| 6 | 用户ID | int | 11 | 是 | 否 | 用户ID |
售后用户表主要是用来存储维修服务提供方的网点信息与联系人员。主要包括售后用户ID、售后网点、网点地址、负责人员等字段。如表4-2所示。
表4-2 售后用户表
|----|--------|---------|----|------|------|--------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | 售后用户ID | int | 11 | 是 | 是 | 售后用户ID |
| 2 | 售后网点 | varchar | 64 | 否 | 否 | 售后网点 |
| 3 | 网点地址 | varchar | 64 | 否 | 否 | 网点地址 |
| 4 | 负责人员 | varchar | 64 | 否 | 否 | 负责人员 |
| 5 | 联系方式 | varchar | 64 | 否 | 否 | 联系方式 |
| 6 | 审核状态 | varchar | 16 | 是 | 否 | 审核状态 |
家电信息表主要是用来存储产品库中各类电器的规格参数与技术指标。主要包括家电信息ID、家电品牌、家电型号、家电名称、出厂年份等字段。如表4-3所示。
表4-3 家电信息表
|----|--------|---------|----|------|------|--------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | 家电信息ID | int | 11 | 是 | 是 | 家电信息ID |
| 2 | 家电品牌 | varchar | 64 | 否 | 否 | 家电品牌 |
| 3 | 家电型号 | varchar | 64 | 否 | 否 | 家电型号 |
| 4 | 家电名称 | varchar | 64 | 否 | 否 | 家电名称 |
| 5 | 出厂年份 | varchar | 64 | 否 | 否 | 出厂年份 |
| 6 | 家电类型 | varchar | 64 | 否 | 否 | 家电类型 |
设备信息表主要是用来存储用户实际拥有的家电设备档案。主要包括设备信息ID、家电名称、家电类型、家电型号、普通用户、购买日期等字段。如表4-4所示。
表4-4 设备信息表
|----|--------|---------|----|------|------|--------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | 设备信息ID | int | 11 | 是 | 是 | 设备信息ID |
| 2 | 家电名称 | varchar | 64 | 否 | 否 | 家电名称 |
| 3 | 家电类型 | varchar | 64 | 否 | 否 | 家电类型 |
| 4 | 家电型号 | varchar | 64 | 否 | 否 | 家电型号 |
| 5 | 普通用户 | int | 11 | 否 | 否 | 普通用户 |
| 6 | 购买日期 | date | - | 否 | 否 | 购买日期 |
运行状态表主要是用来记录设备在不同时间点的运行参数与工作状况。主要包括运行状态ID、家电名称、家电类型、家电型号、普通用户、家电状态、运行参数等字段。如表4-5所示。
表4-5 运行状态表
|----|--------|---------|----|------|------|--------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | 运行状态ID | int | 11 | 是 | 是 | 运行状态ID |
| 2 | 家电名称 | varchar | 64 | 否 | 否 | 家电名称 |
| 3 | 家电类型 | varchar | 64 | 否 | 否 | 家电类型 |
| 4 | 家电型号 | varchar | 64 | 否 | 否 | 家电型号 |
| 5 | 普通用户 | int | 11 | 否 | 否 | 普通用户 |
| 6 | 家电状态 | varchar | 64 | 否 | 否 | 家电状态 |
故障预警表主要是用来存储系统识别出的异常状态与处理建议。主要包括故障预警ID、家电名称、家电类型、家电型号、普通用户、故障类型、风险评分、预警原因等字段。如表4-6所示。
表4-6 故障预警表
|----|--------|---------|----|------|------|--------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | 故障预警ID | int | 11 | 是 | 是 | 故障预警ID |
| 2 | 家电名称 | varchar | 64 | 否 | 否 | 家电名称 |
| 3 | 家电类型 | varchar | 64 | 否 | 否 | 家电类型 |
| 4 | 家电型号 | varchar | 64 | 否 | 否 | 家电型号 |
| 5 | 普通用户 | int | 11 | 否 | 否 | 普通用户 |
| 6 | 故障类型 | varchar | 64 | 否 | 否 | 故障类型 |
售后申请表主要是用来存储用户提交的维修请求信息。主要包括售后申请ID、申请编号、普通用户、用户姓名、家庭住址、手机号码、家电名称、故障类型、故障现象等字段。如表4-7所示。
表4-7 售后申请表
|----|--------|---------|----|------|------|--------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | 售后申请ID | int | 11 | 是 | 是 | 售后申请ID |
| 2 | 申请编号 | varchar | 64 | 否 | 否 | 申请编号 |
| 3 | 普通用户 | int | 11 | 否 | 否 | 普通用户 |
| 4 | 用户姓名 | varchar | 64 | 否 | 否 | 用户姓名 |
| 5 | 家庭住址 | varchar | 64 | 是 | 否 | 家庭住址 |
| 6 | 手机号码 | varchar | 64 | 是 | 否 | 手机号码 |
任务信息表主要是用来存储从售后申请转换而来的工单数据。主要包括任务信息ID、申请编号、普通用户、用户姓名、家庭住址、手机号码、家电名称、故障类型、任务详情等字段。如表4-8所示。
表4-8 任务信息表
|----|--------|---------|----|------|------|--------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | 任务信息ID | int | 11 | 是 | 是 | 任务信息ID |
| 2 | 申请编号 | varchar | 64 | 否 | 否 | 申请编号 |
| 3 | 普通用户 | int | 11 | 否 | 否 | 普通用户 |
| 4 | 用户姓名 | varchar | 64 | 否 | 否 | 用户姓名 |
| 5 | 家庭住址 | varchar | 64 | 否 | 否 | 家庭住址 |
| 6 | 手机号码 | varchar | 64 | 否 | 否 | 手机号码 |
维修记录表主要是用来存储售后用户完成服务后填写的详细信息。主要包括维修记录ID、申请编号、普通用户、用户姓名、家庭住址、手机号码、家电名称、故障类型、维修状态、维修费用、故障原因、记录详情等字段。如表4-9所示。
表4-9 维修记录表
|----|--------|---------|----|------|------|--------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | 维修记录ID | int | 11 | 是 | 是 | 维修记录ID |
| 2 | 申请编号 | varchar | 64 | 否 | 否 | 申请编号 |
| 3 | 普通用户 | int | 11 | 否 | 否 | 普通用户 |
| 4 | 用户姓名 | varchar | 64 | 否 | 否 | 用户姓名 |
| 5 | 维修状态 | varchar | 64 | 否 | 否 | 维修状态 |
| 6 | 维修费用 | double | - | 否 | 否 | 维修费用 |
评价信息表主要是用来存储用户对维修服务的满意度反馈。主要包括评价信息ID、申请编号、普通用户、用户姓名、售后用户、服务评价、评价日期、评价内容等字段。如表4-10所示。
表4-10 评价信息表
|----|--------|---------|----|------|------|--------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | 评价信息ID | int | 11 | 是 | 是 | 评价信息ID |
| 2 | 申请编号 | varchar | 64 | 否 | 否 | 申请编号 |
| 3 | 普通用户 | int | 11 | 否 | 否 | 普通用户 |
| 4 | 用户姓名 | varchar | 64 | 否 | 否 | 用户姓名 |
| 5 | 售后用户 | int | 11 | 否 | 否 | 售后用户 |
| 6 | 服务评价 | varchar | 64 | 否 | 否 | 服务评价 |
故障案例表主要是用来存储常见故障的诊断方案与解决步骤。主要包括故障案例ID、标题名称、家电类型、封面图片、故障描述、诊断信息、解决方案、发布日期等字段。如表4-11所示。
表4-11 故障案例表
|----|--------|---------|-------|------|------|--------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | 故障案例ID | int | 11 | 是 | 是 | 故障案例ID |
| 2 | 标题名称 | varchar | 64 | 否 | 否 | 标题名称 |
| 3 | 家电类型 | varchar | 64 | 否 | 否 | 家电类型 |
| 4 | 封面图片 | varchar | 255 | 否 | 否 | 封面图片 |
| 5 | 故障描述 | text | 65535 | 否 | 否 | 故障描述 |
| 6 | 发布日期 | date | - | 否 | 否 | 发布日期 |
故障类型表主要是用来存储系统预定义的故障分类标签。主要包括故障类型ID、故障类型、创建时间等字段。如表4-12所示。
表4-12 故障类型表
|----|--------|----------|----|------|------|--------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | 故障类型ID | int | 11 | 是 | 是 | 故障类型ID |
| 2 | 故障类型 | varchar | 64 | 否 | 否 | 故障类型 |
| 3 | 创建时间 | datetime | - | 是 | 否 | 创建时间 |
类型信息表主要是用来存储家电产品分类与品牌归属关系。主要包括类型信息ID、家电品牌、家电类型、创建时间等字段。如表4-13所示。
表4-13 类型信息表
|----|--------|----------|----|------|------|--------|
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
| 1 | 类型信息ID | int | 11 | 是 | 是 | 类型信息ID |
| 2 | 家电品牌 | varchar | 64 | 否 | 否 | 家电品牌 |
| 3 | 家电类型 | varchar | 64 | 否 | 否 | 家电类型 |
| 4 | 创建时间 | datetime | - | 是 | 否 | 创建时间 |
5系统实现
5.1普通用户角色功能实现
5.1.1登录注册
登录注册功能主要负责用户身份验证与账户创建。用户访问系统首页时，未认证状态会跳转至登录页面。用户输入用户名与密码后，前端将凭证封装为请求对象发送至服务端。服务端校验用户名是否存在，使用加密算法比对密码是否匹配。校验通过后生成临时访问令牌返回客户端。新用户需要填写用户名、密码、联系方式等基础信息完成注册，系统检查用户名唯一性后创建新账户。登录注册界面如图5-1所示。
图5-1 登录注册界面
5.1.2智能推荐查询
智能推荐查询功能主要负责向用户展示可能感兴趣的家电信息或故障案例。系统根据用户的历史浏览记录与设备绑定情况生成推荐列表。用户进入推荐页面后，前端请求推荐接口获取数据。服务端查询用户最近的点击行为与收藏记录，筛选出同类型或同品牌的内容。推荐结果按照相关度排序后返回前端渲染。用户可以通过推荐列表快速定位可能需要的维修知识或新产品信息。智能推荐查询界面如图5-2所示。
图5-2 智能推荐查询界面
5.1.3家电信息查询
家电信息查询功能主要负责帮助用户检索产品库中的电器数据。页面提供品牌筛选、类型筛选与关键词搜索三种检索方式。用户选择筛选条件后点击查询按钮，前端将参数拼接为查询字符串发送至服务端。服务端根据条件动态构建SQL语句，从家电信息表中检索匹配记录。查询结果以列表形式分页展示，用户点击某条记录可进入详情页面查看完整参数。家电信息查询界面如图5-3所示。
图5-3 家电信息查询界面
5.1.4售后申请
售后申请功能主要负责收集用户提交的维修请求。用户需要从已绑定的设备中选择待维修家电，或者临时填写未注册设备的信息。页面提供故障类型下拉选项与故障现象文本输入框。用户填写联系电话与家庭住址后提交申请，系统生成唯一申请编号并将状态设置为待审核。申请记录写入数据库后，用户可在个人中心查看处理进度。售后申请界面如图5-4所示。
图5-4 售后申请界面
5.1.5设备信息管理
设备信息管理功能主要负责维护用户家庭中实际拥有的家电档案。用户可以添加新设备，从家电信息库中选择产品型号并填写购买日期。已添加的设备支持编辑与删除操作。页面以表格形式展示设备列表，每行记录提供查看运行状态的快捷入口。设备信息管理界面如图5-5所示。
图5-5 设备信息管理界面
5.1.6密码修改
密码修改功能主要负责保障用户账户安全。用户需要输入原始密码进行身份验证，验证通过后方可设置新密码。前端对密码强度进行初步校验，要求长度在6到16个字符之间。服务端接收到修改请求后再次校验原始密码正确性，使用加密算法处理新密码后更新数据库记录。密码修改界面如图5-6所示。
图5-6 密码修改界面
5.1.7运行状态查询
运行状态查询功能主要负责展示已绑定设备的实时运行参数。页面提供家电名称与类型筛选条件，用户选择设备后点击查询按钮。服务端从运行状态表中检索该设备最新的记录，返回家电状态与运行参数等信息。列表中的异常状态会高亮显示，提醒用户关注潜在问题。运行状态查询界面如图5-7所示。
图5-7 运行状态查询界面
5.1.8故障预警查询
故障预警查询功能主要负责展示系统识别出的风险提示。页面默认显示当前用户所有未处理的预警记录，按预警日期倒序排列。每条预警包含家电名称、故障类型、风险评分与预警原因。用户可以点击查看详情获取处理建议，也可直接发起售后申请跳转至报修页面。故障预警查询界面如图5-8所示。
图5-8 故障预警查询界面
5.1.9维修记录查询
维修记录查询功能主要负责帮助用户回顾历史维修情况。页面提供手机号码与维修状态筛选条件，用户可快速定位特定工单。查询结果展示申请编号、维修费用与完成时间。用户点击详情可查看故障原因与维修措施，点击评价入口可对已完成的服务进行打分反馈。维修记录查询界面如图5-9所示。
图5-9 维修记录查询界面
5.1.10评价信息管理
评价信息管理功能主要负责收集用户对维修服务的反馈。页面展示用户已完成的维修工单列表，未评价的记录提供评价按钮。用户选择服务评价等级并填写评语内容后提交，系统将评价信息关联到对应的维修记录与售后用户。已评价的记录可以查看或修改评价内容。评价信息管理界面如图5-10所示。
图5-10 评价信息管理界面
5.2售后用户角色功能实现
5.2.1任务信息管理
任务信息管理功能主要负责展示分配给当前售后用户的工单列表。页面按审核状态分类展示待处理与已完成的任务。用户点击详情按钮查看完整的申请信息，包括用户地址、故障现象与联系方式。任务处理完成后，用户可以更新任务状态并触发维修记录填写流程。任务信息管理界面如图5-11所示。
图5-11 任务信息管理界面
5.2.2维修记录管理
维修记录管理功能主要负责记录现场服务的详细情况。用户进入填写页面后，系统自动关联申请编号与用户信息。售后用户需要录入故障原因、维修措施与更换配件清单。维修费用字段支持手动输入，检测结果与记录详情用于补充说明。提交后维修记录写入数据库，关联的任务状态同步更新为已完成。维修记录管理界面如图5-12所示。
图5-12 维修记录管理界面
5.2.3评价信息管理
评价信息管理功能主要负责查看普通用户对自己服务的评价内容。页面以列表形式展示历史评价记录，包括评价等级、评价日期与评语内容。售后用户可以通过评价反馈了解服务过程中的不足之处，据此改进工作方式。评价信息管理界面如图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 故障类型管理界面
5.3.4设备信息管理
设备信息管理功能主要负责查看所有用户绑定的家电设备。管理员可以按家电名称或类型筛选设备列表，查看每条设备关联的普通用户信息。对于异常设备，管理员可以主动联系用户了解情况。设备信息管理界面如图5-17所示。
图5-17 设备信息管理界面
5.3.5运行状态管理
运行状态管理功能主要负责监控所有设备的实时运行参数。管理员可以查看任意设备的最近状态记录，包括家电状态与运行参数。当发现大量设备出现同类异常时，管理员可以调整故障预警的阈值配置。运行状态管理界面如图5-18所示。
图5-18 运行状态管理界面
5.3.6故障预警管理
故障预警管理功能主要负责配置预测规则的参数。管理员可以调整各类故障的敏感度阈值，平衡漏报率与误报率。预警规则变更后，Spark分析模块会按照新规则重新处理历史数据。管理员也可以手动添加预警记录或删除误报的预警。故障预警管理界面如图5-19所示。
图5-19 故障预警管理界面
5.3.7售后申请管理
售后申请管理功能主要负责处理用户提交的维修请求。管理员查看申请列表，审核申请内容是否完整有效。审核通过的申请进入派发环节，管理员根据故障类型与用户位置选择合适的售后用户。任务派发后系统自动推送通知给对应售后人员。售后申请管理界面如图5-20所示。
图5-20 售后申请管理界面
5.3.8维修记录管理
维修记录管理功能主要负责监督售后用户的服务质量。管理员可以查看所有维修记录的详细信息，包括故障原因、维修措施与费用明细。对于投诉较多的售后用户，管理员可以调取其历史记录进行核查。维修记录管理界面如图5-21所示。
图5-21 维修记录管理界面
5.3.9评价信息管理
评价信息管理功能主要负责审核用户提交的评价内容。管理员可以查看所有评价记录，对于包含不当言论的评价进行隐藏处理。评价数据汇总后用于售后用户的绩效考核。评价信息管理界面如图5-22所示。
图5-22 评价信息管理界面
5.3.10 权限管理
权限管理功能主要负责控制不同角色的菜单访问与操作权限。管理员可以创建新的角色组，为每个角色分配可访问的页面模块。权限配置保存在数据库中，用户登录时系统根据角色加载对应的菜单结构。权限管理界面如图5-23所示。
图5-23 权限管理界面
5.3.11数据概览
数据概览功能主要负责展示系统运行的关键业务指标。页面通过图表形式呈现售后申请趋势、故障类型分布与维修费用统计。管理员可以按时间段筛选数据，快速了解业务波动情况。数据概览界面如图5-24所示。
图5-24 数据概览界面
6系统测试
6.1测试目的
系统测试就是检验家电故障预测系统功能实现是否符合需求规格说明书的要求。测试时采用普通用户、售后用户、管理员三个角色的所有功能模块。设计出具有代表性的一组测试用例，检验系统在正常的输入以及异常边界条件下的响应情况。测试主要是业务流程是否完整闭环，即售后申请可以走完审核、派单、维修、评价的全部环节。数据一致性校验也被包含到测试中，保证跨表操作之后关联数据的同步。测试目的之一就是发现程序中的潜在缺陷，给系统上线前的修复工作提供依据。杨力在Spark大数据实时计算一书中强调了数据处理引擎在预测类系统中的重要性，本系统的故障预警模块测试需要重点验证Spark分析结果的准确性19。
6.2测试方法
系统测试使用黑盒测试方法，测试人员不需要知道程序内部的实现。功能测试是对各个模块是否按照需求文档的要求来工作的检验。集成测试主要检验模块间的数据传递以及接口调用是否正确。测试用例的设计过程中，对等价类划分和边界值分析技术加以考虑。对输入字段设置有效等价类和无效等价类，分别给出测试数据进行验证。边界值测试针对长度限制、数值范围这些临界条件做测试。业务流程测试模拟出完整的场景，即从登录开始一直到退出系统为止的一系列连续的操作。回归测试在缺陷修复后重新执行相关用例，确保修改未引入新的问题20。
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 故障预警功能测试表
|------|---------------|-----------|------|
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
| 数据上报 | 模拟设备发送运行参数 | 数据写入运行状态表 | 符合预期 |
| 分析触发 | Spark模块执行分析任务 | 生成预警记录 | 符合预期 |
| 预警推送 | 普通用户登录系统 | 预警页面显示新记录 | 符合预期 |
| 阈值调整 | 管理员修改预警参数 | 后续分析使用新阈值 | 符合预期 |
6.4测试结论
通过执行上述测试用例，系统各功能模块均表现出符合预期的行为。登录注册模块能够正确识别合法用户并拦截非法访问。售后申请流程从提交到派发的各个环节衔接顺畅，状态流转准确无误。维修记录填写后数据能够正确关联到对应的申请与用户。故障预警模块能够基于运行参数产生风险提示，阈值调整后分析结果随之变化。测试过程中发现的少量界面显示问题已修复。整体评估表明系统功能完整，业务逻辑正确，达到了设计目标。
项目分享:大家可自取用于参考学习，获取方式可私信哦!
