对软件测试的十大误解（下）

这个误解在现如今几乎已经成为信条了。确实，理论上，所有的测试用例都可以通过技术手段来实现并自动执行，但是正如我们再前面提过的，测试并不是测试用例+测试执行的叠加。测试还包括大量的创造性的活动。所以自动化测试代替测试是个伪命题（除非有朝一日，人工智能发展到能够打败人类的创造性。那时可能整个IT行业都不需要人力劳动了）
除此之外，即使自动化测试能把所有的测试用例都实现通过机器执行，也不意味着应该这么做。因为自动化测试本身也是一项投资，有大量的投入在其中。很多测试场景通过自动化测试可以产生很大的价值，比如大量重复性地验证。但是也有很多场景，不需要通过自动化的投入来实现，比如很多一次性的功能验证，还有依赖人进行主观判断的功能等。

真相

测试中的检查工作，很大一部分可以通过自动化测试代替，但是测试工作不会被自动化测试代替。即使可以实现自动化测试的场景，我们也要通过ROI的衡量（如测试金字塔）来确定实施自动化测试的必要性

传统的瀑布研发模式中，在研发后期会有专门的测试阶段，包括集成测试、系统测试、验收测试等。所以长期形成一个误解，测试是在开发阶段后发生的。
可是这是一个错误的认识，这依然是传统工厂流水线思想的产物，并不适用于软件研发。即使在瀑布研发模式下，前期的开发阶段和需求设计阶段也都明确了测试人员参与的必要性。在现代敏捷研发模式下，更加强调测试工作的迁移，测试在需求澄清、系统设计、代码走查、结对编程等等阶段都扮演着重要的角色。

真相

测试是贯穿在研发生命周期全流程的一项活动，并不是某一个割裂开的独立阶段。测试越早介入对产品最终质量就更能产生积极的效果。

这句话就好像《21天精通X语言》，《你也能做CEO》，《XXX三天速成》等故事一样，任何事情，懂得些鸡毛蒜皮都很容易，并不一定是测试，任何行当其实都是这样。10000小时定律对任何行业都适用。

真相

做一个好的测试工程师，一定是需要专业的技能训练以及经验积累。测试是一个广泛的范畴，各种各样不同的测试概念（参见本人免费课 软件测试基础-概念篇）以及对应的测试方法、测试工具都需要大量的实践和学习才能在需要的时候应对自如。

这个误解几乎在所有IT企业都存在。测试工程师被当做质量守门员（背锅侠），测试人员需要为所测试的软件质量背书。测试人员被当做产品质量的最后一道防线，测试结果似乎决定了软件产品最终的交付质量。

真相

实际情况下，测试无法决定产品质量，只能将产品中当前发现的问题暴露出来，并据此进行质量评估。而且无论是因为研发周期还是问题修复成本等问题，测试人员并不能左右产品是否能够交付给用户。测试人员针对测试过程的总结和报告，更多是体现当前测试场景和测试范围下，软件产品的质量评估情况，测试工程师其实无法充当守门员角色。

在很多企业，往往会混淆QA和Testing两种角色，认为Testing就是QA（Quality Assurence）。应该说两者有相关性，或者说QA > testing。
前面说过，质量不会由测试来决定，质量更多是从需求、设计、开发环节就确定的。所以QA工作除了包含测试外，更主要的是流程改进，通过流程关键节点的管控来保证质量水准。

真相

QA涵盖的范围比测试更大，二者侧重点也不同。QA更关注软件研发全流程的质量管控，测试则更关注将当前软件中的缺陷暴露出来。二者的关注点不同，所需要的技能也不相同。不能简单地把测试和QA工作划等号。

测试是一门涵盖范围广泛的专业，但是业界对测试工作却普遍存在或多或少的误解。本文参考了一些国内外相关总结并结合个人的经历，希望能或多或少有清源之效，并和大伙共勉。

参考文章