测试工作杂谈

随着新版本的上线,这个阶段的测试工作暂时告一段落,闲暇之余,不禁对测试团队的工作方式产生了一些想法,先写下来,当作是一次总结吧。

IT从业者,不论是运营人员、需求分析还是程序员,都应该对测试不陌生吧。测试工作,尤其是黑盒测试,在他们眼中,不外乎点点鼠标,操作操作界面,是一项挺没意思的工作,做测试的都挺无聊的(不无聊,谁没事净干点鼠标的活啊),跟开发不在一个层级上。怀着对开发的敬畏,对测试的蔑视,对测试本质的理解,也是渐行渐远。

测试就是点鼠标

第一次听到这句话,我和我的小伙伴们都惊呆了,心脏猛跳了几下,血液循环也加快了不少。可笑的是,当时的我根本不知该如何反驳,对于这样的冷嘲热讽,只能无言已对。那段时间,所谓的“猴子测试”也被大家熟知,想一想平时的工作,嘿,还真像只猴子。当然,像也只是工作方式上与猴子的行为接近,我本人还是一个正常人类的,若不然,猩猩都要称霸世界啦。

如今,回过头再看这句话,是没有丝毫道理的。跟吃饭就是张嘴,走路就是迈腿一样,废话而已。单单说的是必然会经历的动作,忽略了深层次的思想活动。测试技术经过多年的发展,已经形成了一套非常完善的方法体系。测试计划、测试方案和测试用例,成为了测试人员的三大法宝。那敢问,做好了这些,就可以高枕无忧,一劳永逸了吗?答案,是否定的。

我一直认为,测试的精髓在于测试过程中不时闪现的灵感,对测试用例的扩展与改编,就像是拍电影是演员的现场发挥,临时增加的剧情,往往会取得出人意料的效果。有人会问,测试用例难道就不重要了吗?要知道好的用例可以发现所有的BUG。先不论测试用例重不重要,我想,世界上没有谁敢说他的测试用例可以发现所有的BUG,也没有哪一款软件产品敢说完全没有BUG,微软不也是经常通过补丁修复BUG吗。

当然,这不是否认测试用例的重要性,我本人也一直在认真的设计测试用例。只是,我设计测试用例的时候,只写一个业务流程,提供一个大体的方向。要知道,在现今的大环境下,开发周期变短,很多项目都通过压缩测试时间的方式来达到快速开发,往往一个版本留给测试的时间只有一周不到,要在这么短的时间里,执行完成百分之百覆盖的用例,我想,除了“少睡精英”,也不会有其他人了吧。如果用例只是提供测试的方向,例如业务流程这样,那就可以从基础的流程入手,根据自己的感觉(测试人员的感觉有时比专业更重要),逐渐覆盖可能产生BUG的模块。这样,在实际的测试过程中,会不断的有灵感闪现,往往会找到用例中没有考虑到的点,比依葫芦画瓢执行用例要好的多。

灵感这东西是需要状态的,我们必须在一段不受打扰的时间里达到“入定”的状态,接着就需要更长一段免打扰、完整的时间。其实,测试跟开发一样,都是逻辑性要求很高的工作。一次无关紧要的会议,一封不痛不痒的邮件,哪怕是一句善意的问候,都会打断思维,让我们从入定的状态中醒来。而这种一旦从“入定”的状态中脱离,想要再次进入,自然是难上加难。

可以预见的是,在实际的测试过程中,肯定会产生很多的BUG,怎样处理这些BUG,什么时候解决,什么时候发布补丁都是需要经过深思熟虑,考虑到测试团队的工作习惯而制定的。我的建议是对于Block级别,引起系统崩溃,流程不能执行的BUG,应立即解决并迅速发布补丁。其实,这种级别的BUG不应该在系统测试阶段出现,而应该在白盒测试及开发联调阶段发现并解决,这样的BUG会严重影响到测试工作的流畅性和“入定”状态的持久性。对于其他级别的BUG,应实行统一提交和解决,可以规定每天下午1点、5点是提交BUG的时间,这同时也是打补丁的时间(只是参考,具体时间可以根据项目情况而定),大家也知道打补丁需要重启服务器,如果频繁的发布补丁,会对测试工作造成严重影响。例如,正在测试某一功能突然提示不能连接服务器,特别是那种需要做很多输入的表单类操作,我想,大部分人都想拍桌子骂娘了吧。这样可以保证测试人员有两部分完整的免打扰工作时间,对效率的提升是显而易见的。

当然,测试工作的开展与观念的传播离不开整个团队乃至整个社会的支持,只有大家真正树立起对测试的正确认知,QA这个称呼才能实至名归。

也许,这一天就要到来了吧。

你可能感兴趣的:(工作)