Modeling bug report quality

Hooimeijer, Pieter; Weimer, Westley

doi:10.1145/1321631.1321639

Cited by 264 publications

(190 citation statements)

References 17 publications

Supporting

Mentioning

183

Contrasting

Unclassified

Order By: Relevance

“…analysis that required 30 days to operate [18]. The typical performance of our technique, which includes the cost of the 20% manual annotation burden and would take 1.3 h on average per release, is 0.0183-a 20% improvement over that figure.…”

Section: Resultsmentioning

confidence: 95%

Automating regression testing using web-based application similarities

Dobolyi

Soechting

Weimer

2010

Int J Softw Tools Technol Transfer

Self Cite

View full text Add to dashboard Cite

Web-based applications are one of the most widely used types of software, and have become the backbone of many e-commerce and communications businesses. These applications are often mission-critical for many organizations, motivating their precise validation. Although regression testing has been widely used to gain confidence in the reliability of software by providing information about the quality of an application, it has suffered limited use in this domain due to the frequent nature of updates to websites and the difficulty of automatically comparing test case output. We present techniques to address these challenges in regression testing web-based applications. Without precise comparators, test cases that fail due to benign program evolutions must be manually inspected. Our approach harnesses the inherent similarities between unrelated web-based applications to provide fully automated solutions to reduce the number of such false positives, while simultaneously returning true faults. By applying a model derived from regression testing other programs, our approach can predict which test cases merit human inspection. Our method is 2.5 to 50 times as accurate as current industrial practice, but requires no user annotations.

show abstract

Section: Resultsmentioning

confidence: 95%

Automating regression testing using web-based application similarities

Dobolyi

Soechting

Weimer

2010

Int J Softw Tools Technol Transfer

Self Cite

View full text Add to dashboard Cite

show abstract

“…In order to improve cooperation on a bug report between developers and users, many studies [10]- [14] have interviewed with OSS developers and users to understand the information needs for bug fixing. For example, through interviews with over 150 developers and 300 reporters of the Apache, Eclipse and Mozilla projects, Bettenburg et al [11] have found that steps to reproduce and stack traces are most useful in bug reports.…”

Section: How To Make a Good Bug Report?mentioning

confidence: 99%

“…Then we created two histograms: one is for the number of committed patches and another is for the number of changed status in bug reports. Then we used the median value in each histogram to define the threshold for categorizing into the four groups (14,15,22, and 23 committers in G1, G2, G3, and G4 respectively). We can consider committer's characteristics in each group as follows.…”

Section: Categorizing Each Committers Into Four Groups Depend-mentioning

confidence: 99%

Good or Bad Committers? —— A Case Study of Committer's Activities on the Eclipse's Bug Fixing Process

Jongyindee

Ohira

Ihara

et al. 2012

IEICE Trans. Inf. & Syst.

View full text Add to dashboard Cite

Anakorn JONGYINDEE †a) , Student Member, Masao OHIRA † †b) , Akinori IHARA † † †c) , and Ken-ichi MATSUMOTO † † †d) , Members SUMMARYThere are many roles to play in the bug fixing process in open source software development. A developer called "Committer", who has a permission to submit a patch into a software repository, plays a major role in this process and holds a key to the successfulness of the project. Despite the importance of committer's activities, we suspect that sometimes committers can make mistakes which have some consequences to the bug fixing process (e.g., reopened bugs after bug fixing). Our research focuses on studying the consequences of each committer's activities to this process. We collected each committer's historical data from the EclipsePlatform's bug tracking system and version control system and evaluated their activities using bug status in the bug tracking system and commit log in the version control system. Then we looked deeper into each committer's characteristics to see the reasons why some committers tend to make mistakes more than the others. IntroductionOpen Source Software (OSS) has been attracting a great deal of attention from a variety of areas as an alternative way of software use and development. As OSS has become more common and popular among us, however, OSS projects are facing with a big challenge on their quality assurance activities. Due to the growing user base, especially large OSS projects such as the Mozilla and Eclipse projects, they have receives a considerable amount of bug reports from the users on a daily basis [1] (e.g., several hundred bug reports are posted to the Bugzilla [2] database of the Mozilla project every day). OSS projects require finding an effective way of dealing with a large number of bug reports. In an OSS project, a bug is fixed through the bug fixing process [3] which starts from the process where the bug is reported in the project until patches for fixing the bug are submitted into a software repository. Each bug report in this process is passed through one or more developers who play different roles before it is closed.

