团队作业3需求改进与系统设计
一、需求与原型改进
1.1改进的原型
1.1.1 改进说明
改进的地方：
我们将主页各个小组的名称和每个小组的任务清单由原来的输入框改为直接显示文字，在每个小组右边加上加入小组的加号按钮，然后把加入小组的页面里面的加入小组需要密码这项给去掉，而成为管理员这项保留，又给管理员增加了小组管理者这个功能，这个功能包括同意申请人加入小组和把小组成员移出的功能。
改进的理由：
改掉小组名称和任务清单的输入框以免给用户产生该地方可以输入文字的误会，将加入小组的选项放到每个小组右边可以在有很多小组时让用户看到喜欢的小组就直接加入，提高用户的体验。去掉加入小组成员所需要的密码和增加管理员接收新成员申请与移出小组成员的权限是一体的，这样既可以减少组员的负担又可以提高管理者对小组的管理能力。
1.1.2 高保真原型
1.1.3 高保真原型下载地址
https://free.modao.cc/app/3cd697c391022c049f094dbf6b1902251f03d5a9/embed#screen=s94981347831527595084651
1.2改进的需求规格说明书
1.21改进说明
改进部分一:为项目需求规格说明书新增一个目录
改进理由:重新查阅需求规格说明书的格式规范之后，我们发现一般比较正式的说明书都应该有一个目录，但是之前的1.0版本的需求规格说明书缺少这个部分，于是我们对说明书重新编排页码后列了一个目录，方便读者能够快速阅读各个部分的内容。
改进部分二:在引言中为定义重新增加了两个专有名词:App、Android
改进理由:原先的1.0版本的需求规格说明书中只有一个名词定义:Android studio，作为正式的需求规格说明书，确实显得偏少，于是在改进过程中，我们根据自己的项目，又在此基础上增加了两个新的名词定义:App、Android studio。
改进部分三:在需求规定中重新定义了功能规定
改进理由:由于在我们对原型设计的不断改进之中，我们的项目功能也有所改进，所以，对管理端与学生端，都新增了两个共同的功能:登录和编辑个人信息。
改进部分四:对性能规定中灵活性的补充
改进理由:原先书写好的1.0版本的需求规格说明书中只对灵活性这个性能列出了提纲，对于细化内容尚未书写，所以在这次的改进之中对此做出了补充说明。
改进部分五:在需求规定中新增了属性说明
改进理由:之前1.0版本的需求规格说明书中缺少这一部分的内容，但是在改进过程中了解了需求规格说明书的格式规范之后，我们觉得有必要编写，所以就重新增加了可用性、安全性、可维护性三个属性，最终形成了目前改进之后的2.0版本的需求规格说明书。
1.22改进说明书的地址
链接：https://pan.baidu.com/s/1_qDqm9cHBB0iU_AjmFdVdQ 密码：07sq
二、系统分析
2.1系统架构设计
这个系统分析是需求改进前的系统，因为新的改进需求要求了不少新功能，而完善这些新功能需要的时间很多，来不及在期末考试前完成，所以我们打算把初始系统作为版本1，发布后看用户反馈决定是否发布版本2(需求改进后的版本)
该系统的ER图
2.2 任务分解WBS
各个组员估计好自己的完成时间后将deadline写在了WBS里，同时预估了各部分的任务量
另外软件测试没有写在任务分解里，是因为软件测试这方面只有计划，还没有成型的技术，所有我们计划在未来的博客中进一步完善任务分解
三、测试计划
目录
- 1.引言
- 1.1 项目背景
- 1.2 参考资料
- 2.任务概述
- 2.1 测试范围
- 2.2 测试目标
- 3.测试策略
- 3.1 测试方法
- 3.2 测试工具
- 3.3 测试阶段预估及日程计划
- 3.4 测试变量矩阵量
- 4.测试资源
- 5.风险评估
- 6.其他内容
1.引言
1.1 项目背景
对现在的大学生来说，由于学习科目繁多，不同科目的老师都会布置相关的作业与任务，积攒起来，学习任务也挺多。也有不少同学在学校或学院社团、组织中担任相关职务，有许多部门、组织任务要完成，事情往往繁多而琐碎，如果没有把任务安排得合理到位，很有可能就会忘记去做。
我们初步规划在学校内发展，也就是让这款app代替qq/微信通知群，让学生和教师体会到这款app的方便，并广泛使用。
1.2参考资料
计划编写依据：
可行性分析报告
软件需求定义
软件概要设计
软件详细设计
用户使用说明书
2.任务概述
2.1 测试范围
对整个任务助手App及不同开发阶段进行测试
2.2 测试目标(Why)
软件测试目的
（1）给开发人员提供反馈信息。
（2）测试软件开发过程的质量，不仅是软件本身的质量。
软件本身达到目的
（1）开发阶段——对功能模块进行调试验证，对问题bug分析定位
（2）Alpha阶段——保证实现MVP核心功能且无BUG
（3）Beta阶段——核实app的所有功能实现且无BUG，同时满足用户友好性
3.测试策略(What)
3.1 测试方法
- 早期手动测试
- 功能测试（黑河测试）：
每项开发的新功能模块都需要进行手动点击按钮、提交申请
- 功能测试（黑河测试）：
- 后期自动化真机测试
- 客户端性能测试：
参数有：CPU，内存，耗电量，流量，FPS。同时也需关注一下App的安装耗时和启动耗时。 - 功能测试：
后期回归测试，运用MTC平台自动化测试。 - 适配兼容测试：
目前安卓机型碎片化，关注点是不同机型安装、拉起、点击和卸载是否正常 - 安全测试：
检测应用是否容易被外界破解；是否存在被恶意代码注入的风险；上线后外挂的风险高不高等。 - 耗电量测试：
app是否耗电也是至关重要。关注点：手机设备在满电的时App能运行多久；App每小时的耗电是多少；App在某个场景挂机10分钟耗电量是多少； - 中断测试：
针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法，如：App在前台和后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。测试电话，短信，彩信，微博或其他通知进来时app的反应。 - 界面测试
界面是否友好，满足简洁
- 客户端性能测试：
3.2 测试工具
Android测试工具
·Monkey进阶
·Android Instrumentation
·Android BDD-Calabash
MTC测试平台
3.3 测试阶段预估及日程计划
| 工作内容(What) | 工作量 | 人员安排(Who) | 时间安排(When) |
|---|---|---|---|
| 进行手动测试 | 易 | 陈杰、唐祎琳 | 开发阶段 |
| MVP核心功能的系统测试 | 中等 | 刘畅、唐祎琳、陈杰 | Alpha阶段结束后2天 |
| App的所有功能回归测试 | 复杂 | 刘畅、唐祎琳、陈杰 | Beta阶段结束后4天 |
3.4 测试变量矩阵量
| 用户类型 | 屏幕 | 操作系统 | 操作系统默认语言 | |
|---|---|---|---|---|
| 变量数目 | 2 | >5 | >5 | 1 |
| 学生 | 主流Android机型 | Android2.1版本及以上 | 中文（简体） | |
| 管理员 | 主流Android机型 | Android2.1版本及以上 | 中文（简体） |
4.资源
人力：团队主要后端人员与测试人员
物力：
要提交的App物料，即apk文件
MTC平台
5.风险
可能造成风险的不同方面因素：
1.短时间上市，时间不足
2.新的设计，会拖慢进度，还有Bug的风险
3.复杂程度，算法复杂无法实现
4.使用频率
5.不可测试需求
6.其他内容
测试计划制定者：唐祎琳
日期：2018/5/28
修改记录：暂无
评审人员：
开发负责人：刘畅
测试负责人：唐祎琳
