黑盒测试及测试用例设计方法（面试题解析）

黑盒测试这个看似简单的问题，在面试中被提及的机会真是数不胜数。特别是应聘者只有一"两年工作经验时，面试官通常会问道。

●是否做过测试?
●黑盒还是白盒?
●怎么做?
●有什么区别?

这么简单的问题可能大家早早就预备好答案了。还需要一遍又一遍的讨论吗?其实越看似简单的问题，如果应试人员能提供深刻的分析和独特的见解，则越能给面试官留下深刻的印象。

我们需要时时刻刻提醒而试官“我不光是懂，我是真懂”:我做黑盒测试不是在那里点点鼠标键而已，我是有目的地点鼠标键。

下面让我们看看我们为什么是有目的地点鼠标吧。

测试和开发就像软件项目中的两条腿，时而交替时而并行地推动着项目前进。写代码是开发人员的主要任务之一，相比之下测试用例的开发就是测试人员的主要任务之- -。所产生的测试用例的质量也是考核测试用例开发人员业务水平的重要标准。在写作用例方面不断进行质的提高，是一名普通测试工程师成为高级测试工程师的必经之路。

软件测试通常分为黑盒测试和白盒测试两类。本节我们将重点介绍黑盒测试及其测试用例的设计方法。

面试题一

什么是黑盒测试？

解答：

黑盒测试就是测试人员把软件产品(或阶段性产品)看做是- -个黑盒。在测试过程中测试人员只需关心对这个软件黑盒进行操作会得到什么样的结果，而不必深入地去了解它的内部实现机制所进行的测试活动。这样的操作可以是字符串的输入、图片的输入、视频流的输入，甚至可以是事件输入。而不同的输入进入相应的处理软件(即这个黑盒)进行处理之后通常能得到不同的结果，如图3-4所示。

如果对软件测试有兴趣，想了解更多的测试知识，解决测试问题,以及入门指导，帮你解决测试中遇到的困惑，我们这里有技术高手。如果你正在找工作或者刚刚学校出来，又或者已经工作但是经常觉得难点很多，觉得自己测试方面学的不够精想要继续学习的，想转行怕学不会的，都可以加入我们1079636098，群内可领取最新软件测试大厂面试资料和Python自动化、接口、框架搭建学习资料！

例子：

例如我们在Windows的命令行中输入字符串dir 就可以得到当前目录下的子目录及文件的列表。而输入taskist后就可以得到一张正在系统中运行的任务的列表，在以上的操作中我们都不必去考虑命令行解析器会如何解析输入的字符串，也不必考虑系统如何获取我们想要的信息并如何把它显示在屏幕上，这就是黑盒处理机制。我们只关心输入(input)的和想要得到的输出(output). 如果在初始条件确定的情况下的一组确定的输入经过软件产品这个黑盒进行处理后并没有得到期望的结果(expected result)时，则说明此时就发现了一个软件的缺陷(defect )

面试题二

为什么要做黑盒测试？

解答

●验证(verify) 软件产品是否符合需求文档的设计(IEEE 1983 of IEEE Standard 729)
●证实(validate) 软件产品符合终端用户的需求(IEEE 1983 of IEEE Standard 729)

面试小技巧
在IEEE对于软件测试目的的论述中，各项软件测试活动都是围绕以上两个目的展开的。所以在面试过程中，当面试官问及软件测试的目的时不妨把以上两点作为答案，既简练，又深刻。

我们把字符串dir输入到其他软件中(如计算器)可能毫无意义，但在Windows 的命令行中就能被解析为获得当前目录下的子目录及文件的列表，并且在初始条件确定的情况下将得到可预测的输出。这样的输出在软件设计阶段通常就被定义下来以保证开发人员编写的程序有章可循。这正是软件测试的目的之一:验证(verify) 软件产品是否符合需求文档的设计(可参考IEEE标准729之IEEE 1983).

