Model-Based Testing of SAP Modules

This presentation provides an overview of how the model-based testing (MBT) process can help to generate accurate test cases as well as executable test scripts for SAP R/3 module testing to auto- mate regression testing. In the MBT process, a model is used to capture the expected behaviour of the application under test, fulfilling the functional requirements. This model makes it possible to automatically generating test cases and test drivers including the traceability matrix between functional requirements to test cases. Linking requirements to the behaviour model implements the requirements-based testing (RBT) process and addresses two major issues: first, validating that the requirements are correct, complete, unambiguous, and logically consistent during modelling phase; and second, automatically generating a necessary and sufficient (from a black box perspective) set of test cases from those requirements to ensure that the design and code fully meet those requirements. In this talk, we show how tests can be automatically generated from a UML model to test the security aspects of SAP Defense Modules. Defense Security Scenario Requirement Specifications have been modelled using UML 2. In our approach, the automatic generation of functional tests is based on an unambiguous UML model of the functional requirements of the application under test. This functional model uses Class diagram, State machines and OCL expressions to represent the expected visible behaviours of the application, but it does not integrate the implementation details (it is not an archi- tectural representation). Requirements traceability is managed by tagging manually the effects of the transitions in the UML model with the requirements. Then, this model ought to be sufficiently precise to allow the generation of test cases (as sequences of operations) including expected outputs and the traceability matrix between generated test cases and functional requirements. The test cases/expected output pairs are directly used during test case execution on the application under test, to obtain an automated verdict (success or fail).