对于很多不了解软件测试的人来说，同样是从事IT行业工作，软件测试人员看起来却要比软件开发人员“矮一截”。

这其实都是由于大家对软件测试行业不了解造成的，今天，小编就为大家解答一些常见的软件测试行业误区，希望对大家有用。

误解1、测试比较简单，不懂技术也能胜任

很多人认为软件测试是个简单的工作，不需要会编写程序，也不需要很深厚的专业技术能力。但做为一个好的测试工程师，一定是需要专业的技能训练以及经验积累。

测试是一个广泛的范畴，各种各样不同的测试概念以及对应的测试方法、测试工具都需要大量的实践和学习才能在需要的时候应对自如。

开发和测试是两个不同的技术领域，我们不能以同样的技术标准来衡量两种不同的工作。
开发工作的重点是高效、高质量地实现功能，而测试工作的重点是尽可能多地将软件失效在交付用户前暴露出来。

测试工程师擅长开发技能可以帮助测试工程师更加深入地理解软件或帮助自己提供辅助手段来测试软件，但是这不能作为测试工作是否专业的评判标准。

误解2、和开发相比，测试没什么前途

前几年国内普遍存在着“重开发、轻测试”的现象，甚至在很多互联网公司里，根本就没有软件测试岗，产品上线前纯靠开发和非专业人员的内部测试。

大多数人认为软件开发就是编写代码，给人的印象往往是程序员是真正的牛人，具有很高的地位和待遇，相反地软件测试很不受重视，相关人员的地位和待遇自然也比不过开发，甚至软件测试变得可有可无。

可最近几年随着软件行业的日渐成熟，用户对产品的体验感、安全性更加关注，各大企业对产品的重视度也越来越高，软件测试变得越来越重要，相应的软件测试人员的地位和待遇也在逐渐提高。

软件测试将会成为一个具有很大发展前景的行业，软件测试大有前途，市场需要更多具有丰富测试技术和管理经验的测试人员。

误解3、软件开发完成后，测试才开始工作

软件项目要经过需求分析，概要设计，详细设计，软件编码，软件测试，软件发布这几个阶段。因此不了解软件测试周期的人会错误地认为软件测试只是软件编码后的一个过程。

软件测试是一个系列过程活动，包括软件测试需求分析，测试计划设计，测试用例设计，执行测试。因此，软件测试贯穿于整个软件项目的生命周期里，对其每一个阶段都要进行不同目的和内容的测试活动，以保证各个阶段的正常使用。

软件测试的对象不仅仅是软件代码，还包括软件需求文档和设计文档。

如果等到软件编码结束后才进行测试，测试时间将会很短，测试覆盖面很不全面，因此次测试效果也将大打折扣。

另一方面测试过程中发现软件需求阶段或概要设计阶段的错误，此时再进行该类bug的修复将会耗费大量的时间和人力。

因此测试应尽早介入，不同阶段产生的bug在不同阶段修复将降低成本，对产品最终质量就更能产生积极的效果。

误解4、通过测试，可以发现所有bug

软件测试有一条原则：测试是不能穷尽的。测试会面对大量的测试数据、测试场景或代码路径等，测试也只是一个样本实验，不能证明软件是正确的，只能说明发现的缺陷的确是缺陷。

但如果没有发现问题，并不能说明问题就不存在，而是至今未发现软件中所潜在的问题。

测试中，测试人员会尽量站在用户角度来考虑软件的使用场景，但是他并不能预测所有的用户行为，也不可能提前预知所有的运行环境和场景，所以不可能要求测试人员提前发现所有的潜在bug。

在测试工作中，限定测试范围并告知用户经过验证的场景是相对严谨的做法。

测试工作和开发工作、需求分析工作密不可分，产品的总体质量是整个研发团队共同作用的结果。

软件发布后的bug产生是整个研发过程中整体流程的作用后果，是评估产品研发整体质量的一个重要标准。

出现bug并不能简单地归结为某一个人的责任，而是应该分析软件项目的各个过程，从过程改进方面寻找产生错误的原因和改进的措施。

误解5、测试就是写测试用例，然后执行

测试就是把需求转换成测试用例，然后在软件中执行这些用例。这是一个在瀑布研发模式时代非常广泛的一个错误看法。

很多测试工作被严格地要求有非常完备的测试设计文档，然后依照这些文档进行覆盖式地执行验证。可能高级测试工程师负责编写，然后初级工程师来执行。

然而在如今敏捷研发模式时代，也换了个模样，但是依然存在类似的认知。这其实依然是把测试工作文档化，只是这个文档变成了单元测试代码，执行变成了计算机。本质依然是测试=测试设计+执行。

事实上，输出测试设计文档，并不是真的那么重要。测试中，更重要的永远是那些创造性的东西，提问、研究、建模、观察、推理、试验等。

文档是这些活动的一个输出形式，我们不应该把测试简单看作是这些文档的机械生成和执行。

误解6、自动化测试可以代替测试

这个误解在现如今几乎已经成为信条了。确实，理论上，所有的测试用例都可以通过技术手段来实现并自动执行，但是正如我们在前面提过的，测试并不是测试用例+测试执行的叠加。

测试还包括大量的创造性的活动。除此之外，即使自动化测试能把所有的测试用例都通过机器执行实现，也不意味着应该这么做。

自动化测试本身也是一项投资，有大量的投入在其中。很多测试场景通过自动化测试可以产生很大的价值，比如大量重复性的验证。但是也有很多场景，不需要通过自动化的投入来实现，比如很多一次性的功能验证，还有依赖人进行主观判断的功能等。

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

以上列举的6个软件测试误区，你曾经误会了哪些？

最后：希望大家都越来越好。如果对python自动化测试、web自动化、接口自动化、移动端自动化、面试经验交流等等感兴趣的测试人，欢迎私信或者加入我们的Q群（见图），获取更多大厂技术、面试资料，一起进步。