团队作业3——需求改进与系统设计

这个作业属于哪个课程	计科23级12班
这个作业要求在哪里	团队作业3——需求改进与系统设计
这个作业的目标	需求与原型改进、系统设计、Alpha阶段任务分配计划、测试计划

一、需求 & 原型改进

前几周，我们完成了选题确定和《需求规格说明书》初稿。在课堂展示和讨论之后，老师和同学们提出了不少非常具体的问题，本次团队作业3，我们主要围绕这些问题进行需求与原型的改进。

1.1 课堂讨论问题 & 修改

问题1：教职工免费预约、学生付费没有体现在需求里

课堂上老师提醒：我们学校的体育场馆预约实际规则是“教职工免费预约，学生预约需要付费”。
而在我们之前的需求规格说明书中，虽然写了“面向学生、教师和学校人员进行体育场馆预约”，但完全没有体现“是否收费、谁收费、怎么展示费用”这一真实业务规则，容易导致系统设计脱离现实。

修改1：补充“用户角色与收费规则”需求 & 原型展示方式

在需求规格说明书中新增“收费与角色规则”部分：

用户分为两类：

教职工（Teacher/Staff）：预约时显示“本次预约免费”，金额为 0；

学生（Student）：预约时需要显示对应场馆的收费标准（例如 10 元/小时），系统记录本次预约应付金额。

当前阶段系统只记录费用，不接入在线支付，默认线下刷卡/扫码收费。

在原型里调整：

预约确认页面增加“费用信息”区块：根据用户角色动态展示“免费 / 需支付 ¥XX”；

在管理员后台增加“收费标准配置”入口，用于配置不同场馆、不同时段的收费标准。

这样既贴合“老师免费、学生付费”的真实背景，又不会在 Alpha 阶段把范围扩张到复杂支付系统。

问题2：场馆信息过于抽象，看不出差别

初版原型中，场馆只有名字（如“羽毛球馆1、羽毛球馆2”），没有位置、容量、开放时间等信息，用户难以做决策。

修改2：增加“场馆卡片信息 + 详情页”

场馆列表页的每个卡片增加：位置、开放时间概览、可预约状态（如“今日空闲 3/6”）；

详情页展示：场馆介绍、场地数量/容量、开放日期与时间段、使用规则（是否对学生收费、是否对教职工免费等）；

在 User Story 中也补充“用户先比较不同场馆，再进入预约流程”的步骤。

问题3：预约时间选择不直观，很难看出空闲情况

之前采用的是“下拉框选日期+时间段”的方式，老师指出用户很难一眼看出哪天哪段时间有空。

修改3：改用“日历 + 时间段”组合控件

引入日历视图展示某周/某月，日期上用不同颜色标出“可预约 / 部分已满 / 已满”；

点击某一天后，在右侧显示该天各时间段的卡片（例如 18:00–19:00、19:00–20:00），标注剩余场地数量和价格（学生可见）；

支持一次选择连续时间段，但在业务规则中限制单次预约时长不超过 2 小时。

问题4：缺少预约冲突检测，用户可以同一时间约好几场

“如果一个学生能在同一时间预约两个场馆，那这个系统会被骂的。”

修改4：增加“预约冲突检测”业务规则

业务上新增规则：同一用户在同一天同一时间段，只能有一条“有效预约”；

在后端创建预约时，先查询该用户在所选日期时间段是否已有预约（状态非取消）；

若有冲突：接口返回错误码，前端弹出提示“该时间段已有其他预约，请先取消原预约”；

在需求规格说明书中补充到“业务规则”章节，方便后续测试编写用例。

问题5：通知机制单一，只有“预约成功”邮件

原需求里只写了“预约成功时发送邮件”，容易忘记自己约了场地；管理员修改/取消时，学生常常不知道。

修改5：扩展通知场景

增加“预约前提醒邮件”：在预约开始前 2 小时发送提醒；

增加“预约被管理员修改/取消时邮件通知”；

