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

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

团队分工说明

赖柏源（项目经理 PM / 前端支持）

角色定位：
总体负责项目规划与节奏把控，组织需求梳理与评审，协调前后端协作与风险，把关文档与展示输出，同时在关键页面提供前端支持。

具体任务：

任务ID	功能模块	任务内容
WBS-1.1/1.2	需求与文档维护	组织整理课堂反馈，主导《需求规格说明书》修订
WBS-1.3	用例 & User Story	确认和评审核心用户场景与用例
T-1	商品信息发布	指导发布表单的字段设计与校验规则（与前端协同）
T-3	商品信息发布	评审并参与关键发布页面的交互与信息结构优化
T-12	测试规划	把关测试计划与用例设计，组织评审与优先级划分
T-14	文档与总结	把关最终项目文档结构与团队作业整体排版与汇总

徐铭阳（后端开发 / 推荐与核心接口）

角色定位：
负责主要业务接口与部分后端逻辑，尤其是商品列表、筛选与后续可扩展的推荐相关接口设计。

具体任务：

任务ID	功能模块	任务内容
T-2	商品信息发布	商品发布后端接口实现（含校验与错误处理）
T-4	商品信息展示	商品列表展示接口实现（支持条件查询与排序）
T-6	商品分类筛选	分类筛选相关后端接口（type、分类、状态等）
T-10	分页展示	列表分页后端支持与性能优化
T-11	频率限制	发布频率限制逻辑实现（如每小时最多 N 条）
T-13	功能测试	参与后端接口联调与接口级测试，修复后端逻辑问题

唐雷（前端开发 / 表单与测试协同）

角色定位：
负责商品发布相关前端页面与交互，包括表单验证、错误提示与部分测试配合，是前端侧的主要实现者之一，同时兼任部分前端测试。

具体任务：

任务ID	功能模块	任务内容
T-1	商品信息发布	商品发布表单页面设计与前端校验逻辑实现
T-3	商品信息发布	发布页面 UI / 交互优化（提示信息、错误反馈等）
T-6	商品分类筛选	发布页分类选择控件前端实现
T-10	分页展示	列表页分页组件前端实现与样式优化
T-13	功能测试	从前端视角进行提测与问题记录，配合 QA 做回归验证

黄龙宇（前端开发 / 列表、详情与交互体验）

角色定位：
负责用户侧列表、详情展示页面以及管理员后台的前端实现与交互体验优化，重点关注可用性与移动端适配。

具体任务：

任务ID	功能模块	任务内容
T-4	商品信息展示	商品列表页面布局与样式优化（含响应式适配）
T-5	商品详情展示	商品详情页展示完善（状态、联系方式、位置等）
T-7	管理员后台	管理员审核界面前端实现（通过/拒绝等操作入口）
T-9	商品状态管理	状态展示与前端状态标识（待审核/已发布/下架等）
T-13	功能测试	管理端与用户端前端联调与测试，关注交互与视觉问题

于子豪（测试 / 质量保证负责人）

角色定位：
负责整体测试策略制定、用例设计与执行，是质量保障的主责人，推动缺陷闭环与回归测试。

具体任务：

任务ID	功能模块	任务内容
T-12	测试规划	设计详细测试用例（功能 / 接口 / 场景用例）
T-13	功能测试	组织并执行功能测试、回归测试，维护缺陷列表
—	接口测试	使用 Postman 等工具做核心接口验证（参数、错误码等）
—	场景测试	按用户故事走完整“发布–审核–浏览”流程测试

袁梓轩（后端开发 / 数据库与性能）

角色定位：
负责数据库结构设计与优化，以及与高频查询相关的性能支持，保证数据一致性与可扩展性。

具体任务：

任务ID	功能模块	任务内容
WBS-2.3	数据库设计	表结构设计与更新（商品 / 用户 / 分类等）
WBS-5.1	初始化数据	初始化数据库脚本（DDL、测试数据导入）
T-4/T-5	性能支持	为列表 / 详情相关查询添加索引与优化方案
T-12	测试规划	协助准备测试数据集，确保测试覆盖不同数据场景
T-13	功能测试	验证数据一致性（状态变更、过期处理等）

姚沛鸿（后端开发 / 运维与部署）*

角色定位：
偏后端与运维方向，负责部署方案、运行环境、日志与监控等工作，保证服务在 Alpha 阶段可稳定运行。

