Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Object Oriented Testing

Basics about testing

  • Be the first to comment

Object Oriented Testing

  1. 1. T.Y. B.Sc. (Comp. Sci.) Sem I Object Oriented Software Engineering (OOSE) CS-336 Faculty Dr. Amit D. Kasliwal Asst. Professor
  2. 2. Chapter 9 Object Oriented Testing Objective  Object Oriented Testing Strategies  Test Case Design for Object Oriented Software  Inter Class Test Case Design
  3. 3. Object Oriented Testing  Testing is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user.  The objective of testing is to find the greatest possible number of errors with a manageable amount of effort applied over a realistic time span.  Although this fundamental objective remains unchanged for object-oriented software, the nature of OO programs changes both testing strategy and testing tactics.
  4. 4. Testing Shows Object Oriented Testing
  5. 5.  All software testing strategies provide a template for testing and all have the following generic characteristics:  Conduct effective formal technique reviews, by doing this, many errors will be eliminated before testing commences.  Testing begins at the component level and works “outward” towards the integration of the entire computer-based system.  Different testing techniques are appropriate at different points in time.  Testing is conducted by the developer of the software and an independent test group. Object Oriented Testing
  6. 6. Who Tests the Software?
  7. 7. Verification and Validation  Verification refers to the set of activities that ensure that product correctly implements a specific function.  Validation refers to the set of activities that ensure that the product has been built is traceable to customer requirements.  Verification: Are we building the product right?  Validation: Are we building the right product?  The definition of Verification and Validation encompasses many of the activities that are encompassed by software quality assurance (SQA).
  8. 8. Test Case  A test case is a document, which has a set of test data, preconditions, expected results and post conditions, developed for a particular test scenario in order to verify compliance against a specific requirement.  Test Case acts as the starting point for the test execution, and after applying a set of input values, the application has  a definitive outcome and leaves the system at some end point or also known as execution post condition.  Typical Test Case Parameters are Test Case ID, Test Scenario, Test Case Description, Test Steps, Prerequisite, Test Data, Expected Result, Test Parameters, Actual Result, Environment Information, Comments.
  9. 9. Test Case Scenario Test Step Expected Result Actual Outcome Verify that the input field that can accept maximum of 10 characters Login to application and key in 10 characters Application should be able to accept all 10 characters. Application accepts all 10 characters. Verify that the input field that can accept maximum of 11 characters Login to application and key in 11 characters Application should NOT accept all 11 characters. Application accepts all 10 characters.
  10. 10. Organizing for Software Testing  There are often a number of misconceptions that can be erroneously inferred for testing:  That the developer of project shouldn’t test.  That the software project should be tossed over the wall to strangers who will test it mercilessly  That testers get involved only when testing steps are about to begin.  These aforementioned statements are incorrect.
  11. 11. Testing Strategies
  12. 12. Testing Strategies Unit Testing : It is a level of software testing where individual units/ components of a software are tested.  A unit is the smallest testable part of any software. Usually has one or a few inputs and usually a single output.  The purpose is to validate that each unit of the software performs as designed.  An encapsulated class is the focus of unit testing.  However, operations within the class and the state behavior of the class are the smallest testable units.  Class testing for object oriented software is analogous to module testing for conventional software. It is not advisable to test operations in isolation.
  13. 13. Black Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is not known to the tester.  This testing can be initiated on the basis of requirement specifications document. White Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is known to the tester.  This type of testing of software is started after detail design document. Testing Strategies
  14. 14. Testing Strategies Integration Testing : It is a level of software testing where individual units are combined and tested as a group.  It is to expose faults in the interaction between integrated units.  Test drivers and test stubs are used to assist in Integration Testing.  An important strategy for integration testing of object oriented software is thread-based testing.
  15. 15. Integration Testing  Thread-based testing integrates the set of classes required to respond to one input or event for the system. Each thread is integrated and tested individually.  Use-Based testing begins the construction of the system by testing those classes (called independent classes) that use very few server (if any) classes. Dependent classes, which use independent classes, are tested.  This sequence of testing layers of dependent classes continues until the entire system is constructed.  Cluster testing is one-step in the integration testing process.  A cluster of collaborating classes is exercised by designing test cases that attempt to uncover errors in the collaborations. Testing Strategies
  16. 16. Validation Testing : It is described as the last chance to catch program errors before delivery to the customer.  If the users are not happy with what they see, the developers often do not get paid.  The key point to emphasize is traceability to requirements. In addition, the importance of alpha and beta testing (in product environments) should be stressed.  Validation Test Criteria: Focus is on software requirements. A test plan outlines the classes of tests to be conducted, and a test procedure defines specific test cases. Testing Strategies
  17. 17. Alpha/Beta testing: This strategy focuses on customer usage.  Alpha tests are conducted in a controlled environment and conducted at the developer’s site by end-users.  The s/w is used in natural setting with the developer with users, recording errors and usage problems.  The beta-test is conducted at the end-users sites where developer is generally not present.  Beta test is a live application of the software in an environment that cannot be controlled by the developer.  The end-user records errors and all usage problems encountered during the test and the list is reported to the developer.  And then modifications is done to prepare for release of product to the entire customer base. Testing Strategies
  18. 18. System Testing : The focus is on system integration.  System Testing is a series of different tests whose primary purpose it to fully exercise the computer-based system.  Following are the types of system tests:  Recovery Testing : Forces the software to fail in a variety of ways and verifies that recovery is properly performed for data recovery.  Security Testing : It verifies that protection mechanisms built into a system will, in fact, protect it from improper penetration.  The system’s security must, of course, be tested for invulnerability from frontal attack-but must also be tested for invulnerability from flank or rear attack. Testing Strategies
  19. 19. Stress Testing : It executes a system in a manner that demands resources in abnormal quantity, frequency, or volume. For example:  Special tests may be designed to generate 10 interrupts per second, when one or two is the average rate.  Test cases that require maximum memory or other resources are executed,  Test cases causing memory management problems are designed.  Test cases that may cause excessive hunting for disk-resident data are created.  A variation of stress testing is a technique called sensitivity testing. They attempt to uncover data combinations within valid input classes that may cause instability or improper processing. Testing Strategies
  20. 20. Performance Testing : It tests the run-time performance of software within the context of an integrated system.  Performance tests are coupled with stress testing and usually require both hardware & software instrumentation. Documentation Testing involves testing of the documented artifacts that are usually developed before or during the testing of Software.  Documentation for Software testing helps in estimating the testing effort required, test coverage, requirement tracking/tracing, etc. Testing Strategies
  21. 21. Test Case Design for OO Software  An approach to OO test case design has been defined by : 1. Each test case should be uniquely identified and explicitly associated with the class to be tested. 2. The purpose of the test should be stated.  Steps should be developed for each test and should contain:  A list of specified states for the object that is to be tested.  A list of messages and operations that will be exercised as a consequence of the test.  A list of exceptions that may occur as the object is tested.  A list of external that must exist in order to properly conduct the test.  Supplementary information that will aid in understanding or implementing the test.
  22. 22. Interclass Test Case Design  Test case design becomes more complicated as integration of the OO system begins. It is at this stage that testing of collaborations between classes must begin.  Inter class testing is the testing of a set of classes composing a system or subsystem, usually performed during integration.  Typically, such classes are not stand-alone entities, but mutually cooperate in several ways.  These relationships among classes are a fundamental characteristic of object-oriented systems and define the nature of the interactions among objects at runtime.
  23. 23. The figure shows banking process including the classes and collaborations to illustrate interclass test case .
  24. 24. Interclass Test Case Design  Following are the steps to generate multiple inner class random test cases:  For each client class, use the list of class operations to generate a series of random test sequences. The operations will send messages to other server classes.  For each message that is generated, determine the collaborator class and the corresponding operation in the server object.  For each operation in the server object (that has been invoked by messages sent from the client object), determine the messages that it transmits.  For each of the messages, determine the next level of operations that are invoked and incorporate these into the test sequence.
  25. 25. To illustrate above, consider a sequence of operations for the bank class relative to an ATM class as shown in above figure: