size equal to the constant NUMBER OF PTCS. Each test component is created, mapped to the system and then started (see lines 15-17). The aim here is to check that under heavy load timing constraints under which the Alarm component is running are still respected.
In order to edit and compile the specified tests, we use respectively the TTCN-3 Core Lan- guage Editor (CL Editor) and the TThree Compiler that are included in the TTworkbench basic
tool3. The generated Jars are stored in the Test Case Repository for further use and can be
dynamically loaded during the runtime test execution to check dynamic changes.
7.4
Checking TRMCS correctness after structural adaptations
At present, we study the evolution of the basic configuration illustrated in Figure 7.1. Indeed, it comes a moment when this system dynamically evolves to fulfill new requirements. For instance, the Alarm component is updated with a new version in order to increase SUT responsiveness. The new version sends the help request to the medical staff in a duration that does not exceed 15 time units instead of 30 time units for the old version. Once this reconfiguration is achieved, the new component and all the affected parts of the system have to be validated.
To perform efficiently the runtime testing of the studied scenario, we begin with the computa- tion of the affected components and compositions by this dynamic change. Figure 7.3 illustrates the system dependencies in this scenario and the affected parts of the system are delimited by a red square.
Legend:
BP_S: Blood Pressure Sensor HR_S: Heart Rate Sensor RB: Report Builder RS: Report Storer An: Analyzer Al: Alarm Nu: Nurse Am: Ambulatory Hp: Hospital Dr: Doctor
Figure 7.3: The dependency graph of the studied scenario.
In the second step, a subset of test cases covering the impacted parts of the TRCMS appli- cation is identified. Table 7.7 shows the constituents of the new test suite to run. Recall that the unit tests are prefixed by “UT” whereas the integration tests are prefixed by “IT”.
Once the test cases are identified, the constrained test component placement module is called in this stage in order to look for a suitable solution that satisfies predefined resource and
3
7.4 Checking TRMCS correctness after structural adaptations 104
Table 7.7: Reusable test cases.
Selected test cases. UT Alarm.jar
IT RBuilder SensorBPS.jar IT RBuilder SensorHRS.jar IT RBuilder Storer.jar
IT RBuilder Analyzer Alarm Nurse.jar IT RBuilder Analyzer Alarm Hospital.jar IT RBuilder Analyzer Alarm Ambulatory.jar IT RBuilder Analyzer Alarm Doctor.jar
connectivity constraints. For instance, an optimal solution is computed in which four test nodes4
are chosen : the local home server, the hospital computer, the remote server and the nurse PDA. Then, the selected test cases are distributed over these four nodes. Notice that this solution may change especially when we vary the node provided resources and the network connectivity. As mentioned before, affected components as well as their main characteristics (e.g., required and provided interfaces, testability options, etc.), their associated test components and their deployment hosts are included in the RATP file. Figure 7.4 shows a screenshot of this file and describes mainly the new Alarm component and its main features. Especially, it pinpoints the deployment host where the Alarm unit test case will be run on (i.e., the host having 192.168.2.102 as IP address).
Figure 7.4: Screenshot of the RATP XML file content.
The RATP file is used in the next step that copes with the test isolation and execution. Indeed, the preparation of the test isolation layer is done in accordance with the testability options of each component under test. In the current scenario, we have different components with various testability features. The Report Builder is testable and it is equipped with a test interface ensuring that the test data and the business data are not mixed during the runtime testing process. The other components involved in this test process are considered test aware.
4
7.4 Checking TRMCS correctness after structural adaptations 105
This means that they differentiate between test data and business data by using a test tag.
ptc_Al_Nu MTC_RB_An_Al_Nu ptc_An_Al_Nu TT4RT Business data Test data ptc_RB_An_Al_Nu
Main Test Component Parallel Test Component Component under test
Legend Nurse Help Center Service Analysis Service Report Test Interface ptc_Nu Alarm 2 Help Service SUT Analyzer Report Builder Hospital Ambulatory Ambulatory
Figure 7.5: An example of interactions between TTCN-3 test components and SUT.
Figure 7.5 sketches interactions between the SUT and our test system TT4RT when an executable test IT RBuilder Analyzer Alarm Nurse.jar is loaded and performed at runtime. Based on the bottom up integration testing strategy, the lowest level in the dependence path is tested first (e.g., Nurse) then components that rely on it are tested. For this aim, different PTC components playing the role of test drivers (e.g., ptc Nu, ptc Al Nu, etc.) are created in each test case. They perform this integration test under the control of an MTC component called MTC RB An Al Nu.
1 testcase t c _ R B _ A n _ A l _ N u () runs on m t c T y p e system s y s t e m T y p e { 2 var p t c T y p e 2 ptc_Nu , p t c _ A l _ N u , p t c _ A n _ A l _ N u , p t c _ R B _ A n _ A l _ N u ; 3 // create the PTCs
4 p t c _ N u := p t c T y p e .create(" p t c _ N u "); 5 //map the PTCs to the system port
6 map( p t c _ N u : ptcPort , system: s y s t e m P o r t ); 7 //start the PTC’s behaviour
8 p t c _ N u .start( p t c B e h a v i o u r _ N u ( ) ) ; p t c _ N u .done; 9 p t c _ A l _ N u := p t c T y p e .create(" p t c _ A l _ N u "); 10 ... 11 p t c _ A n _ A l _ N u := p t c T y p e .create(" p t c _ A n _ A l _ N u "); 12 ... 13 p t c _ R B _ A n _ A l _ N u := p t c T y p e .create(" p t c _ R B _ A n _ A l _ N u "); 14 ... }
Listing 7.5: The test configuration in TTCN-3 notation.
Listing 7.5 outlines how to specify this test configuration with the TTCN-3 notation. Each involved PTC is created and then its test behavior is started. For instance, line 4 outlines the creation of the test component ptc Nu charged with testing of the Nurse component (see line 8). The PTC behavior (ptcBeahavior Nu()) is a TTCN-3 function similar to the one previously