Available soon...

Available soon...

Mutation testing has been used to assess the quality of test case suites by analyzing the ability in distinguishing the artifact under testing from a set of alternative artifacts, the so-called mutants. The mutants are generated from the artifact under testing by applying a set of mutant operators, which produce artifacts with simple syntactical differences. The mutant operators are usually based on typical errors that occur during the software development and can be related to a fault model. In this paper, we propose a language—named View the MathML source (MUtant DEfinition Language)—for the definition of mutant operators, aiming not only at automating the mutant generation, but also at providing precision and formality to the operator definition. The proposed language is based on concepts from transformational and logical programming paradigms, as well as from context-free grammar theory. Denotational semantics formal framework is employed to define the semantics of the View the MathML source language. We also describe a system—named mudelgen—developed to support the use of this language. An executable representation of the denotational semantics of the language is used to check the correctness of the implementation of mudelgen. At the very end, a mutant generator module is produced, which can be incorporated into a specific mutant tool/environment.

A new model based approach for automated generation of test cases in object oriented systems has been presented. The test cases are derived by analyzing the dynamic behavior of the objects due to internal and external stimuli. The scope of the paper has been limited to the object diagrams taken from the Unified Modeling Language model of the system. Genetic Algorithm’s tree crossover has been proposed to bring out all possible test cases of a given object diagram. Illustrative case study has been presented to establish the effectiveness of our methodology coupled with mutation analysis

In recent years many methods and tools for software clone detection have been proposed. While some work has been done on assessing and comparing performance of these tools, very little empirical evaluation has been done. In particular, accuracy measures such as precision and recall have only been roughly estimated, due both to problems in creating a validated clone benchmark against which toolscan be compared, and to the manual effort required to hand check large numbers of candidate clones. In this paper we propose an automated method for empirically evaluating clone detection tools that leverages mutation-based techniques to overcome these limitations by automatically synthesizing large numbers of known clones based on an editing theory of clone creation. Our framework is effective in measuring recall and precision of clone detection tools for various types of fine-grained clones in real systems without manual intervention.

To increase the confidence in the correctness of specified policies, policy developers can conduct policy testing by supplying typical test inputs (request) and subsequently checking test output (responses) against expected ones to enhance the correctness of specified policies. Testing of Access Control Policies along with the Application program is not a worthful practice. Unlike Software Testing we have the tools and technique for Access Control Policy Testing.Unfortunately, manual testing is tedious and time consuming job. We designed a model called ACPC (Access Control Policy Checker) which include mutation operators for comparing the original policy response with the response of mutant policy and check the correctness of the original policy. The ACPC includes two sections in first section we generate the requests set automatically which is previously not available and in second section we perform testing. This model uses the policy written in XACML (eXtensible Access Control Markup Language) [1] which is the standard language for writing Access Control Policies. We have used a tool called Margrave [8] for Change Impact Analysis and other programming languages like Java and C++ for building different module.

Mutation testing measures the adequacy of a test suite by seeding artificial defects (mutations) into a program. If a mutation is not detected by the test suite, this usually means that the test suite is not adequate. However, it may also be that the mutant keeps the program's semantics unchanged–-and thus cannot be detected by any test. Such equivalent mutants have to be eliminated manually, which is tedious. We assess the impact of mutations by checking dynamic invariants. In an evaluation of our Javalanche framework on seven industrial-size programs, we found that mutations that violate invariants are significantly more likely to be detectable by a test suite. As a consequence, mutations with impact on invariants should be focused upon when improving test suites. With less than 3% of equivalent mutants, our approach provides an efficient, precise, and fully automatic measure of the adequacy of a test suite.

Mutation testing measures the adequacy of a test suite by seeding artificial defects (mutations) into a program. If a mutation is not detected by the test suite, this usually means that the test suite is not adequate. However, it may also be that the mutant keeps the program's semantics unchanged–-and thus cannot be detected by any test. Such equivalent mutants have to be eliminated manually, which is tedious. We assess the impact of mutations by checking dynamic invariants. In an evaluation of our Javalanche framework on seven industrial-size programs, we found that mutations that violate invariants are significantly more likely to be detectable by a test suite. As a consequence, mutations with impact on invariants should be focused upon when improving test suites. With less than 3% of equivalent mutants, our approach provides an efficient, precise, and fully automatic measure of the adequacy of a test suite.

To assess the quality of a test suite, one can use mutation testing - seeding artificial defects (mutations) into the program and checking whether the test suite finds them. Javalanche is an open source framework for mutation testing Java programs with a special focus on automation, efficiency, and effectiveness. In particular, Javalanche assesses the impact of individual mutations to effectively weed out equivalent mutants; it has been demonstrated to work on programs with up to 100,000 lines of code.

Vulnerabilities in applications and their widespread exploitation through successful attacks are common these days. Testing applications for preventing vulnerabilities is an important step to address this issue. In recent years, a number of security testing approaches have been proposed. However, there is no comparative study of these work that might help security practitioners select an appropriate approach for their needs. Moreover, there is no comparison with respect to automation capabilities of these approaches. In this work, we identify seven criteria to analyze program security testing work. These are vulnerability coverage, source of test cases, test generation method, level of testing, granularity of test cases, testing automation, and target applications. We compare and contrast prominent security testing approaches available in the literature based on these criteria. In particular, we focus on work that address four most common but dangerous vulnerabilities namely buffer overflow, SQL injection, format string bug, and cross site scripting. Moreover, we investigate automation features available in these work across a security testing process. We believe that our findings will provide practical information for security practitioners in choosing the most appropriate tools.

