对web系统的测试总结

很荣幸，刚进公司没几天就参与了一个web系统的测试，对于刚毕业的我来说，我能做的仅仅是功能测试及简单的性能测试，不过这也正是公司所需要的。

由于这的的确确是个小公司，测试人员都只有我一个，这个系统又是在开发人员边调研边开发的过程中测试的，所以没有明确的功能式样书，更没有写好的use case，所以，一切都是学习的目标。不过还好，这个系统才刚刚开发不久，功能业务还比较少，在开发人员给我讲解后，我又进行了一些对系统的熟悉操作，对该系统有了一个客观的认识了，开始写use case了，我把这个系统按照管理员角色分为三大类，又把每一个大类中的每一个菜单模块分成一个大项目，每个大项目又分为添加、修改、删除、查询等小功能，我把这个就称之为测试的最小单元了，我想，这就是所谓的单元测试吧。

在这个系统边调研边开发的过程中，bug是少不了的了，比如添加功能不好使啊，删除功能报错啊，修改功能提交不到数据库啊，不支持模糊查询啊，等等，这都是每个系统在开发过程中的必经之路，毕竟，像这种等级高的bug不可怕，可能不用专业的测试人员就能测试出来，可怕的是等级低的bug，如果不懂系统的功能业务，不懂系统的总体流程，一味的瞎点乱点，恐怕这辈子都遇不到，即使偶然遇到了，也记不得是怎么把它给遇到的，一个找不到bug再现步骤的测试人员根本不能称之为测试人员。这种B/S结构的系统测试还好，我觉得应该很少存在有在线率不为5/5的bug吧，反正系统也是比较小，至今我是没遇到，像现在我们用的android手机，平板电脑，应该都遇到过这种情况，比如电话突然关机，但咱不懂它的功能业务，也许在线率也就1/100，作为手机的主人也不希望它再出现一次，所以也就不了了之了，但测试人员可不能这么想，一旦遇到，就不能轻易丢下一个bug。（哦，对了，可能每个公司对于bug的等级分类不同，根据我以前的实习经历，我把bug分为4个等级，1~4级，damage逐一降低，1级bug：影响主功能业务链；2级bug：影响分支功能业务链；3级bug：影响非功能业务链；4级bug：UI显示问题及用户体验问题）在这里，我总结了几个我印象比较深刻的bug，希望给今后的测试工作提个醒儿。

（1）课程修改：点击某课程后的【修改】按钮后，会有修改的弹出式窗口出现，修改内容后点击【提交】按钮，一个提示信息“修改成功”出现后又飞速消失，且该弹出式窗口不消失。

修改后经查询，该课程内容确实被修改，但会给用户造成不便，首先是那个“修改成功”的提示信息飞速消失，在用户不知情的情况下可能就容易被忽视掉，然后是弹出式窗口不消失，这是在用户已经被误解之后的又一次杠头一棒，用户会认为没有修改成功，于是不知所措。给用户的操作带来不便就是bug，哪怕它只是个等级为4的bug。

认识：对于这种等级低的bug来说，必须得站在用户的角度边思考边操作。

（2）修改试题：在试题列表页面点击任意试题后的【修改】按钮后，在修改页面修改试题所属题库/题型/章节/题分/题干，修改后点击【提交】，回到试题列表页面，发现该条记录没有被刷新，需要手动刷新后才显示修改后的内容。

认识：通常在试题数目较多且相似的情况下测试时，需要记清试题的ID号，边记边操作，以免将与其它条目混淆。

（3）教师评阅：（前提介绍：学生提交作业状态可分为两种，一种是阶段性提交，代表试卷未完成；一种是终结提交，代表试卷已完成；教师能够评阅的学生试卷记录一定是学生终结提交后的记录）但在该功能初始之际，学生阶段性提交作业后，评阅教师依然可以看到学生作业记录，这虽然是个等级很高的bug，但并不是一个很好测的bug。因为人脑正常的测试顺序是：学生角色：终结提交作业‚教师角色：查看评阅记录。（把测试的着重点已经加到了这两个方面；）ƒ学生角色中有四条考试记录，其中三条为终结提交，一条为阶段性提交④教师评阅页面发现有四条记录，由ID查询出一条为阶段性提交，经过验证后bug产生。

认识：测试多种角色中的功能时，要勤切换测试，每一个细节都可能是bug的产生点。

待续......