1. 黑盒测试和白盒测试的直观图

　　从图中可以直接看出来，黑盒测试就当整个程序是个黑盒子，我们看不到它里面做了些什么事情，只能通过输入输出看是否能得到我们所需的来测试。而白盒测试可以当盒子是透明的，里面的一切我们都看的清楚，从而我们可以通过去测内部结构来测试。　　

2. 黑盒测试 (Black-Box Testing)

　　黑盒测试又称为功能测试、数据驱动测试或基于规格说明书的测试，是一种从用户观点出发的测试。测试人员一般把被测程序当作一个黑盒子。

　　黑盒测试主要测到的错误类型有：不正确或遗漏的功能；接口、界面错误；性能错误；数据结构或外部数据访问错误；初始化或终止条件错误等等。

　　常用的黑盒测试方法有：等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。

　　· 等价类划分法

　　　　等价类分为有效等价类和无效等价类，其中，有效等价类是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合；而无效等价类是指对于程序的规格说明来说是不合理的，没有意义的输入数据构成的集合。

　　　　确定等价类的原则是：a. 在输入条件规定了取值范围或值的个数的情况下，则可以确定一个有效等价类和两个无效等价类，比如若规定的输入范围是1<x<10的所有数，则有效的是1~10内的任意数，而无效的是 -∞~0.9999 和10.00001~+∞; b. 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，则可以确立一个有效等价类和一个无效等价类；c.在输入条件是一个布尔量的情况下，可以确定一个有效的等价类和一个无效的等价类；d. 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可以确立n个有效等价类和一个无效等价类；e. 在规定了输入数据必须遵守的规则的情况下，可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；f.在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将改等价类进一步的划分为更小的等价类。

　　· 边界值分析法

　　　　根据经验法则，大量的错误是发生在输入或输出范围的边界上的，而不是发生在输入输出范围的内部。因此针对各种边界情况涉及测试用例，可以查出更多的错误。而使用边界值的分析方法涉及测试用例，首先应确定边界情况。通常输入和输出等价类的边界，应当选取正好等于，刚刚大于或者刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

　　　　边界值选择的原则： a. 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围的边界的值作为测试输入数据。 例如，如果程序的规格说明中规定：“重量在10公斤至50公斤范围内的邮件，其邮费计算公式为……”。作为测试用例，我们应取10及50，还应取10.01,49.99,9.99及50.01等；b. 如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数小一，和比最大个数大一的数作为测试数据。例如，一个输入文件应包括1~255个记录，则测试用例可取1和255，还应取0及256等。c. 将前面两个原则应用于输出条件，即涉及测试用例使输出值达到边界值及其左右的值。d.如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。e. 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例数据；f. 分析规格说明，找出其他可能的边界条件。

　　· 因果图法

　　　　因果图是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

　　　　利用因果图生成测试用例的基本步骤有：1. 分析软件规格说明描述中哪些是原因（输入，包括前提条件，操作过程），哪些是结果（输出），并给每个原因和结果赋予一个标识符；2. 分析软件规格说明描述的语义，找出原因和结果之间，原因和原因之间的关系，根据这些关系，画出因果图；3. 在因果图上用一些记号表明约束或限制条件；4. 把因果图转换为判定表；5. 把判定表的每一列拿出来作为依据，设计测试用例。

　　　　因果图的基本符号和约束符号：

　　　　

　　· 场景法

　　　　场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。其中，基本流就是正常的，正确场景；备选流一般指中断操作的。

　　· 正交实验设计法

　　　　使用正交试验设计法首先要知道正交表，正交表是研究多因素多水平的一种设计方法，它是格局正交性从全面试验中挑选出部分有代表性的点进行试验，这些有代表性的点具备了“均匀分散，齐整可比”的特点，正交试验设计是一种基于正交表的、高效率、快速、经济的试验设计方法。正交表由三个成分构成，Runs:正交表的行数，即实验的次数；Factors：正交表的列数，即因素数；Levels:水平数，任何单个因素能够取得的值的最大个数。 正交表的表现形式是：  L行数 (水平数因素数)   L runs（levels^factors  ）。

　　　　用正交表设计测试用例的步骤： 1. 有哪些因素（变量）； 2.每个因素有那几个水平（变量的取值）：用等价类划分出来的；3. 选择一个合适的正交表；4. 把变量的值映射到表中；5. 把每一行的各因素水平的组合作为一个测试用例；6. 加上你认为可以且没有在表中出现的组合。