Available soon...

Mutation testing has traditionally been used as a defect injection technique to assess the effectiveness of a test suite as represented by a "mutation score." Recently, mutation testing tools have become more efficient, and industrial usage of mutation analysis is experiencing growth. Mutation analysis entails adding or modifying test cases until the test suite is sufficient to detect as many mutants as possible and the mutation score is satisfactory. The augmented test suite resulting from mutation analysis may reveal latent faults and provides a stronger test suite to detect future errors which might be injected. Software engineers often look for guidance on how to augment their test suite using information provided by line and/or branch coverage tools. As the use of mutation analysis grows, software engineers will want to know how the emerging technique compares with and/or complements coverage analysis for guiding the augmentation of an automated test suite. Additionally, software engineers can benefit from an enhanced understanding of efficient mutation analysis techniques. To address these needs for additional information about mutation analysis, we conducted an empirical study of the use of mutation analysis on two open source projects. Our results indicate that a focused effort on increasing mutation score leads to a corresponding increase in line and branch coverage to the point that line coverage, branch coverage and mutation score reach a maximum but leave some types of code structures uncovered. Mutation analysis guides the creation of additional "common programmer error" tests beyond those written to increase line and branch coverage. We also found that 74% of our chosen set of mutation operators is useful, on average, for producing new tests. The remaining 26% of mutation operators did not produce new test cases because their mutants were immediately detected by the initial test suite, indirectly detected by test suites we added to detect other mutants, or were not able to be detected by any test.

Available soon...

Available soon...

Logic criteria are used in software testing to find inputs that guarantee detecting certain faults. Thus, satisfying a logic criterion guarantees killing certain mutants. Some logic criteria are composed of other criteria. Determining component criterion feasibility can be used as a means to reduce test set size without sacrificing fault detection. This paper introduces a new logic criterion based on component criterion feasibility. Given a predicate in minimal DNF, a determination is made of which component criteria are feasible for individual literals and terms. This in turn provides determination of which criteria are necessary to detect double faults and kill second-order mutants. A test set satisfying this new criterion guarantees detecting the same double faults as a larger test set satisfying another criterion. An empirical study using predicates in avionics software showed that tests sets satisfying the new criterion detected all but one double fault type. For this one double fault type, 99.91% of the double faults were detected and combining equivalent single faults nearly always yielded an equivalent double fault.

Database application programs are ubiquitous, so good techniques for testing them are needed. Recently, several research groups have proposed new approaches to generating tests for database applications and for assessing test data adequacy. This paper describes a mutation testing tool, JDAMA (Java Database Application Mutation Analyzer), for Java programs that interact with a database via the JDBC interface. Our approach extends the mutation testing approach for SQL by Tuya et al, by integrating it with analysis and instrumentation of the application bytecode. JDAMA's use is illustrated through a small study which uses mutation scores to compare two test generation techniques for database applications.

Mutation testing is a technique for generating high quality test data. However, logic mutation testing is currently inefficient for three reasons. One, the same mutant is generated more than once. Two, mutants are generated that are guaranteed to be killed by a test that kills some other generated mutant. Three, mutants that when killed are guaranteed to kill many other mutants are not generated as valuable mutation operators are missing. This paper improves logic mutation testing by 1) extending a logic fault hierarchy to include existing logic mutation operators, 2) introducing new logic mutation operators based on existing faults in the hierarchy, 3) introducing new logic mutation operators having no corresponding faults in the hierarchy and extending the hierarchy to include them, and 4) addressing the precise effects of equivalent mutants on the fault hierarchy. An empirical study using minimal DNF predicates in avionics software showed that a new logic mutation testing approach generates fewer mutants, detects more faults, and outperforms an existing logic criterion.

Agile development methods have gained momentum inthe last few years and, as a consequence, test-driven developmenthas become more prevalent in practice. However, test cases arenot sufficient for producing dependable software and we ratheradvocate approaches that emphasize the use of assertions orcontracts over that of test cases. Yet, writing self-checks in codehas been shown to be difficult and is itself prone to errors. Astandard technique to specify runtime properties is design-bycontract(DbC). But how can one test if the contracts themselvesare sensible and sufficient? We propose a measure to quantifythe goodness of contracts (or assertions in a broader sense). Weintroduce meta-mutations at the source code level to simulatecommon programmer errors that the self-checks are supposedto detect. We then use random mutation testing to determinea lower and upper bound on the detectable mutations andcompare these bounds with the number of mutants detected bythe contracts. Contracts are considered “good” if they detect acertain percentage of the detectable mutations.We have evaluatedour tools on Java classes with contracts specified using theJava Modeling Language (JML). We have additionally tested thecontract quality of 19 implementations, written independently bystudents, based on the same specification.

Available soon...

Available soon...