黑盒测试和白盒测试的区别

一. 软件测试方法

1.        软件测试方法：白盒测试、黑盒测试、灰盒测试、静态测试、动态测试

2.        白盒测试：是一种测试用例设计方法，在这里盒子指的是被测试的软件，白盒，顾名思义即盒子是可视的，你能够清楚盒子内部的东西以及里面是如何运做的，所以白盒测试须要你对系统内部的结构和工做原理有一个清楚的了解，而且基于这个知识来设计你的用例。

白盒测试技术通常可被分为静态分析和动态分析两类技术。

静态分析主要有：控制流分析技术、数据流分析技术、信息流分析技术。

动态分析主要有：逻辑覆盖率测试(分支测试、路径测试等)，程序插装等。

白盒测试优势：迫使测试人员去仔细的思考软件的实现；能够检测代码中的每条分支和路径；揭示隐藏在代码中的错误；对代码的测试比较完全；最优化。

白盒测试缺点：昂贵；没法检测代码中遗漏的路径和数据敏感性错误；不验证规格的正确性。

3.        黑盒测试又叫功能测试，这是由于在黑盒测试中主要关注被测软件的功能实现，而不是内部逻辑。在黑盒测试中，被测对象的内部结构，运做状况对测试人员是不可见的，测试人员对被测产品的验证主要是根据其规格，验证其与规格的一致性。

在绝大多数没有用户参与的黑盒测试中，最多见的测试有：功能性测试、容量测试、安全性测试、负载测试、恢复性测试、标杆测试、稳定性测试、可靠性测试等。

4.        灰盒测试：白盒测试和黑盒测试每每不是决然分开的，通常在白盒测试中交叉使用黑盒测试的方法，在黑盒测试中交叉使用白盒测试的方法。灰盒测试就是这类界于白盒测试和黑盒测试之间的测试。

最多见的灰盒测试是集成测试。

5.        静态测试：是一种不经过执行程序而进行测试的技术。它的关键功能是检查软件的表示和描述是否一致，没有冲突或者没有歧义。

6.        动态测试：包含了程序在受控的环境下使用特定的指望结果进行正式的运行。它显示了一个系统在检查状态下是正确仍是不正确。

单元测试属于白盒测试范畴；集成测试属于灰盒测试范畴；系统测试属于黑盒测试范畴。

二.  单元测试

1.        概念：单元测试(Unit Testing)是对软件基本组成单元进行的测试，如函数或是一个类的方法。这里的单元，就是软件设计的最小单位。

单元测试的两个步骤：人工静态检查法与动态执行跟踪法。

人工静态检查是测试的第一步，这个阶段工做主要是保证代码算法的逻辑正确性（尽可能经过人工检查发现代码的逻辑错误）、清晰性、规范性、一致性、算法高效性，并尽量的发现程序中没有发现的错误。

第二步是经过设计测试用例，执行待测程序来跟踪比较实际结果与预期结果来发现错误。

2.      人工检查：

(1)、检查算法的逻辑正确性：肯定所编写的代码算法、数据结构定义（如：队列、堆栈等）是否实现了模块或方法所要求的功能。

(2)、模块接口的正确性检查：肯定形式参数个数、数据类型、顺序是否正确；肯定返回值类型及返回值的正确性。

(3)、输入参数有没有做正确性检查：若是没有做正确性检查，肯定该参数是否的确无需作参数正确性检查，不然请添加上参数的正确性检查。

(4)、调用其余方法接口的正确性：检查实参类型正确与否、传入的参数值正确与否、个数正确与否，特别是具备多态的方法。返回值正确与否，有没有误解返回值所表示的意思。最好对每一个被调用的方法的返回值用显示代码做正确性检查，若是被调用方法出现异常或错误程序应该给予反馈，并添加适当的出错处理代码。

(5)、出错处理：模块代码要求能预见出错的条件，并设置适当的出错处理，以便一旦程序出错时，能对出错程序重作安排，保证其逻辑的正确性，这种出错处理应当是模块功能的一部分。若出现下列状况之一，则代表模块的错误处理功能包含有错误或缺陷：出错的描述难以理解；出错的描述不足以对错误定位，不足以肯定出错的缘由；显示的错误信息与实际的错误缘由不符；对错误条件的处理不正确；在对错误进行处理以前，错误条件已经引发系统的干预等。

