黑盒测试

一、等价类划分：

　　是把所有可能的输入数据，即程序的输入域划分成若干部分(子集)，然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的，常用的黑盒测试用例设计方法。

　　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）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.
 判定表通常由四个部分组成.
 条件桩（Condition Stub）:列出了问题得所有条件.通常认为列出得条件的次序无关紧要.
 动作桩（Action Stub）:列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.
 条件项（Condition Entry）:列出针对它左列条件的取值.在所有可能情况下的真假值.
 动作项（Action Entry）:列出在条件项的各种取值情况下应该采取的动作.
 规则:任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列.
 判定表的建立步骤:（根据软件规格说明）
 ① 确定规则的个数.假如有n个条件.每个条件有两个取值（0,1）,故有 种规则.
 ② 列出所有的条件桩和动作桩.
 ③ ③填入条件项.
 ④ ④填入动作项.等到初始判定表.
 ⑤ ⑤简化.合并相似规则（相同动作）.
 B. Beizer 指出了适合使用判定表设计测试用例的条件:
 ①规格说明以判定表形式给出,或很容易转换成判定表.
 ②条件的排列顺序不会也不影响执行哪些操作.
 ③规则的排列顺序不会也不影响执行哪些操作.
 ④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则.
 ⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要.
 五、路径覆盖
 熟悉测试理论的人都知道，路径覆盖是白盒测试中一种很重要的方法，广泛应用于单元测试。那么基于路径覆盖的分析方法是不是只能应用于单元测试呢，能不能将其推而广之呢。一般而言，在单元测试中，路径就是指函数代码的某个分支，而实际上如果我们将软件系统的某个流程也看成路径的话，我们将可以尝试着用路径分析的方法来设计测试用例。采用路径分析的方法设计测试用例有两点好处：一是降低了测试用例设计的难度，只要搞清了各种流程，就可以设计出高质量的测试用例来，而不用太多测试方面的经验；二是在测试时间较紧的情况下，可以有的放矢的选择测试用例，而不用完全根据经验来取舍。下面就具体的介绍一下如何用路径分析的方法编写测试用例。
     首先是将系统运行过程中所涉及到的各种流程图表化，可以先从最基本的流程入手，将流程抽象成为不同功能的顺序执行。在最基本流程的基础上再去考虑次要或者异常的流程，这样将各种流程逐渐细化，这样既可以逐渐加深对流程的理解，还可以将各个看似孤立的流程关联起来。完成所有流程的图表化后就完成了所有路径的设定。
     找出了所有的路径，下面的工作就是给每条路径设定优先级，这样在测试时就可以先测优先级高的，再测优先级低的，在时间紧迫的情况下甚至可以考虑忽略一些低优先级的路径。优先级根据两个原则来选取：一是路径使用的频率，使用越频繁的优先级越高；二是路径的重要程度，如果失败对系统影响越大的优先级越高。将根据两个原则所分别得到的优先级相加就得到了整个路径的优先级。根据优先级的排序就可以更有针对性的进行测试。
     为每条路径设定好优先级后，接下来的工作就是为每条路径选取测试数据，构造测试用例。一条路径可以对应多个测试用例，在选取测试数据时，可以充分利用边界值选取等方法，通过表格将各种测试数据的输入输出对应起来，这样就完成了测试用例的设计。
     对于测试人员而言，测试用例的设计是一件非常困难的工作，而同时测试用例的设计好坏又直接关系到整个系统的设计质量。本文介绍了一种更理论化的设计方法来尽量简化这种工作，将一般应用于单元测试的路径分析方法推广到集成测试、系统测试等后续测试过程中，希望能给大家一点启示。
