Call graph construction in object-oriented languages

GroveDavid,; DeFouwGreg,; DeanJeffrey,; ChambersCraig,

doi:10.1145/263700.264352

Cited by 63 publications

(27 citation statements)

References 29 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…6 indicates that the execution of plug-in A needs to call plug-ins F and G, and the execution of plug-in G needs to call plug-in G. On the other hand, the execution of plug-in D calls plug-ins H and I, and the execution of plug-in H calls G. To illustrate the plug-in calling relation in a vivid manner, we propose to use plug-in calling graph which is motivated by the idea of call graph [30] in the programming area. More specifically, a plug-in calling graph is a directed graph that represents calling relationships between plug-ins.…”

Section: Plug-in Calling Behavior Discoverymentioning

confidence: 99%

A Two-Layered Framework for the Discovery of Software Behavior: A Case Study

Liu

Zhang

et al. 2018

IEICE Trans. Inf. & Syst.

View full text Add to dashboard Cite

SUMMARY During the execution of software, tremendous amounts of data can be recorded. By exploiting the execution data, one can discover behavioral models to describe the actual software execution. As a wellknown open-source process mining toolkit, ProM integrates quantities of process mining techniques and enjoys a variety of applications in a broad range of areas. How to develop a better ProM software, both from user experience and software performance perspective, are of vital importance. To achieve this goal, we need to investigate the real execution behavior of ProM which can provide useful insights on its usage and how it responds to user operations. This paper aims to propose an effective approach to solve this problem. To this end, we first instrument existing ProM framework to capture execution logs without changing its architecture. Then a twolayered framework is introduced to support accurate ProM behavior discovery by characterizing both user interaction behavior and plug-in calling behavior separately. Next, detailed discovery techniques to obtain user interaction behavior model and plug-in calling behavior model are proposed. All proposed approaches have been implemented. key words: software behavior discovery, user behavior, plug-in calling behavior, process mining

show abstract

Section: Plug-in Calling Behavior Discoverymentioning

confidence: 99%

A Two-Layered Framework for the Discovery of Software Behavior: A Case Study

Liu

Zhang

et al. 2018

IEICE Trans. Inf. & Syst.

View full text Add to dashboard Cite

show abstract

“…In activity generate test case call graphs, a dynamic call graph is generated for each test case in the suite, recovering its hierarchy of method calls.…”

Section: The Refactoring‐based Approachmentioning

confidence: 99%

Prioritizing test cases for early detection of refactoring faults

Alves

Machado

Massoni

et al. 2016

Software Testing Verif & Rel

View full text Add to dashboard Cite

Refactoring edits are error-prone, requiring cost-effective testing. Regression test suites are often used as a safety net for decreasing the chances of behavioural changes. Because of the high costs related to handling massive test suites, prioritization techniques can be applied to reorder test case execution, fostering early fault detection. However, traditional prioritization techniques are not specifically designed for detecting refactoring-related faults. This article proposes refactoring-based approach (RBA), a refactoringaware strategy for prioritizing regression test cases. RBA reorders an existing test sequence, using a set of proposed refactoring fault models that define the refactoring's impact on program methods.Refactoring-based approach's evaluation shows that it promotes early detection of refactoring faults and outperforms well-known prioritization techniques in 71% of the cases.Moreover, it prioritizes fault-revealing test cases close to one another in 73% of the cases, which can be useful for fault localization. Those findings show that RBA can considerably improve prioritization of test cases during perfective evolution, both by increasing fault-detection rates as well as by helping to pinpoint defects introduced by an incorrect refactoring. of refactorings and software bugs [13,14]. In addition, 77% of the participants from the survey of Kim et al. with Microsoft developers [4] confirm that refactoring may induce the introduction of subtle bugs and functionality regression.A number of strategies are designed to prevent behavioural changes when refactoring: (i) refactoring mechanics, proposed by Fowler [1], guide the application of refactoring with the combination of micro changes and compilation/test checks; (ii) the formal specification of refactoring edits, founded by theories of object-oriented programming [15][16][17]; (iii) refactoring engines, automate the application of refactoring edits by checking pre-conditions (e.g. Eclipse ‡ , NetBeans § , JRRT ¶ ); and (iv) regression testing, test suites are used to increase confidence on behaviour preservation after refactoring [18].From those options, regression testing is probably the most popular alternative. However, as a system evolves, its regression test suite tends to increase, because new test cases can be added to check new functionalities [19,20]. Thus, it may be impractical to rerun regression suites after each refactoring when working with a large test suite-it can take a long time for the first test case to fail as well as it may be difficult and costly to gather enough information on test cases that fail so that fault localization can begin. In such context, there is a need for techniques that preserve test effectiveness, with as few test cases as possible. Test case prioritization [21] rearranges a test suite aiming to improve achievement of certain testing goals (e.g. the rate of fault detection). Several prioritization techniques have been proposed [22][23][24][25][26][27][28]; most consider code coverage as prioritization cr...

show abstract

“…Shivers' work uses a call graph as the internal representation of choice during static analysis. The call graph of a program is a directed graph that represents the relationships between the program's procedures or methods [6]. According to the method being analysed in the call graph, the calling relationships between that method and the methods that call it can span over several depths.…”

Section: Static Analysismentioning

confidence: 99%

Using control flow analysis to improve the effectiveness of incremental mutation testing

Bajada

Micallef

Colombo

2015

Proceedings of the 14th International Workshop on Principles of Software Evolution

View full text Add to dashboard Cite

Incremental Mutation Testing attempts to make mutation testing less expensive by applying it incrementally to a system as it evolves. This approach fits current trends of iterative software development with the main idea being that by carrying out mutation analysis in frequent bite-sized chunks focused on areas of the code which have changed, one can build confidence in the adequacy of a test suite incrementally. Yet this depends on how precisely one can characterise the effects of a change to a program. The original technique uses a naïve approach whereby changes are characterised only by syntactic changes. In this paper we propose bolstering incremental mutation testing by using control flow analysis to identify semantic repercussions which a syntactic change will have on a system. Our initial results based on two case studies demonstrate that numerous relevant mutants which would have otherwise not been considered using the naïve approach, are now being generated. However, the cost of identifying these mutants is significant when compared to the naïve approach, although it remains advantageous when compared to traditional mutation testing so long as the increment is sufficiently small.

show abstract

Call graph construction in object-oriented languages

Cited by 63 publications

References 29 publications

A Two-Layered Framework for the Discovery of Software Behavior: A Case Study

A Two-Layered Framework for the Discovery of Software Behavior: A Case Study

Prioritizing test cases for early detection of refactoring faults

Using control flow analysis to improve the effectiveness of incremental mutation testing

Contact Info

Product

Resources

About