基本简介
黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等,主要用于软件确认测试。
测试特点
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。
测试方法
采用黑盒技术设计测试用例的方法有:等价类划分、边界值分析、错误推测、因果图和综合策略。
黑盒测试注重于测试软件的功能性需求,也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品,而是用于辅助白盒测试发现其他类型的错误。
黑盒测试试图发现以下类型的错误:
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的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.
除了上述几种黑盒测试的测试用例设计方法之外其他方法还包括判定表驱动分析方法、正交实验设计方法、功能图分析方法等。[1]
.
错误推测法
基于经验和直觉推测[2]
程序中所有可能存在的各种错误。
判断表驱动法
1. 条件桩:列出问题所有条件。通常认为列出的条件的次序不重要。
2. 动作桩:列出问题规定可能采取的操作。这些操作的排列顺序没有约束。
3. 条件项:列出针对它所列条件的取值,在所有可能的情况下的真假值。
4. 动作项:列出针对它所列条件的取值,在所有可能情况下的真假值。
5. 规则:任何一个条件组合的特定取值及其相应要执行的操作。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,条件项和动作项就有多少列。
判断表建立依据和步骤:
1. 确定规则的个数。假如有N个条件,每个条件有两个取值(0、1),故2N种规则。
2. 列出所有的条件桩和动作桩。
3. 填入条件项。
4. 填入动作项。制定初始判定表。
5. 简化。合并相似规则或者相同动作。
适合使用规定判定表设计用例的条件:
1. 规则说明以判定表的形式给出,或很容易转换成判定表。
2. 条件的排序顺序不影响执行那些操作。
3. 规则的排列顺序不影响执行那些操作。
4. 当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则。
5. 如果某一规则要执行多个操作,这些操作的执行顺序无关紧要。
正交试验法
从大量的实验数据中挑选适量的、有代表性的点,合理安排测试的设计方法。
1. 提取功能说明,构造因子--状态表把影响实验指标的条件称为因子,而影响实验因子的条件叫因子的状态。利用正交实验设计方法来设计测试用例时,首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素,把他们当作因子;而把各个因子的取值当作状态。对软件需求规格说明中的功能要求进行划分,把整体的、概要性的功能要求进行层层分解与展开,分解成具体的有相对独立性的、基本的功能要求。这样就可以把被测试软件中所有的因子都确定下来,并为确定每个因子的权值提供参考的依据。确定因子与状态是设计测试用例的关键。因此要求尽可能全面的、正确的确定取值,以确保测试用例的设计作到完整与有效。
2. 加权筛选,生成因素分析表对因子与状态的选择可按其重要程度分别加权。可根据各个因子及状态的作用大小、出现频率的大小以及测试的需要,确定权值的大小。
3. 利用正交表构造测试数据集利用正交实验设计方法设计测试用例,比使用等价类划分、边界值分析、因果图等方法有以下优点:节省测试工作工时;可控制生成的测试用例数量;测试用例具有一定的覆盖率。
功能图法
用功能图形象地表示程序的功能说明,机械的生成功能图的用例。功能图是一个黑盒、白盒混合用例设计方法。
功能图由状态迁移图和逻辑功能模型构成
1. 状态迁移图用于表示输入数据序列及其相应的输入数据。在状态迁移图中,有输入数据和当前状态决定输出数据和后续状态。
2. 逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系。逻辑功能模型只适合于描述静态说明,输出数据仅由输入数据决定。测试用例则由测试中经过的一系列状态和每个状态中必须依靠输入/输出数据满足的一对条件组成。
功能图方法中要用到逻辑覆盖和路径测试的概念和方法。要求设计人员对程序逻辑结构有清楚的了解。
生成用例:
1. 生成局部测试用例:在每个状态中,从因果图生成局部测试用例。局部测试库有原因值(输入数据)组合与对应的结果值(输出数据或状态)构成。
2. 测试路径生成:利用上面的规则生成从初始化状态到最后状态的测试路径。
3. 测试用例合成:合成测试路径与功能图中每个状态的局部测试用例。结果是视状态到最后状态的一个状态序列,以及每个状态中输入数据与对应输出数据组合。
4. 测试用例的合成算法:采用条件构造树。
场景法
事件触发时的情景便形成场景,而同一事件不同的触发顺序和处理结果就形成事件流.
测试方法的综合策略
1. 首先进行等价划分,包括输入、输出条件的等价划分,将无限测试变成有限测试。
2. 使用边界值分析法。
3. 使用错误推测发,追加一些用例。
4. 对照程序逻辑,检查用例设计的逻辑覆盖,力求达到覆盖标准。
5. 程序功能说明中有输入条件组合,就可选用因果图和判定表驱动法。
6. 对于参数配置类软件,用正交试验法选择较少组合到达最佳效果。
7. 功能图是用例设计的好方法,通过不同时期条件的有效性设计不同的测试数据。
对应业务流程清晰的系统,用场景法贯穿测试过程,在案例中综合使用各种测试方法。
黑盒测试的优点
1. 基本上不用人管着,如果程序停止运行了一般就是被测试程序CRASh了
2. 设计完测试例之后,下来的工作就是爽了,当然更苦闷的是确定crash原因
3、对比较大的代码单元来说,黑盒测试比白盒测试效率要高;
4、测试人员不需要了解实现的细节,包括特定的编程语言;
5、测试人员和编码人员是彼此独立的;
6、从用户的视角进行测试,很容易被理解和接受;
7、有助于暴露任何规格不一致或者有歧义的问题;
8、测试用例可以在规格完成之后马上执行。
黑盒测试的缺点
1. 结果取决于测试例的设计,测试例的设计部分来势来源于经验,OUSPG的东西很值得借鉴
2. 没有状态转换的概念,目前一些成功的例子基本上都是针对PDU来做的,还做不到针对被测试程序的状态转换来作
3. 就没有状态概念的测试来说,寻找和确定造成程序crash的测试例是个麻烦事情,必须把周围可能的测试例单独确认一遍。而就有状态的测试来说,就更麻烦了,尤其不是一个单独的tEStcase造成的问题。这些在堆的问题中表现的更为突出。
|