Study of Different Testing Techniques For Oops Software

Software testing is a phase of SDLC that entails much effort, time and cost. Often, testing phase is the single largest contributor towards the whole development time. Testing can not only uncover bugs in the program, but also flaws in design of the software. To make the testing phase quicker, easier and more efficient, automated testing tools are being used. These tools help in test case generation, reporting results and variance from expected ones (if any), bugs in code and other flaws. Usage of these tools speeds up the testing process and also ensures reduction in the probability of a bug/error being uncovered later. However application of these automated testing tools in software testing has its own disadvantages, namely, learning the tool to use it, adapting it to your purpose, and also the tool may not provide specific functionality which you may desire. Object-oriented testing essentially means testing software developed using object-oriented methodology. The target users for the testing tool are mainly software testers and maintainers. As the tools would provide valuable insight into

Available online at www.ignited.in Page 2

the program's structure and behavior plus automate the testing process to a certain extent, it would be highly useful for testers. Also the tool would be beneficial to maintainers who would like to study change impact (here they will be aided by the program's analysis done by the tool), and perform regression testing. The objectives of developing the testing tool for software testers and maintainers are: (1) to help them understand the structures of, and relations between, the components of an oo program (2) to give them a systematic method and guidance to perform oo testing and maintenance (3) to assist them to find better test strategies to reduce their efforts (4) to facilitate them to prepare test cases and test scenarios , and 5) to generate test data and to aid them in setting up test harnesses to test specific components.

The objective of this paper is: design and development of an automated testing tool for object-oriented software. The aim of this paper is to study various established as well as emerging testing techniques, with special focus on those for object-oriented software; and develop a tool which is based upon the techniques which are most suitable due to their effective applicability to OO

For carrying out this paper, following methodology has been adopted: 1. Literature Survey: This involves study of existing testing techniques and strategies, with special emphasis on object-oriented testing. 2. Analysis of Problem: This incorporates analyzing the problem. Out of the literature survey emerged, the right techniques and tactics for object-oriented software testing. Also existing methods have been modified upon where ever necessary. 3. Software tool development: Since the ultimate objective of this paper is to develop an automated testing tool, all the steps of software development have been followed. (i) Analysis (ii) Design (iii) Implementation (iv) Testing (v) Iterative process

(i) Random Testing (ii) Equivalence Partitioning (iii) Boundary Value Analysis (iv) State Transition-based Testing

(i) Basis Path Testing

Available online at www.ignited.in Page 3

(ii) Loop Testing (iii) Mutation Testing (iv) Data flow-based Testing

Certain subset of the testing techniques covered in the study can be favourably applied to object-oriented programs. At various levels of testing of object oriented software, techniques which can be applied are [Pressman, iv]: 1. Unit Testing 2. Method Testing 3. Class Testing 4. Integration Testing 5. System Testing

A main problem with testing object-oriented systems is that standard testing methodologies may not be useful. Smith and Robson [7] say that current IEEE testing definitions and guidelines cannot be applied blindly to OO testing, because they follow the Von Neuman model of processing. This model describes a passive store with an active processor acting upon the store. It requires that there be an oracle to determine whether or not the program has functioned as required, with comparison of performance against a defined specification." They also present the following definition of the testing process: "The process of exercising the routines provided by an object with the goal of uncovering errors in the implementation of the routines or the state of the object or both." Smith and Robson say that the process of testing OO software is more difficult than the traditional approach, since programs are not executed in a sequential manner. OO components can be combined in an arbitrary order; thus defining test cases becomes a search for the order of routines that will cause an error. Siepmann and Newton[8] agree that the state-based nature of OO systems can have a negative effect on testing. Siepmann and Newton state that the iterative nature of developing OO systems requires regression testing between iterations. Smith and Robson state that inheritance is problematic, since the only way to test a subclass is to flatten it by collapsing the inheritance structure until it appears to be a single class. When this is done, the testing effort for the super class is not utilized; therefore, duplicated testing takes place.

Most research on object-oriented(OO) paradigms has been focused on analysis, design, and programming fundamentals. Testing the systems that are created with these paradigms has been considered an afterthought. Traditional testing techniques must be evaluated to determine if they are still useful with respect to object oriented systems, and new techniques must be developed.

The latest research in the field of object-oriented software testing. Tonella [20] proposes a method for evolutionary testing of classes. In this paper, a genetic algorithm is exploited to automatically produce test cases for the unit testing of classes in a generic usage scenario. As , object oriented programming

Available online at www.ignited.in Page 4

promotes reuse of classes in multiple contexts, the unit testing of classes cannot make too strict assumptions on the actual method invocation sequences, since these vary from application to application. Traore [21] discusses a test model for object-oriented programs, based on formal specifications like UML, built from user requirements. Pezze & Young [22] have highlighted some important issues to be considered while testing object oriented programs. Object oriented software requires reconsidering and adapting approaches to software test and analysis.

