第一章 绪论
1.1 研究背景与意义
传统新闻传播基于报纸、广播、电视的一对多定向媒体，信息传播时效严重滞后，受众只能接受经过编辑选择后的有限资讯，无法向其传达个人喜好，造成了严重的供需失调1。用户反馈渠道阻隔，阅读体验枯燥乏味并且低效。互联网早期阶段门户网站与BBS虽然加快了信息的流通速率，把部分交互转移到线上进行，但是依旧是由专职编辑负责信息产出，UGC内容分散且不易整合串联，各网站之间构筑起信息壁垒，新闻展示形式越来越趋于雷同2。当前数字化时代用户的资讯消费方式正在经历着深刻的变化，除了要满足及时性的需求外，更加追求个性化的定制式体验以及具有较强社会参与度的群体认同感，现有的编辑推荐机制已经不能满足愈发复杂的用户需求了3。
打造智能化新闻推送平台可以从根本意义上改变消息推送机制，用算法模型完成新闻文章同阅读者兴趣之间的有效对接，极大增强了对信息进行推送的速度以及精确度。平台程序自动处理海量信息，减少了编辑人员的人为主观判断，也避免了人工处理的失误疏漏等问题，实现了新闻素材的合理分配及动态实时分享，对于新闻业来说，一方面推进新闻生产的发布流程规范化标准化、数字化进程的发展，另一方面也通过调动用户点击赞、评论等交互行为的积极性从而提高了内容生态系统的活力和健康水平。也为建立有质量的数字新闻社区奠定良好基石。本平台设计开发所采取的技术路线及运营方式也为教育、文化等领域搭建个性化兴趣服务平台以及资源整合平台提供了可借鉴的实践方案。
1.2 国内外研究现状
国内新闻推荐系统的演进紧密跟随互联网技术的发展步伐，经历了从门户集权到算法主导的清晰路径。早期新浪、搜狐等综合门户网站扮演了信息聚合与分发的核心角色，其内容生产完全由专业编辑团队把控，呈现模式统一且缺乏个性4。移动互联网的爆发催生了以"今日头条"为代表的平台，它们凭借先进的协同过滤与内容分析算法，开创了"千人千面"的个性化新闻推荐模式，极大提升了用户粘性5。腾讯新闻等大型客户端则注重生态构建，整合了图文、短视频、直播等多种内容形态，并嵌入社交功能以增强用户停留时间6。与此同时，"一点资讯"等平台引入用户主动订阅的兴趣关键词，尝试让人工选择与算法推荐相结合7。当前阶段，国内研究焦点集中于利用深度学习模型挖掘新闻文本的深层语义，并融合用户实时行为序列预测其动态兴趣，以解决传统方法在冷启动和长尾内容推荐上的不足8。
在海外新闻推送的研究方面发展较早，并且产业发展与科学研究相互支撑形成了丰富多样的应用生态9。Bleacher Report这类专注细分领域的新闻机构，很好地将体育新闻与强烈的社交属性相结合，形成了以用户讨论为主导的新闻平台10。而谷歌新闻是国际化的新闻聚合平台，一直利用其聚类算法对各个消息来源的相关报道进行归纳，并根据其点击记录来进行个性化定制排序，同时BBC、CNN等老牌新闻机构也都在其数字化的产品中广泛应用推荐功能，试图吸引更多的年轻群体11。从科学的角度来看，Netflix Prize比赛对于协同过滤方法的发展有着重要的意义，相关的矩阵分解模型广泛应用于新闻的个性化推送系统中12；而在最新的研究当中，深度学习方法的应用十分广泛，循环神经网络用于捕捉用户的阅读路径，或者用神经网络中的注意力机制来抽取新闻标题以及文章的重点特征等等都让推送系统更加理解读者的兴趣变化与新闻的价值内涵13。
1.3 主要研究内容
本文的研究工作围绕着创建以Python为基础技术栈的新型新闻推荐系统而展开。首先明确了系统的总体目标与服务定位，即构建一个能够满足用户个性化阅读需求、同时为管理员提供强大数据支撑与内容管理能力的B/S架构平台。研究严格遵循软件工程开发流程，依次展开针对普通用户与系统管理员这两类核心角色的详细需求分析，并据此规划其具体的功能模块与业务流程。在总体设计阶段，确定了前后端分离的技术路线，前端使用Vue框架开发响应式用户界面，后端采用Django框架构建业务逻辑服务，并结合Python完成核心推荐算法与数据处理任务，数据库选用MySQL进行结构化数据存储。实现的核心功能模块包括面向用户的新闻浏览检索、互动评论与个性化推荐流，以及面向管理员的新闻内容爬取与管理、用户评论情感分析、新闻自动分类、多维度数据可视化统计图表生成以及社区交流内容审核等后台管控功能。本研究着力解决的核心实际问题是如何在海量新闻信息中为用户高效筛选感兴趣内容，以及如何通过数据化工具提升新闻内容运营管理的效率与决策科学性。
第二章 相关技术介绍
2.1 Django框架
Django是一个基于Python的高级Web框架。它采取了MVT的设计理念，它倡导的理念是约定优于配置，从而提高开发速度。框架本身的ORM模块把数据库表封装成Python类，开发人员不必亲自去写繁杂的SQL查询便可对数据进行增删改查14，极大地简化了同数据库打交道的难度。自身的模板引擎支持动态页面的展现，可以一定程度上绑定前后端的同时开发。系统后台管理模块的迅速创建基于Django自身的Admin网站模块，它会依据数据模型来自动生成管理界面。它的请求－响应处理过程以URL路由器将客户端发送来的HTTP请求分发到相应的视图函数，视图函数对模型进行相关数据处理后选择模板返回响应结果。Django的中间件系统是对请求处理层次的可插入式的扩展，方便添加如用户权限验证、跨站请求伪造防护等功能，对于此系统后台新闻信息管理和用户数据分析部分复杂的逻辑的编写有着重要的作用。
2.2 Vue.js框架
前端开发使用了渐进式JavaScript框架Vue.js。它有一个基于响应式的数据劫持结合发布者-订阅者的系统。当应用程序的状态发生变化时，相应的视图会自动更新15，这一方式让开发者摆脱了大量手动的DOM操作工作。Vue.js是基于组件化方式创建UI界面的，每一个组件都是一个相对独立的可复用的vue实例，他们有各自的模板、各自的行为和各自的样式。组件间通过Props传值给子组件，自定义事件来触发父组件的方法的形式进行解耦，达到了明显的关注分离以及模块的高内聚低耦合。单文件组件就是把模板、脚本和样式包裹到一个.vue文件里。增强了项目维护度。在本系统前端搭建方面，Vue.js用于渲染新闻列表页，处理用户的查询及评论交互行为，使用axios与服务端RESTful API完成异步交互，动态加载新闻、推荐信息，保证良好的用户体验。
2.3 MySQL数据库
MySQL作为一款成熟的开源关系型数据库管理系统，给该系统带来了稳定的数据永久保留策略。客户端/服务器模式下，MySQL可以使用标准的SQL语句来实现数据的创建及查询等功能。MySQL采取多存储引擎的架构方式，可以根据具体表的不同使用场景而选择最适合它的那个引擎，在如InnoDB就提供了事务处理能力及支持外键功能，以保障新闻数据的完整性。数据库中索引的功能加快了查找的速度，在系统中对新闻标题、类型及用户ID等信息建立了对应的索引，从而提高了新闻搜索以及个性化推荐算法的运算速度16。数据库表格设计满足第三范式的要求，降低了数据重复率，用外键约束了用户表、新闻表和评论表之间的联系，使得表格中的数据具备了参照完整性。当程序运行时，MySQL除了对新闻的相关属性及正文进行了保存之外，也记录下了用户的浏览足迹、点赞评论操作等信息，这些都是之后做用户偏好挖掘分析以及新闻推荐运算所需要用到的结构化信息。
2.4 RESTful API架构风格
系统前后端交互使用RESTful API的设计风格，即一种建立在HTTP协议之上的软件架构约束，它将互联网上的资源看做统一资源定位符URI的形式存在，在网络上针对资源的操作都遵循一套统一的标准的HTTP方法来完成，如GET查询新闻资讯列表、POST提交评论、PUT更新用户信息，DELETE删除相关内容17等，使得API具有明确的语义并保持无状态，方便前端进行学习及调用；同时，REST API返回的内容一般为JSON格式，它小巧而又易于识别的特点非常适合跨平台的信息交换传输。在此系统的实际开发过程中，后端的Django框架利用Django REST framework工具包高效地搭建起了RESTful API接口，前端vue.js应用程序通过发起异步请求向相应节点发出服务调用以完成获取新闻信息、发送用户行为、接收推荐结果等工作，整个体系结构风格明确地区分出前后端之间各自的职责范围以及它们之间的交互方式协议，也是保证系统能够成功实行前后端分离式开发所做出的重要技术选择。
第三章 系统分析
3.1 可行性分析
3.1.1 技术可行性
系统使用浏览器访问服务器的整体架构设计，实现的基础是成熟的Web开发模式。开发语言使用Python，其中Django框架用于制作信息管理系统较多，社区活跃度高，可以迅速构建系统的雏形并且实现相关业务功能。数据存储采用关系型数据库MySQL，在对其进行插入、删除、更新、查询的操作支持良好，适用于存储新闻，用户，评论等结构化的数据。本人有python编程以及Web开发的经验，可以独立编写系统各主要模块代码。系统可能存在的问题在于随着新闻数量的增长导致查询效率降低，可以通过合理创建数据库索引来解决，用户输入的数据可能存在安全隐患，需要在后台做好严格验证和过滤工作。所以从技术的角度来说本系统是可以实施的。
3.1.2 操作可行性
系统界面设计采用通用的新闻阅读及后台管理模式。目的群体对新闻分类阅读、查找、评论等功能模块路径较为熟悉，在此基础上添加了推荐系统的功能模块，并未对用户主要的阅读方式造成影响，只在页面右侧加了一个推荐列表，易于目的用户的理解与接受。后台管理员界面集合了图表以及具体的功能按扭，统计观察数据、执行相关管理任务方便简洁，步骤符合一般后台管理工作流程。所以系统部署上线之后，系统运行应该比较稳定，以后更新一些功能或是对数据进行维护都可以通过管理员界面来进行处理，不需要有繁琐的运维技巧。所以在此方面，系统是可以实现的。
3.1.3 经济可行性
项目支出主要在于研发期间的人力支出，研发时间约为3个月。硬件依赖实验室已有电脑设备，软件采用Python以及众多开源平台及数据库无需购买额外授权费用。小额投资制作出一款可行并可以实际运行的原型推荐系统具有实际展示及继续开发的使用意义。低成本投入和可以被验证的应用价值形成合理的配比，从而奠定项目的经济基础。所以该项目在经济上是可行的。
3.2 功能需求分析
UML用例图是用来描绘一个系统的功能以及如何与用户交互的一种建模工具，以角色同用例之间关系来描绘系统在各种情况下所表现的行为。用例图可以很清晰地反映一个系统的边界，清楚地指明哪些是外界的参与者，并且说明他们是如何与系统进行交互的。参与者是对系统进行使用的人员或者外部系统，而用例则是系统所能提供的某个功能或者提供的某个服务。用例图在需求获取的过程中具有很重要的意义，可以帮助开发人员找到主要的功能点，不至于遗漏重要的需求。同时以可视化的方式展示系统的需求使得沟通变得更方便简单，理解更加直接明了，为之后的系统设计和系统实现提供了参考的标准。本篇论文将会根据系统对角色模块进行需求分析。
3.2.1 用户功能
系统拥有用户和管理员两种角色。用户的权限可查看新闻文章，对新闻进行查询操作，按自身喜好点赞或是评论。浏览新闻页面会生成用户的行为日志信息，系统根据日志信息生成个性化推荐列表，用户通过个性化推荐来获得更多的感兴趣新闻信息。用户有权管理自己的评论信息，查看以前的评论信息，清除过滤条件，清除不合时宜的评论，查看评论详细信息等。用户用例图如下图3-1所示。
图3-1用户用例图
3.2.2 管理员功能
管理员角色用于管理系统后台并对后台进行全面监控。管理员登陆后台主页，观察各类数据统计图像，包括新闻收藏数目、系统总访问数目、评论数目走势、点赞数目变化情况、访问来源分析、新闻来源占比、阅读数目比较、评论数目比较和用户性别比例。管理员管理新闻观看列表，实现新闻信息的新增、查询、重置、统计分析以及删除等功能，可以对外部网站爬取新闻信息，查看新闻具体信息，了解新闻相关评论，对新闻的信息进行情感分析并归档分类。管理员使用新闻观看预测的功能，查看历史预测结果，清空预测条件，删除旧的预测条目，增加新的预测条目，查看预测结果的图像展示。管理员管理情感分析列表，实现查询、重置、删除、查看详情等的操作。管理员负责管理互动社区，实现用户之间互动内容的查询、清空、删除、添加、查看详情及审核评论等功能。管理员用例图为图3-2所示。
图3-2管理员用例图
第四章 系统设计
4.1 系统架构设计
新闻推荐系统以模块化方式进行设计。形成了结构化的三层架构体系。用户通过浏览器访问基于vue框架搭建的前端页面，对资讯进行查看、搜寻、点赞评论等相关操作；前端应用借助axios库异步向后端服务器发起HTTP请求。后端基于django框架，接收来自前端应用程序的请求，处理相关业务逻辑。主要包含身份验证、新闻推荐算法运算、评论情感计算等功能模块。数据持久化部分依赖mysql的数据存储，存放新闻资讯、用户数据以及用户的交互行为等重要信息，使其更加安全稳定可靠。该框架结构清晰、分工明确有利于开发调试及新增功能。软件结构合理地分层使程序的响应时间与开发效率都得到了很大的改善18。系统整体结构如下图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图设计
用户实体包含用户id，用户名，密码，昵称等等属性。这些都是用于唯一识别用户并辅助登陆及个性化的显示。实体属性图如图4-8所示。
图4-8用户实体属性图
新闻体由新闻id，标题，正文内容、新闻发布来源等属性组成。这些属性构成一条新闻的基本信息。实体属性图如图4-9所示。
图4-9新闻实体属性图
评论实体主要有评论id，新闻id，用户id，内容等属性，用来存储用户对于某条新闻的评论响应情况。实体属性图如下图4-10所示。
图4-10评论实体属性图
情感分析实体主要有情感分析id、新闻id、情感分析结果、情感分析内容等属性。这些属性记录了对于新闻内容的情感判定信息。实体属性图为图4-11。
图4-11情感分析实体属性图
分类录入实体主要包含分类录入id、新闻id、新闻分类、判断结果等字段。它们代表了新闻被管理员处理后得到的类别及标签。实体属性图如下图4-12所示。
图4-12分类登记实体属性图
新闻浏览实体主要有新闻浏览id、标题、详情链接、阅读量等属性。这些属性是用来记录以及统计对新闻的浏览信息的。实体属性图如下图4-13所示。
图4-13新闻浏览实体属性图
新闻浏览预测实体包含新闻浏览预测id、预测字段1、预测字段2、预测结果等等属性，属性中记录着关于对历史数据做出的相关预测的信息。实体属性图如下图4-14所示。
图4-14新闻浏览预测实体属性图
新闻分类实体主要有新闻分类id，新闻分类属性。该实体是系统中新闻的分类系统。实体属性图见图4-15所示。
图4-15新闻分类实体属性图
交流管理实体主要由交流管理id，标题，内容，创建用户id这些属性构成。用于管理用户与用户间的论坛交流内容。实体属性图如下图4-16所示。
图4-16交流管理实体属性图
浏览用户实体主要有浏览用户id、用户姓名、用户性别、用户id等属性。这个实体扩充了用户的部分信息用于后台统计。实体属性图如图4-17所示。
图4-17浏览用户实体属性图
系统E-R图如图4-18所示。
图4-18系统E-R图
4.4.2 数据库表设计
数据库表的设计就是依据业务需要来决定数据库的表结构以及字段类型之间相互的关系。经过合理化的数据库设计确保了数据的有效性、一致性和高效性的同时并防止出现重复数据，也为后面的数据检索、保存等工作的操作提供了明确模型19。下面是系统数据库表的设计图示。
用户表主要为了保存系统的注册用户登录账号信息等。包括用户id、用户名、密码、昵称等属性。如下表4-1所示。
表4-1用户表
| 序号 | 字段名 | 数据类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | user_id | int | 11 | 是 | 是 | 用户ID |
| 2 | username | varchar | 16 | 是 | 否 | 用户名 |
| 3 | password | varchar | 64 | 是 | 否 | 密码 |
| 4 | nickname | varchar | 16 | 否 | 否 | 昵称 |
| 5 | avatar | varchar | 255 | 否 | 否 | 头像地址 |
| 6 | create_time | timestamp | - | 是 | 否 | 创建时间 |
新闻表主要为了存放从各渠道采集到的新闻文章的内容。主要有新闻ID、标题、文章正文、发布来源等字段。见表4-2。
表4-2新闻表
| 序号 | 字段名 | 数据类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | article_id | mediumint | - | 是 | 是 | 新闻id |
| 2 | title | varchar | 125 | 是 | 否 | 标题 |
| 3 | content | longtext | - | 否 | 否 | 正文内容 |
| 4 | source | varchar | 255 | 否 | 否 | 发布来源 |
| 5 | create_time | timestamp | - | 否 | 否 | 创建时间 |
| 6 | img | varchar | 255 | 否 | 否 | 封面图 |
| 7 | tag | varchar | 255 | 否 | 否 | 标签 |
评论表主要是用于存放用户对于新闻所发表的所有评论内容。主要包含评论id，新闻id，用户id，内容等多个属性。如下表4-3所示。
表4-3评论表
| 序号 | 字段名 | 数据类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | comment_id | int | 11 | 是 | 是 | 评论id |
| 2 | source_id | int | 11 | 是 | 否 | 新闻id |
| 3 | user_id | int | 11 | 是 | 否 | 用户id |
| 4 | content | longtext | - | 否 | 否 | 内容 |
| 5 | create_time | timestamp | - | 是 | 否 | 创建时间 |
| 6 | hidden | tinyint | 1 | 否 | 否 | 是否隐藏 |
情绪分析表主要用于保存对于文章内容所做的情绪分析的具体结果。主要包含情绪分析id、新闻id、情绪分析结果、情绪分析内容等等属性值。如下表4-4所示。
表4-4情感分析表
| 序号 | 字段名 | 数据类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | sentiment_analysis_id | int | 11 | 是 | 是 | 情感分析id |
| 2 | source_id | int | 11 | 否 | 否 | 新闻id |
| 3 | sentiment_analysis_result | varchar | 64 | 否 | 否 | 情感分析结果 |
| 4 | sentiment_analysis_details | longtext | - | 否 | 否 | 情感分析内容 |
| 5 | create_time | datetime | - | 是 | 否 | 创建时间 |
分类登记表主要就是用于保存新闻管理员处理之后的分类信息以及情绪标签。主要有分类登记id、新闻id、新闻分类、情绪分析结果等属性。如下表4-5所示。
表4-5分类登记表
| 序号 | 字段名 | 数据类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | class_nameification_registration_id | int | 11 | 是 | 是 | 分类登记id |
| 2 | source_id | int | 11 | 否 | 否 | 新闻id |
| 3 | news_class_nameification | varchar | 64 | 否 | 否 | 新闻分类 |
| 4 | sentiment_analysis_result | varchar | 64 | 否 | 否 | 情感分析结果 |
| 5 | create_time | datetime | - | 是 | 否 | 创建时间 |
新闻浏览表主要用于存储和计算新闻的具体浏览信息。主要有新闻浏览id,标题,详情页链接,阅读数等列。如下表4-6所示。
表4-6新闻浏览表
| 序号 | 字段名 | 数据类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | news_browsing_id | int | 11 | 是 | 是 | 新闻浏览id |
| 2 | title | varchar | 64 | 否 | 否 | 标题 |
| 3 | url | text | - | 否 | 否 | 详情链接 |
| 4 | read_num | double | - | 否 | 否 | 阅读量 |
| 5 | origin | varchar | 64 | 否 | 否 | 发布来源 |
| 6 | content | text | - | 否 | 否 | 正文内容 |
| 7 | create_time | datetime | - | 是 | 否 | 创建时间 |
新闻浏览预测表主要用于保存由历史浏览记录所进行的对未来趋向的推测信息。主要包括新闻浏览预测id、预测字段1、预测字段2、预测结果等字段。如下表4-7所示。
表4-7新闻浏览预测表
| 序号 | 字段名 | 数据类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | news_browsing_forecast_id | int | 11 | 是 | 是 | 新闻浏览预测id |
| 2 | title | varchar | 64 | 否 | 否 | 预测字段1 |
| 3 | origin | varchar | 64 | 否 | 否 | 预测字段2 |
| 4 | read_num | varchar | 64 | 否 | 否 | 预测结果 |
| 5 | output | text | - | 否 | 否 | 预测图表 |
| 6 | create_time | datetime | - | 是 | 否 | 创建时间 |
新闻发布栏主要用于对系统内的新闻信息进行分类以及管理。主要包括新闻发布栏id、新闻发布栏等字段。如下表4-8所示。
表4-8新闻分类表
| 序号 | 字段名 | 数据类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | news_class_nameification_id | int | 11 | 是 | 是 | 新闻分类id |
| 2 | news_class_nameification | varchar | 64 | 否 | 否 | 新闻分类 |
| 3 | create_time | datetime | - | 是 | 否 | 创建时间 |
交流管理表主要用于对用户发在论坛版块的交流帖进行管理。主要由交流管理id、标题、内容、创建用户id等属性组成。如表4-9所示。
表4-9交流管理表
| 序号 | 字段名 | 数据类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | forum_id | mediumint | - | 是 | 是 | 交流管理id |
| 2 | title | varchar | 125 | 是 | 否 | 标题 |
| 3 | content | longtext | - | 否 | 否 | 内容 |
| 4 | user_id | mediumint | - | 是 | 否 | 创建用户id |
| 5 | create_time | timestamp | - | 是 | 否 | 创建时间 |
浏览用户表主要为了丰富用户的资料，提供后台的数据统计分析以及展示。主要有浏览用户id，用户名字，用户性别，用户id等属性。如表4-10所示。
表4-10浏览用户表
| 序号 | 字段名 | 数据类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | browse_users_id | int | 11 | 是 | 是 | 浏览用户id |
| 2 | user_name | varchar | 64 | 否 | 否 | 用户姓名 |
| 3 | user_gender | varchar | 64 | 否 | 否 | 用户性别 |
| 4 | user_id | int | 11 | 是 | 否 | 用户id |
| 5 | create_time | datetime | - | 是 | 否 | 创建时间 |
第五章 系统实现
5.1 用户功能实现
5.1.1 在线AI功能实现
该功能为用户提供的是智聊对话交互体验。用户可以在聊天框内输入自己的问题、系统会通过后台模型进行回答、可以自由选择技能。历史聊天记录会在右侧栏保存下来方便用户查看自己以前的对话记录，增强了用户体验的连贯性和便捷性。在线AI如图5-1所示。
图5-1在线AI界面
5.1.2 新闻浏览功能实现
该模块是用户获取新闻信息的主要页面，展示了系统的新闻列表。用户通过顶部的搜索框输入关键词查找新闻，也可利用发布来源搜索或排序功能筛选内容。列表以图文卡片形式呈现新闻标题、来源与发布时间，用户点击卡片即可进入详情页阅读。新闻浏览界面如图5-2所示。
图5-2新闻浏览界面
5.1.3 新闻浏览推荐功能实现
本模块处于新闻详情页面左侧位置，目的在于给用户提供个性化的拓展性阅读选择。系统根据用户浏览的当前新闻内容进行分析，得出相似新闻列表。推荐信息点击"更多"按钮显现出来，简洁卡片式地展现相关联新闻文章的标题、出处、时间等，使用户能继续发掘所感兴趣的方面。新闻浏览推荐界面如图5-3所示。
图5-3新闻浏览推荐界面
5.1.4 评论管理功能实现
用户在该页面统一处理自己账号的所有评论留言。系统以列表的形式展示出每一个评论所针对的新闻标题以及评论信息和发布时间等。用户可以依照昵称或者关键词来搜索自己需要查找的那个评论记录，点击某一条记录之后就可以实现对其的删除或者查看该条评论的具体上下文的详情。评论管理页面如下图5-4所示。
图5-4评论管理界面
5.2 管理员功能实现
5.2.1 后台首页功能实现
后台首页是管理员的数据汇总平台，包含了一系列数据可视化视图。首页实时显示评论数柱状图、点赞数时间序列曲线、访问量统计图和消息来源比例分布饼图等等，清晰展示了系统的整体运行数据，便于管理员查看系统情况，对数据分析做出判断等，后台首页界面如图5-5所示。
图5-5后台首页界面
5.2.2 新闻浏览列表功能实现
本模块是管理员对于系统内部的所有新闻统一管理的操作平台。页面采用表格的形式来显示新闻标题、来源以及阅读数量。管理员可以通过左侧功能导航跳转到添加、预测等功能模块。主要操作是对新闻记录进行数据分析、爬虫更新、清理多余数据、查看具体内容及相关评论，也可做情感判断并进行归类存档，新闻阅读列表页面如下图5-6所示。
编辑 图5-6新闻浏览列表界面
5.2.3 新闻浏览预测功能实现
这个功能模块是对新闻的未来的阅读数量进行预测和建模，管理员在检索框中设置条件之后，会显示历次的预测情况，管理员可以对失效的预测信息做出删除的操作，或者选择"添加预测"，来开始一个新的预测过程，预测的结果以可视化的折线图的方式显示出来，方便查看判断，新闻浏览预测界面如下图5-7所示。
图5-7新闻浏览预测界面
5.2.4 情感分析列表功能实现
系统对新闻评论自动做情感趋势分析，结果在此列表集中存放，管理员可以利用查询、重置功能选择查看分析的结果。列表内展示了新闻标题、详情链接、阅读次数、来源以及评论数等内容，管理员对每一个分析结果都可以做出删除的处理或者是点击详情查看对应评论的情感分析数据及其原文出处等信息。情感分析列表页面如下图5-8。
图5-8情感分析列表界面
5.2.5 交流管理功能实现
本模快负责对管理平台内用户之间的交流信息进行处理，包括论坛发帖等各种交互方式。管理员可以根据标题、分类等信息来查找对应的交流信息，列表展示了信息是否被置顶以及创建时间、更新时间等，主要的功能有清除不良信息以及发布公告交流信息等。详情按键是用来查看具体的内容、评论按键则是审查该交流话题下面用户的反馈信息情况。交流管理页面如下图5-9所示。
图5-9交流管理界面
第六章 系统测试
6.1 系统运行环境
系统的架构与技术选型主要包含前端交互、后端服务及支撑环境三部分，前端部分负责呈现用户界面并处理交互行为，后端部分执行核心业务逻辑与数据持久化，支撑环境为系统开发、部署与维护提供必要的工具链和平台。各项技术组合旨在构建一个功能完整、响应迅速且易于维护的应用体系。系统所选用的技术如表6-1。
表6-1系统技术选型表
| 分类 | 技术/工具 | 作用说明 |
|---|---|---|
| 前端技术栈 | HTML/CSS/JavaScript | 构建网页基础结构与样式，实现客户端动态交互逻辑 |
| Vue.js | 渐进式JavaScript框架，采用组件化模式构建用户界面，提升开发效率 | |
| Element Plus | 基于Vue.js 3的UI组件库，提供丰富的预设组件，统一界面风格 | |
| Axios | 基于Promise的HTTP客户端，负责前后端之间的异步数据通信 | |
| 后端技术栈 | Python | 后端主要开发语言，以其简洁语法和丰富库支持快速开发 |
| Django | 高级Python Web框架，提供ORM、模板引擎等功能，简化复杂开发任务 | |
| MySQL | 关系型数据库管理系统，存储新闻、用户、评论及行为数据等结构化数据 | |
| Redis | 内存数据结构存储，用于缓存用户会话、热点新闻及推荐中间结果 | |
| Celery | 分布式任务队列，异步处理新闻爬取、情感分析等耗时任务 | |
| 开发工具与环境 | PyCharm | Python集成开发环境，提供代码智能提示、调试与版本控制集成 |
| Docker | 容器化平台，用于封装应用及其依赖，保障环境一致性，简化部署流程 |
6.2 测试目的
系统测试是对新闻推荐系统的功能完备度、业务流程准确性及系统可靠性的全面检测。本次测试的对象不是系统底层源码或者各个组件模块，而是以系统的整体对外服务为核心进行检测，看它能否达到开发之初所规定的需求，即功能性和非功能性的要求。首先我们要保证整个系统在用户端和管理端的业务主链路可以正常运转。如用户端从查看文章到获取个性化推送，再评论并管理个人评论的一个闭合环路是否通畅，管理后台端对于后台的新闻信息增删改查、数据统计与展示、系统监控等事务能否实现等等。我们需要在仿真的应用场景下，对各项功能间的传入传出与对接调用是否正确，防止出现功能孤立、数据不同步的情况。
测试目标包括检查系统的主要业务逻辑是否正确，特别是个性化推荐策略在运行环境下的效果。这要求考察推荐系统是否可以根据用户的交互历史记录以及它在面对不同类型的用户画像、不同类型新闻时的表现。另外对于情绪分析、阅读量预估这些智能化辅助指标来说，则要考察它们判断是否合情合理可信，可以作为管理者做出决策时的一个有效参考而不是相反。
测试需要考察系统的稳定性和容错机制，即系统面临意外输入以及边界情况或者出现并行请求等情况下反应如何。比如对过长的查询关键字、新闻数目骤升、多人同时发帖等情况，系统仍然可以维持最基本的功能实现，并向用户反馈正确的出错语句，而不是无任何征兆地宕机或者产生错误结果。这类试验的目的在于找出程序可能存在的错误漏洞及效率不足之处，以保证其可以在变化莫测的真实工作条件下拥有较高的稳定性。
测试也为了验证系统的UI和交互是否满足要求，虽然这不是纯粹的技术测试目标，却是直接影响用户感受的重要因素。要检测前端页面能否准确显示后台数据、相关按钮点击时是否及时反馈、页面间切换是否清楚明了等，保证整套系统可以被使用者便捷、流畅的操作使用、降低学习及应用难度。实现上述目标，系统测试也将成为项目后期交付发布上线时可靠的质量指标与信心支撑。
6.3 测试方法
本系统测试中以黑盒测试为主要手段并辅以针对特殊场景下的性能测试及界面测试等手段组成了多层次的测试验证体系，测试的开展并不基于被测系统的内部逻辑结构，而是以用户、管理者的角度依据需求文档与设计方案编写出能够覆盖核心业务流程的测试脚本，测试环境独立于生产环境，拥有一套单独的测试数据库，在此数据库中提前导入了组织完善数量充足的相关模拟数据诸如模仿账号、不同类型的新闻信息、过往操作日志与评论等等，保证了测试场景的真实性和再现效果。
测试的重点为功能测试，根据功能模块的不同划分，围绕所选择出的七个主要的业务模块编写并实施详细的测试案例，每一个案例都包括明确的测试初始环境、操作过程描述、期望结果以及测试结果记录。操作步骤模拟真人在进行操作时的行为，通过在浏览器上进行点击来发出请求，而不是直接对后台接口进行调用。测试时对系统的返回信息，数据库的变化情况，页面的跳转，提示消息等都进行了详细的记录并与期待的结果相比较，以此判断该功能是否通过了测试。而对于新闻推荐等算法相关功能，则通过建立不同的行为模式的虚拟用户账号来进行分析，并比较他们之间的推荐列表的不同，从而对此功能的个性化水平做出一个大致的判断。
在完成功能测试的基础上进行了集成测试来检测多个模块之间的配合情况，测试主要检测跨模块数据的一致性，比如用户在前端删除了一条评论，管理员后台管理中的评论曲线图是否实时刷新；管理员爬取了一篇新闻之后，这篇新闻是否能马上展示在前端用户可查看的列表当中并且可以被检索到。对于核心的业务流程"浏览新闻--->触发行为--->反馈推荐--->再次浏览"这个闭环进行了全流程测试保证完整的用户链路畅通。
为了检验系统稳定情况，在项目中加入了非功能性的测试流程。实施了简短的压力测试，模拟多人同时查看新闻、发帖的情况，考察系统响应时间和出错情况。执行了异常及边界条件等测试，比如对空值，超长字符进行检索操作或是删除并不存在的新闻等，测试程序的输入检查、异常处理措施等是否完善。界面测试自始至终都没有停歇过，检查页面在不同分辨率大小的浏览器下排版效果是否合适，交互按钮等是否可以正常点击。所有的测试案例运行、结果反馈及问题追踪都在一套统一的测试流程管控之下，保证了测试过程的严密性和有序程度。
6.4 测试内容
新闻浏览功能的测试着重验证用户查询并获取新闻列表的核心业务，关注搜索关键词的匹配逻辑、结果排序规则以及分页展示的完整性。新闻浏览测试如表6-1所示。
表6-1新闻浏览测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 新闻搜索 | 关键词精确查询 | 输入特定新闻标题进行搜索 | 准确返回包含该关键词的新闻条目 | 符合预期 | 通过 |
| 新闻浏览 | 列表分页显示 | 请求超过单页容量的新闻数据 | 新闻列表正确分页，显示分页导航控件 | 符合预期 | 通过 |
| 内容展示 | 新闻详情加载 | 点击列表中的新闻条目 | 跳转至新闻详情页，完整显示新闻内容与附属信息 | 测试成功 | 通过 |
新闻推荐模块测试是为了检验系统是否可以实现针对用户以前的行为记录动态生成个性化新闻推荐列表并将之展示出来。新闻推荐测试如表6-2所示。
表6-2新闻推荐测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 推荐生成 | 个性化列表生成 | 模拟不同用户行为后刷新推荐页面 | 系统为不同用户呈现差异化、与其兴趣相关的新闻列表 | 符合预期 | 通过 |
| 推荐更新 | 实时行为影响 | 进行新的浏览、点赞操作后查看推荐列表 | 推荐内容随之更新，反映用户最新兴趣偏好 | 测试成功 | 通过 |
评论管理功能测试则集中在用户对自己发表评论的一系列流程上的管理，即评论的位置查询、编辑与最后的删除的逻辑是否正确等方面，评论管理测试如下表6-3所示。
表6-3评论管理测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 评论查询 | 历史评论检索 | 在个人评论管理界面进行查询 | 准确列出用户所有历史评论，支持按时间排序 | 符合预期 | 通过 |
| 评论删除 | 单条评论移除 | 选定一条评论执行删除操作 | 该评论从列表及数据库中彻底移除，相关计数更新 | 测试成功 | 通过 |
后台首页的数据统计模块测试主要是为了检查各个可视化图是否能正确的展示系统的最新数据情况，所使用的图表种类合适以及数据绑定正确。数据统计测试如下表6-4。
表6-4数据统计测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 图表渲染 | 多维度数据展示 | 访问后台首页 | 各统计区域正确加载不同图表，数据不为空 | 符合预期 | 通过 |
| 数据更新 | 图表动态响应 | 在前台产生新的浏览、评论行为后刷新后台 | 相关统计图表的数据与图形随系统状态实时更新 | 测试成功 | 通过 |
新闻查看列表管理测试是检验管理账户针对系统中的新闻信息进行添加删除编辑查询等主要操作的效果及数据是否一致。新闻列表管理测试如下表6-5所示。
表6-5新闻列表管理测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 新闻添加 | 新内容入库 | 通过管理界面添加一条完整的新闻信息 | 新闻成功保存至数据库，并能在前台列表中查看到 | 符合预期 | 通过 |
| 新闻爬取 | 外部数据接入 | 执行新闻爬取任务，指定目标来源 | 系统从指定来源获取新闻数据并解析，自动录入新闻列表 | 测试成功 | 通过 |
| 数据分析 | 新闻热度评估 | 对指定时间段内的新闻列表执行数据分析 | 系统生成阅读量、评论数等维度的统计报告 | 符合预期 | 通过 |
新闻浏览预测功能测试主要用来检查预测算法的输入输出过程及预测结果用折线图方式显示的准确性与直观程度。对新闻浏览预测进行测试如下表6-6所示。
表6-6新闻浏览预测测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 预测任务添加 | 新建预测请求 | 提交一组新闻特征数据，请求进行浏览量预测 | 系统接受请求并返回预测任务ID，任务进入处理队列 | 符合预期 | 通过 |
| 预测结果查看 | 图表化展示 | 根据任务ID查询已完成的预测结果 | 系统以折线图或柱状图等形式清晰展示预测趋势与分析结论 | 测试成功 | 通过 |
情感分析列表管理测试主要是针对系统的对新闻内容的情感判断的结果存储、检索、以及维护等管理工作是否完善可靠进行检验。情感列表管理测试如表6-7所示。
表6-7情感分析管理测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 结果查询 | 情感分类检索 | 根据情感倾向（积极、消极、中性）筛选新闻列表 | 准确返回符合该情感分类的所有新闻条目 | 符合预期 | 通过 |
| 结果维护 | 分析记录删除 | 批量选择历史情感分析记录并删除 | 选中的记录从列表中消失，底层数据被清理 | 测试成功 | 通过 |
测试结论
经过对新闻推荐系统的完整功能、集成以及非功能性测试，各核心业务模块都满足了设计要求。新闻查看搜索、个性化内容推荐生成、用户评论管理、后端新闻内容维护功能、各种数据分析汇总、阅读次数预测、情感管理等功能都能够正常使用，业务流程顺畅，数据逻辑无误，在测试期间存在的一些界面展示细节以及某些边界情况处理不周到，也已经在研发期间进行了调整和完善。
系统整体表现稳定，可以正常响应日常操作以及大多数的非法操作。客户端和服务端之间的通信机制明确，数据在各个模块之间传递一致。个性化推荐模块可依据模拟出的不同用户行为数据输出不同的文章列表，验证了主要业务逻辑的实现是基本合理的，达到了预期效果。通过本次测试验证，本系统已经拥有上线部署，对外进行新闻阅读和推荐的基础服务能力，达到了毕业设计的功能需求目标，为进一步可能开展的性能深度优化和功能扩展提供了可靠的保障。