ACADEMIC REPORT: OBJECT-ORIENTED

SOFTWARE DEVELOPMENT AND TESTING IT8418 Testing and Quality Assurance – Assignment 2

MAY 16, 2013 WHITIREIA NEW ZEALAND EDUCATION INSTITUTE

SEMESTER ONE 2013 FACULTU OF BUSINESS AND INFORMATION TECHNOLOGY

By

Leutele LM Grey

Author

CONTRIBUTE FOR SAMOA FOR EDUCATING OUR YOUNG GENERATION

1

Table of Contents

Executive Summary .............................................................................................................................. 2

Introduction ........................................................................................................................................... 2

Description ............................................................................................................................................. 3

Object Oriented Class Testing Strategy .............................................................................................. 4

Integration Testing for Object Oriented Concept............................................................. 4

Cluster Testing Strategy ...................................................................................................... 5

Object Oriented State Test Model ...................................................................................... 5

Object Oriented Tactics and Techniques ............................................................................................ 5

Object Oriented Metrics ....................................................................................................................... 6

The Internal Product Metrics ............................................................................................. 6

The External Product Metrics ............................................................................................ 7

The Process Metrics ............................................................................................................. 7

Chidamber and Kemere 6 Metrics Suite ............................................................................................ 8

Weighted Method per Class (WMC) .................................................................................. 8

Depth of Inheritance Tree (DIT) ........................................................................................ 8

Number of Children (NOC) ................................................................................................ 9

Coupling Between Objects (CBO) ...................................................................................... 9

Response for a Class (RFC) .............................................................................................. 10

Lack of Cohesion in Methods (LCOM) ............................................................................ 10

Conclusion ........................................................................................................................................... 10

References ............................................................................................................................................ 11

2

A Report: Object Oriented Software Development and Testing

By

Leutele L.M Grey, 2013

Executive Summary

The purpose of this report is to identify and describe the testing strategies, software

tactics, testing techniques and metrics for Object Oriented (OO) software development context.

The Object Oriented Programming (OOP) language refers to a programming methodology that

is based on objects, instead of just functions and procedures. The OOP allows individual

objects to organize and group themselves together into classes. The report explores the

differences between the traditional development and the OO development context as well as

the appropriate testing strategies, tactics, techniques and metrics for OO systems. The findings

revealed that because of the complex structure of the OO development systems, therefore the

traditional unit testing approach is ineffective when considering an OO system. Further, the

three most used testing strategies are: the class testing strategy which starts immediately once

the source code is being created; the two integration testing methods including the thread-based

testing and the used-based testing; the cluster testing and the object state test model. Moreover,

in the OO development, a variety of software development tactics and techniques can be used

appropriately in different areas to help detect coding errors including: the black box, the use

case modelling techniques, the object behaviour models and event flow diagrams. The white-

box testing method can be applied to the operations defined for a class. Testers can also use the

basis path, loop testing, or data flow techniques to check to ensure that every statement in an

operation has been tested. Finally, many OO metrics have been proposed to assess the

testability of an OO system.

Key words: Object Oriented, Object Oriented testing strategies

Introduction

This report identifies and describes the testing strategies, software tactics, testing

techniques and metrics for the OO software development context. Singh and Sahoo (2012) state

that the OO technology has become a very popular development methodology because it offers

features such as encapsulation, inheritance, polymorphism, abstraction, cohesion and coupling.

The OO design and development is aimed to improve software productivity, reusability and

flexibility of software systems which is the reason the OO method is largely favoured by

3

modern software development systems (Tang, Kao, & Chen, 1999; Dubey & Rana, 2010). For

example, PHP .NET and Java programming languages are rich of OO features consisting of

high level capabilities for developing highly maintainable, reusable, testable and reliable

software (Deitel & Deitel, 2010).

The class testing strategy for OO software is different to those of the unit testing for

conventional systems, in that the unit testing focus on algorithmic detail of a module as well as

the data that flow across the module interface. In contrast, class testing for OO software is

driven by operations encapsulation and the state behaviour of the class (Pressman, 2010;

Harold & Rothermel, 1994). For this reason, the OO paradigm presents some critical challenges

to software efforts and cost estimations (Singh et al, 2012). While the usage of OO method

rapidly increased particularly during the 1990s, likewise, demands for the need for an

