本
文
摘
要
在IT行业，特别是那些并不真正从事软件测试行业的业者，对软件测试往往有一些常见的误解，对测试行业的发展和健康都有不利的影响。本文总结了10大常见误解，希望能起到一些正本清源的作用
一、测试工程师的工作是破坏软件
“测试工程师的工作就是破坏软件”是一个常见的误解。作为程序员十大金句之首的“在我机器上是好的”往往来源于这一误解。测试人员好像有什么魔力，能够把正确运行的程序在测试环境上搞得不能工作。 但是这不是测试工程师破坏了软件，测试工程师并不能在软件中创造某些bug。他们只是做了些程序员没有考虑到的某些操作，比如在测试环境上，没有执行相关的依赖操作。程序员在自测时很多情况下会默认某些场景，或者是开发的新功能而没有考虑到对原有功能的影响。这也是为什么我们不推荐完全由开发者本人完成功能的测试。
真相
软件bug只会来源于产生它们的代码，测试工程师不实现代码，所以他们并不能破坏软件，他们只是发现了软件不工作的触发条件并且报告了出来。 “测试工程师对软件进行破坏”往往会导致团队开发和测试的对立情绪，甚至将软件没有满足客户要求和大量因解决问题的额外工作量归咎于测试工程师的劳动。这是非常不利于团队和产品成功的。二、测试工作不需要什么专业技能
很多人认为软件测试是个简单的工作，不需要会编写程序，也不需要很深厚的专业技术能力。这也是一个很常见的误解。诚然，很多优秀的测试工程师都不会编写专业的程序，也不具备软件开发领域的一些专业技能如架构、抽象等。但是这并不是说测试就是一个简单的工作。James Bach在《测试与检查》一文中对测试和检查的区别进行了详细的阐述。测试是一系列创造性活动的 *** ，包括提问、研究、建模、观察、推理、试验等多方面的技巧。
开发和测试是两个不同的技术领域，我们不能以同样的技术标准来衡量两种不同的工作
真相
测试工作不同于开发工作，两者会有一些技能重叠，但是也存在很大的区别。开发工作的重点是高效、高质量地实现功能，而测试工作的重点是尽可能多地将软件失效在交付用户前暴露出来。测试工程师擅长开发技能可以帮助测试工程师更加深入地理解软件或帮助自己提供辅助手段来测试软件，但是这不能作为测试工作是否专业的评判标准。三、测试就是写测试用例，然后执行
测试就是把需求转换成测试用例，然后在软件中执行这些用例。这是一个在瀑布研发模式时代非常广泛的一个错误看法，然而在如今敏捷研发模式时代，也换了个模样，但是依然存在类似的认知。 在瀑布研发模式下，很多测试工作被严格地要求有非常完备地测试设计文档，然后依照这些文档进行覆盖式地执行验证。可能高级测试工程师负责编写，然后初级工程师来执行。这更多是工厂式的质量管理经验在软件行业的错误应用。 即使在敏捷研发模式得到大量应用的今天，我们还是可以看到类似认知的变种，比如测试由开发人员做好单元测试的充分覆盖就可以了。这其实依然是把测试工作文档化，只是这个文档变成了单元测试代码，执行变成了计算机。本质依然是测试=测试设计+执行
真相
输出测试设计文档，并不是真的那么重要。测试中，更重要的永远是那些创造性的东西。提问、研究、建模、观察、推理、试验等。文档是这些活动的一个输出形式，我们不应该把测试简单看作是这些文档的机械生成和执行四、产品出现问题，说明没有很好地进行测试
软件发布后，如果出现问题，很多人会首先归咎于测试的失职。认为测试没有做好份内的工作。软件测试的七大原则中，重要的一条就是穷尽测试是不可能的，何况测试并没有直接编写产生bug的代码。所以产品出现bug，是整个研发过程中整体流程的作用后果，不能也不应该据此作为评判测试工作好坏的标准。
真相
任何软件都不可能被详尽地完全测试。测试工作和开发工作、需求分析工作密不可分，产品的总体质量是整个研发团队共同作用的结果。软件发布后的bu *** 生是评估产品研发整体质量的一个重要标准，但仅以此来评判测试工作好坏有失偏颇。五、通过测试可以发现所有的bug
这个误解和上一条原因比较类似，都是因为认为测试应该保证产品发布的质量并提前发现所有未知的问题。这是不可能办到的。产品是否能有效工作和很多因素有关。不同的测试环境、测试场景，不同用户操作使用软件的操作习惯、使用路径都有可能引起软件不同的表现。测试人员会尽量站在用户角度来考虑软件的使用场景，但是他并不能预测所有的用户行为，也不可能提前预知所有的运行环境和场景。所以在测试工作中，限定测试范围并告知用户经过验证的场景是相对严谨地做法。
真相
测试人员不可能估计到所有的可能性，也不可能预测到所有的用户行为。而软件会因为不同的用户行为和不同的运行场景产生超出预期的问题或bug。所以不可能要求测试人员提前发现所有的潜在bug。一个优秀的团队，会尽可能多地考虑到不同的用户场景，并根据发布目标调整覆盖场景的优先级。简单要求所有bug都能提前检测是不可能办到的任务。六、自动化测试可以代替测试
这个误解在现如今几乎已经成为信条了。确实，理论上，所有的测试用例都可以通过技术手段来实现并自动执行，但是正如我们在前面提过的，测试并不是测试用例+测试执行的叠加。测试还包括大量的创造性的活动。所以自动化测试代替测试是个伪命题（除非有朝一日，人工智能发展到能够打败人类的创造性。那时可能整个IT行业都不需要人力劳动了） 除此之外，即使自动化测试能把所有的测试用例都实现通过机器执行，也不意味着应该这么做。因为自动化测试本身也是一项投资，有大量的投入在其中。很多测试场景通过自动化测试可以产生很大的价值，比如大量重复性地验证。但是也有很多场景，不需要通过自动化的投入来实现，比如很多一次性的功能验证，还有依赖人进行主观判断的功能等。
真相
测试中的检查工作，很大一部分可以通过自动化测试代替，但是测试工作不会被自动化测试代替。即使可以实现自动化测试的场景，我们也要通过ROI的衡量（如测试金字塔）来确定实施自动化测试的必要性七、测试应放在开发环节后期进行
传统的瀑布研发模式中，在研发后期会有专门的测试阶段，包括集成测试、系统测试、验收测试等。所以长期形成一个误解，测试是在开发阶段后发生的。 可是这是一个错误的认识，这依然是传统工厂流水线思想的产物，并不适用于软件研发。即使在瀑布研发模式下，前期的开发阶段和需求设计阶段也都明确了测试人员参与的必要性。在现代敏捷研发模式下，更加强调测试工作的前移，测试在需求澄清、系统设计、代码走查、结对编程等等阶段都扮演着重要的角色。
真相
测试是贯穿在研发生命周期全流程的一项活动，并不是某一个割裂开的独立阶段。测试越早介入对产品最终质量就更能产生积极的效果。八、任何人都可以做好测试
这句话就好像《21天精通X语言》，《你也能做CEO》，《XXX三天速成》等故事一样，任何事情，懂得些鸡毛蒜皮都很容易，并不一定是测试，任何行当其实都是这样。10000小时定律对任何行业都适用。
真相
做一个好的测试工程师，一定是需要专业的技能训练以及经验积累。测试是一个广泛的范畴，各种各样不同的测试概念（参见本人免费课 软件测试基础-概念篇）以及对应的测试方法、测试工具都需要大量的实践和学习才能在需要的时候应对自如。九、测试工程师是质量守门员
这个误解几乎在所有IT企业都存在。测试工程师被当做质量守门员（背锅侠），测试人员需要为所测试的软件质量背书。测试人员被当做产品质量的最后一道防线，测试结果似乎决定了软件产品最终的交付质量。
真相
实际情况下，测试无法决定产品质量，只能将产品中当前发现的问题暴露出来，并据此进行质量评估。而且无论是因为研发周期还是问题修复成本等问题，测试人员并不能左右产品是否能够交付给用户。测试人员针对测试过程的总结和报告，更多是体现当前测试场景和测试范围下，软件产品的质量评估情况，测试工程师其实无法充当守门员角色。十、测试即QA(质量保证)
在很多企业，往往会混淆QA和Testing两种角色，认为Testing就是QA（Quality Assurence）。应该说两者有相关性，或者说QA > testing。 前面说过，质量不会由测试来决定，质量更多是从需求、设计、开发环节就确定的。所以QA工作除了包含测试外，更主要的是流程改进，通过流程关键节点的管控来保证质量水准。
真相
QA涵盖的范围比测试更大，二者侧重点也不同。QA更关注软件研发全流程的质量管控，测试则更关注将当前软件中的缺陷暴露出来。二者的关注点不同，所需要的技能也不相同。不能简单地把测试和QA工作划等号。总结
测试是一门涵盖范围广泛的专业，但是业界对测试工作却普遍存在或多或少的误解。本文参考了一些国内外相关总结并结合个人的经历，希望能或多或少有清源之效，并和大伙共勉。
参考文章
