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.

278 Part III. Model-Based Test Case Generation<br />

Basically, this is achieved by redundancy: two models (state mach<strong>in</strong>es, temporal<br />

formulae, etc.) are built, and detection of a discrepancy among them po<strong>in</strong>ts at<br />

potential difficulties.<br />

If an artifact that is to be checked is of a purely mathematical nature, then<br />

<strong>in</strong>f<strong>in</strong>ite <strong>in</strong>put doma<strong>in</strong>s, or <strong>in</strong>f<strong>in</strong>ite runs, can technologically be coped with by<br />

means of f<strong>in</strong>ite representations. It is hence possible to argue about <strong>in</strong>f<strong>in</strong>ite behaviors.<br />

If, on the other hand, this artifact is part of the real world, and <strong>in</strong>cludes<br />

sensors, actuators, operat<strong>in</strong>g systems, and legacy systems, then these arguments<br />

cannot be applied. The reason is that <strong>in</strong> general, reason<strong>in</strong>g about systems <strong>in</strong>volves<br />

reason<strong>in</strong>g about states, and when hardware is <strong>in</strong>volved, there is no def<strong>in</strong>ite<br />

knowledge about these states. The consequence is that the comparison between<br />

an actual system and a model is <strong>in</strong>complete, both for complexity and pr<strong>in</strong>cipal<br />

reasons.<br />

Overview This motivates the structure of four chapters <strong>in</strong> this third part of the<br />

book.<br />

Chapter 10 provides a brief overview of methodological issues <strong>in</strong> model-based<br />

test<strong>in</strong>g. Pretschner and Philipps discuss both the need for abstraction <strong>in</strong> practical<br />

applications of model-based test<strong>in</strong>g and different scenarios of model-based<br />

test<strong>in</strong>g.<br />

The selection of a few traces of the model can be done w.r.t. functional,<br />

structural, and stochastic criteria. The first category seems to be amenable to<br />

methodology rather than to technology. In Chapter 11, Gaston and Seifert have a<br />

thorough look at the two other criteria, structural and stochastic criteria. While<br />

structural criteria have been used for f<strong>in</strong>ite state mach<strong>in</strong>es (transition coverage,<br />

for <strong>in</strong>stance) <strong>in</strong> previous chapters of the book, they look at coverage criteria at<br />

the level of programm<strong>in</strong>g languages. This does not contradict the title of this<br />

part: models may well be specified by means of programm<strong>in</strong>g languages, and<br />

code is often used to specify guards and assignments <strong>in</strong> respective model<strong>in</strong>g<br />

languages. The authors then have a look at stochastic criteria and review the<br />

discussion on compar<strong>in</strong>g their fault detect<strong>in</strong>g power with test<strong>in</strong>g that is based<br />

on partition the <strong>in</strong>put doma<strong>in</strong>.<br />

In the third Chapter 12 of this part, Lúcio and Samer go one step further.<br />

They assume a selection criterion, be it functional, structural, or stochastic, to<br />

be given. The selection criterion and the model are then used to generate test<br />

cases. The generation process is the subject of their article. Consequently, they<br />

<strong>in</strong>vestigate the use of model check<strong>in</strong>g, symbolic execution, theorem prov<strong>in</strong>g, and<br />

logic programm<strong>in</strong>g. Tools that rely on these and other mechanisms—on-the-fly<br />

test<strong>in</strong>g, <strong>in</strong> particular—are discussed later <strong>in</strong> this book, <strong>in</strong> Chapter 14.<br />

F<strong>in</strong>ally, the fourth Chapter 13 is concerned with a particularly complex class<br />

of systems, namely real-time and mixed discrete-cont<strong>in</strong>uous, or hybrid, systems.<br />

Berkenkötter and Kirner first def<strong>in</strong>e the two classes of systems. After show<strong>in</strong>g<br />

how real-time systems can be modeled with different formalisms, they show how<br />

test cases can be generated for them. As far as hybrid systems are concerned,<br />

hybrid statecharts and hybrid variants of process algebras are <strong>in</strong>troduced. Because<br />

of the very large state spaces of these classes of systems, they discuss ways

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

Saved successfully!

Ooh no, something went wrong!