【入门篇】黑盒测试基础

一.测试的基本问题

1.一个典型的测试项目：

首先，给你一个系统要你去做测试。

这个系统可能有（也可能没有）需求说明文档
所有文档有可能完整（也有可能不完整，并且通常不完整）
接下来，你设计了一系列的测试，然后执行，并且不断把你的工作进度和结果向上汇报。

然后，新的版本被提交给你测试，你重新执行了上个版本设计的测试，检查了bug是否被修复，然后设计并且执行了一些新的测试。

最终，系统成为一个产品投入到生产环境中，或因为这样那样的原因而被取消。

2.针对这样典型的测试项目，有一些关于测试的基本问题需要解决（有时候还会被写下来变成文档）：

为什么要对这个系统进行测试，你想在测试中发现什么？（测试目标）
如何组织你的工作以实现你的目标？（测试策略）
怎样知道系统在测试中最终是Pass还是Fail？（测试依据）
如何对这个系统进行穷尽的测试？（测试的无穷性）
不能做穷尽的测试，那么要测多少才够？（测试完整性度量）
下面开始依次讨论这五个问题。

二、测试目标

1.什么是测试？

Testing is a technical investigation of the product under test conducted to provide stakeholders with quality-related information. (Cem Kaner)

测试是为待测产品的相关利益者提供产品的质量信息而进行的技术调查活动。

技术——测试中运用到的技术方法包括试验、逻辑、数学、模型、工具等等
调查——测试中为了研究产品质量而进行积极的调查活动，比如我们设计和执行测试用例，并仔细查看其测试结果
待测产品——测试中的待测产品除了程序之外还包括了数据，文档，硬件等等所有客户最后会得到的东西，缺一不可
利益相关者——测试中的利益相关者包括对测试的成败有密切关注的人（技术方面的管理者等）和对产品的成败有密切关注的人（业务方面的管理者以及高层领导等）
质量信息——测试中的质量信息通常包括bug相关的信息以及其他对利益相关者来说更重要的信息

不同的测试目标要求采用不同的测试策略，会执行不同的测试，编写不同的文档，以及得到不同的结果，一些可能的测试目标有：

找到重要的bug，使他们得到修复
评估产品的质量
对是否发布产品的决策提供帮助
阻止不成熟的产品被发布
对预测和控制产品的支持成本提供帮助
监测待测产品和其他产品的交互性
解释如何安全地使用产品
评估产品与实际需求的一致性
证明产品符合某个特定的标准（如国际标准，国家标准等）
确保测试的过程符合问责制标准
减少产品可能引起的安全方面的诉讼风险
帮助客户提高产品的质量和可测试性
帮助客户改进他们的流程
作为第三方检测产品

三、测试策略

1.测试策略

测试策略是你所作的计划，其目的是实现你的测试目标，前提条件是 必须根据你的项目实际情况来采取不同的测试策略 。

2.为了说明测试策略的一个思维试验

假设，你现在被要求测试某个程序里的一个计算功能模块，你可以想象成电子表格之类的。假设这一待测模块来自以下4种软件：

一个电脑游戏中的得分计算功能模块
一个商业产品，你现在在这个产品开发流程的前期（开发刚开始不久）介入了这个产品，并且，现在你的项目经理要求你对这个模块做一个测试，以帮助她确定这个产品包含的风险，并且帮助她让她的程序员们明白，他们的工作的可靠性程度会产生的影响。
一个商业产品，你现在在这个产品开发流程的后期（产品即将正式发布）介入了这个产品，并且，现在你的项目经理要求你对这个模块做一个测试，以帮助她确定这个产品什么时候可以发布。
一个控制医疗器械的软件中的计算功能模块
对这4个程序的计算模块，现在有以下问题

A）你的测试目标是什么？

B）你会怎样组织你的测试，以实现这个测试目标？

你对发现的bug有一个什么样的重视程度？为什么？
什么样的bug的重要性会比较高？为什么
你对你的工作所作的文档会细致到什么程度？为什么？
C）假设这个程序中有一个数字输入域，在需求文档上说明了，这个域必须能够接受一位的数字作为输入值，但是没有说明如果输入字母或者符号等等，系统会如何反应。那么你应该去测试输入字母或者符号的情况吗？假如，现在这个项目的时间非常非常的紧急呢？

