Is tcases really model-based generator in a broad sense?

[ghost]

"The Complete Guide" is absolutely great, only one detail bothers me - in which tests to use the tcases generator, and in which cases an alternative approach is needed.

The project declares that it is "model-based test case generator", but in fact it is ideal for static stateless tests with rich input parameter domains, but in theory, model-based tests are something else - generating tests for a graph model, or comparing a real system with its simplified but correct prototype.

Questions: Did you think to highlight these subtleties in the documentation? How correct is my vision? Do you have any experiences using a tcase generator, for example to test multilevel state machines? Thanks a lot for a great project!

[kerrykimbrough]

I think it's fair to say that Tcases is a type of "model-based test case generator". But it is certainly true that there are many other ways to model a software system. True, a Tcases input model is a static model that takes no account of the behavior of the SUT, so it is unable to produce assertions about expected results. On the other hand, it is universal (every system has an input space! ), concrete (no abstract representations of system logic), and effective (if used diligently). At any rate, input space modeling deserves a place alongside all of the other forms of model-based testing. For example, see Introduction to Software Testing by Paul Ammann and Jeff Offutt.

You could certainly apply Tcases to test a system that is based on an FSM -- the current state is simply another input variable. But it would take more effort to chain operations together to test a start-to-finish sequence. A long time ago, I built a prototype for an FSM-based test generator. The concept was to begin with a state transition model and then attach to each transition an input model for the data that stimulates that transition. From these transition input models, Tcases can generate multiple variations of each transition, each using a different valid or invalid data combination. To generate a test sequence, you begin with a random variation of a start transition and repeat the process for each resulting state until you reach an end state. Complete coverage of all transition variations then includes input space coverage for all transition data.

[kerrykimbrough]

Another feature I considered for this FSM testing prototype was to include an estimated probability for each transition. During test generation, you would weight the selection of each transition according to this likelihood. As a result you could use the results of random sequence executions to estimate the reliability of the system, based on mean transitions to failure. This was the approach used with great success in the legendary Cleanroom process.