此外，在黑盒测试活动中，测试人员只按业务逻辑测试而不需要考虑内部实现。这就很好地模拟了终端用户的行为。然而终端用户的行为并不会都在软件需求文档中定义。例如测试一个网站，我们可能会模拟黑客对网站进行一些攻击，但是黑客的攻击方式是无穷尽的，正所谓是道高一尺魔高–丈。黑客们总会想出新点子来达到他们的目的。既然攻击方式是无穷尽的，那么我们就不可能在我们的需求文档中定义应对所有攻击方式的策略。这时我们的测试就派上用场了。我们可以尽量模拟终端用户对产品网站进行攻击。这样的测试既可以是事先定义好的，也可以是随机的(adhoc test)。像这样的模拟终端用户操作对产品进行的测试活动就是在履行软件测试的另- -个目的:证实(validate) 软件产品符合终端用户的需求(请参考IEEE标准729之IEEE 1983)。

面试题三

你在软件生命周期中的哪些测试阶段用到过黑盒测试?

解答

●单元测试(unit test)。.
●组件测试(component test)。
●集成测试(integration test)。
●系统测试(system test)。
●用户验收测试(user aceptance test)。

通常来说，软件生命周期中的测试阶段按时间顺序可分为单元测试(unit test)，组件测试(component test)、集成测试(integration test)、系统测试(system tes)及用户验收测试(useracceptance test)。在各个测试阶段之间通常还会设置通过条件( pass criteria)和准入条件(entrycriteria)。

不过由于产品种类不同，项目的大小也各不相同，所以各个公司都会对上述的测试阶段进行裁减或重新定义。例如做手机类的公司就通常把系统测试阶段再次分为系统测试(system test)和场地测试(field test)。这是因为对于手机这样的产品，其质量极大地受到手机产品与现有的移动运营商的网络的兼容性的影响，所以在内部系统测试的中期，手机的系统达到了-定的稳定性的情况下开始做大量的实网测试(场地测试)是必须的，也是同等重要的。

那么我们的黑盒测试适用于哪些测试阶段呢?其实- -般来说适用于所有阶段。对于这句话大家可能最有异议的就是单元测试阶段。一般大家认为单元测试阶段应该采用的都是白盒测试方法，而非黑盒。其实不然，黑盒测试其实在此阶段是一-种非常行之有效的方法。如果运用得当则可以减少很多把软件缺陷遗漏给其他测试阶段的机会。我们现在知道黑盒测试把软件产品看做是黑盒，测试人员只关心对其进行的输入和获得的输出，而并不关心其内部实现机制。而在单元测试中，其实函数也可以被看做一个黑盒，一个小尺度上的黑盒。

这个黑盒一般也被称作函数黑盒。一个组件或应用软件正是由一个个这样的函数黑盒组成的大黑盒。一个函数一般分为4个部分:函数名、形参表、函数体、返回值。函数名是这个函数的识别标志，一般要取的通俗易懂，且要与上下文一致。函数体是这个函数的实现机制，它是这个函数的核心部分，其决定了这个函数是否做了正确的事，是否占用了最少的代码空间和运行空间，是否用了最少的运行时间。可以这么说，函数体就是这个黑盒。而形参和返回值就是这个函数黑盒的输入和输出。利用黑盒测试用例设计的方法对其输入值域和输出值域进行分析可以极大地保证函数的质量。在本节此后的分析中将举例对此进行详细深入的探讨。

说明

一个函数除了输出返回值之外还可能有其他的输出:

●函数体有可能处理了函数域以外的全局变量，这时全局变量也成为了这个函数输入和输出的一部分。

