====== 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. =====Types of Sequencers===== 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. =====Sequencer - Random===== //Random// sequencer traverses //State-based// models using the variation from the [[https://en.wikipedia.org/wiki/Markov_chain| 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. =====Sequencer - Optimal===== //Optimal// sequencer uses the algorithm for [[https://en.wikipedia.org/wiki/Route_inspection_problem | 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. =====Sequencer - Priority Path===== //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 =====Sequencer - AllPairs===== //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 ([[#Sequencer - Optimal | Optimal]] and [[#Sequencer - Priority | Priority]], and others) with a deterministic test sequence. =====Sequencer - Marking States/Transitions===== 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. =====Sequencer - MCase===== //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.