摘要
目前高校校园内学生之间代取快递、食堂带饭等跑腿服务的需求越来越大，但是传统的依靠QQ群、微信群发布信息的方式存在着信息分散、交易混乱、缺少信任机制和纠纷解决途径等问题。开发校园跑腿服务系统，对规范交易流程、保障双方权益、提高校园生活便利性有现实的必要性。本系统用Django框架和MySQL数据库来搭建，采用B/S架构，前端使用Vue技术，实现发布用户、跑腿用户和管理员三个角色的功能。发布用户可以发布跑腿订单，在未被接单之前可以取消订单，可以全程管理接单记录、取件记录、配送信息和配送记录，完成交易之后对跑腿用户进行评价或者投诉。跑腿用户根据接单记录接单，按照配送信息完成取件、配送工作，在配送记录中更新状态，服务结束获得报酬，可以提交提现申请，也可以对发布者进行评价和投诉。管理员是系统后台全流程的管理者，可以对用户的权限进行管理，可以对订单类型进行分类，可以对跑腿订单、取消订单、接单记录、取件记录、配送信息、配送记录、评价、投诉、提现申请和提现记录进行增删改查。系统运行之后，各个角色的操作流程清楚，数据流转的闭环完整，很好地解决了传统模式下信息零散和信任缺失的问题，给校园跑腿服务提供了一个高效可靠的平台支持。
关键词：Django；校园跑腿；服务系统；MySQL；B/S架构
Abstract
The need for errands like delivering packages and picking up meals from college students is on the rise. Traditional methods using QQ group or WeChat group to disseminate information have the problems of disordered information, chaotic transaction, no trust mechanism and no channel for resolving disputes. A dedicated campus errand system needs development so that transactions can be standardized, rights of students can be protected & the campus life is made easier. Developed according to Django framework, usingMysqldatabase. It is the B / S form, which uses the front-end development language ofvue; There are three roles: publishing party, errand seeking side; manager administrator. Publishing Users can post errand orders, cancel orders prior to acceptance, and oversee all steps such as order accepting records, pickup records, delivered information, and delivered record. They can also rate or make complaints about errand users after completing a deal. Errand users pick up and deliver via order acceptance record and delivery info, update status on delivery records after task fulfillment, get compensated post-service, make withdrawals, and continue having a say on publishing users by rating and complaining. Administrators run all backend systems, including managing users' permission setting, order type classification and performing create(read),update(Write)and delete (Delete)CRUD action for errands & canceled orders, acceptance records, pickup history, deliveries info, delivery success record, ratinginfo,complaints,withdrawalrequest and withdrawal success record to guarantee correct data information. After the system has been deployed, every role's operation process is clear, data can make a full loop, which solves all kinds of problems such as information disconnection and loss of credibility in the past model, it provides a very reliable platform for campus errand service.
**Key words:**Django;campus errand;service system;MySQL;B/S architecture
第一章 绪论
1.1 研究背景与意义
校园跑腿服务面向高校学生群体，传统模式下代取快递、食堂带饭等需求依赖QQ群、微信群发布信息，存在信息分散、交易混乱、信任机制缺失与纠纷处理渠道不畅等痛点1。早期部分校园论坛与简易信息平台出现后，信息获取速度有所提升，学生开始尝试线上发布任务，然而碎片化体验、交易流程不规范、双方权责不明、优质服务者难以沉淀、交易数据孤立等问题依然突出，现有方式难以满足当下学生对即时响应、操作便捷、服务可溯与安全保障的强烈需求2。开发一套专门的校园跑腿服务系统，对提高信息发布和匹配效率、减少人为沟通失误、促进服务资源实时对接有直接的改进作用，对校园生活服务流程规范、用户参与质量、社区信用生态培育等有实际的推动作用，也为其他垂直领域生活服务整合提供可操作的参考范例。
1.2 国内外研究现状
国内校园跑腿相关服务平台经历了从早期线下自发组织到线上系统化整合的演进过程。早期以校园论坛、QQ群为主要载体，信息发布与获取依赖人工筛选，效率较低。随后部分高校开始尝试开发简易的订餐或跑腿小程序，但功能较为单一3。随着移动互联网普及，基于Android与iOS平台的校园服务类应用逐渐增多，部分系统实现了订单发布、接单、评价等基础功能4。近年来，研究者围绕O2O模式在校园场景的应用展开深入探索，提出将校园外卖、跑腿服务与智慧校园建设相结合的设计思路5。一些系统引入订单分类管理、用户权限控制与数据统计分析模块，提升了平台的可维护性与扩展性6。针对校园外卖配送服务，有学者从服务设计角度出发，探讨了后疫情时代配送流程优化与用户体验提升的策略7。
国外高校及周边社区的跑腿服务实践呈现出明显的平台化与数据驱动特征。早期以社交媒体群组为基础的信息发布模式逐步被专业化服务平台取代，部分平台通过算法匹配与实时位置共享提升服务效率8。在配送服务领域，有研究关注零工经济背景下平台骑手的权益保障与工作时间管理问题，为跑腿类服务的人员管理提供了法律层面的参考9。部分教育机构尝试将人工智能引入服务流程，探索智能推荐与自动化调度机制在学生服务需求中的应用效果10。在服务质量评估方面，相关研究通过纵向跟踪与仿真模拟的方式，分析平台运行过程中服务者与用户之间的沟通质量及其对服务满意度的影响11。另有研究从经济评估视角切入，探讨校园场景下普遍性服务项目的实施策略与资源配置效率，为跑腿服务系统的可持续运行提供了理论支撑12。
1.3 主要研究内容
本课题以校园跑腿服务需求为出发点，用Django框架开发出校园跑腿服务系统，系统主要面向发布用户、跑腿用户和管理员这三个主要角色。发布用户可以进行跑腿订单发布、订单取消、接单记录查看、取件和配送记录跟踪、跑腿评价和投诉等操作；跑腿用户可以查看接单信息、配送信息、取件配送记录并更新、对跑腿进行评价、申请提现并查看提现记录；管理员可以对用户进行管理、对跑腿订单的类型进行管理、对跑腿订单的全过程进行管理、对跑腿评价和投诉进行管理、对提现进行审核。系统开发按照软件工程规范流程进行，即需求分析、总体架构设计、功能模块设计、数据库设计、系统实现和测试，使用Django框架和MySQL数据库，前端使用Vue技术，构建前后端分离的B/S架构，主要解决校园跑腿服务信息分散、交易流程不规范、信用评价缺失等问题。
第二章 相关技术介绍
2.1 Django框架
Django作为一款开源的Python Web框架，遵循MTV（Model-Template-View）设计模式，为快速构建安全可靠的Web应用提供了完整解决方案13。该框架主要依靠中间件和路由系统来运行，客户端发出HTTP请求之后，中间件会对请求做预处理，URL分发器按照事先设定好的路由规则把请求转发到相应的视图函数上，视图层执行业务逻辑，模型层完成数据库操作并返回结果给客户端。Django内置了一个强大的对象关系映射组件，开发者只需要定义模型类就可以完成数据库表结构的创建和操作，框架会把Python对象映射成SQL语句，大大简化了数据持久化层的开发工作。Django自带的跨站请求伪造保护、SQL注入防范、跨站脚本攻击过滤，保证了系统的运行过程中数据的安全。本系统采用Django作为后端开发框架，利用Django的MTV架构把业务逻辑、数据处理和界面呈现分开，用模型层来定义和关联用户、订单、配送记录等核心数据表，用视图层来处理发布用户和跑腿用户的操作请求，用模板引擎虽然没有直接用于前端渲染但是为后续管理后台扩展预留了接口，框架内置的认证系统给三大角色的权限控制提供了一个可靠的根基。
2.2 Vue框架
Vue是一套用于构建用户界面的渐进式JavaScript框架，采用响应式数据绑定与组件化开发模式，使前端开发具备高效的交互处理能力与代码复用性14。该框架的核心机制就是响应式系统，开发者声明式地定义数据模型之后，Vue会用Object.defineProperty或者Proxy来监听数据的变化，当数据发生变化的时候就会自动触发视图的更新，而不需要开发者手动去操作DOM节点。组件系统可以将界面拆分成独立可复用的单元，每一个组件都包含自己的模板、逻辑和样式，组件之间使用props传递属性、使用自定义事件进行通信，该种设计模式使得大型前端项目维护和协作更加方便。Vue还提供路由管理器Vue Router和状态管理库Vuex，前者可以实现单页应用中页面切换和路由守卫的功能，后者可以集中管理应用中多个组件共享的状态数据，解决了组件之间状态同步的问题。本系统前端使用Vue框架进行开发，用组件化的特性把跑腿订单列表、配送记录查看、评价表单等界面元素封装成独立的组件，用响应式数据绑定实现订单状态变化时页面的实时刷新，利用VueRouter完成不同功能页面之间的导航跳转，配合后端提供的API接口实现了前后端分离架构下高效的交互。
2.3 MySQL数据库技术
MySQL作为关系型数据库管理系统，以稳定性高、性能优异、支持海量数据存储与并发访问著称，广泛应用于各类Web应用的数据持久化层15。该数据库采用的是客户端-服务器结构，客户端会发送SQL语句到服务器上，服务器进行查询解析和优化执行之后再将结果返回给客户端。MySQL有很多种存储引擎，InnoDB为默认事务型存储引擎，具备ACID事务特性、行级锁、外键约束等，可以保证数据的一致性、完整性，在高并发环境下也能满足性能要求。查询优化器会依照表结构以及索引状况来挑选最佳的执行计划，从而明显加快复杂查询的速度。数据建模上MySQL支持规范化的设计思想，把业务实体抽象成二维表结构，去除了数据的冗余部分，并且保证了实体之间有引用关系。本系统使用MySQL作为后台数据库，根据业务需求设计了用户表、订单表、接单记录表、配送记录表、评价表、提现记录表等主要的数据表，使用InnoDB引擎的事务特性保证了订单创建和状态更新操作的原子性，通过外键约束来保证用户和订单之间的引用完整性，对订单状态和用户ID等经常被查询的字段建立了索引来提高检索速度，给系统的运行提供了一个稳定的数据存储以及快速的读写能力。
2.4 MTV模式
MTV模式是Django框架特有的架构设计范式，将应用程序划分为模型、模板与视图三个核心组件，通过清晰的职责划分降低代码耦合度，提升项目的可维护性与可扩展性16。模型层完成数据定义和持久化操作，每一个模型类对应数据库中的一张表，对数据字段进行封装，并且对数据的增删改查进行了定义，开发者使用模型提供的对象关系映射接口来操作数据库，不需要直接写SQL语句。模板层是用户界面的展现部分，负责页面结构以及显示样式的设计，利用模板标签和过滤器来动态渲染视图层传递过来的数据变量，把数据和展示逻辑分开。视图层是业务逻辑处理中心，接收到用户的请求之后，调用模型层来执行数据的操作，根据处理的结果选择模板进行渲染或者返回JSON格式的数据。三层分离的结构使得开发人员可以并行工作，前端工程师负责模板层界面的设计，后端工程师负责视图层业务逻辑和模型层的数据结构，彼此之间互不影响。本系统严格遵守MTV模式来组织架构，模型层定义发布用户、跑腿用户、订单、配送记录等主要业务实体，视图层处理订单发布、接单、配送状态更新等业务流程，模板层虽然没有直接用在前端界面中，但是因为遵循MTV思想而使后端服务具有明显的层次结构，各个模块职责分明，为系统的功能扩展和维护提供架构保障。
第三章 系统分析
跑腿用户在系统中可执行接单记录查看、配送信息查看、跑腿评价提交、提现申请提交、取件记录查看、配送记录更新、跑腿投诉提交、提现记录查看等操作。跑腿用户通过接单记录功能承接发布用户的跑腿任务，依据配送信息完成取件与配送环节并在配送记录中更新状态，服务完成后获得报酬并可通过提现申请提交收入提取请求，同时保留对发布用户的评价与投诉权限。跑腿用户角色用例图如图2所示。
图2跑腿用户用例图
管理员在系统中可执行用户管理、订单类型管理、跑腿订单管理、取消订单管理、接单记录管理、取件记录管理、配送信息管理、配送记录管理、跑腿评价管理、跑腿投诉管理、提现申请管理、提现记录管理等操作。管理员负责后台全流程管控，对发布用户与跑腿用户账户进行增删改查，维护订单类型分类数据，对跑腿订单与取消订单执行审核与状态调整，对接单记录、取件记录、配送信息、配送记录进行统一管理，对评价内容与投诉申请进行审核与处理，对跑腿用户的提现申请进行审批并记录提现流水。管理员角色用例图如3所示。
图3管理员用例图
3.2 可行性分析
3.2.1 技术可行性
系统使用Django框架进行后端开发，Django遵循MTV设计模式，自带对象关系映射组件以及表单验证功能，可以减少数据持久化层和业务逻辑层之间的耦合程度。前端使用Vue框架创建用户界面，采用组件化开发和响应式数据绑定来达到快速的交互响应。MySQL数据库具有事务支持以及索引优化的功能，可以保证数据的一致性以及查询的效率。开发人员对Python以及Web开发有较多的经验，可以独自完成框架的设置、数据库的设计和接口的开发。系统运行时会遇到并发订单请求造成响应慢的情况，借助数据库连接池设置以及查询语句改进可以在逻辑上减轻压力。安全隐患上使用了Django自带的跨站请求伪造保护和SQL注入过滤，对用户输入的数据做严格的校验。因此，系统在技术方面是可行的。
3.2.2 操作可行性
系统界面设计符合用户的日常使用习惯，发布用户和跑腿用户都可以通过浏览器直接访问系统，不需要下载客户端。发布用户在创建订单的时候，依次填写取件地址、收货地址、订单类型、取件价格等字段，操作流程和线下发布任务习惯相似。跑腿用户根据接单记录列表选取任务，配送时按照配送信息页面给出的地点及联系方式开展服务，配送结束后在配送记录里更新状态，操作流程一目了然。系统引入之后原有的QQ群、微信群人工发布信息的方式被线上平台所取代，发布和接单的效率得到了提高，管理员通过后台管理界面对用户进行审核、监管订单和审批提现，后期维护可以交给专门人员去处理。因此，系统在操作方面是可行的。
3.2.3 经济可行性
项目投入主要是开发阶段的人力成本，开发人员使用现有的设备进行编码和测试，不需要购买新的硬件。后端使用开源的Django框架和MySQL数据库，前端使用Vue框架，所有的技术栈都是免费使用的，不会产生软件授权费用。系统部署之后日常运行只需要一台带有Python运行环境的服务器，管理员通过后台界面完成所有维护工作，无需进行额外的开发投入。系统所带来应用价值表现在提高校园生活服务效率、规范交易流程、给跑腿用户提供收入来源等几个方面，投入产出相匹配。因此，系统在经济方面是可行的。
第四章 系统设计
4.2 系统结构功能设计
系统以发布用户、跑腿用户和管理员三个角色为依托来创建功能模块体系。发布用户主要包含跑腿订单发布与取消、接单记录与取件记录查看、配送信息与配送记录跟踪、跑腿评价和跑腿投诉提交等功能。跑腿用户的核心功能有接单记录查询、配送信息获取、取件记录和配送记录更新、跑腿评价和投诉提交、提现申请和提现记录管理。管理员核心功能包含用户管理、订单类型维护、跑腿订单全流程管控、取消订单审核、接单记录和取件记录管理、配送信息和配送记录监管、评价和投诉审核、提现申请审批和提现记录归档。该系统功能结构如图5所示。
图5系统功能结构图
4.3 系统流程设计
4.3.1 总体业务流程图设计
系统总体业务流程从发布用户发起跑腿订单开始，订单信息经系统验证后进入待接单状态。跑腿用户在订单列表中筛选合适任务并执行接单操作，系统生成接单记录并将订单状态更新为已接单。跑腿用户依据配送信息完成取件，系统记录取件凭证后状态变更为已取件。跑腿用户继续执行配送直至送达目的地，系统记录配送完成信息并更新订单状态为已完成。发布用户确认服务完成后可提交评价或发起投诉，跑腿用户依据服务获得报酬并可申请提现。系统总体业务流程如图6所示。
图6系统总体业务流程图
4.3.2 订单发布流程设计
发布用户进入订单发布界面后填写取件地址、收货地址、订单类型、取件价格、订单简介等信息，系统对必填项进行非空校验与格式验证。校验通过后系统生成唯一订单编号并将订单状态置为待接单，订单信息写入数据库后推送到跑腿用户订单列表。若校验未通过则提示用户补充或修正信息后重新提交。订单发布流程如图7所示。
图7订单发布流程图
4.3.3 接单流程设计
跑腿用户登录系统后进入待接单订单列表，查看订单详情包括取件地址、收货地址、取件价格等信息后选择承接任务。系统验证订单当前状态是否为待接单，验证通过后将订单状态更新为已接单并生成接单记录，同时通知发布用户订单已被承接。若订单已被其他跑腿用户接单则提示接单失败。接单流程如图8所示。
图8接单流程图
4.3.4 配送流程设计
跑腿用户完成取件后进入配送环节，在配送信息页面确认取件完成并上传取件凭证，系统将订单状态更新为配送中。跑腿用户依据收货地址完成货物送达后点击送达按钮，系统记录送达时间并更新订单状态为已完成。配送过程中若遇到问题可通过系统内投诉功能反馈。配送流程如图9所示。
图9配送流程图
4.4.2 数据库表设计
发布用户表主要是用来存储发布跑腿任务的用户基本信息。主要包括发布用户id、学生姓名、学生手机、学生性别等字段。如表1所示。
表1发布用户表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | publish_user_id | int | 11 | 是 | 是 | 发布用户ID |
| 2 | student_name | varchar | 64 | 否 | 否 | 学生姓名 |
| 3 | student_phone | varchar | 64 | 否 | 否 | 学生手机 |
| 4 | student_gender | varchar | 64 | 否 | 否 | 学生性别 |
跑腿用户表主要是用来存储承接跑腿任务的用户基本信息。主要包括跑腿用户id、用户姓名、用户手机、个人收益等字段。如表2所示。
表2跑腿用户表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | errand_user_id | int | 11 | 是 | 是 | 跑腿用户ID |
| 2 | user_name | varchar | 64 | 否 | 否 | 用户姓名 |
| 3 | users_mobile_phone | varchar | 64 | 是 | 否 | 用户手机 |
| 4 | personal_income | double | - | 否 | 否 | 个人收益 |
跑腿订单表主要是用来存储发布用户创建的跑腿任务信息。主要包括跑腿订单id、订单名称、订单编号、订单类型等字段。如表3所示。
表3跑腿订单表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | errand_order_id | int | 11 | 是 | 是 | 跑腿订单ID |
| 2 | order_name | varchar | 64 | 否 | 否 | 订单名称 |
| 3 | order_number | varchar | 64 | 否 | 否 | 订单编号 |
| 4 | order_type | varchar | 64 | 否 | 否 | 订单类型 |
取消订单表主要是用来记录发布用户取消跑腿订单的操作信息。主要包括取消订单id、订单名称、订单编号、订单类型等字段。如表4所示。
表4取消订单表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | cancel_order_id | int | 11 | 是 | 是 | 取消订单ID |
| 2 | order_name | varchar | 64 | 否 | 否 | 订单名称 |
| 3 | order_number | varchar | 64 | 否 | 否 | 订单编号 |
| 4 | order_type | varchar | 64 | 否 | 否 | 订单类型 |
接单记录表主要是用来记录跑腿用户承接订单的操作信息。主要包括接单记录id、订单名称、订单编号、跑腿用户等字段。如表5所示。
表5接单记录表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | order_receiving_record_id | int | 11 | 是 | 是 | 接单记录ID |
| 2 | order_name | varchar | 64 | 否 | 否 | 订单名称 |
| 3 | order_number | varchar | 64 | 否 | 否 | 订单编号 |
| 4 | errand_user | int | 11 | 否 | 否 | 跑腿用户 |
取件记录表主要是用来记录跑腿用户完成取件环节的操作信息。主要包括取件记录id、订单名称、订单编号、取件凭证等字段。如表6所示。
表6取件记录表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | pour_record_id | int | 11 | 是 | 是 | 取件记录ID |
| 2 | order_name | varchar | 64 | 否 | 否 | 订单名称 |
| 3 | order_number | varchar | 64 | 否 | 否 | 订单编号 |
| 4 | ppickup_voucher | varchar | 255 | 否 | 否 | 取件凭证 |
配送信息表主要是用来存储订单配送环节的详细联络信息。主要包括配送信息id、订单名称、订单编号、用户手机等字段。如表7所示。
表7配送信息表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | distribution_information_id | int | 11 | 是 | 是 | 配送信息ID |
| 2 | order_name | varchar | 64 | 否 | 否 | 订单名称 |
| 3 | order_number | varchar | 64 | 否 | 否 | 订单编号 |
| 4 | users_mobile_phone | varchar | 64 | 否 | 否 | 用户手机 |
第五章 系统实现
5.1 发布用户功能实现
5.1.1 跑腿订单功能实现
发布用户在系统中完成跑腿任务的创建。用户进入发布页面后依次填写取件地址、收货地址、订单类型、取件价格等信息，前端完成基础非空校验后提交至后台。后台生成唯一订单编号，将订单状态设置为待接单并存入数据库，订单信息同步推送到跑腿用户的待接单列表。跑腿订单界面如图25所示。
图25跑腿订单界面
5.1.2 取消订单功能实现
发布用户对待接单状态下的订单具备取消权限。用户在订单详情页点击取消按钮时，系统弹出二次确认框防止误操作。确认取消后后台验证订单当前状态，验证通过则将该订单记录写入取消订单表，同时更新原订单状态为已取消。取消订单界面如图26所示。
图26取消订单界面
5.1.5 配送信息功能实现
发布用户在配送信息页面获取订单配送过程中的联络信息。系统展示跑腿用户的联系方式、预计送达时间以及配送过程中的状态变更记录。发布用户可通过该页面与跑腿用户进行必要沟通，保障配送环节的顺利进行。配送信息界面如图29所示。
图29配送信息界面
5.1.6 配送记录功能实现
发布用户在配送记录页面查看订单从取件到送达的完整轨迹。系统按时间顺序展示配送状态的每次变更，包括取件完成、配送中、已送达等关键节点，每条状态变更均记录操作时间与操作人。配送记录界面如图30所示。
图30配送记录界面
5.2 跑腿用户功能实现
5.2.1 接单记录功能实现
跑腿用户在接单记录页面查看已承接的所有跑腿任务。系统从数据库查询该跑腿用户关联的订单，按接单时间倒序展示订单名称、取件价格、发布用户信息等关键字段。用户可通过详情入口查看订单完整信息，便于安排配送路线与时间。接单记录界面如图33所示。
图33接单记录界面
5.2.2 配送信息功能实现
跑腿用户在配送信息页面获取执行配送任务所需的全部信息。系统展示取件地址、收货地址、发布用户联系方式以及订单备注说明。用户根据该页面提供的信息规划取件与配送路线，完成货物从取件到送达的完整过程。配送信息界面如图34所示。
图34配送信息界面
5.3 管理员功能实现
5.3.1 用户管理功能实现
管理员在用户管理页面维护发布用户与跑腿用户账户信息。系统展示用户列表，包含用户名、学生姓名、联系方式、注册时间等字段，支持按条件筛选查询。管理员可对异常账户执行禁用或删除操作，保障平台用户群体的合规性。用户管理界面如图41所示。
图41用户管理界面
5.3.2 订单类型管理功能实现
管理员在订单类型管理页面维护系统中可用的订单分类信息。系统展示已有订单类型列表，管理员可新增类型、修改类型名称或删除不再使用的类型。订单类型数据在前端订单发布页面作为下拉选项供用户选择，保障分类的统一性与规范性。订单类型管理界面如图42所示。
图42订单类型管理界面
5.3.3 跑腿订单管理功能实现
管理员在跑腿订单管理页面查看系统中所有跑腿订单。系统展示订单列表，包含订单名称、订单类型、取件价格、订单状态、发布时间等字段，支持多条件组合筛选。管理员可查看订单详情并对异常订单进行状态调整。跑腿订单管理界面如图43所示。
图43跑腿订单管理界面
5.3.4 取消订单管理功能实现
管理员在取消订单管理页面查看用户取消的订单记录。系统展示取消订单列表，包含订单名称、订单类型、取件价格、取消时间等字段，支持按订单名称筛选查询。管理员通过该页面了解订单取消情况，分析用户取消订单的原因。取消订单管理界面如图44所示。
图44取消订单管理界面
第六章 系统测试
6.1 测试目的
系统测试采取黑盒测试和白盒测试相融合的办法。黑盒测试主要是考察系统功能是否符合需求规格说明书要求，设计出发布用户、跑腿用户、管理员三个角色主要功能模块的测试用例，包括订单发布、接单、配送状态变更、提现申请、后台管理等业务流程。白盒测试对于业务逻辑层中重要的方法进行代码覆盖率的分析，主要是检验订单状态流转的合法性校验、提现金额和账户余额的比较逻辑、评价和投诉的权限控制等重要的代码块。测试过程中记录实际输出与预期输出的差异，对发现的问题进行缺陷跟踪与回归验证19。
6.2 测试方法
测试目的旨在验证系统功能实现的正确性与完整性，确保各功能模块按照需求规格说明正常运行。通过测试发现系统在功能实现过程中存在的缺陷与不足，包括界面交互响应是否符合用户预期、业务流程是否覆盖所有正常路径与异常路径、数据在多次操作后能否保持一致性、权限控制是否准确区分不同角色操作边界。测试过程同时评估系统的可用性与稳定性，为系统正式上线提供质量保障依据，确保系统在实际运行环境中能够满足用户使用需求20。
6.3 测试内容
跑腿订单发布测试覆盖订单创建流程的正确性验证，重点检验系统能否准确记录发布用户填写的订单信息，生成唯一订单编号并将订单状态正确置为待接单。测试过程关注系统对必填项的非空校验与格式验证机制是否生效，确保无效数据无法提交至数据库。
跑腿订单发布测试如表14所示。
表14跑腿订单发布测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 正常发布订单 | 填写完整订单信息后提交 | 生成订单编号，状态为待接单 | 符合预期 |
| 必填项为空 | 不填写取件地址后提交 | 系统提示补充信息，订单不生成 | 符合预期 |
| 订单类型未选 | 不选择订单类型后提交 | 提示选择订单类型，提交被阻止 | 符合预期 |
订单接单测试验证跑腿用户承接任务的业务流程是否完整，重点关注系统能否在订单状态为待接单时允许接单操作，接单后订单状态能否正确更新为已接单并生成接单记录。测试过程同时检验已被接单的订单是否阻止其他用户重复接单。
订单接单测试如表15所示。
表15订单接单测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 正常接单操作 | 选择待接单订单后确认接单 | 订单状态变更为已接单，生成接单记录 | 符合预期 |
| 重复接单尝试 | 对已接单订单再次接单 | 系统提示订单已被接单，操作失败 | 符合预期 |
| 接单后状态变更 | 接单完成后查看订单列表 | 该订单不再显示在待接单列表中 | 符合预期 |
配送流程测试检验跑腿用户完成取件与送达两个关键节点的状态流转是否准确，重点关注取件完成后订单状态能否更新为配送中，送达确认后订单状态能否更新为已完成。测试过程同时验证取件凭证上传功能是否正常工作。
配送流程测试如表16所示。
表16配送流程测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 取件完成操作 | 确认取件并上传凭证 | 订单状态变更为配送中，凭证保存成功 | 符合预期 |
| 送达确认操作 | 点击送达按钮确认送达 | 订单状态变更为已完成，记录送达时间 | 符合预期 |
| 状态变更追溯 | 查看配送记录页面 | 状态变更时间与操作人记录完整 | 符合预期 |
跑腿评价测试验证发布用户对跑腿用户服务质量的反馈流程是否完整，重点关注评价提交后系统能否将评分与评价内容关联至对应订单，同时更新跑腿用户的综合评分。测试过程检验评价完成后是否允许重复提交。
跑腿评价测试如表17所示。
表17跑腿评价测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 正常评价提交 | 选择评分并填写评价后提交 | 评价信息保存成功，关联至订单 | 符合预期 |
| 重复评价尝试 | 对同一订单再次提交评价 | 系统提示已评价，禁止重复提交 | 符合预期 |
| 评分数据统计 | 查看跑腿用户评分变化 | 综合评分依据新评价重新计算 | 符合预期 |
测试结论
系统功能测试涉及到了跑腿订单发布、取消订单、接单记录、配送记录、跑腿评价、提现申请管理、跑腿投诉管理这七个主要的业务模块。测试过程中共设计出测试用例28个，所有的用例都按照预期执行完成。测试结果表明，订单发布之后状态会自动更新为待接单，取消操作只在待接单状态下有效，接单记录可以和订单以及跑腿用户信息建立关联关系，配送记录可以追踪到订单状态的变化过程，评价和投诉提交之后审核状态正常流转，提现申请经过管理员审核之后就会产生相应的记录。各个模块的功能实现与需求描述一致，没有发现阻塞性的缺陷或者逻辑上的错误。
总结
目前高校校园内学生之间代取快递、食堂带饭等跑腿需求不断增多，传统的依靠QQ群、微信群发布信息的方式存在着信息分散、交易混乱、缺少信任机制和纠纷处理渠道等问题。开发出一套专门的校园跑腿服务系统，对规范交易流程、保障双方权益、提高校园生活便利性有现实必要性。本系统以发布用户、跑腿用户和管理员这三个角色为中心来建立完整的业务闭环，完成了订单发布和接单、配送过程的跟踪、评价投诉的反馈、提现申请及审批等主要功能，达到了预期的设计目的，给校园跑腿服务提供了一个规范化的平台支持。
系统开发按照软件工程规范的流程进行，依次是需求分析、系统架构设计、功能模块划分、数据库设计、系统测试。后端使用Django框架搭建业务逻辑层，前端用Vue框架创建用户交互界面，MySQL数据库做数据持久化工作，全部采用B/S架构模式。发布用户可以进行跑腿订单的发布、取消、配送状态查看、评价投诉等操作，跑腿用户可以接单、取件、配送、提现申请等，管理员可以对用户的管理、订单类型的管理、全流程订单的管理、评价投诉的审核、提现的审批等后台管理。系统测试中涉及的主要业务模块的测试结果和预期一致。
由于开发周期以及个人能力的限制，系统在某些方面还存在着不足。支付功能没有接入真实的第三方支付接口，只做模拟支付的过程。配送路径规划依靠人工判断，没有集成地图导航接口来实现智能路线推荐。提现申请和资金划转还没有和真实的银行系统对接，交易流水记录为模拟数据。后台数据分析功能比较简单，只能进行简单的条件筛选查询，没有对数据进行深层次的统计和可视化展示。
后续工作可以从以下几个方面进行。接入微信支付或者支付宝支付接口，进行真实的资金流转，提高交易的安全性。使用高德或者百度地图API，给跑腿用户赋予智能路径规划和实时位置共享服务，从而提升配送速度。引入数据分析模块，用数据可视化的方式对订单量、用户活跃度、评价倾向等数据进行展示，给平台运营提供决策支持。该系统可以推广到其他的高校或者社区中去，给类似的日常生活服务平台的创建提供一定的参考借鉴。
参考文献
1 姚良鹏,邓舒婷.基于Android的校园外卖点餐APP的设计与实现C//全国高等学校计算机教育研究会.第32届计算机新科技与教育学术会议论文集.北京:全国高等学校计算机教育研究会, 2025: 182-186.
2 任安宇.后疫情时代校园外卖配送服务设计研究D.广州:广东工业大学, 2023.
3 谢玉娇,宋新宇,程恩博,等.基于AT89C52单片机的校园外卖柜的设计J.科技传播, 2022, 14(22): 107-110.
4 李章恒.校园外卖系统设计与实现D.济南:山东大学, 2022.
5 郭晓琪.高校校园外卖规范化管理探讨J.中国物流与采购, 2022(8): 55-56.
6 徐伟峰,黄诗雯,陈旭辉.基于O2O模式的校园外卖订餐APP的设计研究J.电子元器件与信息技术, 2021, 5(9): 171-172.
7 陈江辉,於立杰,李强.智慧校园食堂订餐系统信息化平台的设计J.网络安全技术与应用, 2021(3): 43-44.
8 AlmarwaniM A. Adoption of AI in nursing education- A systematic review of factors influencing student intentionsJ. Applied Nursing Research, 2026, 88: 152068.
9 Peng Q, Liang S, Wang K, et al. Institutional pathways to TCM psychological acceptance abroad: A fuzzy Delphi evaluation of four Chinese collegesJ. ActaPsychologica, 2026, 265: 106659.
10 Thompson V R, Conroy M, Flanigan M, et al. A longitudinal evaluation of faculty and simulated participant communicationJ. Clinical Simulation in Nursing, 2026, 113: 101929.
11 Eisman B A, Whitman J, Palinkas A L, et al. Economic evaluation of implementation strategies for school-based universal prevention: Insights from a pilot studyJ. Mental Health & Prevention, 2026, 42: 200498.
12 YanlongZ, Dong Y. Legal protection for gig workers' availability time: an empirical study of take-out platform riders in BeijingJ. Employee Relations: The International Journal, 2024, 46(1): 133-146.
13 段小手.巧用AI大模型轻松学会Python金融数据分析M.北京:北京大学出版社, 2025: 525.
14 刘延林,徐清徽. Python网络爬虫开发从入门到精通M.北京:北京大学出版社, 2025: 619.
15 张书钦,夏敏捷. Python程序设计应用教程M.北京:中国铁道出版社, 2024: 310.
16 翟明岳. Python语言程序设计基础教程M.北京:人民邮电出版社, 2024: 290.
17 王健,彭聪. Python编程基础M.北京:人民邮电出版社, 2024: 218.
18 张敏. Python语言程序设计M.北京:中国铁道出版社, 2024: 301.
19 谢振华.基于Vue.js与Spring Boot的教务管理系统设计J.电脑与信息技术, 2024, 32(4): 95-97.
20 王景.基于MySQL的数据库查询性能优化技术研究J.电脑与电信, 2022, 39(6): 90-93.
致谢
时光荏苒，白驹过隙，转眼间大学时光已近尾声。站在毕业的门槛上回望，这段撰写毕业论文的日子，既是对过往所学的一次检阅，亦是一段弥足珍贵的成长历程。
本论文从选题、开题，到研究设计、论文撰写直至最终定稿，每一个环节都离不开校内指导老师的悉心指导。老师治学严谨、学识渊博，在关键节点上总能给予我拨云见日般的指点，让我在学术探索的道路上少走了许多弯路。同时，感谢企业导师在实践环节中的倾囊相授，让我得以将理论知识与工程应用相结合，真正体会到知行合一的力量。
回顾整个毕设过程，从最初的迷茫困惑，到遭遇理论难点与技术瓶颈时的焦灼，再到逐步理清思路、攻坚克难后的豁然开朗，这一路走来虽有艰辛，却更让我体会到了学术研究的魅力。四年的大学时光，我不仅构建起了相对完整的专业知识体系，更在独立思考与解决问题能力上获得了长足进步，这份成长令人倍感欣慰。
感谢学院所有授课老师与辅导员的辛勤付出，是你们的谆谆教诲为我夯实了学业根基。感谢同窗好友与实验室伙伴们，在那些挑灯夜战、相互切磋的日子里，你们的陪伴与鼓励让求学之路不再孤单。这份情谊，我将长久铭记于心。
最后，我要将最深的谢意献给我的父母和家人。感谢你们多年来的养育之恩与无条件的支持，你们永远是我最坚强的后盾。毕业并非终点，而是新的起点。未来，我将带着这份感恩之心，脚踏实地，以所学所长回馈社会，不负韶华，不负期许。