黑盒测试

　　黑盒测试把产品软件当成是一个黑箱子，只有出口和入口，测试过程中只要知道往黑盒中输入什么东西，知道黑盒会出来什么结果就可以了，不需要了解黑箱子里面是如果做的。

　　即测试人员不用费神去理解软件里面的具体构成和原理，只要像用户一样看待产品就可以了。

　　例如银行转账功能，不需要知道转账的具体实现代码是怎样工作的，只需要把自己想象成各种类型的用户，模拟多种转账情况看系统是否能正常转账即可。

　　但是仅仅像用户一样去测试又是不够的。如果只做黑盒测试，必然是存在一定的风险的。

　　例如某个安全性较高的软件系统，开发人员在设计程序时考虑到记录系统日志的必要性，把软件运行过程中的很多信息都记录到了客户端的系统日志中，甚至把软件客户端连接服务器端的数据库连接请求字符串也记录到系统日志中，这必然会泄漏重要的数据。

　　如果按照黑盒测试，这是程序内部的行为，用户不会直接操作数据库的连接行为，因此检查系统日志这方面的测试是不会做的，所以会形成一个隐藏BUG。

　　有人把黑盒测试比作中医，通过“望闻问切”来判断是否有问题。

　　“望”：观察软件的行为是否正常。

　　“闻”：检查输出的结果是否正确。

　　“问”：输入各种信息，结合“望”，“闻”来观察软件的响应。

　　“切”：像中医一样给软件“把把脉”，敲击一下软件的某些“关节”

白盒测试

　　上面把黑盒测试比喻为中医，那么白盒测试无疑就是西医了。测试人员需要采用各种仪器设备对软件进行检测，甚至把软件摆上手术台解剖来看个究竟。

　　白盒测试是一种以理解软件内部结构和程序运行方式为基础的软件测试技术。通常需要跟踪一个输入在程序中经过了哪些函数的处理，这些处理方式是否正确。

　　如果你是初级测试人员，你可能会认为，不懂代码的根本就做不了白盒测试，其实这种观点是有一定的错误的。

　　当然，会懂代码来做白盒测试，那肯定是最好的。但是一般做白盒测试，不需要读懂每一行程序代码。

　　如果把软件当成是一个黑箱子，那么白盒测试的关键就是给测试人员戴上一副X光透视眼镜，测试人员通过该眼镜可以看清楚给软件的输入在这个黑箱子中是如何运转的。

　　如果你不太懂代码，其实有很多像医院的检测仪器一样，可以帮助了解程序的内部运转过程。

　　例如：对于一个与SQL server数据库连接的软件系统，可以简单地把程序的作用理解为：把用户输入的数据通过SQL命令请求后台数据库，数据库把请求的数据返回给程序的界面层来展示给用户。SQL server自带的工具事件探查器则可以说是一个检查SQL数据传输的精密仪器，记录软件客户端与服务器数据库之间交互的一举一动，从而让测试人员可以洞悉软件究竟做了哪些动作。

　　在测试过程中，应该综合黑盒测试和白盒测试，不管使用哪种方法，能找到BUG就是好方法。一名优秀的测试人员，应该懂得使用各种各样的测试技术和找BUG的手段。

手工测试与自动化测试

　　有些人认为做手工测试是很简单的一件事，只需要点点点；而做自动化很难的事，很多人都避之不及。

　　其实，这两种方式都是需要结合使用。自动化不可以代替手工，手工测试具体不可替代性。

　　自动化测试是对手工测试的一种补充，主要应用在回归测试。主要集中在稳定的功能上面，帮助手工测试验证稳定模块的功能。

　　对于数据的正确性，界面美观，业务逻辑等的满足程度，自动化测试是做不了的，都需要由手工来做。毕竟机器是死的，人们对是非的判断，逻辑推理能力是工具不具备的。

