google,baidu一下，关于软件测试的误读，大家轻易的就会搜出一堆来。
但是这里，我要说的，是在我五年的软件测试经验里面，见识到的种种误读。
第一种：软件测试是用来测试程序员开发的产品满足功能要求
这一种，常常见于开发人员的认知。测试的理论中，我们会讲到异常测试和正常测试，实践过程当中，有很多测试人员会发现一些用异常类测试的bug,但是开发人员有的时候基于种种考虑，比如说终端用户是否会遇到，这种问题出现的几率，修改它可能会引起的其他模块的问题，以及开发人员的工作量的增加等等，不会很乐意去修改这样的bug.在很多通用的软件测试当中，测试的绝大部分也以为这样的环境都趋向于pass-to-pass测试。而这种缺少pass-to-fail的测试实践其实会引发很多潜在的问题和风险。
第二种，力求完美的测试人员，所有bug都能发现并且解决才能是成功的软件测试。
这一种，一般是刚入门的测试人员会有的想法。测试人员希望竭尽全力的发现软件所有的问题。但是实际上，我们知道，因为不能对软件进行穷举测试，而实际上无论是成本的考虑还是效率的分析，这种全面的覆盖也是不可能的。所以才会有，软件测试只能证明软件有错误而不能证明它没有错误这个论断。所以对于软件测试人员来说，要在有限的时间内，基于成本效率的综合分析，把测试的任务分轻重缓急，并且做好风险分析和风险控制，依据测试的计划，完成阶段性的测试，并且测试覆盖到应该覆盖的程度，检测出重要的软件缺陷，并且促使他们最终能得到解决的测试已经算是很有效的很成功的软件测试。
而且做一个接近完美的产品无论从成本考虑还是从企业的利益来考虑都是不可能的一件事情。某跨国公司曾经有过一句名言，就是100%满意的产品等于自杀。对于测试人员来说，我们的目标应该是追求完美但是不能苛求。尽到自己的责任就可以了。有些未发现的或者未解决的问题都将会在后续的版本中陆续的被解决，只要它们值得被修复。
第三种，开发人员拒绝了我的bug,是忽视我的劳动成果，不尊重我的表现。
这种往往反映在现实的测试生活中，开发人员和测试人员的很多矛盾也是因为这个而导致。毕竟，现实的生活中，开发人员的有效业绩是极少的bug检出率，而测试人员的业绩很大一部分来源于测试过程中挖掘出了多少有价值的bug.
实际当中，作为测试人员首先要树立的就是对事不对人的态度。不能因为种种原因和开发人员对抗。不团结的开发测试队伍没有办法很有效地做好沟通，自然就没有办法保证最后的质量。
然后要站在客户的角度上衡量自己被开发人员拒掉的bug的价值，可能给系统带来的风险级别，以及开发人员可能不修复的原因。如果觉得对其的修复非常必要，则应该更好地进行沟通的同时，取得更为有利的证据来证明自己的判断。而不是一味的吵架，僵持或者自我贬低。
第四种，测试人员应该保证产品的质量
这个问题，其实在以前的一个帖子里面我曾经写过。这里，摘抄一下当初的内容
测试人员需要为产品质量负责吗？
这句话其实可以这样问
医生需要为病人的病情负责吗？
答案是肯定的。一个产品从测试人员手中走过，测试人员需要对它进行有目的的有效的测试，确保尽早的发现产品内在的缺陷，从而在最短的时间内促使开发人员完成对产品的修复，减少企业因此而将要承受的损失。
这需要测试人员的责任心。面对一个测试任务，需要的是细心，耐心以及自我的分析。知道成本和效益的关系，了解客户最大的需求，知道面对的这个任务，自己的轻重缓急在哪里，不能磨磨蹭蹭，以至于耽误了最佳的测试时间。
如果测试产品从测试人员手中流过，却没有被检测出隐含的最大的问题，那么就是测试人员的失职。就如同一个医生面对一个病人，经过一番检查，却没有任何的诊断抑或遗漏了最大的病患。。
但是反过来讲，测试人员不能对产品的任何瑕疵都负责任，不可能为产品的质量去100%买单。测试人员只对测试的质量去买单，只为测试的成果负责。
测试人员虽然尽心尽力的对产品进行了最为有效的测试，但是因为客户的决定，或者开发人员的推委，导致产品的已发现的重大的问题没有被解决掉。面对这部分，测试人员不需要去负责
但是也不要因此就影响了士气。虽然，很多时候，人们总说，一个软件做好了，是开发人员的功劳；做得不好，使测试人员的不是。也有很多人，因为这个原因而离开了测试队伍。因为觉得自己跟“替罪羔羊”一样的无奈和无辜。
其实，很多时候，任何角落，都有一些前台的和幕后的英雄，并不是站在领奖台上的人才是最光荣的。无论是设计者，开发者还是测试人员，都是软件生命周期中不可或缺的重要组成人员，大家共同的努力才成就了软件的上市以及企业的盈利和良好信誉。每一个都要为自己的存在而感到自豪。自己的地位靠自己的努力来不断的得到证明，自己的能力不需要别人的证明。金子在沙地也是金子，沙子在金堆也总是沙子。如果你觉得自己被轻视了，那么，不要放弃，请你努力！相信吧，自己今天的努力一定会换来你更美好的明天。
测试人员在面对测试任务之前一定学会思考，从客户，从市场，从软件本身的特点去方方面面的思考，知道自己该如何把握，该怎样策划你的测试用例。该如何更加有效的去发现更有价值的bug.
很多测试人员都觉得很郁闷，当他们的bug被开发的以不需要修复为由而拒掉。但是这个时候抱怨没有用的。开发人员这样做，你要找到理由。开发人员绝对不会贸贸然把一个可能导致软件崩溃的bug置之不理。如果是这样的bug，那么，可能时间已经不够，修复的风险太大，这个时候你要理解，而且要帮助他们出主意，看看怎样解决才是最好。如果你的bug无足轻重，而还有一大堆的问题你都没有去发掘，那么，坐冷板凳是应该的。这个时候，你能做得最好的事情就是，自己多去想，有效地发现出更多更有效的更重要的bug来。
其他的问题，暂时还没有想到，以后再补充好了。呵呵~~
