系统与软件工程软件测试设计技术

测试设计技术包含基于规格说明书的技术，基于结构的技术，基于经验的技术三大项。

一基于规格说明书的技术：

1.1 等价类划分

等价类划分使用测试项模型将测试项输入和输出划分为等价类(也称为“分区”)，其中每个等价类都应当作为一个测试条件。这些等价类应该从测试依据导出,对于每个分区中的所有值,都可以被测试项类似地处理(即等价类中的值是“等同的”)。有效的输入输出以及无效的输入输出均可导出等价类划分。

示例:对于期望小写字母字符作为(有效)输入的测试项,可以派生的无效输入等价类包括包含整数、实数、大写字母字符、符号和控制字符的等价类,具体取决于测试期间所需的严谨程度。

注1:对于输出等价类,基于测试项规格说明中描述的过程导出相应的输入分区。然后从输入分区中选择测试输人。

注 2:无效的输出等价类通常对应于未明确指定的任何输出。由于未指定,通常会根据各测试人员的主观判断得到等价类。当应用基于经验的技术(如错误猜测)时,也可能出现这种主观形式的测试设计。

注3:域分析法通常归类为等价类划分和边界值分析的结合。

1.2 分类树

分类树方法使用测试项模型将测试项的输入进行划分,并且用分类树的方式进行图形化表示。测试项的输入被分为若干个“分类”,每个划分由若干个独立(不重叠)的“类”和子类组成,同时分类集是完整的(被建模测试项的所有输入域都被识别并包括在所有分类内)。每个分类应是一个测试条件。根据测试的严格程度,通过分解分类得到的“类”可能会进一步分为“子类”。根据要求的测试覆盖程度,导出的划分和类可能同时包括有效和无效的输入数据。将分类,类和子类之间的层次关系塑造成一棵树,测试项的输入域作为树的根节点,分类作为分支节点,类或者子类作为叶节点。

注:分类树方法中的分区过程类似于等价类划分。其关键的区别在于,在分类树方法中,划分(分类和类别)必须完全不相交,而在等价类划分中,它们可能会重叠,具体取决于技术的应用方式。此外,分类树方法还包括分类树的设计,其提供测试条件的视觉展示。

1.3 边界值分析

边界值分析是通过对测试项模型边界值的分析,将测试项的输入和输出划分为具有可识别边界的多个有序集和子集(分区和子分区),其中每个边界是测试条件。边界应来自测试依据。

示例:一个分区的定义是从1~10的整数，该分区有两个边界，下边界是1，上边界是10，这些是测试条件。

注：对于输出边界，可基于测试项规格说明中描述的过程导出相应的输人分区，然后从输人分区中选择测试输人。

1.4 语法测试

语法测试使用测试项输入形式化的语法作为测试设计的依据。语法模型表示为多个规则,其中每个规则根据语法中的元素“序列”元素“迭代"或元素“之间的选择"来定义输人参数的形式。语法可以以文本或图形的形式表示。语法测试中的测试条件应为测试项输入的全部或部分模型。

示例1:巴科斯范式是一种形式化元语言,以文本形式定义一个测试项的语法。

示例2:抽象语法树可以图形化地表示形式化语法。

1.5 组合测试设计技术

组合测试设计技术用于系统地导出有效且可控的测试用例子集,其在测试期间覆盖了导出的测试条件和测试覆盖项。组合是根据测试项参数和参数可取的值来定义的。当多参数(每个参数都有大量离散值)必须相互作用的情况下,这种技术可以显著减少所需的测试用例数量,而不会影响功能覆盖率。

1.6 判定表测试

判定表测试以判定表的形式使用了测试项条件(原因)和动作(结果)之间的逻辑关系(判定规则)模型包括:

测试项的每个布尔条件定义了一对输入等价类,一个对应“真”，一个对应“假”；

每个动作是测试项的预期结果或结果的组合，其表示为布尔值；

一组判定规则表示了条件和动作之间的关系。

测试条件应为条件和动作。

注:如果条件由多个值而不是简单的布尔值组成,则会产生“扩展条目”判定表，其测试可以通过等价类划分来处理。

1.7 因果图

因果图法使用以因果图形式表示测试项原因(例如输入)和结果(例如输出)之间的逻辑关系(判定规则)模型包括:

测试项的每个布尔原因定义了一对输入等价类，一个对应“真”的情况，一个对应“假”的情况；

每个结果定义为测试项的预期结果条件或输出条件组合,表示为布尔值。

测试条件应为原因和结果。

因果图将原因和结果之间的逻辑关系建模为布尔运算符加权的布尔逻辑网络，并根据原因之间的关系和结果之间的关系进行语义和约束建模。

1.8 状态转移测试

