1 / 59

OBJECT ORIENTED SOFTWARE TESTING

OBJECT ORIENTED SOFTWARE TESTING. Literature Review Advanced Software Engineering Gayathri V.R. Kunapuli Karthik V Puttaparthi. OVERVIEW. Introduction to Software Testing Conventional, Object Oriented Testing Methods Issues in Object Oriented Testing Testing Problems

mayor
Télécharger la présentation

OBJECT ORIENTED SOFTWARE TESTING

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OBJECT ORIENTED SOFTWARE TESTING Literature Review Advanced Software Engineering Gayathri V.R. Kunapuli Karthik V Puttaparthi

  2. OVERVIEW • Introduction to Software Testing • Conventional, Object Oriented Testing Methods • Issues in Object Oriented Testing • Testing Problems • Integration Testing and Framework • Black Box Testing Methods • Test Strategies • Design Patterns and Issues • Testing by use of Scenario Templates • Discussion

  3. Introduction to Software Testing Software testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results. The difficulty in software testing stems from the complexity of software: we can not completely test a program with moderate complexity. The purpose of testing can be quality assurance, verification and validation, or reliability estimation. Correctness testing and reliability testing are two major areas of testing. Software testing is a trade-off between budget, time and quality.

  4. Importance of Software Testing Provide confidence in the system Identify areas of weakness Establish the degree of quality Establish the extent that the requirements have been met To provide an understanding of the overall system To prove that the software is both usable and operable

  5. Conventional Testing Methods • Software testing is divided into Black-box testing and White-box testing. • Black-box testing • The internal behavior is not known • The tester only gives the inputs to check for the appropriate outputs • Requires thorough test cases to be provided • It is applicable at all levels such as unit, integration, functional level, system level and acceptance testing

  6. Conventional Testing Methods[2] • White-box testing • The tester has access to the internal code, data structures and algorithms • Requires programming skills of the tester • The tester chooses test case inputs to exercise paths through the code and determines the appropriate outputs. • It is applicable to unit level, integration and system levels.

  7. Conventional Vs OO Systems The structural differences- There are only functions, modules and subsystems in a conventional program whereas there are function members defined in a class, classes, groups of classes and subsystems in OO systems. The behavior of the programs- There is a defined control flow among the active processes in a conventional program. But in an OO program, there are several active processes running on multiple processes to complete a function. Dependencies- In conventional systems, there are data dependencies between variables, calling dependencies between modules, functional dependencies between a module and the variables it computes, definitional dependencies between a variable and its type; on the other hand, OO systems have additional dependencies such as class to class dependencies, class to method dependencies

  8. Object Oriented Testing Within the context of the OO software, the conventional testing methods are applied to the various components of the OO paradigm. Class testing is the equivalent of Unit testing Partition testing- tests partitions made that are based on attributes, state changes, queries etc. Inter-class testing- To test the communicating classes Integration testing- To test the combinations of classes that form software modules ( Class interaction testing) System testing- As always, to test if the requirements are met Regression testing- As before, to check for the correct functionality when newer functions are added

  9. Object State Testing Different from Control flow and Data flow testing Focuses on the State dependent behaviors of the object using finite state machines State of an object is defined as the combination of the attribute values of the object.

  10. Object State Testing • Consists of an object state model, • a reverse engineering tool and • an object state test generation tool • Object state test model is an aggregation of hierarchical, concurrent, communicating state machines i.e., AOSD or COSD • AOSD is a mealy type state transition diagram defined for a single attribute of CUT • COSD is an aggregate of AOSDs and other COSDs.

  11. Object State Testing • State dependent behavior of a derived class is- • A COSD consisting of the AOSDs for its own attributes and the COSD of the parent. • State dependent behavior of an aggregate class is- • A COSD consisting of the AOSDs for its own attributes and the COSDs of the component classes.

  12. Steps in Object State Testing • Selecting the classes to be tested • Generating the AOSDs for the classes, COSDs are aggregates of AOSDs • Generating object state test cases from the AOSDs and COSDs • Generating test data for the test cases • Executing the test cases • Analyzing the test results to identify bugs • Conduct state-based fault analysis to identify possible cause

  13. Issues in OO Methods Testing Encapsulation Issues • Encapsulation requires that classes are only aware of their own properties, and are able to operate independently. • If unit testing is performed well, the integration testing becomes more important. • If you do not have access to source code then structural testing can be impossible. • If you violate encapsulation for testing purposes, then the validity of test could be questionable.

  14. Inheritance Issues • Inheritance is an important part of the object oriented paradigm. • Unit testing a class with a super class can be impossible to do without the super classes methods/variables. Polymorphism Issues • Repeatedly testing same methods. • Time can then be wasted if not addressed. • Potentially can be avoided, and actually save time.

  15. Testing Problems • Antiextensionality – If two programs compute the same function ( semantically close), a test set adequate for one is not necessarily adequate for the other. • General Multiple Change – When two programs are syntactically similar, they usually require different test sets. • Antidecomposition – Testing a program in the context of an enclosing program may be adequate with respect to that enclosing program, but not adequate for other uses of the component. • Anticomposition – Adequately testing each individual program component in isolation does not necessarily suffice to adequately test the entire program. • Flow of control in OO programs – Message passing from one object to another. • Dynamic binding and dependencies.

  16. Testing Problems OO testing problems can be summarized – • Understanding problem – Encapsulation and information hiding features. • Complex interdependency problem – Complex relationships that exist in an OO program. • Object state behavior testing problem – Effect of an operation on an object depends on state of object and might change the state of the object. • Tool Support Problem.

  17. Integration Testing • Verifying the interaction between software components • Architecture-driven • Involves building a system from its components and testing it for problems that arise from component interactions. • Top-down integration • Develop the skeleton of the system and populate it with components. • Bottom-up integration • Integrate infrastructure components then add functional components. • To simplify error localisation, systems should be incrementally integrated.

  18. Integrating Testing Framework • New Integration testing approach for object oriented programs and a prototype tool supporting the testing approach. • TACCLE – Generate test cases from Contract specifications. • UIT – Generate test cases based on Use case and Sequence diagrams. • Framework which accomplishes both test case generation and test execution.

  19. Coordination Contract • Specification mechanism which superposes behavior on components without interfering with their implementations. • Connection established between a group of objects (participants). • Contract, rules and constraints are superposed on behavior of the participants. • Test cases are completely self verifying. • Guarantees independence of contracts.

  20. CDE – Coordination Development Environment • Tool to help develop Java applications using coordination contracts. • CDE translates contracts into java classes, which can be complied with other classes to form a executable application. • We use CDE in our approach to generate code from the contracts and the components under test to form a framework.

  21. Framework Architecture • Purpose of our test approach is to detect faults related with interactions among objects in a system. • Test cases are derived from Sequence and class diagrams.

  22. Integration test process In the approach, • Read UML Diagrams – XML parser tool parses and manipulates the data. • Realize test case in terms of contracts – What to test, how to test defined in the rules of the contracts. • Generate test framework in CDE – Import the components under test and contracts generated by the tool and produce the Java code. • Generate test data – JAT tool generates test data from the sequence diagram . • Develop test driver. • Execute test. This test framework addresses automation of both test case generation and test execution.

  23. Black box Testing Method • As the name "black box" suggests, no knowledge of internal logic or code structure is required. • Based/focused on the testing for requirements and functionality of the work product/software application. • To implement Black Box Testing Strategy, the tester is needed to be thorough with the requirement specifications of the system and as a user, should know, how the system should behave in response to the particular action.

  24. Black Box Testing Methods • Size of software getting huge, difficult to check all parts of source code in white box style during integration or system testing period. • Functional test methods based on requirements specification are used. • Testing method has different approach to specify software requirements. • These methods check different levels of code construct.

  25. Black Box Testing Methods [2] • Different testing methods among Black box testing methods. • Test result will be based on technique specifying requirements and method extracting data. • Loss of time, money and manpower if not a proper method. • Consider combination of Efficient test methods.

  26. Black Box Testing Methods [3] • Results of test methods comparison are related to statement coverage test, branch coverage test and data flow coverage test. • Black box testing methods based on OO specification is a little area of research till date. • Five Sequential Black box testing methods. • Difficult to acquire a uniform of the comparative criterion but number of variables and methods in an object can be applied equally.

  27. Test Methods based on Requirements • Requirements specification is baseline of software project. • Functional requirements uses various forms of requirements such as use case, collaboration diagram etc. • Testing methods compared are using UML specification to select test cases. • Use case Driven Testing, Black Box testing using Collaboration diagram, Testing using Formal Specification ( Object Z & OCL), Testing using Extended use cases.

  28. Use case Driven Testing • Test case Extraction from simple use case diagram. • Describe functions of the system and define the flow of events from those • functions. • Redefine events flow with the graph predefined in natural language for • composing possible scenarios. • Test cases are extracted with adding exceptions. • Algorithm in the system and interaction between programming modules are • not considered. • Only forecast, define and verify possible errors.

  29. Black Box Testing using Collaboration Diagram • Extracts test cases with correlation and messages to display interaction between objects. • Composes sequence of operation’s calling and defines I/O values and test cases for invoking series of message passing.

  30. Testing using Formal Specification Object Z • Test cases are extracted from Object Z specification. • Major classes are listed out. • Transformed to state transition diagram along with transition paths of objects states. • Test scenarios from diagram and check the test data.

  31. Testing using OCL • Responsibility and Authority of objects. • Partition domain of functions and express constraints in OCL. • Analyze relations between objects in partitioned domain. • Divide each object’s components. • Arrange the components and constraint of the objects to make test cases. • Components satisfy their constraints.

  32. Testing using Extended Use Cases • Use Case First. • Compose scenario and extract classes. • Combine scenario and parameters to extract MM path. • Test by setting input events and output events expected.

  33. Experiment of testing ATM • Data Transmission and function selection occur frequently between user and ATM.

  34. Use Case Driven Testing

  35. Testing using Collaboration diagram

  36. Test cases extracting from Collaboration Diagram

  37. Testing based on Object Z

  38. Testing using OCL • State Attribute has information of transaction about what ATM serves for user. • List of test data is the value of state attributes. • Pstate1 – START_STATE Pstate2 – PIN_STATE • Pstate3 – ACCOUNT_STATE Pstate4 – TRANSACT_STATE • According to the calling of a method, check the value of states.

  39. Extended Use Cases Use Case Test Cases

  40. Results of Experiments

  41. Coverage Analysis • Combination of efficient test methods improves the performance of software testing.

  42. Test Strategies • Defined as order to unit testing and integration testing of the classes in an OO program. • Finding an order to test the classes is important so that effort required is minimum. • Class Testing Methodology – Utilizes hierarchical nature of classes. • Using Object Relation Diagram – identifies the relationships from the source code and display classes and relationships diagrammatically.

  43. Class Testing Methodology The methodology consists of the following steps – • Initially, base classes having no parents are chosen and test suite is designed for each member function and interactions. • Testing history associates each test case with the attribute it tests. Along with the attributes, the newly defined subclass “inherits” the testing history from its parent class. • Inherited testing history is incrementally updated to reflect differences from parent and result is testing history for the subclass. • New attributes can be easily identified in subclass and must be tested along with the inherited attributes that must be retested.

  44. Class Testing Methodology 5. Inherited attributes are retested in context of subclass by identifying and testing their interactions with newly defined attributes in the subclass. 6. Test cases in the parent class’s test suite can be reused to validate the subclass and attributes in subclass which require new test cases can also be identified. Experiments show significant amount of effort can be saved with well defined hierarchies with a large amount of functionality defined at the top level and modifications and additions are made at the lower level.

  45. ORD • Test strategy is defined to be an order to test the classes such that the effort required to construct the test stubs is minimum. • ORD is generated by a reverse engineering tool which identifies relationships from the source code and displays classes and their relationships by diagrams. • It should consider 2 cases. • ORD = ( V,L,E) is an acyclic graph – test order is simply topological sorting of set of classes using the dependence relation. • ORD = ( V,L,E) is a cyclic graph – Converted to acyclic graph by treating each strongly connected as a composite vertex. Certain association edges are removed so that we obtain a minimum test order.

  46. Design Patterns Introduction The Design Patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context. They provide Extensibility and increase flexibility and reusability. The patterns can either be Static or Extensible.

  47. Issues in Testing Design Patterns • Dynamic Typing • Actual methods select the kind of objects at run time • Policy, Factory Method, Abstract Method and Visitor design patterns enforce this • The tester cannot determine the type of object • Dynamic Binding • Run-time selection of methods • Factory method and Visitor Design pattern enforces • Tester has no way of knowing which method is called

  48. Issues in Testing Design Patterns[2] • Extensibility • It allows application developers to add new classes and methods to framework at compile time or runtime. • Framework developers are responsible for creating a framework that is expandable and also provide some level of quality assurance. • Application Designers are responsible for verification of the extension points and for testing the code together with the framework.

  49. Communication between Framework and Application Extension • Framework objects call Custom objects • Use Message and Event handling mechanisms such as Observer or Strategy patterns • Custom objects call Framework objects • Framework can either be a Black box, Gray box or White box • Use Observer or Visitor patterns

  50. Testing by use of Scenario Templates Scenario Template A template for listing the task sequence of each scenario belonging to a use-case. Generated using MfSS(Message Framework Sequence Specification) MfSS is an extension of MtSS and MgSS MgSS(Message Sequence Specification) specifies the msg a method can send MtSS(Method Sequence Specification) specifies the sequence of msgs sent to a class

More Related