B
UR
GUILLO
,
L
LAMAS
,
F
ERN
A
'
NDEZ
,
R
OBLES
2.2
形式化测试概念
关于测试,重要的是定义一个关系,以建模实现与其规范的一致性在文献
中有几个关系可以选择[14]。由于我们想将我们的框架与其他方法进行比较
并重用现有的理论,因此我们选择了[2,14]中描述的一致性关系conf它的
优点是,只有规范中包含的行为必须被测试,减少了测试空间。关系
conf
定义如下:
定义2(条件:conf)
设
I
,
S∈LTS(L)
,我们说
IconfS
当且仅当对每个迹
σ∈Tr(S)
和对每个子集
A∈L
下面的命题成立:如果
A∈Ref(I
,
σ)
,
则
A
∈
Ref
(
S
,
σ
)
如果
σi ∈Tr(I)
,我们假设
Ref(I
,
σ)
为空。
为了决定一个测试用例是否成功,我们使用
判定
。参考文献[10]提出了
三种可能的判定:通过(通过,当观察到的行为满足测试时),未通过
(未通过,当观察到的行为是无效的规范行为时)和不确定(inc,观察到
的行为到目前为止是有效的,但无法完成测试)。这些概念的形式化如下
[14]
:
定义
3
(测试用例)
测试用例
tc
是一个
5
元组
<Stat
,
L
,
T
,
v
,
s
0
>
,使得
<Stat
,
L
,
T
,
s
0
>
是一个具有有限行为的确定性转移系统,
v
:
Stat
→
{
fail
,
pass
,
inc
}
是一个分配判决的函数。
定义
4
(测试套件)
测试套件或测试集合
ts
是测试用例的集合:
ts
∈
P
owerSet
(
LT S
t
(
L
))
测试用例的执行由测试用例与被测实现(
IUT
)的并行同步执行来建模
这样的执行继续,直到不再有交互,即,陷入僵局。这种死锁可能是因为
测试用例tc达到最终状态,或者当tc和IUT的组合达到不接受tc执行的操作
的状态时出现。
当且仅当测试用例的判决在达到死锁时通过时由于实现
可能具有不确定
性行为,因此
使用相同
IUT
对相同测试用例的不同执行可能会达到不同的最
终状态,从而导致不同的判决。一个实现通过测试用例
tc
,当且仅当所有
tc
的执行都产生一个通过判决。这意味着我们应该多次执行每个测试用例以
获得最终判决,理想情况下是无限次。
测试生成算法根据规范提供测试套件。理想情况下,
当且仅当实现符合
时,它必须通过测试套件。不幸的是,在实践中,这样的测试套件将有无
限多的测试用例。因此,在现实世界中,我们必须将自己限制在(有限大
小的)测试套件中,这些测试套件只能检测不一致性,但不能检测一致
性。