软件测试认识中的误区（转）

误区之一：使用了测试工具，就是进行了有效的测试
因为，要想对一个软件或者模块进行有效的测试，首先该软件或者模块应该是可测试的。可测试性是反映软件质量的一个内在属性，不会因为你使用了某种测试工具进行了测试行为，就使得被测试的软件具有了可测试性。如果被测试的软件本身并不具备可测试性，那么使用多么昂贵的测试工具进行测试所能够带来的收益都是微乎其微的。
要想真正获取测试带来的巨大好处，并且使得测试工具能够发挥最大的效率，关键就是要使软件本身具有很好的可测试性。这种能力的获取是一个逐步的过程，是不可能一蹴而就的。最关键的一点就是要不断实践，不断学习一些优秀的经验，不断的反思。要想获取好的结果，就必须要付出努力，这是亘古不变的真理。
对于测试工具的选择，只要满足需要并能够自动运行测试用例就可以了。不要一味的追求复杂的功能和不必要的灵活性。对于大多数项目来说，一些非常著名的源码开放的测试工具就足够了，比如：Java方面的单元测试工具JUnit和C++方面的单元测试工具CppUnit。关于验收测试方面，目前没有比较好的满足各方面需要通用的测试工具，不过使用脚本语言，循序渐进的自行开发一个适合自己的验收测试工具也不是一件困难的事情，一句话：只有提高了自身团队内在的素质，外在的工具才能够发挥作用。

误区之三：测试代码可以随意写

测试的目的是用来检验软件系统是否满足了需求。所以，你的测试代码一定要明确的表达出这一点来。就那上面的案例来说，如果测试者真正从用户的需求出发，那么他写出来的测试脚本肯定不会是那样的，而因该是每一个测试用例都清晰的刻画了一项用户的需求，然后检验系统是否实现了用户期望的功能。这样的测试才是有明确目的，才是最有效的测试。和把界面逻辑和应用逻辑隔离，采用明确表现用户需求测试用例进行测试相比，上面的测试方法不能不说是随意了一点。
如果能够在编写实际类前，首先编写针对该类的测试代码，情况就会有很大的不同，因为这会迫使你从类的使用者的角度去考虑问题。结果就是会把关注点放在类的易用性上，放在类的职责上面，放在类提供服务的涌谏厦妫皇悄持质迪窒附凇?br> 总之，测试代码的编写应该从被测试的对象是否满足需要的层面进行，而不是其他。

误区之四：单元测试和验收测试没有什么区别


单元测试可以类比为一个建筑的质检人员对建筑进行的检测， 他关注的重点是建筑的内部结构、地基、框架以及墙壁是否垂直等。他的检测是要保证建筑的各个部分是正常的、安全的，换句话说，就是要保证施工满足建筑上面的质量标准。验收测试可以类比为建筑的使用者来对建筑进行的检测。首先，他认为这个建筑是满足规定的工程质量的，这是有建筑的质检人员来保证的。使用者关注的重点是住在这个建筑的中的感受。他关心建筑的外观是否美观、各个房间的大小是否合适，窗户的位置是否合适，是否能够满足家庭的需要等。这里，建筑的使用者执行的就是验收测试，他是从用户的角度出发的。建筑的质检人员执行的就是单元测试，他是从构建者的角度出发的。
正是这种角度的不同决定了单元测试和验收测试之间的区别。它们是对系统的不同的方面进行的测试，二者是互相补充的。不管我们在系统的构建中使用了多么聪明的方法，不管我们的系统是多么的灵活，但是首先我们的产品必须是可用的，否则我们所做的就是浪费时间，从这一点上来说验收测试要比单元测试显得更加重要。
还以上一小节给出的案例为例，案例中所使用的测试方法仅仅是从系统是否健壮的角度出发进行的，即使系统从不崩溃也不能证明那是一个可用的系统。因为测试根本就不是从用户使用的角度出发的，测试者本应该和用户一起来编写验收测试。单元测试保证我们把事情作对，而验收测试则保证我们做正确的事情。