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

一、需求&原型改进

（一）需求修改

问题	修改
问题 1： 平台信息透明度不足，用户对回收价格、处理流程、环保价值缺乏了解，信任度低？	修改 1：新增 “信息透明” 专属板块，展示回收价格标准、回收物处理流程、环保成果；首页增设公益活动宣传轮播图 / 固定板块，展示环保公益活动详情与参与方式，增强用户信任与品牌认同感。
问题 2：订单管理仅提及基础操作，缺乏操作约束、进度跟踪及隐私保护设计，用户体验不佳？	修改 2：明确订单操作规则，待上门订单需提前 1 小时取消、未分配回收员可修改地址 / 时间；预计上门时间跟踪功能；已完成订单支持查看 “回收品类 / 重量” 详情，同时保留星级评分 + 文字评价功能，兼顾透明度与隐私保护。

（二）需求规格书改进

新增核心功能模块：

• 信息透明与公益模块：价格标准、处理流程、环保成果展示，公益活动宣传与参与入口。
• 订单管理优化模块：明确订单操作约束规则，新增回收进度跟踪（实时位置、预计时间）、订单详情查看功能，完善评价体系。
• 细分场景下单模块：个人回收、高校旧教材回收、高校宿舍批量回收、企业批量 / 定期回收的差异化流程设计，补充选填功能（照片上传）与必填信息（发票信息、联系人）。

（三）场景参考（User Story）

李同学是某高校大四学生，毕业季宿舍堆积了大量旧教材、塑料瓶和闲置衣物，之前找回收商要么价格混乱，要么上门时间不固定，排队等半天。使用本小程序后，他打开 “高校专区”，选择 “毕业季批量预约”，勾选 “旧教材 + 宿舍废品”，填写宿舍楼号和期望回收时段（次日 14:00-16:00），提交后立即收到预约成功通知，显示当前该时段仅 3 人预约。同时，他通过 “价格公示” 查看旧教材回收价为 1.5 元 / 公斤，确认无异议后，在回收员上门时，通过小程序实时查看称重数据（教材 8 公斤、衣物 5 公斤），自动计算总价 20.5 元，直接到账余额。回收完成后，他在订单页给回收员评价，整个流程仅用 5 分钟，彻底解决了毕业季回收的繁琐问题。

（四）核心功能四象限分析：

**重要且紧急象限（Alpha阶段必选功能） **	重要不紧急象限（Beta阶段重点功能）
1. 微信一键登录（含用户类型选择）；2. 个人 / 高校 / 企业基础下单功能；3. 价格公示模块；4. 订单状态跟踪；5. 基础地址管理	1. 高校毕业季批量预约与时段分配算法；2. 企业定期回收计划管理与提醒；3. 回收重量实时上传与数据同步；4. 环保成果统计可视化（碳减排量、资源回收量图表）；5. 多端数据同步（小程序 + 回收员端 + 管理员端）
紧急不重要象限（Beta阶段可选功能）	不重要不紧急象限（后期迭代功能）
1. 积分兑换（回收金额可兑换环保周边）；2. 回收员评价与评分；3. 消息通知自定义（短信 / 小程序模板消息）；4. 回收品类知识库（如何分类、回收价值）	1. 回收路线智能规划（基于多订单地址优化）；2. 人脸识别确认回收（防止冒领）；3. 第三方支付接口集成（除余额外支持微信支付）；4. 多语言适配（针对外籍师生 / 企业用户）

