团队作业3--需求改进&系统设计

图书馆管理系统需求规划设计书

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/Class34Grade23ComputerScience/
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/Class34Grade23ComputerScience/homework/13482
这个作业的目标	对图书馆管理系统进行需求改进和系统设计

一、需求&原型改进

1.1 课堂反馈问题及需求修改

问题1：跨模块协作机制缺失，前端与后端开发按独立节奏推进，未建立常态化同步机制，导致集成阶段出现接口不兼容、数据格式不匹配等问题。
修改1：搭建"每日站会+周迭代评审"的协作框架，每日站会聚焦"昨日进展-今日计划- blockers"三个核心问题，每周迭代评审同步各模块进度与衔接需求；建立接口规范前置确认机制，在开发前完成交互标准的共同评审与签字确认。
问题2：项目进度跟踪缺乏量化指标，仅以"已完成/进行中"描述状态，无法精准掌握任务推进节奏与瓶颈所在，导致风险预警滞后。
修改2：建立任务进度量化评估体系，将每个任务拆解为"需求分析-方案设计-开发实现-单元测试"四个子节点，每个节点对应明确的交付物与完成标准，以子节点完成率作为进度量化依据，每日同步进度数据至团队共享看板。

1.2 原说明书不足

资源分配缺乏弹性，未考虑开发过程中的人员变动或任务复杂度升级情况，导致资源紧张时无法快速调整。
风险管控体系缺失，仅关注正常流程推进，未识别项目推进中的潜在风险（如第三方工具适配问题、开发环境冲突等）及应对预案。
沟通效率低下，需求变更与信息同步依赖即时通讯工具零散传递，未建立结构化的信息传递渠道，导致信息衰减与误解。
项目交付物标准不明确，仅列出交付物名称，未定义交付物的格式、内容深度及验收标准，影响交付质量评估。

1.3 功能分析四象限（重要与紧急）

象限	任务类型	核心任务示例	处理策略
紧急且重要	核心管理支撑	RACI矩阵制定、统一开发环境搭建、接口规范确认	Alpha阶段优先启动，投入50%核心资源，资深成员牵头，每日跟进进度，3天内完成基础框架
重要不紧急	长期保障工作	风险管控矩阵搭建、交付物验收规范制定、协作手册编写	Alpha阶段搭框架，Beta阶段完善细节，PM主导联合各模块负责人推进，每周评审迭代
紧急不重要	辅助支撑工作	项目管理平台配置、共享看板搭建、会议纪要模板设计	机动资源快速完成，采用标准化模板（如Leangoo敏捷模板），减少定制化成本
不紧急不重要	优化提升工作	团队文化活动、项目文档美化、历史资料归档	暂不列入Alpha/Beta计划，核心任务稳定后利用碎片化时间推进
1.4 任务分解WBS及进度计划调整

1.4.1 调整后WBS（核心层级）

项目阶段	核心任务模块	具体任务内容
需求改进与规划优化（第11周）	分工与协作机制建设	RACI责任分配矩阵设计、矩阵评审与修订、站会及评审流程规范
风险与资源管理	风险点识别与分类、风险管控矩阵搭建、弹性资源池人员梳理
支撑体系落地（第11-12周）	管理工具配置	Leangoo项目空间搭建、共享进度看板配置、看板测试与调试
标准与规范制定	交付物验收规范编写、接口交互标准确认、会议纪要及文档模板设计
Alpha开发支撑（第12-13周）	技术保障	统一开发环境搭建、开发环境测试与适配、接口规范签字确认
进度管控	开发任务颗粒化拆解、进度量化跟踪表设计、管控体系试运行

1.4.2 调整后进度计划（第11-15周）

周数	核心任务内容	负责人	交付物	验收标准
第12周	1. RACI矩阵设计与评审；2. 风险管控矩阵梳理；3. Leangoo项目空间搭建；4. 统一开发环境搭建	张滨皓、柯程炜、王佳俊	签字版RACI矩阵、风险管控矩阵、Leangoo空间、开发环境配置手册	矩阵全员通过评审，开发环境支持3人同时接入无冲突
第13周	1. 共享看板配置与测试；2. 验收规范与接口标准制定；3. 开发任务拆解；4. 进度跟踪表设计	张滨皓、柯程炜、王佳俊	可用共享看板、验收规范文档、签字版接口标准、任务拆解表	看板支持状态自动更新，任务颗粒度≤8小时/项
第14周	1. 管控体系试运行；2. 试运行问题收集与优化；3. 全套管理文档整理；4. 阶段成果评审	张滨皓、柯程炜、王佳俊	优化报告、全套管理文档、阶段评审纪要	解决试运行中80%问题，文档符合验收规范

