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

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

7: else if (et′:etset)∈subSequence(et)∧V(lastStep(et′))==lastVertex(p) then
8: P←P−{p}
9: while et″∈etset do
10: p′←addVertex(p,V(firstStep(et″)))
11: P←P∪{p′}
12: end while
13: end if
14: end while
15: ∀p∈P,O(p)←L.O e (et)
16: P←∅
17: end while
18: return O
在完成抽象事件流图模型 G 的构建后,测试生成后端将按照模型驱动的界面测试生成算法来生成用于界
面测试的用例.即:对模型 G 做完整遍历或者等概率均匀分布的随机路径遍历,并由遍历中的每一条路径生成一
个用于界面测试的运行脚本,最终由界面测试框架来执行脚本和比对测试结果.这一过程与已有的模型驱动测
试生成方法 [8−10] 类似,因此这里不再进一步详细赘述了.
在运行脚本的过程中,测试人员可能会发现真实的测试运行效果与期望效果不符或者测试人员产生了新
的测试需求,因此在测试生成后端,引入了交互式反馈来帮助用户完善测试.在测试人员手绘过程中,模型生成
和脚本生成时,各自额外维护一份日志文件.在手绘时,日志文件不仅简单明了地记录测试人员在每个状态下绘
制的逻辑动作步,还记录了测试人员绘制的各个逻辑动作步的次序.这就提供了充分的信息便于测试人员快速
定位在哪个逻辑动作步出现了问题.在建模过程中维护的日志文件,主要记录了模型的各个节点与布局文件中
语法符号的对应关系.测试脚本生成过程中维护的日志信息则记录了每一条测试语句与模型的各个节点的对
应关系.

2 实验评估

[5]
在已有的移动应用界面测试文献中,Choi 和 Choudhary [11] 构建了一套基准评估用例集,用来评估不同移动
应用界面测试方法的实施效果.本文亦以该用例集为基准来评估我们手绘界面测试方法的效果.该用例集的应
用程序全部来自于 F-Droid 开源应用市场,具体信息见表 1,其中,最小的应用程序为 music note,含 1 345 条字节
码指令和 245 个程序分支;最大的应用程序为 anymemo,含 72 145 条字节码指令和 4 954 个程序分支.
Table 1 Details of benchmark apps
表 1 基准用例集的详细信息
应用名称 类别 字节码指令数 方法数量 分支数量
musicnote education game 1 345 72 245
whohas lent item tracker 2 366 146 464
explorer JVM status lookup 6 034 252 885
weight weight tracker 4 283 222 813
tippy tip calculator 4 475 303 1 090
myexpense finance manager 11 472 482 1 948
mininote text viewer 13 892 680 2 489
mileage car management 44 631 2 583 3 761
anymemo falsh card 72 145 832 4 954
sanity system management 21 946 1 415 5 723
通过与已知移动应用界面测试技术进行对比实验,本文将试图回答以下 3 个重要的研究问题:
问题 1:手绘所表达的测试意图对提升测试效果能起到多大作用?
问题 2:使用本文框架进行移动应用程序的测试时,需要多少人力?