你真的懂软件测试人员的痛苦吗？——目前软件测试5大误区

随着软件测试对提高软件质量重要性的不断提高，软件测试也不断受到重视。但是，国内软件测试过程的不规范，重视开发和轻视测试的现象依旧存在。

因此，对于软件测试的重要性、测试方法和测试过程等方面都存在很多不恰当的认识，这将会进一步的影响软件测试活动的开展，并且阻碍软件测试质量的提高。

我们暂且不去评析软件测试在当今it公司中的地位，只说大家对软件测试的认识。基于我短暂的经验，我总结出软件测试几个最常见的误区，供大家研究

误区1：软件开发完成后才进行测试

在传统的瀑布模型中，软件项目主要有一下几个阶段组成：用户需求、需求分析、概要设计、详细设计、编码和实现、测试以及运行维护。由于软件测试仅处于运行维护阶段之前，是软件产品交付用户使用之前保证软件质量的重要手段。因此人们一般认为，软件测试只是软件编码后的一个阶段。

个人观点：软件测试是贯穿于整个软件开发生命周期的过程活动，包括软件测试计划、软件测试需求分析、软件测试用例设计、软件测试执行、软件缺陷管理、软件测试风险管理以及其他的一些软件测试相关的活动等等组成。在软件项目的每个阶段，都需要进行不同目的和不同内容的测试活动，以保证各个阶段工作产品输出的正确性。软件测试的对象也不仅仅是软件代码，还包括软件需求文档和设计文档等其他所有的软件工作产品。软件开发与软件测试之间应该是交互进行的，比如单元编码之后需要进行单元测试，模块组合之后进行集成测试。

误区2：软件发布后发现软件问题，那是测试人员的责任

许多人认为测试人员需要对发布的软件质量负责，假如软件到用户后，发现很多的问题，那是测试人员的错和责任。这种认识误区非常打击测试人员的积极性。软件中的缺陷可能来自软件开发过程中的任何一个过程，而对于软件测试而言，只能证明软件存在缺陷，而不能保证软件没有错误。通过软件测试，无法发现软件中的所有错误和缺陷。

个人观点：从软件开发的角度看，软件的高质量不是软件测试人员测出来的，而是需要软件生命周期的各个过程共同来保证的。出现软件错误，不能简单地归结为某一个人或某个团队的责任。比如有些错误的产生可能不是技术原因，可能来自于混乱的项目管理；或者客户发现软件某些功能并没有按照原有需求来实现，换言之，软件没有完成客户想做的操作，诸如此类问题很可能是软件设计人员理解需求错误致使设计不当所引起的。

误区3：测试简单，对技术要求不高

这是对测试最通常的评价，如果一个开发人员转做测试，那么别人通常认为，他是不是开发能力不够，或者是他是不是不愿意吃苦之类。认为测试只是对照产品规格书操作软件，发现软件与规格说明不一致的地方，是没有技术含量的工作，甚至认为测试就是点点点。。。

个人观点：测试反而对技术要求更高。这里的"高"不是说一定多么精于某一门技术，而是需要更广的技术能力。比如简单的功能测试，我们需要需求分析能力和业务能力，很多公司中测试人员的业务能力甚至超越开发人员能力，当然还有相应的测试技术；进行白盒测试，我们需要拥有一定的代码阅读能力和编写能力；安全性测试，我们需要一定的网络安全知识和数据库分析能力等等。

误区4：由项目进度来决定测试工作量

规范的测试流程应该是一个整体的连续的过程，包括测试计划和控制、测试分析和设计、测试实现和执行等阶段。每一阶段也应有各自的规程。而大多数人对测试的理解往往是随项目进度而定，即离项目交付空余的时间多，就多做测试；反之，则少做测试。这样很可能导致测试时间紧张，从而可能放弃其中的一些测试，可能导致遗漏一些重要的缺陷，显然这种做法存在非常大的风险。

个人观点：测试贯穿整个软件生命周期。

误区5：总有一天，机器自动化将代替人工测试

这是业界很多人所津津乐道的话题，记得曾经去某个公司面试，其经理很得意的告诉我他们的目标就是未来以自动化取代手工测试，每个项目只需要一两个自动化测试工程师就ok了

个人观点：当然，我不否认自动化测试的作用，甚至我自己也在津津乐道于测试框架开发等工作，但是自动化代替人工测试？恐怕我得说“NO”。不是难于实现，而是根本不可能。

软件的最终使用者永远是人，所以只有人才能真正了解人的需求。例如用户体验，common sense等等，这是机器永远不能代替的。

况且自动化测试需要在前期投入大量的资源和工作量，同时需要维护的成本很高，包括环境的搭建、测试脚本的设计、维护等，这样的成本在国内企业中要实施起来更是难之又难。

最后:【可能给予你帮助】

资源分享

下面这些是我的收集和整理的资料，对于开始学习【软件测试】或是技能进阶的朋友来说，绝对是最全面的教程仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你。关注我，为你的测试之路保驾护航，陪伴每一位测试人的成长。

测试资源免费领取~~