两年测试经验总结

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

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

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

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

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

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

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

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

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