(6)、保证表达式、SQL语句的正确性：检查所编写的SQL语句的语法、逻辑的正确性。对表达式应该保证不含二义性，对于容易产生歧义的表达式或运算符优先级（如：<、=、 >、 &&、||、++、 --等）能够采用扩号“（）”运算符避免二义性，这样一方面可以保证代码的正确可靠，同时也可以提升代码的可读性。

(7)、检查常量或全局变量使用的正确性：肯定所使用的常量或全局变量的取值和数值、数据类型；保证常量每次引用同它的取值、数值和类型的一致性。

(8)、表示符定义的规范一致性：保证变量命名可以见名知意，而且简洁但不宜过长或太短、规范、容易记忆、最好可以拼读。并尽可能保证用相同的表示符表明相同功能，不要将不一样的功能用相同的表示符表示；更不要用相同的表示符表明不一样的功能意义。

(9)、程序风格的一致性、规范性：代码必须能保证符合企业规范，保证全部成员的代码风格一致、规范、工整。例如对数组作循环，不要一下子采用下标变量从下到上的方式（如:for(i=0;i++;i<10)），一下子又采用从上到下的方式(如:for(i=10;i--;i>0))；应该尽可能采用统一的方式，或则统一从下到上，或则统一从上到下。建议采用for循环和While循环，不要采用do{}while循环等。

(10)、检查程序中使用到的神秘数字是否采用了表示符定义：神秘的数字包括各类常数、数组的大小、字符位置、变换因子以及程序中出现的其余以文字形式写出的数值。在程序源代码里，一个具备本来形式的数对其自己的重要性或做用没提供任何指示性信息，它们也致使程序难以理解和修改。对于这类神秘数字必须采用相应的标量来表示；若是该数字在整个系统中均可能使用到务必将它定义为全局常量；若是该神秘数字在一个类中使用可将其定义为类的属性（Attribute）,若是该神秘数字只在一个方法中出现务必将其定义为局部变量或常量。

(11)、检查代码是否能够优化、算法效率是否最高：如：SQL语句是否能够优化，是否能够用1条SQL语句代替程序中的多条SQL语句的功能，循环是否必要，循环中的语句是否能够抽出到循环以外等。

(12)、检查您的程序是否清晰简洁容易理解：注意：冗长的程序并不必定不是清晰的。

(13)、检查方法内部注释是否完整：是否清晰简洁；是否正确的反映了代码的功能，错误的注释比没有注释更糟；是否作了多余的注释；对于简单的一看就懂的代码没有必要注释。

(14)、检查注释文档是否完整：对包、类、属性、方法功能、参数、返回值的注释是否正确且容易理解；是否会落了或多了某个参数的注释，参数类型是否正确，参数的限定值是否正确。特别是对于形式参数与返回值中关于神秘数值的注释，如：类型参数 应该指出 1.表明什么，2.表明什么，3.表明什么等。对于返回结果集(Result Set)的注释，应该注释结果集中包含那些字段及字段类型、字段顺序等。

3.        动态执行跟踪：动态执行测试一般分为黑盒测试与白盒测试。对于单元测试来讲主要应该采用白盒测试法对每一个模块的内部做跟踪检查测试。对于单元白盒测试，应该对程序模块进行以下检查：(1)、对模块内全部独立的执行路径至少测试一次；(2)、对全部的逻辑断定，取“真”与“假”的两种状况都至少执行一次；(3)、在循环的边界和运行界限内执行循环体；(4)、测试内部数据的有效性等等。

4.      单元测试的目的：在于发现各模块内部可能存在的各类错误，主要是基于白盒测试。

单元测试的目的主要有3方面：验证单元代码和详细设计文档的一致性；跟踪详细设计文档中设计的实现，发现详细设计文档中存在的错误；发如今编码过程当中引入的错误。

5.        单元的常见错误：(1)、单元接口；(2)、局部数据结构；(3)、独立路径；(4)、出错处理；(5)、边界条件。

6.        单元测试策略：有三种，独立的单元测试策略，自顶向下的单元测试策略和自底向上的单元测试策略。

独立的测试策略：不考虑每一个模块与其余模块之间的关系，为每一个模块设计桩模块和驱动模块。每一个模块进行独立的单元测试。

自顶向下的测试策略：先对最顶层的单元进行测试，把顶层所调用的单元作成桩模块。其次对第二层进行测试，使用上面已测试的单元作驱动模块。如此类推直到测试完全部模块。

