一、需求&原型改进
1.1 课堂讨论问题
-
问题1：针对的用户范围较广，不同身份的用户对时间的安排管理需求会有较大的区别；
-
问题2：软件使用流程说明不足；
1.2 问题修改完善
-
解决1：进一步深入调研不同身份人群的时间规划需求，增加智能排序算法的种类；
-
解决2：补充说明各个模块的功能，将各个模块进行串联说明；
1.3 用户需求调研
-
方式：以问卷星的方式进行线上调查，题型为12道选择题+1道填空题
-
核心问题结果统计：
-
-
结果分析：
-
用户痛点：操作不便，界面冗余难懂，任务展示不清晰，对任务安排不明确；
-
用户需求：界面简洁明了，能够智能规划个人一天的时间，并且能够提供实时提醒功能。
-
1.4 需求规格说明书完善
1.4.1 初稿不足之处
-
各个模块之间的关系没有讲解清楚，没有给出整个系统操作对应的流程图；
-
没有详细说明用户在各个模块可以执行的操作；
1.4.2 改进
-
系统流程图：
-
1.4.3 使用场景介绍（User Story）
此场景真实生动，请细品！
在他还没有使用TPlanner的时候
现在是5月18日凌晨2：33，他还在电脑前苟延残喘。
他疲惫地抬头，望了望窗外，外头只有那么几点惨白的灯光。
这个城市的灯火即将熄灭在睡梦中，他感觉他也近将熄灭，熄灭生命的灯火。
当别人闲得在网上冲浪、吐槽无聊的网课生活之时，他的生活丰富得羡煞旁人：
他就读于广东工业大学软件工程专业，正为应用文写作考试的复习、操作系统的实验、计算机网络的预习（？）、概率论和数据库成吨的作业等等秃头；
他出生于一个现代化的双工家庭，工作日在空荡的家里，他摇身一变成为了家里包揽家务的保姆，正在为定期的房间打扫、换季床褥的换洗、宠物甲虫的科学喂养等等操心；
他加入了两个工作室，此外还肩负着一个空降的软件工程团队项目，身为一个卑微的UI、设计、兼职客服、程序员鼓励师、bug背锅侠，前端、后台、产品经理、客户轮番对他进行着全方位的轰炸，他由彻地感受到 来自万恶资本主义的压榨 谋生不易；
“啊…后天就是520了啊…” 他打开手机，看了看日历，上面写满了乱七八糟的日程，“后天就是……中国台湾地区领导人就职日了啊…什么时候台湾才能真正回归呢？”
那些日程并没能帮助他太多，就算知道deadline在那里，又能怎样呢？他的生活还是一团乱麻，像下一盘 “那边还有对象，我除了帅以外一无所有” 的残局，他顾此失彼地、仓皇失措地带着他的帅一格一格地逃亡……
在他开始使用TPlanner的时候
“叮咚！”
他被这突兀的消息提醒声吓到，因为这既不属于客户、也不属于老板，这是——QQ特别关注的专属铃声，属于一个在他记忆深处的女孩。他手忙脚乱地点开，生怕她反悔着撤回。
“ 嘿大兄弟~最近忙吗？♥ ” 她的语气还是那样俏皮可爱，他感到舒心。
“ 哈哈 不忙 小沛最近怎么样？” 他双手微微颤抖着撒了个小谎，飞速敲下一行字。
“ 嘻嘻 想要跟你一起过520 =^•ω•^= ” 她发来一个叫做 “TPlanner” 的小程序，点开，是一个团队计划的邀请。
团队的名字叫 “ 两个人的秘密 ”，那是一个叫做 “ 只有一个中国：台湾回归 ” 的计划，一个个详细的小计划贴心地罗列在团队计划页，原本空空如也的日程页，也终于拥有了它的色彩。
这一刻他的世界静止了，他仿佛被拥入了一个温暖的怀抱。
他的灯火，燃起来了。
他快速地浏览TPlanner的页面，明亮的、正义的黄色映入他的双眼，他熟练地将自己繁多的日程一股脑地输入到个人计划中，点击 “ 完成 ” 键的那一刻，他仿佛重获了新生，日程页清晰地列举地严谨计算过的最优计划，事无大小，从家务到项目工作，都细细列出。
他发现自己的时间是完全够用的，只是因为时间分配的复杂而感到生无可恋，他的生活重新变得美好起来，甚至腾出了许多盈余的时间——他将它们都给予了女孩，他的小沛。
TPlanner，您的专属时间管家，为您点亮混沌的明天。
二、系统设计
2.1 系统架构设计
2.2 数据库设计
2.2.1 ER图
2.2.2 各表设计说明
user表： 存储用户个人的一些基本信息
| 字段名 | 含义 | 类型 | 非空/空 | 约束条件 |
|---|---|---|---|---|
| user_id | 用户的唯一id | int | 非空 | 主键、自动递增 |
| open_id | 用户小程序唯一标识 | varchar | 非空 | |
| name | 用户的昵称 | varchar | 非空 | |
| wechat_icon | 用户头像 | varchar | 非空 | |
| union_id | 用户微信平台唯一凭证 | varchar |
plan表：存储用户在团队和个人计划模块填写的计划信息
| 字段名 | 含义 | 类型 | 非空/空 | 约束条件 |
|---|---|---|---|---|
| plan_id | 计划表的唯一id | int | 非空 | 主键、自动递增 |
| user_id | 用户id | int | 非空 | 外键(与user表的user_id字段进行更新、删除级联) |
| plan_name | 计划名称(描述) | varchar | 非空 | |
| type | 计划类型标识(非0为团队id,0为个人计划) | int | 非空 |
task表：存储plan表中每个计划下的众多子计划信息
| 字段名 | 含义 | 类型 | 非空/空 | 约束条件 |
|---|---|---|---|---|
| task_id | 子计划唯一id | int | 非空 | 主键、自动递增 |
| plan_id | 计划id | int | 非空 | 外键(与plan表的plan_id字段进行更新、删除级联) |
| task_name | 子计划名称(描述) | varchar | 非空 | |
| lasting | 子计划消耗时长(以分为单位) | int | 非空 | |
| start_time | 子计划开始时间 | datetime | 非空 | |
| end_time | 子计划结束时间 | datetime | 非空 | |
| priority | 优先级(1~4,数字越大优先级越高) | tinyint | ||
| status | 完成情况(0表示未完成,1表示已完成) | tinyint | 非空 |
group表：存储用户所创建的团队信息
| 字段名 | 含义 | 类型 | 非空/空 | 约束条件 |
|---|---|---|---|---|
| group_id | 团队唯一id | int | 非空 | 主键、自动递增 |
| group_name | 团队名称 | varchar | 非空 | |
| creator_id | 创建者id | int | 非空 | |
| limit | 团队人数上限 | int |
member表：存储每个团队中成员的id，将团队和成员进行关联
| 字段名 | 含义 | 类型 | 非空/空 | 约束条件 |
|---|---|---|---|---|
| group_id | 团队唯一id | int | 非空 | 外键、(与group表的group_id字段进行更新、删除级联) |
| member_id | 用户的唯一id | int | 非空 |
三、Alpha任务分配计划
3.1 待实现功能项：
-
模块名称 优先级 个人计划模块 高 团队计划模块 较高 日程表模块 高 个人设置模块 中
3.2 待实现功能项分解：
-
功能名称 负责人 预计工时 优先级 个人计划信息展示 洪梓豪、王树干 5h 高 个人计划信息更新 洪梓豪、王树干 8h 高 日程表排序算法 柴政 8h 高 日程表信息展示 郭沛、王树干 5h 高 团队计划信息展示 郭沛、洪梓豪、黎其钻 8h 较高 团队计划信息更新 郭沛、洪梓豪、黎其钻 8h 较高 团队成员更新 郭沛、黎其钻 5h 较高 计划消息推送提醒 郭沛、王树干 4h 中
3.3 迭代冲刺计划（甘特图展示）
四、测试计划
4.1 项目简介
项目名称为TPlanner，本系统主要面向的是对于多项任务需要有一个井然有序的时间安排的用户群体，在日常生活中，大多数人会因为任务繁多且杂乱，而导致时间安排不合理，最终的结果便是做事效率不高，容易出现任务遗忘处理等情况；而我们的小程序致力于“智能规划”用户每一天的时间，根据用户个人做事情的习惯(例如用户喜欢先做短时任务|长时任务等等习惯)来列出任务清单；同时为解决用户可能出现的对事先任务的完成感到动力不足的情况，我们引入了团队计划的方法，这样可以让团队成员之间相互监督，相互督促，是高效办公成为可能。
4.2 测试目的
测试是一个项目开发的核心环节，决定着程序正式上线时的质量，只有经过严密测试，才能提高用户的体验，防止因为开发人员疏忽而导致的客户不能有好的体验。
4.3 单元测试
4.3.1 测试模块
| 测试功能名称 | 测试负责人 |
|---|---|
| 个人计划信息展示 | 洪梓豪、王树干 |
| 个人计划信息更新 | 洪梓豪、王树干 |
| 日程表排序算法 | 柴政 |
| 日程表信息展示 | 郭沛、王树干 |
| 团队计划信息展示 | 郭沛、洪梓豪、黎其钻 |
| 团队计划信息更新 | 郭沛、洪梓豪、黎其钻 |
| 团队成员更新 | 郭沛、黎其钻 |
| 计划消息推送提醒 | 郭沛、王树干 |
4.3.2 单元测试标准
-
按照单元测试计划完成了所有规定单元的测试
-
达到了测试计划中关于单元测试所规定的覆盖率的要求
-
软件单元功能与设计一致
-
在单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准
4.4.1 测试方式
| 压力测试 | |
|---|---|
| 测试目标 | 使用LR模拟真实用户对服务器施加压力。 |
| 测试范围 | 项目服务器(阿里云服务器ECS) |
| 完成标准 | 直到服务器卡死。获得服务器资源，最大与链接数等数据。 |
| 需考虑的特殊事项 | 测试机是否满足需求。 |
| 使用工具 | Jmeter |
4.4.2 测试标准
-
性能测试用例设计已经通过评审
-
按照性能测试计划完成了性能测试
-
达到了性能测试计划中关于性能测试所规定要求
-
在性能测试中不通过的用例已经得到修改，性能达到预计标准
4.5 易用性测试
4.5.1 测试方式
| 易用性测试 | |
|---|---|
| 测试目标 | 模拟真实用户，无经验用户，测试系统的易用性。 |
| 测试范围 | 前台 |
| 完成标准 | 成功地核实出前台各个页面符合可接受易用性标准。 |
| 需考虑的特殊事项 | 无 |
4.5.2 测试标准
-
功能测试用例设计已经通过评审
-
按照功能测试计划完成了功能测试
-
达到了功能测试计划中关于功能测试所规定的覆盖率的要求
-
系统达到详细设计定义的各项功能，性能在功能测试中发现的错误已经得到修改，各级缺陷修复率达到标准
4.6 可靠性测试
4.6.1 测试方式
| 可靠性测试 | |
|---|---|
| 测试目标 | 使用LR模拟真实用户对服务器施加一定压力。 |
| 测试范围 | 项目服务器。 |
| 完成标准 | 持续运行特定时间不出现问题。 |
| 需考虑的特殊事项 | 测试机是否满足需求。 |
4.6.2 测试标准
-
性能测试用例设计已经通过评审
-
按照性能测试计划完成了性能测试
-
达到了性能测试计划中关于性能测试所规定要求
-
在性能测试中不通过的用例已经得到修改，性能达到预计标准
4.7 回归测试
4.7.1 测试方式
| 回归测试 | |
|---|---|
| 测试目标 | 确保BUG修复的完整性。 |
| 测试范围 | 项目中出BUG 的部分。 |
| 完成标准 | 项目中出现的BUG完成修复，并将缺陷保存下来。 |
| 需考虑的特殊事项 | 出BUG的功能和BUG相关的功能都需要回测。 |
4.7.2 测试标准
-
软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。
-
在验收测试中发现的错误已经得到修改，各级缺陷修复率达到标准
-
所有测试项没有残余紧急、严重级别错误。
-
需求分析文档、设计文档和编码实现一致。
4.8 测试计划
| 测试名称 | 测试者 | 预计时长 | 完成时间 |
|---|---|---|---|
| 单元测试 | 郭沛、柴政、洪梓豪、王树干、黎其钻 | 2天 | 2020.6.1 |
| 压力测试 | 郭沛、柴政、洪梓豪 | 1天 | 2020.6.2 |
| 易用性测试 | 郭沛、柴政、洪梓豪、王树干、黎其钻、简蕙兰 | 1天 | 2020.6.2 |
| 可靠性测试 | 郭沛、柴政、洪梓豪 | 1天 | 2020.6.4 |
| 回归测试 | 郭沛、柴政、洪梓豪、王树干、黎其钻、简蕙兰 | 1天 | 2020.6.5 |