在通知模板中增加费用信息（学生）或“免费”提示（教职工），保持与收费规则一致。

问题6：管理员端不够“数据驱动”，缺少统计视图

“管理员最关心的其实是哪些时间段最忙/最闲。”

修改6：增加基础“场馆使用率统计”模块

在管理员后台增加“统计”页面：

按场馆展示预约次数、使用率柱状图；

支持按日期范围筛选（如本周、本月）。

将“基于统计的热门时段推荐”功能保留在需求中，但优先级调整为 P2，放到后续版本。

1.2 需求规格说明书不足 & 修订摘要

结合团队作业2 发布的《需求规格说明书》初稿，我们总结了几个关键不足，并做了系统性的修订。

（1）真实性部分与选题不一致

原文中“真实性”采用的是教务管理/绩点系统的例子，和“体育场馆预约系统”主题不完全匹配。

改进：

重写“真实性”部分，直接引用我们学校当前场馆预约方式：

教职工可以在校内系统中免费预约；

学生需要付费使用场馆；

目前预约方式多依赖微信群/线下登记，信息不透明。

强调本系统是对现有场馆预约流程的线上化升级，而不是完全虚构的场景。

（2）对“收费规则”和“用户角色差异”描述缺失

初稿中只写了“学生、教师和学校人员”，但没有写清：

哪些角色收费？

费用如何显示？是否需要支付功能？

改进：

在需求中新增“收费与角色规则”（见 1.1 问题1/修改1）；

说明本阶段只记录费用，不做在线支付；

在数据库设计中增加字段：user_role、price、is_free 等。

（3）功能列表没有明确优先级

原文中列出了很多功能（统计、反馈、推荐等），但都没有标明优先级，难以指导 Alpha 开发。

改进：

在需求表中给每个功能增加优先级字段（P0/P1/P2）；

（4）业务规则描述不完整

例如：

预约冲突如何处理？

单次预约时长限制？

取消的时间限制？

改进：

在“业务规则”章节补充：

同一用户在同一时间段只能有一个有效预约；

单次预约时长不超过 2 小时；

开场前 1 小时内禁止取消；

教职工预约价格为 0，学生预约按配置收费。

（5）用故事串联功能（User Story）

User Story(学生用户)：大三学生小李预约羽毛球馆

小李想和同学周四晚上打羽毛球，以前他要在群里抢名额，现在打开“体育场馆预约系统”。

他用学生账号登录，在首页看到羽毛球馆卡片上写着：
“今日晚间可预约：3 个时段，学生价格 ¥10/小时”。

点击进入详情页，看完场馆照片和开放时间后，进入预约页面。

在日历上选择“本周四”，系统显示：

18:00–19:00：可预约（¥10）

19:00–20:00：可预约（¥10）

20:00–21:00：已满

小李选了 19:00–20:00，备注“2 人”，点击下一步。

确认页显示：

场馆：羽毛球馆

时间：周四 19:00–20:00

费用：¥10（学生）

系统检查该时段是否与他已有预约冲突，确认无冲突后，生成预约记录并发送“预约成功”邮件。

比赛当天 17:00，他又收到一封“开场前 2 小时提醒”邮件，提醒他准时到馆。

User Story(教职工用户)：教职工王老师预约篮球场

王老师用教职工账号登录，进入篮球场预约页面；

选择时间段后，确认页显示“本次预约免费”；

后台记录此预约的 price=0、user_role=teacher，便于统计教职工使用情况。

1.3 功能分析四象限

结合重要性（对用户价值）和紧急程度（对当前迭代的必要性），我们对功能进行四象限划分：

1.3.1 第一象限：重要 & 紧急（P0，Alpha 必做）

用户注册 / 登录 / 退出

用户角色区分（学生 / 教职工 / 管理员）

场馆列表 & 场馆详情展示（含收费信息）

场馆预约（创建预约、冲突检测、记录费用）

查看 & 取消个人预约

管理员登录后台

