ajeng.savitri@teknokrat.ac.id https://teknokrat.ac.id/en/

1. MEETING 8
OBJECT-ORIENTED TESTING
SOFTWARE TESTING
By : Ajeng Savitri Puspaningrum, M.Kom

2. OBJECTIVE
• Learning Object-Oriented
Testing

3. Introduction

4. 4
INTRODUCTION
• When object-oriented software is considered,
the concept of the unit changes.
• Encapsulation drives the definition of classes
and objects.
• An encapsulated class is usually the focus of
unit testing

5. 5
THE OBJECT-ORIENTED TESTING
• The component being tested is class-
object.
• Larger than testing a function so the
white-box testing approach needs to be
expanded.
• Unclear 'top' of a system for top-down
integration and testing

6. 6
OBJECT-ORIENTED TESTING VS OTHER
• The most notable differences of object-oriented testing concern the
phases of module and system testing
• Due to modularization, there are more intraprocedural interdependencies.
• Sharing of class members (fields) might couple methods of classes that are
not meant to or at least do not appear to share data.
• Programming for reusability and a more generalized functionality of classes
introduces more possibilities to test them.
• There is no linear growth between the size of the class and its complexity.
• Code instrumentation is more complex.
• Modularization, inheritance, and polymorphism have to be given special care.

7. 7
HOW TO TEST THE OO-SYSTEM
• Three things to consider when testing an OO
system
• The definition of testing should be expanded to
include error finding techniques applied to the
OOA(Object Oriented Analysis) and OOD(Object
Oriented Design) models.
• The unit testing strategy will become less meaningful
and the integration strategy will have to change
significantly
• Test case design must account for the unique
characteristics of OO software

8. 8
THE ACTIVITIES
• Reviewing the OOA and OOD models
• Class Test after writing source program
• Integration Test in subsystems
• Integration Test of subsystems that have been
added to the system
• Validation Test based on OOA use-cases
OOA and OOD cannot be tested but can be
reviewed for correctness and consistency

9. 9
CORRECTNESS
• Syntactic
• Defined by ensuring that modeling
requirements and symbolism conventions are
used
• Semantics
• Based on the accuracy of the model with
real-world problem sources

10. 10
CONSISTENCY
1. Review the CRC (class-responsibility-
collaborator) model and the
relationship diagram between
objects.
2. Review system design (check object
behavior model to check system
behavior mapping to subsystems,
review concurrency and task
allocation, use use-case scenarios to
check user interface design)

11. 11
3. Object model test against object
relation network to ensure that all
object designs contains the attributes
and operations required to carry out
the collaboration defined for each CRC
card.
4. Check the detailed specification of the
algorithm used to carry out
conventional operations using
inspection techniques
CONSISTENCY (CONT…)

12. Object-Oriented
Testing
Strategies

13. 13
UNIT TESTING IN OBJECT-ORIENTED
• Concept of unit change
• Smallest unit testable is encapsulated class
or object
• One operation can no longer be tested in
isolation (conventional view of unit testing)
but rather as part of a class
• Does not test operations in isolation with
other operations
• Executed by class operations and fixed
behavior, not algorithmic details and data
flow across module interfaces

14. 14
UNIT TESTING IN OBJECT-ORIENTED( C O NT … )
• Each of these methods will train an
operation encapsulated by the class
• The test sequence is designed to ensure
that the relevant operations are tested
• The fixed position of a class (its attribute
value) is tested to determine if there are
errors

15. 15
TESTING ACTIVITIES
• Test all operations related to
objects
• Manage and interrogate all object
attributes
• Train objects in all possibilities

16. 16
TESTING DESIGN
• Fault-based testing
• Random testing
• Partition testing

17. 17
INTEGRATION TEST IN OBJECT-ORIENTED
• Focused on classroom groups that
collaborate or communicate in some
way.
• The integration of operations one by
one into the class is often futile
• Fewer different levels of integration in
object-oriented systems

18. 18
TESTING DESIGN
• Thread-based testing integrates the set of classes required to respond
to a single input or event for the system
• Use-based testing starts the system building by testing those classes
(called independent classes) that use very few (if any) server classes.
After independent classes are tested, the next layer of classes, called
dependent classes
• Cluster testing defines a group of collaborating classes (determined
by examining CRC and object-relationship models) carried out by
designing test cases that seek to uncover errors in collaboration.

19. 19
VALIDATION TESTING IN OBJECT-ORIENTED
• Class connection details disappear
• Describe use cases that are part of the
requirements model
• Focuses on visible user actions and users can
recognize the output of the system
• Validation tests are based on use-case
scenarios, object behavior models, and
event flowcharts created in the OOA model
• Conventional black box testing can be used
to drive validation tests

20. Object-Oriented
Testing
Method

21. 21
APPROACH
• Each test case must be uniquely
identified and must be explicitly
associated with the class to be tested,
• The purpose of the test should be stated,
• Write down the test steps for each
included test

22. 22
TESTING STEPS
• A list of test steps should be developed for each test and should
contain:
• List of states specified for the object to be tested
• List of messages and operations to be performed as a consequence of testing
• List of exceptions that can occur when the object is tested
• List of external conditions (eg, environmental changes outside of the software
that must be present in order to properly perform the test)
• Additional information that will assist in understanding or carrying out the
test.

