团队作业3——需求改进&系统设计
| 这个作业属于哪个课程 | 计科22级34班 |
|---|---|
| 这个作业要求在哪里 | 作业要求 |
| 这个作业的目标 | 根据团队作业2《需求规格说明书》和老师的建议改进项目需求，并对系统进行初步设计 |
前言
本篇博客是团队作业的第三篇，在上一篇博客需求规格说明书中我们展示了对项目的初步理解与分析。经过老师的点评与建议后，我们认识到了目前需求规格说明书中的不足之处，并进行了改进。同时，我们对整个项目的系统进行了初步的设计。
团队简介
-
队名
拖延是你不队
-
队员学号
| 姓名 | 班级 | 学号 |
|---|---|---|
| 艾彬（组长） | 计科4班 | 3122004730 |
| 陆宇星 | 计科4班 | 3122004491 |
| 范圣林 | 计科4班 | 3122004735 |
| 王佳伟 | 计科3班 | 3122004880 |
| 郑玮源 | 计科4班 | 3122004760 |
需求&原型改进
问题改进
经过上课老师的建议和组内讨论后，对项目设计中存在问题进行修改
问题一：“流浪动物领养网站”是否真的需要“领养”功能？
修改一：删去管理员的“决定动物领养归属”这一功能，改为鼓励用户在评论区上传该流浪动物的近况
需求规格说明书的改进
对于需求的分析并没有问题，但是对应设计的功能欠缺考虑
我们团队项目的初衷是提供一个流浪动物的信息平台，帮助爱动物人士更好地自发改善流浪动物的生活。从这个角度来看，“管理员决定动物的领养归属”这一功能是不必要的，原因有三：1.流浪动物可以被多个爱动物人士照养，不需要将“主人”的头衔交给某个用户；2.决定权在管理员，管理员决定领养归属的依据不足，难以选择；3.用户群大多是学生，学生的住宿条件并不适合领养动物
针对这一点，改为鼓励用户在评论区上传自己观察到的流浪动物近况，目的是帮助关心此流浪动物的用户了解其近况（如：健康状态，活动区域……）
功能需求的4个象限
参考《构建之法》5节功能的定位和优先级，给出功能分析的四个象限
①必须做且重要（Must-haves）：
用户发布和浏览流浪动物帖子：提供用户友好的界面，使用户可以方便地发布和浏览流浪动物帖子。确保帖子包括必要的详细描述、动物的大致定位。
帖子管理与审核： 为了保证帖子的内容符合网站的目标，引入管理员审核机制，管理员对用户发布的帖子进行审核，此时帖子仅对管理员和发布用户可见，只有审核通过其他用户才可浏览该帖子。
登录：管理员的账号密码是提前写好的，通过特定的账号可以登录管理员，并执行审核功能。
②必须做但不重要（Nice-to-haves）：
评论板块： 为每篇帖子创建一个专门的板块，供用户评论。为其他关心该流浪动物的用户提供最新的信息。
定位信息： 引入地图定位功能，编写帖子的用户可以上传流浪动物的位置信息，为其他用户提供流动物位置信息的可视化。
③不必做但重要（Not-so-importants）：
优化用户体验： 确保网站的用户界面简洁直观。考虑到用户体验的因素，例如加载、响应等设计，以提高用户使用体验。
④不必做且不重要（Won't-haves）：
非关键性功能： 避免投入过多资源在一些不是核心业务的功能上，优先考虑满足核心业务需求。
调整任务分解WBS及相应的项目进度计划
根据修改后的需求，进行任务的拆解和计划的调整
| 第9周 | 1.团队组队、团队博客 |
|---|---|
| 2.团队介绍、成员展示、角色分配、选题确定 | |
| 3.制定团队计划安排，团队贡献分的规定 | |
| 第 10 周 | 1.需求规格说明书 |
| 2.原型设计，队员估计任务难度并学习必要的技术 | |
| 3. 平台环境搭建完成、初步架构搭建 | |
| 第 11 周 | 1.编码规范完成 |
| 2.原型改进（给目标用户展现原型，并进一步理解需求） | |
| 3.架构设计，WBS, 团队成员估计各自任务所需时间 | |
| 4.测试计划 | |
| 第 12、13 周 | 1.团队项目Alpha任务分配计划 |
| 2.连续7天的Alpha敏捷冲刺，7 篇 每日Scrum Meeting博客+代码提交 | |
| 第 14 周 | 1.用户反馈+测试计划改进 |
| 2.团队Alpha阶段个人总结 | |
| 3.团队项目Alpha博客：发布说明、测试报告、展示博客、项目管理 | |
| 第 15 周 | 1.团队项目Alpha博客：事后分析 |
系统设计
系统设计由后台开发的同学完成
架构设计
- 项目为前后端分离模式，前端主要采用Vue3框架，后台主要采用springboot进行项目开发，数据使用mysql进行存储，前后端之间通过restful api进行交互
- 后端在收到请求后，先对请求进行预处理，校验用户的登录态、验证接口权限，通过验证后，由接口层负责读取数据加载到参数之中，传递给负责具体逻辑的服务层，服务层对传来的参数进行相应的逻辑处理，再通过调用数据库层的sql请求，完成数据的增删改查
- 模块主要分为用户模块和帖子模块
- 用户模块主要是用户登录注册以及个人信息修改相关的功能，在用户登录后，将通过token作为其登录凭证，参与到预处理流程中的用户登录态校验和权限校验(管理员相关的接口只能由管理员调用)中
- 帖子模版主要是用户的发帖功能，包含帖子的增删改，以及管理员对帖子的审核、主页随机推荐等功能，因为评论隶属于帖子，评论功能也放在这块里面
数据库设计
- 文字说明
- 表user：这个表存储用户信息，包括用户的id、名称、班级、手机号等个人信息
- 表post: 这个表存储帖子内容，包括帖子的标题、内容、发帖人、喂养状态以及定位
- 表comment: 这个表存储评论内容，包括评论人、评论内容以及评论的父评论id
- 表post_image: 这个表存储帖子相关的图片信息
Alpha任务分配计划
Product Backlog
Sprint1
甘特图
测试计划
一、引言
-
项目背景：我们团队决定做一个流浪动物领养网站，主要目的是为发现流浪动物或希望领养流浪动物的人提供交流的平台。用户可以发布流浪动物的信息帖子，也可以选择领养他人帖子中的流浪动物。本网站的出发点是关爱动物，流浪动物的生活普遍非常凄惨，我们希望能尽自己的一份力改善这一状况。
-
参考资料（计划编写依据：可行性分析报告／软件需求定义／软件概要设计／软件详细设计／用户使用说明书／……）
如何编写测试计划 -
测试术语：定义测试过程中使用的专业术语。
-
测试用例（Test Case）：描述了对软件特定功能或场景的测试步骤、预期结果和实际结果的文档或脚本。
-
缺陷（Defect）：在软件中发现的错误、问题或不符合规范的地方，需要被修复。
-
自动化测试（Automated Testing）：使用自动化测试工具和脚本来执行测试任务，提高测试效率和覆盖范围。
-
回归测试（Regression Testing）：在软件发生变更后，重新运行既有的测试用例，以确保修改不会引入新的问题。
-
白盒测试（White Box Testing）：测试人员有关软件内部结构和代码的详细信息，以编写测试用例和进行测试。
-
黑盒测试（Black Box Testing）：测试人员无需知道软件内部结构和代码的详细信息，只需根据需求规格进行测试。
-
集成测试（Integration Testing）：测试不同模块或组件之间的交互和集成，以验证它们一起工作的正确性。
-
端到端测试（End-to-End Testing）：测试软件从开始到结束的整个流程，以确保整个系统的功能和性能都符合要求。
-
用户验收测试（User Acceptance Testing）：由最终用户或客户执行的测试，以确认软件是否满足其预期需求。
-
性能测试（Performance Testing）：测试软件在不同负载条件下的性能表现，包括响应时间、吞吐量和并发用户数等。
-
-
有关项目人员组成以及联系方式：
- 后端开发人员以及版本控制人员：范圣林 、王佳伟
- 前端开发人员：陆宇星
- 测试人员：郑玮源
- 项目经理：艾彬
二、任务概述
-
测试范围：
- 功能测试：包括登录、注册、浏览帖子、发布帖子、修改个人信息、评论帖子、审核帖子等功能，包括输入、输出、处理和用户界面等方面的功能测试。
- 性能测试：测试网站的响应时间、吞吐量等性能指标。
- 兼容性测试：测试网站在不同浏览器、操作系统上的兼容性。
- 安全测试：测试网站的安全性，包括用户数据的保密性、完整性等。
-
测试目标：确保流浪动物网站在功能、性能、兼容性和安全性等方面满足用户需求和设计要求。
-
其他测试内容：
- 测试需求分析：分析软件需求，确定测试范围和测试重点。
- 测试用例编写：根据测试需求编写详细的测试用例。
- 测试环境搭建：搭建与生产环境相似的测试环境。
- 测试执行：按照测试计划执行测试用例，记录测试结果。
三、测试策略
-
测试人员：
- 测试负责人（郑玮源）：负责测试计划的制定、测试资源的协调和测试结果的评估。
-
测试方法：
- 白盒测试：对部分关键代码进行白盒测试，提高代码质量。
- 黑盒测试：以用户的角度进行黑盒测试，确保软件的功能和性能符合用户需求。
-
工具引用及测试培训：
- 工具引用：使用测试管理工具、自动化测试工具、性能测试工具等。
-
测试阶段计划：
① 进行各功能函数的白盒测试
人员：郑玮源
起止时间：开发全程②进行整体程序的白盒测试
人员：郑玮源
起止时间：基本开发完成至完全开发完成③进行整体程序的黑盒测试
人员：郑玮源
起止时间：基本开发完成至完全开发完成 -
测试停止及恢复条件：
- 测试停止条件：当所有测试用例执行完毕，缺陷修复率达到一定标准，性能指标满足要求时，测试可以停止。
- 测试恢复条件：当软件发生重大变更或发现严重缺陷时，需要重新进行测试。
-
测试文档及缺陷提交管理等：
- 测试文档：包括测试计划、测试用例、测试报告等，应按照规范进行编写和管理。
- 缺陷提交管理：使用缺陷管理工具对缺陷进行提交、跟踪和管理。
-
测试环境：
- 操作系统：win11
- 测试工具：IDEA 2020.1
四、测试资源
-
硬件资源需求
一台win10以上系统的个人电脑 -
软件资源需求
IDEA或者其他IDE -
测试环境需求
配置好Java环境，且下载好测试插件
五、风险评估
-
人力方面：人手充足，任务分配合理，风险较低
-
时间方面：计划中安排的时间均较为充裕，风险较低
-
环境方面：该项目对开发环境要求不高，风险较低
-
资源方面：该项目对软硬件设备要求不高，风险较低
-
部门合作方面：团队成员之间关系融洽，交流积极，风险较低
六、其他内容
-
测试计划制定者：郑玮源
-
日期：2024.11.3
-
修改记录：
- 2024.11.3 ：第一版编写
-
评审人员：
- 开发负责人：范圣林、陆宇星、王佳伟
- 测试负责人：郑玮源
- 项目经理：艾彬