具体任务：

任务ID	功能模块	任务内容
WBS-6.1	项目管理与集成	协助搭建开发 / 测试环境，编写启动与部署脚本
WBS-6.3	Alpha 集成与部署	完成 Alpha 阶段的服务部署与基本运维配置
T-2/T-4	后端支持	协助处理线上接口问题、日志记录与异常监控
T-13	功能测试	从运行环境角度检查日志、错误堆栈与异常处理是否合理

一、需求分析与原型优化

在前期完成选题确认与《需求规格说明书》初稿编写的基础上，通过课堂展示与集体讨论，我们收集到师生提出的多项具体改进建议。本次团队作业3将围绕这些问题展开需求细化与原型优化工作。

1.1 课堂反馈问题及解决方案

问题1：商品状态管理机制不健全，审核流程缺失
实际运营中，商品信息发布后需经管理员审核方能展示，当前系统的status字段虽存在但缺乏明确的审核流程规范。

改进方案1：完善商品状态管理与审核机制
在需求规格说明书中新增"商品状态管理"章节：

商品状态划分为三个类别：
- 待审核（status=0）：用户提交后的初始状态
- 已发布（status=1）：管理员审核通过后的状态
- 已下架（status=2）：过期或违规商品状态
  在原型设计中相应调整：
用户发布商品后自动跳转至"等待审核"提示界面
管理员后台增设"待审核商品"列表及审核操作界面
建立自动下架机制：基于expire字段自动将过期商品状态调整为已下架

问题2：商品分类体系缺失，信息组织效率低
当前系统仅支持供应/需求两种类型，实际交易中商品种类繁多，需要更精细的分类管理。

改进方案2：构建商品分类体系
在需求规格说明书中新增"商品分类"章节：

商品按以下大类进行划分：
- 书籍文具（教材、小说、文具等）
- 其他类别
  在原型设计中相应调整：
发布页面增加"商品分类"下拉选择功能
首页增设分类筛选导航栏
商品列表支持按分类展示

问题3：搜索功能过于简单，影响用户体验
当前搜索功能仅通过URL参数传递，缺乏实际搜索实现，且缺少搜索建议和历史记录功能。

改进方案3：优化搜索功能与用户体验
在需求规格说明书中新增"搜索功能"章节：

搜索功能包含以下特性：
- 关键词搜索：支持标题、描述等字段的模糊匹配
- 高级筛选：支持按分类、地区、价格区间等多维度筛选
- 搜索建议：输入关键词时实时提供热门搜索建议
- 搜索历史：自动记录用户最近搜索关键词
  在原型设计中相应调整：
首页和顶部导航栏设置醒目的搜索框
搜索结果页面增加筛选条件面板
搜索框下拉显示热门搜索和搜索历史记录

问题4：用户身份验证缺失，信息真实性难以保障
当前系统允许任何人发布信息，缺乏用户身份验证机制，容易产生虚假信息。

改进方案4：建立用户系统与身份验证机制
在需求规格说明书中新增"用户系统"章节：

用户分为三个层级：
- 普通用户：具备浏览、搜索商品权限
- 认证用户：通过手机号验证后可发布商品信息
- 管理员：负责商品管理、用户管理和系统设置
  在原型设计中相应调整：
增加用户注册/登录页面
发布商品前需完成登录和手机号验证
商品信息页面显示发布者昵称和认证标识

问题5：商品有效期提醒机制缺失
商品虽有expire字段表示有效期，但缺乏到期提醒功能，用户可能错过最佳交易时机。

改进方案5：建立有效期提醒机制
在需求规格说明书中新增"提醒机制"章节：

提醒类型包括：
- 到期前提醒：商品到期前1天发送提醒
- 到期提醒：商品到期时通知用户
- 成交提醒：有用户联系时及时通知
实现方式：
- 系统定时任务检查即将到期商品
- 通过站内信、邮件或短信发送提醒
- 用户可在个人中心设置提醒偏好

问题6：移动端适配不足，响应式设计欠缺
虽然采用Semantic UI框架，但页面布局和交互在移动设备上的体验仍需优化。

改进方案6：完善响应式设计与移动端体验
在需求规格说明书中新增"移动端适配"章节：

适配要求：
- 支持主流移动设备屏幕尺寸
- 简化移动端操作流程
- 优化触摸交互体验
- 提升移动端页面加载速度
  在原型设计中相应调整：
