Testing , Monitoring, and Controlling CORBAbased Applications

1
Testing , Monitoring, and Controlling
CORBA-based Applications

• Sudipto Ghosh
• Priya Govindarajan
• Aditya P. Mathur
• Baskar Sridharan
• Software Engineering Research Center
• Purdue University
• _at_ British Telecom, UK
• Monday, July 12, 1999

2
Structure of a CORBA Application
Component
Component
Orb
Orb
Communication over network or within a process..
3
Needs of a tester

• Test Adequacy
• Goodness of system test.
• Parts of the system that need additional testing.

4
Needs of a tester

• System behavior
• Visualization of system state transition in the
  presence of a given input sequence.
• Visualization of system state transition in the
  presence of injected faults.

5
Needs of a tester

• System performance
• Measurement of instantaneous and average load
  distribution (Hardware and Software).
• Measurement of instantaneous and average response
  time.

6
Needs of a tester

• System control
• Temporary or permanent shut down of selected
  services.
• Injection of an arbitrary stream of requests
  directed at selected servers.

7
How TDS meets a testers needs?

• Test adequacy
• By measuring interface-based coverage
• Method coverage
• Exception coverage
• iMutation Coverage

8
Monitoring Sample Questions

• State related
• What is the current state of component C?
• Performance related
• What is the average round-trip time of a message
  sent to component C ?
• Access related
• Did client C access component C during the past
  24 hours ?

9
Control Sample Commands

• Component related
• Deny a set of services to some or all clients of
  component C upon the occurrence of event E
• start component C
• replicate component C
• send message m to component C

10
Proposed Test Adequacy Criteria
Test Adequacy Criteria
100 Method Coverage methods executed methods
defined
Methods m1, m2, ,mk
100 iMutation Score distinguished
mutants total imutants - equivalent imutants
Exceptions e1, e2, ,ek
Interface
100 Exception Coverage exceptions raised
exceptions defined
Component
11
Proposed iMutant Operators

• Replace inout by out and vice versa
• Swap parameters of the same type
• Increment/decrement parameter by 1
• Set parameter to a value (boundary value)
• Nullify an object reference

12
Test Adequacy Criteria during Integration
Application
Component Ci Errors present
Ei Adequacy Criterion ACi Test Set
Ti Revealed errors ei
Adequacy Criterion AC ?ACi Test set T Errors
revealed eA
eC ?ei
Application
Are eC and eA statistically the same?
13
Methodology for Testing Applications
1. Test each component separately
2. Test the entire system

• What adequacy criteria to use?
• Only AC1
• OR
• Both AC1 and AC2

Client
AC1
AC2
Traditional Test Adequacy Criteria for Client
Interface-based Test Adequacy Criteria for each
server component
14
Experiments Testing Components

• How do the proposed test adequacy criteria
  compare with the traditional criteria?

Seeded Errors
Magellan Component
Interface
Hypothesis E1 E2
15
Experiments Testing Applications

• How do the two criteria compare?

Magellan System
(E1 ? E2) (?T1? ??T2?)
16
Experiments System to be Tested

• Application
• Multi-layer infrastructure for building
  help-desk applications.
• Statistics for one layer
• Approx. Lines of code 80K
• Number of IDL files 16
• Number of methods 150
• Number of exceptions 7
• Number of .exe files 37
• Number of interfaces 24

17
Monitoring Strategy
notifies
Waiting user
Event notification
18
Control Strategy
specifies
User
Control action(s), trigger event(s)
executes
Controller
Control action(s)
19
States

• Local
• S an arbitrary state. S could be
• Component C processing request R
• Component C is inactive
• Component C is active

20
Events

• Local
• E an arbitrary event. E could be
• Component C assumes state S
• E after time T (T local time)
• E during interval T1, T2
• E1 or E2
• E1, E2 (sequence)

21
How TDS meets a testers needs?

• System test
• By allowing the tester to combine features for
  (V2.0)
• test adequacy measurement
• system performance measurement
• system behavior monitoring
• system control

22
An Example
Two Servers - Bank_Srv and TM_Srv
Bank_Srv interface account readonly
attribute float balance void makeLodgement
(in float f) void makeWithdrawal (in float
f) interface bank exception
reject string reason account newAccount
(in string name) raises (reject) void
deleteAccount (in account a)
TM_Srv interface transaction int
verifyTransaction (in account)
23
Goal

• To Monitor and Control object B1.
• B1 implements interface Bank
• Construct event E Arrival of request
  createAccount() to object B1
• Monitor E
• Specify control operation Ignore all incoming
  requests on object B1

24
TDS 2.0 Architecture for Monitoring and Control
25
DATABASE
Global Listener
Host 1
Host 2
Host 3
Local Listener
Request
deleteAccount (acc)
Response
26
TDS 2.0 Event Specification and Registration
27
DATABASE
Global Listener
Host 1
Host 2
Host 3
Local Listener
TDS
SR
28
TDS 2.0 Event Monitoring and Notification
29
DATABASE
Global Listener
Host 1
Host 2
Host 3
Local Listener
TDS
SR1
30
TDS 2.0 Specification and Application of
a Control Operation
31
DATABASE
Global Listener
Host 1
Host 2
Host 3
Local Listener
TDS
SR1
32
Summary

• TDS 1.1 demonstrated in May 99.
• Experiments with a system from Tivoli begun in
  May 99.
• Implementation of the Monitoring and Control
  component begun in June 99.
• Implementation of the Architecture-Extraction
  component begins in August 99..

33
Operation Sequence in the Example

• Listener and Controller are instantiated on
  Host1
• Listener sends information about its presence to
  Global Listener
• Global Listener pushes information to database
• Server Bank_Srv is activated on Host1
• Data Initializer (DI) sends information about
  Bank_Srv to Local Listener (Host1)
• Listener Sends information to database
• Global Listener pushes information to database
• Listener and Controller are instantiated on
  Host2
• Listener(Host2) sends information about its
  presence to Global Listener
• Global Listener pushes information to database

34
Operation Sequence in the Example

• Listener and Controller are instantiated on
  Host2
• Listener sends information about its presence to
  Global Listener
• Global Listener pushes information to database
• Server TM_Srv is activated on Host2
• Data Initializer (DI) sends information about
  TM_Srv to Local Listener (Host2)
• Listener Sends information to database
• Global Listener pushes information to database
• Listener instantiated on Host3
• Listener(Host3) sends information about its
  presence to Global Listener
• Global Listener pushes information to database

35
Operation Sequence in the Example

• Client instantiated on Host3
• Client issues deleteAccount(acc) on object B1
• Request reaches Client Monitor
• Client Monitor sends request-information to
  Listener (Host3)
• Listener sends request-information to Global
  Listener
• Global Listener pushes data to database
• Listener returns success value to Client
  Monitor
• Client Monitor sends request to Bank_Srv
• Request reaches Server Monitor
• Server Monitor sends request-information to
  Listener (Host1)
• Listener sends information to Global Listener
• Listener sends success return value to Server
  Monitor

36
Operation Sequence in the Example

• Server Monitor sends request-information to
  Controller
• Controller processes request-information and
  sends success return value
• Server Monitor passes the request to object B1
  (which implements interface Bank)
• Object B1 issues verifyAccount(acc) request on
  object TM
• Request traverses identical path (as from
  client)
• Object B1 receives response from TM
• The response from B1 reaches Client