第一章 绪论

1.1 研究背景与意义

传统线下书店由于营业时间和地理位置的限制，读者购书常常会遇到奔波耗时、库存信息滞后等麻烦，早期的线上书店虽然把交易搬到了互联网上，但是大多只关注新书销售，没有很好地整合用户之间的二手图书流转，图书闲置资源被大量浪费，读者和管理者之间的信息反馈渠道也并不畅通，购书体验碎片化问题严重[1]。随着互联网技术的不断进步，读者对于购书过程的便捷性、图书信息的全面性、闲置资源处理的高效性等各方面的要求也越来越高，单一的销售方式已经不能满足当下用户对于循环经济和即时互动的综合需求[2]。开发出集新书销售、电子书购买和图书回收为一体的线上书店系统，可以将图书从销售到回收的全部过程线上化，提高信息传播速度和资源匹配度，对规范图书交易流程、改善用户的购书体验、推进图书循环利用生态建设有实际意义，也可以给同类型垂直电商平台功能整合提供可操作的设计参考。

1.2 国内外研究现状

1.2.1 国内现状

国内线上书店发展从最早的单一电商平台销售模式，到后来的多元化服务整合。早期以当当网、卓越网为代表的综合电商平台最早把图书销售线上化，其模式主要是新书零售为主，交易流程比较简单[3]。接着以孔夫子旧书网为代表的垂直平台出现，开始关注二手图书交易，但是其系统大多停留在商品发布和简单的搜索上，用户互动和订单管理能力比较弱[4]。移动互联网普及之后，被引入的电子书和知识服务平台有App、微信读书等，扩大了图书消费场景，但是图书回收和用户反馈管理仍然独立存在，没有形成闭环[5]。近些年来部分综合电商平台开始涉足二手回收入口，不过系统整合程度不高，订单管理同回收流程之间依然存在数据割裂状况[6]。国内研究者对于电商系统的设计已有一定的经验，但是关于图书回收和多类型订单统一管理的系统化实践还比较缺乏[7]。

1.2.2 国外现状

国外的线上书店对于图书销售和回收的整合开始得比较早，已经形成了一套比较成熟的商业模式和架构。以Amazon为代表的一线综合性平台最早就建立了图书销售和第三方二手书交易相结合的机制，它的用户评价体系以及订单追踪系统给图书流转提供了一定的保障[8]。AbeBooks平台主要经营古籍和二手书交易，用标准化的商品描述和全球化的物流系统来实现图书资源的高效匹配[9]。在电子书方面，Apple Books和Google Play Books依靠移动生态系统，实现了电子书的即时交付以及跨设备同步阅读，但是电子书订单和纸质书订单管理系统的独立运作没有融合在一起[10]。部分欧洲独立书店所开发的线上平台也采取了与之对接的方式，把线下回收的服务同线上订单系统结合起来，依靠本地化的物流优势来解决图书逆向流转的问题[11]。国外的研究重点是电商系统在订单管理、用户反馈和库存跟踪等技术方面实现的成果，给多角色权限管理以及多种类型的订单统一处理提供成熟的方案[12]。

1.3 主要研究内容

本课题以线上书店系统为研究对象，属于面向普通用户和管理员的图书交易和回收综合服务平台。系统包含普通用户公告通知查看、图书资讯浏览、图书信息查询、纸质图书购买、电子图书购买、图书回收申请、投诉反馈提交等主要功能，以及管理员纸质图书订单管理、电子图书订单管理、图书回收管理、投诉反馈处理、通知公告发布、图书资讯管理、图书信息管理等主要功能。按照软件工程的规范流程，依次完成需求分析、总体架构设计、功能模块划分、数据库设计、系统实现、测试。技术路线为前后端分离的B/S架构，前端使用Vue框架，后端用SpringBoot框架，数据存储用MySQL数据库。最终使新书销售、电子书购买和图书回收这三个业务模块有机地结合在一起，重点解决图书交易过程中销售和回收相分离、不同类型订单分散管理、用户反馈渠道不畅通等问题。

第二章 相关技术介绍

2.1 Spring Boot框架

