Page 10 - 《软件学报》2020年第12期

3676 Journal of Software 软件学报 Vol.31, No.12, December 2020

接下来,我们描述该测试语言的语义.手绘图形在语义上定义了测试所需覆盖的所有动作序列所构成的动
作序列集,该集合是以下列方式来定义的.
• 首先,在语法上,由分号或者冒号分隔的各个逻辑动作步在语义上定义了动作序列中的一个动作.为了
便于区分测试语言的语法元素,我们假定实际测试的动作序列为 s 1 ;s 2 ;s 3 ;...;s n ,其中,s i 是该次测试序列
中的第 i 个动作;
• 其次,对于每一个逻辑动作步,由手绘语法上的“动作元素+范围元素”在语义定义动作集(例如公式(1)
中动作集的 A 1 ,A 2 ),由量词定义基本动作步内各动作集的数量关系,由逻辑连接符定义基本动作步之间
的逻辑关系.
最终,公式(1)所定义的动作序列集如下:
{s 1 ;s 2 ;s 3 ;...;s n |(∀s 1 ∈A 1 ∧s 1 ≠a 1 )∧(s 2 =a 2 )∧…∧(∀s n ∈A 2 )} (2)
用户在按照测试语言语法完成手绘图形后,本文框架的手绘前端会将图形记录在布局文件 L 内,并将其传
递给后端生成测试用例.布局文件 L 中记录了已经经过形状识别并按照图 6 语法建立的图形描述序列 l、测试
目标 O e 以及待测程序的界面控件信息 W.这里的 O e 和 W 都以映射的形式来存储:O e 将语法上的每一条序列映
射到一个测试目标判断条件上,而 W 则将程序界面上的坐标值映射到界面控件的标识符上.
1.2 测试生成后端
测试生成后端由手绘前端输出的布局文件来构建对应测试模型,并依据模型产生测试脚本.从框架的实用
性考虑,我们希望构建对于大型软件来说也足够简单的测试模型,模型中仅包含满足用户测试意图的动作序列.
本文设计抽象事件流图模型来满足这些需求.与已有的事件流图模型 [6,7] 中每一个节点都是一个具体测试动作
不同,抽象事件流图模型中的每一个节点 v 代表一个逻辑动作步.由于模型中的逻辑动作步表示一个经过抽象
的事件集,因此该模型在表达形式上更为简洁.在抽象事件流图模型中,连接两个不同抽象事件节点 v 1 ,v 2 的边表
示事件的连续触发关系.具体来说,当模型中存在边(v 1 ,v 2 )时,用户希望能够测试节点 v 2 所定义的任意事件 e 2 紧
跟着节点 v 1 对应事件 e 1 的触发序列.我们将抽象事件流图 G 形式化定义为一个四元组〈V,E,V 0 ,O〉,其中,
1. V 代表抽象事件流图 G 的节点集,其中的每个节点 v∈V 都是由测试者手绘生成的一个逻辑动作步构
成的;
2. E⊆V*V 代表抽象事件节点之间的有向边集.对于边(v 1 ,v 2 )∈V 而言,且∀e 1 ∈v 1 ,∀e 2 ∈v 2 ,则事件 e 2 是可以
在事件 e 1 发生之后立即触发.且作为模型的一部分,用户希望先后发生这两个事件的序列能及时被测
试到;
3. V 0 ⊆V 代表起始节点集,即允许测试该应用的第 1 个逻辑动作步所构成的集合;
4. O 是一个代表测试目标(oracle)的映射.它将抽象事件流图 G 中的每一条事件序列映射到一个用于判
断测试目标是否达成的判定条件上:如果测试完该序列后判定条件得到满足,则测试通过;否则,测试
不通过.如果有抽象事件流图中的事件序列未在 O 中定义,则对应的判定条件为缺省条件,即程序是否
崩溃.
算法 1 描述了本文从手绘布局文件 L 中构建抽象事件流图模型 G 的过程.手绘布局文件 L 由三元组〈l,W,O e 〉
定义,其中:l 是按照图 6 的语法定义的图形描述序列;W 保存了每一个界面控件的坐标信息,它将坐标值映射到
控件标识上;而 O e 记录了用户完成手绘过程中定义的测试目标,即,将 l 定义的描述图形序列映射到判断测试目
标是否达成的判定条件上.
算法 1. 抽象事件流图的建模算法.
输入:L〈l,W,O e 〉;
输出:G〈V,E,V 0 ,O〉.
1: while s∈logicStep(L.l) do
2: t v ←vertexGenerate(s)
3: while p t ∈pointCoodinate(t v ) do