管理员维护场馆信息（名称、位置、开放时间、收费标准）

管理员查看预约列表并手动修改/取消预约

邮件通知（预约成功、取消/变更通知）

1.3.2 第二象限：重要 & 不那么紧急（P1，优先在 Beta）

预约前提醒邮件（T-2 小时）

场馆使用率统计与简单图表展示

用户意见反馈与管理员回复

管理员公告发布（停场通知、特殊安排等）

1.3.3 第三象限：不那么重要 & 不紧急（P2，可视时间插入）

UI 细节优化（主题、动画等）

更细粒度的权限划分（助理管理员）

系统操作日志查询界面

多语言支持

1.3.4 第四象限：想法/创意，暂不纳入计划

基于历史数据的热门时段预测与智能推荐

接入在线支付（如校园统一支付平台）

等候队列与自动递补机制

产品 Backlog 中，我们仅从 P0 象限中选取 Alpha 阶段的功能，保证“先把最核心的部分做完”。

1.4 根据修改后的需求调整 WBS 与项目进度计划

1.4.1 修改后的关键需求小结（只列对后续计划有影响的）

增加教职工免费、学生付费的真实业务规则。
用户端增加：
- 场馆详情页（位置、容量、开放时间、收费信息等）；
- 日历 + 时间段的可视化预约方式；
- 预约冲突检测（同一用户同一时间段只能有一个有效预约）。
管理员端增加：
- 场馆收费标准配置；
- 简单的场馆使用率统计图表。
通知模块完善：
- 预约成功通知；
- 预约取消/管理员变更通知；
- （Alpha 阶段提醒邮件可选，优先级略低）。

这些变动会直接影响后端业务逻辑、数据库结构、前端界面设计和测试范围，所以需要重新做 WBS 和进度计划。

1.4.2 WBS 总体结构（按功能分解）

WBS-1 需求与文档维护

WBS-1.1 课堂反馈整理与需求更新
WBS-1.2 需求规格说明书修订
WBS-1.3 用例 & User Story 补充

WBS-2 系统设计

WBS-2.1 系统架构设计（分层 & 模块划分）
WBS-2.2 数据库概念结构设计（ER 图）
WBS-2.3 数据库逻辑结构设计（表结构 & 约束）

WBS-3 后端开发（Flask + MySQL）

WBS-3.1 用户与角色模块
- 注册 / 登录 / 鉴权
- 角色：student / teacher / admin
WBS-3.2 场馆模块
- 场馆信息 CRUD
- 开放时间 & 容量 & 收费标准配置
WBS-3.3 预约模块
- 创建预约（含冲突检测、费用计算）
- 取消预约
- 我的预约查询
WBS-3.4 管理员后台模块
- 预约列表查询与状态更新
- 简单统计数据接口（使用率）
WBS-3.5 通知模块
- 邮件发送基础封装
- 预约成功 / 取消 / 变更触发

WBS-4 前端开发（Web）

WBS-4.1 公共布局和路由
WBS-4.2 登录 / 注册页
WBS-4.3 场馆列表 & 详情页（含收费信息）
WBS-4.4 预约日历 + 时间段选择组件
WBS-4.5 “我的预约”页面
WBS-4.6 管理员后台页面（场馆管理、预约管理、统计）

WBS-5 数据库与测试

WBS-5.1 初始化数据库脚本（DDL & 测试数据）
WBS-5.2 单元测试（后端关键业务）
WBS-5.3 接口测试（Postman 等）
WBS-5.4 场景/功能测试（完整预约流程）
WBS-5.5 测试报告与缺陷跟踪

WBS-6 项目管理与集成

WBS-6.1 每日 Scrum 记录与任务跟踪
WBS-6.2 版本控制（Git 分支策略）
WBS-6.3 Alpha 阶段集成与部署

1.4.3 与项目周次进度计划对齐（Alpha 聚焦）

结合团队作业1中的整体计划，这里只细化第 12–13 周 Alpha 阶段：

