两年测试工作总结

    测试工作,有轻松的时候,也有繁忙的时候,但总的来说忙大于轻松。记得刚上手测试时,不知道从何下手?产品的操作手册和命令手册,最基础的DD,却是新人最好的参考资料;产品的操作手册和命令手册面向的就是用户,对于新产品,用户也是新人;产品资料,不仅仅是告诉你怎么使用它,里面还包括很多概念的阐述,功能的简介,和部分实现方式;对于测试来说,都是很重要的资料.

        看产品资料的同时,也要学习产品所基于的协议,标准之类的;协议,标准阐述了功能的实现方式;在动手测试之前,需要有一定的了解.此时,不需要深究;以后随着测试的深入,自然而然会有更深的理解.

        当中,还应该初步掌握测试平台,测试工具和测试方法;不然开始工作时,那些测试工具会让你傻眼;虽然当你会用后是贼简单的DD,但是没有用过却是不怎么好用的DD!

        新人上手后,会经历这样的一个过程:自己测试的模块怎么问题很少,而其他同事复杂的模块的问题那么多,为啥呢?实际上是这样的吗?答案是否定的!因为新人刚开始,对产品的熟悉程度还不够把产品里隐藏较深的问题发掘出来;还有,毕竟是新人,还没有形成适合自己的一套测试方法和测试理论,这些都是需要通过长期的经验积累和总结才可以形成的.这时,新人可以查看前辈们的问题单,看看前辈们是怎么样进行测试的,他们的测试过程,方法是怎么样的?对于新人来说,问题单是很多的学习资料.对于自己的测试方法和理论的形成有促进的作用.

        之后,信任就开始了漫长的测试执行阶段.测试是具有重复性的,相同的功能模块,相同的产品测试久了会有厌倦的心理;这时需要适当的调整下.可以和同事换模块测试;不仅可以避免测试的重复性,还可以学习新的技术,而因为人与人之间的测试方法和测试理论总是不一样的,一个模块让不同的人来测试,可以测试出不一样的问题来,对于产品的测试,更有覆盖性.

        而后,等测试时间的增长,测试人员除了测试执行外,其他测试工作会越来越多:测试设计(测试点,测试用例的写作)、外对测试用例的协作、各种开发\测试文档资料的评审、对外测试支持、自动化脚本的写作、实验局开局等等;虽然这些工作对于测试执行来说,没有了相对的重复性,但是这些工作的难度或者说是复杂度是大大增加了:因为测试执行只需要跟着测试点跑功能就成,而后面的这些,可没有那么简单.就举对外测试支持来说,外面运营商或是产家的测试注重实际运用的测试,而新研发出来的产品在公司内部注重功能测试,当然也是注重实际应用的;可是是新产品,外面还没有大规模应用的情况下,相对来说,实验室的测试和外面的测试差距还是蛮大的,所以需要测试人员反应要快,能够在短时间内搭建好测试平台和测试环境,对对面突发性的测试需要进行验证;如果在产品不支持的情况下,需要研究出其他的解决方案来满足外面测试需要的功能.

        对于测试人员来说,在测试过程中,或多或少总是会发现一些不是必现的问题.对测试人员来说,需要把问题出现时的现场在问题单中描述的很清楚,(配置文件,操作过程log,流量的类型和大小等等)而且尽可能的对发现问题进行复现操作,当然这个过程也需要把握时间,因为测试版本的时间本来就是比较赶的,不能消耗过多的时间在复现问题上.当整个版本在该论测试完成后,可以考虑集中时间对不能重现的问题进行复现工作.而在复现工作过程中,可以开发人员进行交流.因为开发人员对于产品实现的流程比较测试人员要熟悉,一般来说开发可以提出一些很有价值的观点,有利于问题复线工作.

        测试产品时(测试资料,评审文档),测试人员需要带着怀疑的观点去测试,这个观点往往对于测试新人来说,是比较困难的.新人很容易是带着去验证的观点去测试(总是认为产品,文档资料都是正确),所以发现的问题比较少;当如果换个角度,采用怀疑的观点去测试时,会发现很多原先没有发现的问题.特别是一些设计方面的问题.虽然功能是没有问题的,但是实现的过程或是方法却不是最优的,这些问题是新人很难发现的,当然也是需要一定的经验积累的.

原文转自：http://www.ltesting.net