二、系统设计

2.1 系统架构设计

2.1.1 架构模式选择
采用分层式 B/S 架构（浏览器 / 服务器），搭配 “前后端分离” 设计理念。相比传统 C/S 架构，B/S 模式无需客户端安装，适配学校多终端办公场景（办公室电脑、移动设备临时查询）；前后端分离则实现 “前端专注交互、后端聚焦逻辑” 的分工模式，支持独立迭代与测试，大幅提升开发效率。

2.1.2 架构层次详细设计

架构层次	核心技术选型	核心职责	设计亮点
前端表现层	Vue.js + Element UI + ECharts	负责用户交互与数据展示，按角色提供差异化界面（管理员操作面板、班主任数据看板、家长查询页）；支持响应式布局，适配电脑端主流浏览器；实现表单校验、批量操作组件、数据可视化图表渲染	1. 封装 “批量导入 / 导出” 专用组件，适配行政人员高频批量处理需求；2. 基于角色动态渲染菜单与操作按钮，无需前端额外判断权限；3. 关键操作（如批量修改成绩）增加二次确认与操作日志记录
网关层	Spring Cloud Gateway	作为前后端通信的统一入口，负责请求路由、权限预检、限流熔断、日志收集；拦截未授权请求并跳转至登录页，对高频接口（如成绩查询）设置限流阈值	1. 针对学校高峰期（如成绩录入阶段）设计动态限流策略，避免系统过载；2. 集成接口签名校验，防止非法请求篡改数据；3. 统一封装响应格式，简化前后端数据解析逻辑
后端应用层	Java + Spring Boot + Spring Security	核心业务逻辑处理层，按功能模块拆分（基础信息管理、学业管理、奖惩管理、权限管理、数据统计）；实现业务规则校验、跨模块流程联动、第三方服务对接（如 Excel 解析、报表生成）	1. 采用 “领域驱动设计（DDD）” 思想，按业务场景拆分服务，降低模块依赖；2. 权限管理基于 RBAC 模型扩展，支持 “角色 - 菜单 - 操作” 三级权限控制；3. 核心业务（如成绩计算、考勤统计）增加事务管理，确保数据一致性
数据访问层	MyBatis-Plus + Redis	封装数据库操作，提供 CRUD 基础接口与复杂查询支持；通过 Redis 缓存高频访问数据（如班级列表、学生基础信息），减少数据库压力；支持数据批量操作与事务回滚	1. 针对批量导入场景优化 SQL，支持千级数据快速入库；2. 缓存数据设置过期时间，结合主动刷新机制，确保数据实时性；3. 封装通用查询条件构造器，简化复杂条件查询开发
数据存储层	MySQL + 本地备份 + 加密存储	采用 MySQL 作为主数据库，按功能模块分表设计（学生表、课程表、成绩表等）；敏感数据（如家长联系方式、学生身份证号）采用 AES 加密存储，用户密码通过 BCrypt 算法加盐哈希处理；支持每日自动备份与手动备份，备份文件加密存储	1. 数据库分表设计，提升查询效率（如成绩表按年级分表）；2. 敏感字段加密存储，密钥独立管理，符合数据安全规范；3. 备份策略支持 “全量备份 + 增量备份”，确保数据可追溯与恢复

2.1.3 架构交互流程（以“班主任批量录入班级成绩”为例）

班主任登录系统后，进入 “学业管理 - 成绩录入” 模块，上传 Excel 格式的班级成绩表；
前端表现层校验 Excel 格式（列名、数据类型），通过网关层发送 “批量导入” 请求，附带班主任角色令牌；
网关层校验令牌有效性与操作权限，路由请求至后端应用层的 “学业管理服务”；
应用层解析 Excel 数据，校验课程合法性、学生学号存在性，过滤无效数据；
数据访问层通过批量 SQL 将有效成绩写入数据库，同时更新 Redis 中对应班级的成绩缓存；
数据存储层执行入库操作并返回结果，应用层生成导入报告（成功条数、失败条数及原因）；
网关层将结果返回至前端，前端展示导入报告，支持失败数据下载修正后重新导入。

