所属课程 | 软件工程导论 |
---|---|
作业要求 | 团队作业3–需求改进&系统设计 |
作业目标 | 需求规格说明书改进、系统设计、Alpha任务分配计划、测试计划 |
github链接 | CampusSecond-handMarket–NoBailanGroup |
项目网址 | http://www.stopyc.shop/second/ |
目录一、团队1、团队名称:摆烂就不队2、团队成员二、需求&原型改进1.问题与改进2、修改完善需求规格说明书3、新增内容:4、功能分析的四个象限5、调整任务分解WBS及相应的项目进度计划三、系统设计1、目的2、背景3、系统业务架构图4、系统架构详细说明5、功能列表6、系统页面7、数据库设计(ER图)四、Alpha任务分配计划1、Product Backlog2、Sprint Backlog3、甘特图五、测试计划1.引言2.任务概述3.测试策略4.测试资源5.风险评估6.其他内容
一、团队
1、团队名称:摆烂就不队
2、团队成员
姓名 | 班级 | 学号 |
---|---|---|
林劲辰(组长) | 计科2班 | 3121004707 |
许庆阳 | 计科2班 | 3121004931 |
苏建澎 | 计科2班 | 3121005007 |
黎灿宇 | 计科2班 | 3121004867 |
伊尔凡江·艾合买提 | 计科2班 | 3121005017 |
鄞灿 | 计科2班 | 3121005018 |
于杨 | 计科2班 | 3221004940 |
二、需求&原型改进
1.问题与改进
针对课堂讨论环节老师和其他组的问题及建议,对修改选题及需求进行修改
问题一:如果面对大四毕业生,毕业之后不在学校又想出售二手商品,但是不在学校导致再二手交易的过程很麻烦,应该怎么解决?
修改一:在二手市场网站中增加托管机制,实现二手商品的寄售,但是要收取一定的托管费用,且增加仓库管理人员对二手商品进行管理。
问题二:二手商品在网站上交易成功后要怎么实现配送?
修改二:增加一个送货功能,可以让平时想兼职的同学对二手商品进行配送,并给予一定的费用,消费者和销售者可以在平台上看到二手商品的物流信息。类似滴滴司机的接单功能,想要通过送货兼职的同学可以在平台上接单。
问题三:对于前面提到的仓库管理人员和配送员,去哪里找这些人呢?
修改三:我们决定增加一个兼职板块,平时想要赚取生活费的同学可以在这个板块寻找兼职,其中包括二手商品配送员,仓库管理人员等
与用户沟通
2、修改完善需求规格说明书
上周的《需求规格说明书》中,对二手交易市场的功能分析和需求不够充分,功能方面没有考虑到毕业生不在学校如何进行二手商品的交易,且二手商品主要由毕业生进行出售,所以我们增加了二手商品的寄售功能,对于不在校的同学,二手商品可以寄往平台进行托管销售,但要收取一定的托管费中,且增加了仓库管理人员负责对这些寄售的商品进行管理;且我们的平台只考虑到如何实现二手商品的交易,并没有考虑到如何将二手商品送到消费者手中,于是我们增加了配送模块和兼职模块,平时想要赚取生活费的同学可以通过这个兼职对二手商品进行配送。对于前面说到的兼职,我们增加了兼职模块,其中包括二手商品配送员和仓库管理人员,每个职位对应不同的报酬,想要兼职的同学可以在这个职位选取相应的职位,既解决了二手商品的托管和配送问题,还让兼职的同学多了选择。
3、新增内容:
1、商品管理
•发布物品:卖家可以发布商品,包括物品描述、发布时间地点、分类、照片、价格等。
•商品编辑:卖家可以随时编辑和更新物品信息。
•商品搜索:提供搜索功能,允许用户按类别,商品关键词等搜索商品。
•商品详情:每个商品页面包括详细描述、照片、价格和联系卖家的选项。
•商品状态:标明物品的状态,如已完成,缺货等
•商品评论:允许用户在商品页面上发表评论和评分。
•商品托管机制:大四师兄留下来的书籍实行托管制之类的,防止大一和大四时间差,怎么实现配送之类的
2、交易和支付
•购物车:允许用户将多个物品添加到购物车,以便一次性结账。
•支付选项:先充值到我的钱包中,支持多种支付方式,如微信、支付宝等,再用钱包中的钱支付。
•订单管理:用户可以查看和跟踪他们的订单状态。
•交易通知:向用户发送订单确认、付款和发货通知。
4、功能分析的四个象限
参考《构建之法》5节功能的定位和优先级,给出功能分析的四个象限
①必须做且重要(Must-haves):
用户发布和浏览二手商品: 提供用户友好的界面,使毕业生可以方便地发布和浏览二手商品信息。确保商品信息包括必要的详细描述、价格和联系方式。
交易管理和托管: 实现交易的安全性和可控性,引入托管机制,为不在学校的毕业生提供寄售选择。设计仓库管理系统,确保托管商品的安全存放,增收一定的托管费用。
②必须做但不重要(Nice-to-haves):
兼职板块: 创建一个专门的板块,供学生浏览和申请兼职,包括仓库管理人员和二手商品配送员。为平台提供人力资源,同时为学生提供赚取额外收入的机会。
物流信息: 引入送货功能,让平台上的兼职配送员可以接单并将商品送达消费者手中。为用户提供实时的物流信息,类似于滴滴司机的接单和配送过程。
③不必做但重要(Not-so-importants):
优化用户体验: 确保平台的用户界面简洁直观,易于导航。考虑到用户体验的因素,例如快速加载、响应性和友好的设计,以提高用户留存率。
④不必做且不重要(Won't-haves):
非关键性功能: 避免投入过多资源在一些不是核心业务的功能上,如高级社交功能。优先考虑满足核心业务需求。
5、调整任务分解WBS及相应的项目进度计划
根据修改后的需求,调整任务分解WBS及相应的项目进度计划
任务分解
改进的项目进度计划
时间 | 任务内容 |
---|---|
第9周 | 1.团队组队、团队博客 |
2.团队介绍、成员展示、角色分配、选题确定 | |
3.制定团队计划安排,团队贡献分的规定 | |
第10周 | 1.需求规格说明书 |
2.原型设计,队员估计任务难度并学习必要的技术 | |
3.编码规范完成、平台环境搭建完成、初步架构搭建 | |
4、模拟测试,提出可能遇到的问题 | |
第12周 | 1.原型改进(给目标用户展现原型,并进一步理解需求) |
2.架构设计,WBS, 团队成员估计各自任务所需时间 | |
3.测试计划 | |
第13、14周 | 1. 团队项目Alpha任务分配计划 |
2. 连续7天的Alpha敏捷冲刺,7 篇 每日Scrum Meeting博客+代码提交 | |
3. 邀请部分同学进行第一次用户测试 | |
第15周 | 1.用户反馈+测试计划改进 |
2. 团队Alpha阶段个人总结 | |
3. 发布说明、测试报告、展示博客、项目管理 | |
4. 事后分析 |
三、系统设计
1、目的
本文档编写的目的在于阐明校园二手市场的功能需求与架构设计,通过本文档更好地了解校园二手市场系统的架构方案,为系统设计、编写、测试工作提供参考依据。
2、背景
校园二手交易市场是一个旨在为大学生提供便捷、安全、可靠的二手商品买卖平台的项目。在现代社会中,随着资源消费观念的变化和环保意识的增强,二手商品的需求逐渐增加。尤其是在校园环境中,学生们常常需要购买各类学习用品、生活用品以及娱乐设备等,而二手商品不仅价格相对较低,还能有效减少资源浪费,符合大学生的消费需求。
然而,目前校园内的二手交易往往存在以下问题:信息不透明、安全风险高、交易流程繁琐等。为了解决这些问题,我们决定开发一款校园二手交易市场应用,以提供一个便捷、安全、可信赖的平台,满足学生们的二手交易需求。
该应用将充分利用互联网和移动通信技术,采用B/S架构,为用户提供简单易用的界面和丰富的功能。用户可以通过应用发布自己想要出售的二手商品,也可以浏览他人发布的商品进行购买。同时,我们将提供用户登录注册、商品评论、消息通知、交易管理等功能,以提升用户体验和交易安全性。
用户特点:作为用户终端,基本都是一般的办公电脑,操作系统一般为Win7、Win10(可考虑后续会升级为Win11),一般使用主流的浏览器如Chrome、Edge、FireFox等。
3、系统业务架构图
4、系统架构详细说明
项目采用前后端分离架构,前端使用HTML、CSS和JavaScript开发用户界面,后台使用Spring MVC和MyBatis框架实现业务逻辑和数据持久化。通过RESTful API和HTTP协议实现前后端通信,实现用户、管理员、商品、订单、评论和通知等功能模块的交互。以下是对各模块之间联系的详细分析。
用户与管理员模块:
前端提供用户注册、登录、个人信息管理等功能,后台通过Spring MVC处理用户请求并调用相应的业务逻辑处理用户信息。管理员模块包括管理用户、商品、订单等功能,通过权限控制确保管理员操作的合法性,并向前端提供相应的管理界面。
商品模块:
前端展示商品列表、详情,支持搜索、筛选等功能,后台管理商品信息并提供商品数据接口供前端调用。在数据库中存储商品信息,如名称、价格、库存等,并通过MyBatis框架实现商品信息的增删改查。
订单模块:
用户可以浏览商品并下单,后台处理订单逻辑,包括生成订单、支付、配送等功能。订单信息存储在数据库中,并通过后台与前端进行交互,提供订单状态查询、支付接口等服务。
评论模块:
用户可以对商品进行评价,包括文字评价和评分,后台管理评论信息并与相应商品关联。前端展示商品评价信息,并提供用户评论提交功能,后台将评论信息存储在数据库中,并通过接口返回给前端。
通知模块:
系统可以向用户发送通知,如订单状态变更、活动信息等,后台管理通知内容和发送规则,将通知信息存储在数据库中,并通过业务接口向前端推送通知。
交互方式:
前后端通过RESTful API进行数据交互,前端发送HTTP请求到后台指定的接口路径,后台根据路由信息调用相应的Controller进行业务逻辑处理,并返回JSON格式的数据给前端。前端解析数据并进行页面渲染,实现用户与系统的交互
5、功能列表
模块分类 | 功能名称 | 模块功能 | 备注 |
---|---|---|---|
管理员 | 登录 | 输入账户名密码登录获得管理员权限 | |
注册 | 添加普通管理员 | ||
删除 | 删除管理员 | ||
查询 | 查询全部管理员 | ||
用户 | 登录 | 输入账户名密码登录 | |
注册 | 注册新账号 | ||
通知 | 查询通知 | 获取商品评论的通知 | 区分管理员和游客 |
游客通知 | 获取游客的通知 | 区分管理员和游客 | |
读通知 | 消息已读 | ||
删通知 | 消息删除 | ||
商品 | 购买商品 | 用户购买商品 | |
查询商品 | 用户查询商品 | ||
发布商品 | 用户发布新商品 | ||
删除商品 | 用户删除商品 | ||
更新商品 | 用户更新商品 | ||
评论 | 评论商品 | 用户评论商品 | 需购买后才可评论 |
6、系统页面
7、数据库设计(ER图)
表Users
:这个表存储用户信息,包括用户ID、用户名、电子邮件和注册日期等字段。
表Products
:这个表用于存储产品信息,包括产品ID、产品名称、价格和描述等字段。
表Orders
:这个表用于记录订单信息,每个订单都有一个唯一的订单ID,以及与订单相关的用户ID和产品ID等字段。此外,还有一个代表订单日期的字段。
表OrderItems
:这个表用于记录订单中的产品项信息。每个订单可包含多个产品项,并通过订单ID和产品ID与Orders
和Products
表进行关联。此外,还有一个字段记录产品数量。
表Categories
:这个表用于存储产品类别信息,包括类别ID和类别名称等字段。
这些表之间通过外键建立关联,例如,Orders
表中的用户ID外键关联到Users
表的用户ID字段,OrderItems
表中的订单ID和产品ID外键分别关联到Orders
表和Products
表的对应字段。 以上是简述的数据库设计内容,如果您有任何其他问题,请随时提问!😊
ER图
四、Alpha任务分配计划
1、Product Backlog
依据项目组能提供的总时间、功能模块的优先级以及模块之间的依赖关系,在Product Backlog中选取待实现的功能项。
2、Sprint Backlog
对已选择的功能项再做进一步分解,分解为1-10小时左右的任务,构成Sprint Backlog。在PM的协助下,编码的同学对任务进行认领。
3、甘特图
以甘特图的方式拟定迭代冲刺计划。
五、测试计划
1.引言
1.1项目背景
校园二手交易市场:
本系统主要面向于大学校园网用户,依托校园网提供给这些用户一个发布和交流二手商品信息的平台。在大学校园里,存在着很多的二手商品,但是由于信息资源的不流通以及传统二手商品信息交流方式的笨拙,导致了很多仍然具有一定价值或者具有非常价值的二手商品的囤积,乃至被当作废弃物处理。现在通过进入到本系统,可以方便快捷的发布和交流任何二手商品的信息,并且可以通过留言方式进行深一步的交流。希望本系统的运营不仅可以为同学的校园生活提供便利,而且可以让更多有价值的资源得到利用。
1.2参考资料(计划编写依据:可行性分析报告/软件需求定义/软件概要设计/软件详细设计/用户使用说明书/……)
https://www.cnblogs.com/itest/archive/2008/06/24/1229151.html
1.3测试术语
测试用例(Test Case):描述了对软件特定功能或场景的测试步骤、预期结果和实际结果的文档或脚本。
缺陷(Defect):在软件中发现的错误、问题或不符合规范的地方,需要被修复。
自动化测试(Automated Testing):使用自动化测试工具和脚本来执行测试任务,提高测试效率和覆盖范围。
回归测试(Regression Testing):在软件发生变更后,重新运行既有的测试用例,以确保修改不会引入新的问题。
白盒测试(White Box Testing):测试人员有关软件内部结构和代码的详细信息,以编写测试用例和进行测试。
黑盒测试(Black Box Testing):测试人员无需知道软件内部结构和代码的详细信息,只需根据需求规格进行测试。
集成测试(Integration Testing):测试不同模块或组件之间的交互和集成,以验证它们一起工作的正确性。
端到端测试(End-to-End Testing):测试软件从开始到结束的整个流程,以确保整个系统的功能和性能都符合要求。
用户验收测试(User Acceptance Testing,UAT):由最终用户或客户执行的测试,以确认软件是否满足其预期需求。
性能测试(Performance Testing):测试软件在不同负载条件下的性能表现,包括响应时间、吞吐量和并发用户数等。
1.4有关项目人员组成以及联系方式(开发人员/版本控制人员/测试人员/软、硬、结构、营销人员等)
林劲辰 产品经理 13676708183
许庆阳 需求经理 13692091187
伊尔凡江·艾合买提 需求经理 15609950937
苏建澎 开发工程师 13714283181
鄞灿 开发工程师 13242597082
于阳 开发工程师 13406728050
黎灿宇 测试员 13556481526
2.任务概述
2.1测试范围
1、功能测试:验证软件的功能是否符合需求规格说明书中的要求,包括输入、输出、处理和用户界面等方面的功能测试。
2、性能测试:测试软件在不同负载条件下的性能表现,包括响应时间、吞吐量、并发用户数等方面的性能测试。
3、安全测试:测试软件在面对各种安全攻击和威胁时的表现,包括数据保护、身份验证、授权和审计等方面的安全测试。
4、兼容性测试:测试软件在不同的操作系统、浏览器、设备和网络环境下的兼容性,确保软件在各种环境下都能正常运行。
5、用户体验测试:测试软件的用户界面和交互设计是否符合用户的预期和需求,包括易用性、可访问性和可用性等方面的用户体验测试。
6、回归测试:测试软件在修改、升级或迁移后是否仍然能够正常工作,以确保修改不会引入新的问题。
7、自动化测试:使用自动化测试工具和脚本来执行重复性高、耗时长的测试任务,提高测试效率和覆盖范围。
2.2测试目标
1、发现和修复缺陷:通过测试,发现并报告软件中的缺陷和问题,帮助开发团队及时修复,提高软件的质量和稳定性。
2、确保软件符合需求:验证软件的功能是否符合用户需求和规格说明书中的要求,确保软件能够满足用户的期望。
3、提高软件质量:通过测试,确保软件的功能、性能、安全性和可靠性等方面达到一定的质量标准,提高用户满意度和信任度。
4、保证软件的稳定性:通过不同类型的测试,确保软件在各种条件下都能够稳定运行,减少软件在生产环境中出现故障的可能性。
5、降低软件维护成本:通过及时发现和修复缺陷,减少软件在生产环境中出现故障的可能性,降低软件维护成本和用户投诉率。
6、提高软件交付的可靠性:通过测试,确保软件交付前经过充分验证,提高软件交付的可靠性和稳定性。
2.3广义上还包含测试需求分析/测试用例编写/测试环境搭建/测试培训/测试执行等
3.测试策略
3.1测试人员需求、分工
以下测试角色的工作均由黎灿宇担任且完成
测试经理(Test Manager):负责规划、组织和管理整个测试团队,制定测试策略和计划,确保测试活动与项目目标一致。
测试分析师(Test Analyst):负责分析需求规格和制定测试用例,执行测试用例并记录测试结果,以确保软件功能符合需求。
性能测试工程师(Performance Test Engineer):负责规划和执行性能测试,评估软件在不同负载条件下的性能表现。
用户验收测试人员(User Acceptance Testers):由最终用户或客户承担,负责确认软件是否满足其预期需求。
3.2测试方法(自动化测试/手动测试;白盒测试/黑盒测试;中断测试/临界测试/压力测试等)
手动测试中的白盒测试与黑盒测试
3.3工具引用及测试培训(内训/外训)
IDEA Community Edit
3.4测试阶段计划(工作内容、人员安排、起止时间等)
① 进行各功能函数的白盒测试
人员:黎灿宇
起止时间:开发全程
②进行整体程序的白盒测试
人员:黎灿宇
起止时间:基本开发完成至完全开发完成
③进行整体程序的黑盒测试
人员:黎灿宇
起止时间:基本开发完成至完全开发完成
3.5测试停止及恢复条件
停止条件:
完成测试计划:当测试团队已经完成了测试计划中规定的测试任务和测试用例时,可以停止测试。
达到测试覆盖目标:当测试达到了预定的覆盖范围,包括功能覆盖、代码覆盖、路径覆盖等目标时,可以停止测试。
发现了严重缺陷:当测试过程中发现了严重的、影响系统稳定性和安全性的缺陷时,可以暂停测试并等待缺陷修复后再恢复测试。
超出时间和资源限制:当测试耗费的时间和资源超出了预算或计划范围时,可以暂停测试并重新评估测试策略和资源分配。
测试环境不稳定:当测试环境出现了严重的问题,影响测试的进行时,可以暂停测试并等待环境问题解决后再恢复测试。
恢复条件:
缺陷修复:当发现的缺陷得到修复后,可以恢复测试并验证缺陷是否已经解决。
环境问题解决:当测试环境的问题得到解决后,可以恢复测试并继续进行测试。
重新评估资源和时间:当测试耗费的时间和资源超出了预算或计划范围后,可以重新评估资源和时间,调整测试策略和计划后恢复测试。
重新规划测试:当测试目标或覆盖范围发生变化时,可以重新规划测试策略和测试计划后恢复测试。
3.6测试文档及缺陷提交管理等
软件测试文档和缺陷提交管理是软件测试过程中非常重要的一部分,它们有助于记录测试过程、结果和问题,以便团队成员之间进行有效的沟通和协作。
常见的软件测试文档的内容:
测试计划:测试计划是测试活动的指导文档,包括测试范围、测试目标、测试策略、资源需求、时间计划、风险评估等内容。测试计划通常由测试经理或测试负责人编写,并经项目相关人员审批。
测试用例:测试用例是描述测试步骤、预期结果和测试数据的文档,用于执行测试。测试用例应覆盖软件的各种功能、场景和边界条件,以确保对软件进行全面的测试。测试用例通常由测试人员编写,并经过审查和批准后执行。
测试报告:测试报告记录了测试的执行结果、发现的问题、测试覆盖情况等信息。测试报告有助于评估软件的质量和稳定性,以便决定软件是否可以发布或需要进一步的改进。
缺陷报告:缺陷报告用于记录发现的软件缺陷,包括缺陷的描述、重现步骤、严重程度、影响范围等信息。缺陷报告通常由测试人员提交,并经过评审后分配给开发团队进行修复。
常见的缺陷提交管理步骤:
缺陷提交:测试人员在发现缺陷后,应编写详细的缺陷报告,并提交给缺陷跟踪系统或项目管理工具。
缺陷评审:提交的缺陷报告经过开发团队或相关人员的评审,确认缺陷的有效性和严重程度。
缺陷分配:经过评审后,缺陷被分配给相应的开发人员进行修复。
缺陷验证:开发人员修复缺陷后,测试人员进行验证,确认缺陷是否已经解决。
缺陷关闭:经过验证后,测试人员可以关闭缺陷报告,或重新打开缺陷报告,直到缺陷得到有效解决。
3.7测试环境
设备:联想拯救者R9000P
操作系统Window10IDEA Community Edit
内存:16GB+512GB
测试工具:IDEA
4.测试资源
4.1硬件资源需求
一台win10以上系统的个人电脑
4.2软件资源需求
下载IDEA
4.3测试环境需求
配置好Java环境,且下载好测试插件
4.4测试人员需求
一位时间灵活的软件测试员
4.5其他(仪器、服务器等)
5.风险评估
5.1人力方面;软件测试员可能因为特殊原因无法进行工作,此时团队中有其他技术人员可以顶替,风险较低
5.2时间方面;计划中安排的时间均较为充裕,风险较低
5.3环境方面;该项目对开发环境要求不高,风险较低
5.4资源方面:该项目对软硬件设备要求不高,风险较低
5.5部门合作方面:团队成员之间关系融洽,交流积极,风险较低
6.其他内容
测试计划制定者:黎灿宇
日期:2023年11月16日
修改记录:最新版为2023年11月16日21:00版
评审人员信息:
林劲辰 产品经理 13676708183
许庆阳 需求经理 13692091187
伊尔凡江·艾合买提 需求经理 15609950937
苏建澎 开发工程师 13714283181
鄞灿 开发工程师 13242597082
于阳 开发工程师 13406728050