商品列表采用卡片式布局，适配不同屏幕尺寸
发布表单优化为移动端友好的输入方式
导航栏在小屏幕下转换为汉堡菜单
按钮和链接尺寸适合手指点击操作

1.2 需求规格说明书修订要点

基于团队作业2发布的《需求规格说明书》初稿，我们识别了若干关键不足，并进行了系统性修订。

（1）用户角色与权限定义模糊
原有问题：
对用户群体的描述较为笼统，仅简单划分为"核心用户、重要用户、辅助用户"，未明确不同用户角色的具体权限和功能差异。
优化措施：
重新定义用户角色体系：

普通用户（访客）：可浏览商品信息、搜索商品、查看分类，但无法发布商品或联系卖家
注册用户：完成手机号验证后可发布商品信息、联系其他用户、管理个人商品
认证用户：通过学号/工号认证的用户，享有更高的信誉度标识
管理员：负责审核商品信息、管理用户账户、维护系统正常运行
在数据库设计中增加用户表，包含字段：user_id、username、phone、email、role、is_verified、created_at等。

（2）商品状态管理流程不完整
原有问题：
初稿中未详细描述商品从发布到下架的完整生命周期管理流程。
优化措施：
在需求中新增"商品状态管理流程"：

商品状态分为四个类别：
- 待审核（pending）：用户发布后的默认状态
- 已发布（published）：管理员审核通过后的状态
- 已交易（sold）：买卖双方确认交易完成后的状态
- 已下架（expired/removed）：过期或违规商品状态
增加状态转换规则：
- 普通用户仅能发布待审核状态的商品
- 管理员可将待审核商品转为已发布或拒绝发布
- 用户可主动下架个人商品
- 系统根据expire字段自动将过期商品转为已下架状态

（3）搜索与筛选功能描述不充分
原有问题：
对搜索功能的描述较为简略，未能体现实际使用场景中的复杂需求。
优化措施：
完善搜索与筛选功能需求：

基础搜索功能：
- 关键词搜索：支持在标题、描述中进行搜索
- 分类筛选：按商品大类、子类进行筛选
- 类型筛选：供应/需求类型筛选
高级筛选功能：
- 地区筛选：按发布者所在地区筛选
- 时间筛选：按发布时间范围筛选
- 价格区间：按商品价格区间筛选（针对供应商品）
- 状态筛选：仅显示有效商品
搜索优化功能：
- 搜索建议：输入时提供热门关键词建议
- 搜索历史：记录用户最近搜索记录
- 模糊匹配：支持错别字识别和同义词匹配

（4）业务规则描述不完整
原有问题：
缺乏对核心业务规则的详细描述，可能导致开发过程中出现理解偏差。
优化措施：
在"业务规则"章节补充以下内容：

发布规则：
- 同一用户每小时最多发布5件商品
- 商品标题长度限制为5-50个字符
- 商品描述长度限制为10-500个字符
- 必须选择商品类型（供应/需求）和有效期限
审核规则：
- 管理员需在24小时内完成新发布商品的审核
- 包含违禁词的商品直接拒绝
- 重复发布相同内容的商品标记为垃圾信息
交互规则：
- 仅注册用户可联系商品发布者
- 同一用户对同一商品每天最多联系3次
- 用户可举报违规商品，累计3次举报需管理员介入处理
有效期规则：
- 商品默认有效期为7天，可选择1天、3天、7天
- 系统每天定时清理过期商品
- 过期前1天发送提醒通知

（5）用户场景串联功能（User Story）

用户场景（学生卖家）：计算机专业大四学生小王处理教材
小王即将毕业，需要处理一套专业教材。以往他只能在宿舍群发布消息，效果有限且可能打扰他人。
现在他使用"二手商品交易平台"：

使用学生账号登录系统，进入发布页面
选择"供应"类型，填写商品详细信息：
- 标题："计算机网络教材一套"
- 分类：书籍文具 > 教材
- 描述："计算机网络自顶向下方法第7版，附带习题解答"
- 价格：¥150
- 所在地：计算机学院
- 有效期：7天
提交后进入管理员审核流程（页面显示"审核中"状态）
审核通过后，商品在"教材"分类下正常展示
有买家联系时，及时收到系统通知
交易完成后，手动将商品状态更新为"已交易"

