Abstract
SummarySearch‐based crash reproduction approaches assist developers during debugging by generating a test case, which reproduces a crash given its stack trace. One of the fundamental steps of this approach is creating objects needed to trigger the crash. One way to overcome this limitation is seeding: using information about the application during the search process. With seeding, the existing usages of classes can be used in the search process to produce realistic sequences of method calls, which create the required objects. In this study, we introduce behavioural model seeding: a new seeding method that learns class usages from both the system under test and existing test cases. Learned usages are then synthesized in a behavioural model (state machine). Then, this model serves to guide the evolutionary process. To assess behavioural model seeding, we evaluate it against test seeding (the state‐of‐the‐art technique for seeding realistic objects) and no seeding (without seeding any class usage). For this evaluation, we use a benchmark of 122 hard‐to‐reproduce crashes stemming from six open‐source projects. Our results indicate that behavioural model seeding outperforms both test seeding and no seeding by a minimum of 6% without any notable negative impact on efficiency.
Highlights
The starting point of any debugging activity is to try to reproduce the problem reported by a user in the development environment [1, 2]
We focused our manual analysis on the crash reproduction executions for which the search in one seeding configuration has a significant impact on (i) initializing the initial population, (ii) crash reproduction or (iii) search process efficiency compared with no seeding
We evaluate the relevance of using both test and behavioural model seeding to improve crash reproduction achieved by such techniques
Summary
The starting point of any debugging activity is to try to reproduce the problem reported by a user in the development environment [1, 2]. Manual crash reproduction can be a challenging and labour-intensive task for developers: it is often an iterative process that requires setting the debugging environment in a similar enough state as the environment in which the crash occurred [1]. Depending on the amount of information reported from the operation environment, this debugging process may take more or less time. Previous studies [3, 13] show that such test cases are helpful for the developers to debug the application. For Java programs, the information reported from the operations environment ideally includes a stack trace. Listing 1 presents a stack trace coming from the crash XWIKI-13372.¶ The stack trace indicates the exception thrown (NullPointerException here) and the frames, that is, the stack of method calls at the time of the crash, indexed from 1 (at line 1) to 26 (not shown here)
Sign-in/Register to view highlights & summary Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