　　自动化优势是借助计算机的计算能力，可以重复地、不知疲惫的进行，对于数据能进行精确的，大批量的比较，而且不会出错。

　　综上我们可以知道，手工测试和自动化测试一个都不能少，而且需要有机结合，充分利用优势，测试人员提供各种方法和手段。

探索性测试

　　探索性测试最直白的解释就是同时设计测试用例和执行测试。这种方法一般是测试经验丰富的测试人员使用，因为他们具备一定的测试经验，懂得哪些容易出现问题。

　　也可以在执行测试用例的过程中发现更多测试的途径。需要具备更多的发散思维。

　　探索性测试尤其适合需求不是很明确的测试任务，或者是一名刚刚接受一项新的测试任务的测试人员使用。

单元测试

　　单元测试，即针对的是软件设计中的最小单位--程序模块进行正确性检验的测试工作。其目的在于发现每个程序模块内部可能存在的差错。

　　单元测试应该由谁来做？

　　这里就分为了两派：

　　　　一派认为应该由开发来做；

　　　　因为代码是开发人员编写出来的，开发人员应该对自己所编写的代码负责，而且开发人员对于自己的代码熟悉程度最高，所以编写起来较测试人员容易，更可以得到优质的代码。

　　　　另外一派任务应该由测试人员来做；

　　　　因为开发人员不像测试人员有敏锐的测试思维，所以测试的没有测试人员精细，所以需要测试人员来做单元测试。

　　其实，这个问题都各持己见，但是最好的办法，就是双方合作。

　　即由测试人员设计测试用例，开发人员编写测试代码，测试人员执行测试用例。

单元级别的性能测试

　　性能测试是很多公司都忽略的问题，或者是等到程序已经开发完成之后才去测试的方向。

　　性能测试结果表名系统存在严重的性能问题，相应时间迟缓，内存占用过多，不能支持大量的数据请求，在大量用户并发访问的情况下系统崩溃。

　　如果当我们做完了整个系统的功能之后在发现以上的BUG，那么再去修改程序已经非常困难了，因为如果要彻底地解决性能问题，需要重新调整系统的架构设计，大量的代码需要重构，如果需要做调整，程序员不仅会疲惫，重新编写的程序也会引发大量的不稳定和BUG。

　　所以性能测试应该是贯穿软件的整个生产过程，包括架构设计、单元编码、集成、发布。

　　性能测试应该在单元测试阶段就开始，从代码的每一行效率，到一个方法的执行效率，再到一个逻辑实现的算法的效率；从代码的效率，到存储过程的效率，都应该进行优化。单元阶段的性能测试可以从以下几个方面进行考虑：

• 代码效率评估
• 应用单元性能测试工具
• 数据库优化

　　在代码的编写中，可能一个方法不会造成很大的问题，但是积少成多，就会成为大问题。这些问题可以通过代码走查来发现。如果测试人员不熟悉代码，可以使用代码标准检查工作，例如：FxCop,.TEST等来帮助自动查找类似的问题。

　　测试人员也可以使用一些代码效率测试工具来帮助找出哪些代码或者方法在执行时需要耗费比较长的时间，例如AQTime是一款可以计算出每行代码的执行时间工具。

　　除了代码行效率测试工具外，最近还出现了一些开源的单元级别的性能测试框架，可以像使用XUnit这一类的单元测试框架一样，但不是用于测试单元代码的正确性，而是用于测试函数，方法的性能是否满足要求。

例如NTime。它可以并发得运行同一个方法多次，看能否达到预期的性能指标。例如下面的代码使用NTime框架启动2个线程，在1秒钟内并发执行MyTest方法多次：

　　[TimerHitCountTest(98,Threads = 2,Unit = TimePeriod.Second)]

　　Public void MyTest()

　　{

　　　　　　//调用被测试的方法

　　　　　　MethodToBeTest();

　　}

　　如果测试结果表明能执行超过98次，则认为该方法的性能达标。反之则不达标。