函數的参数中可能有引用型形参(C中可用指针作为引用型形参，C++中可用指针或引用作为引用型形参，C#/Java中引用类型的引用或值类型的引用作为引用型形参)。这时被引用的对象实例有可能在函数中被修改，从而成为函数输出的一部分，如图3-5所示。

如果对软件测试有兴趣，想了解更多的测试知识，解决测试问题,以及入门指导，帮你解决测试中遇到的困惑，我们这里有技术高手。如果你正在找工作或者刚刚学校出来，又或者已经工作但是经常觉得难点很多，觉得自己测试方面学的不够精想要继续学习的，想转行怕学不会的，都可以加入我们1079636098，群内可领取最新软件测试大厂面试资料和Python自动化、接口、框架搭建学习资料！

引申

笔者认为若想做到占用最少的代码空间和运行空间，占用最少的运行时间，就应该深入了解编程语言，熟读数据结构和算法方面的书籍。专业性的软件企业如微软、Google等就很看重这些，即便是招收测试人员也如此，有志于去这些公司的朋友有必要在此多花时间精力。关于函数是否做了正确的事，通过学习测试的知识会有不少的帮助。

正如我们前面所说的组件或程序就是通过层层调用函数来处理用户需求的，所以当多个函数能够封装成类，进而被组装成–个组件时，也就是把–个个小的函数黑盒组装成了一个大黑盒，此时就可以对它进行一定的组件测试了。这时的组件即使不能完成一个完整的功能，也能通:过编写驱动函数或桩函数的方法去测试它。

面试题四

什么叫打桩，什么叫驱动？

说明

驱动函数:在测试被测函数时，一般需要在一个函数中构造一些实验数据作为传入被测函数的实参，然后再在该函教中调用被测函数，之后检验测试结果。这样的函数被称为驱动函数(一般为main函数)桩函数:在测试被测函数时，被测函数可能要调用一个未被实现功能的函数(或一连串函数的调用)。这时测试人员可以写一个临时的简单的函数以模拟被调函数的部分行为。这样的函数被称为桩函数，如图3-6所示，

如果对软件测试有兴趣，想了解更多的测试知识，解决测试问题,以及入门指导，帮你解决测试中遇到的困惑，我们这里有技术高手。如果你正在找工作或者刚刚学校出来，又或者已经工作但是经常觉得难点很多，觉得自己测试方面学的不够精想要继续学习的，想转行怕学不会的，都可以加入我们1079636098，群内可领取最新软件测试大厂面试资料和Python自动化、接口、框架搭建学习资料！

我们通过组件暴露的公共接口分析它的输入值域，然后根据其输入值域编写测试数据。之后在驱动程序中调用组件的公共接口，并把测试数据作为参数(或全局变量)传给被测组件。

最终获得该组测试数据经处理后所产生的输出。此后就要分析这些输出是否是期望结果以确定该组件是否有缺陷。

之后被多个测试过的组件将被集成，成为更大的组件直到成为功能齐全的应用程序。这时系统测试就将开始了。从黑盒测试的角度看，这时的软件产品就是一个更大规模的黑盒，而且因为功能齐全，我们就可以直接通过图形用户界面、命令行或该软件产品所提供的其他方式直接对对其进行黑盒测试了。

进入用户验收测试阶段，黑盒测试也是最主要的测试方法，只不过此时所做的测试大都是
从用户的角度出发，而且生产企业大都会邀请用户直接加入到用户体验测试中来，以使软件产
品更符合用户的习惯。

黑盒测试方法

1.输入值域和输出值域

上一节我们介绍到当测试人员对软件产品进行黑盒测试时，需要对软件黑盒进行输入用以产生相应的测试结果。这样的输入值的组合就构成了我们对某个软件产品进行黑盒测试时所用的测试用例。所有输入值组合的集合就构成了输入值域。

我们来看一个简单的程序:

那么现在我们总结一下以上的情况。这个被输入的数是一-个实数，这个实数可以没有小数部分。如果有小数点后只能为5或零，而这个实数的取值范围是大于等于0且小于等于100,则在计算机中这个数的有效范围将可以被表示为一个大于等于0且小于等于100的浮点数。这个浮点数可以没有小数部分。如果有小数点后只能为5或零，则符合以上条件的浮点数将被允许输入到学生们的成绩数据库中。而这样的一-个有效范围就被称作有效输入值域。我们可以轻松得出在这个有效输入值域中有201种输入的组合{0，0.s， 1， 1.s, … 99, 99.s， 100}。

我们还能有其他的输入吗?当然有。为了达到测试程序健壮性的目的，可以取浮点数中的任意数值对其进行测试。我们知道现实生活中实数的取值范围是无穷大的，而且是连续的，但在我们的计算机中浮点数f是32位的。它不能像我们的生活中的实数-一样，是连续的。它也只有232种取值的可能，因为它只有32个bit 位。因此当我们在浮点数域中对这个程序进行测试时，我们将可以找出2*-201个无效的输入组合。所有的无效的输入组合就组成了我们在浮点数域的无效输入值域。而在这个域中任何- -个输入组合被输入到程序中，这个程序都必须反馈一个合理的信息以通知使用者这个输入是超出有效范围的。

还有其他输入吗?当然有。既然输入框(extbox) 可以允许用户输入字符，那么我们可以满键盘地找到所有看得见的字符(非浮点型字符常量的组合)，然后“爆”输-番。这样的组合有多少呢?当然是无穷无尽了。这样我们就可以看到在这种情况下我们的无效输入组合数量就扩大到无穷大了，而此时这种情况下的无效输入值域也就变得无穷大了。在这个域中任何-一个输入组合被输入到程序中，这个程序都必领反馈- -个合理的信息以通知使用者这个输入中含有无效的字符。

还有吗?当然还有。我们可以不输入任何值而直接按按钮。这也是一个无效的输入。而对应于这个输入，程序就必须将输入为空的信息反馈给使用者。

综合以上3种情况，我们可以看出对于这个小程序我们的无效输入组合数为2.201+∞+1=∞。这也就是我们的无效输入值城了。

结合.上述分析所得的有效输入值城和无效输入值城不难看出，这两个域中的输入组合的总和涵盖了所有可能的输入组合，亦即等于整个输入值城，并且有效输入值域和无效输入值城无交集。

所以我们有:输入值域=有效输入值域+无效输入值域作为对应，我们不难发现每个被测的软件组合还有一个输出值城，而且同样可以推理得出:输出值域=有效输出值域+无效输出值域通过以上的分析我们知道输入(出)值域包括有效输入(出)值域和无效输入(出)值域。

每个域中都有很多输入(出)组合。在以上的例子中，我们列举了有效输入值城201个，无效输入值域无穷个。这样的情形对于我们测试工作来说可不是- -件好事。软件测试的工作不可能通过逐个枚举输入(出)值域中的输入(出)组合来完成。我们必须有一系列方法来减少工作量。首先，我们已经把输入(出)值域划分为了有效输入(出)值域和无效输入(出)值城。如果能够把有效输入(出) 值域和无效输入(出)值城进- – 步划分为更小的集合，而且在每个集合中的输入(出)组合对于这个程序来说都是完全等效的，那么就可以在每个集合中挑选一个或几个输入 (出)组合作为我们的测试用例。这样测试用例的数量将大大减少到我们能够承受的范围之内。当然，我们需要一种方法来帮助我们做到这一点。

这就是稍后要介绍的等价类划分法。

当有效输入(出) 值域和无效输入(出)值域被进一步划分为更小的集合后，如何选定使用哪一些值作为代表来编写测试用例呢?这时就需要边界分析值法来帮助我们选取每个集合的关键值。

此外，在接下来的章节中我们还将介绍其他的黑盒测试方法以帮助我们在各种情况下写出合理的测试用例。这些方法应该被熟练掌握，然后在工作过程中被灵活运用。

2.等价类划分(Equivalence Partitioning)

等价类划分运用的是对组件的输入值域和输出值域进行划分的模式来设计测试用例。我们一般可以通过对该组件的需求文档进行分析来得到这些输入值域和输出值域。当然，这时需求文档的深度、详细程度及精确程度等将对输入值域和输出值域分析都得产生巨大的影响。所以我们要求测试人员应当在需求文档编写期间积极参与文档的审查工作。

该设计模式应该包括对输入值域和输出值域的划分。每个被划分出来的等价类应当包含一-组值的集合或一“个范围之内的值。在每-个等价类中，所有的值对于这个组件来说在某种程度上都是等效(价)的。此外，有效值域和无效值域都应当按照这种方式来划分。

在这种设计模式下测试用例将执行(覆盖)各个等价类。这样的等价类包括对有效输入值，城进行划分所得的等价类和对无效输入值域进行划分所得的等价类。测试用例还可以被设计为用来测试那些无法被推导出的无效输出值。

一个测试用例可以执行(覆盖)任意数量的等价类。每–个测试用例应当包括。
●对于该组件的输入。
●该用例所执行(覆盖)的等价类。
●该用例的期望输出。

等价类划分设计模式的覆盖率为:

等价类划分覆盖率-(已覆盖的等价类的数量/总的等价类数)x100%.在以上的公式中已覆盖的等价类的数量是指我们在测试用例设计过程中使用等价类划分设计模式所设计的测试用例集(test case suite)总共覆盖的等价类的数量。总的等价类数是指一个组件的输入值域和输出值域所有可能的等价类的总和。

说明

我们回忆一下，等价类划分基于以下的假设:根据组件的设计文档，该组件的输入值城和输出值城可以被划分为多个等价类。在每一个等价类中，所有的值对于这个组件来说在某种程度上都是等效的。因此，对一个等价类中的某一个值进行测试就可以被等效认为对这个等价类中所有的值进行了测试。

例子

假设有一个组件，为学生的成绩定级。它在其设计文档中被描述为以下内容:该组件将接收两个有符号整型参数一考试成绩(80分)和平时表现(20分)。该组件将把这两个参数相加。之后根据这个和对其进行定级，经过该组件的运算和判断将输出4个值:

总分大于等于80
A°(优秀)
总分大于等于60并小于80
B’(良好)
总分大于等于50并小于60
C(补考)
总分小于50
D’(重修)

在此，所有输入的考试成绩如果超出其有效值范围，则该组件将返回一个错误消息(errormessage)的提示信息。

对于这个例子，我们首先划分其等价类，然后再设计测试用例来执行(覆盖)每个等价类。

等价类将按照该组件的输入和输出域来进行划分。输入域和输出域中所有的有效值域和无效值域都将被考虑。

下面先来分析该组件的输入域。

先对其两个参数的有效值域进行划分。
●0≤考试成绩≤80。
●0≤平时表现≤20。
然后对这两个参数的其无效值域进行划分。
● 考试成绩<0。
●考试成绩> 80。
●平时表现<0.
●平时表现> 20。
当然我们还有可能碰到用户可能会误输入带小数的浮点数或一些字母、符号等非数字的字
符组合。于是我们在这两个参数的输入域中还划分出以下的无效值域。
●考试成绩=带小数的浮点数。
●考试成绩=非数字的字符组合。
●平时表现=带小数的浮点数。
●平时表现=非数字的字符组合。
下面来分析一下该组件的输出域。
先对其输出域的有效值域进行划分:
●80≤总分≤100.
将输出
‘A’(优秀)
●60≤总分<80
将输出
‘B’(良好)
●50≤总分<60
将输出
‘C’ (补考)
●0≤总分<50
将输出
‘D’(重修)
●100<总分.
将输出
‘error message’ (错误消息)
●总分<0
将输出
‘error message’ (错误消息)
在此总分=考试成绩+平时表现。

我们注意到’errormessage’(错误消息)也在输出域的有效值域之列。这是因为该组件的设计文档中已经指明在考试成绩和平时表现超出有效范围时有这种类型的输出。

以上6种情况之外的输出就是该输出域的无效输出了。-般来说未在组件的设计文档中描述的无效输出是较难被界定出来到的。但是一旦测试人员在使用该组件时遇到或界定出某一无效输出时就应当要求开发人员将其加入设计文档并在新的组件版本中将其实现。

正因为无效输出很难被界定，所以设计无效输出的测试用例就要求测试人员有较强的与被测软件相关的业务背景和较多的经验。因此，测试用例设计人员对于无效输出域进行的等价类的划分都具有主观性。对于这个例子，我们将其输出域的无效值域划分为以下等效类。

●output= 'null’等效于输入的两个参数皆为null.
●output = 'float input’等效于输入参数至少有一个是浮点数。
●output = 'on-numeric input’等效于输入参数至少有一个是非数字。

下面来总结一.下所有等价类的划分。

●0≤考试成绩≤80。
●0≤平时表现≤20。
●考试成绩<0.
●考试成绩> 80。
●平时表现<0.
●平时表现> 20.
●考试成绩=带小数的浮点数。
●考试成绩-非数字的字符组合。
●平时表现-带小数的浮点数。
●平时表现=非数字的字符组合。
●80≤总分≤100

将输出.

‘A’ (优秀)。.
●60≤总分<80
将输出
‘B’(良好)。
●50≤总分<60
将输出‘C’ (补考)。
●0≤总分<50
将输出’D’ (重修)。
●100<总分
将输出‘ error message’(错误消息)。
●总分<0
将输出error message’ (错误消息)。

●output- 'ull’等效于输入的两个参数皆为null.
●output = ‘float input’ 等效于输入参数至少有一个是浮点数。
●output = ‘non-numeric input’ 等效于输入参数至少有一个是非数字。

下面将设计测试有例来覆盖以上的各个等价类，此时我们将采取逐个覆盖的方法。这样可以使我们设计出的用例和被其覆盖的等价类之间的关系显得非常清晰。以下用例是对与输入参数-考试成绩相关的等价类进行覆盖，如表3-3所示。

回顾我们所设计的用例不难发现，有许多用例都比较相似。例如007和017，不同的只是它们被设计的目的是为了覆盖不同的等价类。仔细观察测试用例我们还可以发现以上的每个测试用例都涵盖了两个输入值和一- 个输出值。这就意味着每个测试用例实际上覆盖了3个等价类:两个输入域的等价类和一-个输出域的等价类，这也就意味着我们可以用更小的测试用例集合来覆盖我们所划分的所有的等价类。下面就来尝试缩小以上测试用例的集合，如表3-8所示。

我们可以看到，以上两种用以覆盖等价类的测试用例设计方法(逐个覆盖法和最小集合法)都能做到覆盖所有的等价类。不同的是，逐个覆盖法需婴更多的测试用例。而运用最小集合法时，如果测试用例全部通过，则等效于所有的等价类都顺利地通过了测试，但是一- 旦出现了某-个或多个测试用例未通过的情况，我们就必须设计和运行更多的测试用例以定位出现缺陷的等价类。

通常来说，分析组件的设计文档、界定并划分等价类的时间远高于产生测试用例和执行测试用例所花的时间，所以如果经过初步分析，最小集合法不能大量减少测试用例，则一般都直接采用逐个覆盖法所产生的测试用例的集合。

边界值分析(Boundary Value Analysis)

边界值分析法运用的是将被测组件的输入值域和输出值域划分为多个有序并有确定边界的集合的模式来设计测试用例。我们一般可以通过对该组件的需求文档进行分析来得到这个输入值域和输出值域。

在这个模式下，被划分出来的集合是有序的，而且包含明确的边界。每个被划分出来的集合应当包含一组值或一个取值的范围。在每一- 个被划分出的集合中，所有的值对于这个组件来说在某种程度上都是等效(价)的。此外，有效值域和无效值域都应当按照这种方式来划分。

所谓边界值就是用来界定各个有序集合之间的边界点。每个被划分出来的集合一般都有一个最大值和一个最小值作为其边界值，而其他的值都在这两个边界值的范围之内。

在边界值分析法的模式下设计出来的测试用例将用于覆盖每个被划分出来的集合的边界点上的值和其相邻值(边界点的前一一个有序值和边界点的后- -个有序值)。因此，对于每一-个被确定的边界都有3个值需要覆盖。这样的边界值是对有效输入值域进行划分所得的集合的边界值和对无效输入值城进行划分所得的集合的边界值。另外，测试用例还可以被设计为用来测试那些无法被推导出的无效输出值域的边界值。

每一个运用边界值分析法模式设计的测试用例都应当包括。

●对于该组件的输入。
●该用例所执行(覆盖)的边界值。
●该用例的期望输出。
边界值分析设计模式的覆盖率为:.

边界值覆盖率=(被执行的已确定边界值的数量/总的边界值數)X 100%
以上公式中每一一个边界值均对应于测试用例中所覆盖的边界值或其相邻值。

最后：

1、点赞。防止以后找不到，想看的时候，在自己主页就能找到了，很方便;
2、关注我。让我们成为长期关系，下一个视频会分享更多的硬核干货;
3、本文章学习资源，均可以免费分享。

微信公众号：程序员阿沐。这样的好内容，里面还有近百篇。谢谢你的支持！

目前测试平台项目研发已经完成并且在Github开源，有兴趣的朋友可以去Github下载
https://github.com/ooqitech/ATP

不要只做收藏从未停止，行动从未开始的人，很多事情，做着做着就无师自通了。如果在做的过程中还能稍微加点思考，稍微看一些别人的经验和做法，成长会更快，效果也会更好！加油吧，测试人！路就在脚下，成功就在明天！

一个用心码了这么多文字的人，往往渴望得到大家的认可。如果你觉得这篇文章对你有帮助，双击屏幕，给我点个赞呀！

更多软件测试资源分享微信公众号：【程序员阿沐】
软件测试技术交流群：810119819