This document discusses object-oriented testing methodologies. It provides an overview of the Rumbaugh, Booch, and Jacobson object-oriented design methodologies. It also covers patterns, frameworks, the unified approach to modeling using UML, and various testing strategies like unit testing, integration testing, and validation testing. Quality assurance testing includes debugging, stress testing, and performance testing. Object-oriented concepts like inheritance can impact testing by making some errors less likely while introducing new types of errors. Guidelines for developing test cases include describing the feature under test and testing normal and abnormal use cases.

1. UNIT V TESTING
Presented By R.Krishna Prakash,
Assistant Professor/CSE,
Kongunadu College Of Engineering And
Technology.
KONGUNADU COLLEGE OF
ENGINEERING AND TECHNOLOGY
(AUTONOMOUS)

2. UNIT V TESTING

3. Testing
 Object Oriented Methodology Methodolgies
 The Rumbaugh OMT
 The Booch methodology
 Jacobson’s Methodologies
 Patterns (Very Important)
 Frameworks
 Unified Approach (UA)

4. Object- Oriented Methodology
Object- Oriented Methodology is a set of
Methods
Models
Rules
For developing the system.
Modeling provides a means for conceptualizing
and communicating ideas in a precise, easy to
understand and unambiguous form.

5. SURVEY OF SOME OF THE O-O METHODOLOGIES
Rumbaugh method is well suited for describing
the object model or the static structure of the
system and dynamic model.
The Jacobson method is good for producing
user-driven analysis models.
The Booch method produces detailed object-
oriented design models.

6. RUMBAUGH OBJECT MODELING TECHNIQUE (OMT)
OMT represented describe a method for the
analysis, design, and implementation of a system
using an o-o technique.
OMT is fast, intuitive approach for identifying &
modeling all objects making up the systems.
OMT consists of :
Static(Object), Dynamic(State transistion) and
Functional(Process description & consumer-
producer) models.

7. RUMBAUGH OBJECT MODELING TECHNIQUE (OMT)
contd..
OMT consists of 4 phases:
1. Analysis: The results are objects dynamic & functional
models.
2. System design: Basic architecture & high level strategy of
the system.
3. Object design: Design document produced containing
object static, dynamic and functional model.
4. Implementation: Reusable, extendible & robust code

8. RUMBAUGH OBJECT MODELING TECHNIQUE (OMT)
contd..
OMT separates modeling into three parts:
1. Object model: Presented by the object model and data
dictionary.(Class diagrams)
2. Dynamic model: presented by the state transition diagrams,
and event flow diagrams.
3. Functional model: presented by data flow and constraints.
(DFD)

9. RUMBAUGH CLASS NOTATIONS

10. RUMBAUGH FUNCTIONAL MODEL

11. THE BOOCH METHODOLOGY
its used Object oriented methods to design systems using
object model.
Booch method consists of :
 Class Diagrams
Object Diagrams
State Transition Diagrams
Module Diagrams
Process Diagrams
Interaction Diagrams

12. THE BOOCH METHODOLOGY contd..
Booch methodology consist of Macro and Micro
development process
Macro development process: It serves as a controlling
framework for micro process consists of:
- conceptualization(action or process)
- analysis and development of the model
- design or create the system architecture
- evolution or implementation
- maintenance

13. THE BOOCH METHODOLOGY contd..
Each macro development process has its own micro
development processes.
Micro process is a day-to-day activities
Micro development process consists of :
- identify classes and objects
- identify class and object semantics
- identify class and object relationships
- identify class and object interfaces and
implementation

14. BOOCH NOTATIONS for CLASS

15. BOOCH NOTATIONS

16. THE JACOBSON ET AL. METHODOLOGY
This methodologies covers the entire life cycle and stress
traceability between the different phases both forward &
backward. It consists of:
OOBE (O-O Business Engineering)
OOSE (O-O Software Engineering) also called:
OBJECTORY (Object Factory for Software Development)

17. THE JACOBSON ET AL. METHODOLOGY contd..
O-O Business Engineering
OOBE is object modeling at the enterprise level. (Use case
are also central here)
OOBE consists of :
Analysis phase
Design & Implementation phases
Testing phase: Unit, integration & system testing.

18. THE JACOBSON ET AL. METHODOLOGY contd..
O-O Software Engineering: Objectory
OOSE also called objectory is a method of O-O development
with the specific aim to fit the development of large, real
time systems.
The development process is called use-case driven process.
Used across:
Analysis, Design, Validation & Testing

19. THE JACOBSON ET AL. METHODOLOGY contd..
Concept of use-case
- scenarios for understanding the system requirements
- is an interaction between user and system
- captures the goal of the user and responsibility of the
system to its users

20. THE JACOBSON ET AL. METHODOLOGY contd..

