看了很多同行的日志。

　　成者有之，努力者有之，苦恼者有之，抱怨者亦有之。

　　很多人都在抱怨自己的测试工作没有头绪，比如说公司不重视测试，比如说测试系统的不熟悉而且没有人给他们相关的文档，比如说测试的不规范……

　　我们在当初学习测试理论的时候，都会理所当然的把软件生命周期，测试生命周期看成一个有序的规范的流程。其实流程化工程化的软件管理和软件开发测试流程也正是软件工程的目标。既然说是目标，是因为它跟理想其实还是有差距的。像我们的同行，包括我们自己在每个项目，每个公司遇到的测试环境一样。

　　大家都知道，测试介入越早越好，好在立项之后，需求分析之初介入到项目里面，跟着开发，需求的脚步，一点点排除阻碍，发现缺陷，保证“尽早测试”的顺利进行。但是实际上，我们这些人中，又能有多少真正的能从那个时候开始介入呢？不说有没有机会的问题，让你介入了，系统架构，需求定义，开发的研讨，代码的走查……这些环节你都懂吗？能从系统的高度给出多少有价值的建议和意见呢？

　　来自外企的同行，会有着跟我一样的抱怨，对于测试的流程的了解虽然是优点，但是我们没有全程参与的机会。大家基本是依照流程在进行测试执行，没有人有机会去触摸需求以及更深层的东西。来自国内企业的同行，会抱怨测试的流程不规范，测试中只是开发人员的附属，打杂的，什么都要干，什么都懵懵懂懂……

　　这其实是中国软件目前发展的现状。其实你看招聘信息能看得很清楚。但凡外企招聘，外语是第一要求，然后是测试经验，对于测试流程的熟悉和把握，测试工具，然后才是测试的其他技能比如说coding，db，protocol这些东西。而有些没有这些要求。但凡国内企业的招聘，基本没有外语的要求，主要的是测试的coding，db，protocol这些东西，然后是测试的经验，流程，工具，方方面面，不要一个神人誓不罢休。

　　等你信心满满的进入企业，你会发现理想和现实的差距居然如此之大。其实很正常。用看人的态度看待工作，一样有效。人无完人，工作也一样，不可能方方面面都能符合你的胃口。

　　对于现实中进行测试的我们，面对复杂的抑或烦乱的测试环境，能做的其实只有一点，尽我所能得去履行我的职责。

　　比如说，没有需求文档，我们可以把测试软件当成需求文档，尽快地去熟悉它的功能，然后自己寻找它的workflow，把握数据流向，然后，需要做的是，不要盲目的进行分析和用例设计。一定要把你了解东西跟开发和需求去确认。因为一旦你理解的方向偏了，你的努力将功亏一篑。确认之后，再进行测试用例的设计以及进一步的执行。

　　比如说你对业务不熟悉，公司也不重视，很苦恼……我觉得首先，你要检讨自身。为什么对业务不熟悉，有没有努力的去研究？虽然说人不可能一开始什么都懂。但是基于成本和效率的考虑，很多公司还是不会贸然把测试的重头戏放手给不懂得业务，不懂得规范测试的测试人员的。这一点，建议是，一定要把公司的被测产品学明白。从产品测试的角度来看，它的具体功能，它的业务逻辑，它的数据流……不知道的，自己摸索，摸索不明白的，去问开发和需求的。（不能打扰人家的工作时间，否则没有人愿意给你好好回答。多交一两个开发的朋友，茶前饭后的偶尔问问，大家应该乐意告诉你），然后利用你学习的测试方法，用开发人员不可能想到的测试策略来进行测试。如果有，你发现了很严重的问题，如果有，你的这种举动和测试的成果，对于开发，对于进程，对于产品的质量提高起到的作用越来越大了。你们的地位，作用，随之大了。

　　说句通俗的话，自己的地位是自己建立的，所以做事情之前不要攀比，不要盲目抱怨，首先要想的是，怎样解决现在的问题，打破这种僵局，让他们重视你。不是吗？

　　比如说开发的周期很长，但是给你测试的时间很短。怎么办？那你在等待测试的时间，琢磨你的测试软件。想办法了解测试软件的功能，掌握它的架构，然后运用你学到的东西，来分析我应该怎么入手测试，如何才更为有效？有人说，我没办法了解，没有机会。那么，只能说，你不善于跟开发的打交道。

　　做测试，一定要善于跟开发人员打交道，而且要交几个开发的朋友，大家一起工作，相互了解，经常沟通才能把彼此的工作做得更好。你可以跟开发的人员要些资料，可以问问他们开发的进度，可以到开发的环境下去了解一下测试软件的面貌，可以问问开发人员哪些模块比较复杂（便于你测试的时候重点关注），哪些模块比较重要（如果你却是无从所知）……经过前期的准备，当任务到手的时候，你自然知道轻重缓急，可以有的放矢的进行测试了。

　　一路走下来，你会知道，无论遇到怎样的情况，运用你的经验，技巧，沟通能力，都可以坦然地做好自己的工作。

　　发现自己不足的地方，要及时地学习，补充。发现自己跟开发很难沟通，听不懂他们说话，那么多沟通，没事多学点，总会好的~~测试是一门艺术，一门学问。需要你具备的能力很多，对你的要求也很高。你有什么样的水平，能站到什么样的高度，指点江山……