031302620马凛凛（队长）
测试工作安排：
陈俊达：数据库结构测试；
吕昆明：页面显示效果代码测试；
汪毓顺：php功能代码测试；
马凛凛：模块整合测试
以上为项目冲刺初始时指定的测试分工，具体实施时根据实际情况作调整；
测试工具选择应用：
马凛凛：模块整合测试
页面显示效果测试：chrome浏览器
php功能测试：手动
模块整合测试：手工整合
由于我们组采用的web代码基本只包含一下几类：html、css、js和php，其中页面语言只要用chrome和firefox浏览器自带的f12开发者工具测试即可，而php语句由于涉及的基本是web开发和mysql部分，因此基本错误类型都采用手工检查的方式进行测试，具体测试情况和样例见后文。
测试用例和文档：
1.数据库模块测试
这个模块要测试的主要是数据库的表结构、字段属性、以及数据关系。
· 数据表的结构和字段属性主要靠人工检查和输入一些简单数据进行测试，比如：
像账号这样虽然是由纯数字组成的，但是必须设置为字符串类型，避免前面的0被去掉。再比如像备注这类的字段，要设置200以上的长度以保证不会因为用户输入过长而在存入数据库的时候被截断。
· 数据关系的检查包括表的主键、外键依赖、索引的检查，可以借助phpmyadmin直接查看。
主键：
外键约束：
2.页面显示效果测试
· 页面的显示效果测试主要是检查页面中的导航、按钮的样式，以及表格生成的位置和格式，还有对于动态接收的内容做判断（比如如果某张表目前没有数据那么要自动显示一个“暂无结果”）。
3.php模块测试
php模块主要包括登录、插入数据到数据库、从数据库读取数据到页面、导入文件、导出文件这几类。
主要测试方式就是手动验证功能，比如登录功能要验证：
1.使用正确的账号密码会跳转到对应页面
2.使用不正确的账号密码会弹窗提示
3.在sql中执行的结果可以随时输出以便查找错误。
4.模块整合测试
这类测试是用在某个功能模块基本写完之后统一进行的测试，通常测试方式就是模拟用户进行试用，比如模拟教学办身份进行登录->查看报课情况->修改身份信息等等一整套功能的验证，这样的测试是很有必要的，下面举一个我们在过程开发中 碰到的实际情况：登录时的账号密码不严格匹配问题。
情况描述：在测试登录功能时，使用账号：1和密码：1可以登录，并且显示的是数据库里账号密码为00001的用户身份信息。
起初认为是数据库模块问题，安排人员进行变量类型检查，确认类型无误；
接着判断是否是phpmyadmin允许宽松匹配，在后台的sql中验证：
然后考虑从数据库取出数据到页面的时候是否被强制类型转换，echo到页面，同样发现没有.....
排除了种种可能的情况，最后不得不怀疑：难道是登录的php代码写的不对，（为什么是不得不怀疑？因为之前进行的登录时账号验证是可以成功的，并且用其他不存在的账号密码验证也是可以正常报错的，因此习惯性认为没错）
打开代码，如下：
看起来也没有什么不对，然后只能继续缩小范围：难道php中两个等号是宽松匹配，于是写了两行简单的判断，结果发现。。。。。。。果然是这样的！！！！
接下来问百度，才发现，php里面字符串的严格匹配要用===，三个等号才可以。。。（--！bug原因：程序员基础太差）这个例子是为了说明，每个模块就算在各自测试的时候可能没问题，但是整合在一起的时候还是可能出现新 的问题，另外一个典型的例子就是读取前后的乱码问题，在各自模块都可以很好的中文显示，但是在发生前后端数据交换的时候会生成乱码。
测试方式： 各部分负责人即时测试，写到哪测试到哪；
整合测试人员在其他人提交完一个模块后，测试一个模块；
在全部模块都测试完毕，进行最后的试用测试；
测试进展： 与项目进展同步
测试体会： 测试方面最有用的就是经验，碰到问题就要记下来；
测试思路：首先猜想可能发生的所有原因，然后不断排除，缩小范围，直到找到最终原因；
测试的时候尽量减少思维定势，有时候半天找不到问题最后才发现是自己账号输错了。。。。--！
测试评述： 显然，我们组的测试有一个很大的特点--技术落后，基本处于手工测试水平，没有用到各种单元测试工具。（之前尝试使用过，效果一般，花的时间却比手工测试长的多）
从多个方面进行测试，并且有部分测试和模块，这个算是优点。