这个误解在现如今几乎已经成为信条了。确实，理论上，所有的测试用例都可以通过技术手段来实现并自动执行，但是正如我们再前面提过的，测试并不是测试用例+测试执行的叠加。测试还包括大量的创造性的活动。所以自动化测试代替测试是个伪命题（除非有朝一日，人工智能发展到能够打败人类的创造性。那时可能整个IT行业都不需要人力劳动了）
除此之外，即使自动化测试能把所有的测试用例都实现通过机器执行，也不意味着应该这么做。因为自动化测试本身也是一项投资，有大量的投入在其中。很多测试场景通过自动化测试可以产生很大的价值，比如大量重复性地验证。但是也有很多场景，不需要通过自动化的投入来实现，比如很多一次性的功能验证，还有依赖人进行主观判断的功能等。
真相
七、测试应放在开发环境后期进行测试中的检查工作，很大一部分可以通过自动化测试代替，但是测试工作不会被自动化测试代替。即使可以实现自动化测试的场景，我们也要通过ROI的衡量（如测试金字塔）来确定实施自动化测试的必要性
传统的瀑布研发模式中，在研发后期会有专门的测试阶段，包括集成测试、系统测试、验收测试等。所以长期形成一个误解，测试是在开发阶段后发生的。
可是这是一个错误的认识，这依然是传统工厂流水线思想的产物，并不适用于软件研发。即使在瀑布研发模式下，前期的开发阶段和需求设计阶段也都明确了测试人员参与的必要性。在现代敏捷研发模式下，更加强调测试工作的迁移，测试在需求澄清、系统设计、代码走查、结对编程等等阶段都扮演着重要的角色。
真相
八、任何人都可以做好测试测试是贯穿在研发生命周期全流程的一项活动，并不是某一个割裂开的独立阶段。测试越早介入对产品最终质量就更能产生积极的效果。
这句话就好像《21天精通X语言》，《你也能做CEO》，《XXX三天速成》等故事一样，任何事情，懂得些鸡毛蒜皮都很容易，并不一定是测试，任何行当其实都是这样。10000小时定律对任何行业都适用。
真相
九、测试工程师是质量守门员做一个好的测试工程师，一定是需要专业的技能训练以及经验积累。测试是一个广泛的范畴，各种各样不同的测试概念（参见本人免费课 软件测试基础-概念篇）以及对应的测试方法、测试工具都需要大量的实践和学习才能在需要的时候应对自如。
这个误解几乎在所有IT企业都存在。测试工程师被当做质量守门员（背锅侠），测试人员需要为所测试的软件质量背书。测试人员被当做产品质量的最后一道防线，测试结果似乎决定了软件产品最终的交付质量。
真相
十、测试即QA(质量保证)实际情况下，测试无法决定产品质量，只能将产品中当前发现的问题暴露出来，并据此进行质量评估。而且无论是因为研发周期还是问题修复成本等问题，测试人员并不能左右产品是否能够交付给用户。测试人员针对测试过程的总结和报告，更多是体现当前测试场景和测试范围下，软件产品的质量评估情况，测试工程师其实无法充当守门员角色。
在很多企业，往往会混淆QA和Testing两种角色，认为Testing就是QA（Quality Assurence）。应该说两者有相关性，或者说QA > testing。
前面说过，质量不会由测试来决定，质量更多是从需求、设计、开发环节就确定的。所以QA工作除了包含测试外，更主要的是流程改进，通过流程关键节点的管控来保证质量水准。
真相
总结QA涵盖的范围比测试更大，二者侧重点也不同。QA更关注软件研发全流程的质量管控，测试则更关注将当前软件中的缺陷暴露出来。二者的关注点不同，所需要的技能也不相同。不能简单地把测试和QA工作划等号。
测试是一门涵盖范围广泛的专业，但是业界对测试工作却普遍存在或多或少的误解。本文参考了一些国内外相关总结并结合个人的经历，希望能或多或少有清源之效，并和大伙共勉。