软件黑盒测试定义：

软件黑盒测试作用：

软件黑盒测试用例设计方法(等价类划分法： 错误推测法： 因果图法： 判定表(Decision Table)： 正交试验设计法：)

软件黑盒测试(功能测试)工具的选择(WinRunner： WinRunner的特点： WinRunner的工作流程：)

软件黑盒测试与软件白盒测试的区别：

软件黑盒测试的实施方案

软件黑盒测试定义：

软件黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。

软件黑盒测试也是软件测试的主要方法之一，也可以称为功能测试、数据驱动测试或基于规格说明的测试。测试者不了解程序的内部情况，只知道程序的输入、输出和系统的功能，这是从用户的角度针对软件界面、功能及外部结构进行测试，而不考虑程序内部逻辑结构。

软件黑盒测试作用：

软件黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误：

1.功能不正确或遗漏；

2.界面错误；

3.数据库访问错误；

4.性能错误；

5.初始化和终止错误等。

从理论上讲，软件黑盒测试只有采用穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但可能的输入进行测试。这样看来，完全测试是不可能的，所以我们要进行有针对性的测试，通过制定测试案例指导测试的实施，保证软件测试有组织、按步骤，以及有计划地进行。软件黑盒测试行为必须能够加以量化，才能真正保证软件质量，而测试用例就是将测试行为具体量化的方法之一。具体的软件黑盒测试用例设计方法包括等

软件黑盒测试用例设计方法

大致可以分为以下几种：等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等下面详细列举几种仅供参考。

等价类划分法：

是把程序的输入域划分成若干部分(子集)，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。该方法是一种重要的，常用的软件黑盒测试用例设计方法。

1) 划分等价类：等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据，取得较好的测试结果，等价类划分可有两种不同的情况：有效等价类和无效等价类。

有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合，利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

无效等价类：与有效等价类的定义恰巧相反。

设计测试用例时，要同时考虑这两种等价类。因为，软件不仅要能接收合理的数据，也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。

2)划分等价类的方法：下面给出六条确定等价类的原则。

①在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。

②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。

③在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。

④在规定了输入数据的一组值(假定n个)，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。

⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。

⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

3)设计测试用例：在确立了等价类后，可建立等价类表，列出所有划分出的等价类：

输入条件 有效等价类 无效等价类

... ... ...

... ... ...

然后从划分出的等价类中按以下三个原则设计测试用例：

①为每一个等价类规定一个唯一的编号。

②设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。

③设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。

边界值分析是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。它是对等价类划分方法的补充。

(1)边界值分析方法的考虑：

长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况，应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

(2)基于边界值分析方法选择测试用例的原则：

1)如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。

2)如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据。

3)根据规格说明的每个输出条件，使用前面的原则1).

4)根据规格说明的每个输出条件，应用前面的原则2).

5)如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。

6)如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。

7)分析规格说明，找出其它可能的边界条件。

错误推测法：

是基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的设计测试用例的方法。 错误推测方法的基本思想：

列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。 例如， 在单元测试时曾列出的许多在模块中常见的错误，以前产品测试中曾经发现的错误等， 这些就是经验的总结。 还有， 输入数据和输出数据为0的情况，输入表格为空格或输入表格只有一行，这些都是容易发生错误的情况， 可选择这些情况下的例子作为测试用例。

因果图法：

前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系， 相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。 但要检查输入条件的组合不是一件容易的事情， 即使把所有输入条件划分成等价类，他们之间的组合情况也相当多，因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例，这就需要利用因果图(逻辑模型)。

因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。

利用因果图生成测试用例的基本步骤：

(1) 分析软件规格说明描述中， 那些是原因(即输入条件或输入条件的等价类)，那些是结果(即输出条件)， 并给每个原因和结果赋予一个标识符。

(2) 分析软件规格说明描述中的语义.找出原因与结果之间， 原因与原因之间对应的关系，根据这些关系，画出因果图。

(3) 由于语法或环境限制， 有些原因与原因之间，原因与结果之间的组合情况不不可能出现，为表明这些特殊情况， 在因果图上用一些记号表明约束或限制条件。

(4) 把因果图转换为判定表。

(5) 把判定表的每一列拿出来作为依据，设计测试用例。

从因果图生成的测试用例(局部，组合关系下的)包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而线性地增加。

判定表(Decision Table)：

前面因果图方法中已经用到了判定表，判定表(Decision Table)是分析和表达多逻辑条件下执行不同操作的情况下的工具，在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了，由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。

