黑盒测试与白盒测试查看源代码的思想不同，即通常所说的将系统看做黑盒子，不去考虑具体的代码，而只是根据本段代码要实现的功能需求，进行测试数据的输入，比较结果的输出是否符合预期的输出。
黑盒测试一般要晚于白盒测试，但这并不意味着黑盒测试就不重要。因为经过实践证明，软件大部分的错误是在黑盒测试的过程中发现的。通过本章的学习，将明确黑盒测试的概念，黑盒测试与功能测试的关系，功能测试概念及方法、功能测试最佳实践的指导思想等内容。
1.1 黑盒测试
1.1.1 黑盒测试概念
黑盒测试是将软件看做不透明的黑盒子，完全不考虑软件内部结构和处理算法，只检查软件功能是否按照软件需求说明书正常使用、运行，检查当软件接收数据后是否得到相应的输出，即根据输入输出来判断该模块功能是否正确。
功能测试的目标是整个软件测试目标的具体化，即以最小的代价发现软件产品中最多的功能性错误。
这是黑盒测试被广泛认可的解释。黑盒测试的定义在具体划分时，有广义、狭义之分：第一，广义上的黑盒测试是所有不看源代码的测试方法的总称，其涉及范围很广如功能测试、性能测试等；第二，狭义上的黑盒测试特指功能测试，通过将软件看做黑盒子,主要测试某个软件或者软件的某个模块的功能是否得到实现。性能测试有自己独特的方法和工具，与功能测试的方法和工具不尽相同，因此没有列入狭义的黑盒测试的概念的范畴。
1.2 功能测试
1.2.1 功能测试方法简介
功能测试能够发现较多的错误，同时针对功能测试提出的方法也比较多。其主要方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法等等。
这里重点介绍较为常用的等价类划分法和边界值分析法。
1.2.2 等价类划分法
等价类划分法是把程序的输入域划分成若干由相似属性数据组成的子集，然后从每个子集中选取少数代表性数据作为测试用例。这些代表性数据在测试中的作用等价于其所对应子集中的其他数据。我们称这些代表性数据为等价类。
等价类有两种:有效等价类和无效等价类。有效等价类是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能；无效等价类是指对于程序的规格说明来说是不合理的、没有意义的输入数据构成的集合。
设计测试用例时，要同时考虑这两种等价类。因为，软件不仅要能接收合理的数据,也要能经受意外的考验。这样的功能测试才能确保软件具有更高的质量。
指导划分等价类的六大原则如下。
- 在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。
例：输入值是学生成绩g，范围是0～100，则可以确定一个有效等价类：0<=g<=100；两个无效等价类：g<0和g>100。 - 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类。
例：输入值是学生成绩g，必须大于0，则可以确定一个有效等价类：0<g；一个无效等价类：g<0。 - 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。布尔量是一个二值枚举类型，一个布尔量具有两种状态：true和false。
例：输入值g代表学生是否为团员，g是布尔变量，值为1代表是，值为0代表不是，则可以确定一个有效等价类：g=1；一个无效等价类：g=0。 - 在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
例：输入条件说明输入课程类别为：数学、英语、语文三种之一，则分别取这三种三个值为三个有效等价类，另外把三种类别之外的任何字符作为无效等价类。 - 在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
例：输入值是学生学号g，必须满足是6位数字，则可以确定一个有效等价类：g是6为数字；若干个无效等价类，比如，g是非6位数字或者g是6位字母等等。 - 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。
例：输入值是学生成绩g，范围是0～100，则可以确定一个有效等价类：0<=g<=100；两个无效等价类：g<0和g>100。这时要求成绩小于60的均输入不及格，将有效等价类划分为更小的等价类，其中0<=g<60为一个等价类，60<g<=100为一个等价类。
1.2.3 边界值分析法
根据大量的测试统计数据，很多错误是发生在输入或输出范围的边界上，而不是发生在输入/输出范围的中间区域。因此针对各种边界情况设计测试用例，可以查出更多的错误。
边界值分析法就是对输入或输出的边界值进行测试的一种功能测试方法。通常边界值分析法是作为对等价类划分法的补充。这种情况下，其测试用例来自边界。
使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
基于边界值分析方法选择等价类的原则如下。
- 如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。
例如，如果程序的规格说明中规定：“成绩为0-60的学生，我们要……”。作为测试用例，我们应取0及60，还应取-0.1,0.1,59.9及60.1等。 - 如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。
例如，一个输入文件应包括1~255个记录，则测试用例可取1和255，还应取0及256等。 - 将规则1和2应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。
例如，某程序计算20以内两个自然数的和，则要设计测试用例使得相加结果为0,1,39和40，可取0与0,0与1,20与19,20与20作为四组测试用例。 - 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
例如，某程序的规格说明要求计算出“每年的学费扣除额为5300.0-5600.0”，其测试用例可取5300.0及5599.9、还可取5300.1及5600.1等。 - 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。
例如，某程序使用了数组，则可以选取“0”和“数组长度减1”作为测试用例。 - 分析规格说明，找出其它可能的边界条件。
例如，某程序的规格说明要求某物品在常温下保存，这时查询相关行业常温的范围要求，比如药品的常温指10~30℃，然后根据以上规则，可分别选取温度为9,10,11，20,29,30,31为测试用例，查看相应的输出是否符合需求。
1.2.4 其它功能测试方法简介
错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。通过错误推测法可以提前预测容易出现错误的地方，有时能大大提高测试效率，但这是依靠长期的积累得到的技能，并不属于可以直接学习的范围。
因果图法、判定表驱动法是解决条件组合情况的首选，两者可以相互转换，即因果图可以转变为相对应的判定表，并且两者都有各自的规则。两种测试方法严格的过程都十分繁琐，但是其思想是十分简单易懂的，所以，像很多书的介绍一样，我们同样提倡使用因果图法的思想，但不建议使用其规则，而其思想可以通过等价类表的组合得以实现，从而达到既使用了其思想，又使用简单形象的表达方式的目的，有关因果图法和判定表驱动法的详细介绍，读者可自行去查阅，有关等价类表的组合，我们将在后面的章节详细介绍。
面对功能测试方法繁杂的局面，如何选择方法，让测试事半功倍是重中之重。
1.3 功能测试指导思想
为了达到功能测试的目标，以最小代价测出更多问题，仅使用某一类方法不能完全满足这一要求。这就需要总结出一套行之有效的功能测试最佳实践的方法理论，来指导测试人员如何使用相关的测试方法，进行功能测试，达到功能测试的目标。
1.3.1 以往功能测试指导思想的弊端
为什么会提出指导思想这个概念呢？因为虽然功能测试的测试方法很多，且每一种方法都可以提供一组具体的有用的测试用例，但是都不能单独提供一个完整的测试用例集。换句话说，每种方法都各有自己的优劣，只用一种测试方法必定无法满足覆盖所有功能的要求，于是提出指导思想这个概念，意在将几种测试方法以合理的顺序组合起来，从而达到覆盖所有功能的测试要求。
有的研究提出了测试策略的概念，顾名思义是指导测试的策略，这与测试指导思想有异曲同工之妙，该概念的应用并不普遍，这一点从其在不同的资料中出现的频率也可以看出，既然如此，我们采用指导思想这一概念代替。这章的主要内容便是讲述我们提出的测试指导思想，在这之前，首先分析原先指导思想的弊端。
以往的指导思想如下。
- 如果规格说明中包含输入条件组合的说明情况，应首先使用因果图分析方法。
- 在任何情况下都应使用边界值分析方法。应记住，这是对输入和输出边界进行的分析。边界值分析可以产生一系列补充的测试条件，但是，多数甚至全部条件都可以被整合到因果图分析中。
- 应为输入输出确定有效和无效等价类，在必要的情况下对上面确认的测试用例进行补充。
- 使用错误猜测技术增加更多的测试用例。
- 针对上述测试用例集检查程序的逻辑结构。应使用判定覆盖、条件覆盖、判定/条件覆盖或多重条件覆盖准则（最后一个最为完整）。如果覆盖准则未能被前四个步骤中确定的测试用例所满足，并且满足准则也并非不可能（由于程序的性质限制，某些条件的组合也许是不可能实现的），那么增加足够数量的测试用例，以使覆盖准则得到满足。
毫无疑问，以上的指导思想是合理的，但同时也是不负责任的。因为把以上的指导思想概括一下就是：要用等价类划分、边界值分析、错误猜测技术、因果图法、逻辑覆盖的方法相互组合对系统进行测试。首先这很合理，但是这十分宽泛，仅仅提出要组合的方法以及什么情况下组合，并没有明确指出组合的方式（或者说组合的顺序）；另外，该指导思想使用了很多被时下抛弃的测试方法，这些方法大多十分复杂，对这些方法的分析在1.2节已经讲过。
在此背景下，我们总结出了各种测试方法的组合方式，即功能测试的指导思想。
1.3.2 功能测试指导思想
在讲功能测试指导思想之前，需要对其中提到的全新的功能测试方法——流程图法作详细的解释。
流程图法
流程图法的原型是流程分析法，是从白盒测试设计方法中的路径覆盖分析法借鉴过来的一种很重要的方法。在白盒测试中，路径就是指函数代码的某个分支组合，路径覆盖法需要构造足够的用例覆盖函数的所有代码路径。在黑盒测试中，若将软件系统的某个流程看成路径的话，则可以针对该路径使用路径分析的方法设计测试用例。
将流程分析法的步骤进行完善修改，得到流程图法的具体实施步骤：
- 画出初始流程图。
- 根据流程图中的判断条件和系统逻辑，进行功能模块的划分。
- 确定测试路径。
- 选取测试数据，构造测试用例。
需要说明的是，流程分析法中提到状态节点和条件分支的定义，这里没有再提，提炼其思想就是以流程图中判断条件为中心，根据系统的逻辑进行模块的划分，具体的实践等到后面的章节进行。
采用流程图法设计测试用例的好处如下。
- 降低测试用例设计的难度。即只要清楚程序流程、看懂程序流程图，就可以设计出质量较高的测试用例。
- 是在测试资源紧张的情况下，可以据此有选择的执行测试用例，而非全部依靠经验做取舍。
功能测试指导思想概述如下。
- 全面了解系统的逻辑，画出系统流程图。
- 根据系统流程图划分系统的功能模块。
- 对每个模块进行等价类划分和边界值分析。
- 所有的等价类和边界值进行组合，得到测试路径。
- 代入数据，形成测试用例，实施测试。
其中，等价类划分和边界值分析方法已经在1.1.3节中讲到。
1.3.3 根据指导思想设计用例的步骤
指导思想就是复杂的测试流程的概括，要进行具体的测试，还要添加必要的步骤，才能得到详细的测试用例的设计过程，而测试的过程就是设计并运行测试用例的过程。
用例设计的步骤如下。
- 全面了解系统的逻辑，画出初始系统流程图。
- 对系统流程图进行功能模块的划分，每个模块分别进行等价类分析，得出初始等价类表。
- 对每个模块进行边界值分析，补充初始等价类表，得到等价类表。
- 将等价类表中的每个等价类的序号标注在流程图中，得到系统流程图。
- 根据系统流程图得到测试路径。
- 将测试路径转化为测试数据的输入输出，套用测试用例的模板，形成测试用例。
1.4 功能测试最佳实践
1.4.1 案例简介
本系统的GPRS监控系统是功能测试的主要对象，某产品销往各地后通过内嵌的芯片以指令的形式上传大量产品的信息，用于检测产品是否正常运行。其中产品信息通过Socket服务器接收，并将其中的目标信息（过滤一些无用信息）同步入系统数据库和mongodb数据库，用于之后的网页端显示等。
涉及的主要逻辑有指令的接收判断和数据的同步。其中上传的指令可大体分为两种，数据指令和心跳指令。数据指令是用来保存并检测产品的指令，心跳指令是判断芯片和Socket端正常连接所必要的，接收到心跳指令不用关注收到的具体内容，而是立即返回这些内容以证明连接正常。Socket端接收到信息立即存入系统数据库，并尝试与mongodb数据库同步，所有的同步信息首先存入实时表中，同步过程发生错误会终止当前内容的同步，已经同步的内容存入历史表中，实时表中剩余的未同步的内容不断尝试向历史表中同步，直至所有的信息进入历史表中，即系统数据库与mongodb数据库同步完成。
1.4.2 画流程图
在已经全面了解系统逻辑的前提下，使用画图工具（工具可自行选择，这里推荐微软的visio）画出初始的系统功能流程图，这里根据前面对被测系统的介绍，画出的案例系统的流程图如下：
图1-1 GPRS实时监控系统流程图
1.4.3 划分模块，进行等价类划分，形成初始等价类表
首先根据功能点对模块进行划分，每个模块一个表，然后对划分的每个模块依照前面介绍的等价类方法进行等价类划分，便于后面对等价类的使用，对每个等价类进行编号
表1-1 a. socket服务器接收信息模块
| 输入条件 | 有效等价类 | 编号 | 无效等价类 | 编号 |
|---|---|---|---|---|
| 接受信息 | 心跳指令 | 1 | 其他 | 3 |
| 数据指令 | 2 |
表1-2 b. mongodb和数据库同步模块
| 输入条件 | 有效等价类 | 编号 | 无效等价类 | 编号 |
|---|---|---|---|---|
| mongodb内容与数据库同步 | 同步成功，同步信息一并存到实时表和历史表 | （1） | 同步失败，同步信息存到实时表，成功信息存到历史表 | （4） |
| mongodb内容与数据库同步失败，实时表中失败信息同步到历史表 | 同步成功，实时表中失败信息同步到历史表 | （2） | 同步失败，实时表中失败信息未完全同步到历史表 | （5） |
| 实时表中失败信息未完全同步到历史表中，实时表中失败信息同步到历史表中 | 同步成功，实时表中失败信息同步到历史表 | （3） | 同步失败，实时表中失败信息未完全同步到历史表 | （6） |
1.4.4 边界值分析，补充完善等价类表
根据边界值法分析划分等价类的原则，本系统的等价类并非范围的，连续的，而是单个的，离散的，所以每个等价类同时可以作为自身的边界值。例如，上表1-1中，接收的指令只有两种，这是根据等价类划分得到的，同时也是边界值分析得到的。
1.4.5 由等价类表得到改良流程图
根据完善后的等价类表和第一步得到的流程图
图1-2 改良后的GPRS实时监控系统流程图
借鉴白盒测试的逻辑覆盖方法（逻辑覆盖相关的方法：条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。 路径覆盖就是设计足够多的测试用例，覆盖程序中所有可能的路径。）得到测试路径如下。
编号01: 1
编号02: 2
编号03: 3
编号04: 2->（1）
编号05: 2->（2）
编号06: 2->（2）->（3）
编号07: 2->（2）->（4）
编号08: 2->（2）->（4）->（3）（测的还是（3）路径）
注：其中每一次进行的测试也可以进行排列组合，根据最基本的覆盖，即实现所有功能，测试所有功能模块及其组合一次，上表已经可以完成，每一次的测试组合针对某些特殊的代码（实际每一次测试的组合没必要），试想每一次信息接收完毕或者同步结束代码回到相同的初始状态，所以每一次的组合实际没必要，但是代码的逻辑无法确定时或许还要测。
1.4.6 代入数据，形成用例
表1-3 测试用例模板
| 项目名称 | 某某系统 | |
|---|---|---|
| 程序版本 | v-2.0.0 | |
| 编制人-编制时间 | xxx/2017-8-1 | |
| 用例编号 | JSXX_001（编号方式：功能模块+编号） | |
| 功能模块 | socket服务器接受信息模块 | |
| 功能描述 | 测试socket服务端接受心跳信息 | |
| 用例目的 | 测试socket服务端是否能够接收心跳信息并返回接受到的信息 | |
| 测试类型 | 功能测试 | |
| 前提条件 | 网络连接，产品GPRS模块工作并上传心跳信息 | |
| 测试方法与步骤 | 输入 | 上传心跳信息 |
| 期望输出 | 返回输入的心跳信息 | |
| 测试结果 | ||
| 功能完成 | 是□ 否□ | |
| 备注 | 该用例模板作为样板，信息最为齐全，可在所有用例中只使用一个，其他用例避免繁琐只保留关键部分（如表1-4等），在测试结果中填写实际结果，根据实际结果跟预期比对，确定功能是否完成。 |
表1-4 测试socket服务端接受数据信息
| 用例编号 | JSXX_002 | |
|---|---|---|
| 功能描述 | 测试socket服务端接受数据信息 | |
| 用例目的 | 测试socket服务端是否能够接收数据信息并进行转码正常存储在mongodb | |
| 测试类型 | 功能测试 | |
| 前提条件 | 网络连接，产品GPRS模块工作并上传数据信息 | |
| 测试方法与步骤 | 输入 | 上传数据信息 |
| 期望输出 | 存储到mongodb中 | |
| 测试结果 | mongodb中正常存储数据信息 | |
| 功能完成 | 是 |
表1-5 测试socket服务端忽略其他信息
| 用例编号 | JSXX_003 | |
|---|---|---|
| 功能描述 | 测试socket服务端忽略其他信息 | |
| 用例目的 | 测试socket服务端是否能够过滤其他垃圾信息 | |
| 测试类型 | 功能测试 | |
| 前提条件 | 网络连接，产品GPRS模块工作并上传其他信息 | |
| 测试方法与步骤 | 输入 | 上传其他信息（非心跳、非数据） |
| 期望输出 | 过滤忽略信息 | |
| 测试结果 | 无异常输出（证明过滤其他信息） | |
| 功能完成 | 是 |
表1-6 测试mongodb能否一次同步到多码系统数据库
| 序号 | SJTB_004 | |
|---|---|---|
| 功能描述 | 测试mongodb能否一次同步到多码系统数据库 | |
| 用例目的 | 测试mongodb能否直接同步成功到多码系统数据库 | |
| 测试类型 | 功能测试 | |
| 前提条件 | 网络连接，产品上传的数据信息同步到mongodb中 | |
| 测试方法与步骤 | 输入 | 产品上传的数据信息同步到mongodb中 |
| 期望输出 | 同步到多码系统数据库中 | |
| 测试结果 | mongodb中的成品信息同步到多码系统数据库 | |
| 功能完成 | 是 |
表1-7 测试mongodb一次同步到多码系统数据库失败
| 序号 | SJTB_005 | |
|---|---|---|
| 功能描述 | 测试mongodb一次同步到多码系统数据库失败 | |
| 用例目的 | 测试一次同步到多码系统数据库失败后，是否所有信息存到实时表，成功信息存到历史表，并且实时表中的失败信息不断尝试向历史表中同步 | |
| 测试类型 | 功能测试 | |
| 前提条件 | 网络连接，产品上传数据信息同步到mongodb一次失败 | |
| 测试方法与步骤 | 输入 | 产品上传数据信息同步到mongodb一次失败 |
| 期望输出 | 所有信息存到实时表，成功信息存到历史表，并且实时表中的失败信息不断尝试向历史表中同步 | |
| 测试结果 | 实时表中存储所有上传信息，历史表中存储成功信息，失败信息不断刷新，尝试向历史表中存储 | |
| 功能完成 | 是 |
表1-8 测试实时表中失败信息同步到多码系统数据库成功
| 序号 | SJTB_006 | |
|---|---|---|
| 功能描述 | 测试实时表中失败信息同步到多码系统数据库成功 | |
| 用例目的 | 测试一次同步到多码系统数据库失败后，实时表中的失败信息向历史表中一次同步成功 | |
| 测试类型 | 功能测试 | |
| 前提条件 | 网络连接，产品上传数据信息同步到mongodb一次失败 ，所有信息存到实时表，成功信息存到历史表，并且实时表中的失败信息不断尝试向历史表中同步 | |
| 测试方法与步骤 | 输入 | 第一次mongodb与多码系统数据库同步失败后，实时表中的失败信息 |
| 期望输出 | 成功信息存到历史表中，mongodb所有信息同步多码系统数据库 | |
| 测试结果 | 实时表中的失败信息成功刷新到历史表中 | |
| 功能完成 | 是 |
表1-9 测试实时表中失败信息一次同步失败二次同步失败
| 序号 | SJTB_007 | |
|---|---|---|
| 功能描述 | 测试实时表中失败信息一次同步失败二次同步失败 | |
| 用例目的 | 测试mongodb与多码系统数据库一次同步失败，实时表与历史表二次同步失败，再次同步失败时系统能否正常保存失败内容到历史表 | |
| 测试类型 | 功能测试 | |
| 前提条件 | 产品GPRS模块工作并上传数据信息接收成功，第一次mongodb与多码系统数据库同步失败，第二次实时表与历史表同步失败 | |
| 测试方法与步骤 | 输入 | 第二次实时表同步失败后，实时表失败信息 |
| 期望输出 | 成功信息存到历史表，所有信息存到实时表 | |
| 测试结果 | 经过一次失败后，再次同步失败，实时表存储所有上传信息，历史表存储成功信息 | |
| 功能完成 | 是 |
