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

成浩亮  等:一种手绘制导的移动应用界面测试方法                                                         3679


             问题 3:测试语言中的逻辑连接符和测试框架的交互式反馈对测试有多大帮助?
             针对这 3 个研究问题,我们设计了 3 组不同实验.实验的手绘前端运行于 Android 23.0.0 平台,测试生成后端
         运行于一台 13 英寸的 MacBook Pro,CPU 是 Intel Core i5 2.7GHz,内存为 8G.我们招募了 12 名志愿者来完成手
         绘测试的对比实验.其中有 6 名志愿者有一定的软件测试经验,而另外 6 名为没有经验的在校学生.我们对志愿
         者进行了统一培训,保证其能理解并熟悉我们的手绘测试框架,并在实验时对他们进行了两两分组,每组由一位
         有经验的测试人员和一位在校学生组成.
         2.1   研究问题1:手绘的有效性
             在第 1 个实验中,我们对比了文献中移动应用界面测试的现有前沿技术和本文方法的测试效果,我们以 30
                                                                                             [9]
                                                                                [8]
         分钟时长内达到的测试覆盖率为评价指标来进行评估.我们对比了 onkey                       [12] ,AndroidRipper ,MobiGUITAR 以
         及 SwiftHand [13] 这 4 种前沿的测试框架,其中, Monkey 是目前最流行的随机测试框架,AndroidRipper 和
         MobiGUITAR 是前沿的基于模型移动测试框架,而 SwiftHand 是最新的机器学习制导的移动测试框架.对于我
         们的手绘制导方案,这 30 分钟测试时长中的 10 分钟用于手绘(包括 8 分钟初始手绘和 2 分钟交互式反馈),20
         分钟用于框架运行,对于用于对比的自动化测试框架,对应的 30 分钟全部用于框架运行.
             表 2 给出了本文方法与对比方法在基准用例集上的实验结果,由于对比方法实现接口和部署依赖的限制,
         我们在 Monkey,AndroidRipper 和 MobiGUITAR 上收集了语句覆盖率,而在 SwiftHand 上收集了分支覆盖率.对
         于本文手绘制导的测试方法,我们同时收集了语句覆盖率和分支覆盖率.从测试结果观察:本文手绘制导的移动
         应用测试方法在语句覆盖率上平均比 Monkey 高出 18.86 个百分点,比 AndroidRipper 高出 55.90 个百分点,比
         MobiGUITAR 也高出了 48.41 个百分点.在分支覆盖率上,本文手绘制导的移动应用测试方法比 SwiftHand 平均
         高出 6.12 个百分点.由此可知,手绘制导在移动应用界面的测试效果上能够起到非常关键的作用.
                            Table 2    Coverage of sketch-guided testing and other techniques
                        表 2   本文手绘制导测试方法与对比方法在基准用例集上的测试覆盖率
                                            语句覆盖率(%)                    分支覆盖率(%)
                      待测应用
                               Monkey  AndroidRipper  MobiGUITAR  手绘制导  SwiftHand  手绘制导
                      musicnote  46.85   4.01        29.83     84.12   62.30    73.63
                       whohas   59.35    16.31       32.89     78.35   54.40    61.39
                       explorer  69.36   2.52        16.49     69.40   62.94    53.42
                       weight   45.07    14.97       17.32     70.06   51.45    62.02
                        tippy   78.62    7.68        13.35     88.97   61.50    65.82
                      myexpense  42.57   12.82       9.48      62.04   34.40    45.42
                      mininote  29.15    4.25        6.39      41.89   24.20    28.14
                       mileage  30.60    9.52        14.68     59.79   24.50    39.64
                      anymemo   25.51    2.80        3.99      51.97   36.20    41.67
                       sanity   22.17    3.99        9.36      31.33   16.69    18.69
                       平均值      44.93    7.89        15.38     63.79   42.86    48.98

             进一步深入分析表 2 对应的测试结果可以观察到:用例集中像 sanity 这样的应用程序,无论哪个测试方法都
         不能达到很高的覆盖率.原因在于程序中存在大量图形界面无法触发的功能模块,包括传感器的相关功能、GPS
         定位功能等.这些功能导致了实验中 4 种前沿的图形化界面测试方法,与本文提出的手绘制导测试方法均不能
         通过界面测试来覆盖相关代码.在未来的工作中,我们考虑在手绘测试中引入对传感器、GPS 等部件的控制来
         解决这一问题.尽管如此,我们的手绘制导测试方法对于绝大多数应用程序已经能够获得显著的测试效果.

         2.2   研究问题2:手绘测试的人力消耗
             为了进一步分析手绘测试带来的人力消耗,我们对实验一进行了优化,让测试人员以不同的时间消耗来进
         行手绘,并观察手绘时间对测试结果的影响.在该实验中,我们要求测试人员分别提供 2 分钟内、4 分钟内、6 分
         钟内、7 分钟内以及 8 分钟的手绘图形,并以不同的图形驱动本文测试框架,测试效果见表 3、表 4.
   8   9   10   11   12   13   14   15   16   17   18