SpringBoot框架是基于Spring生态的，它的设计目的就是解决传统Spring应用开发中配置繁杂、依赖管理复杂的难题。该框架在启动的时候会扫描类路径下的依赖库，从而自动完成大量的基础配置的注册和加载，开发者不需要显式地声明就可以得到一个可以运行的应用环境。框架内嵌入了Servlet容器，应用打包之后可以直接启动，容器的生命周期是由框架来统一管理的。SpringBoot使用前端控制器模式，所有的请求都会被DispatcherServlet分发到对应的处理器上，处理器执行完业务逻辑之后再返回模型和视图。框架给出一个条件化的配置机制，依据类路径中是否有某个类来决定是否加载该配置，从而使得同一个代码可以在不同的环境里自由地运行。数据访问层使用模板类封装了常见的操作，开发者调用模板方法就可以完成数据库交互[13]。框架自带了健康检查、指标监控的端点，在运行的时候可以公开应用的状态信息。构建工具使用Starter依赖聚合出功能模块所需要的全部依赖项，引入一个模块就可以得到完整的功能集。

2.2 Vue框架

Vue框架使用声明式渲染方式，开发者用模板语法来描述界面结构和数据绑定的关系，框架内部把模板编译成虚拟DOM树。当组件的数据发生改变的时候，框架就会发起异步更新队列，把同一天内多次出现的数据更新合并成一次更新。在数据变更检测上，框架利用对象属性拦截器对数据对象进行递归遍历，给每一个属性加上getter和setter方法，数据访问时保存依赖，数据修改时触发更新。虚拟DOM机制在更新阶段把新旧节点树进行对比，用双端比较算法得到最小化差异集合，然后将差异批量应用到真实DOM节点上。组件系统可以将界面拆分成一个个独立的单元，每个单元都负责自己的状态和样式，组件之间通过props传递只读数据，自定义事件来发送消息。框架在运行时包括编译时和运行时两部分，完整版可以编译模板，运行时版需要先预编译模板。单文件组件把模板、逻辑和样式集中到一个文件里，由工具将其转换成JavaScript模块[14]。

2.3 MySQL数据库

MySQL数据库使用客户端-服务器架构，服务端进程处理连接请求、解析SQL语句、执行查询计划。查询处理阶段解析器把SQL文本转化为语法树，优化器利用统计信息和代价模型来挑选执行途径，执行引擎调用存储引擎接口来达成数据操作。存储引擎层用插件的形式加载，InnoDB引擎使用聚簇索引来组织数据，主键索引的叶子节点保存完整的行记录，二级索引的叶子节点保存主键值。事务处理机制用重做日志和回滚日志保证原子性和持久性，重做日志记录物理修改操作，回滚日志记录逻辑修改前的状态。锁机制可以分为行级锁和表级锁，行锁是在索引记录上加锁，间隙锁是锁定索引记录之间的间隙。缓冲池用来缓存数据页和索引页，页是磁盘和内存之间数据交换的基本单位，修改操作先在缓冲池里完成，脏页由后台线程异步刷回磁盘[15]。复制功能依靠二进制日志来完成，主库把变更事件存入日志，从库读取并回放这些事件从而达成数据同步。

2.4 RESTful API设计风格

RESTful API以资源为单位来构建接口，每一个资源都有一个唯一的资源标识符，资源的状态用表述的形式在客户端和服务端之间传递。请求方法对应操作类型，GET方法获取资源表述，POST方法创建新资源，PUT方法替换资源状态，DELETE方法删除资源。服务端响应中包含状态码，2xx类表示成功处理，3xx类表示重定向，4xx类表示客户端错误，5xx类表示服务端异常。接口设计采用无状态的方式，每次请求都会携带完整的上下文信息，服务端不会保存会话状态。表述格式一般用JSON结构，数据用键值对的形式组织，嵌套结构用来表示资源之间的联系。缓存控制用响应头字段来实现，客户端根据过期时间和验证信息来决定是否使用本地副本。内容协商机制可以让客户端指定想要得到的表述格式和语言，服务端根据请求头给出相应的版本[16]。超媒体约束要求响应里含有链接信息，客户端依靠链接导航来完成业务流程，服务端同客户端之间脱离了接口耦合。

