测试之新生入学系统，多一份收获

	整个五月份，除了本身的计算机学习外，还参与了基础部评教和ITOO测试工作。也正是因为这两项活动，才让自己真正感受到天天都要开会是个怎么样的感受。下面就将这段时间在ITOO测试的学习情况总结总结，其中也是学习到了很多自己在计算机学习中学不到的一些东西。
	其实，最开始的工作只有ITOO测试组。等到五月中旬，基础部评教开始招人，自己报名参加了，工作也相继开始了。这一篇博客是把ITOO测试组的学习情况写写，在下周评教后，会再写写在基础部工作的一些情况。
	ITOO，这也是第一次接触这一个系统。之前虽然听师哥师姐们经常说高校云平台，但它的庐山真面目自己是从未见到过。这一次，这么好的一个机会，还可以让自己选择想进入哪个系统，说什么也不能错过吧。就这样，自己进入了ITOO的新生入学系统，参与之后的测试工作。
	看着这样简约而不简单的界面，我彻底地被ITOO吸引了。看到原型，就开始一个一个点。

	一个原型，整个一遍点完，也花不了多长时间。但自己点完一遍后的感受就是不想再点第二遍，很大一部分原因是自己不了解系统中的很多业务需求问题，就好像是跟着系统跑完一遍流程结束了，任务终于完成了的感觉。
	所以，紧随其后的任务就是对自己负责的系统的需求进行了解和分析，也是为了后面写测试用例做好一个准备。下面自己就这段时间的学习划分为下面几个阶段，和大家一起分享。
	其实，新生入学系统的需求可以拿我们自己来廊坊师范学院报到作为实例，但我们想的也不能仅仅只是局限在我们学校的报到流程，至于为什么，后面会再给大家提到。
（一）新生入学系统测试之需求初识
	一个学生，不管有没有来报到，学校都是会有一份该学生的信息。后面的一些需求分析，都是以该生来到该校报到的情况为前提。
	从该系统的角色来看，共有两类，一类是学生，另一类是管理员老师。
	对于学生这一角色的用例，我是从他整个报到流程来看的。前期，学生必须核实并且完善自己和家庭的信息，在学校的相关条例上签字，选择办理相关的保险等业务。后期，主要是管理员这一角色的业务。例如：分配学生宿舍、学号和班级等。
	对于学生报到问题，我们学校是自己来学校报到的，而有些学校早已可以在上网进行报到了。所以说，有这么一个新生入学系统也是大势所趋啊。对于宿舍问题，我们学校是早已安排好，而有的学校是可以自己选择的，所以，在两个角色下都有宿舍用例，学生可以自由选择，老师负责分配宿舍。这也是我们做系统时不能仅仅局限于我们报到的情况的原因所在。
（二）新生入学系统测试之测试用例初识
	在了解一些基础的业务后，我们要开始学着写测试用例。对于用例，大家都并不陌生。做完机房收费系统，学习了UML，我们都知道画了至少两遍的用例图。而对于测试用例，这还是头一次接触。我理解的就是在做系统测试的时候，你用什么条件去测试系统，这样的话，条件就是测试用例。
	对于测试用例，张薄师姐给我们上了一堂完整的课，跟随师姐的博客，其实测试用例并不像自己想的那么简单。详见师姐博客：《测试用例》。上完这堂课，才知道测试用例原来是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
（三）新生入学系统测试之需求再分析
	编写测试用例的前提是你对这个系统的需求已经了解的非常清楚。你知道整个系统的流程是如何走下去的，你甚至应该知道写怎样的用例可能会测试出系统的Bug。所以，在对照各自的系统原型下，师姐给我们各个系统讲了一遍系统需求。这一遍，不仅仅是深入了解，我们也需要用批判的眼光去分析。也许系统原型存在某些需求上的不足，也需要我们去发现，提出。
	比如我们负责的新生入学系统，原型图中学生管理下一半的页面都是关于宿舍的这一问题。在线选择宿舍、宿舍、宿舍楼、学生自选宿舍首页等，这看起来名称都有所重复的页面，实际上，功能上也没有达到良好的效果，反而从我作为一名学生来看，选择一个宿舍如此复杂，我还是比较愿意等到了学校再说，而不愿意花费那么多的时间看着与实际环境不符的地图进行选择。这样，系统开发人员就需要再把学生宿舍选择的这一需求好好分析，从而做出些改善，更多的想想用户。
（四）新生入学系统测试之编写测试用例
	对需求又一次了解后，我们就需要开始编写测试用例了。第一次编写，也不知道该怎么做，虽然手里有师哥发给我们的一个模板，但感觉还是无从下手。第一次总是开头难的，第一次也是需要动手去做的，在必须交上一份测试用例的压力之下，自己也是决定还是再一次打开原型，照着模板开始写了。
	我们小组的组长聚哥很是负责，在晚上就召集我们几个写完第一份测试用例的我们开了一次简单而充实的会。自己也从那次会上知道了自己写的测试用例有哪些值得认可和不足的地方。其实，测试用例并没有自己想的那么难的。也许，刚开始我们都是写的很浅层次上的东西，比如文本框输入特殊字符或空值时，会有怎样的预期结果。但这样一个过程是我们成为后期可以编写专业的、高难度的测试用例的一个必经之路。
	记得在一堂课上，王静娜师姐给我们讲了一个她看的一个比赛，规则是比赛分为几个环节，累计加分，前面的几个环节下来，有一个排名。最后一个环节是写测试用例，最后获得冠军的选手就是赢在了这一环节。他前面的表现并不特别出彩，但最后因为他写的测试用例测出了别人程序的很多Bug，所以，最后他反败为胜。
	可见，编写测试用例也是一门值得好好学习和研究的技术。现在的我们，需要从简单做起，点点滴滴积累，才能有最后的成为冠军的可能。
（五）新生入学系统测试之工具学习
	等我们写好了测试用例，我们就需要开始下一个阶段提Bug的工作了。这其中就需要我们使用专门的软件工具了，这也是加入测试组的又一份收获。JIRA和禅道，这就是我们此次测试工作提Bug的两个工具。期间，也有专门的人员给我们专门讲过课，让我们知道了用这些工具，它们是如何对提Bug这一工作进行管理的，何时提交，何时关闭，如何填写，这都需要测试人员之间有着共同的约定。这一阶段的工作还没有真正开始，现在对于这两个管理工具感觉还是陌生的，等到后面真正开始用了，一定会是另一番感受吧。
（六）新生入学系统测试之学习心得
	从刚成立这么一个测试组到现在，由九期张薄师姐，十期王静娜师姐和牛迁迁师哥带着我们十一期的二三十人，很认真负责的给我们安排每一次讲课，相信我们每一个人都会感觉自己收获了很多。师姐在我们刚进测试组的开会的时候就说过，进入了测试组就需要比其他人更多的了解一些有关系统测试的情况。以后再接触到测试方面的东西，不至于自己什么也不知道。
	通过这段时间在测试组的学习，自己最大的感受就是测试也是系统开发过程中不容忽视的一个重要环节。有句话：打江山容易守江山难。那么用在系统开发这样一个场合，我觉得可以借用这句话：系统开发容易，维护系统难。这其中有很多工作需要做。
	此外，在测试组这一阶段的学习，如果没有进测试组的话，这些东西是在平时视频、书籍或者敲代码的学习中收获不到的。所以，这一次加入新生入学系统测试组，又让我多了一份收获，也让我多了一份动力与积极性，去参加其他的各种活动，每一次都是自己学习的机会。