Abstract
- Background: Functional correctness很重要,但难测,传统人测,工具只测crash bugs
- 目的: 利用independent view properties,从种子测试中生成大量property-preserving tests,用来确保具体的app view properties不因为无关操作而改变
- 成果: 工具GENIE
- 能无需人工提供测试或者oracles,自动发现functional bugs
- Q: the detected functional bugs are diverse, thus general and not limited to specific functional properties - 实验
- 数据: 12个Apps
- 结果:
- 检测到33个新functional bugs,都经过开发者确认,其中21个被修复
- 检测到26个crash bugs,其中24个被确认,14个fixed
Intro
背景:
- GUI测试工具,例如Monkey, Sapienz, Stoat: 仅能测crash bugs
- off-the-shell test automation framework, 如Expresso, Robotium, Appium, 能够自动运行测试,但是需要人为设计验证方式
- 静态分析工具,如Lint, Find Bugs, Infer等,能找到广义上的编码bug,但是找不到functional error
本文认为,编码的主要困难是缺失test oracles, 进而缺乏编码者的详细功能描述。
已有解决方法:
- 使用已有的单元测试中的codified oracles
- 为特定app功能手动定义oracle
本文提出了independent view fuzzing的概念,面向off-the-shell Android Apps, 不需要人为提供任何额外的testing 或者oracles,也不限于测试具体的功能
挑战:
- 系统生成属性不变性测试变体 the system generation of app property preserving mutants
- 分析在种子测试执行期间的GUI pages和layouts来推测independent views
- 使用一个GUI transitional model来系统性地生成独立事件
- 识别属性被错误地改变了 the precise identification of property violations
- 将每个mutant test与对应的种子测试的GUI效果进行对比
- 本文认为,由于插入的事件是相互独立的,对应的种子测试的GUI效果应该在任何mutant test执行中保持不变
- the inserted events should add, but not remove GUI effects from the execution
具体实现:
- GUI transitional model
- infers independent views from random seed tests
- 1+2 generate property-preserving mutants and executes them
- 将变体与seed test做对比,报告潜在functional bugs
Illustrative Example
一般分析测试一个App需要四步:
- mining a GUI transitional model from this APP
- 生成一系列随机种子测试+执行每个种子测试来确认independent views
- 种子测试也能来自人工或者已经存在的其他工具
- 生成mutant test+执行
- 对比每个种子测试和其mutants来确认property violation,报告潜在bugs
Step 1:
由GUI transitonal model(GUI转移模型)可以画一个状态图,图中节点是一个GUI state,是根据结构相似性划分的。边则是标识一种用于转移的行为。
Q: 如果layout相同那么就算是同样的状态??不去管例如字体大小被异常更改,按钮被错误disable之类的错误?
Q2: 在后面这些状态有什么用?这些边又是怎么用的,用来推测如何回到当前状态?可是只有layout-或者说GUI tree是一致的?
Step 2:
生成一系列随机种子测试,在执行种子测试的时候,检查GUI layout,主要着重检查Group view(比如ListView或者RecyclerView)中的independent view(似乎就是inactive child view)。也因此一个尤其重要的信息是active view。
Q: 种子测试到底是如何生成的?例如启动之后看到一个界面这样?还是从A界面点击弹出图片这样?
Q2: 那种点击一个按钮后,其它按钮暂时不能点击直到完成编辑那种都测不了?也就是,只要对其他的siblings有任何微小扰动就测不了了?
Q3: 只是检测种子测试中的inactive view?种子测试本身不是还不完备么?
Step 3:
从seed test中挑一个pivot layout,一个inactive view,然后对这个inactive view操作,操作之后再使用transitional model将状态还原回原始状态。
Q: 令人懵逼,Expected和actual如何体现bug了?倒不如说作为用户看起来actual更好吧。
Step 4:
要求seed test中的元素要在mutant test中出现
Q: 如果我触发了删除功能??
符号定义
这里,经过一定程度的简化,两个layout相等被定义为集合中的view的类型和层级一致。
State coverage-optimized model mining
GENIE有两个选择事件e的策略:
-
依据评分:
该评分希望选择执行频率较少或者能够转移到具有较多new events的layout的事件e -
为每种e.type分配一个先验概率,然后按此概率随机选择
这两种策略是先依据评分,等到saturation,也即达到瓶颈之后,再用随机选择策略
Inferring Independent Views from Seed Tests
首先定义Independent from,若Group(wi)代表wi所对应的Group view,那么,若以下条件之一成立:
- Group(w1)≠Group(w2)
- Group(w1)=Group(w2)但w1和w2是sibling views而且w1.type = w2.type
就认为w1 independent from w2
Q: 如果是linearlayout,不能保证同类型兄弟无关?
接着定义active view:
如果事件e满足e.r(l) = wi且e被才执行了,那么wi就是Active状态,且\(h_l[Group(w_i)]=w_i\)。当然,当新的e.r(l)=wj在这一group view发生之后,wi就inactive且被替代了
Q: 整个group view也可以被inactive吧?
由于这样的定义,不属于任何group view的view就是永远inactive的。
此外,GENIE还会做execution traces上active关系的传递,具体方法是对于任意两个无关但都能执行事件e的layout l和l',若w1是l中e的recevier view,w2是l'中e的接收view,那么就认为w1与w2相似,把active关系过继
实际上这一策略执行时还要考虑更多:
- 程序试着把所有view都化成字符串,如果w1的字符串恰好匹配l'中的其他view w2,就认为w2是w1的similiar view
- Q: 图片的?
- 如果没能在1匹配上,那么就把w1和子节点的type info拿来找string edit distance最小的w2.
- Q: 没有限制允许的最大距离?分词么??为啥扁平化
- Q: 没有限制允许的最大距离?分词么??为啥扁平化
Mutant Test Generation and Execution
- 定义independent event trace
- 新的trace是在inactive view上工作
- Q: 难道不会访问本来是active,但是由于操作变为inactive?
- Q: 测试范围变小?
- 定义connect with, E1 can connect with E2 iff
- 存在E2中的第一个事件e2的receiver view,与E1的last layout中的receiver view相似
具体寻mutant算法
GUI-based Oracle Checking
Implementation
Seed Test Generation
- 利用events权重,做state coverage optimized mining
- 利用motif events-比如打开摄像之后,一般人们更多尝试摄像而不是点击cancel
Q: 其实我更多点cancel,因为摄像很容易误触发。。。
Mutant Generation and Execution
- breath-first random search
- 为了避免太多路径,最多2 self loop + 最多3 independent views
- 删除了transition model中的redundant events
- 一对状态中只保留一个event 通路?
Bug report reduction and Visualization
- bug report reduction
- 删除冗余的
- 是通过string比较 - 只保留出现一次的error
- 认为suspicious errors with less occurrences are more likely to be true errors
- bugs as deviant behaviour
- 删除冗余的
- web-based bug report visualization tool
Evaluation
集中在回答以下四个问题:
- 能否找到真实的functional bugs?
- 能增加code coverage吗?
- bug精确度
- 找到的functional bugs的类型?