07.01.2013 Views

Lecture Notes in Computer Science 3472

Lecture Notes in Computer Science 3472

Lecture Notes in Computer Science 3472

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

11 Evaluat<strong>in</strong>g Coverage Based Test<strong>in</strong>g<br />

Christophe Gaston 1 and Dirk Seifert 2<br />

1 Commissariat a l’energie atomique<br />

Logiciels pour la Sûreté desProcédés<br />

christophe.gaston@cea.fr<br />

2 Technische Universität Berl<strong>in</strong><br />

Software Eng<strong>in</strong>eer<strong>in</strong>g Research Group<br />

seifert@cs.tu-berl<strong>in</strong>.de<br />

Abstract. In the previous chapters, various formal test<strong>in</strong>g theories have been discussed.<br />

The correctness of an implementation with respect to a model is denoted by<br />

a so-called conformance relation. Conformance relations are relations between mathematical<br />

abstractions of implementations and models. Based on these conformance<br />

relations, different test<strong>in</strong>g strategies have been def<strong>in</strong>ed. In this chapter, we concentrate<br />

on formal objects used to select test suites. These formal objects are so-called coverage<br />

criteria. A coverage criterion is a property that a selected test suite has to satisfy. We<br />

explore to which purposes these coverage criteria can be used for. Then we concentrate<br />

on the fault detection ability of a test suite satisfy<strong>in</strong>g a given coverage criterion.<br />

11.1 Introduction<br />

All test<strong>in</strong>g methodologies <strong>in</strong>troduced <strong>in</strong> this book follow the same generic test<br />

process. Test cases are generated accord<strong>in</strong>g to a given model of the implementation.<br />

The model results from a requirements analysis and has to be (if test<strong>in</strong>g<br />

is done automatically) a formal description of the requirements. Test cases are<br />

sequences of <strong>in</strong>put/output pairs and a f<strong>in</strong>ite set of test cases is called test suite.<br />

For each test case of a test suite, the <strong>in</strong>put specified <strong>in</strong> the first pair of the sequence<br />

is ref<strong>in</strong>ed with concrete data called test data. Test data are submitted to<br />

the implementation through its environment. The implementation generates a<br />

result which is captured through its environment. The result is compared (with<br />

respect to a conformance relation) to the output specified <strong>in</strong> the pair. If the<br />

conformance relation is not contradicted, the process goes on with the follow<strong>in</strong>g<br />

pair. If generated outputs all correspond to the <strong>in</strong>tended outputs, the test case<br />

is executed successfully. If all the test cases of the test suite are executed successfully,<br />

a success verdict is assigned to the test process, s<strong>in</strong>ce no test case of<br />

the test suite allows to show that the implementation does not conform to the<br />

specification. Figure 11.1 shows this test<strong>in</strong>g framework.<br />

The number of test cases required to obta<strong>in</strong> confidence <strong>in</strong> the system under<br />

test is usually <strong>in</strong>f<strong>in</strong>itely large for real life applications. Consequently, a so called<br />

doma<strong>in</strong> expert is <strong>in</strong>volved <strong>in</strong> the test process, as he is able to extract <strong>in</strong>terest<strong>in</strong>g<br />

test suites due to his knowledge. For automated test case generation, the problem<br />

rema<strong>in</strong>s unsolved. So, for current test<strong>in</strong>g practices, one of the open questions is:<br />

Which test suite should be extracted from a possibly <strong>in</strong>f<strong>in</strong>ite set of test cases?<br />

M. Broy et al. (Eds.): Model-Based Test<strong>in</strong>g of Reactive Systems, LNCS <strong>3472</strong>, pp. 293-322, 2005.<br />

© Spr<strong>in</strong>ger-Verlag Berl<strong>in</strong> Heidelberg 2005

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!