第一章 绪论
1.1 研究背景与意义
以家人及个体为服务主体的生命故事记载一直以来都借助手写记录、纸质留存、口耳相传以及亲身采访的方式进行，信息传递是单项流程，记录耗时长且繁琐，容易造成资料丢失，无法统一归档，人的情绪和真实感受在传播过程中被层层稀释，数据孤立无法实现长时间的价值积累1。到计算机普及和初期网页时代，个人博客和个人论坛提升了对信息获取的速度，线上沟通开始替代一部分线下互动，但是信息发布更新慢，缺乏音频等形式载体的支持，用户参与程度浅，精彩的故事无法系统的沉淀下来，碎片化的体验仍然存在，不能满足人们对即时互动、个性化的需求变化2。
针对生命故事书制作的小程序系统集中化处理故事文本和音频素材，规范化审核机制，降低人为干预失误几率，加快资料传递速度，对于生命叙述类信息的流程透明程度、用户参与质量和社区环境的稳定性有着直接受益的作用，也为兴趣驱动性内容服务聚合供应了一种可以借鉴的解决方案。
1.2 国内外研究现状
国内内容社区平台的发展是从门户网站的信息发展到垂直的兴趣服务，最初的内容社区平台是以编者为主的信息发布为中心，注重信息覆盖面3。用户数量增多之后，互动的论坛也慢慢出现，用户之间交流讨论的内容是重要的部分4。移动互联时代到来之后平台更加注重场景应用体验，用数据服务加强用户依赖度5。这一时期社区管理和内容监管也开始得到重视6。近年来的研究主要针对多元内容融合及用户长期驻留的问题，指出结构化内容管理的重要性7。
海外同类产品的演化趋势也体现了社交基因转向数据驱动型交互平台的特点，早期应用以依赖社交网络扩散获得群体8，紧接着在线数据统计、个性化推送策略占据主导地位9，还有的应用从官方账号、内容供给深度融合入手提升用户信赖感10。而在商业环境当中，产品又逐渐引入品牌植入、订阅功能11等元素。有研究表明可靠的后台结构、明确的功能分配是保证社群活跃的重要前提12。
1.3 主要研究内容
本文的研究以制作生命故事书的小程序为主题，确定系统的业务定位，解析出用户和管理员两个角色的需求，做出整体结构设计与数据库的设计，并且应用前后端分离技术实现了故事管理、音频播放、审核发布等一系列主要的功能来解决问题中出现的内容积累以及分享效率低的问题。
第二章 相关技术介绍
2.1 SpringBoot
SpringBoot来源于Java生态圈对于简化web应用程序开发过程的需求，在其发展历程上基于Spring框架持续发展的背景之上。框架在运行中约定方式进行组织项目结构、初始化时进行环境初始化、进行组件组装、在接收到请求的时候由控制层捕获参数信息并传递给业务单元进行业务计算，相关过程会在服务调用链条之间有序串联起来13。对于围绕生命故事信息管理和审核处置等业务操作，框架内部采用注解的方式描述各组件间关系，在整个生命周期保持稳定的合作状态，在接收到不同接口的响应请求中有明确的参数流转路线。
在整个系统运行的过程中，SpringBoot基于内置容器进行应用程序的启动，配置文件参与了属性初始化的过程，服务对象在上下文环境里处于可管理的状态，请求处理的方式是基于同步调用机制，经过处理后会产生结构化数据返回到前端表现层，无需外部容器介入、管理。内部逻辑相对闭合。
2.2 微信小程序
微信小程序随着移动端轻应用形式而来，整个的技术框架都是基于轻量的运行环境之上。页面层的作用是对视图进行绘制，逻辑层的作用是来进行状态的计算以及对事件进行响应，而数据则是由页面层与逻辑层间相互绑定来传送的14。在阅读人生经历的内容或是启动语音播放操作中，页面加载过程根据生命周期步骤进行，资源请求、视图展示依次展开。在对于社交化应用类型的研究中对此种运行方式的架构特点有详细阐述。
在运行时，小程序运行在一个沙箱环境中，脚本解释器负责逻辑代码的解析，在渲染上是基于数据驱动实现的视图更新。在通讯环节中则是以接口请求的形式来进行信息交互，响应的数据会进入到本地的状态机管理中去，页面依据状态的变化重绘，整个过程保持了较短的执行路径。
2.3 MySQL
MySQL属于关系型数据库管理系统，它是基于结构化的数据存储模型而构建起来的技术框架，在数据表中用字段说明描述信息属性，记录以行的形式保存到存储设备中，用主键来标明唯一性关联15，当对生命故事文本文档、音频索引等信息进行存储录入的过程中，数据库接受服务器发出的操作命令，经过分析之后开始制定执行方案，学术界对于Web应用的数据管理模式有过较为完善的阐述。
当对数据进行读取操作时，则SQL语句进入到优化器阶段、执行计划依据索引组织选择、结果集传递到上层逻辑处理模块，事务控制模块用来管理提交次序，在有异常的时候由回滚机制接管、数据的一致性在执行期间得以保持。
2.4 前后端分离架构
前后端分离结构产生于Web应用系统的复杂程度增加情况下，主要结构以接口界限为主导。前端部分注重界面显示和用户交互事件，后端部分负责进行相应的业务规则计算以及对数据管理，两个模块间依靠通信接口协议来实现双方的数据交流任务。当进行阅读生命故事、发表评论等活动的时候，从客户端向服务器发送请求，经过网络传送到服务器端进行处理之后，会按照一定的形式把处理的结果返回给客户端。有关的研究文献中，在对Web应用的设计方式的探讨过程中，对该种模式进行了整理总结16。
在整个框架执行的过程中，接口层负责进行数据打包工作，在前端不触及到数据存储结构，后台端也不会参与到对视图状态的操作之中去，数据流转的方向就在请求和应答间构成一个闭环，各层功能界限分明。
第三章 系统分析
3.1 功能需求分析
用户角色通过系统完成身份校验后进入功能操作流程，围绕内容浏览以及交互过程展开。用户能够针对发布过的生命故事，实施查看的操作，系统在加载故事文字消息的前提下，支持声音播放的行为，以内容为中心，用户可实施收藏、点赞、评论等操作，相应的动作都是基于已有故事资源展开的。用户还可以浏览新闻资讯板块获得文章信息，与之发生互动进而引发问答的询问，并得到系统的响应消息。个人原创的生命故事内容提交后进入到待审核的状态，审核成功后纳入到用户故事范畴之内。用户角色用例图如下图3-1。
图3-1用户用例图
管理员角色在系统内部完成系统的管理和授权操作等功能，主要职责基于对系统内数据维护展开的任务。管理员能够针对系统中的角色信息做相应的设置操作，以达到对角色所拥有的操作权限的改变，围绕对故事的管理，管理员能够在系统内部查看到用户上传的故事资料并对其的状态做出审核以及管控等操作，对已经公开的资料实施维护，管理员还能针对用户故事合集作出管理操作，使得呈现在系统之上的资料满足系统规定的要求；新闻发布模块也由管理员统一管理，相关的内容通过后台管理系统流程实现发布与更新，管理员角色用例图如下图3-2所示。
图3-2管理员用例图
3.2 可行性分析
3.2.1 技术可行性
系统的总体架构是在成熟的编程语言和开发框架基础上进行搭建的，后端采用稳妥的服务架构形式实现业务逻辑运算，前端展示环境利用原有平台予以呈现。本地数据库保存系统运行数据并且有清晰的数据格式以及明确的读写模式。程序员已经拥有相应技术积累，对于开发工具的操作也相对熟练。在运行时可能会发生的延时或者错误问题，可以改进编码层次及提高数据验证来解决。所以系统从技术上来说是可行的。
3.2.2 操作可行性
系统操作流程符合目标群体惯常的操作习惯，功能入口清楚，在登录之后就进入了主要的操作页面，平时操作当中沿袭原来的指定途径来实施信息查看以及操作交互，基本流程并没有大的变动；后期运维系统平稳运行，后台维护操作集中体现在信息管理上，维护操作具有可行性；所以该系统的操作上是可行的。
3.2.3 经济可行性
项目资金主要用于开发过程中的人力费用，硬件设施使用现有机器进行，在软件上采用开源技术建立不需要增加新的开支。投资总额不大，和所能带来的应用效益处在合理范围内。所以从经济上来说项目也是合理的。
第四章 系统设计
4.1 系统架构设计
系统总体使用了分层式的结构设计，各个功能模块以业务流为主线展开为若干的层次，前端页面作为与用户的操作交互界面，用户相关的指令使用axios的方式以异步的形式传递给后端服务接口，后台控制器接收到请求之后交予service层完成相应逻辑处理，处理的结果进入到持久化阶段即数据访问层执行持久动作，Mysql数据库负责存储用户信息、故事内容、新闻数据等重要业务数据，并保持在进行数据读写时的数据一致性要求。系统在这种单机模式下实现业务流程流转的相关研究也对类似的流程做了完整的描述17。系统的总体设计架构如下图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 数据库设计
数据库的设计是建立在关系模型的基础上进行的，其主要的思想是使用标准化的形式表达出对象之间的相互联系，用表的形式来维护数据的完整性并保持在读入和查询时都处在一个统一的状态。这种方式的作用是在系统运行的时候负责存储持久化的数据，对关系数据库在应用系统中的作用也有一些的相关探讨18。
4.4.1 E-R图设计
用户实体主要由用户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、评论内容、用户id、创建时间等属性组成。实体属性图如下图4-13所示。
图4-13评论实体属性图
E-R图如图4-14所示。
图4-14系统E-R图
4.4.2 数据库表设计
数据库表设计就是依照业务需求规划出相应的数据库表结构、类型、关联等。进行合理化的规划使得数据完整有效、一致、高效，不会有重复的数据，为后面的数据检索、储存、管理有清晰的框架结构。下面是系统数据库表设计图。
4.4.2数据库表设计
用户表主要用来存储系统用户的账户基本信息，数据信息以身份标识、状态管理为主线展开，设定用户id为主键来表示各账户个体差异，用户名与昵称属性用来描述账户展示信息，状态属性用来标注账户是否可使用，时间属性存储账户生成历程。如表4-1所示。
表4-1用户表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | user_id | int | 11 | 是 | 是 | 用户ID |
| 2 | username | varchar | 16 | 是 | 否 | 用户名 |
| 3 | nickname | varchar | 16 | 否 | 否 | 昵称 |
| 4 | state | smallint | -- | 是 | 否 | 账户状态 |
| 5 | create_time | timestamp | -- | 是 | 否 | 创建时间 |
平台用户表是为了保存经过平台审核后的用户个人信息，表格的数据构架偏向于对个体特征的描述，在该表中用平台用户id进行标识，姓名、性别、年龄等字段用来描述用户的个体特征信息，审核状态字段表示当下的数据情况，时间字段来表示产生过程。如表4-2所示。
表4-2平台用户表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | platform_users_id | int | 11 | 是 | 是 | 平台用户ID |
| 2 | user_name | varchar | 64 | 否 | 否 | 姓名 |
| 3 | user_gender | varchar | 64 | 否 | 否 | 性别 |
| 4 | user_age | varchar | 64 | 否 | 否 | 年龄 |
| 5 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
我的故事表是存储用户上传原生的故事内容，数据集包含故事原文和相关素材文件，表内用我的故事id做为主码，标题列用来标明故事标题，音频、图片列表示相关素材地址，时间列表示内容上传流程如表4-3所示。
表4-3我的故事表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | my_story_id | int | 11 | 是 | 是 | 故事ID |
| 2 | story_title | varchar | 64 | 否 | 否 | 故事标题 |
| 3 | explain_audio | varchar | 255 | 否 | 否 | 讲解音频 |
| 4 | story_picture | varchar | 255 | 否 | 否 | 故事图片 |
| 5 | create_time | datetime | -- | 是 | 否 | 创建时间 |
用户故事表用于保存审核通过之后的故事内容信息，是系统对外公布的最重要的一个数据源。在该表内设定用户故事id为主键，标题栏用来描述内容主题，状态栏用来表示是否已发布，统计栏用来统计互动次数，时间栏用来显示发布时间等。如表4-4所示。
表4-4用户故事表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | user_stories_id | int | 11 | 是 | 是 | 用户故事ID |
| 2 | story_title | varchar | 64 | 否 | 否 | 故事标题 |
| 3 | story_status | varchar | 64 | 否 | 否 | 故事状态 |
| 4 | praise_len | int | 11 | 是 | 否 | 点赞数量 |
| 5 | comment_len | int | 11 | 是 | 否 | 评论数量 |
新闻表用来保存系统的消息发布，其数据结构是基于文字信息以及时间记录。在表内以文章ID为主键，标题字段用以对新闻进行总结说明，而正文内容则采用长文本的形式储存下来，在此期间的时间字段用来记载发布时间等，如表4-5所示。
表4-5新闻表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | article_id | int | 11 | 是 | 是 | 文章ID |
| 2 | title | varchar | 125 | 是 | 否 | 标题 |
| 3 | content | longtext | -- | 否 | 否 | 正文内容 |
| 4 | create_time | timestamp | -- | 是 | 否 | 创建时间 |
评论表用于存储用户对故事或者新闻发表的评论信息，其中的数据结构表示了评论内容及其所属的用户。表内以评论id为主键，内容列保存评论内容，用户id列指示评论来源，时间列保存生成信息如表4-6所示。
表4-6评论表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | comment_id | int | 11 | 是 | 是 | 评论ID |
| 2 | content | longtext | -- | 否 | 否 | 评论内容 |
| 3 | user_id | int | 11 | 是 | 否 | 评论用户 |
| 4 | 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 AI问答功能实现
AI问答组件拥有问答交互界面，客户在输入框中输入问题描述信息，后台收到请求之后进行处理得到应答结果并反馈给前端。交谈过程以消息的形式展现出来，在互动环节中页面不会产生跳转，会保留上下文环境，客户可以在同一个界面上进行多次对话询问的操作。AI问答界面如图5-4所示。
图5-4 AI问答界面
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新闻管理界面
第六章 系统测试
6.1 测试目的
系统测试以对生命故事书制作小程序的整体运行状况进行测试为主，目的是基于系统化测试程序确认软件每个功能模块是否达到在需求分析时所提出来的目标。测试过程中主要观察系统的稳定性及安全可靠性，确认功能实现程度、业务逻辑是否贯通以及数据处理无误等，经由查找并弥补存在的漏洞减少系统的错误发生率19。并在此基础上对程序的可操作性和交互性加以验证，以便后期软件交付和运维提供支持。使整个系统能够符合最初的标准。
6.2 测试方法
系统测试以组合方式进行，包括不同层次质量保障的测试。黑盒测试主要站在用户角度进行系统功能行为的检测，输入一定的动作来查看其输出结果，检测系统的各个功能是否按需求所描述的功能正确运作、适用于用户故事查阅、新闻阅览等的测试。白盒测试主要是针对系统内结构逻辑的检测，根据其程序实现过程来进行代码执行路径及数据处理流程的检测，查找其中可能存在的逻辑错误20，针对模块内部的设计进行逻辑验证。灰盒测试是带有部分系统结构信息的知识来对系统功能进行检测，针对模块之间的调用及传递情况进行检测。回归测试是当系统进行了相关功能的调整、修改之后，对已有的功能进行重新的测试，保证了系统修改没有引入了新的BUG问题。性能测试是对系统连续操作的状态下，对其做出的相关反应进行观察。查看系统运行过程中稳定的情况。
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 | 持续访问 | 重复读取资讯 | 系统响应正常 | 测试成功 |
AI问答模块测试主要考察问答互动过程中信息传递逻辑是否合理，验证提问提交及结果应答整个过程是否完整，在连续问答场合下是否保留了正确的上下文等，保证问答结果正确回馈以及对话的完整性。AI问答模块测试如表6-5所示。
表6-5 AI问答模块测试用例表
| 序号 | 测试功能 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| 1 | 问题提交 | 发送问答请求 | 请求处理成功 | 符合预期 |
| 2 | 结果返回 | 接收系统回复 | 内容返回正确 | 测试成功 |
| 3 | 连续问答 | 多轮交互处理 | 流程保持连贯 | 结果一致 |
我的故事管理模块测试基于用户上传内容处理流程进行，主要是针对用户上传的故事相关数据进行测试，在提交故事后，主要测试故事数据的保存逻辑，考察内容在不同的审核状况中所出现的变化，检查系统对用户故事消息的一致性管理，保证数据流通过程中的处理遵循业务流程规则，我的故事管理模块测试如下表6-6所示。
表6-6我的故事管理模块测试用例表
| 序号 | 测试功能 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| 1 | 内容提交 | 提交故事信息 | 数据保存成功 | 符合预期 |
| 2 | 状态变更 | 调整故事状态 | 状态更新正确 | 结果一致 |
| 3 | 数据读取 | 查看提交内容 | 信息展示正常 | 测试成功 |
用户故事管理模块测试主要是校验管理员对已上线的故事内容维护策略是否合理，观察故事数据经管理后是否一致，查看系统对于编辑内容请求的数据库同步结果，保证前台页面所显示的信息与后台管理操作的结果相同。用户故事管理模块测试如表6-7所示。
表6-7用户故事管理模块测试用例表
| 序号 | 测试功能 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| 1 | 内容管理 | 执行维护操作 | 数据更新正确 | 符合预期 |
| 2 | 状态同步 | 刷新展示数据 | 内容一致显示 | 结果一致 |
| 3 | 持续管理 | 重复管理操作 | 系统运行正常 | 测试成功 |
测试结论
经过对系统功能性、功能性以及稳定性等方面进行检测，证明了生命故事书制作小程序能够在规定的要求中正常运作。测试的过程中存在部分小的问题都已经进行了修复或者提出了相关的整改意见，整个系统的运行状况比较稳定。经检测各个模块之间的连接是比较通顺的，主要的业务流程都能够顺利进行，系统没有严重的不能继续使用的情况发生，基本符合设计要求及用户需求。