Towards Integration Testing Of Software Components
Upcoming SlideShare
Loading in...5
×
 

Towards Integration Testing Of Software Components

on

  • 2,453 views

 

Statistics

Views

Total Views
2,453
Views on SlideShare
2,453
Embed Views
0

Actions

Likes
0
Downloads
74
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Towards Integration Testing Of Software Components Towards Integration Testing Of Software Components Document Transcript

  • Towards Integration Testing Of Software Components A Thesis Submitted in partial fulfillment of the requirement for the Award of the Degree of Master of Technology IN COMPUTER SCIENCE & ENGINEERING (2006-2008) Under the Supervision of Ms. Gagandeep Submitted By Harpreet Kaur Department of Computer Science Punjabi University, Patiala.
  • Acknowledgement Nothing concrete can be achieved without an optimal combination of inspiration and perspiration. The real spirit of achieving a goal is through the way of excellence and discipline. I would have never succeeded in completing my task without the cooperation, encouragement and help provided to me by various personalities I owe my special thanks to Ms. Gagandeep, Lecturer, Department of Computer Science Punjabi University, Patiala, who helped and guided me for this work. Her encouraging remarks from time to time greatly helped me in improving my skills. I am also thankful to Dr.Gupreet Singh Lehal, Professor and Head, Department of Computer Science, Punjabi University, Patiala, for providing necessary facilities in the Department, to work. I wish to place on record my gratitude for all those who have been instrument in bringing my work to this stage. Above all I render my gratitude to the ALMIGHTY who bestowed me self-confidence, ability and strength to complete this work. I also owe sincere thanks to my parents for their support and encouragement. Harpreet Kaur 2
  • Abstract The use of third-party components in software system development is rapidly increasing. It allows rapid development of applications with the help of prefabricated and pre-tested components thus allowing more reliability and credibility. Component-based software engineering not only requires focus on system specification and development, but also requires additional consideration for overall system context, individual components properties, and component acquisition and integration process. To ensure the delivery of quality component based software, effective and efficient testing is the key process in software development. Since 40% of software errors are revealed during integration testing. Adequate integration of reusable components is the key to the success of a component-based software system. Integration testing is an important part of the testing process in which individual software modules are combined and tested as a group. It ensure correct interaction and interfacing between the units in a software system. Interfaces must be tested because they could have been specified incorrectly, defined incorrectly and implemented incorrectly. it is also used to find faults that could not have been found in the component testing because they only become apparent when the components are integrated. Currently, components delivered by component providers only include specifications of the interfaces. Without source code many testing techniques are not applicable to component-based systems. Improvements in software testing techniques are needed to address the increasingly complex applications that are implemented by today’s software systems. The Unified Modeling Language (UML) is gaining wide acceptance in industry. UML diagrams can be used as the basis for functional testing. The UML and its diagrams are widely used to visually depict the static structure and more importantly for us, the dynamic behavior of such applications. For integration level testing, we can derive tests from UML Sequence diagrams, which embody the behavioral description of each component of interest and more importantly, the interactions or events between them. 3 View slide
  • In this thesis the focus has been on developing a technique to enhance testing of interactions among classes. In this we present a novel approach of generating test cases from UML design diagrams. We consider sequence diagram in our test case generation scheme. Our approach consists of transforming a UML sequence diagram into a graph called the graph of sequence diagram (GOSD). Sequence diagrams are drawn with StarUml tool.The GOSD is then traversed to generate test cases. The test cases thus generated are suitable for Integration testing and to detect dependency and interaction related faults. 4 View slide
  • Table of Contents Topic Page No. List of Figures vi List of Tables vii Chapter 1 – Introduction 1-3 Chapter 2 – Objective 4 Chapter 3 – Component Based Integration Testing 5 3.1 Introduction 5-6 3.2 Objectives of Integration testing 6 3.3 Component Integration Testing Vs Module Testing 6-7 3.4 Integration Testing Strategies 7-8 3.5 Different issues in component integration 8-9 3.6 Features to be tested 9 3.7 Integration Faults 10-11 3.8 A test Model for integration testing of components based software 11-12 Chapter 4 – Literature Survey 13-15 Chapter 5 – Implementation 5.1 UML-based Integration Testing for Component-Based Software 16-22 5.2 Integration Testing Based on Data Flow Specification 23-28 Chapter 6-Introduction to UML 29 6.1 Introduction 29-30 6.2 Goals of UML 30-31 6.3 The Building Blocks of UML 31-32 6.4 Model View of UML 32-34 Chapter 7 –Related Work 35-36 5
  • 37 Chapter 8 - A Systematic Approach for Integration Testing from Sequence Diagram 8.1 Introduction 37-38 8.2 Integration Testing and Sequence diagram 38 8.3 UML’s Sequence Diagram 39-41 8.4 The Proposed Approach 41-46 Chapter 9 - Implementation and Experiment 47 9.1 Implementation with PIN Authentication Component 47-51 9.2 Implementation with Ticket selling Component 52-56 9.3 Implementation with Registration System Component 57-61 Chapter 10- Conclusions and Future Work 62 10.1 Evaluation of Experiment 62-64 10.2 Summary of the contribution 64-65 66-68 References 6
  • List of Figures Figure 5.1.1: Collaboration diagram of Bank Server Component……………………….16 Figure 5.1.2: Sequence diagram of Bank Server Component………………………….. 16 Figure 5.1.3: Collaboration diagram of Bank Transaction Component………………....18 Figure 5.1.4: state chart diagram of exit event………………………………………… 18 Figure 5.1.5: Collaboration diagram of Bank Component……………………………... 19 Figure 5.1.6: State Chart diagram showing dependence relationship……………....…...20 Figure 5.2.1: The CDFD of Do operation Module…………………………………….. 23 Figure 5.2.2: CDFD of division operation……………………………………………… 25 Figure 6.1.1: Model view of UML………………………………………………………32 Figure 8.3.1: Segment of sequence diagram showing message passing…………………39 Figure 8.3.2: A segment of a sequence diagram in which the addStudent message has a guard……………………………………………………………………………………..40 Figure 8.4.1: Schematic representation of our approach………………………………...42 Figure 9.1.1: Sequence Diagram of ATM PIN Validation Component…………………49 Figure 9.2.1 :Class Diagram of Box office application………………………………….53 Figure 9.2.2: Sequence Diagram of Ticket selling component…………………………..54 Figure 9.3.1: Sequence diagram of Automated Registration System……………………59 Figure 10.1.1: Bar chart of total number of test cases and execution time for ATM component………………………………………………………………………………..62 Figure 10.1.2: Bar chart of total number of test cases and execution time for Ticket Selling component……………………………………………………………………….63 Figure 10.1.3 Bar chart of total number of test cases and execution time for Registration component……………………………………………………………………………….64 7
  • List of Tables Table 5.1.1: Table to generate test cases for context collaboration diagram………….. 17 Table 5.1.2: Table to generate test cases for context Statechart diagram……………… 19 Table 5.1.3: Table to generate test cases for content collaboration diagram………….. 20 Table 5.1.4: Table to generate test cases for content Statechart diagram……………… 21 Table 5.2.1: Process decomposition Table ….……………......……………………… 24 Table 5.2.2: Table to generate test cases for CDFD...………………………………..25-26 Table 6.1.1: Testing Phases and UML diagrams ….……......…………………………..34 Table 9.1.1 : Five operation scenarios represented in the form of quadruples…………..50 Table 9.1.2: Test Run with sequence Diagram of ATM PIN Validation………………..52 Table9.2.1 Three operation scenarios represented in the form of quadruples…………...55 Table 9.2.2 Test Run with sequence Diagram of Ticket Selling………………………...57 Table9.3.1: Two operation scenarios represented in the form of quadruples……………60 Table 9.3.2: Test Run with sequence Diagram of Registration system………………….62 8
  • Chapter 1 Introduction 1.1 Problem Component-Based Software Engineering (CBSE) is a software development methodology based on the reuse of existing, often pre-compiled, modules of software. Third-party built components are regularly referred to as COTS (Commercial off-The Shelf) components. CBSE not only requires focus on system specification and development, but also requires additional consideration for overall system context, individual components properties and component acquisition and integration process [10]. Components-based software systems are becoming prevalent as an engineering approach that empowers rapid development with fewer resources. The major goals of CBSE are the provision of support for the development of systems as assemblies of components, the development of components as reusable entities, and the maintenance and upgrading of systems by customizing and replacing their components. Component- Based Development (CBD) offers a radically new approach to the design, construction, implementation and evolution of software applications. Software applications are assembled from components from a variety of sources; the components themselves may be written in several different programming languages and run on several different platforms. Conventional development is a special case of CBD, which lacks some of the techniques and opportunities (and of course the benefits) that characterize full CBD. To ensure the delivery of quality9 component based software, effective and efficient testing is the key process in software development. Component Based Software has implementation transparency property and its frequent heterogeneity raise some difficulties when the software is to be tested. Since components are intended to be reused across various products and product-families, components must be tested adequately. Since 40% of software errors are revealed during integration testing. Adequate integration of reusable components is the key to the success of a component-based software system [8]. 9
  • Integration testing is an important part of the testing process in which individual software modules are combined and tested as a group. Integration Testing is performed after unit testing and before system testing. Its objective is to identify defects in the interfaces and interactions between components. When the integration errors appear, then error location and cause analysis is done during the integration testing. There could be functional problems, which means errors caused by missing or wrong functionality. Non-functional problems can be a consequence of non-matching requirements, such as reliability, maintainability and usability. In addition, Problems could be architectural, which may require changing the whole architectural structure. There could also be conflicts between components in the systems – for instance, deadlocks. Furthermore, there could be interface problems, which are caused by syntax or semantic software and hardware incompatibilities. Different component features such as source code unavailability, component heterogeneity and continuously changing nature, may cause difficulties in Component integration testing. Thus mechanisms for component integration testing demand that additional information must be packaged with the component for the reliable use of component applications, which is necessary for effectively utilizing the reuse benefit of component [7]. We use Unified Modeling Language (UML) and its sequence diagram for Integration Test case generation.UML design Model consist of Variety of diagrams. Each diagram describes a view of design. For Example, a class diagram describes a structural view and sequence and activity diagrams describe behavioral views. 1.2 Overview of the Solution and the research challenges Quality of end product and effective reuse of software depend on large extent on testing. Developers therefore spend considerable time and efforts to achieve thorough testing. Regardless of the test strategy being used, large systems are inherently complex to test and require large number of test cases to be designed. There is an increasing need for 10
  • effective testing of software for complex safety-critical applications, such as avionics, medical, and other control systems. For Integration testing, we can derive tests from UML Sequence diagrams, which embody the behavioral description of each component of interest and more importantly, the interactions or events between them. UML, the Unified Modeling Language, is the emerging graphical notation to model, document and specify all phases of the software process. An approach of generating inputs for testing UML design requires mechanism that combines information from both the structural and behavioral views of design. We conducted the case studies to investigate the effectiveness of our testing approach. The studies include the effective way of generating the UML Integration test case selection based on UML sequence diagram. The work described in this thesis includes storage of information that we are getting from sequence diagrams in a graph called graph of sequence diagram (GOSD).Sequence diagrams are drawn with the help of UML drawing tool StarUml.The graph is generated in c++, and the structure is decided so that it can dynamically store any number of links and any amount of information .We consider depth-first traversal algorithm to traverse graph. After that the Graph is traversed to generate test cases for integration testing. For the specification of test case, we consider the test case specification language. The practical approach for generating the integration test suite will provide more accuracy as compared to the manually generating the test suite. 1.3 Organization of the Report. The Project is organized as follows: Chapter 2 Presents Objective Chapter 3 Describes Overview of Integration testing. Chapter 4 Discusses Literature Survey Chapter 5 Implementation of Component Integration testing Techniques like UML based, data-flow specification. Chapter 6 Describes UML Chapter 7 Provides related work in UML Chapter 8 Provides an overview of our approach. 11
  • Chapter 9 Describes Implementation of our approach Chapter 10 Discusses results and Future work of our Implementation. 12
  • Chapter 2 Objectives Building high quality and reusable software components is very important for component-based software development projects. The testability of software components is one of the important factors determining the quality of components. Building programs and components with good testability always simplifies test operations, reduces test cost, and increases software quality. The testing process proceeds from testing individual modules, through to integration and system testing. As individual modules are built unit testing occurs on these. Unit testing is done primarily by developers. As the system grows, tests are conducted as the modules are combined together. This type of testing may be done by testing teams, and may no longer involve the original developers. This is called integration testing. The challenge in component based testing is the integration testing because individual components have already been tested. Integration testing is often the most time consuming and expensive part of testing. Commercially available software components are generally packaged without source code and this may cause difficulties in component integration testing. The objectives include: • To study existing component based integration testing techniques and their impact on component based software product. • Implementation of some of the existing techniques and to verify their results. • Improving the exiting component based integration testing methods. • Implementing a systematic approach to automate Integration Testing. Chapter 3 13
  • Component-Based Integration Testing 3.1 Introduction Testing is essential in the development of any software system. Testing is required to assess a system’s functionality and quality of operation in its final environment. This is especially of importance for system being assembled from any self-contained software components. Basically testing is done to reveal faults and after detecting failures, debugging techniques are applied to isolate and remove faults. To ensure the delivery of quality software, effective and efficient testing is the key process in software development. Testing may be viewed as structural (or white box) or it may be viewed as functional (or black box). White box tests are designed using knowledge of the data structures and algorithms within the program, while black box testing uses only system specifications. The testing process proceeds from testing individual modules, through to integration and system testing. As individual modules are built unit testing occurs on these. Unit testing is done primarily by developers. At this point a combination of white and black box testing can occur. As the system grows, tests are conducted as the modules are combined together. This type of testing may be done by testing teams, and may no longer involve the original developers. This is called integration testing. Testing of the entire integrated system is called system testing. Integration and system testing are commonly restricted to black box testing. They rely heavily on documentation of system specifications. Integration testing has always been a challenge especially if the system under test is large with many subsystems and interfaces. According to Li et al., approximately 40% of software errors are revealed during integration testing [8]. IEEE defines integration testing as “testing in which software components are combined and tested to evaluate the interaction between them”. Indeed, unit testing cannot confirm the reliable behavior of components in a new system; hence another testing is essential to attain an acceptable reliability level [7]. The beginning of integration testing assumes a reliable and complete set of unit tests. At this stage we begin to combine the different tested units or components to conform a 14
  • working subsystem. Despite the fact that a unit has been through a successful unit test, it might still behave unpredictable when interacting with other components in a system. Therefore testing at the integration level is dependent on the quality of the unit tests and on the complexity of interactions that occur between components. 3.2 Objectives of Integration Testing Component integration testing is an indispensable phase. Main reasons to conduct integration testing include: 1) Determine if the commercial components will work properly together. 2) To find faults that could not have been found in the component testing because they only become apparent when the components are integrated. 3) To generate credible information about the software under test, so that technical and business decisions can be made. 4) Confirm that as the system grows risk of failure is being diminished. 3.3 Component Integration Testing Vs Module Testing The emphasis on modularity in software design has influenced designers master the complexity of software systems by dividing them into components. One of the benefits of modularity is that the software components can be tested independently, which is usually done by programmers during unit and module testing. Although much is known about unit and module testing and many techniques and tools are available, the integrated components also need to be tested. Unit testing techniques are sometimes applied during integration, but using these techniques for integration testing suffers from two problems. 1) The unit testing techniques are usually too expensive to be practically applied during integration 2) There is no reason to believe that they will find the kinds of faults that appear during integration. Some software faults cannot be detected during unit testing; These are often faults in the interfaces between units. Thus, we must specifically test for integration faults. 15
  • 3) During module testing, we concentrate on analyzing the implemented algorithms and their data usage. These are determined by items such as statements, sequences of statements, and values of variables and expressions. Thus, we use the well- known test data selection criteria. These are well suited since modules usually are relatively small. For integration testing we could, of course, use the same criteria as for module testing. However, on the one hand this could lead to many test cases and on the other; we would not consider that each module has already been tested. This is why during integration testing we concentrate on analyzing another aspect, namely the relations and the interfaces between the modules [15]. 3.4 Integration Testing Strategies There are two common ways to conduct integration testing. • Non-incremental integration: It uses a Big-bang approach to integration; it is a very simple approach as there is no need of stubs and drivers. In addition little planning and resources are needed for big-bang approach. It involves combining all the tested units and performing tests on the combined system as a whole. The usual problem with this approach is the level of complexity involved in locating the sources of errors when unexpected events occur. • Incremental integration: In this approach the program is constructed and tested in small increments by adding a minimum number of components at each interval. Therefore, the errors are easier to isolate and correct, and the interfaces are more likely to be tested completely. Two different approaches have been identified as means of performing incremental integration testing: Top-Down integration and Bottom-up integration 1) Top-Down integration: In this modules are integrated from the main module (main program) to the subordinate modules either in the depth-first or breadth- first manner. Test the top layer of the controlling subsystem first. Then combine All the subsystems that are called by the tested subsystems and test the resulting collection of Subsystems. Do this until all subsystems are incorporated into the test. In 16
  • this approach Test Stubs are used to simulate the components of lower layers that have not yet been integrated. Drivers are not needed in this. The advantage of this approach is that faults can easily be identified. Drawback of this approach is the extra coding involved in writing stubs. 2) Bottom-Up integration: In this lowest level sub-modules integrated and tested first then the successively superior level components are added and tested, transiting the hierarchy from the bottom, upwards. Only Test Drivers are used to simulate the components of higher layers. No stubs are required in this approach. An advantage of this approach is that Interface faults can be more easily found. Disadvantages of this approach are Components of the User Interface are tested last and Faults found in the top layer may lead to changes in the subsystems of lower layers, invalidating previous tests. 3.5 Different issues in component integration In a component-based software product line, programs are built based on a set of software components. There are two factors, which affect the complexity of component integration. The first is the number of involved components. The other is the customization capability of components. Several issues in component integration are listed below: Difficulty to form integration test suites based on component test suites: There are two reasons. Constructing test suites in an ad-hoc manner is the first one, which causes inconsistent test information format, diverse access mechanism, and different data store technology. These affect the reuse of test suites for component integration. The other cause is the lack of test selection methods to build integration test suites based on component test suites. Most existing techniques focus on the selection of white-box tests based on program structures, such as control flow or data flow. However, they are not applicable for selecting black-box tests for component integration and re-integration due to the following facts. • Component integration focuses on a) the interactions between components at the component level, b) the integrated structures of components, and c) the integrated 17
  • functions based on customized components. Thus, test generation and test selection methods must address their integrated functional features at the component level. • The interactions and relationships between components are much more complicated than the interactions between procedures when communications and multithreading are involved. Therefore, we need new systematic methods a) to identify and select tests from black-box component test suites to form integration test suites, and b) to select tests from an integration test suite for regression testing. High cost on building integration environments. In the component engineering paradigm, a product is constructed based a number of components. Each product is the integration result of a set of customized components according to the given requirements. Therefore, as the number of components increases, the number of component integrates also increases. Building an integration environment for a component-based software system is difficult and expansive due to the ad hoc construction of component test drivers and stubs. 3.6 Features to be tested Integration testing should be concerned only about interfaces Thus, to design test cases effectively and efficiently; we need a detailed description of the internal interfaces of the system. Needed Interface information can be obtained from: • Communication protocols • Subsystem definitions • Sequence and collaboration diagrams • Call-pairs and their argument lists • Lists of events to be processed by the system • Definition, use, and flow of global data 18
  • • Failure handling and recovery processing in components. For example special cases at interfaces (data not available, data in improper format, empty files, network unavailable, etc.) 3.7 Integration Faults The interaction-related faults can be classified into programming-related faults, which are intercomponent faults, and nonprogramming-related faults, which are interoperability faults. Faults that are overlooked during unit testing can be identified during integration testing and are classified as traditional faults. • Intercomponent faults: Even when the individual components have been evaluated separately, there can still be faults in the interactions between them. Programming-related faults that are associated with more than one component are considered to be intercomponent faults. • Interoperability faults: Many characteristics of component-based systems, such as heterogeneity, source code unavailability, and reusability, will lead to different types of interoperability problems. These interoperability problems can be classified into system-level, programming-language level, and specification-level interoperability faults. 1) System-level interoperability faults: In a component-based system, different components can have been built under different infrastructures, and the infrastructures may not be 100% compatible. For example, incompatibility between different CORBA products can affect the interaction between CORBA components. 2) Programming-level interoperability faults: When components are written in different programming languages, incompatibility between the languages may cause problems. For instance, Microsoft supports the integration of VC and VB components. But the floating-point incompatibility may cause interoperability faults. 19
  • 3) Specification-level interoperability faults: Specifications may be misinterpreted by developers, and there are many different ways that specifications may be Misunderstood. This type of fault can be caused by the data that pass through the interfaces or the patterns of the component interactions • Traditional faults and other faults: Traditional testing and maintenance techniques can be adopted for those faults that can be isolated within one component. These faults will be identified as traditional faults. Other faults, such as faults related to special-input or special-execution environments, also fall into this category. 3.8 A test Model for integration testing of components based software To test component-based software adequately and effectively a test model is described. In test Model there are different test elements that are likely to reveal integration faults. Given a test element a family of test adequacy criteria is then provided. Test elements: During integration testing, test model emphasizes interaction between components. A component may interact with other components directly, through an invocation of interfaces exposed by those components, an exception or a user action that triggers an event. A component may also interact with other components indirectly through a sequence of events. The elements that need to be taken into account in component-based testing are: Interfaces: Interfaces are the most common ways to activate components. Therefore, it is necessary during integration and system testing to test each interface in the integrated environment at least once. Events: Testing interfaces provides confidence that every interface that is possibly invoked during run time has been exercised at least once. This scenario is similar to the traditional test criterion that requires every function or procedure to be tested at least once. However, an interface invoked by different components within different contexts may have different outcomes. Thus, to observe possible behaviors of each interface 20
  • during runtime, every invocation of the interface needs to be tested at least once. Moreover, some events that are not triggered via interfaces may have an impact on the Components, which need to be tested as well. Therefore, every event in the system regardless of its type needs to be covered by some test. Context-dependence Relationships: Interface and event testing ensure that every interaction between two components, the client and the server, is exercised. However, when execution of a component-based software system involves interactions among a group of components, the sequence of event triggering may produce unexpected outcomes. To capture the inter-relationships among events, we define a context dependence relationship that is similar to the control flow dependence relationship in traditional programs. Context-sensitive dependence relationships include not only direct interactions, but also the indirect collaboration relationships among interfaces and events occurring through other interfaces and events as well. Therefore, testing context-sensitive dependence relationships may serve to identify interoperability faults caused by improper interactions among different components. Content-dependence Relationships: An invocation of an interface of a component is in fact an invocation of a function implemented by the component. Therefore, when a function declared in an interface v1 has data dependence relationship with another function declared in another interface v2, the order of invocation of v1 and v2 could impact the results. A content-dependence relationship exists between two interfaces v1 and v2 if the two interfaces have a data-dependence relationship. 21
  • Chapter 4 Literature Survey Component based technology is increasingly adopted to speed up the development of complex software through component reuse. Yet, improved reuse and reduced cost benefits from software components can only be achieved in practice if the components provide reliable services, which makes component analysis and testing a key activity. The crucial problem is the lack of information for analysis and testing of components. Several component integration-testing techniques have been proposed to provide a solution for these issues. Ye Wu1 and Mei-Hwa Chen2 and Jeff Offutt suggested UML-based Integration Testing for Component-based Software UML, a modeling language, has been widely adopted in component-based software development process as a tool for capturing component relationships. Many of its useful tools, such as Collaboration diagrams, statechart diagrams, and Sequence diagrams, characterize the behavior of a component in various aspects, and thus can be used in testing component-based systems. In the UML, Collaboration diagrams and Sequence diagrams are used to represent interaction among different objects in a component.Statechart diagrams are used to characterize internal behaviors of objects in a component. There are several advantages to adopting the UML.First, the UML provides high-level information that characterizes the internal behavior of components, which can be processed efficiently and used effectively when testing. Second, the UML has emerged as the industry standard for software modeling notations and various diagrams are available from many component providers. Third, the UML includes a set of models that can provide different levels of capacity and accuracy for component modeling, and thus can be used to satisfy various needs in the real world. But the main Drawback of this approach is that the diagrams in the UML do not describe the precise semantics of a system, and therefore the corresponding test cases are less 22
  • rigorously generated. The activity diagrams in UML do not support nondeterministic mechanism useful for modeling of systems either [11]. Sami Beydeda and Volker Gruhn.et al proposes an approach for “integration testing” that explicitly takes into account the testing relevant features of component based software and thus allows more rigorous testing. The basic constituent of this approach is graphical representation combining black and white box information from specification and implementation. The graphical representation can then be used for test case generation. But this technique has one flaw that is very time consuming approach and there is no provision of automatic test case generation [9]. Yuting Chen, Shaoying LIU and Fumiko Nagoya suggested an approach to testing programs based on Data Flow Specification by analyzing data flow paths and discussing criteria for test case generation. This approach suggests a specific Way to generate test cases directly from formalized data flow diagrams and the associated textual specifications. A path oriented approach is used for integration testing of programs based on a conditional data flow diagram (CDFD).CDFD are adopted to describe the architecture of specification. The idea in this approach is to select path from CDFD to cover all branches of the control structures and process functions and then to generate test cases using the constraints defined by textual specifications. Drawback of this technique is that it is extremely difficult to correctly select data flow paths and to generate test cases based on data flow diagrams [12]. Different kind of approach, self-testing was suggested by Fevzi Belli et.al . It is widely accepted that conventional test methods are not necessarily adequate for testing of component-based software. Also conventional test tools cause same problem for the automation of the test automation of CBS, because the knowledge about the implementation of the CBS are essential to run the tests. The component manufacturer on the other hand is not willing to provide the component source code. This technique 23
  • introduces the framework for the automation of user oriented component testing that significantly reduces the test cost and it is based on black box testing and utilizes common features of commercial capture / playback tools. The novelty of this approach is the framework that enables automatic generation of test cases and test scripts without involving domain knowledge and knowledge about object code. However it also reveals a weakness, if the CBSUT is changed, e.g., produce a new release, the test frame, i.e., the test case, and consequently, the test script might become obsolete. So component model needs to be automatically updated [3]. Another technique that is given by Zhenyi Jin and A. Jefferson Offutt is based on software- coupling. Coupling between two units reflects the interconnection between units; faults in one unit may affect the coupled unit. Coupling is ordered into eight different levels according to their effects on the understandability, maintainability, modifiability, and reusability of the coupled units. The coupling-based testing criteria are based on the design and data structures of the program and on the data flow between the program units. The underlying premise of the coupling-based testing criteria is that to achieve confidence in the interfaces between integrated program units, we must ensure that variables defined in caller units be appropriately used in called units [13]. Antonia Bertolino, Paola Inverardi, Henry Muccini, Andrea Rosetti proposed An Approach to Integration Testing Based on Architectural Descriptions. Descriptions of the software architecture can be useful to drive integration testing, since they supply information about how the software is structured in parts and how those parts interact. Therefore a formal architectural description is used to model the “interesting” behavior of the system. Starting from a formal description of the software architecture, A graph of all the possible behaviors of the system in terms of the interactions between its components is shown. This graph contains altogether the information we need for the planning of integration testing. On this comprehensive model, we then identify a suitable set of reduced graphs, each highlighting specific architectural properties of the system. These 24
  • Reduced graphs can be used for the generation of integration tests [2]. 25
  • Chapter 5 Implementation of Component Based Testing Techniques 5.1 UML-based Integration Testing for Component-Based Software UML (Unified Modeling Language) is a tool for capturing component relationships. Without source code, we can obtain the specifications of interfaces and events; however, context-dependence relationships and content- dependence relationships would be difficult to derive without a sophisticate mechanism. These two elements are much more effective than others in detecting component integration faults. Therefore, it is important to develop a methodology to obtain these two elements from the available resources other than the source code. UML, a modeling language, has been widely adopted in component-based software development process. Many of its useful tools, such as interaction diagrams, state chart diagrams, and component diagrams, characterize the behavior of a component in various aspects, and thus can be used in testing component- based systems. Component Bank server component is used in which different interfaces and events are described. We have described context-dependence and content dependence relationships of different transactions and account validation. Implementation: Context-dependence relationships: Context-dependence relationships, which model how interfaces and events interact, can be derived through one of the following different approaches: Collaboration/sequence diagram based approach: The sequence diagram only shows one of the possible scenarios ordered by time while the collaboration combines all scenarios in numbered order. Collaboration diagram and one sequence diagram of a Bank sever component can be described as: 26
  • W1 Choice W5 W2 W5A W5A.1 W6 W4 W3 Accou W3A Log W3b W4A W4A.1 W1- main menu W5- available balance response W2- Enter ID and Password W5A- Insufficient Balance W3-Valid Account data W5A1- Withdrawal response (insufficient balance) W3A- Invalid Id W6- Withdrawn successful message W3B- ID/ Password doesn’t match W4 Enter amount to withdraw (ID, Password) W4A- Log Transaction W4A 1-Update Balance Figure 5.1.1 Collaboration diagram of Bank Server Component Choice Menu Account Transaction Log Entry USER W1 W2 W3 W4 W4A, w4A.1 W5 W6 27
  • Figure 5.1.2 Sequence diagram of Bank Server Component Test Module Test Case Test case Test steps Test data Expected Results case Interfa Title Objective ID ce W1 Main Display Menu To Check menu Is Run program Menu Choice menu is Displayed properly Function displayed correctly and accepting the input correct way W2 Account Accept ID Check accepting Call account interface Id/pwd Id/pwd entered /pwd Id/pwd which accept Id/pwd field without any problem W3 Account Validate Validate accepted Verify Id/pwd Id/pwd If the id/pwd match ID/pwd Id/pwd field found it return success and go to next step otherwise it will go back to choice menu W4 Transact- Accept Accept the Accept Input choice Choice amt Accept the input ion Transaction transaction type ‘W’ for withdraw, choice and amount and perform the ‘d’for deposit’s’ to for successful operation view account transaction accordingly summary and amount in case of selected choice is w/d W5 Transact Insufficient If the balance is Compare amount Available If wdl amt is more -ion Balance less than amount entered with amt than available then entered give an available balance prompt a msg error msg insufficient balance W6 Log Log Record the Write account id, Account id, Data written Transaction transaction Transaction id, Time, transaction successfully and a amount withdrawn, id, time, msg will be displayed available balance in amt for Successful log file withdrawn, transaction available balance Table 5.1.1 Test cases for context collaboration diagram Statechart based approach: The behavior of component more precisely modeled by combining the collaboration diagram with the statechart diagrams which are used to describe state-dependent control objects in components. With the help of statechart diagram we can see exit sequence needs to be validated in four different scenarios 1) 28
  • Waiting for user choice 2) Waiting for A/c & PWD 3) Valid A/c & PWD 4) Waiting for Transaction Type. 1 Display Menu Choic e 1.1 B Exit 1.1 A Exit chosen 1.1Enter Input 2.3 A Exit chosen Input Displ 2. 3 Valid A/C choice 2.1A/C No 2.1 A and Password Invalid 2.4* Enter 2.4.1A insufficient Transaction funds A/c Pwd Type wdl/dep 2.4.1 B Display Msg Accoun Trans 2.5 Transaction action Successful 2.5A Display Message 2.6 Update Balance Log Entry Figure 5.1.3 Collaboration diagram of Bank Transaction Component 1, 1.1 Choice 1.1A, 1.1B Waiting for 2.1 Waiting for 2.1A 2.3 2.3 A Valid A/c & 2.4 29 Waiting for Transaction Type
  • Test Module/I Test Case Test Case Test steps Test data Expected Case nterface Title Objective Result ID W1 Main display menu User can exit waiting for escape key Control will from program user choice- come out from Press exit program key W2 Account invalid ID/Password enter wrong Id,password user ID/Password match not Id or field id/password found exit from password accepted & transaction verfied they are entered wrongly, exit to main menu W3 Transactio cancel user can cacel accept choice choice will exit from n transaction the transaction to cancel transaction & move to transaction interface & main choice control will menu move back to main menu Figure 5.1.4 State Chart of Exit Event Table 5.1.2 Test cases for context Statechart diagram Content-Dependence relationship: Context dependence relationships may depict the interactions within each of the interfaces, but the content-dependence relationships across the interfaces cannot be obtained. The component includes two interfaces-withdraw and deposit interface. For instance, the withdrawal interface depends on deposit interface because deposit transaction will modify the account entity, while withdrawal transaction will use that entity to verify whether there is enough money in that account. it can be obtained through: a) Collaboration diagram approach: collaboration diagram can demonstrate the dependence relationships between two interactions. Collaboration Diagram Withdraw Deposit 30 Ai+1 Bj+ 1
  • Bj Test Module/ Test Case Test Case Test steps Test data Expected Case Interface Title Objective Result ID Ai Withdraw Update Withdraw Choose the Available,amt Balance field Balance interface withdraw updated depends on transaction successfully deposit type. only if there is interface. If And sufficient there is available balance sufficient balance balance then accordingly only we can withdraw Bi Deposit Update deposit Choose amt Balance field balance available deposit updated balance will be Transaction successfully updated type Ai Figure 5.1.5 Collaboration diagram of Bank Component Table 5.1.3 Test cases for Content collaboration diagram Statechart Diagram approach Statechart diagrams are able to demonstrate content dependence relationships from a state transition point of view. The rationale lies in the fact that if interface I1 depends on I2, the state of the component is S1 after the execution of I1.When executing interface I2, the state transitions from S1 to S2 depend on state S1 and the invocation I1. State Chart Diagram showing dependence relationship (in transaction interface I2 the state of available balance changed to S2 from S1 in interface I1) I1:: Account I2::Transaction Interface Interface Available balance Withdrawal/ Deposit Update S1 S2 31 Display available Available Display A/c S1 S2
  • Test Module/ Test Case Test Case Test steps Test data Expected Case Interface Title Objective Result ID T1 Account/ Update if entered amount Perform Available,a Available Transaction Balance for withdraw Valid mt balance field transaction is less Transaction value changed than available and valid the available balance field value will be changed from state s1 to s2 T2 Account/ No change If display summary Choose Available Transaction in Balance is chosen then there display Transaction Balance field won’t be any effect summary type, does not on available balance Available change its it will remain in the state same state Figure 5.1.6 Statechart diagram Table 5.1.4 Test cases for Content State chart diagram Results UML provides high-level information that characterizes the internal behavior of components, which can be processed efficiently and used effectively when testing. The activity diagrams in UML do not support nondeterministic mechanism useful for modeling of systems either. With the Use of UML based integration testing it is very difficult to draw diagrams manually. 32
  • Chapter 6 Unified Modeling Language (UML) 6.1 Introduction Unified Modeling Language (UML) is used by number of software developers as a basis for design and implementation of their component-based applications. The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML is very important part of developing objects oriented software and the software development process. However, only little part of UML is used for Testing. This is an important issue, because in many software development organizations, the cost of testing can account for more than 40% of the total development cost for a software system. UML models offer a lot of information that should not be ignored in testing. By combining different UML components, different views of the program under test are used. We address UML-based testing specifically; we address this under two guidelines: 1) We aim at a test method that is entirely based on UML, so that it can be easily adopted by industries already using UML. 2) We refer to high level descriptions of the system: we want to address test planning for the integration test phase starting from the very first stages of system design. Modeling languages are used to get the specification and generate test cases. Since UML (Unified Modeling Language) is the most widely used language, many researchers are using UML diagrams such as state-chart diagrams, use-case diagrams, sequence diagrams, etc to generate test cases and this has led to Model based test case generation. The UML • Is a Language: it is not simply notation for drawing diagrams, but a complete language for capturing knowledge about a subject and expressing knowledge regarding the subject for the purpose of communication. 33
  • • Applies to Modeling the systems: Modeling involves a focus on understanding (knowing) a subject (system) and capturing and being able to communicate this knowledge. • Is used for specifying, visualizing, constructing and documenting systems. • Is based on the object oriented paradigm. • Is an evolutionary general purpose, broadly applicable, tool supported, industry- standardized modeling language. • Applies to a multitude of different types of systems, Domains and methods or processes. 6.2 Goals of UML If we are working on a software development team, we need to have a specific standard. If we don't have a standard for your software development, it is very likely that our final product will be riddled with problems. This is something that a team must avoid at all costs if we wish to be successful. Primary goals of UML are: • When a team uses a specific standard, they will have high levels of communication. UML is a tool that can allow you to maintain (tool to maintain) this standard. It is the tool of choice for those who work in the software development industry, and it doesn't matter if the team is separated by thousands of miles. UML will give them the platform which will allow the team to build a powerful application. • Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. • Be independent of particular programming languages and development processes. • Support higher-level development concepts such as collaborations, frameworks, patterns and components. • Encourage the growth of the OO tools market. • Provide extensibility and specialization mechanisms to extend the core concepts. 34
  • • The UML diagrams are designed in such a way that they can be used for strong communication. In addition to communication between the development team, applications designed with UML will more efficient for the end user. 6.3 The Building Blocks of UML Each UML diagram is designed to let developers and customers view a software system from a different perspective and in varying degrees of abstraction. UML diagrams commonly created in visual modeling tools include: Use Case Diagram: Displays the relationship among actors and use cases. Class Diagram: Models class structure and contents using design elements such as classes, packages and objects. It also displays relationships such as containment, inheritance, associations and others. Interaction Diagrams • Sequence Diagram displays the time sequence of the objects participating in the interaction. This consists of the vertical dimension (time) and horizontal dimension (different objects). • Collaboration Diagram displays an interaction organized around the objects and their links to one another. Numbers are used to show the sequence of messages. State Diagram displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli, together with its responses and actions. Activity Diagram displays a special state diagram where most of the states are action states and most of the transitions are triggered by completion of the actions in the source states. This diagram focuses on flows driven by internal processing. Physical Diagrams • Component Diagram displays the high level packaged structure of the code itself. Dependencies among components are shown, including source code components, binary code components, and executable components. Some Components exist at compile time, at link time, at run times well as at more than one time. 35
  • • Deployment Diagram displays the configuration of run-time processing elements and the software components, processes, and objects that live on them. Software component instances represent run-time manifestations of code units 6.4 Model View of UML—put it below the model Implementation View Structural View Class / Object Component Diagrams Diagrams Use Case Diagrams Sequence / Collaboration / Deployment Diagrams Statechart / Activity Diagrams Environmental View Behavioral View Figure 6.1.1 Model view of UML • The Use Case View of a system encompasses the use cases that describe the behavior of the system as seen by its end users, analysts and testers. With the UML, the static aspects of this view are captured in use case diagrams. • The Structural View of the system encompasses Class and Object Diagrams. These diagrams depict all the classes and objects that will be used in the development of the application. 36
  • • The Behavioral View of the system encompasses the dynamism of the Classes and Objects. The dynamism of classes and objects are captured in Sequence, Collaboration, Statechart and Activity Diagrams. • The Implementation View of a system encompasses the components and files that are used to assemble and release the physical system. This view primarily addresses the configuration management of the system’s releases, made up of somewhat independent components and files that can be assembled in various ways to produce a running system. • The Environmental View of a system encompasses the nodes that form the system’s hardware topology on which the system executes. This view primarily addresses the distribution, delivery and installation of the parts that make up the physical system. 6.5 Software Testing and UML Testing often accounts for more than 50% of the required effort during system development. However, testing is often not well integrated with other development phases. One reason for this is that designers, developers and testers all use different languages and tools, making it difficult to communicate with each other and to exchange documents. The UML Testing Profile bridges the gap between designers and testers by providing a means to use UML for test specification and modeling. This allows the reuse of UML design documents for testing and enables test development in an early system development phase. UML is basically used to model the interaction of various components and code in the whole system we can check the UML diagrams to understand the various types of information gathering like third party interaction etc and then form the test plan accordingly. This way we can minimize the efforts to write the test plans. When using UML in the software testing process, we will focus primarily on the diagrams in the Behavioral Elements package. This is because most of the activities in software testing seek to discover defects that arise during the execution of software 37
  • System and these defects are generally dynamic (behavioral) in nature. However, there are cases where the behavioral information will need to be augmented with static information typically found in the Foundation package. There are many phases in the testing process, including unit, function, system, regression testing. The following table illustrates the differences between these phases, as well as the potential UML diagram for use in the phase. Test Type Coverage Criteria Fault Model UML Diagram Unit Code Correctness,error Class and state diagrams handling,pre/post conditions,invariants Function Functional Functional and API Interaction and class behavior,integration issues diagrams System Operational Scenarios Workload Use case, activity and contention,recovery interaction diagrams Regression Functional Unexpected behavior from Same as Function new changed function Table 6.1.1 Testing phases and UML Diagrams UML is a language that has a number of potential industry applications. In addition to those who work in the software development field, UML is also beneficial to engineers. It is an excellent language for architects and designers as well. While UML may seem amazingly simple on the outside, it is very rich, and it has a large number of visual elements. It is virtually impossible to memorize all the elements of UML. 38
  • Chapter 7 Related Work The integration testing of OO software is concerned with testing the interactions between units. Traditional testing strategies for procedural programs, such as control flow analysis cannot be directly applied to OO programs. In object-oriented software development, Unified Modeling Language (UML) provides the possibility to describe systems from different perspectives e.g. static view by class diagram; dynamic by interaction and state chart diagrams, etc. The combination of expressiveness and versatility of UML has enabled the Paradigm to become very popular recently. Testing UML design models is challenging because a design model consists of many models that describe different design views. An approach to generating inputs for testing UML design requires a mechanism that combines information from both the structural and behavioral views of a design. Various approaches relating to integration testing of software have been proposed. Basanieri and Bertolino used a User Interaction Testing (UIT) model to perform integration testing. A UIT is generated from use cases and UML sequence diagrams. It basically aims at integration testing to verify that the pre-tested system components interact correctly. They use category partition method and generate test cases manually following the sequences of messages between components over the Sequence Diagram. Use case diagrams are used to identify the suitable steps of an incremental test strategy. For each identified sub Use Case, sequence diagrams are used to identify relevant components or “Test Units”. For each Test Unit, relevant interactions and settings (could be parameters, variables) are identified. After that test cases are generated whereby each test case is characterized by a combination of all suitable choices of the involved settings and Interactions. This approach is very simple and easy portable to industrial contexts. since in this approach only UML diagrams are used the methods does not require specialized expertise and analysis, and so generation of test cases can be done with project development, at no or little extra cost. However method is manual therefore requires lots of efforts and time for testing. Also exclusive use of UML diagrams can be considered a limit to 39
  • this method, because as known UML semantic is not very precise, therefore diagrams can have different interpretations from different users [6]. Trung T. Dinh-Trong, Sudipto Ghosh, Robert B. France proposed an approach to generating inputs to test UML design models that are produced in the detailed design phase of an Model driven development (MDD) project. A symbolic execution based approach is used to derive test input constraints from the paths of a Variable Assignment Graph, which integrates information from UML class and sequence diagrams. The VAG is used to derive test input constraints that are then solved by the constraint solver, Alloy. Model Driven Development (MDD) approaches tackle the complexity of developing large software systems. In MDD, abstract logical models are systematically transformed to detailed design models. If a detailed design model contains faults, those faults are passed to the code if not detected and corrected before the transformation. The novelty of this approach is that it considers both constraints on variables with primitive datatypes and constraints on object configurations characterized by the class diagram view of a system. In this Testing begins when a tester provides a UML design model under test (DUT). A DUT consists of (1) a class model specifying structural aspects of the system, (2) sequence diagrams that each models the interaction between objects when a system operation is executed, and (3) activity diagrams that specify the behavior of operations. A system operation is an operation of the system that executes in response to an external input event generated by an actor to the system. Test inputs are derived from DUT class and sequence diagrams, and used to test an executable form of the DUT.During test execution, a set of failure conditions are checked. The transformation of the UML diagrams into VAGs, the transformation of the constraints into Alloy, and the generation of the path constraints are based on systematic rules, and thus are potentially automatable. But it is very complex approach to generate test inputs [17]. 40
  • 41
  • Chapter 8 A Systematic Approach for Integration Testing from Sequence Diagram 8.1 Introduction In a typical software development project, more than 50% of the software development effort is being spent on testing. Quality of the end product and effective reuse of software depend to a large extent on testing. Correct functioning of object-oriented software depends upon the successful integration of classes. While individual classes may function correctly, several new faults can arise when these classes are integrated together. Developers therefore spend considerable time and effort to achieve thorough testing. Creation of test cases is possibly the most difficult step in testing. Therefore, designing a large number of test cases and carrying out the tests turn out to be very labor- intensive and time consuming. To reduce the testing cost and effort and to achieve better quality software, automatic testing has become an urgent necessity. UML models can be interpreted differently depending on application. Many UML design artifacts have been used in different ways to perform different kinds of testing. For Instance testing of OO systems focuses on the use of class, Interaction or state diagrams. Class diagrams provide information about the public interface of classes, method signatures, and important relationships between classes. Interaction diagrams (collaboration and sequence diagrams) have been used to test class interactions. State diagrams provide information about the behavior of a class (or set of classes.).Modularity aims at encapsulating related functionalities in classes. However, complete system-level functionality (use case) is usually implemented through the interaction of objects. Typically, the complexity of an OO system lies in its object interactions. As a result, complex behaviors are observed when related classes are integrated and several kinds of faults can arise during integration: interface faults, conflicting functions, missing functions. Thus testing each class independently does not eliminate the need for integration testing. A large number of possible interactions between collaborating classes may need to be tested to ensure the correct functionality of the system. 42
  • UML models offer a lot of information that should not be ignored in testing. One of the main problems in testing different components is test case selection. A pragmatic approach is to concentrate on typical message sequences as modeled using the sequence diagram. Testing based on sequence diagrams seems to be intuitive. Each sequence diagram specifies one test case or set of test cases. Each sequence diagram is considered as a set of test cases. In this we present our approach for UML-based Integration Testing that uses Interaction diagrams Specifically the Sequence diagram. 8.2 Integration Testing and Sequence diagrams Ensuring high object interoperability is a goal of integration testing for object-oriented (OO) software. When messages are sent, objects that receive them should respond as intended. Ensuring this is especially difficult when software uses components that are developed by different vendors, in different languages, and the implementation sources are not all available. This essentially attempts to validate that classes, implemented and tested individually, provide the intended functionality when made to interact with each other. The focus at this level is on testing interactions between classes through method calls or asynchronous signals, as well as interactions with databases or hardware. Adequate unit-level testing of individual classes supports but does not produce a reliable integration of group of interacting classes. This is because some of the bugs remain dormant during unit testing and pop-up only after integration for a specific state of the cluster. Hence the need of integration testing is necessary. A sequence diagram describes how groups of objects collaborate in accomplishing some system behavior. This collaboration is implemented as a series of messages between objects. Sequence diagrams are good at showing which objects communicate with which other objects; and what messages trigger those communications. Sequence diagrams are not intended for showing complex procedural logic. Such diagrams capture important aspects of object interactions, and can be naturally used to define testing goals that must be achieved during Integration testing. 43
  • 8.3 UML’s Sequence Diagram A sequence diagram is a form of interaction diagram which shows objects as lifelines running down the page, with their interactions over time represented as messages drawn as arrows from the source lifeline to the target lifeline. Sequence diagrams are good at showing which objects communicate with which other objects; and what messages trigger those communications. Sequence diagrams are not intended for showing complex procedural logic. Lifelines A lifeline represents an individual participant in a sequence diagram. A lifeline will usually have a rectangle containing its object name. Messages Messages are displayed as arrows. Messages can be complete, synchronous or asynchronous. In the following diagram, the first message is a synchronous message (denoted by the solid arrowhead) complete with an implicit return message; the second message is asynchronous (denoted by line arrowhead), and the third is the asynchronous return message (denoted by the dashed line). Figure 8.3.1: Segment of sequence diagram showing message passing 44
  • Guards When modeling object interactions, there will be times when a condition must be met for a message to be sent to the object. Guards are used throughout UML diagrams to control flow. Figure 7 shows a fragment of a sequence diagram with a guard on the message addStudent method Figure 8.3.2: A segment of a sequence diagram in which the addStudent message has a guard Combined fragments (alternatives, options, and loops) A combined fragment is used to group sets of messages together to show conditional flow in a sequence diagram. Alternatives Alternatives are used to designate a mutually exclusive choice between two or more message sequences. Alternatives allow the modeling of the classic "if then else" logic an alternative combination fragment element is drawn using a frame. The word "alt" is placed inside the frame's namebox. Option The option combination fragment is used to model a sequence that, given a certain condition, will occur; otherwise, the sequence does not occur. An option is used to model a simple "if then" statement.Option combination is represented as a frame. The text "opt" 45
  • is placed inside the frame's namebox. and in the frames content area the option's guard is placed towards the top left corner on top of a lifeline. Loops Modeling a repeating sequence is done with the addition of the loop combination fragment.The loop combination fragment is very similar in appearance to the option combination fragment. You draw a frame, and in the frame's namebox the text "loop" is placed. Inside the frame's content area the loop's guard is placed towards the top left corner, on top of a lifeline. Then the loop's sequence of messages is placed in the remainder of the frame's content area. 8.4 The Proposed Approach We have proposed a novel approach of generating test cases from UML design diagrams. Our approach consists of transforming a UML sequence diagram into a graph called the graph of sequence diagram (GOSD) and which consists of nodes and edges. Each node stores information necessary for testing. This information can be taken from class diagrams. We construct the storage graph using C++. The GOSD is then traversed according to generate test cases. The test cases thus generated are suitable for integration testing and to detect interaction faults. Sequence diagrams are drawn with the help of StarUml tool. StarUML is an open source project to develop fast, flexible, extensible, featureful, and freely-available UML/MDA platform running on Win32 platform. The goal of the StarUML project is to build a software modeling tool and also platform that is a compelling replacement of commercial UML tools such as Rational Rose, Together and so on. StarUML supports most of the diagram types specified in UML 2.0. The run-time behavior of an object-oriented system is modeled by well-defined sequences of messages passed among collaborating objects. In the context of UML, this is usually modeled as interaction diagrams (collaboration or sequence). We have proposed an integration testing technique that is based on the idea that the interactions between objects should ideally be exercised while generation of test cases. The main advantage with this approach is that test cases can be generated early in 46
  • the development process and thus it helps in finding out many problems in design if any even before the program is implemented. A test case consists of a test input values, its expected output and the constraints, that is the pre- and post condition for that input values. This information may not be readily available in the design artifacts. As a way out to this problem we propose an automatic test case generation method using UML models. We use sequence diagram as a source of test case generation. The proposed technique can be applied during the integration test phase, right after the completion of class testing. It consists of the following steps: 1) Converting Sequence diagram into a GOSD: A graph for sequence diagram is constructed from sequence diagram. It stores all necessary information for integration testing. 2) Test Case Generation: Graph (GOSD) is traversed to generate all possible paths. Test paths are executed by using manually-generated test data . 3) Result Evaluation: The object states are compared with the expected object states in the test paths generation. If any state of any object after execution of a test path is not in the required resultant state, then the corresponding test case is considered to have failed. 47
  • Graph of Test Paths Sequence Diagram SEQUENCE Result Generator Diagram Evaluator (GOSD) Pass/Fail Figure 8.4.1 Schematic representation of our approach 1. Converting Sequence diagram into a GOSD: In this part of our approach we construct the GOSD using the C++. The minimum requirement for the storage graph is window 98 or higher version and minimum 32 MB RAM. A sequence Diagram can be Represented as a Graph. The graph models all possible Interaction among the different objects in diagram. Definition of GOSD: Graph of Sequence diagram consists of states each state is assumed to be vertex of graph. Transition from one state to another depending on the input/applicable method with signatures is given by an edge of graph. Two way list is used to implement the graph with linked representation. GOSD :{ V, E} where 1) V is Vertex of graph. Vertex node consists of following info: State id ISinitial ISfinal Pointer Next Pointer to first vertex(Next edge(edge root) vertex) Initial and Isfinal are treated as Boolean types which gives the information about the state whether it can be initial and /or final. Stateid is correct state id and this vertex store the address of next vertex in the list. Pointer to first edge store the address of first node in the edge list. Each vertex is provided a separate edge list. Which store the outgoing edges from that vertex. 48
  • 2) The Edge node is as follows: Message Sender(from Receiver(to Attributes condition Name object) object) Algorithm of graph Construction: Adding State: A new State can be added in a graph .create new state let it be Newstate. Input the state parameters .Set pointer toedge=NULL .Set Next State pointer = NULL tmp =ROOT // temp be a pointer to vertex If ROOT=NULL ROOT=New State Else { While tmp->Next Vertex#NULL Tmp=tmp->NextVertex Temp->NextVertex=NewVertex } End if ADDITION EDGE/TRANSITION Create a new edge let it be Newedge. Input edge parameter and pre condition. Input method and method parameter with sender Receiver. Input source vertex. Let tmp be a State and temp=root While tmp->stateid#sourcevertex.stateid and tmp#NULL { Tmp=tmp->NextVertex } If (tmp=NULL) 49
  • Display message “Source Vertex not found” Else { If (tmp->edgeRoot=Null) Tmp->edgeRoot=NewEdge Else { Tmpedge=edgeRoot; While (tmpedge->NextEdge#NULL) Tmpedge=tmpedge->NextEdge tmpEdge->Nextedge=NewEdge } } End if 2. Integration test case Generation A sequence diagram represents various interactions possible among different objects .A test set is therefore necessary to detect faults if any when an object invokes a method of another object and whether the right sequence of message passing is followed. From the GOSD we can cover all paths from the start node to a final node and it can cover all interactions as well as all message sequence paths. Given a test set T and a sequence diagram D; T must cause each sequence of message path exercise at least once.To generate test cases that satisfy the criteria, we first enumerate all possible paths from the start node to a final node in the GOSD. Each path then would be visited to generate test cases. Test Strategy is used to detect Interaction faults. Several faults such as incorrect response to a message, correct message passed to a wrong object or incorrect message passed to the right object, message invocation with improper or incorrect arguments may occur in an interaction. 50
  • Algorithm: TestSetGeneration Let T be the test case input and S be a set of states. Let ‘TRANS’ be the set of transition in sequence diagram. Now, to undergo integration testing we will have to match the test input T’s attributes and test case is declared as PASS if all the attribute, of any transition in ‘TRANS’. For each s1 state in S // loop that will traverse each sate in Sequence diagram For each transition t1 in TRANS // loop that will traverse each transition of current state If t1.attributes= T.attributes then // condition that compares the attributes of test Case input and transition of sequence diagram Result = “Test is passed” Else Result= “Test Failed” CheckReason (t, T) // to find the reason of failing test Endif // CheckReason function to check the integration faults CheckReason (TRANS t1, testinput T) If (t1.sender <> T.sender) then Display “wrong sender” Elseif (t1.receiver <> T.receiver) then Display “wrong receiver” Else if (t1.argumenttyrpes <> T.values) then Display “invalid arguments/message” Else if t1.returntype <> T.returntype then Display “invalid response” Endif. 51
  • 52
  • Chapter 9 þÇ Æ_ÒYÆ_É&¾«¿_×&×_¾ËÆ_¿_ÌqÎ2_ Implementation and Experiment We performed three pilot studies to 1) demonstrate the interaction related faults using our approach and 2) explore the performance of our approach. We applied our design testing approach to ATM PIN validation component, Ticket selling System and automatic Registration Component. In order to validate the effectiveness of our proposed approach, we implemented a c++ program to store sequence diagram into a graph called graph of sequence diagram and after that using Test case generation algorithm test cases are generated to find out integration faults. The minimum requirement for the storage graph is window 98 or higher version and minimum 32 MB RAM. 9.1 Implementation with PIN Authentication Component: PIN Authentication component of ATM card is taken. In this component ATM card is checked if card is valid then PIN is verified after that user will get Display message. If card is not valid then it is ejected. Step by Step Implementation of PIN Authentication Component is as follow: 1. Draw Sequence diagram of PIN Authentication Component: Sequence diagram associated with PIN Authentication in a usual ATM System is drawn with StarUml tool. Sequence diagram shows the interaction between different objects like cardreader, sessionmgr, displaymgr, key reader and abank. Also sequence diagram shows the order in which messages are transferred between different objects. This sequence diagram consists of five operation scenarios as shown on next page. 53
  • Figure 9.1.1 Sequence Diagram of ATM PIN Validation Component 2) Transformation of SD into a GOSD In order to formulate a methodology, we define an operation scenario as a quadruple, aOpnScn: <ScnId; StartState; MessageSet; NextState>. ScnID identifies each operation scenario. StartState is a starting point of the ScnId, that is, where a scenario starts. MessageSet denotes the set of all events that occur in an operation scenario. NextState is the state that a system enters after the completion of a scenario. This is the end state of an activity or a use case.GOSD has a single start state and one or more end state depending on different operation scenarios. An event in a MessageSet is denoted by a tuple, aEvent: <messageName; fromObject; toObject 54
  • [/guard]> Where, messageName is the name of the message with its signature fromObject is the sender of the message toObject is the receiver of the message and the optional part /guard is the guard condition subject to which the aEvent will take place. An aEvent with * indicates it is an iterative event. Individual aOpnScn of above sequence diagram is shown below: <Scn1 <Scn2 StateX State X S1:(cardinfo(int cardNo),cardreader,sessionMgr) S1:(cardinfo(int S2:(eject(),sessionMgr,Cardreader)|[!validAtmCard] cardNo),cardreader,sessionMgr) State Y> S3:(checkcard(int cardNo,int AccountNo),sessionMgr,aBank) S4:(retain(),sessionMgr,cardReader)|[status Stolen] State Y> <scn 3 S1:(cardinfo(int cardNo),cardreader,sessionMgr) S3:(checkcard(int cardNo,int AccountNo),sessionMgr,aBank) S5: :(eject(),sessionMgr,Cardreader)|[Status close Account] State Y> <scn4 <scn5 State X State X S1:(cardinfo(int cardNo),cardreader,sessionMgr) S1:(cardinfo(int cardNo),cardreader,sessionMgr) S3:(checkcard(int cardNo,int S3:(checkcard(int cardNo,int AccountNo),sessionMgr,aBank) AccountNo),sessionMgr,aBank) S6:(requestPIN(int S6:(requestPIN(int PinNo),sessionMgr,DisplayMgr)|[!validPIN PinNo),sessionMgr,DisplayMgr)|[!validPIN &&try<4] &&try<4] S7:(readPIN(int PinNo),sessionMgr,KeyReader)|[!validPIN S7:(readPIN(int &&try<4] PinNo),sessionMgr,KeyReader)|[!validPIN S8:(verifyPIN(int PinNO),sessionMgr,ebank)||[!validPIN &&try<4] &&try<4] S8:(verifyPIN(int S9:(eject(),sessionMgr,cardReader)|[!validPIN] PinNO),sessionMgr,ebank)||[!validPIN State Y> &&try<4] S10:(displayHello(),sessionMgr,displayMgr) State Z) Table 9.1.1 Five operation scenarios represented in the form of quadruples 55
  • Initially GOSD contains only the StartState.We then add each aEvent of all aOpnScn followed by its corresponding NextState, and remove duplicates, if any. C++ program is used to Store all the information from UML Sequence diagram to GOSD. 3) Integration Test Case Generation: A test case, t, is generated using information from the sequence diagram, sd. The test case t is used to test one of the scenarios that is specified by sd.The set of all inputs generated from sd is used to test a variety of scenarios specified by sd.In order to produce test Input GOSD needs to contain information as shown above 1) the order in which messages are sent 2) how variables are changed when sequence diagram messages are received and handled 3) what objects and links need to exist for messages to be sent. In order to generate Test cases for Integration testing c++ program is used that will traverse the graph using depth-first traversal to enumerate all paths in a GOSD. Test cases that are generated for ATM PIN Validation component are shown below. Test cases can be passed or failed by comparing the values that are entered by user and the values that are traversed from GOSD. TEST OBJECTIVE METHO Parameters SENDER RECEIVER Pre- EXPECTED Status ID D NAME Condition STATE Test1 To chekc Card CardInfo 47115 CardReade SessionMgr s3 TEST Info r PASSED SUCCESSFUL LY Test2 to check card CardInfo 47.471 CardReade SessionMgr S3 TEST FAILED info r : parameter type mismatch Test3 to check valid Eject SessionMg CardReader !ValidAtm Y TEST atm card r Card PASSED SUCCESSFUL LY Test4 to check card Eject CardReade SessionMgr !ValidAtm Y Sender/Receive validity r Card r mismatch Test5 to verify Pin VerifyPin 48557 SessionMg aBank !ValidPin s9 TEST r & Try<4 PASSED SUCCESSFUL LY TEST OBJECTIVE METHO Parameters SENDER RECEIVER Pre- EXPECTED Status ID D NAME Condition STATE Test6 to Read the pin ReadPinC 47778 SessionMg KeyReader !ValidPin s8 Test fail ode r & Try<4 method not found to read pin ReadPin 4788 SessionMg KeyReader !ValidPin s10 TEST FAILED Test7 r & Try<4 : destination 56
  • state mismatch Test8 to retain card Retain SessionMg CardReader StatusStole y TEST r n PASSED SUCCESSFUL LY Test9 To retain card Retain SessionMg CardReader !ValidPin Y TEST FAILED r : condition nto matched Test to check logion DisplayHe 47.655 SessionMg DisplayMgr Z TEST FAILED 10 sucess llo r : parameter mismatch Test To check login DispHello hello SessionMg DisplayMgr Z TEST 11 success r FAILED: METHOD NOT FOUND Test to request for RequestPi 7444 SessionMg keyreader !ValidPin s7 TEST FAILED 12 pin n r & Try<4 : Sender/Receive r mismatch Test 13 To request for RequestPi 74484 SessionMg DisplayMgr !ValidPin s7 TEST pin n r & Try<4 PASSED SUCCESSFUL LY Test 14 to check login DisplayHe SessionMg DisplayMgr Z TEST FAILED success llo r : parameter mismatch Table 9.1.2 Test Run with sequence Diagram of ATM PIN Validation 9.2 Implementation with Ticket selling Component: In this we have taken part of a ticket selling domain model. In which customer may have many reservations, but each reservation is made by one customer .Reservations are of two kinds: subscription series and individual reservation. Both reserve tickets: In one case, only one ticket; in the other case several tickets. Every ticket is part of a subscription series or an individual reservation, but not both. Every performance has many tickets available, each with a unique seat number. A performance can be identified by a show, date and time. Class diagram for above specification is shown as: 57
  • Figure 9.2.1 Class Diagram of Box office application Above class diagram shows several imp classes such as Customer, Reservation, Ticket and Performance After that sequence diagram of ticket selling component is drawn with the help of StarUml tool. 58
  • Figure 9.2.2 Sequence Diagram of Ticket selling component 2) Transformation of SD into a GOSD In above sequence Diagram we have three different objects. Kiosk, box office, Credit card service. Different messages that are passed between objects and their parameters are shown in Sequence diagram. Similar to previous component In order to formulate a methodology, we define an operation scenario as a quadruple, aOpnScn: <ScnId; StartState; MessageSet; NextState> and 59
  • MessageSet is denoted by a tuple, aEvent: <messageName; fromObject; toObject [/guard]> Individual aOpnScn of above sequence diagram is shown below: <Scn1 <Scn2 StateX State X S1:(Request(int count,string perform),Kiosk,boxoffice) S1:( Request(int count,string perform) S2:(showavailability(string seat-list) ,boxoffice,Kiosk)|[!Available] ,Kiosk,boxoffice) State Y> S2: :(showavailability(string seat-list) ,boxoffice,Kiosk) S3:(select(int seats),Kiosk,boxoffice) S4:(Demandpayment(int cost),kiosk,boxoffice) S5:(InsertCard(int Cardno) ,kiosk,boxoffice) S6:(charge(int cardno,int cost),boxoffice,Creditcardservice)|[!authorised] <Scn3 S7:(reject(),boxoffice,Kiosk) StateX State Y> S1:( Request(int count,string perform) ,Kiosk,boxoffice) S2: :(showavailability(string seat-list) ,boxoffice,Kiosk) S3:(select(int seats),Kiosk,boxoffice) S4:(Demandpayment(int cost),kiosk,boxoffice) S5:(InsertCard(int Cardno) ,kiosk,boxoffice) S6:(charge(int cardno,int cost ) ,boxoffice, Creditcardservice) S7:PrintTicket(String Perform,int Seat),boxoffice,kiosk) State Z> Table9.2.1 Three operation scenarios represented in the form of quadruples Initially GOSD contains only the StartState.We then add each aEvent of all aOpnScn followed by its corresponding NextState, and remove duplicates, if any. C++ program is used to Store all the information from UML Sequence diagram to GOSD. 3) Integration Test Case Generation: A test case, t, is generated using information from the sequence diagram, sd. The test case t is used to test one of the scenarios that is specified by sd.The set of all inputs generated from sd is used to test a variety of scenarios specified by sd.In order to produce test Input GOSD needs to contain information as shown above 1) the order in which messages are sent 2) how variables are changed when sequence diagram messages are received and handled 3) what objects and links need to exist for messages to be sent. 60
  • In order to generate Test cases For Integration testing c++ program is used that will traverse the graph using depth-first traversal to enumerate all paths in a GOSD. Test cases that are generated for Ticket Selling component are shown below.Test cases can be passed or failed by comparing the values that are entered by user and the values that are Traversed from GOSD. Test ID Objective Method Name paramet sender Receiver Pre- Expecte Status ers conditi d on State Test1 test seats ShowAvailability “LB 53 BoxOffice Kiosk S3 TEST available B4” PASSED SUCCESSF ULLY Test 2 Request to Box Request 3,”26- Kiosk BoxOffice s2 TEST Office 07- PASSED 08”,4pm SUCCESSF ULLY Test3 check card InsertCard 456.35 Kiosk BoxOffice S6 TEST insertion FAILED : parameter type mismatch Test ID Objective Method Name paramete sender Receiver Pre- Expecte Status rs condition d State Test4 payment DemandPaymen 450 Kiosk BoxOffic S5 TEST FAILED demand t e : Sender/Receive r mismatch Test5 print the tickets PrintTicket “26-07- BoxOffice Kiosk z TEST 08”,”4pm PASSED ”,3 SUCCESSFUL LY Test6 check rejection Reject BoxOffice CreditCar Y Sender/Receive dService r mismatch 61
  • Test7 check rejection Detect BoxOffice Kiosk Y TEST FAILED : method not found Test8 charge money Charge 6544 300 BoxOffice CreditCar Authorize S7 TEST dService d PASSED SUCCESSFUL LY Test 9 Insert card insertcard 4567 boxoffice kiosk S6 TEST FAILED : Sender/Receive r mismatch Test 10 Select seats select 7 kiosk boxoffice S4 TEST FAILED: CAN SELECT MAXIMUM 6 TICKETS Table 9.2.2 Test Run with sequence Diagram of Ticket Selling 9.3 Implementation with Registration System Component: Step by Step Implementation of Registration System Component is as follows: In this we have taken a part of Automated Registration System. A student registers for a class through a web Interface. If student is having logged in then he can directly go for registration procedure but if Student is not already logged in then he has to perform user login procedure. And new student ID is generated. After registration, registered information is given back to student. Sequence diagram associated with Automated Registration system is drawn with StarUml tool. Different Objects and Actors associated with this specification are shown in sequence diagram. In Figure 9.3.1 we have shown Browser, Web Server and DB different objects and student as an actor. Web server further consists of web server, Registration, aStudent, aCourse. Different messages that are passed between different 62
  • objects of sequence diagrams are shown in diagram. Also parameters that are passed are shown. Sequence diagram also represent the Sequence in which messages are transformed. Sequence diagrams are Interaction diagrams that are used to test class interactions. Typically the complexity of component based system lies in its object interactions, not within class methods which tend to be small and simple. As a result complex behaviors are observed when related classes are integrated and several kinds of faults can arise during integration: interface faults, conflicting functions, missing functions. Thus testing each class independently does not eliminate the need for integration testing. A large number of possible interactions between collaborating classes may need to be tested to ensure the correct functionality of system. Sequence Diagram for above Specification is shown on next page. 63
  • Figure 9.3.1: Sequence diagram of Automated Registration System 64
  • 2) Transformation of SD into a GOSD Similar to previous component In order to formulate a methodology, we define an operation scenario as a quadruple, aOpnScn: <ScnId; StartState; MessageSet; NextState> and MessageSet is denoted by a tuple, aEvent: <messageName; fromObject; toObject [/guard]> Individual aOpnScn of above sequence diagram is shown below: <scn1 <scn2 State X State X S1:(BrowseHome(String URL),Student,Browser) S1:(BrowseHome(String URL),Student,Browser) S2:(RequestHome(string URL),Browser, webserver) S2:(RequestHome(string URL),Browser, webserver) S3:(Response(string URL),webserver, Browser) S3:(Response(string URL),webserver, Browser) S4:(select Registerationpage(string URL) S4:(select Registerationpage(string URL) ,student,Browser) ,student,Browser) S5:(RequestRegisterationpage(string URL) S5:(RequestRegisterationpage(string URL) ,Browser,webserver) ,Browser,webserver) S6:(newpage(),webserver,Registerationpage) S6:(Userlogin(String ID,String Pass) S7:(Prepare(),webserver,Registerationpage) ,Student,DB)|[!logged in) S8:(Intialize(),webserver,Registerationpage) S9:(new(int studentID), Registerationpage,astudent) State Y> S10:(GetRegisterationInfo(),Registerationpage,astudent) S11:(GetstudentRegisteration(int studentID),astudent,DB) S12:(return(string data),DB,aStudent) S13:(return(string registerationdata) ,astudent,registerationpage) S14:(response(String data),registerationpage,Browser) State z> Table 9.3.1 Two operation scenarios represented in the form of quadruples 3) Integration Test Case Generation: A test case, t, is generated using information from the sequence diagram, sd. The test case t is used to test one of the scenarios that is specified by sd.The set of all inputs generated from sd is used to test a variety of scenarios specified by sd.In order to produce test Input GOSD needs to contain information as shown above 1) the order in which messages are sent 2) how variables are changed when sequence diagram messages are received and handled 3) what objects and links need to exist for messages to be sent. 65
  • In order to generate Test cases For Integration testing c++ program is used that will traverse the graph using depth-first traversal to enumerate all paths in a GOSD. Test cases that are generated for Automated Registration component are shown below. Test cases can be passed or failed by comparing the values that are entered by user and the values that are traversed from GOSD. Test Objective Method parameters sender Receiver Pre- Expec Status ID Name condit ted ion State Test1 to browse BrowseHo www.home.com Student Browser S2 TEST PASSED home page SUCCESSFULLY me Test2 To request RequestHo www.home.com Browser WebServer s3 TEST PASSED home Page mePage SUCCESSFULLY Test3 to request Requestpag www.home.com Browser WebServer S3 method not found home page e Test4 Initialize Initialize WebServer RegPage S9 TEST PASSED page SUCCESSFULLY Test5 to register GetStudent 103 aStudent DB S12 method not found student Register Test6 to register GetStudent 346 aStudent DB S12 TEST PASSED student Registeratio SUCCESSFULLY n Test7 to open NewPage RegPage WebServer S7 TEST FAILED : new page Sender/Receiver mismatch Test8 Browse BrowseHo 1447 Student Browser S2 TEST FAILED : home page me parameter type mismatch Test 9 Extract return Rich,M.Tech,34 DB aStudent S13 TEST PASSED data 0,70%. SUCCESSFULLY Test ID Objective Method parameters sender Receiver Pre- Expec Status Name condit ted ion State Test10 Response Response www.regiter.co WebServer astudent S4 TEST FAILED from server m : destination state mismatch Test11 Get Response www.regiter.co WebServer Browser S2 TEST PASSED Response m SUCCESSFUL 66
  • LY Test12 get Getregist astuden RegPage S11 TEST FAILED registration t : erationin info Sender/Receive fo r mismatch Test 13 To check userlogin Rich,pass astudent DB !logge Y TEST PASSED user login d in SUCCESSFUL LY Test 14 New NewStuden 4558 Registratio DB S10 TEST student t n page FAILED : destination state mismatch Test15 New NewStuden 4558 Registratio aStudent S10 TEST PASSED student t n page SUCCESSFUL LY Test16 Select page selectregist www.register.c student Registration S5 TEST FAILED erationpage om page : destination state mismatch Table 9.3.2 Test Run with sequence Diagram of Registration system 67
  • Chapter 10 Conclusions and Future Work This chapter first starts with evaluation of the Implementation and the chapter ends with the directions for future work. 10.1 Evaluation of Experiment: a) Evaluation of ATM PIN validation Component: We can check the running time of the ATM PIN validation component for producing the final regression test suite. This can be checked with the help of the bar chart. Component ATM PIN validation Total Passed Test Failed Test 14 5 9 16 Execution time: 14 0.0031 14 12 10 9 8 6 5 4 2 0 Total Passed Test Failed Test Series1 14 5 9 Figure 10.1.1 Bar chart of total number of test cases and execution time for ATM component The bar chart shows the total number of the test cases and the shows how many test cases are passed and failed. b) Evaluation of the Ticket-Selling component We can check the running time of the Ticket-Selling component for producing the final regression test suite. This can be check with the help of the bar chart. Component: Ticket-Selling Total Passed Test Failed Test 10 5 5 68
  • 15 Execution Time: 0.0030 10 10 5 5 5 0 Total Passed Test Failed Test Series1 10 5 5 Figure 10.1.2 Bar chart of total number of test cases and execution time for Ticket Selling component c) Evaluation of the Student Registeration component We can check the running time of the Ticket-Selling component for producing the final regression test suite. This can be check with the help of the bar chart. Component: Student Registeration component Total Passed Test Failed Test 10 5 5 20 Execution 16 Time:0.0032 15 10 9 7 5 0 Total Passed Test Failed Test Series1 16 7 9 Figure 10.1.3 Bar chart of total number of test cases and execution time for Registration component 10.2 Summary of the contribution 69
  • In this paper, we have presented a new strategy for integration testing that is based on a storing test information from Sequence diagrams into the form of a graph. The motivation is to exercise interactions between different components. Therefore, it takes into account the states of all objects involved in a sequence diagram to exercise class interactions in the context of integration testing. UML, a Modeling language used as a tool for capturing component relationships. It provides the whole structure of a system with the help of different diagrams The information those are required for the specification of input,output,pre and post conditions etc. of a test case are retrieved from class diagram and Sequence diagram. Diagrams are drawn with the help of StarUML tool. After that graph is traversed and all information is used to generate integration test cases. Thesis describes three Implementations of different software components .The results shows efficiency and less time to generate test cases as compared to manual approach. Future Work Since Integration testing is the most time consuming and expensive part of testing. Commercially available software components are generally packaged without source code and this may cause difficulties in component integration testing. So far we are able to automatic generate test cases from UML sequence diagrams. In a next step the efficiency can be increased by optimizing the number of test cases. As another activity, the case study presented in this paper, though far from simple, may not be representative of an industrial system. Therefore Industrial case studies are required to carefully analyze. So we can further add functionality to our approach by converting diagrams to XML format. . 70