四、测试依据

1.什么是测试的依据？

依据就是你用来辨别一个问题的方法。

首先看一个例子:

现在有一个Linux下的开源软件Open Office，该软件提供一个类似于Word的文本编辑器，其定位也是专业的文本处理软件。现在要测试的是其中字体大小（font size）这个功能。请问，你如何来测试？

测试是一种认知的活动，而不是一种机械的活动，也就是说必须确定了测试的依据（先有认知），才能进行测试。

回到刚才的例子，那么现在有一种简化的测试方法是这样的：

先在Open Office中输入不同尺寸（size）的文字，再打开Microsoft Word，输入同样尺寸（size）的文字，然后打印出来，对比两者的文字是否一样大。

那么这种测试方法，其实是把Microsoft Word这个软件作为了测试的依据。因为我们都知道Microsoft的软件质量高，应用广。一般上就会认为可以把这个word用作测试的依据。

接下来就会产生一个新问题。和Microsoft Word的字体大小一样大，是否就真的说明这个功能正确了呢？而Microsoft又怎么样去测试他们的Word呢？这个问题暂时我们先放一放，做一种新的假设:

假如我们需要测试的不是Open Office ，而是windows下的写字板程序的字体大小，那么我们怎么样来测试她？

实际上我们完全没有必要去测试写字板的字体大小的大小是不是标准。因为写字板程序，并不是一个专业的文本处理程序，她只是windows自带功能的一部分。我们对写字板的要求，其实就很简单，你能处理文本，没有影响使用的错误，就可以了。

假设写字板的字体大小10和11其实显示的文字是一样大的，那么这个问题（ISSUE）是不是一个BUG？确实我们可以把这个当做一个BUG，但对于使用来说，其影响可以忽略不计，而写字板本身也不是一个专业的文本处理软件，所以，这个不是一个BUG。也就是说，测试依据要考虑的，不仅仅是

一个功能是pass还是fail，

更重要的是要能决定一个功能上的问题(ISSUE)，是不是BUG 。

我们做出的判断是依据 客户对这个软件的期望 。

而Open Office和Word则不同，作为专业的文本处理软件，字体大小必须符合标准。做出同样的假设，有字体大小的10和11，显示的文字一样大，那么对于Open Office来说，就是一个严重的bug。因为她作为专业的文本处理软件，客户对她是有这个期望的，她需要具备正确显示font size的功能。

现在我们来总结，针对Open Office的这个专业的文本处理软件，她的字体大小功能到底需要测哪些东西，有一个简单的列表如下：

每一种字体大小
每一个字母在每一个字体下的显示
每一种改变字体大小的方法
每一个关于字体大小的UI
字体大小功能和文档的其他内容的交互
字体大小功能和Open Office其他功能模块的交互
字体大小功能和电脑的显卡，显示模式的交互
文字的打印以及屏幕显示功能

好，回到如何测试Open Office的这个功能的问题上来，
这个功能的标准化测试方法其实是相当复杂的，
比如，需要知道字体的点的定义，有六种不一样的定义 http://www.oberonplace.com/dtp/fonts/point.htm

每一个字母的尺寸大小都需要有测量的标准，而且很困难 http://www.oberonplace.com/dtp/fonts/fontsize.htm

每一种尺寸大小之间和她的标准之间允许的误差值范围也需要定义
另外的一种测试方法前面也提到了，属于启发式的方法，

比如，检测字母的相对大小，与Microsoft Word进行比较；设计针对不同用户对软件的这个功能的不同使用的测试。

测试是需要想法的，而启发式思维可以给你想法。

五、启发式思维

1.启发式思维和测试的依据
用启发式思维（software oracles as heuristics）得到的结果，并不能被当做是最终的或者严格的，而仅仅是临时的或者并不确定的，但是用这种方法的目的是为了解决现在的问题 - Georg Polya

本文中说的启发式思维方法是一种不严谨的但是又可以帮助你简化并解决一个难题的方法。