第 12 周：设计完善 + 后端 & DB 为主
- 完成系统架构设计和 ER 图定稿（WBS-2）。
- 搭建 Flask 项目骨架、数据库连接（WBS-3.1 部分）。
- 初步实现用户模块 & 场馆模块基础接口。
- 建好数据库表结构 & 初始化测试数据（WBS-5.1）。
第 13 周：前后端联调 + 核心功能打通
- 完成预约模块、通知模块核心逻辑（WBS-3.3、3.5）。
- 完成主要前端页面和预约流程（WBS-4）。
- 进行 Alpha 集成测试与缺陷修复（WBS-5.2~5.4）。
- 写 Alpha 小结和团队作业3 随笔。

二、系统设计

2.1 总体架构概览

本系统采用B/S 架构 + 前后端分离 + 分层设计，主要划分为三层：

表示层（Presentation Layer）
- 技术栈：HTML / CSS / JavaScript（可后续引入 Vue）。
- 运行环境：浏览器。
- 职责：展示页面、处理交互、调用后端 REST API。
业务逻辑层（Business Layer）
- 技术栈：Flask（Python）+ RESTful API。
- 模块：用户与角色模块、场馆模块、预约模块、通知模块、统计模块。
- 职责：实现业务规则（包括收费规则、预约冲突规则、取消规则等），封装业务接口。
数据访问层（Data Access Layer）
- 技术栈：MySQL + SQLAlchemy（或原生 SQL）。
- 职责：数据持久化，负责表结构定义、查询与事务控制。

简单示意图：

[ 浏览器前端 ]|v
[ Flask REST API (用户、场馆、预约、统计、通知) ]|v
[ MySQL 数据库 (User / Venue / Reservation / ...) ]

2.2 模块划分与接口说明

（1）用户与角色模块

功能：
- 用户注册 / 登录 / 注销；
- 角色区分：student / teacher / admin；
- 权限控制中间件（未登录不能访问预约接口）。
典型接口：
- POST /api/auth/register
- POST /api/auth/login
- GET /api/users/me

（2）场馆模块

功能：
- 场馆信息增删改查；
- 设置每个场馆的开放时间、容量；
- 设置收费标准：
  - 学生单价 price_per_hour_student；
  - 教职工是否免费 is_teacher_free。
典型接口：
- GET /api/venues
- GET /api/venues/{id}
- POST /api/admin/venues
- PUT /api/admin/venues/{id}

（3）预约模块

功能：
- 创建预约：日期 + 起止时间段 + 场馆；
- 冲突检测：
  - 同一场馆同一时间段不可重复被预约；
  - 同一用户同一时间段只能有一个有效预约；
- 费用计算：
  - 学生：单价 × 时长；
  - 教职工：为 0（免费）。
- 取消预约 & 状态流转。
典型接口：
- POST /api/reservations
- GET /api/reservations/my
- DELETE /api/reservations/{id}

（4）通知模块

功能：
- 封装通用邮件发送函数；
- 在预约成功、取消、管理员变更时发送通知；
- 后续可扩展短信/微信等渠道。
实现方式：
- 后端在业务操作成功后调用通知模块；
- 可异步处理（后续阶段再做优化）。

（5）统计模块（Alpha 最小版）

功能：
- 按场馆统计预约次数、使用率；
- 为管理员端图表提供数据接口。
典型接口：
- GET /api/admin/statistics/venue-usage?from=...&to=...

2.3 数据库设计

2.3.1 核心实体与字段设计

下表只给出核心字段。

（1）用户表 `users`

字段名	类型	说明
`id`	INT, PK, AUTO_INCREMENT	用户 ID
`name`	VARCHAR	姓名
`student_no` / `work_no`	VARCHAR	学号 / 工号（其一或同时存在）
`email`	VARCHAR, UNIQUE	邮箱（用于登录 & 通知）
`password_hash`	VARCHAR	加密后的密码
`role`	ENUM('student','teacher','admin')	角色
`created_at`	DATETIME	创建时间

