说到测试的依据，相信很多朋友首先想到的是：测试需求。

　　没错，测试需求是测试人员很重要的测试依据，这其中的重要性相信开发人员比测试人员更能体会，需求不确定，意味着他们需要经常返工。

　　测试需求对我们测试人员来讲，也当然是越详细越好，这样对我们做测试工作也越有利。可是，实际工作中却不如人意，经常碰到需求不清晰、文档不充分的情况，甚至开发人员都还不清楚某个功能的意义是什么要开始开发，更不用说需要进行测试了。

　　所以，测试过程中遇到需求不明确的地方和开发讨论也是在所难免的，甚至开发认为你提交的Bug根本不是Bug，不值一提。

　　在这样的情况下，我们测试人员当然是心里感觉不爽，想竭力维护我们的劳动成果了。

　　又回到测试需求这个问题上了，如果我们有了详细的需求文档，我们也是按客户的需求点进行测试的，那还好，我们提交Bug也算是有理有据了。

　　另一个方面，如果需求不明确，文档不充分，开发和测试，公说公有理婆说婆有理，这个时候如果测试人员的态度过于强硬，恐怕是两败俱伤，谁都不服谁了，还影响后续工作的开展。

　　举个简单点的例子：

　　网页的版面和颜色的设计，用户可能不会提出很详细的要求要怎么排版，颜色是要浅黄、橘黄还是深黄，甚至是深绿，开发人员当然也会根据自己的理解和经验进行设计，同时，测试人员也有自己的想法，觉得页面的版式和颜色不好看，应该要怎么怎么设计。

　　哦了，问题来了：测试人员相信自己的理解才是对的，按照自己的意见设计才更好看。

　　于是，测试人员可能和开发人员吧啦吧啦说了很多自己的想法，但是，开发人员还是不接受测试人员的意见，测试人员急了，和开发人员说：我是站在用户的角度去理解的，我觉得用户是要我这样的效果。

　　结果很显然，测试人员把开发人员也惹毛了，开发人员说：你会站在用户角度，我们不会站在用户角度啊，你以为我们想天天返工，天天加班啊？吧啦吧啦，开发人员和测试人员又说了一通，后又是不欢而散。

　　其实，很多时候，问题不在缺陷本身，而是在沟通方式上。测试人员和开发人员对同一个问题理解不同也是很正常的，特别是在需求不明确的情况下。大家的目标都是一致，都是想把软件做的更好，谁也不想客户在真正使用系统的时候，系统出现这样那样的问题，毕竟到头来，出了问题还是得算到测试人员和开发人员头上，大家都没有好果子吃。

　　个人比较喜欢的沟通方式是：

　　事论事，对事不对人。

　　1、提交Bug的时候，尽量将Bug客观描述，描述语句不带有主管色彩的词语。

　　2、对于开发人员觉得有异义的Bug，沟通的时候我也尽量客观的把自己的想法说出来，但不会说“我是站在用户角 度考虑的”之类的词语，虽然我们实际测试过程中需要站在用户角度考虑。