自底向上测试：先对模块调用层次图上最低层的模块进行单元测试，模拟调用该模块的模块作驱动模块。而后再对上面一层作单元测试，用下面已被测试过的模块作桩模块。依次类推，直到测试完全部模块。

7.        单元测试过程：计划(测什么)、设计(测试方案、策略)、实现(写测试用例、代码)、执行(测试报告)四个阶段。

8.        单元测试的原则：(1)、对全新的代码或修改过的代码进行单元测试；(2)、单元测试根据单元测试计划和方案进行，排除测试的随意性；(3)、必须保证单元测试计划、单元测试方案、单元测试用例等通过评审；(4)、当测试用例的测试结果与预期结果不一致时，单元测试的执行人员需如实记录实际的测试结果；(5)、只有当测试计划中的结束标准达到时，单元测试才能结束；(6)、对被测试单元需达到的必定的代码覆盖率要求。

三.  测试用例

1.        简介：测试用例(Test Case)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否知足某个特定需求。也指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并造成文档。

不一样类别的软件，测试用例是不一样的。

2.        概述：测试用例构成了设计和制定测试过程的基础。测试的“深度”与测试用例的数量成比例。因为每一个测试用例反映不一样的场景、条件或经由产品的事件流，于是，随着测试用例数量的增长，你对产品质量和测试流程也就越有信心。

判断测试是否彻底的一个主要评测方法是基于需求的覆盖，而这又是以肯定、实施和/或执行的测试用例的数量为依据的。

测试工做量与测试用例的数量成比例。最佳方案是为每一个测试需求至少编制两个测试用例。一个测试用例用于证实该需求已经知足，一般称做正面测试用例。另外一个测试用例反映某个没法接受、反常或意外的条件或数据，用于论证只有在所需条件下才可以知足该需求，这个测试用例称做负面测试用例。

3.      设计方法：

(1)、白盒技术：白盒测试是结构测试，因此被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例。

白盒测试的测试用例设计：通常采用逻辑覆盖法和基本路径法进行设计。

逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计技术，这一方法要求测试人员对程序的逻辑结构有清楚的了解。逻辑覆盖可分为：语句覆盖、断定覆盖、条件覆盖、断定-条件覆盖、条件组合覆盖与路径覆盖。

语句覆盖：在测试时，首先设计若干个测试用例，而后运行被测程序，使程序中的每一个可执行语句至少执行一次。

断定覆盖法：在测试时，首先设计若干个测试用例，而后运行被测程序，使得程序中的每一个判断的取真分支和取假分支至少经历一次，即判断的真假值均曾被知足。

条件覆盖法：在测试时，首先设计若干个测试用例，而后运行被测程序，要使每一个判断中每一个条件的可能取值至少知足一次。

断定条件覆盖法：在测试时，首先设计若干个测试用例，而后运行被测程序，使得判断中每一个条件的全部可能至少出现一次，而且每一个判断自己的断定结果至少出现一次。

路径覆盖法：在测试时，首先设计若干个测试用例，而后运行被测程序，要求覆盖程序中全部可能的路径。

基本路径覆盖法：是在程序控制流图的基础上，经过分析控制结构的环路复杂性，导出基本可执行路径集合，设计测试用例的方法。该方法把覆盖的路径数压缩到必定限度内，程序中的循环体最多只执行一次。设计出的测试用例要保证在测试中，程序的每个可执行语句至少执行一次。

循环路径测试：基本路径覆盖法将循环限制在最多一次，这样虽然大大下降了须要覆盖的路径的条数，但对循环的测试却不充分了，所以还须要对循环路径进行测试。循环路径测试包含，简单循环的测试和嵌套循环的测试。

每一种覆盖方法都有其优缺点。一般在设计测试用例时应该根据代码模块的复杂度，选择覆盖方法。通常的代码的复杂度与测试用例设计的复杂度成正比。所以，设计人员必须作到模块或方法功能的单一性、高内聚性，使得方法或函数代码尽量的简单；这样将可大大提升测试用例设计的容易度，提升测试用例的覆盖程度。

基本路径测试法是在程序控制流图的基础上，经过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每一个可执行语句至少执行一次。基本路径测试法包括如下5个方面：(1)、程序的控制流图：描述程序控制流的一种图示方法；(2)、程序环境复杂性：McCabe复杂性度量；从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是肯定程序中每一个可执行语句至少执行依次所必须的测试用例数目的上界；(3)、导出测试用例；(4)、准备测试用例，确保基本路径集中的每一条路径的执行；(5)、图形矩阵：是在基本路径测试中起辅助做用的软件工具，利用它能够实现自动地肯定一个基本路径集。

