Login | Register
My pages Projects Community openCollabNet

Documentation of mbt.tigris.org

The Model

In order for mbt to understand the model, there are some simple rules to follow.

  1. File format – GraphML
    The model has to be saved as a graphml file.

  2. The model has to be a directed graph, or digraph.

  3. Every graph must have one (and only one) vertex with the label 'Start'.
    This shows mbt the starting point in the graph.

  4. Every vertex in a graph must have a name. Edges usually has names, but are not required to have them. The name shall follow whatever naming convention is required of the test execution engine.

  5. Labels
    The first line of the label represents the name of the vertex or edge.

  6. Keywords
    Keywords are written within the label of a vertex or an edge. They must exist on their own line in the label, but no the first line.

Fig 1: Example of a graph with keywords. The keywords are: weight, NO_MERGE and BLOCKED

Fig 1: Example of a graph with keywords. The keywords are: weight, NO_MERGE and BLOCKED

More on Labels, Guards and Reserved Keywords

Label format

FSM format
Label
Keyword
Where the Label and Keyword are optional.
An example showing different types of FSM labels
An example showing different types of FSM labels


EFSM format:
Label Parameter [Guard] / Action1;Action2;ActionN;
Keyword
Where the Label, Parameter. Guard, Actions and Keyword are optional.
An example showing different types of EFSM labels
An example showing different types of EFSM labels

Labels

Should start with "e_" and not contain whitepace. The "e_" comes from the word edge, and makes it easier to read code later on, and quickly determine what is edges and what is vertices functions/methos.

Example:
  e_StartApplication

Example:
  e_EnterBasicView


Parameters

Freely formed string

Example:
  e_AddEggs 5

Example:
  e_Login WorkingPassword

Example (Sting containing spaces):
  e_Login "This is a string containing spaces"


Guards

Must return boolean value that indicates if the edge is accessable in the current state of the machine.

Exaple:
  e_Evaluate [x>0 && y<=10]

Example:
  e_Checkout [shoppingBasket.contains("Cerials")]

Action

Any applicable Java statements, should be used to restrict or direct the flow though the model.

Example:
  e_Calculate / x=5;y=10*x;

Example:
  e_AddCerials / shoppingBasket.add("Cerials");


Reserved Keywords

The keywords are written on separate lines on the labels of vertices and edges. The exception of that rule is START and STOP, which are written on the first line.

Example:
    e_CloseApp_AltF4
    BACKTRACK
    weight=0.1


MERGE
Used by Vertices only, can be combined with other keywords.
This keyword is used by mbt when merging graphs. It tells MBT that the vertex containing this key word, should be merged with the first occurence of a vertex with the same label.

Example:
    v_MainForm
    MERGE


NO_MERGE
Used by Vertices only, can be combined with other keywords.
This keyword is used by MBT when merging graphs. It tells MBT that the vertex containing this key word, should not merge this vertex with any subgraph.

Example:
    v_MainForm
    NO_MERGE


BACKTRACK
Used by Edges only in FSM (not for use in EFSM), can be combined with other keywords.
An edge with the key word BACKTRACK is used to enable a simple logic that enables a end user to backtrack in the graph to the previous vertex. This is used only during a dynamic run.

Example:
    e_ClickOKButton
    BACKTRACK


BLOCKED
Used by Vertices and Edges, can be combined with other keywords.
A vertex or an edge with the key word BLOCKED, will be excluded from the model.

Sometimes it can be useful, to mark vertcies or edges as BLOCKED due to bugs in the system you test, and you do not want the test to execute that specific part of the system. When the bug is removed, the BLOCKED keyword can be removed.

Another reason could be that you have made a complete model according to the requirements, but the system under test is only partial finished. Then it would be convinient to mark those parts in the model using BLOCKED, preventing the tests from trying to execute in parts of the system that is not yet delivered by the development team.

Example:
    v_MainForm
    BLOCKED

Example :
    e_MenuFileExit
    BLOCKED


START
Used by Vertices only, can not be combined with other keywords.
Each graph has a start (entry) vertex, and that vertex holds this datum. There is only one vertex in a graph, holding this datum. Used by MBT when merging graphs, and when generating test sequences.

Example:
    START


STOP
Used by Vertices only, can not be combined with other keywords.
The stop (exit) vertex denotes an exit point in a graph. There can only be one vertex in a graph, holding this datum. Only sub-graphs can have a stop vertex. Used by MBT only when merging graphs.

Example:
    STOP


weight
Used by Edges only, can be combined with other keywords.
Used by mbt during random walks during test sequence generation. It holds a real value between 0 and 1, and represents the probability that a specific edge should be chosen. A value of 0.05, would mean a 5% chance of that edge to be selected during a run.
Note: The keyword is case sensitive, and it only works with the RANDOM generator, and is enabled using the command-line switch -w

Example:
    e_GoAdmin
    weight=0.05


REQTAG
Used by Vertices and Edges.
Used by mbt for keeping track of which requirements are fullfilled during testing.

Example:
    v_BookInformation
    REQTAG=UC01 2.2.3

In the example above, if v_BookInfomation is passed, it would mean the the requirment with tag UC01 2.2.3 has passed.

Complex graphs

When a graph becomes complicated, a break-down of a single graph into several graphs can be very useful. Instead of selecting a single graph for the test, a folder is used. This folder contains one, or more graphs. When the test is run, MBT merges all graphs into one single graph. The merged graph is not written to any file during the test, but stored in memory. However, sometimes it can be useful to inspect the merged graph.
  1. Type 'java -jar mbt.jar merge -f folder
  2. The output is printed to standard output, if you want it to a file, type:
    java -jar mbt.jar merge -f folder > model.graphml

Merging of graphs

The folder, which contains the graphs, must have one, and only one mother-graph. A mother-graph is where the merging process starts. The rest of the graphs, are known as sub-graphs.
A mother-graph is defined as follows:
  1. The graph must have one, and only one vertex, named ”Start”.
  2. There can only be one out-edge from the ”Start” vertex.
  3. The out-edge from the ”Start” vertex must have a label.
  4. The name of the mother-graph is equal to the name of the destination vertex of the out-edge from the ”Start”-vertex.
In the example below, the name of the mother-graph would be ”A”.
Fig 2: Example of a mother-graph, with the name ”A”
Fig 2: Example of a mother-graph, with the name ”A”

A sub-graph is defined as follows:
  1. The graph must have one, and only one vertex, named ”Start”.
  2. There can only be one out-edge from the ”Start” vertex.
  3. The out-edge from the ”Start” vertex can have no label, or the label must be empty.
  4. The name of the sub-graph is equal to the name of the destination vertex of the out-edge from the ”Start”-vertex.
In the example below, the name of the sub-graph would be ”C”.
Fig 3: Example of a sub-graph, with the name ”C”
Fig 3: Example of a sub-graph, with the name ”C”

The advantage with mother- and sub-graphs is that it allows complex graphs with repeating patterns of vertices and edges, to be broken down into smaller and re-usable parts. A simple example of a merged graph is illustrated below. It is a merge from Fig 2 and 3.
Fig 4: Merged graph from Fig 2 and 3
Fig 4: Merged graph from Fig 2 and 3