appropriate metric suite that could take into consideration the complexity of OO structures,

(including inheritance and polymorphism that are not present in functionally orientated

software) maximized (Kjellqvist, 2004). In addition, the OO development requires not only a

metric suite, but it also needs a different appropriate design and implementation approach

(Singh et al, 2012). The remainder of this report is organized as follow: part two describes the

OO testing environment. Parts three and four discuss the OO testing strategies, tactics and

techniques, followed by part five which introduces the OO metrics followed by the conclusion.

Description

A test strategy is an outline that describes the testing approach of the software

development cycle (Gambhir, 2012). Further, its purpose is to inform project managers, testers,

and developers about some key issues of the testing process. In the OO context, the

encapsulation feature defines and drives classes and objects, therefore, instead of testing an

individual module, the encapsulated class or object becomes the smallest testable unit

(Gambhir, 2012). Further, because a class can contain many different operations and that a

particular operation may exist as part of a number of different classes, this changes the meaning

of unit testing in the OO context (Gambhir, 2012, Pressman, 2011). This also means that a

single operation (the conventional view of unit testing) cannot be tested in isolation, but rather

as part of a class (Gambhir, 2012). This is illustrated as follow:

“Operation X of a class hierarchy has been defined for a super class which in turn is

inherited by a number of subclasses and that each subclass uses Operation X. which is

applied within the context of the private attributes and operations that have been defined

4

for the subclass. As the context in which operation X is used varies, it is necessary to

test operation X in the context of each subclass (Gambhir, 2012,). This means that to

enable testing of operation X, the traditional unit testing approach is ineffective

(Gambhir, 2012)”.

In the OO testing environment, the known main testing strategies are: class testing, the

thread-based testing; used-based testing; cluster testing and the object state test model, all of

which are discussed in detailed in the next section.

Object Oriented Class Testing Strategy

Software testing strategies describe how the product risks of the stakeholders are mitigated at

the testing level. The tests strategies define the types of tests that are to be performed, and

which entry and exit criteria to apply (Gambhir, 2012). Moreover, for every stage of

development design, a corresponding test strategy will be created to test the new feature sets.

In the OO context, the class testing strategy starts once the source code has been

generated (Pressman, 2010). During the process, a series of test cases are also being designed

and created aimed to exercise class operations and identify existing errors as each class

collaborates with other classes. Systematically, as classes are integrated continuously to form

sub systems a combination of the class testing, thread-based testing, use-based testing and

cluster testing along with fault base approaches are applied to fully test the collaborating

classes. Harold, McGregor and Fitzpatrick (1992) state that one of the main benefits of OO

programming is that it facilitates reuse of instantiable, information-hiding modules, or classes.

A key goal of OO programming is to create libraries of well-designed and thoroughly tested

classes that can be confidently reused for many applications (Harold et al, 1992).

Integration Testing for Object Oriented Concept

There are two different strategies for integration testing of OO systems including: thread-

based testing and use-based testing.

Thread-Based Testing Strategy - integrates the set of classes required to respond to one

input or an event of the system. Moreover, each thread is integrated and tested

individually and the regression testing is also applied to ensure that no side effects has

occurred (Gambhir, 2012).

5

Use-Based Testing Strategy - This strategy is also the beginning of the construction of

the system which is implemented by testing independent classes that may use very few

(if any) of server classes. Upon duration of the independent classes testing process, the

next layer of classes which are dependent classes that use the independent classes are

tested. Moreover, the sequence of testing layers of the dependent classes continue until

the entire system is constructed (Gambhir, 2012).

Cluster Testing Strategy

The cluster testing strategy is one step towards the integration testing of OO software.

Here, a cluster of collaborating classes which is determined by examining the cyclic

redundancy check (CRC) and the object relationship model is exercised by designing test cases

that attempt to uncover errors in the collaboration processes (Pressman, 2010; Gambhir, 2012).

Object Oriented State Test Model

Kung, Suchak, Gao, Hsia, Toyoshima & Chen (1994) explain that the Object State

Testing (OST) model is an important aspect of OO software testing which is different from

both the control flow and data flow testing. Kung et al (1994) explains that the OST model is

a hierarchical, concurrent, communicating state machine which resembles the concepts of