用户场景（学生买家）：研究生小李寻找实验教程
小李需要特定电子元件完成研究项目：

在首页搜索框输入"电阻电容相关的教程"
系统显示相关商品列表，支持按价格、时间排序
筛选"需求类型"为"供应"，地区选择"本校"
浏览商品详情，通过系统内置通信功能联系卖家
确认交易意向，双方线下完成交易
在个人中心将商品标记为"已购买"

每日工作流程：

上午9点登录管理后台
查看待审核商品列表，检查商品信息合规性
对包含违禁内容的商品执行"拒绝"操作并说明原因
对合规商品执行"通过"操作，使其对所有用户可见
处理用户举报信息，处置违规商品
统计昨日平台数据：新增商品数、活跃用户数、交易数
基于统计数据调整运营策略

三、需求规格说明书核心内容

用户群体分析

核心用户：在校本科生（占比75%）- 主要进行教材、电子设备教程交易
重要用户：研究生群体（占比20%）- 专业书籍、实验指导交易需求较多
辅助用户：教职工及校园商户（占比5%）- 偶尔处理闲置书籍或寻找特定书目

功能性需求

用户管理系统（P0）：注册、登录、身份认证、信息管理
商品信息管理（P0）：发布、编辑、删除、状态管理
智能搜索与筛选（P0）：关键词搜索、多维度筛选、排序
沟通联系功能（P0）：内置聊天系统、联系方式交换
审核管理功能（P0）：商品审核、违规处理、内容监管
统计分析功能（P1）：数据统计、用户行为分析、报表生成
推荐系统（P2）：个性化推荐、热门商品展示

非功能性需求

性能需求：页面响应时间控制在2秒以内，支持200并发用户
可用性需求：系统可用性保证99%，故障恢复时间不超过30分钟
安全性需求：用户隐私保护、数据传输加密、防刷机制
兼容性需求：支持主流浏览器和移动设备访问

四、项目特色优势
相比其他二手交易平台，本平台的差异化特点体现在：

校园专属特性：仅面向本校师生，确保交易安全性和便利性
教育公益属性：重点关注教材、学习用品等教育相关商品流通
信用体系建设：基于校园身份认证建立可信交易环境
本地化服务：支持面对面交易，降低物流成本和风险
学术资源整合：可与学校图书馆、实验室等资源对接，提供增值服务

1.3 功能优先级矩阵分析

基于功能对用户价值的重要性和当前迭代的紧急程度，我们采用四象限法进行功能优先级划分：

1.3 功能优先级矩阵分析

基于功能对用户价值的重要性和当前迭代的紧急程度，我们采用四象限法进行功能优先级划分：

1.3.1 第一象限：重要且紧急（P0，Alpha阶段必须完成）

用户发布二手商品信息（标题、类型、联系方式等）
商品信息列表展示与分类筛选
商品详情查看（含基本信息、联系人信息、发布时间等）
后台管理员审核商品信息（通过/拒绝）
管理员管理商品分类
用户查看已发布商品状态
商品信息过期处理机制

1.3.2 第二象限：重要但不紧急（P1，Beta阶段优先）

商品搜索功能（按关键词、类型等搜索）
商品信息编辑与更新
用户反馈与举报机制
管理员公告发布（系统通知、使用规范等）
商品浏览量统计

1.3.3 第三象限：不重要不紧急（P2，根据时间安排）

UI细节优化（主题、动画等）
商品图片上传与展示
导出商品信息报表
用户使用指南与帮助文档

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

用户评价与信用体系
商品收藏与关注功能
站内消息系统
数据分析与可视化展示（热门商品类型统计等）

在产品Backlog中，我们仅从P0象限选取Alpha阶段的功能，确保核心功能优先完成，为后续功能迭代奠定坚实基础。

1.4 基于修订需求的WBS与项目进度调整

1.4.1 修订后关键需求总结（仅列出影响后续计划的内容）

增加商品分类管理的实际业务规则（出售/求购）
用户端功能增强：
- 商品详情页（位置、联系方式、过期时间等）
- 商品发布表单验证
- 商品状态管理（有效/过期）
管理员端功能增强：
- 商品信息审核机制
- 简单的商品统计功能
通知模块完善：
- 商品发布成功通知
- 商品状态变更通知

这些调整将直接影响后端业务逻辑、数据库结构、前端界面设计和测试范围，因此需要重新制定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 后端开发（Django + MySQL）

