Model Sequencers

Model Sequencer is algorithm-based test case (test sequence) generation from the model.

The test case generation is referred to as Generate action.

The generated test cases can be automated to drive Application Under Test (AUT) through Groovy-based Scripting. This step is referred to as Execute model action.

Sequencers generate the test sequence by traversing the state diagram using graph-based algorithms. A graph path from model's initial state to any of the final state is considered a test case.

Different algorithms achieve different coverage on the model. In combination with stop conditions, you can stop the test generation when the desired coverage is achieved.

Random sequencer traverses State-based models using the variation from the markov-chain process to construct test paths from iniital state to final states.

The weight of the outgoing transitions determines the probability a transition will be traversed from its source state. The higher the weight, the more often the transition will be traversed, with a caveat: non-traversed transitions are preferred over already-traversed transitions.

Random sequencer is useful for exploratory type of testing by allowing the model to run for an extended period of time to let the algorithm explore “all possible” paths.

Random sequencer is also often used for load and stress testing by running model with many virtual users (VUs) to simulate realistic load of a production systems.

Another good use of Random sequencer is to find memory leak, locking contention, etc. that are caused by running AUT over a long period of time or under heavy load. You can just leave the model running with the elapse time stop condition set to desired duration of time.

The disadvantage of Random sequencer is that the model coverage is typically time-dependent - it may take longer time for it to achieve the desired model coverage.

Optimal sequencer uses the algorithm for Route inspection problem (aka Chinese Postman Problem) to generate the test cases (paths) that covers all transitions (and thus all states) in the State-based models.

The obvious advantage of Optimal sequencer is that it generates the least number of steps to cover all transitions in the model. As the result, this sequencer would work better for larger models or if you just want to run all test cases in the least amount of time.

The side effect is that the test cases generated by Optimal sequencer tends to be longer and fewer test cases with the minimal total number of test steps. This can be viewed as either an advantage or disadvantage depending on your specific use case.

Priority sequencer prioritizes transitions based on their assigned weight and tries to traversed transitions with higher weight first using graph algorithm to achieve desired model coverage.

The test cases generated by Priority sequencer usually are shorter than Optimal sequencer due to the nature of the algorithm, but the number of test steps to achieve the similar model coverage would be larger compared to Optimal sequencer.

Priority sequencer might be a good choice if you have certain transitions in the model that you wish to cover earlier and/or prefers shorter test cases.

This sequencer supports following parameters to adjust the sensitivity on choosing higher priority transitions and over traversed transitions:

• TraversedTransCost: integer, default 500
• scale: float >= 0.1, default 1.0 = neutral, < 1.0 for less sensitive (less penalty on choosing lower weight transitions), > 1.0 for more sensitive

You may also set above parameters in config.properties for all models:

  Sequencer.TraversedTransCost=integer
  Sequencer.scale=float

AllPairs sequencer explores combinations of incoming and outgoing transitions of each state in the model and generate test paths that cover all incoming - outgoing transition pairs.

AllPairs sequencer offers more extensive model coverage than most of the sequencers ( Optimal and Priority, and others) with a deterministic test sequence.

With IDE, you can mark (highlight) states and transitions and generate test sequence to cover partial of the model. With ProMBT, you can also submit model execution with REST api.

MCase is a collection of transitions that represents a custom test case. MCase sequencer generates the actual test sequence (test steps) to navigate through the model to cover the transitions included in the MCase. This works very similarly as Marked Serial sequencer except that the transition collections are defined in scripts and MCases can be executed in IDE as well as remotely.

The main use of MCase sequencer is to generate custom test cases, which can be used to test a bug fix, regression testing of important workflows and smoke testing.

Since MCase is built with scripting, you can dynamically build any number of MCases through REST api. This provides an option to allow ALM process to test bug fixes remotely.