这种方法得到的结果并不一定正确，应该说他只在特定的条件下正确。

在软件测试中，启发式的思维方法可以作为测试的依据：

与本产品内的类似功能是否符合
与同类产品的同种功能是否符合
与本产品历史版本是否符合
与测试人员对系统的想象是否符合
与非技术文档以及本产品的广告的描述是否符合
与一些必须实现的要求是否符合
与用户的预期是否符合
与产品或者功能的明显目标是否符合
2.启发式方法和自动化测试的依据

我们经常会想要把一些或者所有测试变成自动化测试。自动化测试的程度取决于我们的能力，我们需要能够程序化地发现待测软件在什么情况下会通不过一个测试。我们自动化测试的能力从根本上受到我们对自动化测试的依据的构建和使用的能力所限制。

一种确定自动化测试的依据的基本方法是定义一组测试的预期结果。

比较你的待测程序的结果和你准备的作为自动化测试的依据的预期结果作比较，如果不符合，那么表示程序出错

前面用Microsoft Word的输出作为预期结果来对比Open Office这个待测程序的测试方法就属于这种。

这种方法是进行自动化测试的最直接的方式。

但是，有一个问题，就是我们要把待测程序跟什么东西来比较？换句话说，我们怎么确定这个测试的预期结果。在结果很复杂的时候，我们就不可能简简单单地做一个表格手工列上预期的结果。（比如测试Open Office的font size功能）

再看自动化测试的依据：

输入—>待测程序—>输出实际结果
输入—>测试依据—>输出预期结果
如上，自动化测试的依据也可以是一个程序。比如，用不同方法实现同种同能的代码作为依据（这种方法可靠度最高但是成本过高）；用类似功能的软件作为依据（比如我们前面测试Open Office的font size功能时就用到了Word）

自动化测试的对比测试结果和预期结果，其实就是一种启发式的方法。

自动化测试的这种对比不是严谨的 ，因为可能有：

误报：比如对比写字板和Word时，发现的不一致，有可能并不能算是bug（因为对软件的期望不同，见第四节）
漏报：比如对比写字板和Word，即使他们功能互相符合，也有可能遗漏一些共同的bug
自动化测试受到误报和漏报的影响，必然包含风险，是否要进行自动化测试，必须考虑这些风险。另外，可能会由于设计的变更导致一些误报，我们必须随时更新这些自动化测试脚本。

六.测试的不可穷尽性

什么样的测试才是穷尽的测试？

对于穷尽的测试，有一些理解是这样的:

穷尽“覆盖率”：测试每一行代码/每一个分支/每一个路径？
测试员不再发现新的bug？
测试计划完整地执行了？
穷尽的测试，真正的意思是，在测试完毕之后， 测试员知道在系统里没有残留着任何未知的BUG 。因为如果有未知的BUG，那么你可以通过做更多的测试来找到他们，你的测试也就还没有穷尽。
接下来针对上面的三种理解，做一个解释，
1.穷尽“覆盖率”：测试每一行代码/每一个分支/每一个路径？

有人认为软件测试的完整程度可以简单地看做是代码的覆盖率。

那么，什么是覆盖率？
----对某一段代码或者代码的某一种属性做测试，其测试达到的程度被称为是覆盖率，比如对语句的覆盖，对分支或者条件的覆盖，等等
----把现有的测试与可能的执行的测试做比较，现有测试能够占总的可能执行的测试的多少比例作为计算覆盖率的方法

但是这种覆盖率的经典定义，对软件测试的穷尽性来说，还太简单了。他没有考虑到一些情况，比如
-----输入特定的某个值或者某组值
-----在编码中遗漏的代码
-----中断，以及其他并行操作的情况

Cem Kaner在他的著作“Software Negligence & Testing Coverage”里列举了101种这样的例子
举一个很简单的例子,有代码如下：
Input A //此程序接收输入值A，B，然后打印A/B
Input B
Print A/B
在这个例子中，我们可以轻易地让覆盖率达到100%。

我们令A=2 B=1，则覆盖了此程序所有语句，也覆盖了所有分支。

