27.03.2014 Views

SEKE 2012 Proceedings - Knowledge Systems Institute

SEKE 2012 Proceedings - Knowledge Systems Institute

SEKE 2012 Proceedings - Knowledge Systems Institute

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Figure 2. Overview of the Test Generation<br />

Framework.<br />

only if the conditions of context are satisfied. Following<br />

we present an overview of our tests suite generation framework<br />

for O2O. Graphically, it is represented in Figure 2.<br />

The process of “Automatic test case generation” receives<br />

two inputs parameters. On the one hand the specification<br />

of the system by using a formal model based on Extended<br />

Finite Automata. This model represent the joint behavior of<br />

the two systems (the O-grantor and the O-grantee). In particular,<br />

the O-grantor model describes the functional aspect<br />

of the system and the interoperability security policy [11].<br />

On the other hand the test objectives specifying the security<br />

properties to be tested. Regarding the hole approach, these<br />

are the main concepts that allow us to describe it in detail:<br />

1. The test architecture,<br />

2. the systems behaviors using a formal specification language,<br />

3. the test objectives and the test case generation, and<br />

4. the test execution and test verdict.<br />

Let us focus in the first topic 1, by means the test architecture.<br />

Our system consists of two systems: a system that<br />

represents the O-grantee and the other one that represents<br />

the O-grantor. On the one hand, the access is done by the<br />

users of the O-grantee so the unique control point should<br />

be placed at the user side of the O-grantee that initializes<br />

the interaction between the two systems. On the other hand<br />

we have a set of compulsory minimum set of points of observation<br />

to attach to the architecture, but we are allowed<br />

to define higher number of points of observations where the<br />

exchanged data can be collected at runtime. Note that in our<br />

approach it is necessary to attach the following points of observations:<br />

those points that allow us to collect the interactions<br />

of the O-grantor with its information system which in<br />

charge of managing the security policies contexts, and those<br />

interactions between the O-grantor and the O-grantee when<br />

the information of a context are managed by the O-grantee.<br />

Now, let us focus on 2, that is the systems behaviors using<br />

a formal specification language process. The description<br />

shows the behavior of the communicating system by<br />

taking in consideration the test architecture, the interoperability<br />

security policy, and the different actions that intervene<br />

in the correct behaviors of the service. In our approach<br />

each system behavior is modeled with an Extended Finite<br />

Automaton in IF language. The extended automaton that<br />

covers the joint-behavior of the two systems is built from<br />

the automata of these systems.<br />

Next we present the following concept, by means 3: the<br />

test objectives and test generation. This task is based on<br />

selecting a set of tests according to a given criteria. These<br />

criteria are defined with respect to the security requirements<br />

to be tested. We formally define a test objective as a list<br />

of ordered conditions. This means that the conditions have<br />

to be satisfied in the order that is given by the test objective.<br />

The test case generation is guided by the set of these<br />

test objectives. The inputs of the generated test case stimulate<br />

the system O-grantee that sends specific requests to<br />

the system O-grantor. Whereas, the outputs of the test cases<br />

represent the expected behavior of the system when the security<br />

rules hold. In this step we have also to check the<br />

activation of the security rules. We define for each security<br />

rule of the interoperability security policy a test objective.<br />

Thus, we generate at least for each security rule a test case<br />

to check if the O-grantor conforms this rule. The test cases<br />

are generated from the extended automaton that covers the<br />

joint-behavior of the two systems. When we generate test<br />

cases from the extended automata (in 2) it is necessary to<br />

use some methodologies based on partial generation of the<br />

reachability graph to obtain the tests [4]. In these methods<br />

the test case generation process is guided by the test architecture<br />

and a predefined set of test objectives.<br />

Finally, to automatize the process of tests generation presented<br />

in Figure 2 we use the TestGen-IF tool [5]. This<br />

tool is open source and it accepts systems modeled with the<br />

IF language. In Figure 3 the architecture of this tool is presented.<br />

The tool allows to build tests sequences with high<br />

fault coverage and to avoid the state explosion and deadlock<br />

problems encountered respectively in exhaustive or exclusively<br />

random searches. Let us remind that in the architecture<br />

of this tool the test coverage considers a complete test<br />

generation if all set of chosen properties are specified in the<br />

test objectives.<br />

Following we present the last notion, by means 4: test<br />

execution and test verdict. In order to execute the test<br />

cases generated with TestGen-IF in an O2O scenario, it<br />

466

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!