The tools for automated testing is based upon certain models of software/programs and algorithms. This mathematically defined test model, consists of following types of diagrams: 1. the class diagram (object relation diagram) 2. the control flow graph (of a method), and 3. the state transition diagram (of a class)

A class diagram or an object relation diagram (ORD) represents the relationships between the various classes and its type. Types of relationships are mainly: inheritance, aggregation, and association. In object oriented programs there are three different relationships between classes They are inheritance, aggregation and association.

A control flow graph represents the control structure of a member function and its interface to other member functions so that a tester will know which at a is used and/or updated and which other functions are invoked by the member function.

A STD or an Object State Diagram (OSD) represents the state behavior of an object class. Now the state of a class is embodied in its member variables which are shared among its methods. The OSD shows the various states of a class (various member variable values), and transitions between them (method invocations).

These diagrams are taken from the design models prepared as part of Software Development process. UML (Unified Modeling Language) has become the defacto standard for object-oriented analysis and design (OOAD). UML provides features for specifying all the above types of diagrams. Rational Rose Suite is the most widely used.

The tool for automated testing of OO programs has the following components/features:

1. GUI

2. Import File Feature 3. Change Impact Identifier for classes 4. Maintenance Tools 5. Logging results

Available online at www.ignited.in Page 5

6. Diagram Displayer 7. Class Diagram 8. State Transition Diagram 9. Control Flow Graph 10. Test Tools: (i) Test Order generator for testing of classes at integration level (ii) Test Case generator for testing classes 11. Basis Path generator for member functions/methods

This paper dealt with Design and Development of an Automated Testing Tool for OO software. The tool mainly focuses on testing design specifications for OO software. An advantage of testing software specifications as compared to program code is that specifications are generally correct whereas code is flawed. Moreover, with software engineering principles firmly established in the industry, nowadays, while developing software all the steps of Software Development Life Cycle (SDLC) are adhered to. For this work, UML specifications are considered. UML has become the defacto standard for analysis and design of OO software. UML designs created in Rational Rose are used by the tool as input. The main components of this tool are: 1. Test Order Generator for classes 2. Test Case Generator for State-based class testing 3. Change Impact Identification for Classes

Future work would include extending the tool to incorporate more functionality. Both testing and maintenance components can be added. Some additions can be: 1. Incorporating a fully functional Method Basis Path Generator module. 2. Providing both Test Case Generation as well as Execution. The user would be able to provide test data; and the test cases generated would be executed using the test data as input. 3. Reporting Code Coverage achieved after Test Set has been executed. Various test adequacy criteria like statement coverage, branch coverage, and path coverage can be reported upon. 4. Metrics: Certain program metrics like Lines of Code(LOC), function points, interfaces, etc. can be reported upon.

[1] Jorgensen, Erikson ”Object-oriented Integration Testing” Communications of the ACM, Vol. 37, No. 9, 1994 [2] Kung, Gao, Hsia ”Developing an OO Testing and Maintenance Environment” Communications of the ACM, Vol. 38, No. 10, 1995. [3] Doong, Frankl ”ASTOOT approach to testing OO Programs” ACM Transactions on Software Engineering and Methodology, Vol. 3, No.2, 1994 [4] Doong, Frankl ”Case Studies on testing OOprograms” Communications of the ACM, Vol. 25, No. 5, 1991.

Available online at www.ignited.in Page 6

[5] M. Smith and D. Robson ”A Framework for Testing Object-Oriented programs” Journal of Object-Oriented Programming, June 1994, pp.45 -

53.

[6] Frankl, Elaine Weyuker ”An applicable family of data flow testing criteria” IEEE Transactions on Software Engineering, Vol. 14, No. 10, 1988. [7] Mary Jean Harrold, Gregg Rothermel “Performing data flow testing on classes” December 1994 ACM SIGSOFT Software Engineering Notes , Proceedings of the 2nd ACM SIGSOFT symposium on Foundations of software engineering, Volume 19 Issue 5 [8] Ugo Buy, Alessandro Orso, Mauro Pezze “Automated Testing of Classes” August 2000 ACM SIGSOFT Software Engineering Notes , Proceedings of the 2000 ACM SIGSOFT international symposium on Software testing and analysis, Volume 25 Issue 5 [9] Gao, J.Z.; Kung, D.; Hsia, P.; Toyoshima, Y.; Chen, C. ”Object state testing for object-oriented programs” Computer Software and Applications Conference, 1995. COMPSAC 95. Proceedings., Nineteenth Annual International, 9-11 Aug. 1995 Pages:232 – 238