（2）场馆表 `venues`

字段名	类型	说明
`id`	INT, PK	场馆 ID
`name`	VARCHAR	场馆名称（篮球馆、羽毛球馆等）
`type`	VARCHAR	类型（basketball、badminton…）
`location`	VARCHAR	地理位置/校区
`capacity`	INT	可容纳人数或场地数量
`open_time_info`	VARCHAR / TEXT	开放时间描述
`price_per_hour_student`	DECIMAL	学生每小时收费
`is_teacher_free`	TINYINT(1)	教职工是否免费（一般为 1）
`description`	TEXT	场馆介绍

（3）预约表 `reservations`

字段名	类型	说明
`id`	INT, PK	预约 ID
`user_id`	INT, FK → `users.id`	预约人
`venue_id`	INT, FK → `venues.id`	场馆
`date`	DATE	预约日期
`start_time`	TIME	开始时间
`end_time`	TIME	结束时间
`price`	DECIMAL	本次预约金额（学生>0，教职工=0）
`status`	ENUM('reserved','cancelled','finished')	状态
`created_at`	DATETIME	创建时间

索引建议：

(venue_id, date, start_time, end_time) 唯一索引 → 防止同场馆同时间段重复预约；

(user_id, date, start_time, end_time) 非唯一索引 → 业务层再做“同一用户同一时间只能有一条有效预约”的检查。

（4）意见反馈表 `feedbacks`（可选）

字段名	类型	说明
`id`	INT, PK	反馈 ID
`user_id`	INT, FK	提交者
`content`	TEXT	反馈内容
`created_at`	DATETIME	提交时间
`status`	ENUM('unread','processed')	处理状态
`reply`	TEXT	管理员回复

三、Alpha任务分配计划

3.1 Product Backlog 选择 Alpha 功能项

3.1.1 Product Backlog 功能清单（节选）

编号	功能	描述	优先级
PB-1	用户注册 / 登录	基于邮箱 + 密码，支持角色区分	P0
PB-2	用户信息维护	修改个人资料	P1
PB-3	场馆列表 & 详情展示	查看场馆基本信息、开放时间、收费规则等	P0
PB-4	场馆预约创建	选择日期 + 时间段 + 场馆，检查冲突，计算费用	P0
PB-5	预约取消 & 我的预约	查看自己的预约记录并取消	P0
PB-6	管理员场馆管理	场馆信息 / 收费标准增删改查	P0
PB-7	管理员预约管理	查看预约列表、修改状态	P0
PB-8	预约通知邮件	预约成功 / 取消 / 变更邮件	P0
PB-9	预约前提醒邮件	开始前 2 小时提醒	P1
PB-10	场馆使用率统计	预约数据统计接口+图表	P1
PB-11	用户意见反馈	提交 & 管理员回复	P2

3.1.2 Alpha 阶段待实现功能（MVP）

综合优先级、依赖关系和团队时间，我们将以下P0 功能列入 Alpha：

PB-1 用户注册 / 登录
PB-3 场馆列表 & 详情展示
PB-4 场馆预约创建（含冲突检测 + 收费规则）
PB-5 预约取消 & 我的预约
PB-6 管理员场馆管理
PB-7 管理员预约管理
PB-8 预约通知邮件

PB-9（预约前提醒）、PB-10（统计）、PB-11（反馈）暂定为 Beta 阶段实现。

3.2 Sprint Backlog：1–10 小时任务分解与认领

本 Sprint 只覆盖 Alpha 核心功能。所有任务预估工时控制在 1–10 小时 之内。

3.2.1 任务列表

