Results 1 - 10 of 16

Improving Test Suites via Operational Abstraction

by Michael Harder, Jeff Mellen, Michael D. Ernst - In Proceedings of the 25th International Conference on Software Engineering , 2003
"... This paper presents the operational difference technique for generating, augmenting, and minimizing test suites. The technique is analogous to structural code coverage techniques, but it operates in the semantic domain of program properties rather than the syntactic domain of program text. The opera ..."
Abstract - Cited by 103 (12 self) - Add to MetaCart
This paper presents the operational difference technique for generating, augmenting, and minimizing test suites. The technique is analogous to structural code coverage techniques, but it operates in the semantic domain of program properties rather than the syntactic domain of program text. The operational difference technique automatically selects test cases; it assumes only the existence of a source of test cases. The technique dynamically generates operational abstractions (which describe observed behavior and are syntactically identical to formal specifications) from test suite executions. Test suites can be generated by adding cases until the operational abstraction stops changing. The resulting test suites are as small, and detect as many faults, as suites with 100% branch coverage, and are better at detecting certain common faults.
(Show Context)

Predicting problems caused by component upgrades

by Stephen Mccamant, Michael D. Ernst - In ESEC/FSE , 2003
"... This report presents a new, automatic technique to assess whether replacing a component of a software system by a purportedly compatible component may change the behavior of the system. The technique operates before integrating the new component into the system or running system tests, permitting qu ..."
Abstract - Cited by 52 (6 self) - Add to MetaCart
This report presents a new, automatic technique to assess whether replacing a component of a software system by a purportedly compatible component may change the behavior of the system. The technique operates before integrating the new component into the system or running system tests, permitting quicker and cheaper identification of problems. It takes into account the system’s use of the component, because a particular component upgrade may be desirable in one context but undesirable in another. No formal specifications are required, permitting detection of problems due either to errors in the component or to errors in the system. Both external and internal behaviors can be compared, enabling detection of problems that are not immediately reflected in the output. The technique generates an operational abstraction for the old component in the context of the system, and one for the new component in the context of its test suite. An operational abstraction is a set of program properties that generalizes over observed run-time behavior. Modeling a system as divided into modules, and taking into account the control and data flow between the modules, we formulate a logical condition to guarantee that the system’s behavior is preserved across a component replacement. If automated logical comparison indicates that the new component does not make all the guarantees that the old one did, then
(Show Context)

On The Testability of SDL Specifications

by R. M. Hierons, T. -h. Kim, H. Ural - Computer Networks , 2003
"... The problem of testing from an SDL specification is often complicated by the presence of infeasible paths. This paper introduces an approach for transforming a class of SDL specification in order to eliminate or reduce the infeasible path problem. This approach is divided into two phases in order to ..."
Abstract - Cited by 10 (6 self) - Add to MetaCart
The problem of testing from an SDL specification is often complicated by the presence of infeasible paths. This paper introduces an approach for transforming a class of SDL specification in order to eliminate or reduce the infeasible path problem. This approach is divided into two phases in order to aid generality. First the SDL specification is rewritten to create a normal form extended finite state machine (NF-EFSM). This NF-EFSM is then expanded in order to produce a state machine in which the test criterion may be satisfied using paths that are known to be feasible. The expansion process is guaranteed to terminate. Where the expansion process may lead to an excessively large state machine, this process may be terminated early and feasible paths added. The approach is illustrated through being applied to the Initiator process of the Inres protocol. Key words: SDL, test generation, extended finite state machine, infeasible path problem. 1
(Show Context)

A Comparison of the BTT and TTF Test-Generation Methods

by Bruno Legeard, Fabien Peureux, Mark Utting , 2002
"... This paper compares two methods of generating tests from formal specifications. The Test Template Framework (TTF) method is a framework and set of heuristics for manually generating test sets from a Z specification. The B Testing Tools (BTT) method uses constraint logic programming techniques to gen ..."
Abstract - Cited by 6 (0 self) - Add to MetaCart
This paper compares two methods of generating tests from formal specifications. The Test Template Framework (TTF) method is a framework and set of heuristics for manually generating test sets from a Z specification. The B Testing Tools (BTT) method uses constraint logic programming techniques to generate test sequences from a B specification.

Combining algebraic and model-based test case generation

by Li Dan, Bernhard K. Aichernig - In Proceedings of First International Colloquium on Theoretical Aspects of Computing
"... Abstract. The classical work on test case generation and formal methods focuses either on algebraic or model-based specifications. In this paper we propose an approach to derive test cases in the RAISE method whose specification language RSL combines the model-based and algebraic style. Our approach ..."
Abstract - Cited by 5 (1 self) - Add to MetaCart
Abstract. The classical work on test case generation and formal methods focuses either on algebraic or model-based specifications. In this paper we propose an approach to derive test cases in the RAISE method whose specification language RSL combines the model-based and algebraic style. Our approach integrates the testing techniques of algebraic specifications and model-based specifications. In this testing strategy, first, every function definition is partitioned by Disjunctive Normal Form (DNF) rewriting and then test arguments are generated. Next, sequences of function calls are formed. Finally, the test cases are built by replacing the variables, on both sides of the axioms, with the sequences of functions calls. These kinds of test cases not only provide the data for testing, but also serve as test oracles. Based on this combined approach, a test case generation tool has been developed.
(Show Context)

