程序测试概论与单元测试详解

本篇内容全部搜集整理自网络资源

    程序测试(program testing)是指对一个完成了全部或部分功能、模块的计算机程序在正式使用前的检测，以确保该程序能按预定的方式正确地运行。
     软件测试所追求的是以尽可能少的时间和人力发现软件产品尽可能多的错误。

测试方法：

     白盒测试：又称结构测试，前提是测试者完全知道程序的结构和处理算法，可以把程序看成在一个透明的白盒子里。按照程序内部逻辑设计测试用例，检测程序中的主要执行通路是否能按照预定要求正确工作。

     黑盒测试：根据关键需求说明书所规定的功能来设计测试用例，它不考虑软件的内部结构和处理算法。

     灰盒测试：是一种介于白盒测试与黑盒测试之间的测试方法。灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。

测试流程：

   从测试流程的角度划分，软件测试可分为单元测试、集成测试和确认测试。

    单元测试：也称模块测试，通常放在编程阶段，由程序员对自己编写的模块自行测试，检查模块是否实现了详细设计说明书中规定的功能和算法。

单元测试计划应该在详细设计阶段制定。

 集成测试：集成测试（integrationtesting），也称组装测试，它是对由各模块组装而成的程序进行测试，主要目标是发现模块间的接口和通信问题。

集成测试计划应该在概要设计阶段制定。

    确认测试：主要依据软件需求说明书检查软件的功能、性能及其他特征是否与用户的需求一致。

确认测试计划应该在需求分析阶段制定。

单元测试：

      单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

    谁来做：单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。

    目的：

执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。程序员通常边编写代码边测试结果，只 是进行临时单元测试，针对代码的测试很不完整，代码测试的覆盖率超过70%都很困难，未覆盖的代码可能遗留大量的细小的错误，这些错误还会互相影响，当BUG暴露出来的时候难于调试，大幅度提高后期测试和维护成本，也降低了软件开发商的竞争力。

对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。

要进行充分的单元测试，应专门编写测试代码，并与产品代码隔离。比较简单的办法是为产品工程建立对应的测试工程，为每个类建立对应的测试类，为每个函数（很简单的除外）建立测试函数。

单元测试的好处：

提高开发速度——测试是以自动化方式执行的，提升了测试代码的执行效率。

提高软件代码质量——它使用小版本发布至集成，便于实现人员除错。同时引入重构概念，让代码更干净和富有弹性。

提升系统的可信赖度——它是回归测试的一种。支持修复或更正后的“再测试”，可确保代码的正确性。

单元测试的时机：

单元测试越早越好，根据极限编程（Extreme Programming,或简称XP）所推崇的测试驱动开发的思想，即先编写测试代码再进行开发。从经验来看，先编写产品函数的框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码，每写一个功能点都运行测试，随时补充测试用例。所谓先编写产品函数的框架，是指先编写函数空的实现，有返回值的直接返回一个合适值，编译通过后再编写测试代码，这时，函数名、参数表、返回类型都应该确定下来了，所编写的测试代码以后需修改的可能性比较小。

成本效率：

一个特定的开发组织或软件应用系统的测试水平取决于对那些未发现的Bug的潜在后果的重视程度。这种后果的严重程度可以从一个Bug引起的小小的不便到发生多次的死机的情况。这种后果可能常常会被软件的开发人员所忽视（但是用户可不会这样），这种情况会长期的损害这些向用户提交带有Bug的软件的开发组织的信誉，并且会导致对未来的市场产生负面的影响。相反地，一个可靠的软件系统的良好的声誉将有助于一个开发组织获取未来的市场。

很多研究成果表明，无论什么时候作出修改都需要进行完整的回归测试，在生命周期中尽早地对软件产品进行测试将使效率和质量都得到最好的保证。Bug发现的越晚，修改它所需的费用就越高，因此从经济角度来看， 应该尽可能早的查找和修改Bug。在修改费用变的过高之前，单元测试是一个在早期抓住Bug的机会。

相比后阶段的测试，单元测试的创建更简单，维护更容易，并且可以更方便的进行重复。从全程的费用来考虑，相比起那些复杂且旷日持久的集成测试，或是不稳定的软件系统来说，单元测试所需的费用是很低的。

优点：

1、它是一种验证行为。程序中的每一项行为都是用来测试和验证被测程序的正确性。它为以后的开发提供了支援和保障，就算是开发后期，依旧可以轻松的增加功能或改进程序结构，而不用担心这个过程中会破坏重要的东西；而且它为代码的重构提供了保障，这样可以更自由的对程序进行改进。

2、它是一种设计行为。编写单元测试将使我们从调用者的角度观察、思考、设计以及编写我们的程序；特别是先写测试，将迫使我们把程序设计成易于调用和可测试的形式，可以帮助我们软件中独立单元之间的耦合性。

3、它是一种编写文档的行为。单元测试是一种无价的文档，它是展示函数或类如何使用的最佳文档；这份文档是可编译、可运行的，并且它保持最新，永远与代码同步。

4、它具有回归性。自动化的单元测试可避免代码出现回归，编写完成之后，可以随时随地的快速运行测试。