任务 ID	所属功能	任务内容	负责人	预估工时
T-1	PB-1	初始化 Flask 项目结构，配置虚拟环境、基础路由	宋可月	4h
T-2	PB-1	设计用户表结构，与 ORM 映射	戴清	3h
T-3	PB-1	实现注册/登录接口（含密码加密、角色字段）	宋可月	6h
T-4	PB-1	前端登录/注册页开发 + 表单校验	齐畅	6h
T-5	PB-3	设计场馆表结构（含收费字段）	戴清	3h
T-6	PB-3	实现场馆列表 & 详情 API	颜宏宇	5h
T-7	PB-3	前端场馆列表页面布局与样式	赖彦彤	5h
T-8	PB-3	场馆详情页（展示收费、开放时间等）	赖彦彤	5h
T-9	PB-4	预约表结构设计 + 约束（唯一索引）	戴清	4h
T-10	PB-4	实现创建预约 API（含冲突检测、费用计算）	颜宏宇	8h
T-11	PB-4	前端预约日历组件（日期 & 时间段选择）	齐畅	8h
T-12	PB-5	我的预约查询 & 取消预约 API	宋可月	5h
T-13	PB-5	前端“我的预约”页面 + 取消按钮交互	赖彦彤	4h
T-14	PB-6	管理员场馆 CRUD 接口（含收费配置）	颜宏宇	6h
T-15	PB-6	管理员场馆管理页面	齐畅	4h
T-16	PB-7	管理员预约列表查询 & 状态更新接口	宋可月	5h
T-17	PB-7	管理员预约管理页面	齐畅	4h
T-18	PB-8	通用邮件发送模块（Flask-Mail 封装）	曹伟斌	4h
T-19	PB-8	将通知模块接入预约创建/取消流程	曹伟斌 + 颜宏宇	4h
T-20	-	初版测试用例设计（功能 + 接口）	缪子睿	5h
T-21	-	接口测试（Postman）与 BUG 记录	缪子睿	6h
T-22	-	基本系统功能回归测试 + 报告	戴清 + 缪子睿	6h
T-23	-	项目文档与团队作业3 博文整理	缪子睿	4h

说明：

所有任务均可在 1–10 小时内完成，符合作业要求；

PM（宋可月）主要负责后端框架设计、核心接口和任务协调；

测试任务穿插在整个开发过程中，而不是等全部写完才测。

3.3 Alpha 冲刺甘特图

假设 Alpha 冲刺周期为 2 周（14 天），第 1 周偏重设计与基础模块，第 2 周偏重联调与测试。
可以按照此表在 leangoo 里画真正的甘特图。

3.3.1 周视图甘特表

周次 / 日期	主要任务	涉及任务 ID	负责人
第 1 周 Day1–Day2	搭建后端骨架、DB 初始设计、登录注册基本完成	T-1 ~ T-4, T-2, T-5	宋可月、戴清、齐畅
第 1 周 Day3–Day4	场馆模块后端 & 前端列表/详情页	T-6 ~ T-8	颜宏宇、赖彦彤
第 1 周 Day5–Day6	预约表设计、预约 API 初版、预约日历组件开发	T-9 ~ T-11	戴清、颜宏宇、齐畅
第 1 周 Day7	我的预约 & 取消接口 + 页面	T-12, T-13	宋可月、赖彦彤
第 2 周 Day8–Day9	管理员场馆/预约管理后台接口 & 页面	T-14 ~ T-17	宋可月、颜宏宇、齐畅
第 2 周 Day10	邮件模块封装 & 挂载到预约流程	T-18, T-19	曹伟斌、颜宏宇
第 2 周 Day11–Day12	编写测试用例、接口测试、功能测试、修复关键 BUG	T-20 ~ T-22	戴清、缪子睿、全组配合
第 2 周 Day13–Day14	回归测试、整理文档与博客、准备课堂展示	T-22, T-23	全组

3.3.2 甘特图

第1周:
Day1-2: [T-1,T-2,T-3,T-4,T-5]  后端骨架+登录注册+DB基础
Day3-4: [T-6,T-7,T-8]          场馆模块前后端
Day5-6: [T-9,T-10,T-11]        预约模块核心
Day7:   [T-12,T-13]            我的预约 & 取消第2周:
Day8-9: [T-14,T-15,T-16,T-17]  管理员后台
Day10:  [T-18,T-19]            邮件通知模块
Day11-12:[T-20,T-21,T-22]      测试与修复
Day13-14:[T-22,T-23]           回归测试 & 文档、博客

