Chapter 23 Object-Oriented Testing

1

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001

Chapter 23Chapter 23Object-Oriented Object-Oriented

TestingTesting

2


3


Object-Oriented Object-Oriented TestingTesting

begins by evaluating the correctness and begins by evaluating the correctness and consistency of the OOA and OOD modelsconsistency of the OOA and OOD models

testing strategy changestesting strategy changes the concept of the ‘unit’ broadens due to the concept of the ‘unit’ broadens due to

encapsulationencapsulation integration focuses on classes and their execution integration focuses on classes and their execution

across a ‘thread’ or in the context of a usage across a ‘thread’ or in the context of a usage scenarioscenario

validation uses conventional black box methodsvalidation uses conventional black box methods

test case design draws on conventional test case design draws on conventional methods, but also encompasses special methods, but also encompasses special featuresfeatures

4


Testing OOA and OOD Testing OOA and OOD ModelModel

Correctness of OOA and OOD ModelsCorrectness of OOA and OOD ModelsThe notation and syntax used to represent analysis and The notation and syntax used to represent analysis and

design models will be tied to the specific analysis and design models will be tied to the specific analysis and design method that is chosen for the project. design method that is chosen for the project.

Hence, syntactic correctness is judged on proper use of Hence, syntactic correctness is judged on proper use of the symbology; each model is reviewed to ensure that the symbology; each model is reviewed to ensure that proper modeling conventions have been maintained.proper modeling conventions have been maintained.

Consistency of OOA and OOD ModelsConsistency of OOA and OOD ModelsThe consistency of OOA and OOD models may be judged The consistency of OOA and OOD models may be judged

by considering the relationships among entities in the by considering the relationships among entities in the model.model.

To assess consistency, each class and its connections to other classes To assess consistency, each class and its connections to other classes should beshould be

examined. The class-responsibility-collaboration model and an object-examined. The class-responsibility-collaboration model and an object-relationshiprelationship

diagram can be used to facilitate this activity.diagram can be used to facilitate this activity.

5


6


Invert the connection to ensure that Invert the connection to ensure that each collaborator that is asked for each collaborator that is asked for service is receiving requests from a service is receiving requests from a reasonable source.reasonable source.

7


8


9


10


Broadening the View of Broadening the View of “Testing”“Testing”

Review of OO analysis and design models is especially Review of OO analysis and design models is especially useful because the same semantic constructs (e.g., classes, useful because the same semantic constructs (e.g., classes, attributes, operations, messages) appear at the analysis, attributes, operations, messages) appear at the analysis, design, and code level. Therefore, a problem in the design, and code level. Therefore, a problem in the definition of class attributes that is uncovered during definition of class attributes that is uncovered during analysis will circumvent side effects that might occur if analysis will circumvent side effects that might occur if the problem were not discovered until design or code (or the problem were not discovered until design or code (or even the next iteration of analysis). even the next iteration of analysis).

11


OOT OOT StrategyStrategy

class testing is the equivalent of unit class testing is the equivalent of unit testingtesting

operations within the class are testedoperations within the class are tested the state behavior of the class is examinedthe state behavior of the class is examined

integration applied three different integration applied three different strategiesstrategies

thread-based testing—integrates the set of classes thread-based testing—integrates the set of classes required to respond to one input or eventrequired to respond to one input or event

use-based testing—integrates the set of classes use-based testing—integrates the set of classes required to respond to one use caserequired to respond to one use case

cluster testing—integrates the set of classes cluster testing—integrates the set of classes required to demonstrate one collaborationrequired to demonstrate one collaboration

12


UN IT TestingUN IT Testing Integration Testing in the OO ContextIntegration Testing in the OO ContextThe first, thread-based testing, integrates the set of classes The first, thread-based testing, integrates the set of classes

required to respond to one input or event for the system. required to respond to one input or event for the system. Each thread is integrated and tested individually. Each thread is integrated and tested individually.