　　　　如何选择正交表呢？取行数最少的一个，情况分三种：1.因素数（变量）、水平数（变量值）相符；2. 因素数不相同: 取因素数最接近但略大的实际值的表；3. 水平数不相同: 有五个因素（变量）A、B、C、D和E。两个因素有两个水平（变量的取值）、两个因素有三个水平，一个因素有六个水平。行数取最少的一个（ 行数取最少的一个（L49(78)、 L18（3661）

　　· 判定表驱动分析法

　　　　判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。判定表由以下部分构成： 1. 条件桩（Condition Stub）：列出了问题的所有条件。通常认为列出的条件的次序无关紧要； 2. 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束；3. 条件项（Condition Entry）：列出针对它左列条件的取值在所有可能情况下的真假值； 4. 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

 

　　· 错误推测法

　　　　错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况, 根据它们选择测试用例。

　　　　最后，对于黑盒测试的综合策略是：首先，考虑边界值分析法，边界值分析法是在任何情况下都必须使用的方法，因为经验表明这种方法设计的测试用例发现程序错误的能力最强。必要时用等价类划分方法补充一些测试用例。其次，可以用错误推测法再追加一些测试用例。这时，可以对照程序逻辑，检查已设计出的测试用例的逻辑覆盖率，如果没有达到要求的覆盖标准，应当再补充足够的测试用例；如果程序的功能说明中含有输入条件的组合情况，则一开始就可以选用因果图法。

3. 白盒测试 (White-Box Testing)

　　为什么要考虑白盒测试呢？举个栗子说明，设x=0,y=5, 程序设计z=y/x, 如果只考虑输入输出的黑盒测试，我们看不出程序内部的逻辑错误(分母不能为零)，即使我们使用黑盒测试的测试用例覆盖的再全也发现不了这个问题，这个时候就要考虑使用白盒测试了。

　　而什么是白盒测试呢？白盒测试也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但仍然有可能存在错误。因为：穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序；穷举路径测试不可能检查出程序因为遗漏路径而出错；穷举路径测试发现不了一些与数据相关的错误。

　　白盒测试需要遵循的原则有： 1. 保证一个模块中的所有独立路径至少被测试一次；2. 所有逻辑值均需要测试真（true）和假（false）；两种情况；3. 检查程序的内部数据结构，保证其结构的有效性；4. 在上下边界及可操作范围内运行所有循环。

　　白盒测试方法有：

　　· 静态测试&动态测试

　　静态测试是不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。动态测试则需要执行代码，也是我们用的最多的一种测试，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。

　　· 单元测试

　　· 代码检查

　　· 同行评审

　　· 技术评审

　　要检验测试的效果，就要去看测试的覆盖率，当覆盖率越大，说明测试成效越好，软件的缺陷越少。但覆盖率不是目标（质量才是目标）而只是一种手段。测试覆盖率包括功能点覆盖率和结构覆盖率，其中，功能点覆盖率大致用于表示软件已经实现的功能与软件需要实现的功能之间的比例关系；而结构覆盖率包括语句覆盖率、分支覆盖率、循环覆盖率和路径覆盖率等等。

　　而逻辑覆盖法中根据覆盖目标的不同和覆盖源程序语句的详尽程度，逻辑覆盖又可分为：语句覆盖； 判定覆盖；条件覆盖；判定/条件覆盖；组合覆盖；路径覆盖，且这些覆盖程度越往后越全。

4. 灰盒测试 (Gray-Box Testing)

　　灰盒测试更像是白盒测试和黑盒测试的混合测试，现阶段对灰盒测试没有更明确的定义，但更多的时候，我们的测试做的就是灰盒测试，即既会做黑盒测试又会做白盒测试。

总结：

       黑盒测试就是不看代码测试，模拟最真实的用户使用环境。

       白盒测试是看代码测试，结合测试结果和代码逻辑来测试，有时候这种方式更能发现、找出问题，尤其是一些潜伏性bug。

        灰盒测试介于白盒测试与黑盒测试之间的一种测试方法，灰盒测试多用于集成测试阶段，它不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。灰盒测试看作是白盒测试和黑盒的结合体。