ACADEMIC REPORT: OBJECT-ORIENTED SOFTWARE DEVELOPMENT AND TESTING

Transcription

1 ACADEMIC REPORT: OBJECT-ORIENTED SOFTWARE DEVELOPMENT AND TESTING IT8418 Testing and Quality Assurance Assignment 2 By Leutele LM Grey Author CONTRIBUTE FOR SAMOA FOR EDUCATING OUR YOUNG GENERATION MAY 16, 2013 WHITIREIA NEW ZEALAND EDUCATION INSTITUTE SEMESTER ONE 2013 FACULTU OF BUSINESS AND INFORMATION TECHNOLOGY

2 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) Lack of Cohesion in Methods (LCOM) Conclusion References... 11

3 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 whitebox 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

4 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

5 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: threadbased 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).

6 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

7 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.

8 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

9 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.

10 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), 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

11 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.

12 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 Bruntink, M., & Van Deursen, A. (2004). Predicting class testability using object-oriented metrics. In source Code Analysis and Manipulation. Fourth IEEE International Workshop Chidamber, S. R., & Kemerer, C. F. (1991). Towards a metrics suite for object oriented design. IEEE Transactions. 26 (11), Chidamber, S. R., & Kemerer, C. F. (1994). A metrics suite for object oriented design. IEEE Transactions on Software Engineering, 20(6) Deitel, P & Deitel, H. (2010). Java: How to Program. (8 th 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), El Emam, K., Melo, W., & Machado, J. C. (2001). The prediction of faulty classes using objectoriented design metrics. Journal of Systems and Software, 56(1) 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 14 th International Conference on Software Engineering Harold, M J., & Rothermel, G. (1994). Performing data flow testing on classes. Foundation of Software Engineering. DOI / , 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), 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), 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, Maini, R., & Mehra, S. (2011). Analysis of object oriented design quality metrics. An International Journal of Engineering Sciences, 1,

13 12 Meyer, B. (1998). The role of object-oriented metrics. Computer, 31(11), Orso, A. (1998). Integration testing of object-oriented software. Politecnico di Milano, Milano, Italy. Pressman, R. S. (2010). Software Engineering, A Practitioner s Approach. (7 th 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, 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), 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 objectoriented design complexity: implications for software defects. IEEE Transactions on Software Engineering, 29(4), Tang, M. H., Kao, M. H., & Chen, M. H. (1999). An empirical study on object-oriented metrics. IEEE. In Software Metrics Symposium, Proceedings. Sixth International,