对软件测试的10大误解（上）

在IT行业，特别是那些并不真正从事软件测试行业的业者，对软件测试往往有一些常见的误解，对测试行业的发展和健康都有不利的影响。本文总结了10大常见误解，希望能起到一些正本清源的作用

“测试工程师的工作就是破坏软件”是一个常见的误解。作为程序员十大金句之首的“在我机器上是好的”往往来源于这一误解。测试人员好像有什么魔力，能够把正确运行的程序在测试环境上搞得不能工作。
但是这不是测试工程师破坏了软件，测试工程师并不能在软件中创造某些bug。他们只是做了些程序员没有考虑到的某些操作，比如在测试环境上，没有执行相关的依赖操作。程序员在自测时很多情况下会默认某些场景，或者是开发的新功能而没有考虑到对原有功能的影响。这也是为什么我们不推荐完全由开发者本人完成功能的测试。

真相

软件bug只会来源于产生它们的代码，测试工程师不实现代码，所以他们并不能破坏软件，他们只是发现了软件不工作的触发条件并且报告了出来。
“测试工程师对软件进行破坏”往往会导致团队开发和测试的对立情绪，甚至将软件没有满足客户要求和大量因解决问题的额外工作量归咎于测试工程师的劳动。这是非常不利于团队和产品成功的。

很多人认为软件测试是个简单的工作，不需要会编写程序，也不需要很深厚的专业技术能力。这也是一个很常见的误解。诚然，很多优秀的测试工程师都不会编写专业的程序，也不具备软件开发领域的一些专业技能如架构、抽象等。但是这并不是说测试就是一个简单的工作。James Bach在《测试与检查》一文中对测试和检查的区别进行了详细的阐述。测试是一系列创造性活动的集合，包括提问、研究、建模、观察、推理、试验等多方面的技巧。

开发和测试是两个不同的技术领域，我们不能以同样的技术标准来衡量两种不同的工作

真相

测试工作不同于开发工作，两者会有一些技能重叠，但是也存在很大的区别。开发工作的重点是高效、高质量地实现功能，而测试工作的重点是尽可能多地将软件失效在交付用户前暴露出来。测试工程师擅长开发技能可以帮助测试工程师更加深入地理解软件或帮助自己提供辅助手段来测试软件，但是这不能作为测试工作是否专业的评判标准。

测试就是把需求转换成测试用例，然后在软件中执行这些用例。这是一个在瀑布研发模式时代非常广泛的一个错误看法，然而在如今敏捷研发模式时代，也换了个模样，但是依然存在类似的认知。
在瀑布研发模式下，很多测试工作被严格地要求有非常完备地测试设计文档，然后依照这些文档进行覆盖式地执行验证。可能高级测试工程师负责编写，然后初级工程师来执行。这更多是工厂式的质量管理经验在软件行业的错误应用。
即使在敏捷研发模式得到大量应用的今天，我们还是可以看到类似认知的变种，比如测试由开发人员做好单元测试的充分覆盖就可以了。这其实依然是把测试工作文档化，只是这个文档变成了单元测试代码，执行变成了计算机。本质依然是测试=测试设计+执行

真相

输出测试设计文档，并不是真的那么重要。测试中，更重要的永远是那些创造性的东西。提问、研究、建模、观察、推理、试验等。文档是这些活动的一个输出形式，我们不应该把测试简单看作是这些文档的机械生成和执行

软件发布后，如果出现问题，很多人会首先归咎于测试的失职。认为测试没有做好份内的工作。软件测试的七大原则中，重要的一条就是穷尽测试是不可能的，何况测试并没有直接编写产生bug的代码。所以产品出现bug，是整个研发过程中整体流程的作用后果，不能也不应该据此作为评判测试工作好坏的标准。

真相

任何软件都不可能被详尽地完全测试。测试工作和开发工作、需求分析工作密不可分，产品的总体质量是整个研发团队共同作用的结果。软件发布后的bug产生是评估产品研发整体质量的一个重要标准，但仅以此来评判测试工作好坏有失偏颇。

这个误解和上一条原因比较类似，都是因为认为测试应该保证产品发布的质量并提前发现所有未知的问题。这是不可能办到的。产品是否能有效工作和很多因素有关。不同的测试环境、测试场景，不同用户操作使用软件的操作习惯、使用路径都有可能引起软件不同的表现。测试人员会尽量站在用户角度来考虑软件的使用场景，但是他并不能预测所有的用户行为，也不可能提前预知所有的运行环境和场景。所以在测试工作中，限定测试范围并告知用户经过验证的场景是相对严谨地做法。

真相

测试人员不可能估计到所有的可能性，也不可能预测到所有的用户行为。而软件会因为不同的用户行为和不同的运行场景产生超出预期的问题或bug。所以不可能要求测试人员提前发现所有的潜在bug。一个优秀的团队，会尽可能多地考虑到不同的用户场景，并根据发布目标调整覆盖场景的优先级。简单要求所有bug都能提前检测是不可能办到的任务。

参考文章