做测试快两年了,虽然我去年才毕业,但是在此之前我已经做了9个月的测试,毕业后才成为正式员工,之前的9个测试，我从一个测试新手进步到初级测试人员,十分感谢照顾我的老大,呵呵.
在我们公司,因为我们是做自己公司的产品,所以我们就不存在与用户沟通那些业务的事项啦.所以相对而言就不用折腾了,呵呵.当一个项目下来时,我们的测试leader会参与一个meeting,这个meeting会有PE,相关的developer,其实就是一群老大了,参与此会的目的,了解该项目的起始到结束的时间,参与的人员,该项目能实现的功能,若你是参与测试这边的测试人员,那么你只带了一双耳朵是不行,你首先要想到自己测试所需要的硬件及软件这一块是否充分,测试人员是否足够,若是不够的话,你就要说出来的,因为这些都会影响你测试的进度.所以在参加这个meeting前,大家一定要提前想想我们会遇到的问题,并且在会上适时的提出.
接下来,我们会有一个SPEC,这上面有该项目主要的功能,比方说我,我主要是测application,那么一般给我们的SPEC上会有安装方法及路径,功能实现,UI这些.那么这就是我们获得最重要的信息了,然后你会根据SPEC开始写你的Test Plan,Test Plan是真的需要经验的,经验越丰富的leader会能cover到很多场景的,这样会减少我们的风险.
对于软件的测试流程,我们会有两个阶段,第一个阶段我们称为beta阶段，第二个阶段我们称为RC阶段,可能每个公司说法不一样.对于beta的阶段，我们也可以分很多阶段的,如beta1,beta2,ect.但是在beta前,我们的coverage应该cover到了很多的场景,并且软件也是相对很成熟的,basic function是能正常工作的，当然,我们可能会遇到一些比较变态的bug,这时开发人员也解不了的,那不关我们的事,至于能否进入RC,还是老大们决定的,我们想管也管不了(测试人员身份尴尬的一面).进入RC的软件,一般都是相对稳定的,那么这时的测试着重点,就不在是basic function,这时我们的coverage要cover到我们没涉及到的场景,基本上在RC最好不要在出现很严重的bug了,在我们公司,要是在RC出现了严重的bug,是要挨批的(明明是开发人员开发出不好的程序,但是出现问题,是我们背黑锅的,这也是大家一直争议的问题,对于这个问题，我觉得若是我们在之前遗漏的bug,并且我们也做了那块的function 测试,若没发现，这部分挨批我们是可以接受的,毕竟我们自己工作的疏忽).若是软件很稳定了,就可以去认证了,我们公司都是拿到微软认证的.
拿去认证后我们的任务就大告成功了,呵呵.
