The document discusses object-oriented testing strategies and techniques. It covers unit testing of individual classes, integration testing of groups of classes, validation testing against requirements, and system testing. Interclass testing focuses on testing collaborations between classes during integration. Test cases should uniquely identify the class under test, state the test purpose and steps, and list expected states, messages, exceptions, and external dependencies.

1. T.Y. B.Sc. (Comp. Sci.) Sem I
Object Oriented Software Engineering
(OOSE)
CS-336
Faculty
Dr. Amit D. Kasliwal
Asst. Professor

2. Chapter 9
Object Oriented Testing
Objective
 Object Oriented Testing Strategies
 Test Case Design for Object Oriented Software
 Inter Class Test Case Design

3. Object Oriented Testing
 Testing is the process of exercising a program with the
specific intent of finding errors prior to delivery to the end
user.
 The objective of testing is to find the greatest possible
number of errors with a manageable amount of effort
applied over a realistic time span.
 Although this fundamental objective remains unchanged
for object-oriented software, the nature of OO programs
changes both testing strategy and testing tactics.

4. Testing Shows
Object Oriented Testing

5.  All software testing strategies provide a template for
testing and all have the following generic characteristics:
 Conduct effective formal technique reviews, by doing this,
many errors will be eliminated before testing commences.
 Testing begins at the component level and works “outward”
towards the integration of the entire computer-based system.
 Different testing techniques are appropriate at different points
in time.
 Testing is conducted by the developer of the software and
an independent test group.
Object Oriented Testing

6. Who Tests the Software?

7. Verification and Validation
 Verification refers to the set of activities that ensure that
product correctly implements a specific function.
 Validation refers to the set of activities that ensure that the
product has been built is traceable to customer
requirements.
 Verification: Are we building the product right?
 Validation: Are we building the right product?
 The definition of Verification and Validation encompasses
many of the activities that are encompassed by software
quality assurance (SQA).

8. Test Case
 A test case is a document, which has a set of test data,
preconditions, expected results and post conditions, developed
for a particular test scenario in order to verify compliance
against a specific requirement.
 Test Case acts as the starting point for the test execution, and
after applying a set of input values, the application has
 a definitive outcome and leaves the system at some end point
or also known as execution post condition.
 Typical Test Case Parameters are Test Case ID, Test Scenario,
Test Case Description, Test Steps, Prerequisite, Test Data,
Expected Result, Test Parameters, Actual Result, Environment
Information, Comments.

9. Test Case
Scenario Test Step Expected Result Actual Outcome
Verify that the input
field that can accept
maximum of 10
characters
Login to application and
key in 10 characters
Application should be
able to accept all 10
characters.
Application accepts all
10 characters.
Verify that the input
field that can accept
maximum of 11
characters
Login to application and
key in 11 characters
Application should NOT
accept all 11 characters.
Application accepts all
10 characters.

10. Organizing for Software Testing
 There are often a number of misconceptions that can be
erroneously inferred for testing:
 That the developer of project shouldn’t test.
 That the software project should be tossed over the wall
to strangers who will test it mercilessly
 That testers get involved only when testing steps are
about to begin.
 These aforementioned statements are incorrect.

11. Testing Strategies

12. Testing Strategies
Unit Testing : It is a level of software testing where individual
units/ components of a software are tested.
 A unit is the smallest testable part of any software. Usually
has one or a few inputs and usually a single output.
 The purpose is to validate that each unit of the software
performs as designed.
 An encapsulated class is the focus of unit testing.
 However, operations within the class and the state behavior of
the class are the smallest testable units.
 Class testing for object oriented software is analogous to
module testing for conventional software. It is not advisable
to test operations in isolation.

13. Black Box Testing is a software testing method in which the
internal structure/ design/ implementation of the item being
tested is not known to the tester.
 This testing can be initiated on the basis of requirement
specifications document.
White Box Testing is a software testing method in which the
internal structure/ design/ implementation of the item being
tested is known to the tester.
 This type of testing of software is started after detail design
document.
Testing Strategies

14. Testing Strategies
Integration Testing : It is a level of software testing where
individual units are combined and tested as a group.
 It is to expose faults in the interaction between integrated
units.
 Test drivers and test stubs are used to assist in Integration
Testing.
 An important strategy for integration testing of object
oriented software is thread-based testing.

15. Integration Testing
 Thread-based testing integrates the set of classes required to
respond to one input or event for the system. Each thread
is integrated and tested individually.
 Use-Based testing begins the construction of the system by