另外，对于测试用例的选择除了知足所选择的覆盖程度（或覆盖标准）外还须要尽量的采用边界值分析法、错误推测法等经常使用地设计方法。采用边界值分析法设计合理的输入条件与不合理的输入条件；条件边界测试用例应该包括输入参数的边界与条件边界（if,while，for，switch ,SQL Where子句等）。错误推测法，列举出程序中全部可能的错误和容易发生错误的特殊状况，根据它们选择测试用例；在编码、单元测试阶段能够发现不少常见的错误和疑似错误，对于这些错误应该做重点测试，并设计相应的测试用例。

(2)、黑盒技术：等价划分类、边界值分析、错误推测、因果图、综合策略

4.        测试类设计：一个模块或一个方法（Method）并非一个独立的程序，在考虑测试它时要同时考虑它和外界的联系，用些辅助模块去模拟与所测模块相联系的其余模块。这些辅助模块分为两种：

(1)、驱动模块（driver）：至关于所测模块的主程序。它接收测试数据，把这些数据传送给所测模块，最后再输出实际测试结果；

(2)、桩模块（stub）:用于代替所测模块调用的子模块。桩模块能够作少许的数据操做，不须要把子模块全部功能都带进来，但不允许什么事情也不作。

打桩：通常在作单元或集成测试时，若是某个程序单元的某条语句，须要调用的一个外部函数尚未设计、编码、调试完成的话，能够只让它简单地返回几个支持测试用例的值就能够了，这种状态的外部函数通常就叫作“打桩”。

所测模块与它相关的驱动模块及桩模块共同构成了一个“测试环境”。

驱动模块和桩模块的编写会给测试带来额外的开销。由于它们在软件交付时并不做为产品的一部分一同交付，并且它们的编写须要必定的工做量。特别是桩模块，不能只简单地给出“曾经进入”的信息。为了可以正确的测试软件，桩模块可能须要模拟实际子模块的功能，这样桩模块的创建就不是很轻松了。

编写桩模块是困难费时的，其实也是彻底能够避免编写桩模块的；只需在项目进度管理时将实际桩模块的代码编写工做安排在被测模块前编写便可。并且这样能够提升测试工做的效率，提升实际桩模块的测试频率从而更有效的保证产品的质量。可是，为了保证可以向上一层级提供稳定可靠的实际桩模块，为后续模块测试打下良好的基础，驱动模块仍是必不可少的。

对于每个包或子系统咱们能够根据所编写的测试用例来编写一个测试模块类来作驱动模块，用于测试包中全部的待测试模块。而最好不要在每一个类中用一个测试函数的方法，来测试跟踪类中全部的方法。这样的好处在于：(1)、可以同时测试包中全部的方法或模块，也能够方便的测试跟踪指定的模块或方法；(2)、可以联合使用全部测试用例对同一段代码执行测试，发现问题；(3)、便以回归测试，当某个模块做了修改以后，只要执行测试类就能够执行全部被测的模块或方法。这样不但可以方便得检查、跟踪所修改的代码，并且可以检查出修改对包内相关模块或方法所形成的影响，使修改引进的错误得以及时发现；(4)、复用测试方法，使测试单元保持持久性，并能够用既有的测试来编写相关测试；(5)、将测试代码与产品代码分开，使代码更清晰、简洁；提升测试代码与被测代码的可维护性。

5.        跟踪调试：跟踪调试不可是深刻测试代码的最佳方法，并且也是程序调试发现错误根源的有利工具。测试类设计完成后，最好能借助代码排错工具来跟踪调试待测代码段以深刻的检查代码的逻辑错误。现有的代码开发工具（如:JBuilder）通常都集成了这类排错工具。排错工具通常由执行控制程序、执行状态查询程序、跟踪程序组成。执行控制程序包括断点定义、断点撤销、单步执行、断点执行、条件执行等功能。执行状态查询程序包括寄存器、堆栈状态、变量、代码等与程序相关的各类状态信息的查询。跟踪程序用以跟踪程序执行过程当中所经历的事件序列（如：分支、子程序调用等）。程序员可经过对程序执行过程当中各类状态的判别进行程序错误的识别、定位及改正。