六、功能图
 功能图方法是一种黑盒、白盒混合用例设计方法，是功能图FD形式化地表示程序的功能说明，并机器地生成功能图的测试用例。功能图模型由状态迁移图和逻辑功能模型构成。
 状态迁移图用于表示输入数据序列以及相应的输出数据。在状态迁移图中，由输入数据和当前状态决定输出数据和后续状态。
 逻辑功能模型用于表示在状态输入条件和输出条件之间的对应关系。逻辑功能模型只适合于描述静态说明，输出数据仅由输入数据决定。测试用例则由测试中的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成。
 （1）功能图：功能图由状态迁移图和布尔函数组成。状态迁移图用状态和迁移来描述。一个状态指出数据输入的位置（或时间），而迁移则指明状态的改变，同时要依靠判定表或是因果图表示的逻辑功能。例如，一个简化的自动出纳ATM机的功能图。
 （2）测试用例生成方法：从功能图生成测试用例，得到的测试用例数是可以接受的。问题的关键是如何从状态迁移图中选取测试用例。若用节点代替状态，用弧线代替迁移，则状态迁移图就可转化成一个程序的控制流程图形式。问题就转化为程序的路径测试问题了。
 （3）测试用例生成规则： 为了把状态迁移的测试用例与逻辑模型的测试用例相组合起来，从功能图生成生成实用的测试用例，需定义下面的规则。在一个结构化的迁移（SST）中，定义三种形式的循环：顺序、选择和重复。但分辨一个状态迁移中的所有循环是有困难的。
 （4）从功能图生成测试用例的过程。
 A、生成局部测试用例：在每个状态中，从因果图生成局部测试用例。局部测试用例由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成。
 B、测试路径生成：利用上面的规则（3种）生成从初始状态到最后状态的测试路径。
 C、测试用例合成： 合成测试路径与功能图中每个状态的局部测试用例。结果是初始状态到最后状态的一个状态序列，以及每个状态中输入数据与对应输出数据的组合。
 D、测试用例的合成算法：采用合成构造树。
七、正交试验设计法
 1、什么是因素（Factor在一项试验中，凡欲考察的变量称为因素（变量）
 2、什么是水平（位级Level在试验范围内，因素被考察的值称为水平（变量的取值）
 3、什么是正交试验设计
 是研究多因素多水平的一种设计方法，它是根据正交性从全面试验中挑选出部分有代表性的点进行试验，这些有代表性的点具备了均匀分散，齐整可比的特点，正交试验
 设计是一种基于正交表的、高效率、快速、经济的试验设计方法

 4、正交表的构成 正交表的构成
 行数(Runs)：正交表中的行的个数，即试验的次数
 因素数(Factors)：正交表中列的个数。
 水平数：任何单个因素能够取得的值的最大个数。
 正交表中的包含的值为从最大个数。正交表中的包含的值为从0到数 到数“水平 水平数-1”或从 或从1到“水平数 水平数”。
 正交表的表示形式： L行数 (水平数因素数)
 正交表的正交性

 整齐可比性
 在同一张正交表中，每个因素的每个水平出现次数是完全相同的。由于在试验中每个因素的每个水平与其它因素的每个水平参与试验的机率是完全相同的，这就保证在各个水平中最大程度的排除了其它因素水平的干扰。因而，能最有效地进行比较和作出展望，容易找到好的试验条件进行。

 均衡分散性
 在同一张正交表中，任意两列（两个因素）的水平搭配（横向形成的数字对）是完全相同的。这样就保证了试验条件均衡地分散在因素水平的完全组合之中，因而具有很强的代表性，容易得到好的试验条件。

七.一、 用正交表设计测试用例
 用正交表设计测试用例的步骤

 1 有哪些因素（变量）
 2 每个因素有哪几个水平（变量的取值）
 3 选择一个合适的正交表
 4 把变量的值映射到表中
 5 把每一行的各因素水平的组合做为一个测试用例
 6 加上你认为可疑且没有在表中出现的组

 

如何选择正交表：
 考虑因素（变量）的个数
 考虑因素水平（变量的取值）的个数
 考虑正交表的行数
 取行数最少的一个

 