inheritance and aggregation in the OO paradigm, rather than the concept of state decomposition

as in some existing models.

Object Oriented Tactics and Techniques

This section briefly explores some of the tactics and techniques in consideration of the

OO software testing. Gambhir (2012) states that at the OO validation level, one of the key focus

of the OO software is on the user-visible actions and user recognizable output from the system.

Therefore, testers during the derivation of validation testing may have to draw from use case

models that are part of the analysis model which are useful in producing scenarios that are

likely to uncover errors in the user interaction requirements. Also, the black box testing

technique can be used to drive validation tests. Moreover, other test cases may be drawn from

object behaviour models and from event flow diagrams that have been created as part of the

OO analysis (Kung et al, 1994). In addition, the basis path, loop testing, or data flow techniques

all have the potentials that can help ensure that every statement in an operation has been tested.

On one side of the spectrum, the white-box testing technique can be applied to the operations

6

defined for a class (Harold et al, 1994). However, the concise structure of many class operations

causes concern that the effort applied to white-box testing might be better redirected to tests

at a class level (Harold et al, 1994) .On the other hand, the black-box testing technique are as

appropriate for OO systems as they are for conventional software engineering methods

(Gambhir, 2012). Moreover use-cases can provide useful input in the design of black-box and

state-based tests (Gambhir, 2012).

Object Oriented Metrics

A software metric is a measure of some properties of a piece of software or its

specifications (Kjellqvist, 2004). The goal of a software metric is to obtain objective,

reproducible and quantifiable measurements, which may have numerous valuable applications

in schedule and budget planning, cost estimation, quality assurance testing, software

debugging, software performance optimization, and optimal personnel task assignments

(Gambhir, 2012). In addition, software measurement can help improve the software process,

assist in tracking and control of a project and assessing of the quality of a product. By analysing

metrics, a developer can correct those areas of a software process that could be the cause of a

software’s defects.

Kjellqvist (2004) states that the OO metrics is still under developed and that there is a

lack of consensus within the community when deciding which metrics to use or how to

calculate them. That said, still, there are already many different proposed metric suites and

general metrics available for the OO software development context. The purpose of this section

is to introduces the metrics and discuss an OO existing metrics suites namely Chidamber and

Kemerer metric suite.

Meyer (1998) in his study divided the software metrics in two different categories

including: product metrics and process metrics. In addition, the product metrics measure the

properties of a product which is also divided into two categories including: internal and external

metrics (Meyer, 1998). The external metrics are those visible to the user of a product and the

internal metrics measure properties that are only visible to the development team. Unlike the

product metrics, process metrics are not divided into any subgroup (Meyer, 1998).

The Internal Product Metrics

The internal product metrics’ properties are:

Size metrics - which measure the internal size of a product.

7

Complexity metrics - which is related to the size metric and estimates the complexity

of a product.

Style metrics - which gauge how well the work is of product components, programs

and documents as well as whether or not the program follows the style guidelines of

coding and documentation.

The External Product Metrics

The external product metrics’ properties are:

Product non-reliability metrics - which assess the number of defects that are remaining

within the software.

Functionality metrics – which consider the amount of useful functionality the product

will provide when finished.

Performance metrics - which estimate the effectiveness with which the product uses its

resources, including computation speed and space.

Usability metrics - which quantify the products ease of learning and ease of use.

Cost metrics - which measure the cost of purchasing and using a product

In contrast, the process metrics measure a process that is used during the product development

phase (Meyer, 1998).

The Process Metrics

The process metrics’ properties are:

Cost metrics – which include the cost of the project, or the cost of a specific project

activity such as: initial development, maintenance or documentation.

Effort metrics - which is a sub-metric of the cost metric best use to gauge the human

part of the cost, typically measured in person-days or person-weeks.

Advancement metrics - which estimates which degree in which a product is finished

during its development.

Process non-reliability metrics - which assess the number of flaws uncovered so far in

the development of a product

8

Chidamber and Kemere 6 Metrics Suite

Chidamber and Kemerer (CK) (1991, 1994) have created a suite of six metrics aimed to

measure design complexity in relation to their impact on quality attributes such as usability,