第三章 系统分析

3.1 可行性分析

3.1.1 技术可行性

系统使用前后端分离架构，前端用Vue框架，具有成熟的组件化开发模式，后端用Spring Boot框架，可以完成所有的业务逻辑处理，MySQL数据库可以对数据进行持久化存储和事务管理。开发人员经过前期的学习已经掌握了框架的基本使用方法，可以完成功能模块的编码和调试工作。系统运行过程中会存在并发访问时数据库连接池资源竞争的问题，通过合理设置连接池参数可以改善资源争用的情况。接口安全使用采用的是角色权限，不同的用户组有不同的操作权限。因此该系统的技术上是可行的。

3.1.2 操作可行性

系统界面的布局参照主流电商平台的设计风格，用户不用经过任何的学习就可以完成图书检索、下单购买、回收申请等操作。管理员后台使用表单化的操作方式，订单处理、内容发布等日常维护工作只需点击和填写就可以完成。系统上线之后日常运维工作主要集中在订单审核和内容更新这两方面，维护人员经过短暂的熟悉就可以完成。因此系统在操作上是可行的。

3.1.3 经济可行性

项目开发投入主要用在开发人员的工作时间上，硬件设备使用现有的个人计算机就可以满足开发和测试的需求。后端框架、前端框架以及数据库全部使用开源的技术方案，不需要支付授权费用。系统上线之后主要的运行成本就是服务器资源占用费用，和系统带来的图书流转效率提高相比处于可控范围内。因此系统在经济上是可行的。

3.2 功能需求分析

3.2.1 用户功能

用户登陆之后就可以查看平台所发布的信息公告以及图书资讯，从而获取到最新的活动信息和书籍推荐。用户通过图书信息查询功能查询需要的图书，查看图书详情之后选择纸质图书购买或者电子图书购买的方式进行交易。用户可以将闲置的图书提交到图书回收模块，输入相关信息之后等待处理。用户在使用时出现的任何问题都可以通过投诉反馈功能向平台提出意见或者申诉。用户角色用例图如图3-1所示。

图3-1用户用例图

3.2.2 管理员功能

管理员对纸质图书订单、电子图书订单进行处理，对订单的状态进行跟踪和管理。管理员收到图书回收申请之后就开始了回收工作，对用户投诉的反馈信息进行核实和回复。管理员还要负责通知公告的发布、图书资讯的更新和图书信息的管理等工作。管理员角色的用例图如图3-2所示。

图3-2管理员用例图

第四章 系统设计

4.1 系统架构设计

系统用前后端分离的模块化设计把展示层、业务逻辑层和数据访问层分开。前端使用Vue框架来创建用户界面，异步请求后端服务器；后端使用Spring Boot框架接收请求，控制器层对请求进行参数校验和路由分发，服务层进行业务规则处理，数据访问层用对象关系映射方式和数据库交互。系统有图书信息检索、订单交易处理、图书回收申请、投诉反馈管理等主要业务模块。用户操作触发前端请求，后端根据请求类型调用相应的服务组件，服务组件在事务管理的控制下完成数据库的读写操作，返回的结果以结构化的数据格式给前端完成界面渲染[17]。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 数据库设计

数据库设计符合关系型模型规范，用实体关系映射把业务对象转化为数据库表结构。规范化理论指导表结构的设计，消除数据的冗余以及更新的异常来保证数据的一致性。主键、外键约束来保证实体之间的参照完整性，事务来保证多步操作的原子性。本系统的数据库主要存储用户信息、图书数据、订单记录、回收申请等主要业务数据，索引设计主要对高频查询的字段进行索引设计以提高检索速度[18]。

4.4.1 概念设计

E-R图（实体关系图）是一种用来做数据建模的图形化工具，描述实体、属性以及实体之间的关系。以图示的形式来辅助数据库结构的分析与设计，清楚地表明数据间的相互联系，利于后续的数据库开发及管理工作。下面给出系统全局E-R图以及各个实体的属性图[19]。

注册用户实体主要包括注册用户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收货地址实体属性图