Towards Automated Unit Testing of Statechart Implementations

by Simon Burton , 1999
"... This report describes an automated method of unit test design based on requirements specified in a subset of the statechart notation. The behaviour under test is first extracted from the requirements and specified in the Z notation. Existing methods and tools are then applied to this specification t ..."
Abstract - Cited by 5 (0 self) - Add to MetaCart
This report describes an automated method of unit test design based on requirements specified in a subset of the statechart notation. The behaviour under test is first extracted from the requirements and specified in the Z notation. Existing methods and tools are then applied to this specification to derive the tests. Using Z to model the requirements and specify the tests allows for a deductive approach to verifying test satisfiability, test result correctness and certain properties of the requirements. An examination of the specification coverage achieved by the tests is provided and the report concludes with an evaluation of the work to date and a set of directions for future work. Contents 1 Introduction 3 2 A subset of statecharts 4 2.1 States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Statechart computations . . . . . . . . . . . . . . . . . . . . ....
(Show Context)

Improving Test Suites via Generated Specifications

by Michael Harder , 2002
"... This thesis presents a specification-based technique for generating, augmenting, and minimizing test suites. The technique is automatic but assumes the existence of a test case generator. The technique dynamically induces specifications from test suite executions. Test suites can be generated by add ..."
Abstract - Cited by 5 (1 self) - Add to MetaCart
This thesis presents a specification-based technique for generating, augmenting, and minimizing test suites. The technique is automatic but assumes the existence of a test case generator. The technique dynamically induces specifications from test suite executions. Test suites can be generated by adding cases until the induced specification stops changing. The resulting test suites have better fault detection than suites of the same size with 100% branch coverage. Augmenting an existing test suite, such as a code-covering suite, also increases its fault detection. Minimizing test suites while holding the generated specification constant compares favorably to previously-known techniques.

Config: a case study in combining software engineering techniques

by David Maley , Ivor Spence
"... Config is a software component of the Graphical R-Matrix Atomic Collision Environment. Its development is documented as a case study combining several software engineering techniques: formal specification, generic programming, object-oriented programming, and design by contract. It is specified in ..."
Abstract - Add to MetaCart
Config is a software component of the Graphical R-Matrix Atomic Collision Environment. Its development is documented as a case study combining several software engineering techniques: formal specification, generic programming, object-oriented programming, and design by contract. It is specified in VDM++; and implemented in C++, a language which is becoming more than a curiosity amongst the scientific programming community. C++ supports object orientation, a powerful architectural paradigm in designing the structure of software systems, and genericity, an orthogonal dimension to the inheritance hierarchies facilitated by object oriented languages. Support in C++ for design by contract can be added in library form. The combination of techniques make a substantial contribution to the overall software quality.

TESTAF: A Test Automation Framework for Class Testing using Object-Oriented Formal Specifications

by Aamer Nadeem, Muhammad Jaffar-ur-rehman
"... Abstract: In this paper, we present a novel framework TESTAF to support automatic generation and execution of test cases using object-oriented formal specifications. We use IFAD VDM++ as the specification language, but the ideas presented can be applied equally well to other object-oriented formal n ..."
Abstract - Add to MetaCart
Abstract: In this paper, we present a novel framework TESTAF to support automatic generation and execution of test cases using object-oriented formal specifications. We use IFAD VDM++ as the specification language, but the ideas presented can be applied equally well to other object-oriented formal notations. The TESTAF framework requires a VDM++ specification for a class, a corresponding implementation in C++, and a test specification, to generate and execute test cases, and evaluate the results. The test specification defines valid test sequences in an intermediate specification language based on regular expressions. The framework uses the formal specification of the class, and the test specification to generate empty test shells, which are then filled in with the test data to create concrete test cases. The test data for a method are generated from the input space defined by the method pre condition and the class invariant. The TESTAF applies boundary value analysis strategy to generate the test data. A test driver then executes the implementation with the test data, and uses a conjunction of method post condition and the class invariant as a test oracle to evaluate the results, while reporting failed test cases to the user. Key Words: automated testing, formal specification, object-oriented software Category: D.2.5

Predicting Problems Caused by Component Upgrades

by unknown authors
"... We present a new, automatic technique to assess whether replacing a component of a software system by a purportedly compatible component may change the behavior of the system. The technique operates before integrating the new component into the system or running system tests, permitting quicker and ..."
Abstract - Add to MetaCart
We present a new, automatic technique to assess whether replacing a component of a software system by a purportedly compatible component may change the behavior of the system. The technique operates before integrating the new component into the system or running system tests, permitting quicker and cheaper identification of problems. It takes into account the system’s use of the component, because a particular component upgrade may be desirable in one context but undesirable in another. No formal specifications are required, permitting detection of problems due either to errors in the component or to errors in the system. Both external and internal behaviors can be compared, enabling detection of problems that are not immediately reflected in the output. The technique generates an operational abstraction for the old component in the context of the system and generates an operational abstraction for the new component in the context of its test suite; an operational abstraction is a set of program properties that generalizes over observed run-time behavior. If automated logical comparison indicates that the new component does not make all the guarantees that the old one did, then the upgrade may affect system behavior and should not be performed without further scrutiny. In case studies, the technique identified several incompatibilities among software components.
(Show Context)