maintainability, functionality, reliability etc. (Sharma, Sharma, Bhardwaj, Singh & Singh,

2012; Dubey et al, 2010; Arora, Khanna, Tripathi, Sharma, & Shukla, 2011; Tang et al, 1999;

Kpodjedo, Ricca, Galinier, Guéhéneuc & Antoniol, 2011; Shaik, Reddy & Damodaran, 2010;

Bruntink & Van Deursen, 2004). The six CK metrics are:

Weighted Method Per Class (WMC)

Depth of Inheritance Tree (DIT)

Number of Children (NOC)

Coupling between Objects (CPO)

Response for a Class (RFC)

Lack of Cohesion (LOC)

The CK metrics offer informative insight to ensure developers are following OO principles

Chidamber et al (1991, 1994). Moreover, Chidamber et al (1991, 1994) argue that by using

some of their metrics collectively, this can assist testers and designers in making better design

decisions. The CK metrics have generated a significant amount of interest and are currently the

most well-known suite of measurements for OO software (Shaik et al, 2010; Bruntink et al,

2004).

Weighted Method per Class (WMC)

The WMC measures the complexity of a class e.g. by calculating the cyclamate complexities

of the methods. This means that a high value of WMC will indicates that the class is more

complex than that of a WMC with a low value. The desired outcome is a class with less WMC

(Chidamber et al, 1991).

Depth of Inheritance Tree (DIT)

The DIT metric is the length of the maximum path from the node to the root of the tree.

Therefore, this metric calculates how far down a class is declared in the inheritance hierarchy.

9

It also measures how many ancestor classes can potentially affect this class. The DIT represents

the complexity of the behaviour of a class, the complexity of design of a class and potential

reuse. For example, if DIT increases as illustrated in Figure 1, it means that more methods are

to be expected to be inherited, which makes it more difficult to calculate a class behaviour.

Thus it can be hard to understand a system with many inheritance layers. On the other hand, a

large DIT value indicates that many methods may have been reused (Chidamber et al, 1991).

Figure 1: The Value of DTI for Class Hierarchy

Source: Chidamber, S. R., & Kemerer, C. F. (1991). Towards a metrics suite for object

oriented design. IEEE Transactions. 26 (11), 197-21

Number of Children (NOC)

The NOC metric measures how many sub-classes are going to inherit the methods of

the parent class. As shown in the figure 1 above, class C1 has three children, subclasses

C11, C12, and C13. The size of NOC approximately indicates the level of reuse in an

application. If the NOC grows it means reuse has increase. Moreover, as NOC

increases, the amount of testing will also increase because more children in a class

indicate more responsibility. Therefore, NOC represents the effort required to test the

class and reuse (Chidamber et al, 1991).

Coupling Between Objects (CBO)

The idea of CBO metrics is that an object is coupled to another object if two objects act upon

each other. A class is coupled with another if the methods of one class use the methods or

10

attributes of the other class. An increase of CBO indicates that the reusability of a class will

decrease. Thus, the CBO values for each class should be kept as low as possible. The CBO

metric measure the required effort to test the class (Chidamber et al, 1991).

Response for a Class (RFC)

The RFC metric presents the number of methods that can be invoked in response to a message

in a class. Pressman (2012) states that since the RFC increases, the effort required for testing

also increases because the test sequence grows. Further, if the RFC increases, the overall design

complexity of the class increases and becomes hard to understand. On the other hand lower

values indicate greater polymorphism. The value of RFC can be from 0 to 50 for a class and in

some cases the higher value can be 100 depending on the project (Chidamber et al, 1991).

Lack of Cohesion in Methods (LCOM)

The LCOM metric uses the notion of degree of similarity of methods. LCOM measures the

amount of cohesiveness present, how well a system has been designed and how complex a

class is. LCOM is a count of the number of method pairs whose similarity is zero, minus the

count of method pairs whose similarity is not zero (Chidamber et al, 1991).

Conclusion

The purpose of this report is to describe the testing strategies, tactics, techniques and

metrics for OO software development context. The report examines and discuss the OO testing

environment, testing strategies, tactics and techniques and metrics. The final section identifies

and discuss in details the OO metrics. It was found that, the traditional unit testing approach is

ineffective in the OO context. The major testing strategies are: class testing strategy; two

integration testing methods including the thread-based testing and the use-based testing; the

cluster testing and the object state test model. Several testing tactics and techniques can be used