设计测试用例时的三种情况：

 1 因素数（变量）、水平数（变量值）相符
 2 因素数不相同
 3 水平数不相同

 因素数、水平数相符 因素数、水平数相符
 水平数（变量的取值）相同、因素数（变量）刚好符合正交表。
 八、场景设计方法
 现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。
 基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止或者终止用例而不再重新加入到某个流（如备选流2和4）。

在这个图中，有一个基本流和四个备选流。

每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：

场景 1 基本流

场景 2 基本流 备选流 1

场景 3 基本流 备选流 1 备选流 2

场景 4 基本流 备选流 3

场景 5 基本流 备选流 3 备选流 1

场景 6 基本流 备选流 3 备选流 1 备选流 2

场景 7 基本流 备选流 4

场景 8 基本流 备选流 3 备选流 4

场景法的基本设计步骤:

根据说明，描述出程序的基本流及各项备选流

根据基本流和各项备选流生成不同的场景

对每一个场景生成相应的测试用例

对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值

实例
1. 例子描述
下图所示是ATM例子的流程示意图。
 
2.场景设计：下表所示是生成的场景。
表3-8 场景设计

场景1——成功提款
 基本流
 
 
场景2——ATM内没有现金
 基本流
 备选流2
 
场景3——ATM内现金不足
 基本流
 备选流3
 
场景4——PIN有误（还有输入机会）
 基本流
 备选流4
 
场景5——PIN有误（不再有输入机会）
 基本流
 备选流4
 
场景6——账户不存在/账户类型有误
 基本流
 备选流5
 
场景7——账户余额不足
 基本流
 备选流6
 

注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入上表。
3.用例设计
对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。

 

表3-9 测试用例表

  

TC（测试用例）ID号
 场景/条件
 PIN
 账号
 输入（或选择）的金额
 账面

金额
 ATM内的金额
 预期结果
 
CW1
 场景1：成功提款
 V
 V
 V
 V
 V
 成功提款
 
CW2
 场景2：ATM内没有现金
 V
 V
 V
 V
 I
 提款选项不可用，用例结束
 
CW3
 场景3：ATM内现金不足
 V
 V
 V
 V
 I
 警告消息，返回基本流步骤6，输入金额
 
CW4
 场景4：PIN有误（还有不止一次输入机会）
 I
 V
 n/a
 V
 V
 警告消息，返回基本流步骤 4，输入 PIN
 
CW5
 场景4：PIN有误（还有一次输入机会）
 I

 
 V
 n/a
 V
 V
 警告消息，返回基本流步骤 4，输入 PIN
 
CW6
 场景4：PIN有误（不再有输入机会）
 I
 V
 n/a
 V
 V
 警告消息，卡予保留，用例结束
 

 

4.数据设计
一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。
测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据，如表3-10所示。

 

 

 

 

 

 

 

 

表3-10      测试用例表

TC（测试用例）ID号
 场景/条件
 PIN
 账号
 输入（或选择）的金额

（元）
 账面
金额（元）
 ATM内的金额（元）
 预期结果
 
CW1
 场景1：成功提款
 4987
 809-498
 50.00
 500.00
 2 000
 成功提款。账户余额被更新为450.00
 
CW2
 场景2：ATM内没有现金
 4987
 809-498
 100.00
 500.00
 0.00
 提款选项不可用，用例结束
 
CW3
 场景3：ATM内现金不足
 4987
 809-498
 100.00
 500.00
 70.00
 警告消息，返回基本流步骤6，输入金额
 
CW4
 场景4：PIN有误（还有不止一次输入机会）
 4978
 809-498
 n/a
 500.00
 2 000
 警告消息，返回基本流步骤4，输入PIN
 
CW5
 场景4：PIN有误（还有一次输入机会）
 4978
 809-498
 n/a
 500.00
 2 000
 警告消息，返回基本流步骤4，输入PIN
 
CW6
 场景4：PIN有误（不再有输入机会）
 4978
 809-498
 n/a
 500.00
 2 000
 警告消息，卡予保留，用例结束