On Oracles for Interpreting Test Results against Algebraic Specifications

Machado, Patrícia D. L.

doi:10.1007/3-540-49253-4_35

Cited by 16 publications

(30 citation statements)

References 8 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Machado [27] proposed oracles derived from flat algebraic specifications expressed in first-order logic. Machado [28] presented an extension of the framework in Bernot et al [3], [4] to first-order logic with restrictions on quantifiers.…”

Section: Related Previous Workmentioning

confidence: 99%

“…(a) In previous work such as Aiguier et al [1], Bernot et al. [3], [4], Le Gall and Arnould [26], Machado [27], [28], and Machado and Sannella [29], the authors defined that a program P is correct with respect to a specification Sp if and only if P satisfies the set of all ground instances of every axiom in Sp. For the sake of brevity, we will use GI to denote this set of all such ground instances.…”

Section: Theoretical Implications In Relation To Previous Work On Clamentioning

confidence: 99%

See 1 more Smart Citation

Equality to Equals and Unequals: A Revisit of the Equivalence and Nonequivalence Criteria in Class-Level Testing of Object-Oriented Software

Chen

Tse

2013

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

Abstract-Algebraic specifications have been used in the testing of object-oriented programs and received much attention since the 1990s. It is generally believed that class-level testing based on algebraic specifications involves two independent aspects: the testing of equivalent and nonequivalent ground terms. Researchers have cited intuitive examples to illustrate the philosophy that even if an implementation satisfies all the requirements specified by the equivalence of ground terms, it may still fail to satisfy some of the requirements specified by the nonequivalence of ground terms. Thus, both the testing of equivalent ground terms and the testing of nonequivalent ground terms have been considered as significant and cannot replace each other.In this paper, we present an innovative finding that, given any canonical specification of a class with proper imports, a complete implementation satisfies all the observationally equivalent ground terms if and only if it satisfies all the observationally nonequivalent ground terms. As a result, these two aspects of software testing cover each other and can therefore replace each other. These findings provide a deeper understanding of software testing based on algebraic specifications, rendering the theory more elegant and complete. We also highlight a couple of important practical implications of our theoretical results.

show abstract

Section: Related Previous Workmentioning

confidence: 99%

Section: Theoretical Implications In Relation To Previous Work On Clamentioning

confidence: 99%

Equality to Equals and Unequals: A Revisit of the Equivalence and Nonequivalence Criteria in Class-Level Testing of Object-Oriented Software

Chen

Tse

2013

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

show abstract

“…This contradicts a common belief that the existence of a formal specification is sufficient to directly decide whether a test is a success. In presence of complex data types, it may be necessary to embed the tests into observable contexts, or to enrich the SUT with some concrete equivalence function [22].…”

Section: The Oracle Problemmentioning

confidence: 99%

“…Historically the above framework has been developed for algebraic specifications [4], [22]. Test data are just instantiated axioms of the specification and test experiments consist in their evaluation by the SUT to check that they are satisfied.…”

Section: Axioms Pre-conditions and Post-conditionsmentioning

confidence: 99%

“…Thus, testing is very different from program proving, even if it is related. Similarly, testing is different from model checking, where verifications are performed on a known model: when testing, the model corresponding to the system under test is unknown (if it was known, testing would not be necessary…) and it is sometimes difficult to observe in what state it is [20], [22]. These points have been successfully circumvented in several testing methods based on formal specifications (or models) that use various and diverse techniques such as graph theory, symbolic evaluation, proof techniques, constraint solving, static analysis or model checking.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Formal Methods and Testing: Hypotheses, and Correctness Approximations

Gaudel

2005

FM 2005: Formal Methods

View full text Add to dashboard Cite

Abstract. It has been recognised for a while that formal specifications can bring much to software testing. Numerous methods have been proposed for the derivation of test cases from various kinds of formal specifications, their submission, and verdict. All these methods rely upon some hypotheses on the system under test that formalise the gap between the success of a test campaign and the correctness of the system under test.

show abstract

Exhaustive test sets for algebraic specifications

Aiguier

Arnould

Gall

et al. 2016

Software Testing Verif & Rel

View full text Add to dashboard Cite

In the context of testing from algebraic specifications, test cases are ground formulas chosen amongst the ground semantic consequences of the specification, according to some possible additional observability conditions. A test set is said to be exhaustive if every programme P passing all the tests is correct and if for every incorrect programme P , there exists a test case on which P fails. Because correctness can be proved by testing on such a test set, it is an appropriate basis for the selection of a test set of practical size. The largest candidate test set is the set of observable consequences of the specification. However, depending on the nature of specifications and programmes, this set is not necessarily exhaustive. In this paper, we study conditions to ensure the exhaustiveness property of this set for several algebraic formalisms (equational, conditional positive, quantifier free and with quantifiers) and several test hypotheses. EXHAUSTIVE TEST SETS FOR ALGEBRAIC SPECIFICATIONS 295 decision procedure, hence are considered to be observable. The notion of observable contexts has been introduced to systematically observe non-observable sorts through successive applications of operations leading to a result of observable sort [16][17][18]. Therefore, equations of non-observable sort are converted into a family of equations built by surrounding terms that occur in the initial equation with the same observable context. This has been particularly used for object-oriented software testing where, by assumption, object states are encapsulated [7,14,19].Because test cases are defined up to observability issues, the notion of correctness is closely related to observability assumptions. Roughly speaking, correctness is reached when there is a (possibly infinite) test set that verifies that any correct (resp. incorrect) programme successfully (resp. unsuccessfully) passes the test. Because any programme that satisfies all test cases has to be considered correct, correctness is defined according to an observational approach similar to those used to define specification refinement [20-24]: a concrete specification is said to be a refinement of an abstract specification if any algebra of the concrete specification is observationally equivalent to an algebra of the abstract specification. Here, by analogy, we say that a programme P is correct with respect to a specification SP if it is equivalent to an algebra of SP, up to the observable formulas in Obs [1,9]. Let us point out that by default, the model class defined by SP is not restricted to a unique model (such as the initial one or the terminal one [25]). Thus, we follow a loose semantics approach, that is the model class associated to SP can contain several models, each of them likely to represent a different programme. The interest is to be able to accept programmes that possibly implement some extra functionalities or properties (contrarily to other approaches considering terminal semantics [14,19]).As usual, SP denotes the set of all semantic consequences of ...

show abstract

On Oracles for Interpreting Test Results against Algebraic Specifications

Cited by 16 publications

References 8 publications

Equality to Equals and Unequals: A Revisit of the Equivalence and Nonequivalence Criteria in Class-Level Testing of Object-Oriented Software

Equality to Equals and Unequals: A Revisit of the Equivalence and Nonequivalence Criteria in Class-Level Testing of Object-Oriented Software

Formal Methods and Testing: Hypotheses, and Correctness Approximations

Exhaustive test sets for algebraic specifications

Contact Info

Product

Resources

About