测试工作,有轻松的时候,也有繁忙的时候,但总的来说忙大于轻松
记得刚上手测试时,不知道从何下手?
产品的操作手册和命令手册,最基础的DD,却是新人最好的参考资料;
产品的操作手册和命令手册面向的就是用户,对于新产品,用户也是新人;
产品资料,不仅仅是告诉你怎么使用它,里面还包括很多概念的阐述,
功能的简介,和部分实现方式;对于测试来说,都是很重要的资料.
看产品资料的同时,也要学习产品所基于的协议,标准之类的;
协议,标准阐述了功能的实现方式;在动手测试之前,需要有一定的了解.
此时,不需要深究;以后随着测试的深入,自然而然会有更深的理解.
当中,还应该初步掌握测试平台,测试工具和测试方法;
不然开始工作时,那些测试工具会让你傻眼;虽然当你会用后是贼简单的
DD,但是没有用过却是不怎么好用的DD!
新人上手后,会经历这样的一个过程:自己测试的模块怎么问题很少,而
其他同事复杂的模块的问题那么多,为啥呢?实际上是这样的吗?答案是
否定的!因为新人刚开始,对产品的熟悉程度还不够把产品里隐藏较深的
问题发掘出来;还有,毕竟是新人,还没有形成适合自己的一套测试方法
和测试理论,这些都是需要通过长期的经验积累和总结才可以形成的.
这时,新人可以查看前辈们的问题单,看看前辈们是怎么样进行测试的,
他们的测试过程,方法是怎么样的?对于新人来说,问题单是很多的学习
资料.对于自己的测试方法和理论的形成有促进的作用.
之后,信任就开始了漫长的测试执行阶段.测试是具有重复性的,相同的
功能模块,相同的产品测试久了会有厌倦的心理;这时需要适当的调整下.
可以和同事换模块测试;不仅可以避免测试的重复性,还可以学习新的技术
,而因为人与人之间的测试方法和测试理论总是不一样的,一个模块让不
同的人来测试,可以测试出不一样的问题来,对于产品的测试,更有覆盖性.
而后,等测试时间的增长,测试人员除了测试执行外,其他测试工作会越来
越多:测试设计(测试点,测试用例的写作)、外对测试用例的协作、各种
开发\测试文档资料的评审、对外测试支持、自动化脚本的写作、实验局
开局等等;虽然这些工作对于测试执行来说,没有了相对的重复性,但是这
些工作的难度或者说是复杂度是大大增加了:因为测试执行只需要跟着测
试点跑功能就成,而后面的这些,可没有那么简单.就举对外测试支持来说,
外面运营商或是产家的测试注重实际运用的测试,而新研发出来的产品
在公司内部注重功能测试,当然也是注重实际应用的;可是是新产品,外面
还没有大规模应用的情况下,相对来说,实验室的测试和外面的测试差距
还是蛮大的,所以需要测试人员反应要快,能够在短时间内搭建好测试平台
和测试环境,对对面突发性的测试需要进行验证;如果在产品不支持的情况
下,需要研究出其他的解决方案来满足外面测试需要的功能.
对于测试人员来说,在测试过程中,或多或少总是会发现一些不是必现的
问题.对测试人员来说,需要把问题出现时的现场在问题单中描述的很清楚,
(配置文件,操作过程log,流量的类型和大小等等)而且尽可能的对发现
问题进行复现操作,当然这个过程也需要把握时间,
因为测试版本的时间本来就是比较赶的,不能消耗过多的时间在复现问题上.
当整个版本在该论测试完成后,可以考虑集中时间对不能重现的问题进行
复现工作.而在复现工作过程中,可以开发人员进行交流.因为开发人员对于
产品实现的流程比较测试人员要熟悉,一般来说开发可以提出一些很有价值
的观点,有利于问题复线工作.
测试产品时(测试资料,评审文档),测试人员需要带着怀疑的观点去测试,
这个观点往往对于测试新人来说,是比较困难的.新人很容易是带着去验证的
观点去测试(总是认为产品,文档资料都是正确),所以发现的问题比较少;
当如果换个角度,采用怀疑的观点去测试时,会发现很多原先没有发现的问题.
特别是一些设计方面的问题.虽然功能是没有问题的,但是实现的过程或是方法
却不是最优的,这些问题是新人很难发现的,当然也是需要一定的经验积累的.