系统E-R图如图4-16所示。

图4-16系统E-R图

4.4.2 数据库表设计

数据库表设计就是根据业务需求来确定数据库表的结构、字段类型、关系。经过规范化的处理之后，可以保证数据的完整性、一致性、高效性，从而避免出现重复的数据，为后面的数据查询、存储、维护工作打下良好的基础。以下为系统的数据库表结构图。

注册用户表主要是用来存储系统注册用户的基本身份信息。主要包括注册用户id、用户姓名、用户手机等字段。如表4-1所示。

表4-1注册用户表

图书信息表主要是用来存储平台上架销售纸质图书的详细信息。主要包括图书信息id、图书名称、图书作者、卖价、商品库存等字段。如表4-2所示。

表4-2图书信息表

电子图书表主要是用来存储平台销售的电子图书基本信息。主要包括电子图书id、图书名称、图书作者、定价价格等字段。如表4-3所示。

表4-3电子图书表

图书购买表主要是用来记录用户购买纸质图书或电子图书的交易明细。主要包括图书购买id、订单单号、支付状态、购买日期等字段。如表4-4所示。

表4-4图书购买表

图书回收表主要是用来存储用户提交的闲置图书回收申请信息。主要包括图书回收id、闲置图书、回收进度、回收报价等字段。如表4-5所示。

表4-5图书回收表

投诉反馈表主要是用来存储用户提交的意见反馈与投诉内容。主要包括投诉反馈id、反馈标题、反馈类型、处理结果等字段。如表4-6所示。

表4-6投诉反馈表

纸质订单表主要是用来存储用户购买纸质图书生成的订单详情。主要包括订单id、订单号、订单状态、总价等字段。如表4-7所示。

表4-7纸质订单表

收货地址表主要是用来存储用户下单时填写的收货地址信息。主要包括收货地址id、地址、姓名、手机等字段。如表4-8所示。

表4-8收货地址表

第五章 系统实现

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.2 管理员功能实现

5.2.1 管理纸质图书订单功能实现

管理员在订单管理页面查看所有纸质图书订单列表，按订单状态筛选待处理订单进行发货操作。系统记录发货信息后订单状态更新为已发货，管理员可随时跟踪订单处理进度。管理纸质图书订单界面如图5-8所示。

图5-8管理纸质图书订单界面

5.2.2 管理电子图书订单功能实现

管理员在电子订单管理页面查看用户购买电子图书的记录，核对订单信息与支付状态。订单支付完成后系统自动完成电子图书交付，管理员无需人工干预发货环节。管理电子图书订单界面如图5-9所示。

图5-9管理电子图书订单界面

5.2.3 管理图书回收功能实现

管理员进入回收管理页面查看用户提交的回收申请，对申请内容进行审核并给出回收报价。审核通过的申请安排回收人员联系用户，完成后更新回收状态为已完成。管理图书回收界面如图5-10所示。

图5-10管理图书回收界面

5.2.4 管理投诉反馈功能实现

管理员在投诉反馈列表中查阅用户提交的反馈内容，根据反馈类型与内容进行调查核实。核实完成后填写处理回复内容提交系统，用户可在个人中心查看到处理结果。管理投诉反馈界面如图5-11所示。

图5-11管理投诉反馈界面

5.2.5 管理通知公告功能实现

管理员进入公告管理页面编写公告标题与正文内容，选择发布时间后发布公告。已发布公告在用户端首页展示，管理员可对已发布内容进行编辑或删除操作。管理通知公告界面如图5-12所示。

图5-12管理通知公告界面

5.2.6 管理图书资讯功能实现

管理员在资讯管理页面撰写图书推荐文章或行业资讯文章，上传封面图片并填写摘要后发布。资讯内容在用户端资讯栏目展示，管理员可对已有资讯进行修改或下架处理。管理图书资讯界面如图5-13所示。

图5-13管理图书资讯界面

5.2.7 管理图书信息功能实现

管理员在图书信息管理页面维护图书数据库，添加新书时填写图书名称、作者、价格、库存等信息。已上架图书可进行价格调整、库存更新或下架操作，确保图书信息准确有效。管理图书信息界面如图5-14所示。

