OBJECTIVE
我们的目标呢，就是经过测试之后软件的质量得到有效的保证，在已经考虑到的所有场面都可以“Hold住”。
As much as I concern，
1、所有设计中的功能都能实现
2、代码经过review
3、用户界面经过用户的试用
4、系统的反应时间可以忍受
5、发现的bug或者都已解决，或者下一个iteration解决
6、各种极端情况都可以Handle
7、数据可靠
8、Last but not least， 不存在版权问题
下面我们详细说一下各个部分。
1、所有设计中的功能都能实现
UI在开发之前就是有设计蓝图的，所以具体应该实现什么功能是非常确定的，这个也比较方便检查。UI开发人员在完成开发的时候就可以确定这些功能是否都已实现。为了减少差错，可以再由测试人员进行double check。原始的用户也可以报告bug。
2、代码经过review
为了提高代码质量，review是非常有必要的。既是对代码的double check，也验证了写出的代码确实能够比较容易地被今后的维护人员读懂。
3、用户界面经过用户的试用
这个在1中已经阐述。
值得提出的一件事就是，关于国际化（Internationalization的测试），即使保证我们的产品也可以被全世界的用户可以方便使用。除了界面的文字语言问题，还涉及到东西放思维差异等等。
比较幸运的是，我们的开发人员中就有一位欧洲瑞士的同学，我们的Daily Scrum也是使用英语的。从而使得我们的产品和国际化并不遥远。为了保证这方面的质量，还可以找一些国际友人来进行使用并反馈。
4、系统的反应时间可以忍受
在去年的一个版本中，查询和反应时间非常缓慢，到了一种难以忍受的情况。
所以今年我们要格外重视这方面的情况。
具体在做好了之后，我们会在不同的网络环境（公司内部、北京市电信网络、美国雷德蒙德总部网络、安徽合肥中科大教育网络）进行使用测试，确保我们的反应时间得到用户满意的迅捷成都。
5、发现的bug或者都已解决，或者下一个iteration解决
测试的阶段不可避免要发现很多bug，发现bug多不是坏事，发现的少也不一定是好事。
关键的是，尽可能暴露出所有存在的问题，并且尽我们最大的努力进行改进，fix the bug.
6、各种极端情况都可以Handle
各种边界条件往往是出问题的地方。
在我们beta版本上周刚刚demo，在准备数据的过程中我们就特意准备了各种极端条件的数据。
比如说：
A）老师数量为0， 或学生数量为0
B）老师数量最多（4）， 学生数量最多（79）
C）还有学生分属很多不同的工作机构的情况
确保我们的系统在不同情况下都可以得到一个比较美观、可靠的界面。
7、数据可靠
我们所挖掘到的师生关系对是需要经过验证的。
暂时由于数量庞大，而我们人员有限，往往采用抽样人工验证的方法。
在条件具备的情况，我们会编写脚本、测试程序等对关心的内容进行机器验证。
8、Last but not least， 不存在版权问题
确保我们的代码都是原创，或者没有使用本公司外的代码。