状态转移测试使用测试项的状态模型,模型包含测试项可能的状态、状态间的转移,导致转移的实际和转移可能导致的动作。模型的状态应该是离散的、可识别的和数量有限的。单个转移可由事件守护进行约束,事件守护定义了一组条件,当事件发生时,该组条件应为真,从而发生转移。在状态转移测试中,测试条件可以是状态模型的所有状态,状态模型的所有转移或整个状态模型,这取决于测试的覆盖要求。模型可以表示为状态转移图或状态表(也可以使用其他表示方式)。

1.9 场景测试

场景测试使用测试项与其他系统之间的交互序列模型(在此周境中,用户通常被认为是其他系统)，以测试所涉及的测试项使用流程。测试条件应是一个交互序列(即一个场景)或所有交互序列(即所有场景)。

场景测试应该包括以下场景:

--“主”场景是测试项的预期典型动作序列,或无典型动作序列时所采取的一个任意选择；

--和“备选”场景表示测试项可选择的(非主)场景。

注1:备选的场景包括非正常的使用、极端或者压力条件和异常。

注2:场景测试通常在功能测试中用于产生“端到端测试”,比如系统测试或者验收测试。场景测试的一种常见形式称为用例测试,其采用了测试项的用例模型来描述测试项如何与一个或多个参与者交互,以测试相关测试项的交互序列(即场景)。

注3:在用例测试中,用例模型用于描述参与者如何触发测试项的各种动作。参与者可以是用户或其他系统。

注4:事务流测试也是一种场景测试。

1.10 随机测试

随机测试使用测试项的输入域模型来定义所有可能输入值的集合。应选择用于生成随机输入值的输入分布。整个输入域应是随机测试的测试条件。

示例:输入分布包括正态分布、均匀分布和运行剖面。

二基于结构的测试设计技术:

2.1语句测试

应导出测试项的源代码模型,并将语句标识为可执行或不可执行。每个执行语句应为一个测试条件。

注:可在步骤TD4期间采用自动化工具进行不可执行语句的识别。

2.2 分支测试

应导出识别控制流分支的测试项控制流模型。控制流模型的每个分支是一个测试条件分支包括:

从控制流的任一节点到另一节点的条件转移;

从控制流任一节点到另一节点控制的明确无条件转移；

当一个测试项有不止一个人口点时，到测试项一个人口点的控制转移。

注1:分支测试要达到100%的分支覆盖率,要求测试控制流图中的所有的弧(链接或边),包括任何入口和出口之间不包含判定的顺序语句。

注2:分支测试可以要求同时测试条件分支和非条件分支,包括测试项的入口和出口,这取决于要求的测试覆盖水平。

注3:在分支测试中,功能和方法调用不能被识别为独立的测试条件。

2.3 判定测试

应导出识别判定的测试项控制流模型。判定是测试项中可以产生控制流模型两个或多个结果(因此出现子路径)的点。典型的判定用于简单的选择(例如,源代码中的if-then-else),决定何时退出循环(例如,源代码中的while循环),以及case(switch)语句(例如,源代码中的case-1-2-3-.- N)。在判定测试中,控制流模型中的每个判定都应是测试条件。

2.4 分支条件测试

应导出识别判定和判定中条件的测试项控制流模型。判定是测试项中可以产生控制流模型两个或多个结果(因此出现子路径)的点。典型的判定用于简单的选择(例如,源代码中的if-then-else),决定何时退出循环(例如,源代码中的while循环),以及 case(switch)语句(例如,源代码中的 case-1-2-3-..-N，也称switch语句)。在分支条件中，每个判定都应是测试条件。

示例:在程序源代码中,判定语句“AORBANDCthen"是一个测试条件，包含了由逻辑运算符关联的3个条件。

2.5 分支条件组合测试

应导出识别判定和条件的测试项控制流模型。在分支条件组合测试中,每个判定都应该是一个测试条件。

示例:在程序源代码中,判定语句“if A or B and C then”是一个测试条件,包含了由逻辑运算符关联的3个条件。

2.6 修正条件判定覆盖测试

应导出标识判定和条件的测试项控制流模型。修正条件判定覆盖(MCDC)测试中,每个判定应为测试条件。

示例:在程序源代码中,判定语句“if A or B and C then”则包含了逻辑运算符关联的3个条件的测试条件。

2.7 数据流测试

在数据流测试中,应该导出测试项的模型,该模型识别测试项的控制流子路径,在该子路径中,给定变量的每个定义与该变量的后续使用相关,并且后续使用没有重新定义变量的值。

“定义”可能给变量赋了新的值(有时定义将变量保持与之前相同的值)。“使用”是变量出现,不是赋新的值;“使用”可以进一步划分为“p-use”(谓词使用)和“c-use”(计算使用)。谓词使用是指使用变量来确定判定条件(谓词)的结果,例如while-loop,if-then-else等。计算使用是指一个变量作为任何变量定义或输出的计算输入。

在数据流测试中,测试项中变量的每个定义-使用对都是测试条件。

有许多形式的数据流测试,它们都是基于相同的测试条件。本部分中定义的5种形式是:全定义测试、全谓词使用测试、全计算使用测试、全使用测试、全定义使用路径测试。