图5-14管理图书信息界面

第六章 系统测试

6.1 测试目的

系统测试用黑盒测试和白盒测试相结合的方法。黑盒测试是对功能模块进行检验，按照需求文档来制订测试用例，涵盖用户登录，图书查询，订单创建，图书回收申请等主要业务流程，检验输入和输出是否满足预期。白盒测试关注的是代码逻辑路径的覆盖，对重要的业务方法做语句覆盖和分支覆盖的检查。测试过程中使用JUnit单元测试框架对后端接口进行测试，前端用浏览器开发者工具模拟用户操作并查看请求响应。测试环境和开发环境一致，保证测试结果可以真实的反映系统的运行情况[20]。

6.2 测试方法

测试目的就是检验系统功能实现是否符合需求规格说明书的要求，找出并修复可能存在的缺陷。利用测试用例的执行结果来检查各个模块对于各种输入情况的响应，看是否正确地处理了边界条件。测试过程重视数据流转的完整性和准确性，检验订单状态改变，库存扣减，回收申请审批这些业务逻辑是否达到设计要求。测试结果用来评价系统的质量，给系统上线运行提供可靠性依据，保证用户在使用过程中得到稳定的流畅的操作体验。

6.3 测试内容

6.3.1 纸质图书购买功能测试

对纸质图书购买流程进行功能验证，测试从图书选择到订单生成的完整链路。重点关注库存校验逻辑在数量异常情况下的处理方式，检验支付状态变更后订单信息的同步准确性。纸质图书购买测试如表6-1所示。

表6-1纸质图书购买测试用例表

6.3.2 电子图书购买功能测试

对电子图书购买交付机制进行测试，验证支付成功后电子图书文件的推送时效与访问权限。检验已购电子书在用户个人账户中的展示状态与在线阅读功能。电子图书购买测试如表6-2所示。

表6-2电子图书购买测试用例表

6.3.3 图书回收功能测试

对图书回收申请提交与审核流程进行测试，验证用户提交的闲置图书信息能否完整传递至管理员端。检验审核状态变更后用户端回收记录的同步更新效果。图书回收测试如表6-3所示。

表6-3图书回收测试用例表

6.3.4 投诉反馈功能测试

对投诉反馈的提交与处理机制进行测试，验证用户提交的反馈内容能够准确记录并传递至管理员端。检验处理结果返回后用户端查看功能的正常运作。投诉反馈测试如表6-4所示。

表6-4投诉反馈测试用例表

6.3.5 管理纸质图书订单功能测试

对纸质图书订单管理模块进行测试，验证管理员对订单状态的查询筛选与更新操作。检验发货信息填写后订单状态变更的准确性以及前端同步效果。管理纸质图书订单测试如表6-5所示。

表6-5管理纸质图书订单测试用例表

6.3.6 管理图书回收功能测试

对图书回收管理模块进行测试，验证管理员对回收申请的审核处理能力。检验报价填写后用户端同步显示的准确性，以及回收状态更新后用户端查看功能。管理图书回收测试如表6-6所示。

表6-6管理图书回收测试用例表

6.3.7 管理通知公告功能测试

对通知公告管理模块进行测试，验证管理员对公告内容的发布与维护能力。检验公告发布后用户端首页展示的及时性与准确性，以及编辑更新后内容的同步效果。管理通知公告测试如表6-7所示。

表6-7管理通知公告测试用例表

测试结论

系统功能测试包括纸质图书购买、电子图书购买、图书回收、投诉反馈、管理纸质图书订单、管理图书回收、管理通知公告7个主要模块。测试过程中各个模块的功能运行正常，测试用例的通过率为预期值。纸质图书购买的库存校验、未登录处理等逻辑正确，电子图书购买支付成功后文件交付及时。图书回收及投诉反馈的申请提交、审核处理、状态更新链条完整。管理员端订单处理、回收管理、公告发布等操作都可以正确地完成数据的变更以及前端的同步。实际检测结果和预期结果一致，没有出现阻塞性缺陷。

项目分享：大家可自取用于参考学习，获取方式可私信哦！