团队作业第3周——需求改进&系统设计
1.需求&原型改进
本团队问卷内容：https://www.wjx.cn/jq/49658469.aspx
注：由于团队问卷调查均是线上分发问卷，没有照片或视频在线下调查用户的过程
参与本次调查的被调查者大部分为学生，因此该问卷对本平台的改进更有针对性
问题一：根据本团队进行的向学校分发调查问卷的统计结果发现，绝大部分被调查者利用网络进行休闲娱乐玩游戏如下统计：
基于此结果，本团队意向打造一个休闲娱乐与学习相结合的学习平台，即在原来设计的平台基础上，在时间允许的情况下，将加入在线影院等用户交互式的休闲娱乐社交功能。
问题二：调查问卷的结果显示，大部分被调查者都没有明确的学习计划甚至是迷茫；与此同时，大部分被调查者认为影响网络学习效果的主要原因是自身的控制力不强。
基于此结果，本团队在时间允许的条件下，意向为平台加入学习计划版块，可以根据个人不同的需求，打造个性化的学习计划，以及加入一些激励机制，例如：每进行有效线上学习超过一个小时，奖励现金红包等等。
系统WBS
2.系统设计
系统架构说明：
https://github.com/InnerGoast/StudySystem/blob/master/docs/系统架构技术规格.pdf
数据库设计说明：
https://github.com/InnerGoast/StudySystem/blob/master/docs/数据库说明.pdf
3.Alpha任务分配计划
1.根据前期的需求分析和项目计划，对学习凭条的功能实现进行优先级排序。
第一优先级：实现学习平台页面搭建，基本功能实现（登录、提问讨论、作业上传、评论功能、设置功能等）
第二优先级：实现社交娱乐版块（同城交友、实时聊天、影院）以及推送功能等复杂功能。
2.对已选择的功能项再做进一步分解，分解为1-10小时左右的任务，构成Sprint Backlog。在PM的协助下，编码的同学对任务进行认领。
| 任务 | 负责人 | 开始日期 | 结束日期 |
|---|---|---|---|
| Alpha版本 | |||
| 数据库 | 8748 | 2019/11/18 | 2019/11/22 |
| 建立数据表 | 8748 | 2019/11/18 | 2019/11/19 |
| 实现基本操作 | 8744 | 2019/11/19 | 2019/11/22 |
| 前端页面 | 8747 | 2019/11/18 | 2019/11/25 |
| 首页页面 | 8747 | 2019/11/18 | 2019/11/19 |
| 登录页面 | 8747 | 2019/11/19 | 2019/11/20 |
| 学生页面 | 8747 | 2019/11/20 | 2019/11/22 |
| 教师页面 | 8747 | 2019/11/22 | 2019/11/24 |
| 页面整合 | 8747 | 2019/11/24 | 2019/11/22 |
| 后端功能 | 2019/11/22 | 2019/11/30 | |
| 提问讨论 | 8744 | 2019/11/22 | 2019/11/25 |
| 评论功能 | 8744 | 2019/11/25 | 2019/11/28 |
| 作业上传 | 8748 | 2019/11/22 | 2019/11/28 |
| 设置功能 | 8749 | 2019/11/22 | 2019/11/28 |
| 登录功能 | 8747 | 2019/11/22 | 2019/11/28 |
| 测试总结 | 8746/8744 | 2019/11/22 | 2019/11/30 |
| 测试 | 8746/8744 | 2019/11/22 | 2019/11/28 |
| 总结 | 8746/8744 | 2019/11/28 | 2019/11/30 |
3.以甘特图的方式拟定迭代冲刺计划。
4.测试计划
1 测试术语
黑盒测试，功能测试，测试项，严重性
性能测试（Performance Testing）：
在一定负载情况下，系统响应时间、搜索筛选结果等性能是否满足用户特定的性能需求。
负载测试（Load Testing）：
在一定的软甲、硬件及网络环境下，在不同虚拟用户数量的情况下进行一种或者多种业务，测试服务器的性能指标是否在用户要求的范围内，用于确定系统所能承受的最大用户数、最大有效用户数以及不同用户数下的系统响应时间和服务器的资源利用率。
压力/强度测试（Stress Testing）：
在一定软件、硬件及网络环境下，模拟大量的虚拟用户想服务器产生负载, 使服务器的资源处于极限状态下并长时间连续运行,目的是用来测试服务器高负载情况下是否能够稳定工作。
配置测试（Configuration Testing）：
在一定的软件，硬件及网络环境下, 在数据库中构造不同数量级别的数据记录,运行一种或多种业务,在一定虚拟用户数量的情况下,获取不同配置的性能指标,由于选择最佳的设备及参数配置。通过配置测试可以将性能缺陷放大,方便定位行呢瓶颈。
4.2 有关项目人员组成
唐崇珂，石林峰，刘霍翔
2 任务概述
测试范围
本软件所有功能
| 测试类型 | 是否完成测试 | 测试优先级 | 说明 |
|---|---|---|---|
| 注册账号 | 最高级 | 用户（老师/学生）注册时使用的信息是否能通过 | |
| cookies测试 | 中等 | 检查cookies能否正常记录下用户的信息，cookies是否按预设时间进行保存用户信息，禁用cookie后系统的处理（可以通过改变系统时间来测试cookie过期等问题） | |
| 进入网站 | 高级 | 通过发布的链接是否能进入网站 | |
| 修改个人信息 | 中等 | 修改个人信息时，是否检测敏感字符 | |
| 新窗口的打开 | 中等 | 点击功能时新窗口能否按照预定方式打开 | |
| 数据库测试 | 低 | 数据信息是否一致：用户提交的信息是否正确，数据输出错误：主要由网络或程序本身设计问题等引起 |
压力测试： 测试系统的限制和故障恢复能力,即测试web应用
系统会不会崩溃，在什么情况下会崩溃。
测试的区域包括表单、登陆和信息传输页面等
测试目标
所有功能均能正常实现，能应对多用户需求
测试用例编写
模拟教师帐号，测试教师角度下的功能，如布置作业等；
模拟学生帐号，测试学生角度下的功能，如校园聊天等。
3.测试策略
测试人员需求、分工
唐崇珂：用户测试
石林峰：性能测试
刘霍翔：压力测试
测试方法
手动测试，黑盒测试
工具引用及测试培训
手动，内训
测试阶段计划
（工作内容、人员安排、起止时间等）
测试停止及恢复条件
测试停止条件：开发人员需要更改代码
恢复条件：确认代码修改无误
测试文档及缺陷提交管理等
在每次做完测试后都要记录并且上传
测试环境
Windows系统，校园网
4．测试资源
硬件资源需求
计算机、手机
软件资源需求
浏览器，sql server/my sql
测试环境需求
校园网内、公网内
测试人员需求
用户测试：唐崇珂
性能测试：石林峰
压力测试：刘霍翔
5．风险评估
人力方面；
人力充足
时间方面；
时间充足，当开发出一个功能的同时尽量测试
环境方面；
缺少对macOS的测试
资源方面
无
部门合作方面
测试人员随时报告测试结果给开发人员，开发人员根据报告进行代码修改
6.其他内容
测试计划者：
日期：
修改记录：
评审人员
开发负责人：
测试负责人：
项目负责人：