四、测试计划

测试不是在所有的开发工作完成之后才进行，而是与开发几乎同步进行的【测试的计划和执行】。因此，我们在 Alpha 阶段就给出整体测试计划，并在开发迭代中不断细化和调整。

4.1 产品概述与测试目标

产品名称： 体育场馆预约系统（Sports Venue Reservation System）

系统面向 学生、教师和学校管理人员，提供线上浏览场馆、选择时段、提交预约、接收通知、查看统计等功能，后台为管理员提供场馆配置和数据管理能力。

本次测试计划的总体目标是：

在 Alpha 阶段验证核心预约流程「登录 → 选择场馆与时段 → 提交预约 → 接收通知 → 取消 / 查看记录」的正确性与稳定性；
在限定时间和资源内尽可能提前发现并修复严重缺陷，降低后续迭代的风险；
为后续 Beta 阶段测试设计、回归测试和上线验收提供可复用的测试用例和数据基础。

4.2 测试范围与测试类型

4.2.1 测试范围

本阶段测试范围聚焦于 Alpha 选定的核心功能（对应前文 Product Backlog）：

用户模块
- 用户注册 / 登录 / 退出
- 不同角色（学生、教师、管理员）的权限控制
场馆模块
- 场馆列表与详情展示（名称、类型、位置、开放时间、收费规则等）
- 管理员维护场馆信息、收费标准
预约模块
- 创建预约（日期 + 时间段 + 场馆）
- 学生付费、教职工免费等收费规则
- 冲突检测（同一场馆/同一用户同一时间不可重复占用）
- 查看“我的预约”和取消预约
通知模块
- 预约成功、取消等邮件通知
管理后台
- 管理员查看预约列表、修改状态（通过/取消）

不在 Alpha 范围内（但会在后续迭代重点关注）的包括：

较复杂的数据统计与可视化；
高并发性能压测；
深度安全渗透测试等。

4.2.2 测试类型

结合系统特点和迭代时间，本阶段主要采用以下测试类型：

功能测试（黑盒）
- 按需求规格说明书和原型，对各模块功能正确性进行验证；
- 覆盖正常路径与主要异常路径（非法输入、越界时间、越权操作等）。
接口测试
- 使用 Postman 等工具对后端 REST API 进行参数组合、错误码、鉴权等测试；
- 确保前后端分离场景下 API 稳定、返回格式统一。
用户界面与易用性测试（初级）
- 核查表单校验提示、按钮状态、页面跳转是否合理；
- 观察典型用户（同组同学）在完成一个预约任务时的操作路径和困惑点。
兼容性测试（轻量）
- 浏览器兼容性：主测 Chrome / Edge（桌面端），给出后续多浏览器测试矩阵扩展方案。
回归测试
- 每次修复中高优先级缺陷后，执行相关用例集，验证原有功能未被破坏。

4.3 测试策略与方法

4.3.1 总体策略（5W1H）

Why（为什么测）
- 保证核心预约流程在 Alpha 阶段可稳定演示和使用；
- 尽早发现设计/实现问题，降低后续修改成本。
What（测什么）
- 测试范围中列出的核心功能及其主要业务规则；
- 关键非功能：基础兼容性、基本性能（响应时间是否可接受）。
When（何时测）
- 在功能开发完成一个“可运行切片”后立即安排测试；
- 不是“最后一天集中测试”，而是贯穿迭代全过程。
Who（谁来测）
- 由小组中负责测试与文档的同学主导执行；
- 功能开发者对自己模块进行基本单元测试和自测。
Where（在哪里测）
- 开发/测试环境服务器（Flask + MySQL 测试库）；
- 缺陷记录在共享的在线文档或敏捷工具中。
How（如何测）
- 以黑盒功能测试为主，接口测试和简单白盒（日志分析、边界值）为辅；
- 通过测试用例文档驱动测试执行，使用 Postman、浏览器开发者工具等辅助。