对于模块的单元跟踪调试最好可以作到：每次修改被测模块后，都将全部测试用例跟踪执行一遍以排除全部可能出现或引进的错误。在时间有限的状况下也必须调用驱动模块对全部的测试用例执行一次，并对出现错误或异常的测试用例跟踪执行一次，以发现问题的根源。

排错过程每每是一个艰苦的过程，特别是那种算法复杂、调用子模块较多的模块，对于错误的定位来讲并非件容易的事情。尽管排错不是一门好学的技术（有时人们更愿意称之为艺术），但仍是有若干行之有效的方法和策略，下面介绍几种排错时应该采用的方法策略：(1)、断点设置，设置断点对源程序实行断点跟踪将可以大大提升排错的效率。一般断点的设置除了根据经验与错误信息来设置外，还应重点考虑如下几种类行的语句：A、函数调用语句。子函数的调用语句是测试的重点，一方面因为在调用子函数时可能引发接口引用错误，另外一方面多是子函数自己的错误；B、断定转移/循环语句。断定语句经常会因为边界值与比较优先级等问题引发错误或失效而做出错误的转移。所以，对于断定转移/循环语句也是一个重要的测试点；C、SQL语句。对于数据库的应用程序来讲，SQL语句经常会在模块中占比较重要的业务逻辑，并且比较复杂。所以，它也属于比较容易出现错误的语句；D、复杂算法段。出错的几率常与算法的复杂度成正比。因此越复杂的算法越须要做重点跟踪，如递归、回朔等算法。(2)、可疑变量查看，在跟踪执行状态下当程序中止在某条语句时可查看变量的当前值和对象的当前属性。经过对比这些变量当前值与预期值能够轻松的定位程序问题根源；(3)、SQL语句执行检查，在跟踪执行或运行状态下将疑似错误的SQL语句打印出来，从新在数据库SQL查询分析器（如：Oracle SQL Plus）中跟踪执行能够较高效的检查纠正SQL语句错误；(4)、注意群集现象，经验代表测试后程序中残存的错误数目与该程序中已发现的错误数目或检错率成正比。根据这个规律，应当对错误群集的程序段进行重点测试，以提升测试投资的效益。若是发现某一代码段彷佛比其余程序模块更多的错误倾向时，则应当花费较多的时间和代价测试这个程序模块。

6.        测试用例设计的基本原则：(1)、一个好的测试用例在于可以发现至今没有发现的错误；(2)、测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成；(3)、在测试用例设计时，应当包含合理的输入条件和不合理的输入条件。

7.      测试用例的具体作法：

(1)、测试用例文档：编写测试用例文档应有文档模板，须符合内部的规范要求。

(2)、测试用例的设置：按功能设置用例、按路径设置用例、按功能、路径混合模式设置用例；

(3)、设计测试用例：测试用例能够分为基本事件、备选事件和异常事件。

四.   白盒测试

1.      白盒测试通常包括如下几项：

(1)、目的：保证程序建立的类与接口的完整与正确，以及程序模块单独正常运行。保证局部模块功能完备性，运行正确性与稳定性。

         (2)、测试项：所要测试的类。

         (3)、测试依据：A、需求规格说明书、用例描述清单；B、设计文档；C、编码规范；D、开发命名标准。

         (4)、经过的准则：建立的类、接口、方法、属性应与《设计文档》保持一致；程序的各类命名、注释、代码行的格式等应符合《程序开发命名标准》和《编码规范》；程序模块能独立稳定运行。

         (5)、测试环境配置：A、测试工具；B、软件环境。

2.      测试步骤：

(1)、配置好测试环境；

(2)、编写测试用例；

(3)、静态测试、走查代码；

(4)、动态测试；

(5)、肯定问题属性：分为四类，错误、缺陷、失效、故障。

错误是指计算值、观测值、测量值之间，或条件与真值之间，不符合规定的或理论上的正确值或条件。

缺陷是指与指望值或特征值的误差。

故障是指功能部件不能执行所要求的功能。故障可能由错误、缺陷或失效引发。

失效是指功能部件执行其功能的能力丧失，系统或系统部件丧失了在规定限度内执行所要求功能的能力。

(6)、肯定问题类别；

(7)、填写测试报告。

3.        白盒测试和单元测试的区别：(1)、测试目的：一个是测试程序的总体逻辑，另外一个是测试程序中一个独立的模块；(2)、一般的执行人员不同：白盒通常由专门的白盒测试人员完成，单元测试通常由程序员本身完成。