WBS-3.1 商品模块
- 商品信息CRUD
- 商品分类管理
- 商品状态管理（发布/审核/过期）
WBS-3.2 用户交互模块
- 商品发布表单
- 联系信息发布者
WBS-3.3 管理员后台模块
- 商品信息审核
- 简单统计数据接口
WBS-3.4 通知模块
- 消息提示基础封装
- 商品状态变更提示

WBS-4 前端开发（Web）

WBS-4.1 公共布局和路由
WBS-4.2 商品列表 & 详情页
WBS-4.3 商品发布页
WBS-4.4 管理员后台页面（商品管理、审核）

WBS-5 数据库与测试

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

WBS-6 项目管理与集成

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

1.4.3 项目周进度计划对齐（16天迭代周期）

结合团队作业的整体规划，将16天的迭代周期划分为四个阶段：

第1-4天：需求分析与系统设计阶段

完成需求规格说明书修订（WBS-1.2）
完成系统架构设计和ER图定稿（WBS-2）
完善数据库逻辑结构设计（WBS-2.3）
搭建Django项目骨架、数据库连接

第5-8天：核心功能开发阶段

实现商品模块基础接口（WBS-3.1）
建立数据库表结构 & 初始化测试数据（WBS-5.1）
开发商品发布表单和验证逻辑（WBS-3.2）
实现管理员审核机制（WBS-3.3）

第9-12天：前后端联调阶段

完成主要前端页面开发（WBS-4）
实现商品列表 & 详情页展示（WBS-4.2）
完成管理员后台页面（WBS-4.4）
实现通知模块基础功能（WBS-3.4）

第13-16天：测试与完善阶段

进行单元测试和接口测试（WBS-5.2~5.3）
进行场景/功能测试（WBS-5.4）
缺陷修复与优化
编写测试报告与项目总结（WBS-5.5）

基于现有代码分析，项目已具备基本的商品发布和展示功能，后续重点需要完善：

管理员审核机制
商品状态管理
更完善的表单验证
商品分类筛选功能
过期商品处理逻辑

二、系统架构设计

2.1 总体架构概述

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

表示层（Presentation Layer)

技术选型：HTML / CSS / JavaScript（后续可引入Vue）
运行环境：浏览器
主要职责：页面展示、交互处理、调用后端REST API

业务逻辑层（Business Layer）

技术选型：Django（Python）+ RESTful API
核心模块：商品模块、用户交互模块、管理员模块、通知模块、统计模块
主要职责：实现业务规则（包括商品发布规则、审核规则、状态管理等），封装业务接口

数据访问层（Data Access Layer）

技术选型：MySQL + Django ORM
主要职责：数据持久化，负责表结构定义、查询与事务控制

2.2 模块划分与接口规范

（1）商品模块

功能要点：
- 商品信息增删改查
- 商品分类管理（出售/求购）
- 商品状态管理（发布/审核/过期）
- 过期时间管理
典型接口：
- GET /api/products
- GET /api/products/
- POST /api/products
- PUT /api/admin/products/

（2）用户交互模块

功能要点：
- 商品发布表单
- 联系信息发布者
- 商品搜索与筛选
典型接口：
- POST /api/products
- GET /api/products?category=...&type=...

（3）管理员模块

功能要点：
- 商品信息审核
- 商品状态变更
- 简单统计数据查看
典型接口：
- PUT /api/admin/products/{id}/approve
- PUT /api/admin/products/{id}/reject
- GET /api/admin/statistics

（4）通知模块

功能要点：
- 封装通用消息提示功能
- 在商品发布成功、状态变更时发送通知
实现方式：
- 后端在业务操作成功后调用通知模块
- 使用Django messages框架实现页面提示

（5）统计模块（Alpha精简版）

功能要点：
- 按商品类型统计发布数量
- 为管理员端提供数据展示
典型接口：
- GET /api/admin/statistics/product-count

2.3 数据库设计

2.3.1 核心实体与字段设计

注：下表仅列出核心字段

（1）用户表 auth_user（使用Django内置）

字段名	类型	说明
id	INT, 主键, 自增	用户ID
username	VARCHAR, 唯一	用户名
email	VARCHAR, 唯一	邮箱
password	VARCHAR	加密密码
is_staff	TINYINT(1)	是否为管理员
is_superuser	TINYINT(1)	是否为超级用户
date_joined	DATETIME	创建时间