Regression testing is applied to ensure that no side effects Regression testing is applied to ensure that no side effects occur. occur.

The second integration approach use-based testing, begins The second integration approach use-based testing, begins the construction of the system by testing those classes the construction of the system by testing those classes (called independent classes) that use very few (if any) of (called independent classes) that use very few (if any) of server classes. server classes.

After the independent classes are tested, the next layer of After the independent classes are tested, the next layer of classes, called dependent classes, that use the independent classes, called dependent classes, that use the independent classes are tested. This sequence of testing layers of classes are tested. This sequence of testing layers of dependent classes continues until the entire system is dependent classes continues until the entire system is constructedconstructed

13


Validation Testing in an OO ContextValidation Testing in an OO Context At the validation or system level, the details of At the validation or system level, the details of

class connections disappear. Like conventional class connections disappear. Like conventional validation, the validation of OO software focuses validation, the validation of OO software focuses on user-visible actions and user-recognizable on user-visible actions and user-recognizable output from the system. To assist in the derivation output from the system. To assist in the derivation of validation tests, the tester should draw upon the of validation tests, the tester should draw upon the use-cases that are part of the analysis model.use-cases that are part of the analysis model.

The use-case provides a scenario that has a high The use-case provides a scenario that has a high likelihood of uncovered errors in user interaction likelihood of uncovered errors in user interaction requirements. requirements.

14


OOT—Test Case OOT—Test Case DesignDesignBerard [BER93] proposes the following approach:

1. Each test case should be uniquely identified and should be explicitly associated with the class to be tested,

2. The purpose of the test should be stated,

3. A list of testing steps should be developed for each test and should contain [BER94]:

a. a list of specified states for the object that is to be tested

b. a list of messages and operations that will be exercised as a consequence of the test

c. a list of exceptions that may occur as the object is tested

d. a list of external conditions (i.e., changes in the environment external to the software that must exist in order to properly conduct the test)

e. supplementary information that will aid in understanding or implementing the test.

15


Fault Based Fault Based TestingTesting

16


Fault-based testing misses two main types of Fault-based testing misses two main types of errors: (1) incorrect specifications and (2) errors: (1) incorrect specifications and (2) interactions among subsystems.interactions among subsystems.

When errors associated with incorrect When errors associated with incorrect specification occur, the product doesn't do what specification occur, the product doesn't do what the customer wants. It might do the wrong thing the customer wants. It might do the wrong thing or it might omit important functionality. But in or it might omit important functionality. But in either circumstance, quality (conformance to either circumstance, quality (conformance to requirements) suffersrequirements) suffers

Scenario Based Testing - Scenario Based Testing - Scenarios uncover Scenarios uncover interaction errors. But to accomplish this, test cases interaction errors. But to accomplish this, test cases must be more complex and more realistic. Scenario-must be more complex and more realistic. Scenario-based testing tends to exercise multiple subsystems in based testing tends to exercise multiple subsystems in a single test (users do not limit themselves to the use a single test (users do not limit themselves to the use of one subsystem at a time).of one subsystem at a time).

17


Testing Surface Structure and Deep Testing Surface Structure and Deep Structure Structure

Surface structure refers to the externally Surface structure refers to the externally observable structure of an OO program. observable structure of an OO program. ThatThat

is, the structure that is immediately is, the structure that is immediately obvious to an end-user.obvious to an end-user.

Rather than performing functions, the Rather than performing functions, the users of many OO systems may be given users of many OO systems may be given objects to manipulate in some way.objects to manipulate in some way.

18


Deep structure refers to the internal Deep structure refers to the internal technical details of an OO program. That technical details of an OO program. That is, is, the structure that is understood by the structure that is understood by examining the design and/or code.examining the design and/or code.

Deep structure testing is designed to Deep structure testing is designed to exercise dependencies, behaviors, and exercise dependencies, behaviors, and communication mechanisms that have communication mechanisms that have been established as part of the system been established as part of the system and object design of OO software.and object design of OO software.