但是这样的测试并不完整，或者说并没有穷尽，那么我们遗漏了什么，程序中还存在什么bug呢？

很显然这里令B=0的时候，程序不可避免地会出错。也就是说这段程序里，遗漏了当B=0时需要如何处理的代码。前面提到过的， 代码的遗漏，这种问题通过覆盖率根本无法发现。
计算并且追求实现高的覆盖率，是一种很好的方法来展示你距离穷尽的测试还有很大的距离。但是，如果你想她来确定你离穷尽的测试的距离究竟有多大，那么她并不是一种很好的工具。假如管理者一味地要求测试必须实现多少多少的覆盖率，反而会产生反效果，造就一大堆低效的测试用例。当测试员受

到必须达到百分之多少的覆盖率的压力的时候，自然而然就会去选择编写那些容易提高覆盖率的测试用例，而不是去实现那些更能发现bug的测试用例。并且一旦你规定了百分之几，几乎没有人会在达到你的标准之后，再去做更多的测试。
2.BUG发现率：测试员不再发现新的bug是否表示测试已经穷尽了.

一些人是用这样的一些统计曲线来衡量测试的完整程度。

每周发现新bug的数量曲线
每周状态仍然是open的bug的数量曲线
每周bug发现数量和修复数量的比例曲线
威布尔（Weibull）可靠度模型下的每周发现bug数量曲线：

Bug的曲线可以用作衡量测试的进程的参考，但是一些人试图把实际的数据拟合到理论化的曲线上来决定项目什么时候能完成。这其实是忽略了这些理论曲线成立的必要假设条件，比如威布尔模型的假设前提条件有：

测试时对软件的操作和实际使用时对软件的操作高度相似
所有的缺陷发生率都相等
缺陷的修复中都不引入新的缺陷
缺陷均互相独立
在测试开始时，软件中缺陷的总数已经确定不变
发现一个缺陷所需的时间服从威布尔分布的准则
在一个测试里发现的缺陷数量与其他测试里发现的缺陷数量互相独立
威布尔模型：

在实际的测试中，依赖这样一个每个前提假设都明显不成立的分布模型是很荒谬的。

使用这种bug曲线图表会产生一些副作用，其原因是：

当一个项目的bug发现情况被要求符合威布尔分布的时候，项目组员会因为压力而在项目初期很快地去提升bug数量
实际上，项目组成员，包括测试人员，在这种情况下经常会采用无效的方法，做一些从长远来看对项目没有好处的方法来尽快提升bug数量。
更多信息可以阅读Bob Austin’s的Measurement and management of performance in Organizations
更多关于这类问题在软件公司里发生的信息，阅读Doug Hoffman的The Dark Side of Software Metrics
那么副作用具体有哪些呢：

1） 曲线的走势可以很容易地从曲线的参数上来预测
2） 曲线越早达到峰值，就意味着项目可以越早结束
3） 所以，在测试的初期，压力集中在尽可能快地使bug数量上升上。于是，测试人员会这样子：

对已经知道是有错误或者不完整的功能进行测试
执行很多有关联的测试来发现很多有关联的bug
尽量去大量发现容易找到的bug而不是去发现隐蔽的bug
对于测试的组织，自动化的结构，工具等等都不重视，而只重视bug的发现数量（确实这样做在短期内回报很大，但是从长期来看是缺乏效率的）

4） 在曲线到达峰值之后，人们开始期望测试人员每周发现的bug数量都比上一周递减。
5） 而根据图表，在到达峰值之后，此后每周发现的bug数量都可以从模型中计算来预测出来，所以，在测试的后期，压力集中在减少新bug的发现数量上，于是，测试人员会这样子：

 执行很多已经执行过的回归测试
 不努力寻找新bug
 把工作中心转到评价、状态报告上
 把互相之间没有关联的bug当做是重复bug
 把有关联的bug当做是重复bug并且关闭，但是对于引起这个问题的原因却不深究。
 在通过新的进度衡量点（里程碑）之前隐瞒bug不报告
 在缺陷跟踪系统之外非正式的报告bug
 程序员会忽略测试员没有报告的bug
 更多的bug被打回