由于人们对于软件质量的重视程度越来越高，测试行业最近几年发展迅速，越来越多的人员进入软件测试领域。随着从业人员的剧增，软件测试人员的水平也参差不齐，部分人员甚至觉得做软件测试不需要什么技能，点点点就可以完成的事情，其实，这些都是误解，笔者刚好最近在网上学习软件测试知识，特将这些误解梳理如下。

    一、软件测试工作就是应用软件测试工具，把测试和工具等同一起来。

    这个误区可以说是一种通病，几乎每一个领域中的CASE工具刚刚出现时都会带来这个问题，比如：如果一个软件开发团队在软件的开发中使用了Rational Rose工具来进行UML图的绘制，他们可能就会声称他们采用了面向对象的方法，也不管他们的设计和代码实际上是多么的过程化。测试团队使用了QTP就认为是做了自动化测试一样。

    二、存在太多的无法测试的东西

    在软件开发领域，确实存在一些东西看起来要比另外一些东西难测试一些，但是远非无法测试。

    并且在大多数的情况下，还是由于被测试的软件本身在设计时没有考虑到可测试性的问题。只不过这种不可测试性不是由于被测试的软件内部的过紧耦合造成的，而是和外部某些很难测试的部分耦合过紧，从而表现出被测试的软件本身很难测试。

    这些很难测试的部分比较常见的有：图形界面、硬件、数据库等。下面以图形界面为例进行说明。

    那么对于不好测试的图形界面，我们该怎么办呢？原则很简单，如果某种东西不好测试，那么就让它做肯定不会出错的事情，而把可能会出错的逻辑剥离出来，放到一个可以测试的模块中。对于图形界面来说，就是仅仅保持一个很薄的图形界面逻辑，它的工作就是把用户的请求简单的转发给真正处理该请求的软件模块（一般称之为Application Facade）。转发逻辑足够简单以至于它肯定不会出错，所以我们也无需对它进行测试。

    如果在进行软件开发时能够首先编写测试代码，那么就会迫使你从易使用性，易测试性的角度开考虑问题，从而你就会专注于软件模块的高层抽象和职责。这样就会定义出清晰的、明确反映意图的模块接口来，另外，为了使得测试能够进行，你就会主动把那些导致不好测试的耦合去掉。这样的结果不仅仅是获得了可测试性，并且也产生了更好的设计和系统架构。

    但是确实存在一些不好测试的东西并且很难只让它执行一些非常简单的逻辑，比如嵌入式系统中的BSP（板级支持包）。开发它们所使用的语言、环境以及它们本身的特性等决定了它们是很难测试的。这里说的难测试其实是一个测试代价问题，具体的说就是要付出更多的时间和努力。这就需要你在付出的代价和测试带来的收益之间进行平衡。如果付出的代价所带来的收益（更少的调试、维护、发布成本）是巨大的，那么付出的代价就是非常值得的。