27.07.2013 Views

2 Why We Need Model-Based Testing

2 Why We Need Model-Based Testing

2 Why We Need Model-Based Testing

SHOW MORE
SHOW LESS

Create successful ePaper yourself

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

62 <strong>Model</strong> Programs<br />

reasonable work assignment. For example, a tester would choose a collection of<br />

features that would be covered by a typical test suite. The chosen subset of features<br />

is sometimes called a slice (of the implementation’s complete feature set).<br />

For this example, we choose a very small subset of newsreader features: the<br />

screens, styles, and options described in Section 5.2. This is an unusually small<br />

collection of features for a model program that we chose to make this example brief.<br />

5.3.3 Choose a level of abstraction<br />

Even when we limit ourselves to a subset of features, we do not consider every<br />

implementation detail in that subset. <strong>We</strong> must decide which details to include in<br />

the model program; other details can be omitted or greatly simplified. This is called<br />

abstraction; our choice of which details to include defines the level of abstraction.A<br />

lower level shows more detail, and results in a larger, more complex model program.<br />

A higher level shows less detail, and results in a smaller, simpler model program.<br />

Working at a higher level of abstraction is easier because there is less information<br />

to deal with. You should always write your model program at the highest level<br />

of abstraction that achieves your purpose (that can answer the questions you have<br />

formulated). Much of the skill in modeling is understanding what can be left out in<br />

order to achieve the right level of abstraction.<br />

<strong>We</strong> use three kinds of abstraction. Data abstraction deals with variables. A higher<br />

level of data abstraction uses fewer variables, fewer values for those variables, and<br />

simpler data types. Data abstraction is our primary technique for finitizing models:<br />

we replace a potentially “infinite”collection of values with a (usually small) finite<br />

collection. Behavioral abstraction deals with statements and methods. A higher level<br />

of behavioral abstraction uses fewer statements or methods, where each statement or<br />

method in the model program represents more behavior in the implementation. Environmental<br />

abstraction deals with control structure. A higher level of environmental<br />

abstraction removes control structure, leaving it to the tool or the environment<br />

to choose which methods to execute at run time. In other words, environmental<br />

abstraction replaces control structure with nondeterminism.<br />

In this example we choose a high level of data abstraction where the variables<br />

only represent the kind of page that is displayed and its style. <strong>We</strong> do not represent<br />

the page contents (the topics and messages). <strong>We</strong> choose a high level of behavioral<br />

abstraction where each action in the model program represents a large amount of<br />

implementation behavior. Each action represents both the selection of an option that<br />

causes a new page (or a different page style) to appear, and the appearance of that<br />

page.<br />

In every model program, we use the same high level of environmental abstraction.<br />

There is no main method, nor any other control structure that determines the sequence<br />

in which actions occur (methods are called). Instead, the model program has enabling<br />

more free ebooks download links at:<br />

http://www.ebook-x.com

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

Saved successfully!

Ooh no, something went wrong!