21. THE JACOBSON ET AL. METHODOLOGY contd..
Objectory is built around several different models such as:
Use-case model- outside and inside of system
Domain Object model: The object of the real world are
mapped into the domain object model.
Analysis Object model: It presents how the source
code(implementation) should be carried out and written.
Implementation model: implement of system
Test model: It includes the test plans, specifications, and
reports.

22. PATTERNS
It solves a problem.
It is a proven concept.
The solution is clear
It describes a relationship. (i.e system
structure & mechanism)

23. PATTERNS contd..
Patterns are used for :
Software architecture & design
Organization
Specification models
Software development process
Project planning
Requirements engineering
Software configuration management

24. GENERATIVE & NON GENERATIVE PATTERNS
Types of patterns are:
Generative Patterns: That only describe a recurring problem.
It tells how to generate something and can be observed
in the resulting system architectures they help shape.
Nongenerative patterns are static and passive: They describe
recurring event without necessarily saying how to reproduce
them.
Most of the patterns are generative.

25. PATTERNS TEMPLATE
Patterns Template:
Name: A meaningful pattern name.
Problem: A statement of the problem.
Context: It give problem and solution
seem to repeatedly. and for which
solution is attractive.
Forces: Relevant forces & constraints
under which the system has to work.

26. PATTERNS TEMPLATE contd..
Solutions: Static relationships &
dynamic rules describing how to
realize the desired outcome.
Examples: Sample application of
pattern.
Resulting context: configuration of
the system after the pattern has
been applied.

27. PATTERNS TEMPLATE contd..
Rationale: A justifying explanation of steps
or rules in the pattern.
Related patterns: The static & dynamic
relationship between this pattern and others.
Known uses: The known occurrences of the
patterns and its application within existing
system.

28. How Patterns-A Summary
Problem
Solution
Benefits
Related Patterns
result
Forces

29. Frame works
Its way of delivering application development patterns
to support practice sharing during application
development.
The major differences between design patterns and
frameworks as follows
Design patterns are more abstract than frameworks.
Design patterns are smaller architectural elements than
frameworks.
Design patterns are less specialized than frameworks

30. Unified approach
Uml modeling
Unified Modeling approach is used for modeling
Object oriented analysis
Object oriented design
Testing
Layered approach

31. Object oriented analysis
Identify actors.
Develop a simple process model.
Develop the use case.
Develop interaction diagrams.
Identify classes.

32. Object oriented design
◦ Design classes, attributes, methods etc.
◦ Design the access layer.
◦ Design the prototype user interface.
◦ User satisfaction and usability tests.
◦ Iterate and refine the design.

33. Layered approach
The business layer
Displaying results.
Data access details
The user interface or view layer
Responding to user interaction

34. Quality assurance tests
Debugging-the process of identifying and removing
errors from computer hardware or software.
A software has three types of errors such as
1.Language (syntax) errors (incorrectly constructed
code)
2.Run–time errors (detected as the program is running)
3.Logic errors (Expected output is not published)

36. Testing Strategies
Unit Testing
Integration Testing
Validation Testing
System Testing

37. Contin…
Integration Testing - individual units are
combined and tested as a group
Top down Testing- In this approach testing is
conducted from main module to sub module.
 Bottom up testing-In this approach testing is
conducted from sub module to main module
Regression testing- is a type of software testing
(enhancements or defect fixes) to the software
have not adversely affected it

38. Contin…
Validation testing – software assembled as a package
Alpha test- its controlled by developer site.
Beta test- one or more sites
System testing- function
Recovery testing
Security testing – protection in your system
Stress testing – resources are abnormal
Performance testing – test in run time performance
of software

39. IMPACT OF OBJECT ORIENTATION ON TESTING
Some types of errors could become less
reasonable
Some types of errors could become more
reasonable
Some new types of errors might appear

40. IMPACT OF OBJECT ORIENTATION ON TESTING
Impact of Inheritance in Testing:
 The base class contains methods inherited() and
redefined ()
Derived class redefines the redefined() method
The derived ::redefined has to be tested different
way since it is a new code.
If the base:: inherited has been changed, the
derived:: inherited() may not have to be
completely tested.

41. Reusability of tests
If base::redefined() and derived::redefined() are
two different methods with different protocols
and implementations,
Each needs a different set of test requirements
derived from use cases, analysis, design or
implementation.

42. DEVELOP TEST CASES AND TEST PLANS
Testing is process of executing a program with
the intent of finding errors
A good test case is one that has a high
probability of detecting undiscovered error
A successful test case is one that detects as
undiscovered error

43. Guidelines for developing Quality Assurance Test Cases
Describe which feature or service (external of
internal), test attempts to cover
If test case is based on use case
what to test on which method along with test
feature
Test normal use of the object’s methods
Test abnormal but reasonable use of the object’s
methods
Test boundary conditions of number of
parameters

44. Object-oriented Testing Methods