团队作业3--需求改进&系统设计
| 课程 | 网工1934-软件工程 |
|---|---|
| 要求 | 点击查看 |
| 目标 | 需求改进&系统设计 |
一、需求&原型改进
1.问题
问题1 ：漂流瓶聊天功能只能是实时聊天，用户离线后将不能聊天
修改：用户交流双方均在线时可以相互聊天，其中一方离线后也可通过留言的形式进行聊天。
问题2：由于漂流瓶采用随机分配，当投掷漂流瓶过多时，不能合理选择漂流瓶呈现给用户捡。
修改：对于被捡到次数过多的漂流瓶，采取降权的形式，即被捡到的概率将会降低，甚至移除该漂流瓶。
2.原型展示
以上只展示了部分功能，还有更多功能等待与用户沟通添加。
3.需求规格说明书
新增离线留言功能，离线后也能发送消息给对方。
场景模拟（User Story）
用户登录完进入首页后，可以捡页面上已有的漂流瓶，也可以自己仍一个，若是自己捡（即点击对应漂流瓶）可以查看漂流瓶的内容，这时候有两种选择，用户可以选择扔回去，也可以选择回复TA，若选择了回复，则可以进行聊天并可添加好友，当捡到的漂流瓶主人已经离线也可以留言。
功能分析四象限
| 外围功能 | 杀手功能 | |
|---|---|---|
| 必要需求 | 登录注册登录 | 仍捡漂流瓶、随机匹配、聊天留言 |
| 辅助需求 | 用户举报 | 添删好友 |
分解WBS
项目进度计划
登录注册模块大概用一天，漂流瓶模块大概用三天，聊天模块大概用五天，测试完善用两天。
二、系统设计
1.架构设计
2.数据库设计
三、Alpha任务分配计划
1.Sprint Backlog
2.Product Backlog
3.甘特图
四、测试计划
1.引言
1.1项目背景
漂流瓶APP是一款面向交友、恋爱、约会、树洞、社交于一身的软件。有很多话,无处诉说却不愿藏在心底,那就来漂流瓶,说给 Ta 听吧。在这里,快乐能被分享,难过能被倾诉,平凡无聊的生活因为声音的聆听变得丰富。在这里,你可以唱歌,可以讲故事,可以当声音主播,可以当话题能手,可以交到志同道合的朋友,这是单身却并不孤独的时刻。
1.2参考资料
用户使用说明书。
1.3测试术语
黑盒测试：
黑盒测试，指的是把被测的软件看作是一个黑盒子，我们不去关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出结果。
它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
白盒测试：
白盒测试，指的是把盒子盖子打开，去研究里面的源代码和程序结果。
它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作 。
灰盒测试：
灰盒测试介于黑盒测试与白盒测试之间。
可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
2.任务概述
2.1测试范围
漂流瓶APP。
2.2测试目标
检查功能是否能正常使用，是否存在bug。
3.测试策略
3.1测试人员需求、分工
小组成员一人测一个模块。
3.2测试方法
白盒测试／黑盒测试
3.3工具引用及测试培训
JUnitGenerator 单元测试，内训。
3.4测试阶段计划
人员安排：所有小组成员
时间：app完成后的一天。
3.5测试停止及恢复条件
当所有功能测试并完善完毕时，测试停止及恢复条件。
3.6测试文档及缺陷提交管理等
3.7测试环境
Window，Android等。
4．测试资源
4.1硬件资源需求
电脑、手机。
4.2软件资源需求
IDEA等工具。
5．风险评估
5.1人力方面
组内成员测试，人力充足。
5.2时间方面
几周内完成。
5.3环境方面
仅有我们小组做这个app，环境较好。
5.4资源方面
网络资源充足，无需资金投入。
5.5部门合作方面
自主开发。
6．其他内容
测试计划制定者：蔡鑫源
日期：2021年11月15日
评审人员：罗汉光，纪培浩，拜合提亚尔。