(五）开发的任务分解以及项目进度计划

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 后端开发

• WBS-3.1 用户与身份模块：微信登录授权接口、用户身份信息存储接口、个人中心信息查询/更新接口
  WBS-3.2 地址管理模块：地址新增接口、地址列表查询接口、地址修改接口、地址删除接口
  WBS-3.3 垃圾分类模块：分类详情查询接口
  WBS-3.4 下单回收模块：个人订单创建接口、高校旧教材订单创建接口、高校宿舍批量订单创建接口、企业定期回收订单创建接口
  WBS-3.5 订单管理模块：订单列表查询接口、订单详情查询接口、订单信息修改接口、订单取消接口、订单复用（再来一单）接口
  WBS-3.6 价格管理模块：回收价格新增/修改接口、价格按用户类型查询接口等
  WBS-3.7 通知触发模块：订单状态变更提醒接口、企业定期计划到期提醒接口

WBS-4 前端开发（微信小程序）

• WBS-4.1 公共布局与路由
  WBS-4.2 登录 / 个人中心页面
  WBS-4.3 价格公示页面
  WBS-4.4 下单回收页面（个人 / 高校 / 企业）
  WBS-4.5 订单管理页面
  WBS-4.6 高校毕业季批量预约页面
  WBS-4.7 企业定期回收页面
  WBS-4.8 管理员后台页面（价格 / 时段管理）

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 阶段集成与部署

项目周次进度计划对齐
结合团队作业计划，第 12-15 周的核心任务安排如下：

第 12周：以设计完善、后端与数据库搭建为主

• 完成系统架构设计与数据库表结构的确定
• 搭建 Flask 项目骨架并完成数据库连接
• 初步实现用户模块的登录、身份信息收集接口
• 初始化数据库表结构与测试数据

第 13 周：推进前后端联调，完成核心功能基础

• 开发完成核心下单模块、地址管理模块的后端接口
• 实现对应模块的前端页面（价格公示页、下单回收页）
• 对已开发接口进行 Postman 接口测试

第 14 周：完善业务模块，补充通知逻辑

• 完成订单管理、高校毕业季专项模块的后端接口
• 开发对应模块的前端页面（订单管理页、高校批量预约页）
• 实现通知模块的订单提醒、定期计划提醒核心逻辑

第 15 周：收尾企业模块，完成集成测试与部署

• 开发企业定期回收模块的后端接口与前端页面
• 开展完整回收流程的场景 / 功能测试
• 修复测试中发现的缺陷，完成集成与部署
• 编写项目小结

二、系统设计

结合环保回收小程序的业务需求，参考场馆预约系统的设计框架，采用B/S 架构 + 前后端分离 + 分层设计的模式，从总体架构、模块划分、数据库设计三个核心维度完成系统设计，确保架构清晰、模块职责明确、数据存储合理。

2.1 总体架构概览

本系统采用B/S 架构 + 前后端分离 + 分层设计，主要划分为三层，适配微信小程序的运行特性与环保回收的业务场景：

表示层（Presentation Layer）
技术栈： UniApp
运行环境：微信客户端（小程序容器）。
职责：展示回收业务页面、处理用户交互（如下单、预约）、调用后端 REST API、封装请求 / 响应逻辑。

业务逻辑层（Business Layer）
技术栈：JAVA+Springboot+RESTful API。
职责：实现核心业务规则（价格计算、校园时段分配、订单状态流转等），封装业务接口，处理权限与身份校验。

数据访问层（Data Access Layer）
技术栈：MySQL + SQLAlchemy（或原生 SQL）。
职责：数据持久化，负责回收业务相关表结构定义、数据查询与事务控制（如订单创建、价格更新）。

2.2 模块划分与接口说明

结合环保回收小程序的核心业务，目前大致分为以下五个模块，以下是各个模块的功能定位与主要接口。

（1）用户与身份模块
功能定位：处理用户登录、信息查询与更新，匹配图片中 “个人中心接口” 需求。

请求方式	接口路径	接口说明
GET	/user/center/info	获取当前用户信息（含昵称、头像、身份类型、扩展信息等）
PUT	/user/center/info	更新用户信息（如修改昵称、补充高校 / 企业身份信息）

（2）地址管理模块
功能定位：处理用户地址的新增、删除、修改、默认设置
核心接口

请求方式	接口路径	接口说明
POST	/address/create	新增用户收货地址（需传入地址标签、详细地址、联系人、手机号等）
GET	/address/list	获取当前用户的所有收货地址列表（含默认地址标识、经纬度等）
PUT	/user/center/addresses	修改已有的收货地址（支持修改详细地址、联系人、手机号等）
DELETE	/user/center/addresses/	删除指定 ID 的收货地址（需校验地址归属，仅本人可删除）
POST	/address/default/	将指定 ID 的地址设为默认地址（自动取消原默认地址）

（3）垃圾分类模块
功能定位：提供回收品类的层级查询（一级 / 二级分类），匹配垃圾分类管理需求。
核心接口：

请求方式	接口路径	接口说明
GET	/category/top	获取所有一级回收分类（如 “塑料”“废纸”“旧教材”，仅展示启用状态）
GET	/category/{parentId}/sub	根据一级分类 ID（parentId）获取对应的二级分类（如 “塑料”→“塑料瓶”）
GET	/category/	根据分类 ID 获取分类详情（含分类名称、父级 ID、排序序号、启用状态）

（4）下单回收模块
功能定位：处理多类型订单创建，覆盖个人订单、校园订单接口，同时补充企业订单功能。
核心接口：

请求方式	接口路径	接口说明
POST	/order/personal	个人用户创建回收订单（需关联地址 ID、选择分类、填写预约时间、上传物品图片）
POST	/campus0rder/textbook	高校用户创建旧教材回收订单（需关联学校、宿舍楼、预约时段）
POST	/campus0rder/dormitory	高校用户创建宿舍批量回收订单（支持多品类批量提交，关联宿舍楼信息）
POST	/api/enterprise/regular	企业用户创建定期回收订单（设置回收周期、预约时间、预估重量）

（5）订单管理模块
功能定位：处理订单查询、修改、取消、“再来一单”，覆盖所有订单管理接口。
核心接口：

请求方式	接口路径	接口说明
GET	/order/list	获取当前用户的所有订单列表（默认展示所有状态，支持按状态筛选）
GET	/manage/order/manage/list	分页查询用户订单列表（支持按订单状态、创建时间范围筛选）
GET	/manage/order/detail/	获取指定订单的详情（含物品明细、地址信息、回收员信息、订单状态等）
PUT	/manage/order/modify/	修改订单信息（仅支持未分配回收员的订单，可修改预约时间、地址）
POST	/order/cancel/	取消指定订单（需校验订单状态，仅 “待上门” 状态可取消）
POST	/manage/order/repeat/	“再来一单” 功能（复用原订单的地址、分类信息，快速创建新订单）

2.3 数据库设计

实体与字段设计

（1）用户表（user）- 所有身份用户统一存储
核心设计：仅保留微信授权与身份共性字段，差异信息通过extended_info（JSON）存储，避免表结构冗余。

字段名	类型	说明	约束
id	bigint	用户唯一主键	AUTO_INCREMENT、PRIMARY KEY
openid	varchar(255)	微信授权唯一标识（用户在当前小程序 / 公众号的唯一 ID，登录核心）	UNIQUE、NOT NULL
unionid	varchar(255)	微信跨平台唯一标识（同一用户在微信生态不同产品的通用 ID，可选）	UNIQUE、DEFAULT NULL
nickname	varchar(100)	微信昵称（同步微信授权信息，无需用户手动填写）	DEFAULT NULL
avatar_url	varchar(500)	微信头像 URL（同步微信授权信息，支持直接访问）	DEFAULT NULL
identity_type	tinyint	身份类型（1 - 个人用户、2 - 高校用户、3 - 企业用户，区分身份的核心标识）	NOT NULL、DEFAULT 1
school_name	varchar(100)	高校用户共性字段（仅identity_type=2时填写，便于按学校筛选用户）	DEFAULT NULL
department	varchar(100)	高校用户共性字段（院系 / 部门，仅identity_type=2时填写）	DEFAULT NULL
extended_info	json	不同身份的差异信息（JSON 格式，存非共性字段，避免表膨胀）	DEFAULT NULL
created_at	datetime	注册时间（首次微信授权登录时间）	DEFAULT CURRENT_TIMESTAMP
last_login_at	datetime	最后登录时间（每次微信授权登录时更新）	DEFAULT NULL
is_active	boolean	账号状态（true = 正常，false = 禁用，软删除替代物理删除）	-

xtended_info JSON 示例：
个人用户：{"street_address": "北京市海淀区中关村大街1号"}
高校用户：{"role": "学生", "dormitory": "3号楼2单元101室"}
企业用户：{"company_name": "北京绿色回收科技有限公司", "credit_code": "91110108********XY"}

（2）地址表（user_address）- 支持多地址存储

核心设计：通过user_id关联用户，实现 “1 用户→N 地址”，字段贴合回收员上门定位场景。

字段名	类型	说明	约束
id	bigint	地址唯一主键	AUTO_INCREMENT、PRIMARY KEY
user_id	bigint	关联用户 ID（外键，确保地址归属）	NOT NULL、FOREIGN KEY REFERENCES user(id) ON DELETE CASCADE
address_label	varchar(50)	地址标签（区分多地址，如 “家”“公司”“学校”，用户可自定义）	NOT NULL
detail_address	text	详细地址（如 “XX 小区 3 号楼 2 单元 501 室”，便于回收员上门定位）	NOT NULL
contact_name	varchar(50)	联系人姓名（可能与用户昵称不同，如 “张三（家人代收）”）	NOT NULL
contact_phone	varchar(20)	联系人手机号（地址专属电话，避免依赖用户核心手机号）	NOT NULL
location	json	经纬度（JSON 格式：{"lat":39.9042,"lng":116.4074}，用于地图导航）	DEFAULT NULL
is_default	boolean	是否默认地址（用户可设 1 个默认地址，下单时自动选中，减少操作）	DEFAULT false
created_at	datetime	地址创建时间	DEFAULT CURRENT_TIMESTAMP
updated_at	datetime	地址修改时间（更新地址时自动更新，便于追踪变更记录）	-

（3）订单表（order）- 多类型订单统一存储

核心设计：用address_id关联地址表（替代 JSON 存完整地址），extended_order_info（JSON）存储订单差异信息，优化数据冗余

字段名	类型	说明	约束
id	bigint	订单唯一主键	AUTO_INCREMENT、PRIMARY KEY
order_no	varchar(50)	订单编号（如 “ORD20240916001”，唯一标识，便于用户查询）	UNIQUE、NOT NULL
user_id	bigint	关联用户 ID（外键，绑定下单用户）	NOT NULL、FOREIGN KEY REFERENCES user(id)
address_id	bigint	关联地址 ID（外键，复用地址表数据，避免重复存储地址）	NOT NULL、FOREIGN KEY REFERENCES user_address(id)
order_type	tinyint	订单类型（1 - 个人回收、2 - 旧教材回收、3 - 宿舍批量回收、4 - 企业批量回收、5 - 企业定期回收）	NOT NULL
status	tinyint	订单状态（1 - 待上门、2 - 回收中、3 - 已完成、4 - 已取消）	NOT NULL、DEFAULT 1
items	json	回收物品明细（JSON 数组，存品类、数量、单位，如塑料瓶 10 个）	NOT NULL
scheduled_time	datetime	预约回收时间（用户选择的上门时间，如 “2024-09-18 14:00:00”）	NOT NULL
images	json	物品图片 URL 列表（JSON 数组，用户上传的物品照片，用于回收员核验）	DEFAULT NULL
collector_id	bigint	关联回收员 ID（外键，分配回收任务后填写）	DEFAULT NULL、FOREIGN KEY REFERENCES collector(id)
extended_order_info	json	订单差异信息（JSON 格式，存不同类型订单的特有字段）	DEFAULT NULL
created_at	datetime	订单创建时间	-

JSON 示例：

- 个人回收订单（order_type=1）：
items：[{"category_id":2,"category_name":"塑料瓶","quantity":10,"unit":"个"},{"category_id":5,"category_name":"旧报纸","quantity":2,"unit":"公斤"}]
extended_order_info：{}
- 企业定期回收订单（order_type=5）：
items：[{"category_id":8,"category_name":"办公废纸","quantity":50,"unit":"公斤"}]
extended_order_info：{"invoice_info":{"title":"北京绿色回收科技有限公司","tax_number":"91110108********XY"},"plan_info":{"cycle":"每月","total_times":12,"next_time":"2024-10-18 10:00:00"}}

（4）分类表（category）- 回收品类管理

核心设计：支持二级分类（通过parent_id关联），控制分类展示顺序与启用状态。

字段名	类型	说明	约束
id	bigint	分类主键	AUTO_INCREMENT、PRIMARY KEY
name	varchar(50)	分类名称（如 “塑料”“废纸”“旧教材”）	NOT NULL
parent_id	bigint	父级分类 ID（用于二级分类，如 “塑料瓶” 的父级是 “塑料”，null= 一级分类）	DEFAULT NULL、FOREIGN KEY REFERENCES category(id)
sort	int	排序序号（控制分类展示顺序，数字越小越靠前）	DEFAULT 0
is_active	boolean	是否启用（true = 展示给用户，false = 隐藏）	DEFAULT true
created_at	datetime	分类创建时间	DEFAULT CURRENT_TIMESTAMP

（5）订单评价表（order_rating）- 用户对回收员的评价

核心设计：绑定订单与回收员，确保评价唯一性（1 个订单仅 1 条评价），支持评分与文字反馈。

字段名	类型	说明	约束
id	bigint	评价主键	AUTO_INCREMENT、PRIMARY KEY
order_id	bigint	关联订单 ID（外键，绑定评价对应的订单，唯一）	UNIQUE、NOT NULL、FOREIGN KEY REFERENCES order(id)
user_id	bigint	关联用户 ID（外键，绑定评价用户）	NOT NULL、FOREIGN KEY REFERENCES user(id)
collector_id	bigint	关联回收员 ID（外键，绑定被评价回收员）	NOT NULL、FOREIGN KEY REFERENCES collector(id)
rating	tinyint	评分（1-5 星，1 = 最差，5 = 最好）	NOT NULL、CHECK(rating BETWEEN 1 AND 5)
comment	text	文字评价（用户对回收员的具体评价，如 “服务态度好，上门准时”）	DEFAULT NULL
created_at	datetime	评价提交时间	DEFAULT CURRENT_TIMESTAMP

三、Alpha分配计划

假设 Alpha 冲刺周期为 4 周（28天）

（一）Product Backlog（Alpha 阶段待实现功能项）

模块	功能项	依赖关系
1. 用户模块	1.1 微信一键登录（含用户类型选择）	无
	1.1 微信一键登录（含用户类型选择
	1.2 身份信息收集（学校名称 / 企业信用代码）	1.1
	1.3 个人中心基础功能（余额 / 积分展示）	1.1、1.2
2. 核心下单模块	2.1 个人用户下单（品类选择 / 地址 / 时间预约）	无
	2.2 高校基础下单（旧教材回收 / 宿舍回收）	1.2
	2.3 企业基础下单（批量回收预估）	1.2
3. 价格公示模块	3.1 回收价格数据库设计	无
	3.2 价格展示页面开发	3.1
4. 订单管理模块	4.1 订单状态分类展示	2.1、2.2、2.3
	4.2 订单修改 / 取消功能	4.1
	4.3 重量明细与总价计算	2.1、2.2、2.3
5. 高校毕业季专项模块	5.1 批量预约功能	2.2
	5.2 回收时段分配	5.1
6. 企业定期回收模块	6.1 周期设置与提醒	2.3
	6.2 计划表导出	6.1
	6.3 环保成果统计	6.1

（二）Sprint Backlog（任务分解与认领）

开发人员：1：林欣然 2：周诗涵 3：周纯微 4：陈文婉 5：李思淇

功能项	子任务	预估时间	任务类型	认领人	依赖子任务
1.1 微信一键登录	1.1.1 前端微信授权组件开发	4 小时	前端	4	无
	1.1.2 前端用户类型选择弹窗开发	3 小时	前端	4	1.1.1
	1.1.3 后端微信登录接口开发（含用户类型存储）	5 小时	后端	1	无
	1.1.4 前后端联调与登录验证	2 小时	前后端	1、4	1.1.1、1.1.3
1.2 身份信息收集	1.2.1 前端差异化表单开发（高校 / 企业）	5 小时	前端	5	1.1.4
	1.2.2 后端信息校验与存储接口开发	4 小时	后端	2	1.1.3
	1.2.3 前后端联调	2 小时	前后端	5、2	1.2.1、1.2.2
1.3 个人中心基础功能	1.3.1 前端个人中心页面开发（余额 / 积分展示）	4 小时	前端	4	1.2.3
	1.3.2 后端用户余额 / 积分查询接口开发	3 小时	后端	3	1.2.2
	1.3.3 前后端联调	1 小时	前后端	4、3	1.3.1、1.3.2
3.1 回收价格数据库设计	3.1.1 价格表结构设计（按用户类型 / 品类）	4 小时	后端	1	无
	3.1.2 价格数据初始化	2 小时	后端	2	3.1.1
3.2 价格展示页面开发	3.2.1 前端价格展示页面开发	4 小时	前端	5	3.1.2
	3.2.2 后端价格查询接口开发	3 小时	后端	3	3.1.1
	3.2.3 前后端联调	1 小时	前后端	5、3	3.2.1、3.2.2
3.3 价格趋势查询功能	3.3.1 前端趋势图表组件开发	4 小时	前端	4、5	3.2.3
	3.3.2 后端趋势数据统计接口开发	3 小时	后端	1、2、3	3.1.1
	3.3.3 前后端联调	1 小时	前后端	1、4	3.3.1、3.3.2
2.1 个人用户下单	2.1.1 前端下单页面开发（品类 / 地址 / 时间）	6 小时	前端	4、5	无
	2.1.2 后端下单接口开发	5 小时	后端	1、2、3	3.1.1
	2.1.3 前后端联调	2 小时	前后端	2、5	2.1.1、2.1.2
2.2 高校基础下单	2.2.1 前端旧教材 / 宿舍回收下单页面开发	5 小时	前端	4、5	1.2.3
	2.2.2 后端高校下单接口开发	4 小时	后端	1、2、3	1.2.2、3.1.1
	2.2.3 前后端联调	2 小时	前后端	3、4	2.2.1、2.2.2
2.3 企业基础下单	2.3.1 前端企业批量回收下单页面开发	5 小时	前端	4、5	1.2.3
	2.3.2 后端企业下单接口开发	4 小时	后端	1、2、3	1.2.2、3.1.1
	2.3.3 前后端联调	2 小时	前后端	1、5	2.3.1、2.3.2
4.1 订单状态分类展示	4.1.1 前端订单列表页面开发（按状态分类）	5 小时	前端	4、5	2.1.3、2.2.3、2.3.3
	4.1.2 后端订单查询接口开发	4 小时	后端	4、5	2.1.2、2.2.2、2.3.2
	4.1.3 前后端联调	2 小时	前后端	1、5	4.1.1、4.1.2
4.2 订单修改 / 取消功能	4.2.1 前端修改 / 取消按钮开发与逻辑	3 小时	前端	4、5	4.1.3
	4.2.2 后端订单修改 / 取消接口开发	3 小时	后端	3	4.1.2
	4.2.3 前后端联调	1 小时	前后端	3、5	4.2.1、4.2.2
4.3 重量明细与总价计算	4.3.1 前端明细展示组件开发	3 小时	前端	4、5	4.1.3
	4.3.2 后端总价计算逻辑与接口开发	4 小时	后端	2	2.1.2、3.1.1
	4.3.3 前后端联调	1 小时	前后端	1、4	4.3.1、4.3.2
5.1 高校批量预约功能	5.1.1 前端批量预约页面开发	4 小时	前端	4、5	2.2.3
	5.1.2 后端批量预约接口开发	4 小时	后端	1、2、3	2.2.2
	5.1.3 前后端联调	2 小时	前后端	2、4	5.1.1、5.1.2
5.2 回收时段分配	5.2.1 前端时段选择组件开发	3 小时	前端	4、5	5.1.3
	5.2.2 后端时段分配算法与接口开发	5 小时	后端	3	5.1.2
	5.2.3 前后端联调	2 小时	前后端	3、4	5.2.1、5.2.2
6.1 周期设置与提醒	6.1.1 前端周期设置页面开发	4 小时	前端	4、5	2.3.3
	6.1.2 后端周期逻辑与提醒接口开发	5 小时	后端	1	2.3.2
	6.1.3 前后端联调	2 小时	前后端	1、4	6.1.1、6.1.2
6.2 计划表导出	6.2.1 前端导出按钮与逻辑开发	3 小时	前端	4、5	6.1.3
	6.2.2 后端 Excel 导出接口开发	4 小时	后端	2	6.1.2
	6.2.3 前后端联调	1 小时	前后端	2、5	6.2.1、6.2.2
6.3 环保成果统计（基础版）	6.3.1 前端统计展示页面开发	3 小时	前端	4、5	6.1.3
	6.3.2 后端统计数据接口开发	3 小时	后端	1、2、3	6.1.2
	6.3.3 前后端联调	1 小时	前后端	全员	6.3.1、6.3.2

（三）Alpha 阶段迭代冲刺甘特图

四、测试计划

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

（一）项目概述与基础

1.1 项目背景
环保回收小程序聚焦个人、高校、企业三大核心场景，解决环保回收行业场景适配不足、操作流程繁琐、信息不透明等痛点，提供便捷下单、精准匹配、透明追溯的回收服务。为保障小程序功能可用性、稳定性与用户体验，特制定本测试计划，指导全流程测试工作有序开展。

1.2 测试术语

• 黑盒测试：不关注系统内部实现，仅通过输入输出验证功能是否符合需求；
• 功能测试：验证系统功能是否满足需求规格说明书中的描述；
• 兼容性测试：验证小程序在不同微信版本、不同设备上的运行效果；
• 性能测试：测试系统响应速度、并发处理能力等性能指标；
• 缺陷：系统功能、性能等不符合需求或影响用户使用的问题；
• 回归测试：修复缺陷后，验证相关功能是否正常，未引入新问题。

1.3测试计划编写6要素？（5W1H）

why——为什么要进行这些测试；

what—测试哪些方面，不同阶段的工作内容；

when—测试不同阶段的起止时间；

where—相应文档，缺陷的存放位置，测试环境等；

who—项目有关人员组成，安排哪些测试人员进行测试

how—如何去做，使用哪些测试工具以及测试方法进行测试。

（二）任务概述

2.1 测试范围

（1）功能测试范围

• 用户模块：微信一键登录、用户身份信息收集与校验、个人中心数据展示；
• 价格公示模块：回收价格列表展示、价格趋势查询、不同用户类型价格过滤；
• 下单回收模块：个人 / 高校 / 企业下单流程、高校毕业季批量预约、企业批量回收预约；
• 订单管理模块：订单列表展示（按状态分类）、订单修改 / 取消、订单详情与明细展示；
• 高校毕业季专项模块：批量预约时段分配、回收点信息展示；
• 企业定期回收模块：定期计划创建、计划表导出、环保成果统计展示；
• 异常处理：订单取消规则执行、重量争议处理、发票申请异常处理。

（2）非功能测试范围

• 性能测试：页面加载时间（≤2 秒）、订单提交响应时间（≤1 秒）、支持同时在线用户≥500 人；
• 兼容性测试：主流微信版本（近 3 个版本）、不同机型（iOS/Android 各主流品牌）的适配；
• 安全性测试：用户 Token 校验、敏感信息加密存储、接口防非法调用、评价内容敏感词过滤；
• 易用性测试：核心操作（下单、查询）三步内完成，界面简洁直观，适配不同年龄段用户。

2.2 测试目标

• 1.验证小程序所有核心功能符合需求规格说明书，无严重缺陷；
• 2.确保系统性能满足要求，页面加载、订单提交等操作响应迅速；
• 3.保障小程序在不同环境、不同设备上稳定运行，兼容性良好；
• 4.提升用户体验，确保操作流程简洁，信息展示清晰；
• 5.发现并提交系统潜在缺陷，协助开发团队修复，降低上线风险；
• 6.出具完整测试报告，为项目上线提供决策依据。

2.3 测试核心工作内容

• 测试需求分析：梳理各模块测试要点，明确测试优先级；
• 测试用例设计：针对功能点设计覆盖正常场景、异常场景的测试用例；
• 测试环境搭建：配置小程序测试环境、数据库测试环境、接口调试工具；
• 测试执行：按计划执行功能测试、性能测试、兼容性测试等；
• 缺陷管理：提交缺陷报告，跟踪缺陷修复进度，组织回归测试；
• 测试总结：整理测试结果，出具测试报告，总结测试过程中的问题与经验。

（三）测试策略

3.1 测试人员需求及分工

测试人员	分工	负责模块
测试负责人（许潆之）	制定测试计划，设计核心模块测试用例，审核测试用例，组织缺陷评审，执行功能测试、兼容性测试	全模块
测试辅助人员（方馨）	辅助设计测试用例，辅助编写测试报告	用户模块、订单管理模块

3.2 测试方法

• 功能测试：以黑盒测试为主，模拟用户实际操作场景，验证功能正确性；关键流程（如下单、支付相关）补充场景测试，覆盖不同用户类型、不同操作路径；
• 性能测试：使用 JMeter 工具模拟多用户并发访问，测试系统响应时间与并发处理能力；通过微信开发者工具的性能面板，监测页面加载性能；
• 兼容性测试：手动在不同微信版本、不同机型上执行核心功能测试用例，验证展示效果与操作流畅度；
• 安全性测试：通过 Postman 工具模拟非法接口调用，验证 Token 校验有效性；检查敏感数据（手机号、企业信用代码）是否加密存储；
• 易用性测试：邀请内部人员模拟不同年龄段用户，体验核心操作流程，收集使用反馈。

3.3 测试阶段计划

测试阶段	工作内容	负责人	起止时间	交付物
测试准备阶段	制定测试计划，梳理测试需求，搭建测试环境	测试负责人	第 12 周第 1-3 天	测试计划、测试环境配置文档
测试用例设计阶段	设计各模块测试用例，审核测试用例	测试负责人、测试人员	第 12 周第 4 天 - 第 13 周	测试用例集
功能测试执行阶段	执行功能测试用例，提交缺陷，跟踪缺陷修复	全体测试人员	第 14 周第 1-5 天	测试执行报告、缺陷清单
非功能测试执行阶段	执行性能、兼容性、安全性、易用性测试	测试负责人、测试人员	第 14 周同步并行	非功能测试报告
回归测试阶段	针对修复的缺陷执行回归测试，验证功能稳定性	全体测试人员	第 15 周第 1-3 天	回归测试报告
测试总结阶段	整理测试结果，编写测试总结报告	测试负责人	第 15 周第 4-5 天	测试总结报告

3.4 测试停止及恢复条件

（1）测试停止条件
核心功能测试用例执行率 100%，严重缺陷修复率 100%，主要缺陷修复率≥95%，轻微缺陷修复率≥80%；
性能指标达到需求要求（页面加载≤2 秒，订单响应≤1 秒，并发用户≥500 人）；
兼容性测试无严重适配问题，不影响核心功能使用；
回归测试无新增严重缺陷，相关功能正常。

（2）测试恢复条件
缺陷修复完成，开发团队提交回归测试申请；
测试环境恢复稳定，无影响测试执行的环境问题；
需求变更或版本更新后，重新明确测试范围与测试用例，补充测试资源。

（四）测试环境

** 测试环境需求**

• 环境独立性：测试环境与开发环境、生产环境隔离，避免相互影响；
• 数据一致性：测试环境初始化数据与生产环境模拟数据一致，保障测试真实性；
• 环境稳定性：服务器持续运行，网络无频繁中断，数据库定期备份；
• 权限配置：测试人员拥有测试环境的查询、操作权限，开发人员拥有缺陷修复权限