Lecture 25: Testing Strategies/OO Testing
Upcoming SlideShare
Loading in...5
×
 

Lecture 25: Testing Strategies/OO Testing

on

  • 2,591 views

 

Statistics

Views

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

Actions

Likes
0
Downloads
91
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

Lecture 25: Testing Strategies/OO Testing Lecture 25: Testing Strategies/OO Testing Document Transcript

  • Verification & validation ECE 452 – Introduction to Software Engineering z Verification: Are we building the product right Lecture 25: Testing Strategies/OO z Validation: Are we building the right product Testing Manish Parashar parashar@ece.rutgers.edu Department of Electrical & Computer Engineering Rutgers University ECE 452 - Introduction to Software Engineering Testing strategy Unit testing interface high-order Module local data structures requirements tests boundary conditions independent paths integration test error handling paths design unit code test Test cases ECE 452 - Introduction to Software Engineering ECE 452 - Introduction to Software Engineering Unit testing environment Why integration testing? interface z If all units work individually, why doubt that driver local data structures they work together? z Putting units together - interfacing boundary conditions Module independent paths error handling paths stub stub RESULTS Test cases ECE 452 - Introduction to Software Engineering ECE 452 - Introduction to Software Engineering 1
  • Integration testing Top down integration incremental top module is tested construction A with stubs strategy B F G Big incremental Bang! “builds” stubs are replaced one at C a time, “depth first” regression as new modules are integrated, testing D E some subset of tests is re-run ECE 452 - Introduction to Software Engineering ECE 452 - Introduction to Software Engineering Bottom-up integration Sandwich testing A A top modules are tested with stubs B F G B F G drivers are replaced one C at a time, “depth first” C cluster cluster worker modules are grouped into worker modules are grouped into builds and integrated builds and integrated D E D E ECE 452 - Introduction to Software Engineering ECE 452 - Introduction to Software Engineering High-order testing Alpha & Beta test Alpha test z validation test z system test software customer tests z alpha and beta test developer site customer site z other specialized testing y performance testing Beta test y usability testing developer customer software y ... reviews tests developer site customer site ECE 452 - Introduction to Software Engineering ECE 452 - Introduction to Software Engineering 2
  • Testing strategies and OO testing Object - oriented testing z Testing strategies & higher-order testing z begins by evaluating the correctness and consistency of the OOA and OOD models z Testing object-oriented software z testing strategy changes y the concept of the ‘unit’ broadens due to encapsulation y integration focuses on classes and their execution across a ‘thread’ or in the context of a use case y validation uses conventional black box methods z test case design draws on conventional methods, but also encompasses special features ECE 452 - Introduction to Software Engineering ECE 452 - Introduction to Software Engineering OOT strategy Integration testing of OO software z classes are the smallest testable unit z thread-based testing z inheritance defines new context for methods x integrates the set of classes required to respond to one input or y behavior of inherited methods can be changed because of methods that event are called within methods have to be tested per class z use-case based testing z objects have states: testing methods have to take that into x integrates the set of classes required to respond to one use cas e account x shows that every use case is executable within the system z class testing is the equivalent of unit testing • with and without user interface y operations within the class are tested y the state behavior of the class is tested z OO testing concentrates on the states of the objects and their interactions ECE 452 - Introduction to Software Engineering ECE 452 - Introduction to Software Engineering OOT - test case design (1) OOT - test case design (2) Berard [BER93] proposes the following approach: A a list of specified states for the object that is to be tested 1. each test case should be uniquely identified and B a list of messages and operations that will be exercised should be explicitly associated with the class to as a consequence of the test be tested C a list of exceptions that may occur as the object is 2. the purpose of the test should be stated tested 3. a list of testing steps should be developed for D a list of external conditions (i.e., changes in the each test and should contain [BER94]: environment external to the software that must exist in order to properly conduct the test) E supplementary information that will aid in understanding or implementing the test. ECE 452 - Introduction to Software Engineering ECE 452 - Introduction to Software Engineering 3
  • OOT methods: Use case based Problems in testing OO software testing z Testing shall report errors z Concentrates on what the user does NOT what accessing the internal state of the system does objects z Based on use cases z Encapsulation hides internal things z Described by z Inheritance: test cases of the superclass may ya test may have to be adapted y specific user needs ECE 452 - Introduction to Software Engineering ECE 452 - Introduction to Software Engineering OOT methods: random testing OOT methods: partition testing (1) z random testing z Partition testing identify operations applicable to a class reduces the number of test cases required to define constraints on their use test a class in much the same way as identify a minimum test sequence equivalence partitioning for conventional x anoperation sequence that defines the minimum life history of the software object state-based partitioning generate a variety of random (but valid) test sequences xcategorize and test operations based on their x exercise other (more complex) class instance life histories ability to change the state of a class ECE 452 - Introduction to Software Engineering ECE 452 - Introduction to Software Engineering OOT methods: partition testing (2) State diagram based testing z Partition testing z Use state diagram to determine a sequence of attribute-based partitioning events xcategorize and test operations based on the attributes that they use z Tests should cover all states category-based partitioning z All transitions should be tested at least once xcategorize and test operations based on the generic function each performs e.g. z Test invalid events • initialization • state changing • queries • termination ECE 452 - Introduction to Software Engineering ECE 452 - Introduction to Software Engineering 4
  • OOT methods: Inter-class testing (1) OOT methods: Inter-class testing (2) z Inter-class testing z Inter-class testing For each client class, use the list of class operators to For each operator in the server object (that has been generate a series of random test sequences. The invoked by messages sent from the client object) operators will send messages to other server determine the messages that it transmits. classes. For each of the messages, determine the next level For each message that is generated, determine the of operators that are invoked and incorporate these collaborator class and the corresponding operator into the test sequence in the server object. ECE 452 - Introduction to Software Engineering ECE 452 - Introduction to Software Engineering Test case document Class test cases 1. Usual cover information z For every class in your system 2. Class test cases y at least one test case for xthe normal behavior of every public method 3. Use case test descriptions xtheexceptions of every public method 4. References xevery state transition of the class 5. Appendices xinvalid state transitions of the class y white-box test cases for important methods ECE 452 - Introduction to Software Engineering ECE 452 - Introduction to Software Engineering Use case test descriptions Executing tests z For every use case/sequence diagram in the z Develop automatic test drivers for every class design document y main method of class executes the class test ya test case that shows that the use case can be y class methods define (sets of) tests executed by the system z Use case tests xdescribe the objects that get messages from the UI y develop test classes that execute the use cases xlistthe messages that are send from the UI to define the y test the use cases manually with UI test cases z System test driver calls all class test drivers y test cases for all exceptions of the use case and all use case test classes ECE 452 - Introduction to Software Engineering ECE 452 - Introduction to Software Engineering 5
  • Implementing test cases Debugging: Symptoms & causes z Symptom and cause may be separated z Test driver code must z Symptom may disappear when another y create the system state described in the test case problem is fixed y call the method to test z Cause may be due to a combination of non- y check if the expected result is produced errors y print test result to file/console e.g. z Cause may be due to a system or compiler Class: ResourcePool error method: addAgent test case: No. 265 - tests exception of the method z Cause may be due to assumptions that result: failed everyone believes y count the number of successful/failed test to produce a z Symptom may be intermittent summary result at the end symptom cause ECE 452 - Introduction to Software Engineering ECE 452 - Introduction to Software Engineering 6