Testing and Validation Options for Large Models - Gnorion/BizVR GitHub Wiki

TESTING AND VALIDATION OPTIONS (BVR and DMN)

  1. send the entire model with all tables and all of its inputs (ok for small models)
  2. send the entire model (but pin some values of the variables to reduce the number of combinations)
  3. send the entire model (but only select a subset of the input variables)
  4. send a single table (with all inputs, pinned inputs or a subset) - recommended approach as tables are created
  5. send a related (i.e connected) set of tables (with all inputs, pinned inputs or a subset of the inputs) - recommended approach done as related groups of tables are created - but only after the individual tables have been validated and tested

Options 1, 3 and 4 are currently working (except for pinning). Options 2 and 5 need additional work in BVR to choose tables or set values

In all cases VV will validate whatever you send and generate test cases (assuming you have set "test cases limit" to some non zero value in the settings table)

Note VV will also accept additional test values to use beyond those discovered in the rules. For this you can create a "possible values" table.

https://github.com/Gnorion/BizVR/wiki/Defining-Test-Values-as-Decision-Tables

You can also use standard decision tables to construct test cases (particulary lwhen complex data structures are involved)

https://github.com/Gnorion/BizVR/wiki/Defining-Test-Data-Using-Decision-Tables

This technique allows you to customize the test cases as opposed to having every combination generated automatically.

You might use this approach to create specific text cases aimed at specific rules. This would be appropriate when all possible combinations might include impossible combinations.

Example traffic lights has red, yellow and green. Each light can on or off. so there are 2x2x2=8 possible combinations.

But in reality (and assuming the traffic control circuit is working) only three actually occur (red, red+yellow, green). Well maybe four if you are in the UK where yellow only is an option.

So depending on the business case you may choose to generate all 8 test cases or just three.

Of course if you also have to deal with flashing lights then there are 3x3x3 possible combinations, of which maybe six actually occur in real life.

Now imagine a decision model handling an intersection with many lights (and filter arrows and pedestrian walk signs) the total number of combinations could be staggeringly large. But the number of real combinations would be much smaller (still could be quite large though)