The analysis and design models are The analysis and design models are used as the basis for deep structure used as the basis for deep structure testing.testing.

19


Testing the CRC Testing the CRC ModelModel1. Revisit the CRC model and the object-relationship model.

2. Inspect the description of each CRC index card to determine if a delegated responsibility is part of the collaborator’s definition.

3. Invert the connection to ensure that each collaborator that is asked for service is receiving requests from a reasonable source.

4. Using the inverted connections examined in step 3, 4. Using the inverted connections examined in step 3, determine whether other classes might be required or whether determine whether other classes might be required or whether responsibilities are properly grouped among the classes.responsibilities are properly grouped among the classes.

5. Determine whether widely requested responsibilities might 5. Determine whether widely requested responsibilities might be combined into a single responsibility.be combined into a single responsibility.

6. Steps 1 to 5 are applied iteratively to each class and 6. Steps 1 to 5 are applied iteratively to each class and through each evolution of the OOA model.through each evolution of the OOA model.

20


OOT Methods: Random OOT Methods: Random TestingTesting

Random testingRandom testing identify operations applicable to a classidentify operations applicable to a class define constraints on their usedefine constraints on their use identify a miminum test sequenceidentify a miminum test sequence

an operation sequence that defines the an operation sequence that defines the minimum life history of the class (object)minimum life history of the class (object)

generate a variety of random (but valid) test generate a variety of random (but valid) test sequencessequences

exercise other (more complex) class exercise other (more complex) class instance life historiesinstance life histories

21


consider a banking application in which an consider a banking application in which an account class has the following operations: account class has the following operations: open, setup, deposit, withdraw, balance, open, setup, deposit, withdraw, balance, summarize, creditLimit, and closesummarize, creditLimit, and close

The minimum behavioral life history of an The minimum behavioral life history of an instanceinstance

of account includes the following operations:of account includes the following operations:

open•setup•deposit•withdraw•closeopen•setup•deposit•withdraw•close

22


23


Partition Testing at the Class Partition Testing at the Class LeLevelvel

Input and output are categorized and test Input and output are categorized and test cases are designed to exercise each cases are designed to exercise each categorycategory

Partitioning categories are divided as Partitioning categories are divided as following ---following ---

24


25


26


INTERCLASS TEST CASE INTERCLASS TEST CASE DESIGNDESIGN

For each client class, use the list of class For each client class, use the list of class operations to generate a series of random test operations to generate a series of random test sequences. The operations will send messages to sequences. The operations will send messages to other serverother server

classes.classes. For each message that is generated, determine For each message that is generated, determine

the collaborator class and the corresponding the collaborator class and the corresponding operation in the server object.operation in the server object.

For each operation in the server object (that has For each operation in the server object (that has been invoked by messages sent from the client been invoked by messages sent from the client object), determine the messages that it transmits.object), determine the messages that it transmits.

For each of the messages, determine the next For each of the messages, determine the next level of operations that are invoked and level of operations that are invoked and incorporate these into the test sequence.incorporate these into the test sequence.

27


28


29


30


OOT Methods: Partition OOT Methods: Partition TestingTesting Partition TestingPartition Testing

reduces the number of test cases required to test a reduces the number of test cases required to test a class in much the same way as equivalence class in much the same way as equivalence partitioning for conventional softwarepartitioning for conventional software

state-based partitioningstate-based partitioning categorize and test operations based on their categorize and test operations based on their

ability to change the state of a classability to change the state of a class attribute-based partitioningattribute-based partitioning

categorize and test operations based on the categorize and test operations based on the attributes that they useattributes that they use

category-based partitioningcategory-based partitioning categorize and test operations based on the categorize and test operations based on the

generic function each performsgeneric function each performs

Documents

Chapter 23 Object-Oriented Testing