我想要怎样的测试人员

    不知不觉在51的学习生涯已过了大半，乘着这会儿还未正式踏上测试行业的道路，来回想下过去5年作为一名开发人员的角度对于测试人员的看法和期望：

    1 不要想当然

    这点听起来很容易，其实是最难做到的。 很多做功能测试的（尤其是刚毕业的），总是喜欢凭着所谓的经验去测。 加上很多国内项目本身就缺少文档，于是不同的人对于需求的理解就会产生很多差异。 当需求不明的时候切记要多问（尤其是涉及业务流程方面的需求），这不是靠自己努力想象就能想出来的事情。 明确了需求再去测试会减少很多和开发发生矛盾的机会。

    2 缺陷描述要确切

    尤其是操作步骤（也就是重现过程）。 以前碰到过不少测试人员（甚至是一些有着2 3年经验的），不但缺陷描述写的不知所云，连操作步骤都懒得写，整天跑过来对我说：“我来操作给你看……”我想说:1 开发人员不会一直有空看你重现bug； 2 即使开发人员有空看你重现，也不一定有空马上改。等他有空想到要改了，多半早就忘了你是怎么操作的了； 3 如果没有对缺陷进行精确描述的话，别人找到相同性质的缺陷可能就会对该缺陷进行重复登记；4 ……（总之问题很多，后果很严重，目前暂时只想到三点）

    3 不要害怕提出bug被"rejected"

    有些测试人员总是觉得应该多提有技术含量的bug，有时候看到一些"小问题"会不好意思提或者担心提出了也没人改甚至是懒得提，这种想法是很要不得的。 当然，提bug要有充分的理由，想当然的也不行。 能够多提不同方面的bug不但对软件质量本身和对开发人员有好处，对自己也是一种积累和提高。 （顺便提一句：如果一家企业以new和被rejected的缺陷多少来进行绩效考核的话，建议换地方！）

    4 注意积累一点一滴的开发经验

    我一向偏执地认为没做过开发是做不好测试的，不过我并不反对没有开发经验的人直接踏入测试行业（否则没人做这行业了-_-）然而踏入测试行业只是个起点而已，除非你是愿意一辈子就做测试执行或者你认为自己是个monkey test的顶尖高手，不然还是多积累些开发的经验吧。 需求、设计、编码……什么都行。 对开发过程了解了，才能够对整个测试过程有侧重点，才能具体问题具体分析，才能真正做到见招拆招。 如果对开发过程一无所知的话，你所能做的只能是照搬测试理论。 （话说以后如果自动化程度高了，做测试执行说不定要失业了）

    其他的，什么责任心，沟通能力等等之类的我就不说了，外面类似的文章多了去了。

    另外，虽然是在说测试人员，但是很多方面（包括上面说的几条）对开发人员同样适用。 开发人员想当然的问题就不说了； 你说开发人员不需要描述bug？ 但是开发人员需要做需求分析，需要做设计，需要在代码里写注释。 很多人认为一些不称职的开发人员不写文档不写注释是因为不屑去写，其实这个想法通常是错的。 事实上，那些人是不会写。Joel Spolsky在给计算机系的学生提的7条建议中，第一条就说到：“要在毕业前学会写作。” (Learn how to write before graduating. 原文链接：http://www.joelonsoftware.com/articles/CollegeAdvice.html)； 开发人员一般不需要自己提bug，但是需要他们对整个设计架构及具体实现提出自己的看法，有的时候不要害怕自己没经验说错，设计做多了的人，很容易陷入自己的框架式思维当中去； 开发人员会不注意积累开发经验吗？ 当然会。 好吧，现身说法：其实我自己就有点这种趋势-_-