软件工程顶会论文中的自动修复工具——XFix [ISSTA 2017]
Preface
Today I am going to use English because I nearly have no chance to speak or write English in the daily life, though English is fairly important…
So just take a try this time.
Automated program repair tools: XFix [ISSTA 2017]
1.1 Basic Info
The name of the paper: “XFix: An Automated Tool for the Repair of Layout Cross Browser Issues”
The authors: Sonal Mahajan; Abdulmajeed Alameer; Phil McMinn; William G. J. Halfond
I have already read an article of Sonal Mahajan before… It seems that that paper is derived from this short paper of ISSTA 17.
1.2 What is the abstract talking about?
1) Current situation: Differences in the rendering of a website across different browsers can cause inconsistencies in its appearance and usability, resulting in Layout Cross Browser Issues (XBIs).
- There are XBIs that impose huge threat to the quality of a website.
2) Such XBIs can negatively impact the functionality of a website as well as users’ impressions of its trustworthiness and reliability.
Existing techniques can only detect XBIs, and therefore require developers to manually perform the labor intensive task of repair.
- Harm of XBIs + existing techniques can only detect XBIs but fail to repair them.
3) In this demo paper we introduce
our tool, XFix, that automatically repairs layout XBIs in web applications. To the best of our knowledge, XFix is the frst automated
technique for generating XBI repairs.
- The first tool to generate XBI repair.
1.3 about the introduction
1) Layout XBIs are by far the most prevalent type of XBIs, observed
in over 56% of the websites [10]
[10] Shauvik Roy Choudhary, Mukul R. Prasad, and Alessandro Orso. 2013. X-PERT:
Accurate Identifcation of Cross-browser Issues in Web Applications. In Proceedings of the International Conference on Software Engineering (ICSE).
- Quote the 2013 ICSE paper to illustrate that “Layout XBIs are the most prevalent type of XBIs.
2) To address these limitations, we proposed a novel automated technique [4] to repair layout XBIs in web applications. It uses search-based techniques to identify repair solutions.
One thing is that “it uses search-based techniques …” is not clear for me.
3) Our key insight is that the amount of layout deviation given by the position and size of HTML elements of a web page rendered in different browsers can be used as a ftness function to guide the exploration to likely solutions. When the amount of layout deviation converges to zero,
the layout of a web page renders consistently in two different
browsers, and a fault has likely been identifed and repaired.
The fitness function is found.
1.4 So my interest lies in “what is the operator during the repair”
1.5 the website of the open-source repair tool XFix
https://github.com/sonalmahajan/xfx
1.6 How does the author get such an idea?
1) you need to be very familiar with this field of web, web repair, web testing and debugging;
2) also, you are supposed to master the corresponding techniques concerning web;
3) You should read many papers. This idea is about search-based strategy, which does not relate to complicated semantics-based method such as symbolic execution.
So maybe the idea is not complex, but it really solves the real-world problem and contributes to the web reparing community. That is the point.
1.7 Techniques used in the process of XFix repair
1) Stage 1: initial XBI dectection.
XFix uses Selenium WebDriver to open R and T and render the
PUT in them, and then capture Document Object Model (DOM)
information including XPath, location, and size of the elements.
XFix then invokes X-PERT [10] by passing the two DOMs as input
to obtain a set, X , of detected XBIs. X-PERT reports each XBI as the tuple ⟨label, ⟨e1, e2⟩⟩, where ⟨e1, e2⟩ is a pair of HTML elements
in the PUT that is inconsistent in layout in T with respect to R,
and label describes the layout problem.
Note that we used the publicly available version of X-PERT
(https://github.com/gatech/xpert) by making minor changes to fx
bugs and add accessor methods for data structures. Due to space
reasons, we describe the details of our changes to X-PERT on the
XFix project page (https://github.com/sonalmahajan/xfix).
2) Stage 2: Extract Root Causes. In this stage, XFix extracts the
root causes for each XBI detected in stage 1. A root cause is defned
by the tuple ⟨e, p,v⟩, where e is an HTML element in the PUT, p is
a CSS property of e, and v is the value of p.
3) Stage 3: Search for Candidate Fixes. In this stage, XFix performs a guided search over each of the root cause tuples populated
in stage 2 to fnd individual candidate fxes.
To do this, we implemented a search to be used in a single variable mode inspired by the
variable search component of the Alternating Variable Method (AVM)
technique [2].
[2] Joseph Kempka, Phil McMinn, and Dirk Sudholt. 2015. Design and Analysis of
Different Alternating Variable Searches for Search-Based Software Testing. In
Theor. Comput. Sci., Vol. 605. 1–20.
1.8 about the fault localization & statement selection
A CSS-label map suggests the root cause tuples.
And during the repair, AVM is used mostly like a hill climbing search, but is comparatively fast.
XFix uses the AVM in a single variable mode by resetting the PUT to its original form before running the search on a root cause tuple to fnd a potential fx value, v′. For each root cause processed, XFix reports a candidate fx tuple ⟨e, p,v,v′⟩
But for me, it still remains a problem that whether the XFix repair statement/element from the top to bottom, or just randomly.