2.2 数据库设计

2.2.1 核心实体及关系

系统核心实体围绕 “学生管理全生命周期” 设计，共包含 8 个核心实体，实体间关系如下：

核心实体：学生（Student）、班级（Class）、课程（Course）、成绩（Score）、考勤（Attendance）、奖惩记录（RewardPunish）、用户（User）、角色（Role）；
核心关系：
1. 学生与班级：多对一（多个学生归属一个班级，一个班级包含多个学生）；
2. 学生与课程：多对多（一个学生可选修多门课程，一门课程对应多个学生），通过 “成绩表” 关联；
3. 学生与考勤 / 奖惩记录：一对多（一个学生对应多条考勤 / 奖惩记录）；
4. 用户与角色：多对一（一个用户对应一个角色，一个角色可分配给多个用户）；
5. 角色与菜单：多对多（一个角色可拥有多个菜单权限，一个菜单可分配给多个角色）。

2.2.2 核心实体关系与表结构

+---------------+       +---------------+       +---------------+
|    Student    |       |     Class     |       |    Course     |
+---------------+       +---------------+       +---------------+
| id (PK)       |<----->| id (PK)       |       | id (PK)       |
| name          |       | name          |       | name          |
| student_no    |       | grade         |       | code          |
| gender        |       | teacher_id    |<----->| credit        |
| class_id (FK) |       | create_time   |       | semester      |
| id_card       |       | update_time   |       | teacher_id    |
| parent_phone  |       +---------------+       | create_time   |
| create_time   |                              | update_time   |
| update_time   |                              +---------------+
+---------------+                                       ^
        |                                               |
        |                                               |
        v                                               |
+---------------+       +---------------+       +---------------+
|  Attendance   |       | RewardPunish  |       |     Score     |
+---------------+       +---------------+       +---------------+
| id (PK)       |       | id (PK)       |       | id (PK)       |
| student_id(FK)|       | student_id(FK)|       | student_id(FK)|
| date          |       | type          |       | course_id(FK) |
| status        |       | reason        |       | score         |
| remark        |       | proof_file    |       | rank          |
| create_time   |       | create_time   |       | semester      |
+---------------+       | update_time   |       | create_time   |
                        +---------------+       | update_time   |
                                                +---------------+
+---------------+       +---------------+
|     User      |       |     Role      |
+---------------+       +---------------+
| id (PK)       |<----->| id (PK)       |
| username      |       | name          |
| password      |       | desc          |
| real_name     |       | create_time   |
| role_id (FK)  |       | update_time   |
| phone         |       +---------------+
| status        |
| create_time   |
| update_time   |
+---------------+

2.2.3 核心表结构设计（MySQL）

班级表（class）

