说到测试的依据，相信很多朋友首先想到的就是：测试需求。
没错，测试需求是测试人员很重要的测试依据，这其中的重要性相信开发人员比测试人员更能体会，需求不确定，意味着他们需要经常返工。
测试需求对我们测试人员来讲，也当然是越详细越好，这样对我们做测试工作也越有利。可是，实际工作中却不如人意，经常碰到需求不清晰、文档不充分的情况，甚至开发人员都还不清楚某个功能的意义是什么就要开始开发，更不用说需要进行测试了。
所以，测试过程中遇到需求不明确的地方和开发讨论也是在所难免的，甚至开发认为你提交的Bug根本就不是Bug，不值一提。
在这样的情况下，我们测试人员当然是心里感觉不爽，想竭力维护我们的劳动成果了。
又回到测试需求这个问题上了，如果我们有了详细的需求文档，我们也是按客户的需求点进行测试的，那还好，我们提交Bug也算是有理有据了。
另一个方面，如果需求不明确，文档不充分，开发和测试，公说公有理婆说婆有理，这个时候如果测试人员的态度过于强硬，恐怕是两败俱伤，谁都不服谁了，还影响后续工作的开展。
举个简单点的例子：
网页的版面和颜色的设计，用户可能不会提出很详细的要求要怎么排版，颜色是要浅黄、橘黄还是深黄，甚至是深绿，开发人员当然也会根据自己的理解和经验进行设计，同时，测试人员也有自己的想法，觉得页面的版式和颜色不好看，应该要怎么怎么设计。
哦了，问题来了：测试人员相信自己的理解才是对的，按照自己的意见设计才更好看。
于是，测试人员可能和开发人员吧啦吧啦说了很多自己的想法，但是，开发人员还是不接受测试人员的意见，测试人员急了，和开发人员说：我是站在用户的角度去理解的，我觉得用户就是要我这样的效果。
结果很显然，测试人员把开发人员也惹毛了，开发人员说：就你会站在用户角度，我们就不会站在用户角度啊，你以为我们想天天返工，天天加班啊？吧啦吧啦，开发人员和测试人员又说了一通，最后又是不欢而散。
其实，很多时候，问题不在缺陷本身，而是在沟通方式上。测试人员和开发人员对同一个问题理解不同也是很正常的，特别是在需求不明确的情况下。大家的目标都是一致，都是想把软件做的更好，谁也不想客户在真正使用系统的时候，系统出现这样那样的问题，毕竟到头来，出了问题还是得算到测试人员和开发人员头上，大家都没有好果子吃。
个人比较喜欢的沟通方式是：
就事论事，对事不对人。
1、提交Bug的时候，尽量将Bug客观描述，描述语句不带有主管色彩的词语。
2、对于开发人员觉得有异义的Bug，沟通的时候我也尽量客观的把自己的想法说出来，但不会说“我是站在用户角 度考虑的”之类的词语，虽然我们实际测试过程中需要站在用户角度考虑。
【好了，码字也码了很多了，第一次在论坛发这么长的帖子，也算是工作中的一个小结吧，欢迎大家拍砖，也谈谈自己工作中遇到此类问题的处理方式了】
