第一章 绪论
1.1 研究背景与意义
随着本地生活服务数字化进程的加快，便利店作为社区零售的重要节点，其外卖业务规模也越来越大。传统便利店运营模式下，商品管理、订单处理、配送调度等环节大多依靠人工记录和分散的线下操作，信息传递存在延迟和误差。相关研究认为O2O模式的发展会使得零售终端的数字化能力有更高的要求1。由于外卖平台流量红利逐渐消失，便利店自身的后台管理效率成了决定履约质量、客户黏性的重要因素。目前很多小型连锁便利店仍然使用纸质单据或者通用进销存系统来处理外卖订单，没有专门针对外卖场景设计的管理工具，造成拣货、打包、配送等环节衔接不畅。创建一个以便利店外卖业务为依托的后台管理系统，把商品信息、促销活动、订单流转、配送调度等各个模块整合到同一个平台上，从而达到业务数据实时同步、状态跟踪的目的。该系统研究及应用可以降低人工操作造成的差错率，规范接单到配送的整个业务流程，改善店内人力资源和库存资源的配置方式2。从而提高消费者的购物体验。系统设计和实现过程中产生的模块化方案，可以给类似小型零售业态的数字化转型提供可借鉴的技术途径和管理方式3。
1.2 国内外研究现状
国内有关便利店数字化管理以及O2O外卖系统方面的研究已经取得一定的成果。早期的研究大多集中在大型连锁便利店整体的ERP系统建设上，近些年来开始向轻量化、模块化外卖业务支撑系统转变。学者们将订单管理、库存预警、配送调度等结合起来，解决了便利店外卖业务中信息孤岛的问题。
李瑶等对校园场景下O2O服务需求进行分析，并设计出一个包含商品浏览、在线下单和订单跟踪等主要功能的校园服务平台，使用前后端分离的方式进行开发，验证了轻量级框架在O2O业务中的应用4。柳萌对于社区优选商城系统的商品管理模块以及促销策略的联动机制进行了研究，利用设置限时折扣和满减活动的方式，提高了用户下单转化率，其促销策略的设计思路也可以给便利店外卖场景下的商品推广提供一定的借鉴5。刘仁华就O2O模式下的外卖系统展开研究，重点放在了订单分配算法和配送路径优化上，提出了一种基于动态信息的订单匹配方法，该研究虽然偏重于算法方面，但是其中有关订单状态流转、骑手任务分配的逻辑设计，给本系统配送大厅和骑手接单模块的流程设计提供理论依据6。韦庆满就连锁便利店的管理需求，创建并执行了一套包含进销存、会员管理以及销售分析等功用的后台系统，重视数据一致性对于零售管理的重要作用，其数据库设计思想给便利店外卖业务商品信息和订单信息的准确同步提供参考7。从国内的研究现状来看，目前有关订单分配算法以及大型连锁管理系统的成果较多，但是针对小型便利店外卖业务中"店员、骑手、管理员"三者之间协同工作的后台管理系统具体实现的研究较少，在拣货和打包环节的状态反馈机制上还有待完善。本系统在功能上又增加了一部分对店员用户进行拣货信息、打包信息的管理模块，加强了业务执行过程的闭环控制。
国外对于零售终端管理系统和外卖配送服务的研究开始得比较早，主要研究的是智能化技术的应用以及服务质量的提高。Hurricane Commerce被选作ETrak配送管理系统合作伙伴，该系统重视配送过程中数据的实时性以及文档电子化管理，依靠标准化接口达成各个角色之间信息共享的目的，这样的设计思想对于跨角色信息流转的系统架构有着启示作用8。但丁等人就人工智能驱动的无人便利店展开研究，发现智能技术可以凭借缩减等候时间以及改善商品陈列的方式改进消费者的体验品质，这一研究表现出零售技术演进的趋向，由自动化朝着智能化迈进9。Schwartz等人的研究主要关注的是加拿大安大略省将酒类销售扩展到便利店之后网点分布的变化，虽然该研究主要关注公共健康问题，但是它所采用的跟踪方法给人们理解零售业务扩张给后台管理带来新需求的社会学视角10。Tuson等人对西澳大利亚州立法改革之后电子烟在实体店和便利店的零售可得性进行研究，发现监管政策对零售商品结构产生影响之后，就会传导到库存管理上，这就意味着后台系统要具有灵活的商品类型配置能力来应对品类的变化11。Bhinder就人工智能辅助的食品订购与配送系统展开研究，主要针对智能排序和个性化推荐对客户满意度产生的影响展开分析，并且给出建议订单管理系统需要具备动态适应消费者偏好的能力12。国外有关配送管理系统数据标准化和智能化推荐的研究比较深入，给本系统中配送大厅和骑手接单模块的功能定位提供了一个参照。但是这些研究大多面向大型平台或者技术密集型的场景，对于小型便利店后台管理系统低成本、易操作的实现方案很少涉及。
1.3 主要研究内容
研究以便利店外卖后台管理系统为对象，从系统需求分析、系统架构设计、系统功能模块实现和系统测试验证四个方面进行研究。首先对便利店外卖业务的实际情况进行梳理，找出管理员、店员用户和骑手用户在商品管理、订单处理、配送调度等各个环节的操作需求，进而进行可行性分析以及功能需求的定义。然后根据Django框架搭建后端业务逻辑，用Vue框架创建前端交互界面，使用MySQL数据库保存数据，并且前后端之间通过接口来互相传递数据。系统主要功能模块按照角色分为管理员端、店员用户端和骑手用户端，管理员端主要是对商品类型、商品信息、促销策略等基础数据进行配置和管理，对订单和配送的整体情况进行监督，店员用户端主要是对商品信息进行维护、促销策略进行执行、订单拣货打包，将待配送订单推送到配送大厅，骑手用户端是从配送大厅接到订单并更新配送进度。在系统实现的过程中，就商品库存预警、订单状态流转跟踪、配送进度反馈这些重要的业务节点展开详细的规划。完成系统的开发之后，编写测试用例对主要的功能模块进行测试，分析测试结果来评价系统对于便利店外卖业务需求的满足情况。
第二章 相关技术介绍
2.1 Django框架
Django是一个用Python语言编写的高级Web开发框架，采用MTV模式组织代码结构。该框架自带了对象关系映射组件、URL路由分发机制和模板引擎，可以快速创建数据库驱动的Web应用。Django用以完成便利店外卖后台管理系统后端业务逻辑的封装以及请求响应工作。对商品信息管理、促销策略配置、订单状态变更等主要业务操作进行定义，用模型类和数据库表建立映射关系，用视图函数或者类视图接收前端请求，调用相应的业务处理方法。Django所具有的管理后台，在一定程度上减轻了基础数据的维护工作量，并且内置的身份认证以及权限控制机制给区分管理员、店员用户和骑手用户的操作权限赋予了基本的支持13。框架本身的模块化设计可以使得商品、订单、配送等各个业务模块独立开发、集成，从而减小了系统各个功能之间的耦合程度。
2.2 Vue框架
Vue是一个用于创建用户界面的渐进式前端框架，使用组件化的方式进行开发，支持声明式的渲染和响应式的数据绑定。在便利店外卖后台管理系统当中，Vue主要用来创建各个角色的操作界面的视觉展示以及交互逻辑。将页面拆分出可以被复用的组件，即商品列表组件、订单卡片组件、表单输入组件等等，让代码更容易维护和开发。Vue框架提供的路由管理功能可以实现不同功能页面之间的无刷新切换，用户在商品信息管理、促销策略管理、配送大厅等各个模块之间操作时会得到比较流畅的交互体验。结合状态管理库，可以对用户的登录状态、购物车信息、订单数据等全局状态进行统一的管理，从而避免各个组件间的数据传递混乱的情况发生。Vue的响应式特性使数据的变化可以立即反映到界面上，店员用户修改商品库存之后，相关的列表页面会立刻更新14。
2.3 MySQL数据库
MySQL是关系型数据库管理系统，以稳定、高效著称，在Web应用中被广泛使用。本系统采用MySQL来实现数据的持久化存储，将商品信息、订单记录、用户数据、配送状态等主要的业务数据存入其中15。设计合理的数据库表结构，建立商品信息表和订单信息表之间的关联、订单信息表和配送大厅表之间的状态流转关系。MySQL支持事务处理，在订单创建、库存扣减、状态更新等需要保证数据一致性的操作场景中，用事务机制来保证多个数据表之间的操作要么全部成功，要么全部回滚。系统用MySQL的索引优化机制，对订单编号、商品编号等经常被查询的字段创建索引，加快了列表查询和详情检索的速度。数据库定时备份功能给业务数据安全提供基本保障。
2.4 前后端分离架构
前后端分离就是把用户的界面展示和业务逻辑处理解耦的一种系统组织方式。在这种架构下，后端只做数据接口的提供，前端负责页面的渲染以及用户的交互。便利店外卖后台管理系统用前后端分离的方式搭建起来，Django后端以RESTful风格的接口向前端推送JSON格式的数据，Vue前端用异步请求去获取数据并实现动态更新页面视图的功能。这样一种架构模式使前后端开发同时开始，后端主要是商品管理、订单处理、配送调度等业务逻辑和数据库交互优化的工作，前端主要是各个角色的界面布局和操作流程的设计。前后端用明确的接口契约来协作，接口文档中给出了请求参数和响应数据的格式规范。当后面系统需要扩展功能或者接入其他终端的时候，后端接口可以被复用，不需要重新开发业务逻辑。架构上职责的划分使系统出现问题时可以更快地找到是数据接口问题还是界面渲染问题，有利于日常维护和功能迭代16。
第三章 系统分析
3.1 功能需求分析
3.1.1 店员用户角色功能需求
店员用户是便利店日常经营中商品维护、订单处理和促销执行的负责人。该角色可以在商品信息管理模块中查看商品列表，对商品进行名称查询过滤，也可以查看单个商品的详细信息。促销策略管理模块可以显示某个商品所对应的促销价格和促销日期。订单信息管理模块可以显示所有外卖订单，店员可以查看订单信息然后发起拣货操作。拣货信息管理模块保存拣货数量、拣货备注，拣货结束后将订单发送到打包环节。打包信息管理模块记录打包图片和打包备注，完成后把订单发布到配送大厅。配送大厅管理模块可以展示出待配送的订单信息，即订单的配送地址和客户的联系电话。骑手接单管理模块显示被骑手接取的订单和配送进度。店员用户用例图如图3-1所示。
图3-1店员用户用例图
3.1.2 骑手用户角色功能需求
骑手用户在系统中承担订单配送的执行任务。配送大厅管理功能向骑手展示所有待配送的订单列表，骑手可以根据自身位置与配送范围选择合适的订单进行接单操作。接单后，订单状态从待配送变更为配送中。骑手接单管理功能展示骑手已经接取的订单列表，骑手需要在此模块中更新配送进度，例如标记为已取货、配送中或已送达。系统记录骑手的接单时间与配送完成时间，为后续的配送效率分析提供数据支持。骑手用户用例图如图3-2所示。
图3-2骑手用户用例图
3.1.3 管理员角色功能需求
管理员用户具有系统最高权限，可以进行基础数据的设置以及业务监督。商品类型管理模块可以实现管理员对商品类型的添加、修改、删除功能，类型信息包含类型名称和创建时间。商品信息管理模块除了常规的增删改查之外，还具有库存预警的功能，即当商品库存数量低于设定的阈值时会弹出提示。促销策略管理模块管理员可以查看所有的商品促销信息，即促销价格、促销日期和促销原因。订单信息管理模块显示所有订单，管理员可以查看订单详情并执行拣货。配送大厅管理模块管理员可以查看待配送的订单，为订单指派骑手。骑手接单管理模块管理员可以查看所有的骑手接单记录以及配送进度。拣货信息管理模块和打包信息管理模块的管理员可以查看店员的工作完成情况。管理员用户用例图如图3-3所示。
图3-3管理员用例图
3.2 可行性分析
3.2.1 技术可行性
系统使用Django、Vue、MySQL这三个开源技术，这三个开源技术都是社区活跃的，并且文档也十分丰富。Django框架自带的对象关系映射以及数据校验功能，可以很好地满足便利店外卖业务中商品、订单等数据的管理要求。Vue框架的组件化开发方式适合用来创建多角色、多模块的管理界面。MySQL数据库给中小型Web应用的数据存储和查询提供足够的支持。开发环境可以利用本地计算机搭建起来，不需要另外的硬件投入。因此系统从技术上是可行的。
3.2.2 操作可行性
系统界面设计采用后台管理系统通用布局，各个功能入口用侧边导航栏的形式组织起来，用户经过简单的引导就可以掌握基本的操作。店员用户主要是对商品信息进行增删改查以及订单的拣货打包操作，操作路径较短。骑手用户只包含配送大厅接单、配送进度更新，交互过程比较简单。管理员做基础数据的设置以及业务的监督，操作频率低。系统的操作方式符合目标用户日常的计算机使用习惯，具有操作可行性。
3.2.3 经济可行性
系统开发所用到的软件工具都是免费的，开发人员可以使用现有的计算机设备来完成编码和测试。系统部署之后可以运行在基础服务器上，不需要购买昂贵的专用硬件。系统上线以后，可以提高订单处理速度并减少人工核对差错，从而给便利店带来间接的经济效益。相比于大型商用零售管理系统，该系统的开发成本低、维护费用低，具有经济性。
第四章 系统设计
4.1 系统架构设计
系统采用前后端分离的分层结构，自上而下分为用户界面层、应用服务层、数据持久层和系统支持层。用户界面层采用Vue进行开发，运行在浏览器上，实现对用户输入和反馈信息的处理。应用服务层使用Django开发，对商品管理、订单处理、促销配置等业务逻辑进行封装，以RESTful API的形式对外提供服务。数据持久层使用MySQL数据库来存储业务数据，用Django ORM实现对象关系映射。系统支持层包含日志记录、异常处理以及安全认证这些基本的功能。用户界面层使用HTTP协议调用应用服务层的接口，应用服务层使用数据库连接池访问数据持久层。分层架构确定了各个层次的职责边界，上层依靠下层接口，下层不会知道上层具体的实现方式。系统架构图如图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 库存预警处理流程设计
系统每日定时扫描商品信息表中的库存数量字段，将库存数量小于5的商品记录提取出来。若存在预警商品，管理员登录后系统弹窗提示预警数量与具体商品名称。管理员查看预警商品后可以进行补货操作或调整预警阈值。库存预警处理流程图如图4-7所示。
图4-7库存预警处理流程图
4.4 数据库设计
4.4.1 概念模型设计
概念模型设计起到从现实业务需求到数据库结构转换的作用，它的主要价值就是提供一个独立于具体的数据库管理系统的数据视图17。通过对业务场景中实体及实体间的联系进行识别，就可以得到一个概念模型，该模型可以很好地反映数据对象间的关系。实体描述的是具有相同属性特征的事物集合，联系是表示实体之间业务关系的，常见的有三种类型，即一对一、一对多和多对多。本系统用E-R图来表示概念模型。根据对便利店外卖业务流程的分析，实体有商品信息、订单信息、促销策略、拣货信息、打包信息、配送大厅、骑手接单、商品类型、店员用户和骑手用户。上述实体包含商品上架、下单等全部过程。商品信息和订单信息以商品编号为查询依据，订单信息经由拣货信息、打包信息逐步传递到配送大厅，骑手用户通过接单操作把配送大厅中的订单转移到骑手接单记录上。全局E-R模型如图4-8所示。
图4-8全局ER图
根据系统分析，系统的主要实体有：商品信息、订单信息、促销策略、拣货信息、打包信息、配送大厅、骑手接单、商品类型、店员用户、骑手用户，各个实体具体的属性如下图所示。
（1）商品信息实体主要包括商品信息id、商品名称、商品编号、商品类型、商品价格、库存数量等。如图4-9所示。
图4-9商品信息实体属性图
（2）订单信息实体主要包括订单信息id、订单编号、商品编号、商品名称、商品价格、购买数量等。如图4-10所示。
图4-10订单信息实体属性图
（3）促销策略实体主要包括促销策略id、商品名称、商品类型、商品价格、促销价格、促销日期等。如图4-11所示。
图4-11促销策略实体属性图
（4）拣货信息实体主要包括拣货信息id、订单编号、商品编号、商品名称、拣货数量、拣货备注等。如图4-12所示。
图4-12拣货信息实体属性图
（5）打包信息实体主要包括打包信息id、订单编号、商品编号、商品名称、打包图片、打包备注等。如图4-13所示。
图4-13打包信息实体属性图
（6）配送大厅实体主要包括配送大厅id、订单编号、商品编号、商品名称、商品价格、配送地址等。如图4-14所示。
图4-14配送大厅实体属性图
（7）骑手接单实体主要包括骑手接单id、订单编号、商品编号、商品名称、骑手用户、配送进度等。如图4-15所示。
图4-15骑手接单实体属性图
（8）商品类型实体主要包括商品类型id、商品类型、创建时间、更新时间等。如图4-16所示。
图4-16商品类型实体属性图
（9）店员用户实体主要包括店员用户id、店员姓名、店员工号、电话、审核状态等。如图4-17所示。
图4-17店员用户实体属性图
（10）骑手用户实体主要包括骑手用户id、骑手姓名、骑手电话、配送范围、审核状态等。如图4-18所示。
图4-18骑手用户实体属性图
4.4.2 数据库表设计
数据库逻辑设计把概念模型中实体和联系转换成MySQL数据库支持的表结构。根据E-R图中定义的实体属性和实体间的关系，为每一个实体创建对应的表，并确定主键、外键和索引策略18。商品信息表中商品类型字段是商品类型表主键的外键，保证商品分类数据的一致性。订单信息表中店员用户字段与店员用户表建立关联，表示该订单是由哪个店员处理的。配送大厅表和骑手接单表之间用订单编号来建立关联，配送大厅中的订单被骑手接取之后，接单记录就会写入骑手接单表。为了提高查询效率，将经常被查询到的订单编号、商品编号等字段做成普通索引。各个数据表的设计都符合第三范式，消除数据冗余以及更新异常。
（1）商品信息表主要用于存储便利店在售商品的基本数据。主要包括商品信息id、商品名称、商品编号、商品类型、商品价格、库存数量、摆放位置、商品图片等字段。如表4-1所示。
表4-1商品信息表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 商品信息id | int | 11 | 主键 |
| 2 | 商品名称 | varchar | 64 | 商品名称 |
| 3 | 商品编号 | varchar | 64 | 商品编号 |
| 4 | 商品类型 | varchar | 64 | 商品类型 |
| 5 | 商品价格 | double | - | 商品价格 |
| 6 | 库存数量 | double | - | 库存数量 |
| 7 | 摆放位置 | varchar | 64 | 摆放位置 |
| 8 | 商品图片 | varchar | 255 | 商品图片 |
| 9 | 创建时间 | datetime | - | 创建时间 |
（2）订单信息表主要用于记录外卖平台推送的顾客订单数据。主要包括订单信息id、店员用户、订单编号、商品编号、商品名称、商品价格、购买数量、配送地址、客户电话等字段。如表4-2所示。
表4-2订单信息表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 订单信息id | int | 11 | 主键 |
| 2 | 店员用户 | int | 11 | 处理订单的店员 |
| 3 | 订单编号 | varchar | 64 | 订单编号 |
| 4 | 商品编号 | varchar | 64 | 商品编号 |
| 5 | 商品名称 | varchar | 64 | 商品名称 |
| 6 | 商品价格 | double | - | 商品价格 |
| 7 | 购买数量 | double | - | 购买数量 |
| 8 | 配送地址 | varchar | 64 | 配送地址 |
| 9 | 客户电话 | varchar | 64 | 客户电话 |
（3）促销策略表主要用于存储商品参与促销活动的配置信息。主要包括促销策略id、商品名称、商品类型、商品价格、库存数量、摆放位置、促销日期、促销价格、促销原因等字段。如表4-3所示。
表4-3促销策略表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 促销策略id | int | 11 | 主键 |
| 2 | 商品名称 | varchar | 64 | 商品名称 |
| 3 | 商品类型 | varchar | 64 | 商品类型 |
| 4 | 商品价格 | double | - | 商品价格 |
| 5 | 库存数量 | double | - | 库存数量 |
| 6 | 摆放位置 | varchar | 64 | 摆放位置 |
| 7 | 促销日期 | date | - | 促销日期 |
| 8 | 促销价格 | double | - | 促销价格 |
| 9 | 促销原因 | text | 65535 | 促销原因 |
（4）拣货信息表主要用于记录店员执行拣货操作的过程数据。主要包括拣货信息id、店员用户、订单编号、商品编号、商品名称、商品价格、购买数量、拣货数量、拣货备注等字段。如表4-4所示。
表4-4拣货信息表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 拣货信息id | int | 11 | 主键 |
| 2 | 店员用户 | int | 11 | 执行拣货的店员 |
| 3 | 订单编号 | varchar | 64 | 订单编号 |
| 4 | 商品编号 | varchar | 64 | 商品编号 |
| 5 | 商品名称 | varchar | 64 | 商品名称 |
| 6 | 商品价格 | double | - | 商品价格 |
| 7 | 购买数量 | double | - | 购买数量 |
| 8 | 拣货数量 | double | - | 拣货数量 |
| 9 | 拣货备注 | text | 65535 | 拣货备注 |
（5）打包信息表主要用于记录店员完成商品打包的操作信息。主要包括打包信息id、店员用户、订单编号、商品编号、商品名称、商品价格、购买数量、打包备注、打包图片等字段。如表4-5所示。
表4-5打包信息表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 打包信息id | int | 11 | 主键 |
| 2 | 店员用户 | int | 11 | 执行打包的店员 |
| 3 | 订单编号 | varchar | 64 | 订单编号 |
| 4 | 商品编号 | varchar | 64 | 商品编号 |
| 5 | 商品名称 | varchar | 64 | 商品名称 |
| 6 | 商品价格 | double | - | 商品价格 |
| 7 | 购买数量 | double | - | 购买数量 |
| 8 | 打包备注 | text | 65535 | 打包备注 |
| 9 | 打包图片 | varchar | 255 | 打包图片 |
（6）配送大厅表主要用于存储已完成打包并等待骑手接取的订单。主要包括配送大厅id、店员用户、订单编号、商品编号、商品名称、商品价格、购买数量、商家地址、配送地址、客户电话等字段。如表4-6所示。
表4-6配送大厅表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 配送大厅id | int | 11 | 主键 |
| 2 | 店员用户 | int | 11 | 发布订单的店员 |
| 3 | 订单编号 | varchar | 64 | 订单编号 |
| 4 | 商品编号 | varchar | 64 | 商品编号 |
| 5 | 商品名称 | varchar | 64 | 商品名称 |
| 6 | 商品价格 | double | - | 商品价格 |
| 7 | 购买数量 | double | - | 购买数量 |
| 8 | 配送地址 | varchar | 64 | 配送地址 |
| 9 | 客户电话 | varchar | 64 | 客户电话 |
（7）骑手接单表主要用于记录骑手接取订单后的配送执行信息。主要包括骑手接单id、店员用户、订单编号、商品编号、商品名称、商品价格、购买数量、骑手用户、接单日期、配送进度等字段。如表4-7所示。
表4-7骑手接单表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 骑手接单id | int | 11 | 主键 |
| 2 | 店员用户 | int | 11 | 发布订单的店员 |
| 3 | 订单编号 | varchar | 64 | 订单编号 |
| 4 | 商品编号 | varchar | 64 | 商品编号 |
| 5 | 商品名称 | varchar | 64 | 商品名称 |
| 6 | 商品价格 | double | - | 商品价格 |
| 7 | 购买数量 | double | - | 购买数量 |
| 8 | 骑手用户 | int | 11 | 接单骑手 |
| 9 | 配送进度 | varchar | 64 | 配送进度 |
（8）商品类型表主要用于存储商品所属的分类信息。主要包括商品类型id、商品类型、创建时间、更新时间等字段。如表4-8所示。
表4-8商品类型表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 商品类型id | int | 11 | 主键 |
| 2 | 商品类型 | varchar | 64 | 商品类型 |
| 3 | 创建时间 | datetime | - | 创建时间 |
| 4 | 更新时间 | timestamp | - | 更新时间 |
（9）店员用户表主要用于存储店员角色的账户与身份信息。主要包括店员用户id、店员姓名、店员工号、电话、审核状态、用户id等字段。如表4-9所示。
表4-9店员用户表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 店员用户id | int | 11 | 主键 |
| 2 | 店员姓名 | varchar | 64 | 店员姓名 |
| 3 | 店员工号 | varchar | 64 | 店员工号 |
| 4 | 电话 | varchar | 64 | 电话 |
| 5 | 审核状态 | varchar | 16 | 审核状态 |
| 6 | 用户id | int | 11 | 关联用户账户 |
（10）骑手用户表主要用于存储骑手角色的账户与配送资质信息。主要包括骑手用户id、骑手姓名、骑手电话、配送范围、审核状态、用户id等字段。如表4-10所示。
表4-10骑手用户表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 骑手用户id | int | 11 | 主键 |
| 2 | 骑手姓名 | varchar | 64 | 骑手姓名 |
| 3 | 骑手电话 | varchar | 64 | 骑手电话 |
| 4 | 配送范围 | varchar | 64 | 配送范围 |
| 5 | 审核状态 | varchar | 16 | 审核状态 |
| 6 | 用户id | int | 11 | 关联用户账户 |
第五章 系统实现
5.1 店员用户功能实现
5.1.1 商品信息管理功能实现
店员通过商品信息管理模块维护商品数据。Controller类Commodity_information继承基础Controller，调用服务层Commodity_information的Get_list方法获取商品列表数据，并渲染commodity_information/list.html页面展示。商品信息界面如图5-1所示。
图5-1商品信息界面
核心代码实现如下：
classCommodity_information(controllerClass):
definit(self, config={}):
config_init= {
"tpl":"./commodity_information/",
"service": "commodity_information",
}
super(Commodity_information,self).init(config_init)
5.1.2 促销策略管理功能实现
促销策略管理允许店员配置商品促销活动。Promotional_strategy控制器通过Get_list方法查询促销策略数据，前端页面支持新增、修改和删除策略，后端调用服务层的Add、Set和Del方法完成数据操作。促销策略界面如图5-2所示。
图5-2促销策略界面
核心代码实现如下：
classPromotional_strategy(controllerClass):
definit(self, config={}):
config_init= {
"tpl":"./promotional_strategy/",
"service": "promotional_strategy",
}
super(Promotional_strategy,self).init(config_init)
5.1.3 订单信息管理功能实现
订单信息管理模块展示所有用户订单。Order_information控制器接收前端查询参数，调用服务层Get_list方法从数据库获取订单列表，支持按订单状态筛选，数据返回到order_information/list.html渲染。订单信息界面如图5-3所示。
图5-3订单信息界面
核心代码实现如下：
classOrder_information(controllerClass):
definit(self, config={}):
config_init= {
"tpl":"./order_information/",
"service": "order_information",
}
super(Order_information,self).init(config_init)
5.1.4 拣货信息管理功能实现
店员根据订单生成拣货任务。Picking_information控制器重写Add_before方法，在添加拣货记录前校验商品库存是否充足，库存不足时返回错误提示，通过后调用服务层Add方法保存数据。拣货信息界面如图5-4所示。
图5-4拣货信息界面
核心代码实现如下：
defAdd_before(self,ctx):
body =ctx.bodyservice =self.service
select =service.run("SELECTMAX(picking_information_id) AS max FROMpicking_information")
max = select[0]["max"]
ifmax != None:
ret =service.run("SELECTcount(*) as count FROMcommodity_information...")if ret[0]["count"] > 0:
return {"code": 30000, "message": "库存不足~"}
return {"code": 0}
5.1.5 打包信息管理功能实现
打包信息管理记录商品打包状态。Packing_information控制器继承基础Controller，通过Get_list方法查询待打包订单列表，店员更新打包状态时调用Set方法修改数据库记录。打包信息界面如图5-5所示。
图5-5打包信息界面
核心代码实现如下：
classPacking_information(controllerClass):
definit(self, config={}):
config_init= {
"tpl":"./packing_information/",
"service": "packing_information",
}
super(Packing_information,self).init(config_init)
5.1.6 配送大厅管理功能实现
配送大厅展示待配送订单供店员分配。Distribution_hall控制器调用服务层Get_list方法获取状态为"待配送"的订单列表，店员确认分配后调用Set方法更新订单配送状态。配送大厅界面如图5-6所示。
图5-6配送大厅界面
核心代码实现如下：
classDistribution_hall(controllerClass):
definit(self, config={}):
config_init= {
"tpl":"./distribution_hall/",
"service": "distribution_hall",
}
super(Distribution_hall,self).init(config_init)
5.1.7 骑手接单管理功能实现
店员可查看骑手接单情况并分配订单。Ruser_iders_take_orders控制器通过Get_list方法查询已接单记录，支持按骑手和订单状态筛选，店员可手动改派订单调用Set方法更新骑手信息。骑手接单界面如图5-7所示。
图5-7骑手接单界面
核心代码实现如下：
classRuser_iders_take_orders(controllerClass):
definit(self, config={}):
config_init= {
"tpl":"./ruser_iders_take_orders/",
"service": "ruser_iders_take_orders",
}
super(Ruser_iders_take_orders,self).init(config_init)
5.2 骑手用户功能实现
5.2.1 配送大厅管理功能实现
骑手登录后查看配送大厅的待接单任务。Distribution_hall控制器根据骑手位置和状态筛选订单，调用Get_list方法获取可抢订单列表，骑手点击接单后调用Set方法将订单状态改为"已接单"。配送大厅界面如图5-8所示。
图5-8配送大厅界面
核心代码实现如下：
classDistribution_hall(controllerClass):
definit(self, config={}):
config_init= {
"tpl":"./distribution_hall/",
"service": "distribution_hall",
}
super(Distribution_hall,self).init(config_init)
5.2.2 骑手接单管理功能实现
骑手管理自己已接取的订单。Ruser_iders_take_orders控制器调用Get_list方法查询当前骑手的接单记录，支持查看订单详情和配送状态，骑手更新配送进度时调用Set方法修改订单状态。骑手接单界面如图5-9所示。
图5-9骑手接单界面
核心代码实现如下：
classRuser_iders_take_orders(controllerClass):
definit(self, config={}):
config_init= {
"tpl":"./ruser_iders_take_orders/",
"service": "ruser_iders_take_orders",
}
super(Ruser_iders_take_orders,self).init(config_init)
5.3 管理员功能实现
5.3.1 商品类型管理功能实现
管理员通过商品类型管理维护商品分类。Product_type控制器调用服务层Add、Set和Del方法实现类型的增删改查，前端页面展示类型树形结构，管理员可设置类型的排序和状态。商品类型界面如图5-10所示。
图5-10商品类型界面
核心代码实现如下：
classProduct_type(controllerClass):
definit(self, config={}):
config_init= {
"tpl":"./product_type/",
"service": "product_type",
}
super(Product_type,self).init(config_init)
5.3.2 商品信息管理功能实现
管理员拥有商品管理的完整权限。Commodity_information控制器调用Get_list方法查询所有商品，支持按类型、价格筛选，管理员调用Add方法添加商品，Set方法修改商品信息，Del方法下架商品。商品信息界面如图5-11所示。
图5-11商品信息界面
核心代码实现如下：
classCommodity_information(controllerClass):
definit(self, config={}):
config_init= {
"tpl":"./commodity_information/",
"service": "commodity_information",
}
super(Commodity_information,self).init(config_init)
5.3.3 促销策略管理功能实现
管理员配置和管理全平台的促销活动。Promotional_strategy控制器调用Get_list方法展示所有策略，管理员通过Add方法创建新活动，Set方法调整活动规则和时间，Del方法结束或删除活动。促销策略界面如图5-12所示。
图5-12促销策略界面
核心代码实现如下：
classPromotional_strategy(controllerClass):
definit(self, config={}):
config_init= {
"tpl":"./promotional_strategy/",
"service": "promotional_strategy",
}
super(Promotional_strategy,self).init(config_init)
5.3.4 订单信息管理功能实现
管理员查看并处理所有订单。Order_information控制器调用Get_list方法获取全平台订单数据，支持复杂条件筛选，管理员可调用Set方法修改订单状态或处理异常订单。订单信息界面如图5-13所示。
图5-13订单信息界面
核心代码实现如下：
classOrder_information(controllerClass):
definit(self, config={}):
config_init= {
"tpl":"./order_information/",
"service": "order_information",
}
super(Order_information,self).init(config_init)
5.3.5 配送大厅管理功能实现
管理员监控所有待配送订单。Distribution_hall控制器调用Get_list方法查看全部待分配订单，管理员可手动指派骑手或调整配送优先级，通过Set方法更新订单的配送信息。配送大厅界面如图5-14所示。
图5-14配送大厅界面
核心代码实现如下：
classDistribution_hall(controllerClass):
definit(self, config={}):
config_init= {
"tpl":"./distribution_hall/",
"service": "distribution_hall",
}
super(Distribution_hall,self).init(config_init)
5.3.6 骑手接单管理功能实现
管理员查看和管理所有骑手的接单记录。Ruser_iders_take_orders控制器调用Get_list方法获取骑手接单汇总数据，支持按骑手和时间段统计，管理员可调用Set方法调整接单状态或分配订单。骑手接单界面如图5-15所示。
图5-15骑手接单界面
核心代码实现如下：
classRuser_iders_take_orders(controllerClass):
definit(self, config={}):
config_init= {
"tpl":"./ruser_iders_take_orders/",
"service": "ruser_iders_take_orders",
}
super(Ruser_iders_take_orders,self).init(config_init)
5.3.7 拣货信息管理功能实现
管理员监控全店拣货任务执行情况。Picking_information控制器调用Get_list方法获取所有拣货记录，管理员可查看拣货员效率数据，调用Set方法调整任务优先级或重新分配拣货任务。拣货信息界面如图5-16所示。
图5-16拣货信息界面
核心代码实现如下：
classPicking_information(controllerClass):
definit(self, config={}):
config_init= {
"tpl":"./picking_information/",
"service": "picking_information",
}
super(Picking_information,self).init(config_init)
5.3.8 打包信息管理功能实现
管理员查看打包进度和质量管理。Packing_information控制器调用Get_list方法查询打包任务列表，支持按打包员和状态筛选，管理员调用Set方法更新打包状态或标记异常打包记录。打包信息界面如图5-17所示。
图5-17打包信息界面
核心代码实现如下：
classPacking_information(controllerClass):
definit(self, config={}):
config_init= {
"tpl":"./packing_information/",
"service": "packing_information",
}
super(Packing_information,self).init(config_init)
第六章 系统测试
6.1 测试目的
系统测试是检验便利店外卖后台管理系统是否达到需求分析阶段所确定的功能和非功能需求。测试过程中主要关注各个角色权限是否正确，保证店员不能进行管理员的删除操作，骑手不能修改商品信息。业务流程完整性的测试是对订单从产生到交付的整个过程进行的，主要查看订单信息在拣货、打包、配送等各个环节的状态是否同步。数据一致性测试主要是对商品信息表和订单信息表之间的关联字段进行检查，看促销策略生效或者过期时商品价格是否会改变。经过系统的测试执行，找出可能存在的功能缺陷以及逻辑错误，给系统正式上线提供质量保证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库存预警测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 预警触发 | 将某商品库存修改为3并保存 | 管理员登录后弹出预警提示 | 符合预期 |
| 预警确认 | 管理员点击确定关闭弹窗 | 预警提示关闭 | 符合预期 |
| 补货后恢复 | 将预警商品库存修改为10并保存 | 下次登录不再弹出该商品预警 | 符合预期 |
测试结论
商品信息管理模块查询、重置功能工作正常，详情弹窗可以正确地显示出商品的所有信息。在订单处理流程中拣货、打包环节的状态流转与预期一致，订单从信息管理模块出发经过拣货、打包之后成功推送到配送大厅。促销策略配置模块可以正确保存新增的促销策略，并且可以检测日期冲突，促销到期之后商品价格会自动恢复到原来的售价。配送接单测试时骑手接单操作正确地更新了订单状态并把订单转移到了骑手的接单列表中，配送进度更新功能也正常。库存预警机制在库存低于阈值的时候成功触发管理员弹窗提示，补货操作之后预警就不再出现了。经过测试发现的缺陷已经全部修复，系统的功能符合需求规格说明的要求，可以进行部署。