03月27, 2014

测试感想之新人篇

从13年9月份到现在,做测试工作已经有半年多了,也接触了不同类型的业务,其实最开始我对测试并没有太多了解,只是在某次软件工程课上,听到了一些关于诸如白盒、黑盒的测试理论,仅此而已。后来,当我找工作之前,也看过些诸如怎样测试一个杯子的问题。当时我就想,一个杯子嘛,还要怎么测试啊,看它是啥样的呗,能不能装水啊,装热水还是冷水啊,会不会漏啊,容不容易倒啊,会不会摔坏啊,拿着会不会烫啊,想了几条,实在是没想法了,打开网页一看傻眼了,着实吓我一跳,一个简简单单的杯子,能有这么多测试?当时那作者把一个杯子的测试分了好几类,例如什么功能测试、性能测试、界面测试、安全测试,还有什么更奇怪的可用性测试,听都没听过,我看了下他的测试内容,从能不能装水或者其他液体,能装多少,刻度表,泡茶、咖啡,放冰块,材质,到外观的各种角度,放到国外会不会有种族歧视的语言,到装特定温度的水、涂料、颜色,到是否有毒、容易爆炸、摔打是否破碎,到内壁材料,长不长细菌,水好不好喝到,有没有防滑措施,有没有缺口会划破嘴(我当时想,这是人才啊,想的真够多)等等等等,看了半天,发现虽然是各种诡异的测试,但貌似个个都合情合理啊,唯有无尽的佩服,佩服,人家一不小心,就写30多个所谓的test case,而我绞尽脑汁,也只写了不到10个,再写下去自己都感觉在无理取闹了。

后来,到了公司,自己也开始做测试工作,最开始是云盘,也不外乎那些上传啊下载啊之类的,不停地点点点,但是好像测来测去还是觉得测的比较片面,突然想起那个杯子的故事,发觉测试光点点点是远远不够的,最主要的,其实用例设计的好与坏、以及用例覆盖的广度,太能说明一个测试工程师发现问题的能力了,接到一个项目,先不要盲目地点点点,要想清楚怎么来设计一些好的用例,而这绝非简单的事情,也不是一朝一夕就能积累沉淀起来的。至此就开始向那位“杯子”前辈学习,努力开阔思维,虽说之后思维还是比较局限,但相比之前已有很大提升。后来,在测完另一个web项目之后,进行了一次用例评审,又一次深刻地发现自己知道的还是太少了,用例覆盖的还是不全,这次知晓了,其实对于web测试,有太多的通用测试用例,是适用于任何web页面的,例如tab键、回车键的使用、各种分辨率的显示、文本框的前后空格以及中间空格,还有其他各种控件的相应操作,都是有章可循的,又一次丰富了我大脑中的用例库。再后来,测360联盟的的时候,涉及到了后台数据,又发现,其实在测试的过程中,是很需要掌握开发技术的,例如,我们需要写测试脚本来生成所需要的数据,而这些数据如果人为造是不可能的。再比如,有的同事会利用程序来帮助进行UI级的以及接口级的自动化测试,而这些自动化的程序可能是java写的,也可能是php写的。

从一开始的认为测试比较简单,到现在的认为做一个好的测试工程师绝非易事,需要付出极大的努力以及需要各方面的综合素质,相信是任何一个测试工程师在工作过程中所必须经历的转变。测试之路不容易,入门看起来很简单,但想要做好,很难。有的人很容易就会发现问题,而且还能重现;不仅重现,还能找到重现的最短路径;不仅能找到最短路径,还会排查问题的原因,以及想到可能存在的其他问题;不仅这些问题都想到了,还会一针见血地写出bug的描述以及步骤,开发一看就心知肚明;开发修完bug之后,他们能及时地做好回归,并且能保证没有引入其他问题;他们测试完成之后,能精准地对系统做出很有效的分析以及确定可能存在的风险;而且正因为这样,开发对他们的认可度非常高;他们设计的用例非常全面,且基本没有冗余;他们对产品的理解,甚至比PM、RD还要清楚……再想想我们自己吧,我们又做到哪些了呢?可能,我们在提交bug的时候,绕了半天才绕到问题点上,却不是最短路径;可能,开发看了我们的bug描述,一头雾水,还得反过来问你;可能,我们设计的用例有太多冗余,却没有覆盖到应该覆盖的点;可能,当我们都已经测完了整个系统,还不知道这个系统是用来干嘛的……

对比一下,就可以看到,做一个好的测试真的不容易。那么,该怎样提高自己?作为一个新人,其实要做的,就是从小事做起,把小事做好。多想想怎样测试才能保证产品的质量,因为这就是最终的目的,然后才是具体的方法;要给自己排期,在规定的时间内完成测试任务,这也是执行力的体现;经常思考一下,我们在平时哪些做的好,哪些做的不好,为什么不好,怎样改进;不知道自己需要学习什么,那么就看自己目前缺少什么;迷茫的时候,就把眼前的事情做好,想太多,没用的。

说了这么多,也该结束了,最后,借用网上某位前辈老兄的话来共勉——心沉下去,bug才能浮上来。

本文链接:http://blogs.360.cn/post/测试感想之新人篇.html

-- EOF --

Comments