4.3.2 测试方法

黑盒测试
- 等价类划分、边界值分析：例如预约时间的起止边界、一人一天最大预约次数等；
- 场景/流程法：围绕“学生预约一个羽毛球馆并取消”的完整故事编写用例。
白盒/灰盒测试（轻量）
- 对复杂业务（例如费率计算、冲突检测）由开发者在本地添加断点与日志，结合 SQL 查询验证内部状态。
探索式测试
- 测试人员在执行完脚本化用例后，尝试“乱点一通”：重复点击、快速切换日期、并行开多个标签页等，以发现隐蔽问题。

4.4 测试阶段与时间安排

结合 Alpha 冲刺的两周周期，我们将测试活动与开发同步规划，而不是“开发完再统一测试”。

阶段	时间示意	主要测试活动
阶段 0：准备	冲刺前 0.5 天	阅读需求规格说明书，搭建测试环境，编写初版测试计划与用例模板
阶段 1：模块开发早期	第 1–3 天	随功能开发同步：对登录/注册、场馆列表等完成冒烟测试，及时反馈严重缺陷
阶段 2：核心功能联调	第 4–7 天	对“预约创建”“我的预约”“管理员后台”等核心流程执行功能测试与接口测试，回归修复缺陷
阶段 3：Alpha 收尾	第 8–9 天	回归测试 + 简单兼容性测试；整理缺陷统计与测试小结，为下一迭代提供输入

每个阶段结束时，测试负责人会更新测试计划与用例，根据实际进展调整测试重点，这也符合“测试计划并非一成不变，而需根据项目变化持续修订”的观点。

4.5 测试角色分工

具体姓名在前两篇团队博文中已有介绍，这里只按角色说明职责。

测试负责人（主测）
- 编写和维护测试计划、测试用例；
- 组织评审测试用例，协调测试资源；
- 负责缺陷的收集、跟踪和测试报告总结。
模块开发者（前端 / 后端）
- 对自己负责的功能进行单元测试和基本自测；
- 对发现的缺陷进行分析和修复，并配合回归测试。
协同测试人员
- 按照用例执行功能测试、接口测试；
- 参与用户体验测试，从“普通学生/老师”的视角提出改进建议。

在团队规模较小的情况下，实行“开发兼任测试 + 专人主测”的模式：既不完全依赖测试同学，也强调开发人员对质量负责。

4.6 测试环境与资源

4.6.1 硬件环境

学校实验室或个人电脑（8G 内存及以上）；
局域网或校园网环境下的测试服务器（可与开发服务器合并）。

4.6.2 软件环境

后端：Flask + Python + MySQL 测试库（独立于生产库）；
前端：Chrome / Edge 浏览器；
测试工具：
- Postman：接口测试与接口回归；
- 浏览器开发者工具（Network / Console）：调试前端交互问题；
- Leangoo 或类似工具：记录任务和缺陷状态；
- 在线文档：维护测试用例、测试报告。

这些资源在测试计划中列出，是为了让团队清楚完成测试所需的硬件、软件和人员条件。

4.7 风险与对策

本项目 Alpha 阶段的主要测试风险：

时间风险：开发延期导致可测试时间被压缩
- 对策：在迭代早期就安排冒烟测试，不把所有测试堆到最后两天；对核心流程优先测试。
需求理解不一致：测试与开发对“免费/收费规则”“冲突检测”等理解不同
- 对策：测试前组织一次需求走查会议，统一关键业务规则；发现歧义及时更新需求与测试用例。
环境不一致：开发环境与测试环境配置不同，导致“测得好、部署坏”
- 对策：在测试计划中明确环境配置，并尽量与预期部署环境保持一致；用脚本统一初始化数据库和配置。