在我们每天的工作中，我们可能时时都在面对着对测试的批评和指责中。开发人员或管理人员试着用这种或那种的理由要求我们在测试过程中更负责，更仔细些。但是你认为他们对你的要求或指责都是正确抑或合理的吗?作为一个测试人员，你是否在工作中固执己见?作为一个管理者，你是否一味地追求高深的技术或测试自动化呢?本文参照了国外一些资深的测试专家的观点，并结合本人多年的经验而成。希望我们能够更理性的把测试工作做的更好。
测试的角色
认为测试小组应负责保证产品的质量
-这是经常被开发人员和管理人员滥用的一句话。经常出现在出现问题时，对测试小组的指责中。就是由于这个观念的存在，导致很多问题在开发晚期或测试后期才发现，可能需要大量的返工甚至拖延了产品的发布时间。其实在开发过程中的每一人都有可能影响产品的质量。这就像建房子一样，房子出现问题了，只是检查人员的问题吗?我想如果每一个人都心怀以“质量为中心”，小心谨慎的做好自己的工作，产品的质量会上一个很多的台阶。
认为测试就是为了发现错误
-在很多“软件测试”的定义中，都提到类似“软件测试是为了发现错误”的话。其实这个观点是提醒人们在测试过程要以查找错误为中心，而不是证明软件的正确功能。但是很多人仅凭着字面的意思就认为发现错误是测试的唯一目的，那些找不出任何错误或很少错误的测试都不是成功的测试，这是错误的。
其实测试不仅仅只是为了发现错误，还需要分析错误产生的原因和其分布情况，为开发人员，管理层提供参考，指出产品或开发过程中存在的主要问题。而且随着人们对产品质量的要求的提高，出现了多样的测试类型。象易用性测试，性能测试，覆盖率测试，恢复性测试，完整性测试等，这些测试都不是完全为了发现错误，而是找出和预期标准不同的问题。
所以个人认为还是IEEE在1983年提出的:“使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。”比较权威。
认为测试不能发现重要的错误
-有些开发人员认为单纯的手工测试只是发现系统的一些皮毛问题，因此从心里看低测试人员。但有过经验的开发人员知道，测试人员也发现了很多重要的问题。我曾经看过一些在开发小组中特别有权威的测试人员，他们虽然也只作黑盒测试，但他们发现的错误都是重量级的。
认为测试小组没有提交可用性方面的问题
没有集中精力评估产品的质量
提交错误数据的同时，但没有把数据放入错误发生的背景里
-有些测试人员认为我发现错误了，就成功了。在错误报告中，只是提及错误的情况和数据，但却没有提及错误发生的背景或是步骤。造成开发人员很难重现并修改错误。
很晚才开始测试(只是发现错误，而不是减少错误)
-这个很显而易见。但不幸的是，我参与过的很多项目测试小组都是在很晚才开始测试的。由于公司在成本上的考虑，导致了在开发后期或系统测试时才开始测试。出现了开发人员在项目晚期还在加班改bug的情况，甚至由于错误太多拖延了交付时间。在其中，还有可能发现整体设计和构架上的缺陷，导致明知会有很严重的后果都不敢改动代码的事情。
计划完成的测试工作量
测试的工作量和功能测试有偏离
低估了配置测试
把压力和负载测试放在最后进行
不测试文档
不测试安装过程
过分依赖beta测试
在转移到下一个任务之前必须完成现在的测试任务
未能正确地识别风险区域
固执地遵从测试计划
人员问题
利用测试作为新开发人员的过渡工作
从不合格的程序员中招募测试人员
测试人员不需要是领域专家
不从客户服务人员或技术文档人员中挑选测试人员
坚持测试人员必须能够编程
缺乏多样性的测试小组
认为测试和开发人员有本质的区别
相信开发人员不能够测试他们自己的代码
开发人员既没有受过培训，也没有激情测试
工作中的测试人员
比设计测试更注重运行测试
不审核测试设计
非常详细地描述测试的输入和过程
没有注意并探测到“不相关的”怪事
检查产品应该执行的和期望的一样，但没有检查它不应该执行的是期望不应该执行的一样
测试套件只有他们的作者才可以理解
只通过用户可见的界面测试
拙劣的错误报告
当发现错误后，只是增加了回归测试
没有为下一此测试工作量做笔记
测试自动化
尝试自动化所有的测试
可以立即减少工作量或人力
期望重新运行手工测试
使用GUI捕获/回放工具以减少创建测试的成本
期望回归测试可以发现更多的新错误
测试覆盖
只是追求一个简单的关于测试覆盖率的数据
只是因为有些测试不能增加覆盖率，就把它们从回归测试包中移除掉
把覆盖率作为测试人员的绩效目标
彻底地放弃覆盖率
本文转自：http://www.spasvo.com/news/html/20141211152726.html