23. 23
TESTING SURFACE STRUCTURE
AND DEEP STRUCTURE
• Testing a surface structure
• Is training a structure visible to the end
user, often involving observing and
interviewing users as they manipulate
system objects.
• Testing deep structure
• Is training internal program structures, such
as dependencies, behaviors, and
communication mechanisms that exist as
part of system and object design.

24. 24
CLASS TESTING
• Class testing for object-oriented (OO)
software is the equivalent of unit testing
for conventional software.
• Driven by the operations encapsulated by
the class and the state behavior of the
class.
• Method :
• Random Testing
• Partition testing
• Fault-based testing

25. 25
RANDOM TESTING
• Requires a large number of permutations and
combinations of data, and can be inefficient
• Identify the operations that apply to a class
• Define constraints on their use
• Identify the minimum test sequence
• Operations Sequence that define the minimum
life history of a class (object)
• Generate various random (but valid) test
sequences
• Other class example life history exercises (more
complex)

26. 26
PARTITION TESTING
• Eliminates the number of test cases needed to test a
class
• State-based partitioning : tests are designed in such a way
that operations that cause state changes are tested
separately from those that do not.
• Attribute-based partitioning : for each class attribute,
operations are classified based on the user of the attribute,
which modifies the attribute and which does not use or
modify the attribute
• Category-based partitioning : operations are categorized
based on the function they perform, such as: initialization,
computing, querying, termination

27. 27
FAULT-BASED TESTING
• Best for operations and class levels
• Using inheritance structures
• Testing examines the OOA model and
hypothesizes a set of understood crashes
that might occur in operation calls and
message connections, and builds appropriate
test cases
• Finds incorrect specifications and errors in
subsystem interactions

28. 28
INTER-CLASS TESTING
• Test case design becomes more complicated as does integration from
the start of the OO system – testing collaboration between classes
• Various class test, such as:
• For each client class uses a class operator list to generate a sequence of
random tests that send messages to the same server class else
• For each message generated, specify the collaborator class and the
designated server object operator
• For each server operator class (requested by a message from the client
object) specify the message sent
• For each message, determine the next operator level requesting and
combining them into the trial order

29. 29
TEST DESIGN
• Tests generated from behavioral models
• Use a state transition diagram (STD) as a model that
represents the dynamic behavior of a class.
• Test cases should cover all stages of STD
• Breadth first traversal of usable state models (test
one transition at a time and only make use of
previously tested transitions when testing new
transitions)
• Test cases can also be generated to ensure that all
behavior for the class has been tested properly
• Methods :
• Cluster Testing
• Use Case/Scenario-based Testing

30. 30
CLUSTER TESTING
• Focuses on integrating and testing groups
of objects that work together
• Identifying groups by using knowledge of
the operation of objects and having
systems implemented by these groups.

31. 31
CLUSTER TESTING APPROACH
• Use-case or scenario testing
• Testing is based on user interaction with the system
• Has the advantage that system testing features as experienced by users.
• Thread testing : tests the response of the system to events as the
thread processing through the system
• Object interaction testing : tests the sequence of object interactions
that stop when an object's operation does not call the service of
another object

32. 32
USE CASE/SCENARIO-BASED TESTING
• Based on use-case and corresponding sequence
diagram
• Identify scenarios of use-cases and add to these with
interaction diagrams showing the objects included in
scenario
• A scenario is a path through a sequence diagram
• Concentrate on requirements (functional):
• Every use case
• Every expansion combination full extension (<<extend>>)
• Every expansion of the full usage combination (<<uses>>)
• Normal test like behavior

33. 33
USE CASE/SCENARIO-BASED TESTING(CONT…)
• Many different scenarios can be linked by a
sequence diagram
• Use the user tasks described in the use-cases and
build test cases from these tasks and their variations
• Find errors that arise when users interact with OO
software
• Concentrate on what the function does, not what
the product does
• Can get a greater return on the effort and time spent
reviewing use-cases since they were created, than
on wasting time on test use-cases

34. 34
OO TEST DESIGN ISSUES
• The white-box testing method can be applied to
program usability testing to implement class operations
but not to others
• The black-box testing method is very appropriate for
testing OO systems
• Object-oriented programming creates additional
requirements for testing, in the form of:
• Classes can contains operations derived from super classes
• Subclasses can contain operations that are redefined rather
than derived
• All classes generated from testing of previous base classes
require further testing

35. References
Lewis, W. E. (2009). Software Testing And Continuous Quality
Improvement ed. 3rd. Auerbach publications.
02
Majchrzak, T. A. (2012). Improving Software Testing: Technical And
Organizational Developments. Springer Science & Business Media.
03
Myers, G. J., Sandler, C., & Badgett, T. (2012). The Art Of Software
Testing. John Wiley & Sons.
04
Roger, S. P., & Bruce, R. M. (2019). Software Engineering: A
Practitioner’s Approach Ed.9th. McGraw-Hill Education.
01

36. THANK YOU
Insert the Subtitle of Your Presentation