SE 754NT

1
SE 754-NT Object-Oriented Testing and
Reliability Robert Oshana Lecture
20 For more information, please
contact NTU Tape Orders NTU Media
Services [phone]
oshana_at_airmail.net
tapeorders_at_ntu.edu
2
Where we are

• Introduction
• The testing perspective
• Planning for testing
• Testing analysis and design models
• Class testing basics
• Testing interactions
• Testing class hierarchies
• Testing distributed objects
• Testing systems
• Components, frameworks, product lines

3
Testing Distributed Objects

• Chapter 8

4
Basic differences - nondeterminism

• Very difficult to exactly replicate a test run
  when the software contains multiple concurrent
  threads
• Testing approach
• Conduct more thorough testing at the class level
• Execute a large number of test cases while
  attempting to record the order in which events
  occur
• Specify a standard test environment

5
Basic differences - Additional infrastructure

• Many distributed object systems rely on an
  infrastructure provided by a third party
• Versions released over time
• Regression needed to verify
• Reconfiguration of the system can have a
  significant impact
• Must design a set of tests for this as well

6
Basic differences partial failures

• Hardware and/or software failures on one of the
  distributed machines will cause failures in the
  entire app
• Single machines do not have this problem
• Tests must be designed in which failures are
  simulated by removing or disabling network
  connections or by shutting down nodes

7
Basic differences time outs

• Networked systems avoid deadlock by using timers
• Software must be able to perform the correct
  behavior when request is answered as well as when
  it is not
• Tests must be run with a variety of loading
  configurations on the machines in the network

8
Basic differences dynamic nature of the
structure

• Distributed systems built with capability to
  change configuration
• Systems also designed to allow for a variety of
  machines to participate in the network
• Use OATS to select a specific set of tests and
  configurations

9
Threads

• During design the principal tradeoff concerns the
  number of threads
• Increasing can simplify certain algorithms but
  increases the risk of sequencing problems
• Reducing reduces sequencing problems but makes
  software more rigid

10
Threads - synchronization

• When two or more threads access the same location
  in memory, a mechanism is needed to prevent
  interference
• Some languages have keywords to support
• Others have explicit structures

11
The need for synchronization

• Guard clauses in UML state diagrams used to
  specify synchronization
• Synchronization mechanisms designed as classes in
  C
• Monitor object

12
Guard clause
Event(arguments)condition/action
State-A
State-B

• Event significant occurrence that has a location
  in time and space
• triggers the transition
• signals, calls, passing of time, change in state
• Guard condition
• Transition only occurs when guard evaluates to
  true
• Guards of transition exiting one state are
  mutually exclusive

13
Testing that the need is met

• Possible for the developer to misplace or
  incorrectly document the specification for
  synchronization
• Test harness should create multiple thread-based
  test objects
• Each then fires a request against the OUT

14
Path testing in distributed systems

• A path is a set of logically contiguous
  statements that is executed when a specific input
  set is used
• S1
• if (cond1) S2
• Else S3

15
Path testing in distributed systems

• Coverage measured by computing the percentage of
  paths that have been exercised by a test case
• 100 provides complete coverage
• May not detect defects related to the computation
  environment
• Alternative is measuring branches out of
  selection statements

16
Another definition

• Link the place where a variable is given a value
  ( a def) with all those places where the variable
  is used (a use)
• Covering all def-use pairs constitutes complete
  path coverage

17
Distributed system coverage

• SYN-event action that involves the
  synchronization of two threads
• SYN-sequence sequence of SYN-events that will
  occur in a specified order
• Example on next page

18
Activity diagram of multiple threads
19
Types of events in OO that qualify for SYN-events

• Creation and destruction of an object that
  represents a thread
• Creation and destruction of an object that
  encapsulates a thread
• Sending of a message from an object on one thread
  to an object on another thread
• One object controls another by putting it to
  sleep or waking it up

20
Testing the class first

• Tester should trace paths from one of these
  events to another
• Object that has its own thread should receive
  thorough testing as a class before being
  interacted with other objects

21
Selected TimerTester code
22
Thread models

• Write once, run anywhere needs to be Write
  once, run anywhere after testing everywhere!
• Differences in behavior of Java threads among
  operating systems
• Should test on multiple operating systems

23
Life cycle testing

• Test plan for the system should include a test
  run starting from nothing instantiated followed
  by bringing the system up, executing a series of
  actions, and then bringing the system completely
  down

24
Life cycle testing

• Did each of the actions carried out by the system
  complete successfully?
• Were all resources allocated by the system
  released after the system was terminated?
• Can the system be successfully restarted?

25
SE 754-NT Object-Oriented Testing and
Reliability Robert Oshana End of
lecture For more information, please
contact NTU Tape Orders NTU Media
Services [phone]
oshana_at_airmail.net
tapeorders_at_ntu.edu