判定表通常由四个部分组成。

条件桩(Condition Stub)：列出了问题得所有条件，通常认为列出得条件的次序无关紧要。

动作桩(Action Stub)：列出了问题规定可能采取的操作，这些操作的排列顺序没有约束。

条件项(Condition Entry)：列出针对它左列条件的取值，在所有可能情况下的真假值。

动作项(Action Entry)：列出在条件项的各种取值情况下应该采取的动作。

规则：任何一个条件组合的特定取值及其相应要执行的操作，在判定表中贯穿条件项和动作项的一列就是一条规则。显然，判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列。

判定表的建立步骤：(根据软件规格说明)

①确定规则的个数，假如有n个条件，每个条件有两个取值(0.1)，故有 种规则。

②列出所有的条件桩和动作桩。

③填入条件项。

④填入动作项，等到初始判定表。

⑤简化，合并相似规则(相同动作)。

B. Beizer 指出了适合使用判定表设计测试用例的条件:

①规格说明以判定表形式给出，或很容易转换成判定表。

②条件的排列顺序不会也不影响执行哪些操作。

③规则的排列顺序不会也不影响执行哪些操作。

④每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。

⑤如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。

正交试验设计法：

就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率。

软件黑盒测试的优点

1. 基本上不用人管着，如果程序停止运行了一般就是被测试程序crash了

2. 设计完测试例之后，下来的工作就是爽了，当然更苦闷的是确定crash原因

软件黑盒测试的缺点

1. 结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG的东西很值得借鉴

2. 没有状态转换的概念，目前一些成功的例子基本上都是针对PDU来做的，还做不到针对被测试程序的状态转换来作

3. 就没有状态概念的测试来说，寻找和确定造成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来说，就更麻烦了，尤其不是一个单独的testcase造成的问题。这些在堆的问题中表现的更为突出。

软件黑盒测试(功能测试)工具的选择

那么，如何高效地完成功能测试？选择一款合适的功能测试工具并培训一支高素质的工具使用队伍无疑是至关重要的。尽管现阶段存在少数不采用任何功能测试工具，从事功能测试外包项目的软件服务企业。短期来看，这类企业盈利状况尚可，但长久来看，它们极有可能被自动化程度较高的软件服务企业取代。

目前，用于功能测试的工具软件有很多，针对不同架构软件的工具也不断推陈出新。这里重点介绍的是其中一个较为典型自动化测试工具，即Mercury公司的WinRunner。

WinRunner：

是一种用于检验应用程序能否如期运行的企业级软件功能测试工具。通过自动捕获、检测和模拟用户交互操作，WinRunner能识别出绝大多数软件功能缺陷，从而确保那些跨越了多个功能点和数据库的应用程序在发布时尽量不出现功能性故障。

WinRunner的特点：

与传统的手工测试相比，它能快速、批量地完成功能点测试；能针对相同测试脚本，执行相同的动作，从而消除人工测试所带来的理解上的误差； 此外，它还能重复执行相同动作，测试工作中最枯燥的部分可交由机器完成； 它支持程序风格的测试脚本，一个高素质的测试工程师能借助它完成流程极为复杂的测试，通过使用通配符、宏、条件语句、循环语句等，还能较好地完成测试脚本的重用；它针对于大多数编程语言和Windows技术，提供了较好的集成、支持环境，这对基于Windows平台的应用程序实施功能测试而言带来了极大的便利。

WinRunner的工作流程：

1.识别应用程序的GUI

在WinRunner中，我们可以使用GUI Spy来识别各种GUI对象，识别后，WinRunner会将其存储到GUI Map File中。它提供两种GUI Map File模式: Global GUI Map File和GUI Map File per Test。其最大区别是后者对每个测试脚本产生一个GUI文件，它能自动建立、存储、加载，推荐初学者选用这种模式。但是，这种模式不易于描述对象的改变，其效率比较低，因此对于一个有经验的测试人员来说前者不失为一种更好的选择，它只产生一个共享的GUI文件，这使得测试脚本更容易维护，且效率更高。

2.建立测试脚本

在建立测试脚本时，一般先进行录制，然后在录制形成的脚本中手工加入需要的TSL(与C语言类似的测试脚本语言)。录制脚本有两种模式：Context Sensitive和Analog，选择依据主要在于是否对鼠标轨迹进行模拟，在需要回放时一般选用Analog。在录制过程中这两种模式可以通过F2键相互切换。