（2）商品表 mask_product

字段名	类型	说明
id	INT, 主键, 自增	商品ID
title	VARCHAR(100)	商品标题
type	INT	商品类型（0:出售, 1:求购）
contact	VARCHAR(10)	联系人
location	VARCHAR(20)	位置信息
phone	VARCHAR(13)	联系电话
weixin	VARCHAR(50)	微信
status	TINYINT(1)	状态（0:待审核, 1:已发布）
timestamp	DATETIME	创建时间
expire	INT	过期天数
pv	INT	浏览量

（3）商品分类表（可选，当前通过type字段实现）

字段名	类型	说明
id	INT, 主键	分类ID
name	VARCHAR	分类名称
description	TEXT	分类描述

索引优化建议：

type字段普通索引 → 提高分类查询效率
status字段普通索引 → 提高状态筛选效率
(type, status, timestamp) 复合索引 → 提高列表页查询效率

2.3.2 现有系统分析与优化建议

基于当前代码分析，系统已具备基本的商品发布和展示功能。现有数据库结构基本满足需求，但可进行以下优化：

增加管理员操作日志表
- 记录商品审核等管理员操作
- 便于追踪和审计
增加商品浏览记录表
- 用于更详细的统计分析
- 支持热门商品推荐等功能
优化索引策略
- 根据实际查询需求调整索引
- 提高查询性能
增加商品图片字段
- 支持商品图片展示
- 提升用户体验

通过以上架构设计和数据库优化，系统能够更好地支持商品交易的核心功能，并为后续扩展提供良好的基础。

三、Alpha阶段任务分配方案

3.1 Product Backlog中Alpha功能筛选

3.1.1 Product Backlog功能列表（精选）

编号	功能模块	功能描述	优先级
PB-1	商品信息发布	用户可发布供应/需求商品信息	P0
PB-2	商品信息展示	用户可浏览商品列表和详情	P0
PB-3	商品分类筛选	支持按供应/需求类型筛选商品	P0
PB-4	管理员审核机制	管理员审核用户发布的商品信息	P0
PB-5	商品状态管理	商品具有完整状态生命周期	P0
PB-6	分页功能	商品列表分页展示	P0
PB-7	频率限制	防止恶意发布的频率控制	P0
PB-8	用户注册/登录	建立用户身份体系	P1
PB-9	商品搜索功能	支持关键词搜索商品	P1
PB-10	商品有效期提醒	商品到期前发送提醒	P1

3.1.2 Alpha阶段核心功能（MVP）
综合考虑优先级、依赖关系和团队资源，以下P0功能纳入Alpha开发范围：

PB-1 商品信息发布
PB-2 商品信息展示
PB-3 商品分类筛选
PB-4 管理员审核机制
PB-5 商品状态管理
PB-6 分页功能
PB-7 频率限制

PB-8（用户注册/登录）、PB-9（搜索）、PB-10（提醒）暂定为Beta阶段实现。

3.2 Sprint Backlog：任务分解与分配

本Sprint仅覆盖Alpha核心功能，所有任务预估工时控制在1-10小时范围内。

3.2.1 任务明细表

任务ID	功能模块	任务内容	负责人	预估工时
T-1	PB-1	商品信息表单设计与验证完善	成员A	4h
T-2	PB-1	商品发布后端接口实现	成员B	5h
T-3	PB-1	商品发布前端页面优化	成员C	6h
T-4	PB-2	商品列表展示逻辑优化	成员D	4h
T-5	PB-2	商品详情页展示完善	成员E	5h
T-6	PB-3	商品分类筛选功能实现	成员B	4h
T-7	PB-4	管理员审核界面完善	成员D	5h
T-8	PB-4	商品状态变更接口实现	成员A	4h
T-9	PB-5	商品状态管理逻辑完善	成员F	4h
T-10	PB-6	分页展示功能优化	成员G	4h
T-11	PB-7	频率限制机制完善	成员B	3h
T-12	-	Alpha测试用例设计	成员G	5h
T-13	-	功能测试与缺陷记录	全体	6h
T-14	-	项目文档与团队作业整理	成员G	4h

任务说明：

所有任务工时均在1-10小时范围内，符合任务要求
基于现有代码基础，重点完善核心功能模块
测试工作贯穿整个开发周期，非最后集中进行