show abstract

“…Conventional development relies heavily on regression testing and reproducible defect reports; a testcase demonstrating the vulnerability makes it more likely that the defect will be fixed [29,30]. We…”

Section: Motivating Examplementioning

confidence: 99%

“…Although the vulnerability is real, it may not be obvious to developers how an untrusted user can trigger it. For example, setting posted newsid to "' OR 1=1 ; DROP 'news' --" fails to trigger it, instead causing the program to exit on line 4.Conventional development relies heavily on regression testing and reproducible defect reports; a testcase demonstrating the vulnerability makes it more likely that the defect will be fixed [29,30]. We…”

mentioning

confidence: 99%

Decision Procedures for String Constraints

Hooimeijer¹

Self Cite

View full text Add to dashboard Cite

String-related defects are among the most prevalent and costly in modern software development. For example, in terms of frequency, cross-site scripting vulnerabilities have long surpassed traditional exploits like buffer overruns. The state of this problem is particularly disconcerting because it does not just affect legacy code: developing web applications today -even when adhering to best practices and using modern library support -remains error-prone.A number of program analysis approaches aim to prevent or mitigate string-related defects; examples include static bug detectors and automated testcase generators. Traditionally, this work has relied on built-in algorithms to reason about string-manipulating code. This arrangement is suboptimal for two reasons: first, it forces researchers to re-invent the wheel for each new analysis; and second, it does not encourage the independent improvement of domain-specific algorithms for handling strings.In this dissertation, we present research on specialized decision algorithms for string constraints.Our high-level approach is to provide a constraint solving interface; a client analysis can use that interface to reason about strings in the same way it might use a SAT solver to reason about binary state. To this end, we identify a set of string constraints that captures common programming language constructs, and permits efficient solving algorithms. We provide a core solving algorithm together with a machine-checkable proof of its correctness.Next, we focus on performance. We evaluate a variety of datastructures and algorithms in a controlled setting to inform our choice of each. Our final approach is based on two insights: (1) string constraints can be cast as an explicit search problem, and (2) to solve these constraints, we can i instantiate the search space lazily through incremental refinement. These insights lead to substantial performance gains relative to competing approaches; our experimental results show our prototype to be several of magnitude faster across several published benchmarks. iv Chapter 1 IntroductionThis dissertation focuses on a common source of software defects: string manipulation. Stringrelated defects are among the most prevalent and costly in modern software development. Reasoning about strings is a key aspect in many types of program analysis work, including static bug finding [1, 5, 6,7] and automated testing [8,9,10,11,12]. Until recently, this work has relied on ad hoc algorithms to formally reason about the values that string variables may take at runtime.That situation is suboptimal for two reasons: first, it forces researchers to re-invent the wheel for each new tool; and second, it does not encourage the independent improvement of domain-specific reasoning for strings.In this dissertation, we focus on the development of algorithms that enable formal reasoning about string operations; we refer to these algorithms as string decision procedures. Informally, a decision procedure is an algorithm that, given an input formula, answe...

show abstract

Modeling bug report quality

Cited by 264 publications

References 17 publications

Automating regression testing using web-based application similarities

Automating regression testing using web-based application similarities

Good or Bad Committers? —— A Case Study of Committer's Activities on the Eclipse's Bug Fixing Process

Decision Procedures for String Constraints

Contact Info

Product

Resources

About