团队作业3——需求改进与系统设计
需求改进and系统设计
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/gdgy/Class34Grade23ComputerScience |
|---|---|
| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/gdgy/Class34Grade23ComputerScience/homework/13482 |
| 这个作业的目标 | <对现有项目进行需求改进与系统设计，完善测试计划> |
1 需求与原型改进
1.1 需求修改
- 问题1：项目亮点不够突出
修改1：引入了智能化、数据驱动的配送优化，使得用户、餐厅和配送员之间的配合更为精准流畅。项目的亮点在于通过智能算法和用户行为分析优化外卖配送的效率与用户体验。通过大数据分析预测高峰时段与用户偏好，为每位用户提供个性化推荐，减少等待时间，并且提升餐厅与配送员的匹配度，从而提升整体配送效率。
- 问题2：项目的适用人群不清晰
修改2：明确项目适用人群：在校大学生（注重性价比和口味）、餐饮商家（注重餐品制作效率）、校内外配送员（注重配送效率）
- 问题3：项目推广前景不明确
修改3：提供推广思路：扩大市场营销（线上社交媒体宣传等多渠道增加曝光度）、建立合作伙伴关系（与大型餐饮品牌、外卖平台或交通工具公司（如共享单车、共享电动滑板车）建立合作）、用户教育和激励机制（通过优惠券、会员积分等方式吸引新用户并培养忠诚度，增加用户粘性，同时通过推荐奖励机制鼓励现有用户为我们引荐新用户）
1.2 目标用户的原型及需求沟通
项目进行初期，团队成员和目标用户进行了深入的沟通，采用了用户访谈、问卷调查等手段了解用户真实需求。团队成员发现用户的主要痛点在于配送时间不准确、配送员与餐厅的沟通不畅以及外卖平台推荐的餐厅不符合个人口味。
以下是调研过程中收集的部分反馈数据：
- 使用前：用户通常需要等待较长时间才能收到外卖，常常因为配送时间不准而感到不满。
用户A（班内同学）：“每次点外卖，我经常等好久，特别是下雨天，等待时间更长。”
- 使用后：通过本项目优化后的外卖服务，用户能够在较短时间内收到餐品，并且能享受到个性化推荐的餐饮体验。
用户A：“这个平台很智能，推荐的餐厅更符合我的口味，而且配送时间比以前快了很多。”
1.3 需求规格说明书修改
1.3.1 完善功能
新增功能：
支付渠道与支付状态查询、配送时间预估（简单基于距离与历史速度）、订单评价（评分 + 评论）、商家营业状态显示（营业中 / 打烊 / 维护中）
新增非功能性需求：
数据安全（密码加密、用户登录态校验、重要操作的权限检查）、性能要求（支持至少并发 1000 用户访问）、可用性要求（响应时间 < 1s，系统可用性 99%）、日志审计（管理员查看操作日志）。
新增角色与流程描述：
商家订单状态流：未接单 → 已接单 → 备餐中 → 已出餐 → 配送中 → 已完成。
配送员流程：查看列表 → 接单 → 配送中 → 送达 → 上传送达凭证。
1.3.2 用户场景参考
用户操作：打开系统 → 浏览菜品详情 → 下单支付 → 配送跟踪 → 送达评价
中午 11:50临近下课，小林准备点外卖作为午饭，但午休时间紧张。小林打开校园点餐系统，在首页看到不同餐厅的菜品。系统根据他经常点的食堂，智能推荐几款热销套餐。他选择了某商家的“香辣鸡排饭套餐”，查看了图片、价格、月售量以及学生评价（新增功能）。确认好后加入购物车并下单支付，系统立即显示”支付成功“。很快，一名配送员在自己的任务大厅里看到该订单，抢单成功。系统为小林显示“预计送达：18分钟”（新增功能）。在订单详情页面，小林可以看到配送员的动态：（已取餐/配送途中/即将送达）配送员送达后上传送达凭证并点击“送达”。小林收到通知并对此次订单进行了评价：“好吃！配送很准时！”
1.3 功能分析四象限
1.4任务分解WBS以及项目进度计划调整
1.4.1 WBS
1.4.2 项目进度调整
| 周次 | 主要目标 | 原时间估计 | 修正后时间 |
|---|---|---|---|
| 第十一周（本周） | 系统设计与文档完善阶段 1. 根据老师意见修订需求说明书（补充 User Story、功能四象限、遗漏功能等） 2. 完善 UI 原型（改进交互流程、统一界面风格） 3. 完成系统架构设计（SSM 三层结构、模块划分） 4. 完成项目 WBS 任务分解（根据新版需求） 5. 团队成员估算各自任务时间（用于 Alpha 冲刺） 6. 编写测试计划（Alpha 阶段测试方案、测试项） |
70h | 70h |
| 第十二周 | Alpha 冲刺（用户端为主） 1. 用户端核心功能开发：登录、菜品浏览、下单、订单管理 2. 商家端基础功能：菜品管理、订单接单 3. 配送员端：抢单 + 基本配送状态更新 4. 每日 Scrum 站会 + 博客 |
3h | 10h |
| 第十三周 | Alpha 冲刺（后台 + 高价值功能） 1. 管理端开发：用户管理、订单管理、公告模块 2. 实现评价功能、支付流程模拟、配送时间预估 3. 前后端联调 4. 每日 Scrum Meeting + 博客 |
5h | 15h |
| 第十四周 | 1. 根据测试计划执行 Alpha 测试 2. 缺陷修复与功能补全 3. Alpha 阶段个人总结 4. 完成团队 Alpha 博客（发布说明、测试报告、展示博客等） |
15h | 18h |
| 第十五周 | 1. 撰写团队 Alpha 事后分析（Postmortem） 2. 文档归档（设计文档、测试文档、开发文档） |
8h | 8h |
2 系统设计
2.1 整体架构概述
系统采用经典的分层架构，包括前端层、后端层、数据层、外部接口层和安全层。这种设计允许模块化开发，便于维护和扩展。
前端层
基于 Vue 的单页应用（SPA），分多角色端：学生点餐端、商家管理端、配送员端、系统管理后台。
组件化设计：封装OrderView（订单页）、AdminDashboard（管理看板）等组件，适配不同角色操作场景。
后端层
以@RestController/@Controller接收前端请求，转发至业务层；负责参数校验、响应封装（JSON / 页面）。
业务逻辑层
以@Service为核心封装业务流程，管理事务（@Transactional）；
支持模块化开发：不同开发人员负责不同 Service 组件，通过接口定义层解耦。
数据层
主数据库：MySQL（存储用户、订单、商品等核心数据）。
缓存层：Redis（缓存订单状态、促销码、验证码）
外部接口层
集成支付接口（支付宝 / 微信 SDK）、模拟 SM-DP + 接口（用于订单二维码生成）；通过Spring Task实现异步任务（如二维码生成、订单超时处理）。
安全层
全站 HTTPS 加密、JWT 身份认证、密码哈希存储（MD5/SHA256）、接口幂等性校验（防止重复提交）
2.2 核心组件详细设计
| 组件 | 描述 | 关键技术（SSM适配） |
|---|---|---|
| UserService | 处理用户注册、登录、个人信息管理 | JWT 令牌、Spring Security 权限控制、密码哈希（60s 有效期） |
| OrderService | 订单创建、库存锁定（15min 超时释放）、状态流转 | Redis 分布式锁、Spring Task 异步调度、MyBatis 关联查询 |
| PaymentService | 统一支付对接、沙箱测试、账单核对 | 支付宝 / 微信 SDK、Spring 事务回滚机制 |
| MarketingService | 促销码生成、用户推荐 | 基于历史订单的简单算法、Redis 缓存促销码 |
| OperatorSimService | 模拟 SM-DP + 接口，实现订单二维码生成 / 核销 | SpringMVC RESTful 接口、参数校验 |
| AdminDashboard | 后台管理（数据 CRUD、库存监控、报表可视化） | Element-Plus UI、ECharts 折线图 / 饼图 |
2.3 数据库设计
本数据库设计以实体关系模型为核心，包含User（用户）、Order（订单）、Package（配送包）等关键实体。User实体以userId为主键，与Order存在一对多关系，即一个用户可创建多个订单；Order实体通过orderId唯一标识，与Package为一对一关联，确保每个订单对应唯一配送包。系统存在弱实体Cart（购物车），其依赖于User实体，需通过userId与用户建立关联，无独立主键。实体间关系通过ER图清晰呈现，其中多对多关系主要体现在用户与菜品分类（Category）的交互中，用户可浏览多个分类，每个分类包含多种菜品。
ER图
3 Alpha任务分配计划
3.1 Product Backlog 筛选
| 模块ID | 功能模块 | 描述 | 优先级 | 依赖模块 |
|---|---|---|---|---|
| 1 | 基础支撑模块 | 用户 / 配送员 / 商家 / 管理员登录注册、个人中心（信息查看 / 修改） | P0 | |
| 2 | 菜品模块 | 商家菜品添加 / 修改 / 删除 / 查询、用户菜品浏览（列表 + 详情）、菜品分类展示 | P0 | 1 |
| 3 | 库存模块 | 商家库存设置、库存扣减、库存预警（弹窗 + 消息通知） | P0 | 2 |
| 4 | 订单模块 | 用户下单支付（模拟）、订单状态流转（待支付→待备餐→待接单→配送中→已完成） | P0 | 2，3 |
| 5 | 配送模块 | 配送员抢单、订单配送跟踪、送达通知（用户端接收） | P0 | 4 |
| 6 | 辅助功能模块 | 用户菜品收藏、订单取消（未备餐前） | P1 | 2，4 |
| 7 | 系统管理模块 | 管理员用户信息管理（查询 / 修改） | P1 | 1 |
3.2 Sprint Backlog 任务拆解与认领
选取P0等级模块作为核心功能。单任务工时控制在 1-10 小时，按 “前端界面实现→后端接口开发→前后端联调→测试验证” 流程拆解；
任务认领基于 “角色匹配 + 技术擅长” 原则，若单个任务遇到技术卡点，可由对应领域成员协助，协作成果计入双方贡献分；若冲刺过程中需调整任务，需经团队讨论确认后更新任务状态与负责人
| 任务 ID | 所属模块ID | 任务名称 | 任务描述 | 依赖任务 | 预计工时 | 负责人 | 期望输出成果 |
|---|---|---|---|---|---|---|---|
| T001 | 1 | 全角色登录注册页面实现（ElementUI） | 设计登录 / 注册表单，实现表单校验、提交逻辑，适配不同角色登录入口 | 无 | 6h | 贺海伦 | 登录注册页面（HTML/CSS/JS） |
| T002 | 1 | 全角色个人中心页面实现 | 实现个人信息展示、编辑表单、密码修改功能，适配不同角色信息字段 | T001 | 5h | 陈煜楠 | 个人中心页面 + 前端逻辑 |
| T003 | 1 | 基础支撑模块后端接口开发（登录 / 注册 / 个人信息） | 开发用户登录验证、注册数据入库、个人信息 CRUD 接口，含权限校验 | 无 | 8h | 谢希哲 | 接口文档 + 可运行接口 |
| T004 | 2 | 菜品列表 / 详情页面实现（用户端 + 商家端） | 用户端：菜品分类展示、详情弹窗；商家端：菜品管理表单（增删改查） | T001 | 7h | 贺海伦 | 菜品相关页面 + 前端逻辑 |
| T005 | 2 | 菜品模块后端接口开发 | 开发菜品 CRUD、分类查询、库存关联接口，支持商家菜品上下架 | T003 | 6h | 陈愉均 | 接口文档 + 可运行接口 |
| T006 | 1，2 | 前后端联调（登录 / 注册 / 个人中心 / 菜品模块） | 对接 T003、T005 后端接口，解决跨域、数据格式问题，确保页面功能正常使用 | T002、T004、T005 | 4h | 陈煜楠 | 联调完成的功能模块 |
| T007 | 3 | 库存设置与预警页面实现（商家端） | 实现菜品库存设置表单、库存预警弹窗、预警消息列表功能 | T004 | 3h | 肖锦瑞 | 库存管理页面 + 前端逻辑 |
| T008 | 3 | 库存模块后端接口开发（设置 / 扣减 / 预警） | 开发库存设置、下单库存扣减、预警触发接口，关联菜品 ID | T005 | 5h | 谢希哲 | 接口文档 + 可运行接口 |
| T009 | 4 | 订单下单页面 + 订单列表页面实现（用户端） | 实现购物车、下单表单（地址选择、备注）、订单列表（状态筛选、详情查看） | T004 | 8h | 陈煜楠 | 订单相关页面 + 前端逻辑 |
| T010 | 4 | 商家订单管理页面实现（接单 / 备餐 / 出餐） | 实现订单列表、订单详情、状态更新按钮（待备餐→已出餐）功能 | T009 | 4h | 贺海伦 | 商家订单管理页面 + 前端逻辑 |
| T011 | 4 | 订单模块后端接口开发（下单 / 状态流转） | 开发下单创建订单、状态更新、订单查询接口，关联用户 / 商家 / 库存 | T003、T008 | 10h | 陈愉均 | 接口文档 + 可运行接口 |
| T012 | 3，4 | 前后端联调（库存 + 订单模块） | 对接 T008、T011 后端接口，确保下单扣减库存、库存预警正常触发 | T007、T009、T010、T011 | 3h | 陈煜楠 | 联调完成的功能模块 |
| T013 | 5 | 配送员订单抢单页面 + 配送跟踪页面实现 | 实现待抢单列表、已接单列表、配送状态更新（配送中→已完成）、送达通知按钮 | T010 | 6h | 肖锦瑞 | 配送相关页面 + 前端逻辑 |
| T014 | 5 | 智能派单基础逻辑开发（距离优先） | 实现 “商家 3km 内 + 当前订单≤3” 配送员筛选，按距离排序推荐订单 | T011 | 5h | 许雯妍、陈健 | 派单逻辑代码 + 测试用例 |
| T015 | 5 | 配送模块后端接口开发（抢单 / 送达通知） | 开发抢单锁定、配送状态更新、送达通知推送接口 | T011、T014 | 6h | 许雯妍 | 接口文档 + 可运行接口 |
| T016 | 5 | 前后端联调（配送模块） | 对接 T015 后端接口，确保抢单、配送跟踪、送达通知功能正常 | T013、T015 | 3h | 陈煜楠 | 联调完成的功能模块 |
| T017 | 全模块 | Alpha 阶段功能测试（功能 + 边界场景） | 编写测试用例，覆盖核心流程及边界场景（库存不足下单、重复抢单等），执行测试并提交 Bug 报告 | T006、T012 | 7h | 陈健 | 测试用例 + Bug 报告 |
3.3 Alpha 阶段迭代冲刺甘特图
冲刺周期：2 周（11.24-12.09）
4 测试计划
4.1 测试目标
本次测试的总体目标是验证系统是否严格按照设计文档的要求进行实现，确保交付的产品满足功能性、可靠性、易用性和安全性的需求。具体目标包括：
- 功能正确性： 验证所有核心功能（用户注册登录、商品浏览、下单、支付、订单状态流转、后台管理等）符合设计预期。
- 系统集成： 确保前端各角色端、后端各服务层、数据库及外部接口（支付、二维码）之间能够正确、稳定地交互。
- 数据安全： 验证用户密码加密存储、JWT令牌机制、接口幂等性等安全措施有效。
- 业务容错： 验证系统在异常情况（如网络超时、库存不足、支付失败）下的处理能力。
- 用户体验： 确保各角色端界面操作流畅，信息展示准确。
4.2 测试策略与范围
测试将采用分层、分阶段的策略进行，具体范围如下：
| 测试阶段 | 测试类型 | 测试重点 / 范围 | 关联设计组件 |
|---|---|---|---|
| 单元测试 | 白盒测试 | 对后端Service、Controller等核心类和方法进行测试，重点关注业务逻辑（如库存锁定算法、订单状态机）、异常处理。 | UserService, OrderService, PaymentService等 |
| 集成测试 | 灰盒测试 | 1. 接口集成： 测试Controller与Service、Service与MyBatis Mapper之间的调用与数据传递 2. 外部接口集成： 重点测试与支付宝/微信支付沙箱环境、模拟SM-DP+二维码接口的连通性和数据解析 3. 数据层集成： 测试MySQL与Redis之间的数据同步与一致性（如订单状态缓存）。 |
@RestController,@Service,MyBatis, 支付SDK,OperatorSimService |
| 系统测试 | 黑盒测试 | 1. 功能测试： 基于用户角色（学生、商家、配送员、管理员）对完整业务流程进行端到端测试 2. 安全测试： 测试JWT令牌有效性、权限控制、HTTPS、密码强度、接口重复提交防护等 3. 性能测试： 评估系统在高并发下的表现，如模拟用餐高峰期的集中下单、支付 4. 兼容性测试： 测试前端SPA在不同浏览器（Chrome, Firefox, Edge）及移动设备上的表现。 |
整个系统，特别是安全层、Redis分布式锁、Spring Task异步 |
| 验收测试 | 黑盒测试 | 在模拟真实业务环境中，由产品经理、业务方或最终用户代表进行测试，确认系统满足初始业务需求。 | 整个可交付系统 |
4.3 职责分工
| 角色 | 人员/部门 | 职责 |
|---|---|---|
| 测试经理 | 肖锦瑞 | 制定和维护测试计划，协调资源，控制测试进度，报告整体测试质量。 |
| 测试工程师 | 陈健 | 编写测试用例，执行单元、集成、系统测试，记录和跟踪缺陷，编写测试报告。 |
| 开发工程师 | 贺海伦、许雯妍、谢希哲 | 负责完成自身模块的单元测试，配合测试人员修复缺陷，提供必要的测试支持。 |
| 运维工程师 | 陈愉均、陈煜楠 | 搭建和维护测试环境（服务器、数据库、网络）。 |
4.4 测试进度安排
- 十一周： 测试准备阶段。完成测试计划评审，开始编写核心模块（如UserService）的测试用例。开发人员进行单元测试。
- 十二周： 集成测试阶段。后端API初步可用后，开始接口集成测试。前端组件完成后，进行前后端联调测试。
- 十三周： 系统测试阶段。进行全面的功能、安全、性能测试。此阶段是测试执行的高峰期。
- 十四周： 验收测试与回归测试阶段。业务方进行验收测试，同时测试团队对已修复的缺陷进行回归验证。
- 上线后： 进行线上核心业务流程的烟雾测试。
4.5 测试环境与工具
- 测试环境：
服务器： 与生产环境配置相似的独立服务器集群。
软件环境： JDK 8+, Tomcat 9+, MySQL 5.7+, Redis 6.x。
外部接口： 使用支付宝/微信支付的沙箱环境进行测试。
- 测试工具：
后端测试： JUnit, Mockito, Spring Test。
前端测试： Jest, Vue,Test Utils, Cypress（用于E2E测试）。
API测试： Postman
性能测试： JMeter
缺陷管理： JIRA, Tapd
4.6 风险与应对
| 风险情况 | 可能性 | 影响 | 应对措施 |
|---|---|---|---|
| 开发进度延迟，导致测试时间被压缩 | 中 | 高 | 1. 测试提前介入，与开发同步编写用例 2. 采取风险导向的测试策略，优先测试核心和高风险模块 |
| 测试环境不稳定或与生产环境有差异 | 中 | 中 | 1. 由运维专人负责环境维护 2. 建立自动化的环境检查和部署脚本 |
| 外部接口（如支付）不稳定，阻塞测试 | 中 | 中 | 1. 对关键外部接口建立Mock服务，降低依赖 2. 与接口提供方保持沟通，获取稳定性时间窗口 |
| 发现重大架构缺陷，需大规模返工 | 低 | 高 | 1. 在早期设计和代码评审阶段加强审查 2. 一旦发现，立即评估影响，调整开发和测试计划 |
4.7 出口准则
- 所有规划内的测试用例已100%执行完毕。
- 所有致命、严重级别的缺陷已全部解决并验证关闭。
- 一般级别缺陷修复率超过95%。
- 产品经理或业务负责人确认验收测试通过。
- 输出正式的测试报告，结论为“通过”。
浙公网安备 33010602011771号