团队作业3--需求改进&系统设计
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/gdgy/CSGrade22-34/ |
|---|---|
| 作业要求 | 需求&原型改进、系统设计、Alpha任务分配计划、测试计划 |
| 团队项目仓库 | https://github.com/bitpurleclude/GDUT-Goofish/issues |
| 团队成员 | 李嘉锐 车峤锐 于海洋 林进光 黄健 钟启腾 钟月灿 |
一、需求&原型改进
1、对修改选题及需求进行修改
问题一 用户安全问题：二手交易存在欺诈风险。
修改一 可以通过引入实名认证、交易保障和举报系统来提高安全性。
问题二 商品质量和描述不一致。
修改二 提供详细的商品质量检查和用户反馈系统，让买家能够更真实地了解商品情况。
问题三 用户体验不佳：如果搜索、筛选功能不够完善，用户可能难以找到需要的商品。
修改三 可以优化搜索算法，提供个性化推荐和更清晰的界面设计。
问题四 售后支持不足：许多平台在交易完成后没有完善的售后服务，导致用户体验不佳。
修改四 可以增加售后支持选项，比如纠纷处理和退货政策。
向目标用户展示原型
Persona 1
名字：陈丽
年龄：35岁
收入：年收入15万人民币
市场占比和重要性：高端品牌的二手买家，较少但购买力强，影响力大。
典型使用场景：寻找低价的高端品牌包包
使用环境：手机应用为主，偶尔使用电脑查看大图
生活情况：单身，公司职员
知识层次和能力：本科以上学历，对电子商务熟悉
动机、目的和困难：希望便捷安全地购买二手奢侈品，担心假货问题
偏好：喜欢担保交易模式，有明确的质量认证标准
Persona 2
名字：张明
年龄：27岁
收入：年收入12万人民币
市场占比和重要性：普通卖家比例较大，交易量较高，活跃用户
典型使用场景：闲置电子设备快速出手
使用环境：手机应用
生活情况：自由职业者
知识层次和能力**：熟悉电子产品，电商交易经验丰富
动机、目的和困难：希望快速、安全地售出电子设备，减少与买家的沟通成本
偏好：喜欢订单管理简洁，物品发布流程简单
2、需求规格说明书改进
用户故事1
- 背景
典型用户：陈丽，35岁，公司职员
用户的需求/迫切需要解决的问题：陈丽希望在平台上以优惠的价格购买到一款轻微使用过的高端包包，但不想冒风险购买假货。
假设：平台提供可靠的验证和担保服务，让用户对购买二手物品的真实性和质量有信心。 - 场景
陈丽打开二手交易平台，查看轻微使用的高端包包列表。她浏览了多款包包的详细信息，包括图片、卖家信息和平台验证信息。她对一款价格合适的包包产生兴趣，平台的“质保认证”和“担保交易”功能让她感到放心。她点击购买后，选择担保交易模式并下单。买家支付完成后，卖家在3天内将物品寄出，陈丽在收到包包后进行验收，通过平台确认无误后，款项才会最终支付给卖家。这让她觉得这个流程非常安全和便捷。
亮点：
质保认证：平台提供高端物品的质保认证，帮助买家确认物品的真实性。
担保交易模式：让买家在验收商品前不用直接将款项支付给卖家，增强了交易安全性。
逻辑和界面设计注意事项：
- 初次使用者需要简洁的流程引导，尤其在“担保交易”上增加详细说明。
- 对于多次使用者，可提供快速交易入口，简化操作步骤。
- 其他资料
提供平台担保流程图，帮助用户理解交易流程的保障机制。
用户故事2
- 背景
典型用户：张明，27岁，自由职业者
用户的需求/迫切需要解决的问题：张明希望快速售出手头上一些闲置的电子设备，如平板电脑和耳机，但希望交易过程简单且无纠纷。
假设：平台提供简化的物品上传流程和退货/纠纷管理功能。 - 场景
张明进入平台后，选择“发布闲置物品”功能。他填写基本信息并上传图片，界面会提示他选择类别，填写详细的物品描述，并选择是否接受退货。由于他急于售出，因此勾选“不接受退货”选项。物品发布后，张明很快接到了数位买家的询问。他选择了一个出价合适的买家达成交易，并通过平台沟通完成交接。平台的订单系统帮助张明简化了交易记录和流程，他的订单状态变更为“待买家确认”，并在买家确认后完成交易。
亮点：
简易的物品发布流程：简化上传物品的步骤，减少填写内容，使卖家能快速发布物品。
清晰的订单流程和状态跟踪：订单状态明了，有效减少纠纷产生。
逻辑和界面设计注意事项：
- 初次发布物品的用户需要引导上传流程并附上示例图。
- 多次发布物品的用户可简化为一页式操作，减少不必要的填空项。
- 其他资料
订单状态追踪图，展示从“物品上传”到“交易完成”的各个状态。
3、功能分析四象限
第一象限：重要且紧急
必须优先开发的关键功能，直接影响用户体验和平台基本运作。
1.用户注册和登录：确保用户能够顺利注册和登录是平台的入口功能，属于核心模块。
商品发布与管理：作为二手交易平台的核心功能，必须保证卖家可以流畅地上架商品，并进行管理。
2.商品浏览与搜索：买家能否便捷地找到商品决定了平台的实用性，搜索、筛选和排序功能需保证高效。
3.即时聊天：提供买卖双方直接沟通渠道，是C2C模式的关键。
数据安全与隐私保护：加密和隐私设置是平台的安全保障，需在上线前完成。
第二象限：重要但不紧急
提高用户体验和留存的功能，开发时优先级稍低于基础功能。
1.用户评价系统：完善的评价系统能够帮助用户建立信任，但该功能可以在平台初期上线后逐步完善。
2.商品收藏与卖家关注：此功能提升用户留存和互动，虽然不是平台的基础功能，但能提高用户黏性。
3.个人资料管理：允许用户自行管理个人资料增强了平台的便利性，但不影响交易流程。
通知提醒：可提高即时聊天的响应率，提升用户体验，优先级略低于核心交易功能。
第三象限：紧急但不重要
短期内可提升平台体验的附加功能，但不具备关键影响。
1.订单管理：展示交易记录和收藏、关注内容，这类信息的管理对提升用户体验有帮助。
第四象限：不重要且不紧急
对平台运作影响较小，可后期考虑。
1.高级统计分析功能（管理后台）: 平台初期可以通过简单的数据报表进行基础管理，复杂的数据分析可后期优化。
2.更多的隐私设置：基础隐私设置可满足用户需求，更多个性化设置可在平台稳定后逐步添加。
4、任务分解WBS及相应的项目进度计划
4.1WBS图
4.2项目 WBS 优先级和时间表
1. 需求分析
任务 1.1：用户需求分析
o优先级：高
o预计时间：1周
o任务分配：业务分析师
o说明：Alpha 阶段的初步核心任务，帮助理解买家和卖家的核心需求。
任务 1.2：需求规格说明书撰写和评审
o优先级：高
o预计时间：1周
o任务分配：需求分析团队
o说明：在Alpha阶段需要完成，以确保后续开发任务明确。
2. 设计阶段
任务 2.1：数据库设计
o优先级：高
o预计时间：1周
o任务分配：数据库工程师
o说明：Alpha阶段核心任务，需确保数据库能够支持用户、商品、订单等功能。
任务 2.2：后端系统架构设计
o优先级：高
o预计时间：1周
o任务分配：后端开发团队
o说明：确保架构能够支持用户、商品管理、即时沟通等核心功能。
任务 2.3：前端界面设计
o优先级：高
o预计时间：2周
o任务分配：UI/UX设计师
o说明：设计直观、友好的界面，满足用户需求。
3. 功能模块开发
任务 3.1：用户模块开发
o任务 3.1.1：注册与登录功能
优先级：高
预计时间：2周
任务分配：后端开发团队
说明：Alpha阶段核心任务，确保用户能够顺利注册和登录平台。
o任务 3.1.2：个人中心功能
优先级：中
预计时间：1周
任务分配：前后端开发团队
说明：包括查看订单、修改个人信息等，提供基础的用户管理。
任务 3.2：商品管理模块开发
o任务 3.2.1：商品上架与管理功能
优先级：高
预计时间：2周
任务分配：前后端开发团队
说明：Alpha阶段核心任务，确保卖家可以上传商品，买家可浏览商品。
o任务 3.2.2：图片上传功能
优先级：高
预计时间：1周
任务分配：前端开发团队
说明：确保商品有良好的图片展示功能。
任务 3.3：交易模块开发
o任务 3.3.1：即时沟通功能
优先级：高
预计时间：2周
任务分配：后端开发团队
说明：Alpha阶段核心任务，支持买卖双方的沟通，促进交易达成。
o任务 3.3.2：订单管理功能
优先级：高
预计时间：1周
任务分配：后端开发团队
说明：买家和卖家可以查看和管理订单状态，Alpha阶段必备功能。
任务 3.4：支付系统初步集成
o优先级：中
o预计时间：2周
o任务分配：后端开发团队
o说明：支持交易支付，为 Alpha 阶段后的 Beta 版本做准备。
4. 系统测试与验证
任务 4.1：单元测试
o优先级：高
o预计时间：1周
o任务分配：测试团队
o说明：确保核心模块的功能稳定，是 Alpha 阶段的必要任务。
任务 4.2：集成测试
o优先级：高
o预计时间：1周
o任务分配：测试团队
o说明：确保模块之间的无缝集成，属于 Alpha 阶段的必要任务。
5. 上线准备
任务 5.1：部署环境搭建
o优先级：中
o预计时间：1周
o任务分配：运维团队
o说明：为正式上线打基础，是 Beta 阶段准备工作。
任务 5.2：数据库备份与恢复设置
o优先级：中
o预计时间：1周
o任务分配：运维团队
o说明：Alpha阶段后开始设置，保障数据安全。
任务 5.3：系统监控与告警配置
o优先级：中
o预计时间：1周
o任务分配：运维团队
o说明：Beta版本准备工作。
二、系统设计
1、系统架构设计概述
为了满足二手交易平台的功能需求和非功能需求，采用分层架构设计有助于提高系统的可维护性、可扩展性和可复用性。基于所使用的技术栈（前端：Vue，Element-UI，Axios；后端：Spring Boot，MySQL，MyBatis，HttpClient（微信支付），OSS）。
2、分层结构设计
分层架构 (Layered Architecture)
该模式将应用划分为多个独立层次（如表现层、业务逻辑层、数据访问层等），每一层都只与相邻的上下层进行交互。适合中小型项目，且对系统的可维护性和清晰度有很大帮助。
优点：
(1)清晰的模块分层，便于功能划分和职责分配。
(2)易于测试，且各层次可以独立开发和调试。
(3)在不同层次上实现功能后，可以平行扩展各个层次的功能。
3、系统整体分为以下四个层次：表示层（Presentation Layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data Access Layer）、持久层（Persistence Layer）。
3.1 表示层（Presentation Layer）
职责：
- 提供用户交互界面，包括网页和移动端界面。
- 处理用户输入，展示后台传递的数据。
- 实现前端的业务逻辑，如表单验证、页面路由等。
技术栈： - Vue.js：构建用户界面。
- Element-UI：提供UI组件库，提升开发效率。
- Axios：用于与后端进行HTTP通信。
接口： - 与业务逻辑层的API接口进行交互，通常是RESTful风格的HTTP接口。
3.2.业务逻辑层（Business Logic Layer）
职责：
- 处理核心业务逻辑，如用户注册登录、商品发布、交易沟通等。
- 实现系统的业务规则和流程控制。
- 对请求进行验证和权限控制。
技术栈： - Spring Boot：构建后端应用，提供RESTful API。
- MyBatis：用于对象关系映射，简化数据库操作。
接口： - 向表示层提供API接口。
- 调用数据访问层的方法获取或更新数据。
3.3.数据访问层（Data Access Layer）
职责：
- 负责与数据库的交互，对数据库进行CRUD操作。
- 将业务逻辑层的请求转换为数据库查询。
- 对数据库操作进行封装，提供统一的接口。
技术栈： - MyBatis：用于映射SQL语句和对象关系。
接口： - 接受业务逻辑层的调用，执行数据库操作。
- 返回数据给业务逻辑层。
3.4.持久层（Persistence Layer）
职责：
- 实际存储数据的地方，包括关系型数据库和文件存储等。
- 保存用户数据、商品信息、交易记录等。
技术栈： - MySQL：关系型数据库，存储结构化数据。
- OSS（对象存储服务）：用于存储图片、文件等非结构化数据。
接口： - 被数据访问层调用，执行具体的数据库和文件存储操作。
4、层次之间的接口定义
表示层 ↔ 业务逻辑层：
- 使用HTTP/HTTPS协议，通过RESTful API进行通信。
- 接口文档可使用Swagger等工具生成，定义请求路径、方法、参数和返回值。
业务逻辑层 ↔ 数据访问层：
- 通过方法调用，传递参数对象。
- 接口定义在Service和DAO（Data Access Object）层，明确输入输出。
数据访问层 ↔ 持久层：
- 使用MyBatis映射XML或注解方式，将方法映射到SQL语句。
- 对象与数据库表的映射关系明确。
5、开发人员分工
前端开发人员（表示层）：
- 负责页面设计、交互实现、接口调用。
- 使用Vue.js、Element-UI构建用户界面。
后端开发人员（业务逻辑层、数据访问层）：
- 负责业务逻辑的实现、API接口的开发。
- 编写Service层和Controller层代码。
- 使用Spring Boot、MyBatis等技术。
数据库管理员（持久层）：
- 设计数据库结构，创建表和索引。
- 优化数据库性能，管理数据存储。
全栈开发人员（可覆盖多个层次）：
- 在需要时，参与多个层次的开发，确保整体功能的实现和优化。
6、数据库设计
6.1数据库设计原则
- 规范化：消除数据冗余，避免数据不一致。
- 扩展性：易于添加新功能或扩展现有功能。
- 性能：考虑查询效率，适当建立索引。
6.2主要实体和属性
用户表（User）
| 字段名 | 数据类型 | 描述 |
|---|---|---|
| user_id | INT | 用户ID，主键 |
| username | VARCHAR | 用户名/昵称 |
| password | VARCHAR | 密码 |
| VARCHAR | 邮箱 | |
| phone | VARCHAR | 手机号 |
| avatar | VARCHAR | 头像URL |
| create_time | DATETIME | 注册时间 |
| last_login | DATETIME | 最后登录时间 |
| user_role | INT | 用户角色（0-普通用户，1-管理员） |
| status | INT | 用户状态（0-正常，1-禁用） |
商品表（Product）
| 字段名 | 数据类型 | 描述 |
|---|---|---|
| product_id | INT | 商品ID，主键 |
| user_id | INT | 发布者用户ID |
| name | VARCHAR | 商品名称 |
| category_id | INT | 商品类别ID |
| description | TEXT | 商品描述 |
| price | DECIMAL | 商品价格 |
| status | INT | 商品状态（0-上架，1-下架，2-已售） |
| create_time | DATETIME | 创建时间 |
| update_time | DATETIME | 更新时间 |
商品图片表（Product_Image）
| 字段名 | 数据类型 | 描述 |
|---|---|---|
| image_id | INT | 图片ID，主键 |
| product_id | INT | 商品ID，外键 |
| image_url | VARCHAR | 图片URL |
| create_time | DATETIME | 上传时间 |
类别表（Category）
| 字段名 | 数据类型 | 描述 |
|---|---|---|
| category_id | INT | 类别ID，主键 |
| category_name | VARCHAR | 类别名称 |
| parent_id | INT | 父类别ID |
聊天消息表（Message）
| 字段名 | 数据类型 | 描述 |
|---|---|---|
| message_id | INT | 消息ID，主键 |
| sender_id | INT | 发送者用户ID |
| receiver_id | INT | 接收者用户ID |
| content | TEXT | 消息内容 |
| send_time | DATETIME | 发送时间 |
| is_read | INT | 是否已读（0-未读，1-已读） |
评价表（Review）
| 字段名 | 数据类型 | 描述 |
|---|---|---|
| review_id | INT | 评价ID，主键 |
| reviewer_id | INT | 评价者用户ID |
| reviewed_user_id | INT | 被评价的用户ID |
| rating | INT | 评分（1-5星） |
| content | TEXT | 评价内容 |
| create_time | DATETIME | 评价时间 |
收藏表（Favorite）
| 字段名 | 数据类型 | 描述 |
|---|---|---|
| favorite_id | INT | 收藏ID，主键 |
| user_id | INT | 用户ID |
| product_id | INT | 商品ID |
| create_time | DATETIME | 收藏时间 |
关注表（Follow）
| 字段名 | 数据类型 | 描述 |
|---|---|---|
| follow_id | INT | 关注ID，主键 |
| follower_id | INT | 关注者用户ID |
| followed_user_id | INT | 被关注的用户ID |
| create_time | DATETIME | 关注时间 |
订单表（Order）
| 字段名 | 数据类型 | 描述 |
|---|---|---|
| order_id | INT | 订单ID，主键 |
| buyer_id | INT | 买家用户ID |
| seller_id | INT | 卖家用户ID |
| product_id | INT | 商品ID |
| order_status | INT | 订单状态（0-待支付，1-已支付，2-已完成，3-已取消） |
| create_time | DATETIME | 下单时间 |
| update_time | DATETIME | 更新时间 |
管理员操作日志表（Admin_Log）
| 字段名 | 数据类型 | 描述 |
| -------------- | ----------- | --------------- |
| log_id | INT | 日志ID，主键 |
| admin_id | INT | 管理员用户ID |
| operation | VARCHAR | 操作内容 |
| target_id | INT | 操作对象ID |
| create_time | DATETIME | 操作时间 |
6.3实体关系描述
- 用户（User）和商品（Product）：一对多关系。一个用户可以发布多个商品。
- 商品（Product）和商品图片（Product_Image）：一对多关系。一个商品可以有多张图片。
- 用户（User）和聊天消息（Message）：一对多关系。用户作为发送者和接收者，与消息存在关联。
- 用户（User）和评价（Review）：一对多关系。一个用户可以给多个用户评价，也可以收到多个评价。
- 用户（User）和收藏（Favorite）：一对多关系。一个用户可以收藏多个商品。
- 用户（User）和关注（Follow）：一对多关系。一个用户可以关注多个用户。
- 订单（Order）与用户（User）和商品（Product）：订单关联买家、卖家和商品。
- 管理员（User，user_role=1）和操作日志（Admin_Log）：一对多关系。
6.4ER图描述
由于无法在文本中直接绘制ER图，以下对ER图进行文字描述。
-
User表
- 主键：user_id
- 与Product表：一对多关系（user_id）
- 与Message表：一对多关系（sender_id，receiver_id）
- 与Review表：一对多关系（reviewer_id，reviewed_user_id）
- 与Favorite表：一对多关系（user_id）
- 与Follow表：一对多关系（follower_id，followed_user_id）
- 与Order表：一对多关系（buyer_id，seller_id）
- 与Admin_Log表（当user_role=1时）：一对多关系（admin_id）
-
Product表
- 主键：product_id
- 外键：user_id（关联User表）
- 与Product_Image表：一对多关系（product_id）
- 与Favorite表：一对多关系（product_id）
- 与Order表：一对一关系（product_id）
- 外键：category_id（关联Category表）
-
Product_Image表
- 主键：image_id
- 外键：product_id（关联Product表）
-
Category表
- 主键：category_id
- 自关联：parent_id（父类别）
-
Message表
- 主键：message_id
- 外键：sender_id、receiver_id（关联User表）
-
Review表
- 主键：review_id
- 外键：reviewer_id、reviewed_user_id（关联User表）
-
Favorite表
- 主键：favorite_id
- 外键：user_id（关联User表）
- 外键：product_id（关联Product表）
-
Follow表
- 主键：follow_id
- 外键：follower_id、followed_user_id（关联User表）
-
Order表
- 主键：order_id
- 外键：buyer_id、seller_id（关联User表）
- 外键：product_id（关联Product表）
-
Admin_Log表
- 主键：log_id
- 外键：admin_id（关联User表，当user_role=1时）
6.5数据库设计示意
plaintext
[User] 1 —— [Product]
[User] 1 —— [Message] —— 1 [User]
[User] 1 —— [Review] —— 1 [User]
[User] 1 —— [Favorite] —— 1 [Product]
[User] 1 —— [Follow] —— 1 [User]
[Product] 1 —— [Product_Image]
[Product] 1 —— 1 [Order]
[Product] —— 1 [Category]
[User] 1 —— [Order]
6.6注意事项
- 索引设计：对经常用于查询的字段，如
user_id、product_id、category_id等建立索引，提高查询性能。 - 数据安全：对敏感信息，如密码，使用加密方式存储。
- 字段规范：字段命名遵循统一的命名规范，便于维护。
7、总结
通过上述系统架构设计和数据库设计，明确了系统的分层结构、各层的职责和接口，以及数据库的实体和关系。这有助于开发人员理解系统的整体架构，明确各自的开发任务，提高开发效率。
- 前端开发人员专注于表示层的开发，负责用户界面和交互。
- 后端开发人员负责业务逻辑层和数据访问层，处理核心业务和数据操作。
- 数据库管理员确保数据库结构合理，高效可靠。
三、Alpha任务分配计划
Product Backlog
该项目的目标是创建一个用户友好的在线平台，让用户能够轻松地买卖二手商品，同时确保交易的安全性和透明度，Product Backlog如下：
1.用户模块
1.1 用户注册和登录
1.1.1 需求：用户希望能够创建账户并登录，以便能够买卖商品。
1.1.2 功能：用户可以注册、登录、找回忘记的密码以及管理个人信息。
1.2 用户个人资料管理
1.2.1 需求：用户希望能够编辑个人资料，包括头像、联系方式和交易偏好。
1.2.2 功能：用户可以上传头像、编辑联系信息、设置交易偏好。
2.商品模块
2.1 发布商品
2.1.1 需求：用户希望能够发布要出售的商品，包括图片、描述和价格。
2.1.2 功能：用户可以上传商品图片、填写商品描述、设置商品价格。
2.2 搜索商品
2.2.1 需求：用户希望能够搜索商品，根据类别、价格、地区等条件。
2.2.2 功能：用户可以通过关键词搜索商品、可以筛选搜索结果，可以按价格、新旧程度排序。
- 交易模块
3.1 购买商品
3.1.1 需求：用户希望能够购买商品，并通过安全的支付方式完成交易。
3.1.2 功能：用户可以将商品添加到购物车并完成购买，可以通过第三方支付平台完成支付。
3.2 订单管理
3.2.1 需求：用户希望能够查看和管理我的订单状态。
3.2.2 功能：用户可以查看订单详情、可以取消未发货的订单。
4.反馈模块
4.1用户评价系统
4.1.1 需求：用户希望能够评价商品，以建立信任和提高安全性。
4.1.2 功能：用户可以对交易进行评价，可以是星级评分和文字评论。
4.2交易争议解决
4.2.1 需求：用户希望能够解决交易中的争议，并获得平台的支持。
4.2.2 功能：用户可以报告交易问题，平台提供争议解决流程。
5、选取待实现功能项
依据项目组能提供的总时间、功能模块的优先级以及模块之间的依赖关系，在Product Backlog中选取待实现的功能项，如下表：
| 功能项 | 时间 | 优先级 |
|---|---|---|
| 用户功能模块 | 一周 | 高 |
| 商品功能模块 | 一周 | 高 |
| 交易功能模块 | 一周 | 高 |
| 反馈功能模块 | 一周 | 中 |
Sprint Backlog
| 功能项 | 具体功能 | 功能分解 | 时间/h | 功能总耗时 |
|---|---|---|---|---|
| 用户功能模块 | 注册和登录 | 设计用户注册和登录界面 | 1 | |
| 创建用户数据库模型 | 0.5 | |||
| 编写注册和登录逻辑 | 2 | |||
| 个人资料管理 | 设计个人资料编辑页面 | 1 | ||
| 头像上传功能实现 | 2 | |||
| 编写用户数据更新逻辑 | 2 | 9 | ||
| 商品模块 | 发布商品 | 设计发布商品页面 | 1 | |
| 创建商品数据库模型 | 0.5 | |||
| 实现图片上传功能 | 1 | |||
| 编写发布商品逻辑 | 1 | |||
| 搜索商品 | 设计商品展示页面 | 1 | ||
| 设计前端搜索条件组件 | 1 | |||
| 编写商品搜索逻辑 | 2 | 7.5 | ||
| 交易模块 | 购买商品 | 设计购物车页面 | 2 | |
| 创建购物车、订单数据库模型 | 1 | |||
| 编写购物车状态变更逻辑 | 2 | |||
| 集成第三方平台支付 | 2 | |||
| 编写支付逻辑 | 1 | |||
| 订单管理 | 设计订单展示页面 | 1 | ||
| 编写订单状态变更逻辑 | 1 | 10 | ||
| 反馈模块 | 评价系统 | 设计商品评价展示页面 | 1 | |
| 创建评价数据库模型 | 0.5 | |||
| 编写评价产生逻辑 | 1 | |||
| 争议解决 | 设计订单投诉页面 | 1 | ||
| 创建冲突订单数据库模型 | 1 | |||
| 编写争议订单处理逻辑 | 2 | |||
| 设计管理端处理争议订单的页面 | 2 | 7.5 | ||
| 34 |
Alpha 阶段的核心任务汇总
核心任务 预计完成时间
需求分析（任务 1.1 和 1.2） 第1周
数据库设计（任务 2.1） 第2周
后端系统架构设计（任务 2.2） 第2周
前端界面设计（任务 2.3） 第2-3周
用户注册与登录（任务 3.1.1） 第4-5周
商品上架与管理（任务 3.2.1） 第5-6周
图片上传功能（任务 3.2.2） 第6周
即时沟通功能（任务 3.3.1） 第7-8周
订单管理（任务 3.3.2） 第8周
单元测试（任务 4.1） 第9周
集成测试（任务 4.2） 第10周
时间安排总览
1.第1-2周：需求分析和数据库、架构设计
2.第3-6周：用户、商品、沟通等核心模块开发
3.第7-8周：即时沟通、订单管理开发
4.第9-10周：系统测试与集成
甘特图：
四、测试计划
1、测试策略概述
目标：通过系统化的测试，发现并修复平台的功能性、性能和安全性问题，确保高质量的用户体验和稳定的系统性能。
测试类型：
1.功能测试：验证每个功能模块是否按照需求正常工作。
2.安全性测试：保障用户数据的安全和平台的隐私保护措施。
3.用户体验测试：收集用户反馈，优化界面交互和流程设计。
4.性能测试：测试系统的响应速度、负载承受能力，确保在高并发情况下的稳定性。
2、测试内容
2.1功能测试
用户注册和登录：验证注册和登录流程，找回密码功能的可用性。
商品发布与管理：确保商品发布、编辑、上架、下架等操作正确执行。
商品浏览与搜索：验证商品搜索、筛选、排序的准确性。
即时聊天：测试聊天消息的发送和接收功能，确保及时通知到达。
用户评价系统：验证买家评价、评分展示的准确性。
收藏和关注：测试商品收藏和卖家关注的功能，确保信息的正确保存和展示。
个人中心和数据管理：验证订单管理、个人信息修改、隐私设置等功能。
管理后台：测试管理员的用户、商品管理和统计分析功能。
2.2安全性测试
数据加密：验证用户信息和密码的加密存储。
权限控制：检查用户隐私设置和后台权限管理，确保没有未授权访问。
防止攻击：进行SQL注入、XSS攻击、CSRF攻击的模拟测试，确保系统抗攻击能力。
2.3用户体验测试
界面测试：验证页面布局、按钮、文本等设计的用户友好性。
交互流程：观察用户在注册、发布商品、聊天等核心流程的操作，确保流畅性。
2.4性能测试
加载速度测试：验证页面加载时间和资源加载速度，尤其是商品搜索结果和图片。
并发测试：模拟高并发访问，尤其是即时聊天、商品发布和搜索功能，确保系统承载能力。
数据库性能：测试高频数据库操作，检查查询、插入、更新的速度，保证数据访问效率。
3、测试流程
测试计划制定：根据项目进度制定详细的测试计划，包括每个模块的测试时间、目标、内容等。
单元测试：由开发团队编写并执行单元测试，确保各个模块的基本功能实现。
集成测试：对多个模块的集成功能进行测试，确保各个功能模块能够正确协作。
系统测试：全面测试所有功能模块，验证平台的完整性和业务逻辑的正确性。
用户体验测试：邀请部分真实用户或内部团队使用产品，收集反馈以优化界面和操作流程。
回归测试：在发现并修复问题后，进行回归测试确保修复未引入新问题。
验收测试：在系统上线前进行最后的验收测试，确认所有核心功能按预期工作。
性能与压力测试：使用自动化测试工具模拟高并发场景，测试系统的负载能力和稳定性。
4、工具与环境
测试工：可使用Postman、JMeter等工具进行API、性能等测试。
测试环境：搭建与生产环境相似的测试环境，包括数据库和服务器配置，确保测试结果的准确性。
5、测试报告与反馈
报告生成：每轮测试结束后生成测试报告，包括测试的成功率、失败的用例、性能数据等。
问题跟踪：使用Bug管理系统（如JIRA）记录、跟踪和分配问题。
反馈与改进：基于测试结果，安排修复、优化和重新测试，确保在下个版本中提高产品的质量和稳定性。