只要看看现代软件的规模和功能点数就可以明白，功能测试早已跨越了单靠手工敲敲键盘、点点鼠标就可以完成的阶段。而性能测试则是控制系统性能的有效手段，在软件的能力验证、能力规划、性能调优、缺陷修复等方面都发挥着重要作用。

3.对测试脚本除错(debug)

在WinRunner中有专门一个Debug Toolbar用于测试脚本除错。可以使用step、pause、breakpoint等来控制和跟踪测试脚本和查看各种变量值。

4.在新版应用程序执行测试脚本

当应用程序有新版本发布时，我们会对应用程序的各种功能包括新增功能进行测试，这时当然不可能再来重新录制和编写所有的测试脚本。我们可以使用已有的脚本，批量运行这些测试脚本测试旧的功能点是否正常工作。可以使用一个call命令来加载各测试脚本。还可在call命令中加各种TSL脚本来增加批量能力。

5.分析测试结果

分析测试结果在整个测试过程中最重要，通过分析可以发现应用程序的各种功能性缺陷。当运行完某个测试脚本后，会产生一个测试报告，从这个测试报告中我们能发现应用程序的功能性缺陷，能看到实际结果和期望结果之间的差异，以及在测试过程中产生的各类对话框等。

6.回报缺陷(defect)

在分析完测试报告后，按照测试流程要回报应用程序的各种缺陷，然后将这些缺陷发给指定人，以便进行修改和维护。

软件黑盒测试与软件白盒测试的区别：

软件黑盒测试：

已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。

软件白盒测试：

已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此软件黑盒测试又叫功能测试或数据驱动测试。

软件黑盒测试主要是为了发现以下几类错误：

1、是否有不正确或遗漏的功能。

2、在接口上，输入是否能正确的接受，能否输出正确的结果。

3、是否有数据结构错误或外部信息(例如数据文件)访问错误。

4、性能上是否能够满足要求。

5、是否有初始化或终止性错误。

软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。

白盒测试主要是想对程序模块进行如下检查：

1、对程序模块的所有独立的执行路径至少测试一遍。

2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。

3、在循环的边界和运行的界限内执行循环体。

4、测试内部数据结构的有效性，等等。

以上事实说明，软件测试有一个致命的缺陷，即测试的不完全、不彻底性。由于任何程序只能进行少量(相对于穷举的巨大数量而言)的有限的测试，在未发现错误时，不能说明程序中没有错误。

软件黑盒测试的实施方案

传统系统的编程语言和逻辑全是过程式的。这种逻辑顺序只有当数据中的值引起不同的循环或控制顺序改变时才会发生变化。

客户机/服务器和图形用户界面系统不是过程式的。它们是事件驱动的。这意味着计算机针对发生的事件执行相应的程序。这里的事件是指用户采取的行为，象键盘活动，鼠标移动，鼠标击键动作和按键的动作，都是事件的例子。因为事件发生的顺序不能预先知道，事件驱动系统相对来说更难测试。开发人员不可能知道用户下一次要选中哪个按钮或菜单项。实际上，应用程序必须在任何时候对所有发生和可能发生的事件作好正确处理的准备。

另外，随着RAD(快速应用开发方式)的引入，导致应用的实现速度很快，但这种方式也有它的不足。一个重要的缺点是项目规划经常漏掉重要的测试阶段。测试象在传统开发项目中一样，经常被忽视，并且给予很不现实的少量时间和资源。对于这一点，测试RAD方式下提交的应用并保证软件质量是测试团队的首要工作。

软件黑盒测试在实施时又分为客户端的测试和服务器端的性能测试。客户端的测试主要关注应用的业务逻辑，用户界面，功能测试等;服务器端的测试主要关注服务器的性能，衡量系统的响应时间、事务处理速度和其他时间敏感的需求。在应用系统最终被交付之前保证这两方面的测试没有缺陷。

由于测试并不是进行一次就可以完成的个过程，而是需要根据产品版本的变化生成不同的测试过程，如果这一过程仅通过手工方式完成是很难达到的。需要通过工具的帮助，从而简化测试的复杂程度，降低在测试成本上的开销，缩短投放市场的时间。还有一个突出的特点就是应用程序的回归测试，这是手工方式完成不了的过程，只有通过工具才能实施。而回归测试在测试阶段是很重要的过程，通过回归测试可以发现很多隐含的缺陷和错误。

在服务器端的测试主要以模拟合法用户活动给系统的负载，负载测试的统计结果被用来预测用户将体验到的性能和响应时间。这都需要在客户机/服务器系统发行之前都要进行的。