3.3 Alpha冲刺进度规划

假设Alpha冲刺周期为2周（14天），第1周侧重功能完善，第2周侧重测试优化。

3.3.1 周视图任务安排

时间段	主要任务	涉及任务ID	负责人
第1周第1-2天	商品信息发布功能完善	T-1, T-2, T-3	成员A、B、C
第1周第3-4天	商品展示与详情页优化	T-4, T-5	成员D、E
第1周第5-6天	分类筛选与状态管理	T-6, T-9	成员B、F
第1周第7天	管理员审核功能完善	T-7, T-8	成员D、A
第2周第8-9天	分页与频率限制优化	T-10, T-11	成员G、B
第2周第10-11天	测试用例编写与功能测试	T-12, T-13	成员G、全体
第2周第12-13天	缺陷修复与系统优化	T-1~T-11相关修复	全体
第2周第14天	文档整理与博客撰写	T-14	成员G

3.3.2 甘特图示意

第1周:
第1-2天: [T-1,T-2,T-3] 商品信息发布功能完善
第3-4天: [T-4,T-5] 商品展示与详情页优化
第5-6天: [T-6,T-9] 分类筛选与状态管理
第7天:   [T-7,T-8] 管理员审核功能完善

第2周:
第8-9天: [T-10,T-11] 分页与频率限制优化
第10-11天:[T-12,T-13] 测试用例编写与功能测试
第12-13天:[缺陷修复] 系统优化与问题修复
第14天:  [T-14] 文档整理与博客撰写

四、质量保障计划

说明：本测试计划基于项目实际架构与功能设计制定，旨在指导Alpha冲刺阶段的质量保障活动，确保核心业务流程稳定可靠，为后续迭代奠定质量基础。

4.1 产品概述与测试目标

产品名称
二手书交易平台（Second-hand Book Trading Platform）

系统定位
面向高校师生的线上二手书交易服务平台，提供以下核心功能：

用户发布商品信息（出售/求购）
商品信息浏览与查询
联系信息发布者
商品状态管理与审核
管理员后台商品审核与管理

测试总体目标

验证核心流程完整性：确保「浏览商品→发布商品→联系卖家→管理员审核」主干流程在Alpha阶段正常运行
提前识别关键缺陷：在开发过程中同步开展测试，尽早发现逻辑错误、接口异常、权限漏洞等问题
建立可复用测试资产：形成标准化测试用例模板、接口测试脚本、缺陷跟踪机制，为后续阶段提供基础
提升团队质量意识：推行"开发即测试"理念，实现开发测试协同推进

4.2 测试范围与测试类型

4.2.1 测试范围

模块	包含状态	测试重点
商品模块	✅	商品发布、列表展示、详情页、分类筛选
用户交互模块	✅	发布表单、联系卖家、商品搜索
管理员模块	✅	商品审核、状态变更、数据统计
通知模块	✅	页面提示信息（发布成功/审核结果）
数据库交互	✅	核心数据操作的持久化正确性
前后端接口	✅	RESTful API参数校验、返回格式

❌ 排除范围（Beta阶段重点）：

多浏览器深度兼容性测试
高并发性能压力测试
安全渗透测试（SQL注入、XSS、CSRF等）
移动端响应式体验深度测试

4.2.2 测试类型

测试类型	工具/方法	测试目标
功能测试（黑盒）	手动执行测试用例	验证功能点符合需求规格
接口测试	Postman / requests	检查API请求响应、参数合法性、错误处理
UI与易用性测试	浏览器手动操作	表单提示、按钮状态、页面跳转合理性
回归测试	自动化脚本+手动验证	确保缺陷修复不影响现有功能
探索式测试	自由操作探索	发现边界情况和隐藏缺陷

4.3 测试策略与方法

4.3.1 总体策略（5W1H分析）

维度	策略内容
测试目的	保证核心交易流程可演示使用，降低后期返工成本
测试内容	核心功能正确性、接口稳定性、权限控制、数据一致性
测试时机	功能开发完成后立即测试，贯穿整个迭代周期
测试人员	测试负责人主导，开发者自测配合，全员参与
测试环境	开发/测试服务器（Django + MySQL测试库）
测试方法	黑盒为主，辅以接口测试与轻量白盒分析

4.3.2 测试方法详述

1. 黑盒测试

