Application of PROLOG to test sets generation from algebraic specifications

Bougé, Luc; Choquet, N; Fribourg, Laurent; Gaudel, Marie-Claude

doi:10.1007/3-540-15199-0_17

Cited by 16 publications

(5 citation statements)

References 16 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Gerhart [25] describes a logicprogramming approach to generate test points according to any scheme the tester imposes. In a slightly different approach, an ESPRIT project automatically generates tests based on traces (operation sequences) without direction by the tester [14], [15], [24]. Third, the DAISTS system [22] attempts to check consistency of an implementation and algebraic ADT specification, by executing the concrete code corresponding to the two sides of a specification axiom and comparing the results with an implementation-supplied equality function.…”

Section: Relation To Previous Workmentioning

confidence: 99%

Automatically checking an implementation against its formal specification

Antoy

Hamlet

2000

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

ÐWe propose checking the execution of an abstract data type's imperative implementation against its algebraic specification. An explicit mapping from implementation states to abstract values is added to the imperative code. The form of specification allows mechanical checking of desirable properties such as consistency and completeness, particularly when operations are added incrementally to the data type. During unit testing, the specification serves as a test oracle. Any variance between computed and specified values is automatically detected. When the module is made part of some application, the checking can be removed, or may remain in place for further validating the implementation. The specification, executed by rewriting, can be thought of as itself an implementation with maximum design diversity, and the validation as a form of multiversion-programming comparison. Index TermsÐSelf-checking code, object-oriented software testing, formal specification, rewriting.

show abstract

Section: Relation To Previous Workmentioning

confidence: 99%

Automatically checking an implementation against its formal specification

Antoy

Hamlet

2000

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

show abstract

“…Analogous problems arise in program testing where one must determine whether user invisible effects of running test data on component programs affect system correctness. For example, see [4].…”

Section: Proving Program Noninterferencementioning

confidence: 99%

“…By being carried out on as abstract a level as possible, our security proof can survive implementation changes that do not affect the user interface to the system. 4 We then show how to prove that a program satisfies a trace specification of Noninterference directly, without having to introduce an intermediary state machine. We go beyond this rather local concern, however, by showing how to define a programming language in terms of traces and how to prove a program correct vis-a-vis a trace specification.…”

Section: Introductionmentioning

confidence: 99%

Proving Noninterference and Functional Correctness Using Traces

McLean

1992

JCS

View full text Add to dashboard Cite

The trace method of software specification is extended to provide a natural semantics for a procedural programming language. This extension provides a method for proving program correctness that permits a direct proof of program Noninterference without having to produce an intermediate finite state machine and unwinding conditions. This approach provides a uniform framework for reasoning about abstract software system specifications and their implementations. It also allows us to prove security at an abstract level so that changes to programs that do not affect functional behavior will not affect the security proof. 1. For example, see [19]. 4. Similar remarks apply, e. g., to safety.

show abstract

“…This paper is a survey of a research activity which has been led for several years in the area of program testing [5,6,7], and a presentation of some recent results [2,3,22].…”

Section: Introductionmentioning

confidence: 99%

Testing can be formal, too

Gaudel

1995

TAPSOFT '95: Theory and Practice of Software Development

200

147

View full text Add to dashboard Cite

Abstract. The paper presents a theory of program testing based on formal specifications. The formal semantics of the specifications is the basis for a notion of an exhaustive test set. Under some minimal hypotheses on the program under test, the success of this test set is equivalent to the satisfaction of the specification. The selection of a finite subset of the exhaustive test set can be seen as the introduction of more hypotheses on the program, called selection hypotheses. Several examples of commonly used selection hypotheses are presented. Another problem is the observability of the results of a program with respect to its specification : contrary to some common belief, the use of a formal specification is not always sufficient to decide whether a test execution is a success. As soon as the specification deals with more abstract entities than the program, program results may appear in a form which is not obviously equivalent to the specificied results. A solution to this problem is proposed in the case of algebraic specifications.

show abstract

Application of PROLOG to test sets generation from algebraic specifications

Cited by 16 publications

References 16 publications

Automatically checking an implementation against its formal specification

Automatically checking an implementation against its formal specification

Proving Noninterference and Functional Correctness Using Traces

Testing can be formal, too

Contact Info

Product

Resources

About