testing those classes (called independent classes) that use
very few server (if any) classes. Dependent classes, which
use independent classes, are tested.
 This sequence of testing layers of dependent classes
continues until the entire system is constructed.
 Cluster testing is one-step in the integration testing process.
 A cluster of collaborating classes is exercised by designing
test cases that attempt to uncover errors in the
collaborations.
Testing Strategies

16. Validation Testing : It is described as the last chance to catch
program errors before delivery to the customer.
 If the users are not happy with what they see, the
developers often do not get paid.
 The key point to emphasize is traceability to requirements.
In addition, the importance of alpha and beta testing (in
product environments) should be stressed.
 Validation Test Criteria: Focus is on software requirements.
A test plan outlines the classes of tests to be conducted, and
a test procedure defines specific test cases.
Testing Strategies

17. Alpha/Beta testing: This strategy focuses on customer usage.
 Alpha tests are conducted in a controlled environment and
conducted at the developer’s site by end-users.
 The s/w is used in natural setting with the developer with users,
recording errors and usage problems.
 The beta-test is conducted at the end-users sites where developer
is generally not present.
 Beta test is a live application of the software in an environment
that cannot be controlled by the developer.
 The end-user records errors and all usage problems encountered
during the test and the list is reported to the developer.
 And then modifications is done to prepare for release of product
to the entire customer base.
Testing Strategies

18. System Testing : The focus is on system integration.
 System Testing is a series of different tests whose primary
purpose it to fully exercise the computer-based system.
 Following are the types of system tests:
 Recovery Testing : Forces the software to fail in a variety of ways
and verifies that recovery is properly performed for data
recovery.
 Security Testing : It verifies that protection mechanisms built
into a system will, in fact, protect it from improper penetration.
 The system’s security must, of course, be tested for
invulnerability from frontal attack-but must also be tested for
invulnerability from flank or rear attack.
Testing Strategies

19. Stress Testing : It executes a system in a manner that demands
resources in abnormal quantity, frequency, or volume. For
example:
 Special tests may be designed to generate 10 interrupts per
second, when one or two is the average rate.
 Test cases that require maximum memory or other resources are
executed,
 Test cases causing memory management problems are designed.
 Test cases that may cause excessive hunting for disk-resident
data are created.
 A variation of stress testing is a technique called sensitivity
testing. They attempt to uncover data combinations within valid
input classes that may cause instability or improper processing.
Testing Strategies

20. Performance Testing : It tests the run-time performance of
software within the context of an integrated system.
 Performance tests are coupled with stress testing and
usually require both hardware & software instrumentation.
Documentation Testing involves testing of the documented
artifacts that are usually developed before or during the
testing of Software.
 Documentation for Software testing helps in estimating the
testing effort required, test coverage, requirement
tracking/tracing, etc.
Testing Strategies

21. Test Case Design for OO Software
 An approach to OO test case design has been defined by :
1. Each test case should be uniquely identified and explicitly
associated with the class to be tested.
2. The purpose of the test should be stated.
 Steps should be developed for each test and should contain:
 A list of specified states for the object that is to be tested.
 A list of messages and operations that will be exercised as a
consequence of the test.
 A list of exceptions that may occur as the object is tested.
 A list of external that must exist in order to properly conduct
the test.
 Supplementary information that will aid in understanding or
implementing the test.

22. Interclass Test Case Design
 Test case design becomes more complicated as integration
of the OO system begins. It is at this stage that testing of
collaborations between classes must begin.
 Inter class testing is the testing of a set of classes composing
a system or subsystem, usually performed during
integration.
 Typically, such classes are not stand-alone entities, but
mutually cooperate in several ways.
 These relationships among classes are a fundamental
characteristic of object-oriented systems and define the
nature of the interactions among objects at runtime.

23. The figure shows banking process including the classes and collaborations
to illustrate interclass test case .

24. Interclass Test Case Design
 Following are the steps to generate multiple inner class random
test cases:
 For each client class, use the list of class operations to generate a
series of random test sequences. The operations will send
messages to other server classes.
 For each message that is generated, determine the collaborator
class and the corresponding operation in the server object.
 For each operation in the server object (that has been invoked by
messages sent from the client object), determine the messages
that it transmits.
 For each of the messages, determine the next level of operations
that are invoked and incorporate these into the test sequence.

25. To illustrate above, consider a sequence of operations for the bank class
relative to an ATM class as shown in above figure: