Elements of MBT - Part 2 – States and State Variables

This is a continuation of the Elements of MBT series of posts which I started last time with Part 1 and covered what is meant by a model of a software system. In this post I shall be covering additional concepts which you will need to know to gain a better understanding of Model Based Testing.

One of the most fundamental concepts required to define a model of a system is that of State Variables which in turn are needed to define what a State is. A State Variable is simply some aspect of the system which changes over time. For e.g. in the car driving model, one aspect that changes (and which you care about tracking for the purpose you are building the model for) is whether the car is moving or not. So this can be a state variable, say "CarMotionState", which can have values such as "Moving" and "NotMoving". Couple of important things to keep in mind is that a state variable can have multiple values (not just 2 as in the example above) and that these "values" are really just semantic terms to help us define the model. What the actual values of these do and result in (especially from an automation point of view) is tied in later when you are implementing the code for the model.

A State then becomes much easier to define as simply a combination of all the State Variables in the model with particular values assigned to each state variable. Thus if your model contains 3 state variables S1, S2 and S3 with multiple values for each state variable, a state will be defined by a unique set of values for each of the state variables S1, S2 and S3. You can therefore think of a state as simply a snapshot of all the state variable values at a given point in time. From the Part 1 car driving model we can now see that the 3 states in the model are comprised of the following unique combinations of state variable values.

S1 = { IgnitionState = IgnitionOff; CarMotionState = NotMoving; }

S2 = { IgnitionState = IgnitionOn; CarMotionState = NotMoving; }

S3 = { IgnitionState = IgnitionOn; CarMotionState = Moving; }

One thing to notice here is that not all possible states need to be defined for a particular model. Depending on the system and the reason you are creating the model or the abstraction level you want to capture, you might not include certain states in your model. Or certain states simply won't make any sense to model such as the state "IgnitionOff" + "Moving" if you do not want to capture the behavior of the car sliding down hill when the ignition has not been turned on. The great thing though is that it forces you to think of that scenario and to consider if that is something you want to capture and if so then what the expected behavior would be.

In the next post I shall cover Actions and Action Parameters and update the model to add an Action Parameter to one of the actions.

Comments

• Anonymous
  June 28, 2007
  PingBack from http://car-part-directory.com/blog/index.php/2007/06/28/mazda-car-part-pink-cadillac/

• Anonymous
  July 05, 2007
  In the last 2 posts we have looked at what we mean by a model of a system and defined what States and

• Anonymous
  July 05, 2007
  In the last 2 posts we have looked at what we mean by a model of a system and defined what States and

• Anonymous
  July 01, 2008
  The comment has been removed

• Anonymous
  November 26, 2008
  The comment has been removed