CREATE TABLE `class` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '班级ID（主键）',
  `name` varchar(50) NOT NULL COMMENT '班级名称（如：高一(3)班）',
  `grade` varchar(20) NOT NULL COMMENT '年级（如：高一、高二）',
  `teacher_id` bigint NOT NULL COMMENT '班主任ID（关联user表id）',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  KEY `idx_grade` (`grade`),
  KEY `idx_teacher_id` (`teacher_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='班级信息表';

学生表（student）

CREATE TABLE `student` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '学生ID（主键）',
  `name` varchar(50) NOT NULL COMMENT '学生姓名',
  `student_no` varchar(20) NOT NULL COMMENT '学号（唯一标识）',
  `gender` tinyint NOT NULL COMMENT '性别（0：男，1：女）',
  `class_id` bigint NOT NULL COMMENT '所属班级ID（关联class表id）',
  `id_card` varchar(18) DEFAULT NULL COMMENT '身份证号（加密存储）',
  `parent_phone` varchar(11) DEFAULT NULL COMMENT '家长手机号（加密存储）',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_student_no` (`student_no`),
  KEY `idx_class_id` (`class_id`),
  KEY `idx_name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生基础信息表';

课程表（course）

CREATE TABLE `course` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '课程ID（主键）',
  `name` varchar(50) NOT NULL COMMENT '课程名称（如：数学、语文）',
  `code` varchar(20) NOT NULL COMMENT '课程编码（唯一标识）',
  `credit` decimal(2,1) NOT NULL COMMENT '学分',
  `semester` varchar(20) NOT NULL COMMENT '学期（如：2024-2025学年上学期）',
  `teacher_id` bigint NOT NULL COMMENT '授课教师ID（关联user表id）',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_code` (`code`),
  KEY `idx_semester` (`semester`),
  KEY `idx_teacher_id` (`teacher_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='课程信息表';

成绩表（score）

CREATE TABLE `score` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '成绩ID（主键）',
  `student_id` bigint NOT NULL COMMENT '学生ID（关联student表id）',
  `course_id` bigint NOT NULL COMMENT '课程ID（关联course表id）',
  `score` decimal(5,1) NOT NULL COMMENT '分数（如：95.5）',
  `rank` int DEFAULT NULL COMMENT '班级排名',
  `semester` varchar(20) NOT NULL COMMENT '学期',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_student_course_semester` (`student_id`,`course_id`,`semester`),
  KEY `idx_course_id` (`course_id`),
  KEY `idx_semester` (`semester`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生成绩表';

奖惩记录表（reward_punish）

CREATE TABLE `reward_punish` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '记录ID（主键）',
  `student_id` bigint NOT NULL COMMENT '学生ID（关联student表id）',
  `type` tinyint NOT NULL COMMENT '类型（0：奖励，1：惩罚）',
  `reason` varchar(200) NOT NULL COMMENT '原因（如：校级三好学生、迟到3次）',
  `proof_file` varchar(255) DEFAULT NULL COMMENT '证明文件路径（如获奖证书扫描件）',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  KEY `idx_student_id` (`student_id`),
  KEY `idx_type` (`type`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生奖惩记录表';

用户表（user）（含管理员、班主任、家长）

CREATE TABLE `user` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '用户ID（主键）',
  `username` varchar(50) NOT NULL COMMENT '登录账号（唯一）',
  `password` varchar(100) NOT NULL COMMENT '登录密码（BCrypt加密）',
  `real_name` varchar(50) NOT NULL COMMENT '真实姓名',
  `role_id` bigint NOT NULL COMMENT '角色ID（关联role表id）',
  `phone` varchar(11) DEFAULT NULL COMMENT '联系电话',
  `status` tinyint NOT NULL DEFAULT '1' COMMENT '状态（0：禁用，1：正常）',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_username` (`username`),
  KEY `idx_role_id` (`role_id`),
  KEY `idx_status` (`status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='系统用户表（含管理员、班主任、家长）';

角色表（role）

CREATE TABLE `role` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '角色ID（主键）',
  `name` varchar(50) NOT NULL COMMENT '角色名称（如：超级管理员、班主任、家长）',
  `desc` varchar(200) DEFAULT NULL COMMENT '角色描述',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='角色表';

2.2.4 数据库设计亮点

针对性优化批量操作：成绩表、学生表设计了联合唯一索引，避免重复数据；支持批量导入时的高效校验与入库，适配行政人员高频批量处理需求；
数据安全合规：敏感字段（身份证号、家长手机号）采用 AES 加密存储，密码通过 BCrypt 加盐哈希处理，符合学生信息安全保护要求；
查询效率优化：核心查询字段（如班级 ID、学期、学生 ID）均建立索引，成绩表按 “学生 - 课程 - 学期” 联合索引避免重复记录，提升查询响应速度；
扩展性强：角色与权限分离设计，支持后续新增 “年级组长”“学科老师” 等角色，无需修改核心表结构；课程表与成绩表通过学期关联，支持跨学年数据管理。

三、Alpha任务分配计划

本次迭代计划会议于第12周周五召开，团队全员（张滨皓、柯程炜、王佳俊）共同参与，基于Scrum敏捷框架，明确Alpha阶段（第12-13周，共2周）的Sprint目标、任务范围与执行计划。核心目标为完成“基础信息管理+核心学业管理”的可用版本，支撑行政人员完成学生信息录入、成绩管理等核心操作，所有任务通过Leangoo平台进行协作跟踪。

3.1 迭代计划会议核心结论

3.1.1 团队资源与时间基线

参与人员：后端开发2人（张滨皓、柯程炜）、前端开发+测试1人（王佳俊），PM全程协调；
总可用时间：120小时（每人每周20小时，2周×3人×20小时/人）；
时间分配原则：开发时间占比75%（90小时），测试与Bug修复占比20%（24小时），缓冲时间占比5%（6小时），应对需求变更与任务延期。

3.1.2 Sprint目标与功能优先级排序

基于Product Backlog，结合“核心需求先落地、高依赖模块优先开发”原则，通过“MoSCoW方法”划分功能优先级，最终选取以下功能项进入Sprint Backlog：

优先级	功能模块	核心价值	依赖关系
Must have（必须实现）	学生基础信息管理（增删改查+批量导入）	系统核心数据基础，所有后续功能依赖学生数据	无前置依赖，为最高优先级
Must have（必须实现）	班级信息管理（增删改查+班主任关联）	实现学生按班级归类，支撑班主任权限控制	依赖用户表中“班主任”角色数据
Must have（必须实现）	基础权限控制（角色分配+菜单权限）	保障数据安全，实现“管理员-班主任”权限隔离	依赖用户表与角色表设计
Should have（应该实现）	课程信息管理（增删改查）	学业管理的基础模块，支撑成绩录入功能	无直接依赖，可与基础信息模块并行开发
Should have（应该实现）	成绩录入与查询（单条录入+班级查询）	核心学业功能，满足班主任高频操作需求	依赖学生、班级、课程模块
Could have（可以实现）	基础数据统计（班级人数+成绩平均分）	提供初步数据洞察，提升系统实用性	依赖学生、成绩模块

3.2 Sprint Backlog（任务拆解与认领）

在PM协助下，将上述功能模块拆解为1-10小时的细粒度任务，明确任务描述、预估时间、负责人及验收标准，所有任务同步至Leangoo平台，通过“待开始-执行中-待验收-已完成”状态跟踪进度。

模块分类	任务描述	预估时间（小时）	负责人	验收标准	Leangoo任务状态
后端基础模块	数据库表设计（学生表、班级表、用户表、角色表）	8	张滨皓	表结构含主键、外键、索引，字段注释完整，符合数据安全规范	已完成
基础实体类与Mapper接口开发（学生、班级）	6	张滨皓	实体类属性与表字段对应，含Getter/Setter及构造方法，Mapper支持基础CRUD	已完成
用户与角色实体类、Service接口开发	5	柯程炜	实现角色与用户关联查询，Service含权限校验基础方法	执行中
课程与成绩实体类、Mapper接口开发	6	柯程炜	成绩表含“学生-课程-学期”联合唯一约束，避免重复数据	待开始
后端业务接口	学生信息CRUD接口开发（含批量导入）	10	张滨皓	支持单条增删改查，批量导入Excel格式正确，支持千级数据入库	执行中
班级与班主任关联接口开发	4	张滨皓	支持班级绑定班主任，查询班级时可关联获取班主任信息	待开始
基于RBAC的权限控制接口开发	8	柯程炜	根据用户角色返回可访问菜单，接口请求需携带令牌并校验权限	待开始
课程信息CRUD接口开发	5	柯程炜	支持课程增删改查，课程编码唯一不可重复	待开始
成绩录入与查询接口开发（含班级维度）	9	张滨皓	支持单条成绩录入，班主任可查询本班所有学生成绩，返回数据含排名	待开始
前端开发	前端项目初始化与基础布局搭建（含登录页）	6	王佳俊	项目集成Element UI，实现响应式布局，登录页支持账号密码验证	已完成
学生与班级管理页面开发（含批量导入组件）	10	王佳俊	页面含增删改查按钮，批量导入组件支持Excel上传与格式校验	执行中
课程与成绩管理页面开发	8	王佳俊	成绩录入支持下拉选择学生与课程，数据提交前做格式校验	待开始
基础数据统计页面开发（班级人数+平均分图表）	6	王佳俊	集成ECharts图表，支持按年级筛选，数据实时渲染	待开始
测试与优化	编写测试用例（含接口测试与功能测试）	4	王佳俊	测试用例覆盖所有核心功能，含正常场景与异常场景（如无效学号录入）	执行中
系统测试与Bug修复（前后端联调）	20	全体成员	核心功能无致命Bug，接口响应时间≤1秒，页面操作流畅无卡顿	待开始

3.3 Alpha阶段迭代冲刺计划

基于任务依赖关系与负责人时间分配，通过甘特图明确各任务的起止时间、里程碑节点，所有时间节点同步至Leangoo平台，PM每日通过站会同步进度，确保按计划推进。

3.3.1 甘特图核心信息

任务阶段	时间	核心任务集群	负责人	里程碑成果
启动与基础开发阶段	第12周	数据库设计、基础实体类开发、前端项目初始化	张滨皓、柯程炜、王佳俊	完成核心数据库表设计，前后端基础框架搭建完成
核心功能开发阶段	第12周至第14周	学生/班级/课程接口开发、对应前端页面开发、权限控制接口开发	张滨皓（后端核心）、柯程炜（权限）、王佳俊（前端）	完成“基础信息管理+权限控制”全流程开发，支持学生信息录入与查询
业务功能完善阶段	第14周	成绩录入与查询接口开发、前端成绩页面开发、数据统计页面开发	张滨皓、王佳俊	完成学业管理核心功能，支持成绩录入、查询与基础统计
测试与优化阶段	第14周	编写测试用例、系统测试、Bug修复、前后端联调	全体成员	Alpha版本上线，核心功能可用，无致命Bug

3.3.1 甘特图

四、测试计划
测试工作遵循“开发与测试并行”的敏捷测试理念，不依赖所有开发任务完成后集中执行，而是与开发过程同步推进——核心功能模块开发完成后立即启动对应测试，通过“边开发、边测试、边反馈、边优化”的模式，提前暴露问题、降低修复成本，确保Alpha阶段交付的系统版本稳定可用。

4.1 测试总纲

4.1.1 测试目标

验证学生信息管理系统Alpha阶段核心功能（基础信息管理、学业管理、权限控制等）是否符合需求规格说明书，确保功能可用、流程通顺；
保障系统性能满足预期指标（单条数据查询响应时间≤1秒，支持100+用户同时在线）；
排查数据安全风险（敏感信息加密、权限隔离等），避免数据泄露或越权操作；
优化用户操作体验，确保界面交互符合行政人员工作习惯，无卡顿、闪退等异常。

4.1.2 测试范围

功能测试（核心范围）

测试模块	测试内容	测试重点
基础信息管理	学生/班级信息增删改查、批量导入/导出、数据校验（如学号唯一性、Excel格式兼容性）	批量导入千级数据的成功率、异常数据（如重复学号、格式错误）的容错处理
学业管理	课程增删改查、成绩录入/查询、排名计算、学期关联	成绩录入的准确性、排名逻辑的正确性、跨班级成绩查询的权限控制
权限管理	角色分配、菜单权限控制、接口访问权限校验	班主任仅能查看本班数据、家长仅能查看自家孩子信息，无越权操作漏洞
前端交互	页面跳转、表单提交、按钮点击、图表渲染	响应式布局适配、操作反馈及时性、错误提示清晰度

非功能测试（重点覆盖）

性能测试：单接口并发请求（100+用户同时查询成绩）、批量导入大数据量（1000条学生信息）的响应时间；
安全测试：敏感字段（身份证号、家长手机号）加密存储验证、SQL注入防护、未授权接口访问拦截；
兼容性测试：主流浏览器（Chrome、Edge、Firefox）的页面适配与功能可用性。

4.1.3 测试环境与资源

资源类型	具体配置	负责人
硬件环境	测试服务器：8核CPU、16G内存、500G硬盘；测试终端：Windows 10/11操作系统、主流浏览器（Chrome 120+、Edge 120+）	王佳俊
软件环境	后端：Java 11、Spring Boot 2.7.x、MySQL 8.0；前端：Vue 3、Element UI；测试工具：Postman（接口测试）、Jmeter（性能测试）、Selenium（UI自动化测试）	张滨皓、柯程炜、王佳俊
测试数据	模拟测试数据：30个班级、5000名学生基础信息、10门课程、10000条成绩记录、5种角色账号（超级管理员、班主任、家长等）	张滨皓、柯程炜（提供基础数据脚本）

4.2 测试计划

4.2.1 测试时间安排（与开发并行）

测试阶段	时间范围	核心任务	依赖开发进度	负责人
测试准备阶段	第13周前期	搭建测试环境、编写测试用例（功能测试+接口测试）、准备测试数据	数据库表设计完成、核心接口文档输出	王佳俊
接口测试阶段	第13周-第14周	按模块执行接口测试（学生管理→班级管理→课程管理→成绩管理→权限控制），每日提交接口Bug报告	对应模块接口开发完成（前后端联调前）	王佳俊、柯程炜
UI与功能测试阶段	第13周-第14周	执行前端页面功能测试、交互体验测试，验证“前端操作→后端响应”全流程通顺性	对应模块前端页面开发完成	王佳俊
性能与安全测试阶段	第13周-第14周	执行并发性能测试、数据安全测试，验证系统性能指标与安全防护能力	核心功能开发完成、Bug修复率≥90%	王佳俊、张滨浩
回归测试与验收阶段	第14周	对所有已修复Bug进行回归测试，执行全流程冒烟测试，输出测试报告	所有开发任务完成、高危Bug全部修复	王佳俊、张滨浩、柯程炜

4.2.2 测试任务分工

测试类型	负责人	核心职责	交付物
接口测试	王佳俊、柯程炜	编写接口测试用例、使用Postman执行测试、记录接口Bug、跟踪修复进度	接口测试用例文档、接口Bug清单、接口测试报告
UI与功能测试	王佳俊	编写UI测试用例、执行页面功能测试、验证交互逻辑、记录前端Bug	UI测试用例文档、功能Bug清单、UI测试报告
性能测试	王佳俊、张滨浩	设计性能测试场景、使用Jmeter执行并发测试、分析性能瓶颈	性能测试报告（含响应时间、并发量等指标）
安全测试	王佳俊	验证敏感信息加密、权限隔离、SQL注入防护等安全特性	安全测试报告
回归测试	王佳俊	对已修复Bug重新测试，确保问题彻底解决，无新Bug引入	回归测试报告
验收测试	王佳俊、张滨浩、柯程炜	模拟真实用户场景执行冒烟测试（核心流程：登录→学生信息录入→成绩录入→查询统计）	验收测试纪要

4.2.3 测试流程与Bug管理

测试流程：测试用例编写→测试用例评审（全体成员）→执行测试→发现Bug→提交Bug报告（Leangoo平台）→开发修复→回归测试→Bug关闭；
Bug分级标准： P0（致命Bug）：核心功能不可用（如学生信息无法录入、登录失败），需24小时内修复；
P1（严重Bug）：功能可用但存在严重逻辑错误（如成绩排名计算错误），需48小时内修复；
P2（一般Bug）：非核心功能异常（如页面样式错乱、次要按钮无反馈），需72小时内修复；
Bug反馈机制：每日18:00前，王佳俊在Leangoo平台提交当日Bug报告，标注Bug级别、复现步骤、预期结果；开发人员每日优先修复P0/P1级Bug，修复完成后标注“待回归”，王佳俊次日完成回归测试。

4.2.4 测试交付物

Alpha阶段测试工作结束后，需提交以下交付物：

测试计划文档（含测试总纲、时间安排、分工）；
测试用例文档（接口测试用例+UI功能测试用例）；
Bug清单与修复跟踪报告（含Bug级别、修复率、未修复Bug说明）；
测试报告（功能测试报告、性能测试报告、安全测试报告）；
验收测试纪要（全体成员签字确认）。

4.3 与开发协作机制

每日同步：测试人员参与团队每日站会，同步测试进度、当前遇到的阻塞问题（如开发未按时提供测试环境、接口文档更新不及时）；
模块级联调：每个功能模块开发完成后，开发人员通知测试人员启动对应模块测试，避免“等待全量开发完成再测试”；
紧急Bug快速响应：发现P0级致命Bug时，测试人员立即通过即时通讯工具同步给对应开发人员，开发人员暂停当前非核心任务优先修复，修复后第一时间通知测试人员回归；
测试用例评审：测试用例编写完成后，组织开发人员参与评审，确保测试场景覆盖核心业务逻辑，避免遗漏关键测试点。

posted @ 2025-11-22 23:16 柯程炜阅读(6) 评论(0) 收藏举报

刷新页面返回顶部

团队作业3--需求改进&系统设计

公告