1 引言
1.1 系统概述
毕设导师智能分配系统是一个用来简化传统手工匹配繁琐操作的系统。本系统将学生报志愿、系负责人收集整理数据、相关人员进行手工分配、反馈选择结果等繁琐的操作转移到线上。把毕设导师互选的所有流程，传化对本系统的操作。减少了相关人员的工作量，降低了流程中由于手工操作而出现错误的可能。学生的志愿选择、导师分配、数据统计、结果查看及导出等操作均可在上系统完成，提高了毕设导师选择的效率。
本系统有以下四种类型的用户：
| 角色 | 主要功能 |
|---|---|
| 学生 | 修改个人信息、填报志愿、查看导师列表、查看导师详细信息、查看中选导师信息、查看中选导师的学生列表、 查看中选导师的学生信息 |
| 导师 | 修改个人信息、填报研究的课题方向、设置学生数、选择学生、查看选择自己的学生列表、查看选择自己的学生信息、查看中选学生列表、查看中选学生信息 |
| 系负责人 | 修改个人信息、批量导入学生信息、手动添加学生信息、修改学生信息、设置志愿个数、批量导入导师信息、手动添加导师信息、修改导师信息、设置导师学生数、设定当前年级、设定各个期限、选择算法自动分配、选择强制分配、导出分配结果 |
| 院负责人 | 修改个人信息、修改分配结果、导出分配结果、设置系负责人 |
本系统的主要流程为：
- 院负责人设置各个系的负责人 -> 系负责人进行匹配设置 ->
- 导师填报学生人数和选题 -> 学生填报志愿（第一轮） ->
- 导师选择学生（第一轮） -> 学生填报志愿（第二轮） ->
- 导师选择学生（第二轮） -> 系负责人为未分配到导师的学生进行手动分配 ->
- 院负责人对结果进行微调 -> 系和院负责人导出分配结果 -> 导师和学生查看各自结果
1.2 文档概述
本文档是毕设导师智能分配系统的用户试用和调研报告。文档第一部分是引言，描述了系统的大致功能、用户类型以及系统流程。第二部分是试用结果概述，给出了试用结果的总体评估，试用的环境以及方法等。第三部分是本文档的重点部分，详细描述了各个用户角色的试用详情。第四部分是用户对系统的总体评价、意见和建议以及最终结论。附录部分给出了团队小组成员从开发人员的角度对本系统的测试、试用心得。
2 试用概述
2.1 试用环境
- 各主流浏览器（Chrome等）
- 系统网址 ：http://www.303studio.cn/public/index.php
- 输入给定的用户账号密码，登录试用，模拟师生互选的过程
2.2 试用方法
| 角色 | 试用方法 |
|---|---|
| 学生 | PM将系统大致情况、流程介绍给测试学生，测试学生登录网址，按照指定流程进行试用 |
| 导师 | 暂无导师参与测试 |
| 系负责人 | 栋哥作为计算机实验班系负责人，在软工实践课验收时进行试用 |
| 院负责人 | 去院教学办找曹英老师，向其介绍大致流程，曹老师从院负责人的角度使用系统 |
2.3 总体评估
本系统在经过各个用户试用之后，得到了较高的满意度。虽然系统仍然存在一些不完善之处，但是基本上做到了不影响用户的体验。在试用时，用户切身体会到了该系统带来的便利之处，达到了设计该系统的初衷。
3 试用详情
3.1 学生用户
试用对象：数计学院2014级"NoBug"软工小组
试用时间：2016年12月19日
试用地点：30#宿舍
试用时长：60min
3.1.1 试用感受
针对我们的测试，这个是一个相对较为复杂的系统，基本功能都能满足，觉得后续在多个浏览器，或者系统上再测试一下，就可以投入使用了。
| 角色 | 试用感受 |
|---|---|
| 学生 | 作为学生，相比以前只能上福大数计学院网站上查看老师信息相比，这更方便的去获取老师的信息，了解自己兴趣所在。 |
| 教师 | 作为教师，间接打通了自己和学生的消息壁垒，可以看到学生的推荐信息以及个人基本信息，并且可以根据自己的意愿去主动选择学生。 |
| 系负责人 | 作为系负责人，核心功能智能分配算法能帮系负责人省去很大部分的工作，但同时觉得也是这个系统中最忙的人，需要对一些时间进行计算，等导师选择结束后，也可以通过导出获得便利，浏览器兼容问题还是有点的，还有就是智能匹配算法点击会卡掉。 |
| 教学办 | 有一个提示说您可以修改选课结果，这个有点麻，可能是报课系统的原因吧，可以方便的管理系负责人。 |
3.1.2 存在问题
| 所在页面 | BUG |
|---|---|
| 教学办-》管理系负责人-》修改 | 点击返回无效 |
| 教学办-》管理系负责人-》修改 | 搜索负责的人的时候，比如搜张，出来了张栋，张浩两位老师，选择张栋老师确认后，没有页面提示（没有反应），然后点击关闭，发现原先有的计算机实验班的负责人就没了，变成空，然后想要重新设置也无法重新设置系负责任人了。 |
| 学生、教师修改个人头像界面 | 上传不是图片的话，会出错误 |
| 系负责人与院负责人界面 | 登录两个账号，比如先登录系负责人，再登录院负责人，之前登录的界面会出现界面错乱的情况，点击对应的信息也会出现相应的报错 |
| 系负责人个人信息界面 | 头像无法加载 |
| 导师查看可选学生界面，具体学生信息 | 出现了这样的提示： 提示2：导师所带学生总数不得超过 -1 名，不得少于 1名0名！ |
| 系负责人学生结果 | 点击导出后无反应，不知道是不是浏览器兼容的原因 |
| 智能匹配 | 本次有三个作为学生的作为测试其中一个被老师选中，一个被老师拒绝，一个老师不选择也没拒绝，时间到了，同学还是没有出现在智能匹配列表中 |
3.1.3 UI鉴赏
整题风格简介大方，布局合理，基本上都达到了预期的效果，比教务处的系统好看，有妹子的组就是厉害。
3.2 导师用户
暂无导师参与测试
3.3 系负责人用户
试用对象：计算机实验班系负责人张栋老师
试用时间：2016年12月21日
试用地点：教学楼东3-305
试用时长：30min
3.3.1 存在问题
- web端和app端互联效果有待提高
- 演示的数据和真实数据不一致（比如说栋哥的工号就错了...
- 结果导出excel文件，其后缀名称变成了txt（手动改成xls是可以打开的
3.3.2 预期改进
和现有报课系统的数据，教师信息，负责人信息数据对接
进行系统压力测试，以应对后期较多的使用人数
模拟多人同时点击提交志愿按钮、导师同时点击确认学生按钮等情况
3.4 院负责人用户
试用对象：数计学院教学办曹英老师
试用时间：2016年12月20日
试用地点：数计院楼教学办
试用时长：45min
3.4.1 存在问题
院负责人设定系负责人时，点击确认没有反应
系负责人导入导师Excel信息后，界面提示导入失败，但是数据却成功导进数据库
模拟的真实数据量太少，应该至少有200名用户
3.4.2 需求变更
智能分配算法要能分配完所有学生，然后系负责人再去进行微调
一个系可以对应多个负责人
系负责人不能给予太多的工作量，对于信息导入只需要一次的操作，应由开发人员一次性导入
3.4.3 预期改进
整个简化的演示流程
用户指南
用户操作视频
展示经过智能分配后的整个计算机系的结果以及导出Excel文件的功能
4 系统评价
4.1 优点
- UI界面简洁美观大方
- 操作简单、容易上手
- 系统提示人性化
- 功能完善不冗余
- 解决传统手工收集、分配的烦恼，降低出错概率
- 提供师生相互选择、负责人手动分配、负责人算法智能分配等多种方式
- 提供excel一键导入用户信息、导出分配结果等功能，方便管理
4.2 不足
- 在学生的个人信息修改界面 ，点击修改后，要修改信息等等一系列基础资料，这个时候需要输入一些旧密码才能修改信息，这个地方我觉得提示不够好吧，第一次改的时候会觉得要全部信息都改了才能提交。
- 在系负责人智能匹配界面 ， 学生只有四个志愿，在这里有五个志愿，没有学生却存在着可翻页。
- 个别提示信息有误，比如系负责人管理导师界面，搜索框中提示的是"搜索姓名或学号"。
- 没有进行压力测试，小数据测试和大数据测试是完全不一样的概念。
4.3 建议
- 在系负责人设置等等系列时间的匹配设置界面，我觉得点进右边的日历栏，然后根据日历来选择对应的时间，看到琳琅满目的时间列表，确实花了不少功夫。可我觉得还是有点过于复杂化，个人建议是可以也构成对应的可用键盘输入的模式，然后也可以采用日历的模式，我觉得这样会好点。
- 在老师课题提交界面， 先选择超过限定人数的时候，点击后会把之前写的课题名称和介绍都清空，建议可以保留一下。
- 在第k轮老师选择学生过后，如果学生没有被选中，登录上去还是跟没有选老师一样，我个人觉得会不会有二义性，让学生认为自己没有过提交志愿的经历，个人建议要给个提示。
- 为了以后系统的实际投入运行，需分别为四种类型的用户角色提供相应的系统操作指南。
4.4 结论
经过alpha和beta阶段的开发，毕设导师互选系统终于面向用户试用了，喜大普奔！ 在给多位不同角色的用户试用之后，结果还是挺让人满意的，而且后期说不定还会在学院里投入正式的使用。用户在试用之后，也提出了非常中肯、有用的建议与意见，为系统后续的完善优化提供了方向。总之，该系统达到了用户的预期效果，实现了开发该系统的总体目标。附录：系统的真实数据模拟测试
测试信息
测试时间： 2016年12月18日下午
测试数据： 2014级计算机实验班的所有学生以及导师
测试方法：
- 组内7名成员分别充当学生、导师、系负责人、院负责人的所有角色，七台电脑轮流登录各个学生、导师账户进行操作
- 根据2014级真实志愿填报信息以及分配结果信息模拟师生互选的所有流程
- 导师设置可带学生人数时，尽可能模拟真实情况，可带学生人数为2个或3个的居多，1个和4的相对较少
- 导师选择学生时，部分老师拒绝所有学生，部分导师选择所有学生直至超出人数上限，部分导师接受一些拒绝一些。在接受和拒绝时参考了学生的绩点以及志愿顺序
- 第二轮学生填报志愿时，参考了学生第一轮所填报志愿的信息
- 二轮师生互选之后，采用智能分配对未分配到导师的学生进行分配，再手动微调，并导出Excel信息
- 压力测试，例多用户同时点击选择按钮
测试结果：
- 第一轮的分配结果信息和真实的分配结果信息基本一致
- 第二轮模拟填报时因为填报志愿信息和真实学生意愿可能相差较多，导致分配结果中第二轮中选的学生的导师和真实分配结果有点出入
- 整个测试过程中发现了发现了部分BUG和页面逻辑不大合理的部分，不过在后期均已进行修改完善。
开发人员测试及试用心得汇总
031402304 陈燊
存在问题
- 测试数据量太大，而且模拟时难以体现出学生和老师的真实选择意愿
- 整个运行流程出现了还几处BUG，基本是边改BUG边进行测试的
- 老师所给的师生信息中有几处是重复的
- 一共七个组员要模拟上百的角色，整个测试过程较为繁琐，而且容易因为粗心而导致填报错误
遗漏原因
- 老师所给数据信息过少，而且所给信息里面有导师以及学生姓名重复出现的情况
- BUG的出现是由于在开发过程中不同模块之间的沟通不足，导致程序猿的理解出了问题
- 小组里每个人都是第一次接触这么多数据的测试，显得略微有点手忙脚乱，对大量数据的测试方法还不是很科学、规范
心得体会
- 我们项目在测试的前几天就基本已经完成了，这几天来一直都是在为模拟测试进行准备，对系统边边角角的过程进行修补，但尽管如此，在实际模拟测试过程中还是出现了挺多问题，整个测试过程基本都是改一个BUG测试前进一步。其中最大的问题还是在于老师所给的Excel信息里面有出现不同工号或学号的对应同一个名字的信息，以及我们本身对Excel信息的审核不足，才导致了我们在测试到中间阶段时才发现了这个问题。不过其实对最终结果的影响不是很大，只是在填报志愿时和选择学生时会有点误差而已。
- 整个测试过程还是挺有价值的，充分验证了我们系统足以经受一百多号人的同时操作。不过这个数据测试量相对还是较少，进一步的测试拟采用整个计算机200多号人的数据进行测试。
031402203 陈齐民
存在问题
- 学生个人信息页面、导师个人信息页面、个人信息修改页面被覆盖
- 导师课题信息表的默认设置遗漏
- 接口的小修改很多
- 算法只能固定实现五个志愿数的设置，没有适应可设置的志愿数
- Excel导入时，学生的信息不正确
遗漏原因
- 系负责人的功能很多，而且功能都较复杂，实现比较麻烦，有些细节在一开始没有全部都考虑周到
- 接口是根据前端的界面实现的，所以需要根据前端的需要修改接口
- 智能分配算法因为有实验班的存在，需要单独处理比较麻烦，有许多地方需要调整没有考虑全面
- 系负责人可以设置志愿数，但是在算法中忘记忘记考虑
- Excel导入没有按照模版规定的格式导入
如何改善
- 本地有备份，学生个人信息页面、导师个人信息页面、个人信息修改页面从备份中复原
- 在系负责人设置匹配设置的时候，在导师的课题表中自动加入该系所有导师默认的课题信息
- 算法中多传入一个参数，即系负责人设置的志愿数，后台获取学生填报的志愿信息时，根据志愿数获取志愿信息写入文件，并调用算法
- Excel导入后结果不正确是因为导入时没有根据模版导入，导致写入数据库时错误，根据模版的格式导入即正确
- 根据前端的需求修改接口返回信息，改动并不大，主要是返回格式和数据的席位修改
心得体会
系负责人的功能太多 ，而且实现又比较复杂，所以每天都在敲代码，在测试前写好了所有的接口，但是在测试的时候还是发现了一堆的bug，不过还好这些bug都比较小，只需要稍微做修改就好，beta版本大家对github的使用都比较熟悉了，所以基本没有产生冲突，而且同步后也都能使用，着实轻松了不少。感谢前端partner，有他在我就可以一直专心的写后台，效率也高了不少，也感谢PM的合理分工，让大家都没有熬夜（我自己熬夜是因为沉迷软工无法自拔，一旦敲代码就停不下来了）。测试中发现了不少的问题，也解决了不少的问题，感觉测试是非常值得去做的。031402209 黄伟炜
存在问题
- 本地数据和服务器数据的更新有延迟，导致数据的现实的不一致
- 分页设置总页数为0时，js 会报类型错误，导致分页栏不能被正常更新
- 智能匹配界面调用错接口，导致每次刷新结果页面，都重新进行算法分配
- 按钮的样式不统一
遗漏原因
- 在冲刺阶段没有进行详尽的测试，只是测试样例通过就开始写写一个任务
- 忽略了很多细节的测试，比如，弹窗关闭后是刷新整个页面，还是调用接口刷新局部数据
- 没有重构代码，代码的条理不够清晰
如何改善
- 本地数据和服务器数据的不一致，主要是因为在调用数据的几乎同时，又对服务器数据进行了更新。造成了，本地数据被替换成旧的服务器数据。解决办法为，先更新数据，延迟500ms后再获取服务器数据
- 抽离公共模块，增加代码的复用度
- 重构 js ，找到代码上的错误，同时增强代码的可读性
心得体会
这几天并没有都在休息！虽然没有花很多时间在代码上。但是，总有断断续续地在接后台接口和改善前端界面。中间还对智能匹配界面进行了大修改，这里要感谢一下后台partner，提供了便利的接口！大赞！在界面的修修补补中，发现了自己代码很多不和逻辑的地方。比如界面的刷新、弹窗提示信息、分页的更新、文件重复上传等，都一一改过。重构了代码，觉得一下清爽了很多。解决bug，是既痛苦，又享受的过程。乐在其中！031402233 郑扬涛
存在问题
- 整理的excel表格信息有重复和遗漏之处
- 界面样式不统一
遗漏原因
- 给的原始数据就存在错误或重复的问题，比如存在不同的学生学号一样的错误数据，然后整理的时候也没特别注意，直到测试的时候才发现
- 之前没特别注意一些边边角角的界面细节
如何改善
- 重新整理数据，然后一行一行检查过去
- 修改样式
心得体会
体会了一把手动收集整理学生和导师信息的过程，虽然仅有不到一百条记录，但是还是出现了问题，这也恰恰暴露了传统手工收集信息，手动分配生成结果的弊端，容易导致信息有误。这也是我们开发这个导师互选系统的初衷，降低了流程中由于手工操作而出现错误的可能，方便了用户，同时也提高了工作效率。031402342 许玲玲
存在问题
- 按钮样式不统一
- 选择/拒绝获取学生信息，只能获取第一行学生的信息
- 弹窗的样式是浏览器的样式，风格不统一
遗漏原因
- 由于是前端写完代码，后台进行赋值，后台人员在button里面加了a标签导致的问题
- 对js的不熟悉导致只获取第一行的信息
- 这一部分由后台来写，所以遗漏了
如何改善
- 把a标签放在button的外面
- 通过学习jquery遍历的内容，还有在队友伟炜的帮助下，get到新知识
- 还未改善完成
心得体会
测试一步，发现一个bug，沉迷bug，无法自拔，对js的不熟悉，导致花了很多的时间，用了多种方法还是不行，最终还是在队友和外援的帮助下，顺利解决了，感觉理论学习和动手实践还是有很大的差距，理想和现实就是差距巨大。改bug令人烦躁，但是感觉学到了很多东西，懂得了用控制台查看，调试，懂得了JQuery的遍历的方法，还有ajax的使用，终于改完了bug，哈哈哈哈哈哈哈哈哈03140241 王婷婷
存在问题
- 导师个人详细界面——职称的显示
- 导师列表的分页显示
- 志愿填报界面——导师列表的显示顺序
- 志愿填报界面——提交志愿后按钮变成修改
- 课题提交界面——过了课题设置时间段后，界面显示之前设置的信息，但是没有提交按钮
- 提示不够完善
- 弹窗样式不一致
遗漏原因
4.5.6.这三个部分主要是因为个人考虑问题，在我眼里算是一个可有可无的功能，但是在别人看来就不一定了，属于人性化设计的问题。
职称显示这个地方主要是之前数据库中职称和课题填报的课题题目都是title所导致的，后面数据库修改好了，但是我后台赋值的时候忘记了。
分页这个问题主要是自己对于thinkphp5分页不够熟悉，写的很差劲，没有发现这个问题主要是之前自己在测试的时候基本就只有4、5个导师，就不会出现前几页丢失问题，昨天测试的时候有30+导师就会导致前几页会丢失。
导师列表显示问题，也是因为之前测试数据较少，凑巧成功排序了（真是好尴尬）
弹窗样式这个问题的话就是打算测试之前修改一下（原本以为很好改呢。。）
如何改善
4.5.6三点就是按照要求修改就好了，都是比较简单，就不细说了。
后台赋值的时候修改title为position。
分页显示这个问题实际上还没有很理想的对策（能力还不够），目前只是调整了下每页显示的最大数。
导师列表的显示顺序这个是由于字符编码问题，由于数据库编码是utf8,但是是按照导师名称（即中文，也就是gbk）,order中加入 using gbk即可。
弹窗样式这个问题是最最最最难搞得了，由于自己之前比较少用到接口，所以对前端调用接口显示这部分不大理解，昨晚和队友百度到很晚似懂非懂地找了些方法（主要是改写alert这样的）。今天想说自己试着修改一下alert的样式，发现好难啊啊啊啊，最终在立昊大神--前端大神的帮助下总算是把弹窗搞定了！！
心得体会
- 测试一步、BUG一步。。。。。。
- What I Can Say??
- 虽然BUG很多，但感觉自己变得耐心很多，特别是那次改需求之后，基本上是把6个页面重新写 了遍，变得特别耐心，之后遇到BUG就没有那么烦躁了，反而觉得是有东西可以学习了呢~
- 我真棒！
- 真棒！
- 棒！
- ！
031402337 胡心颖
- //我写的代码怎么可能会有BUG
- 感觉系统虽然看上去已经做完了，功能也很完善，可是测试的时候才发现到处都是BUG，还有很多要改的。测试过程基本是做一步改一个BUG，然后继续测继续改。而且程序员之间有的地方没有沟通好，因为每个角色之间都有点或多或少的联系，有的地方没考虑周全就会影响其他功能。