等价类划分：商品类型（出售/求购）、状态（待审核/已发布）
边界值分析：文本字段长度限制、数字范围
场景法：基于典型用户故事设计测试用例

2. 接口测试（重点）

针对核心接口进行测试：
GET /api/products/ # 获取商品列表
GET /api/products// # 获取商品详情
POST /api/products/ # 发布商品
PUT /api/admin/products// # 修改商品状态

使用Postman构建测试集合，验证不同参数组合
检查错误码返回（400, 401, 403, 404, 500）
验证认证机制有效性
确认返回JSON格式规范性

3. 白盒/灰盒测试（轻量）

关键逻辑添加日志输出
结合数据库查询验证数据正确性
复杂业务逻辑的单元测试辅助验证

4. 探索式测试

快速切换、重复提交等异常操作
非标准输入测试（特殊字符、超长文本等）
越权访问尝试

4.4 测试阶段与时间安排

结合两周Alpha冲刺周期，测试活动分为四个阶段：

阶段	时间节点	主要活动
准备阶段	第0天	需求文档研读、测试环境搭建、测试用例模板编写
早期冒烟测试	第1-3天	商品列表展示、发布表单等基础功能验证，严重问题反馈
核心联调测试	第4-7天	商品发布、审核流程、状态管理等核心流程测试
收尾与总结	第8-9天	回归测试、兼容性检查、测试报告编写

✅ 每阶段结束时更新测试计划，动态调整测试重点

4.5 测试团队分工

角色	主要职责
测试负责人	测试计划与用例编写、评审组织、缺陷跟踪、报告输出
前端开发者	页面交互测试、UI与易用性测试配合
后端开发者	接口测试实现、API功能验证、单元测试
全体成员	探索式测试参与、改进建议提出、代码质量维护

💡 采用"开发兼任测试 + 专人主测"模式，平衡工作负荷与责任明确

4.6 测试环境与资源准备

** 4.6.1 硬件环境**

测试设备：8GB RAM以上PC或笔记本
网络环境：局域网连接，支持访问测试服务器

4.6.2 软件环境

类别	版本/工具
后端环境	Django 2.1 + Python 3.6+ + MySQL 5.7
前端环境	Chrome / Edge 浏览器
测试工具	Postman、浏览器DevTools、缺陷跟踪工具
数据库	MySQL测试实例（独立环境）

4.6.3 测试数据准备

测试账号：普通用户、管理员各1个
初始化数据：至少5个商品（出售/求购各若干）
数据导入：使用管理命令或fixtures导入测试数据

4.7 风险识别与应对措施

潜在风险	应对策略
开发延期导致测试时间不足	提前介入、每日冒烟测试、核心流程优先
需求理解不一致	需求澄清会议、关键业务规则确认、测试用例及时更新
环境差异导致部署失败	明确环境配置、使用统一初始化脚本
接口变更频繁	接口文档实时更新、测试集合同步调整

4.8 测试准入与完成标准

准入条件（测试启动前提）

对应功能模块开发完成并在测试环境部署
提供最新接口文档与数据库结构说明
关键依赖服务（数据库等）可用
测试账号准备就绪

完成标准（Alpha阶段）

所有P0/P1级别缺陷已修复并通过回归验证
中低级别缺陷数量可控，已记录至后续迭代
≥90%计划测试用例已执行
输出《Alpha测试报告》，包含缺陷统计与改进建议

附录：测试用例示例（部分）

用例编号	测试场景	预期结果
TC001	用户访问商品列表页	成功显示商品列表，包含基本信息
TC002	用户发布出售商品	表单验证通过，商品成功提交待审核
TC003	用户发布求购商品	表单验证通过，商品成功提交待审核
TC004	管理员审核通过商品	商品状态更新为已发布，页面提示成功
TC005	管理员拒绝商品发布	商品状态更新为拒绝，页面提示成功
TC006	用户查看商品详情	正确显示商品详细信息
TC007	搜索特定类型商品	返回符合条件的商品列表

📌 建议：将测试计划保存为Markdown格式，纳入项目文档库

✅ 总结：本测试计划紧密结合项目技术特点，强调"早期测试、快速反馈、持续验证"，确保Alpha阶段核心功能稳定可靠，为项目后续发展奠定坚实基础。

posted on 2025-11-20 15:57 yzx567 阅读(10) 评论(0) 收藏举报