Interface Mutation: an approach for integration testing

Delamaro, Márcio Eduardo; Maidonado, J.C.; Mathur, Aditya P.

doi:10.1109/32.910859

Cited by 205 publications

(163 citation statements)

References 16 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Starting with a DG as the underlying model, the elementary operators are applied to other models, such as ESG, FSM, and SC in the same manner. This is also a major difference between this paper and other studies, such as [7][8][9][10][11][12][13][14][15][16]. Many mutation operators known from literature can be reduced to these two elementary operators and their combinations and iterations.…”

Section: Introductionmentioning

confidence: 82%

“…Typically, test case generation results only in a few test cases for each mutant -in best case even only one. For details, refer to [7,12]. Average time spent to execute test cases manually for each mutant is 3.11 minutes for RJB, whereas it took 4.75 minutes in average for RSM13.…”

Section: Fault Id Description Of the Fault Operatormentioning

confidence: 99%

“…Code-based mutation operators are the operators developed for testing a function or a unit of procedural programs, such as the 22 operators used by Mothra [29] for Fortran programs and the 77 operators used by Proteum [5,43] for C programs. Interface mutation operators include operators such as those used by Proteum/IM [7] that apply mutation testing at the integration-level. Test cases generated to kill these mutants provide a good indication of how well the interactions between different modules of an application have been tested.…”

Section: Code-based Mutation Testingmentioning

confidence: 99%

“…Some are applied to source code of the SUC while others are applied to models derived from specifications. Mutants generated can be used at the unit testing [5,6], as well as at the integration testing level [7] (further details on related work are given in Section 6). A common problem of these studies is that they use a large number of mutation operators to generate mutants because they empirically determine the mutation operators based on selected fault models.…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Model-based mutation testing—Approach and case studies

Belli

Budnik

Hollmann³

et al. 2016

Science of Computer Programming

View full text Add to dashboard Cite

This paper rigorously introduces the concept of model-based mutation testing (MBMT) and positions it in the landscape of mutation testing. Two elementary mutation operators, insertion and omission, are exemplarily applied to a hierarchy of graph-based models of increasing expressive power including directed graphs, event sequence graphs, finite-state machines and statecharts. Test cases generated based on the mutated models (mutants) are used to determine not only whether each mutant can be killed but also whether there are any faults in the corresponding system under consideration (SUC) developed based on the original model. Novelties of our approach are: (1) evaluation of the fault detection capability (in terms of revealing faults in the SUC) of test sets generated based on the mutated models, and (2) superseding of the great variety of existing mutation operators by iterations and combinations of the two proposed elementary operators. Three case studies were conducted on industrial and commercial real-life systems to demonstrate the feasibility of using the proposed MBMT approach in detecting faults in SUC, and to analyze its characteristic features. Our experimental data suggest that test sets generated based on the mutated models created by insertion operators are more effective in revealing faults in SUC than those generated by omission operators. Worth noting is that test sets following the MBMT approach were able to detect faults in the systems that were tested by manufacturers and independent testing organizations before they were released.

show abstract

Section: Introductionmentioning

confidence: 82%

Section: Fault Id Description Of the Fault Operatormentioning

confidence: 99%

Section: Code-based Mutation Testingmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Model-based mutation testing—Approach and case studies

Belli

Budnik

Hollmann³

et al. 2016

Science of Computer Programming

View full text Add to dashboard Cite

show abstract

“…Fault-based techniques inject faults to the program to produce program mutants [42,109]. Data-flow techniques check data-flow or synchronization anomalies [21,89,31,49,48,32].…”

Section: Other Techniquesmentioning

confidence: 99%

Towards a new extension relation for compositional test case generation for CSP concurrent processes

Chan¹,

陳榮光.²

View full text Add to dashboard Cite

Software concurrent systems such as electronic financial services are very popular today. Rigorous testing of such systems is indispensable. Nevertheless, the state-explosion problem, in which the size of a system grows exponentially with the number of concurrent components, is a severe obstacle to the generation of test cases.In this study, we propose a new relationship assuring the conformities of test cases for concurrent systems. We stipulate it in Communicating Sequential Processes (CSP), which is an excellent tool to study concurrent systems. Specification of concurrent systems is expressed as processes that are composed sequentially and concurrently. Our proposal supports both abstraction and process composition.This approach decomposes a given process into sequential compositions of component processes. Each component can be anti-extended into abstract forms. Sequential and concurrent combinations of abstract forms can substitute their corresponding extending components in a process to form aggregated abstract forms. Since the given processes, components and abstract forms are all processes, this approach can be applied recursively and compositionally. We prove that these aggregated abstract processes should be anti-extensions of the corresponding processes under a few necessary and sufficient conditions. Hence, test cases generated from these processes will be conformance test cases for the implementations.We examine three major testing relations (conformance, extension and reduction) from the point of view of their ability to support abstraction. Extension and reduction are special kinds of conformance, which are partially ordered. However, only extension from a specification can provide abstract forms that guarantee to be conformed by an implementation of the specification. Extension is further investigated to support the compositional approach. We identify five weaknesses of extension, which we call problems of preceding, succeeding, prefix, decomposition and paralleling. Each will result in non-conforming abstraction.To resolve the identified weaknesses of extension in a compositional and abstractionoriented approach, we formulate σ-extension and identify the necessary and sufficient conditions. We also discuss a restricted sub-class of process specification so that these conditions can easily be satisfied. In the restricted sub-class, successful terminations of processes are deterministic.Under these conditions, we achieve a few desirable properties. First, both preceding and succeeding components of a given sequential composition can be anti-extended. The given composition should extend the sequential composition of its corresponding anti-extended processes. Secondly, a given parallel composition whose concurrent components are sequential compositions should extend a parallel composition of anti-extensions of preceding components of corresponding sequential compositions, followed by a parallel composition of anti-extensions of corresponding succeeding components. Furthermore, a given sequential co...

show abstract

A runtime fault survival method for deployed software during production runs

Seo

Park

Choi

2016

J. Softw. Evol. and Proc.

View full text Add to dashboard Cite

Runtime memory faults during production run should be more thoroughly addressed because they severely affect system availability. This paper proposes a method for mitigating memory faults during production runs of deployed software, thereby ensuring normal system operation until patches to fix the faults are delivered. Furthermore, the method helps enhance debugging efficiency by providing accurate on‐site fault information used by developers to release timely patches. The core of the method is to offer information tagging to identify runtime faults and a fault survival algorithm to provide differentiated fault mitigation according to the runtime state. We implemented ROPHE on a Linux 2.6 platform and conducted an empirical study of representative Linux applications. The results show that the average fault‐handling rate among the applications is 35.75%, whereas the RemOte runtime Protection for High‐risk Error (ROPHE) greatly improves capacity to an average of 91.94%. Specifically, the fault‐handling rates of the applications ranged widely from 7.32% to 62.96%, while ROPHE provided fault‐survival rates in the relatively narrow range of 82.35–97.44%. The experimental results show that the proposed method guarantees the same level of reliability for all applications regardless of their individual fault handling capacity. Copyright © 2016 John Wiley & Sons, Ltd.

show abstract

Interface Mutation: an approach for integration testing

Cited by 205 publications

References 16 publications

Model-based mutation testing—Approach and case studies

Model-based mutation testing—Approach and case studies

Towards a new extension relation for compositional test case generation for CSP concurrent processes

A runtime fault survival method for deployed software during production runs

Contact Info

Product

Resources

About