for the OO software development including: black box and white box techniques, In addition,

use case models, the basis path, loop testing, or data flow techniques all have the potentials that

can help ensure that every statement in an operation has been tested. A wide variety of OO

metrics have been proposed to assess the testability of an OO system. Finally, this report focus

on examining the CK metrics suite which capture different aspects of an OO design which

focus on class and class hierarchy.

11

References

Arora, D., Khanna, P., Tripathi, A., Sharma, S., & Shukla, S. (2011). Software quality

estimation through object oriented design metrics. Int. J. Computer Science and Network

Security, 11(4). Pp. 100-104.

Bruntink, M., & Van Deursen, A. (2004). Predicting class testability using object-oriented

metrics. In source Code Analysis and Manipulation. Fourth IEEE International Workshop.

136-145.

Chidamber, S. R., & Kemerer, C. F. (1991). Towards a metrics suite for object oriented design.

IEEE Transactions. 26 (11), 197-21.

Chidamber, S. R., & Kemerer, C. F. (1994). A metrics suite for object oriented design. IEEE

Transactions on Software Engineering, 20(6). 476-493.

Deitel, P & Deitel, H. (2010). Java: How to Program. (8th Ed). Pearson Education Inc. New

Jersey.

Dubey, S. K., & Rana, A. (2010). A comprehensive assessment of object-oriented software

systems using metrics approach. International Journal on Computer Science and Engineering,

2(08), 2726-2730.

El Emam, K., Melo, W., & Machado, J. C. (2001). The prediction of faulty classes using object-

oriented design metrics. Journal of Systems and Software, 56(1). 63-75.

Gambhir, S. (2012). Testing strategies for object oriented systems. International Journal of

Computer Science and Information Technology & Security, 2(2).

Harold, M, J., McGregor, J.D., & Fitzpatrick, K, J. (1992). Incremental testing of object-oriented class

structures. In proceedings of the 14th International Conference on Software Engineering. 68-80.

Harold, M J., & Rothermel, G. (1994). Performing data flow testing on classes. Foundation of

Software Engineering. DOI.10.1145/193173.195420, 154-163.

Khan, R.A., Mustafa, K & Alnson, S.I. (2011). An empirical validation of object oriented

design quality metrics. J. King Saud Univ., Comp. & Info. Sci, 1(16), 1-17.

Kpodjedo, S., Ricca, F., Galinier, P., Guéhéneuc, Y. G., & Antoniol, G. (2011). Design

evolution metrics for defect prediction in object oriented systems. Empirical Software

Engineering, 16(1), 141-175.

Kung, D., Suchak, N., Gao, J., Hsia, P., Toyoshima, Y., & Chen, C. (1994). On object state

testing. In IEEE. Computer Software and Applications Conference, COMPSAC 94.

Proceedings, 222-227.

Maini, R., & Mehra, S. (2011). Analysis of object oriented design quality metrics. An

International Journal of Engineering Sciences, 1, 40-52.

12

Meyer, B. (1998). The role of object-oriented metrics. Computer, 31(11), 123-127.

Orso, A. (1998). Integration testing of object-oriented software. Politecnico di Milano, Milano,

Italy.

Pressman, R. S. (2010). Software Engineering, A Practitioner’s Approach. (7th Ed). The

McGraw-Hill Companies Inc. New York.

Shaik, A., Reddy, C. R. K., & Damodaran, A. (2010). Statistical analysis for object oriented

design software security metrics. International Journal of Engineering and Technology, 2,

1136-1142.

Sharma, M., Sharma, C., Bhardwaj, A., Singh, N., & Singh, L. (2012). Comparative study of

static metrics of procedural and object oriented programming languages. International Journal

of Computers & Technology, 2(1), 15-19.

Singh, J., & Sahoo, B. (2012). UML based object oriented software development effort

estimation using ANN.

Subramanyam, R., & Krishnan, M. S. (2003). Empirical analysis of CK metrics for object-

oriented design complexity: implications for software defects. IEEE Transactions on Software

Engineering, 29(4), 297-310.

Tang, M. H., Kao, M. H., & Chen, M. H. (1999). An empirical study on object-oriented metrics.

IEEE. In Software Metrics Symposium, 1999. Proceedings. Sixth International, 242-249.