1 Software Testing and Quality Assurance Lecture 21 – Class Testing Basics (Chapter 5, A Practical Guide to Testing Object- Oriented Software)

Slides:



Advertisements
Similar presentations
Class Testing ECEN5033 University of Colorado. January 27, 2002 ECEN5033 University of Colorado -- Class Testing 2 Overview Class Testing Testing Interactions.
Advertisements

Testing Object Oriented Programs CSE 111 4/28/20151.
1 Software Testing and Quality Assurance Lecture 13 - Planning for Testing (Chapter 3, A Practical Guide to Testing Object- Oriented Software)
Data Abstraction II SWE 619 Software Construction Last Modified, Spring 2009 Paul Ammann.
Chapter 7 Testing Class Hierarchies. SWE 415 Chapter 7 2 Reading Assignment  John McGregor and David A. Sykes, A Practical Guide to Testing Object-Oriented.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
Object Oriented Design An object combines data and operations on that data (object is an instance of class) data: class variables operations: methods Three.
Software Engineering and Design Principles Chapter 1.
1 Software Testing and Quality Assurance Lecture 12 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)
Software Testing and Quality Assurance
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Software Testing and Quality Assurance
Software Testing and Quality Assurance: The Testing Perspective Reading Assignment: –John McGregor and David A. Sykes, A Practical Guide to Testing Object-Oriented.
Fall 2007CS 225 Introduction to Software Design Chapter 1.
1 Software Testing and Quality Assurance Lecture 26 (a) – Testing Interactions (Chapter 6)
Software Testing and Quality Assurance
1 Software Testing and Quality Assurance Lecture 28 – Testing Class Hierarchies.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
1 Software Testing and Quality Assurance Lecture 24 – Testing Interactions (Chapter 6)
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
November 13, 2006ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder 1 Testing Object-Oriented Software Principles Summary ECEN 5543 / CSCI.
January 27, 2002 ECEN5033 University of Colorado -- Class Testing 1 Adequacy of a Class Test Suite Ideally – exhaustively test each class Practically –
1 Software Testing and Quality Assurance Lecture 15 - Planning for Testing (Chapter 3, A Practical Guide to Testing Object- Oriented Software)
Software Testing and Quality Assurance: Class Testing Basics
1 Software Testing and Quality Assurance Lecture 20 – Class Testing Basics (Chapter 5, A Practical Guide to Testing Object- Oriented Software)
Software Testing and Quality Assurance
1 Software Testing and Quality Assurance Lecture 14 - Planning for Testing (Chapter 3, A Practical Guide to Testing Object- Oriented Software)
1 Software Testing and Quality Assurance Lecture 25 – Testing Interactions (Chapter 6)
Class Testing Software Engineering of Standalone Programs University of Colorado, Boulder.
Recall The Team Skills Analyzing the Problem
Spring 2009CS 225 Introduction to Software Design Chapter 1.
1 Software Testing and Quality Assurance Lecture 5 - Software Testing Techniques.
Introduction to Software Testing
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Test Design Techniques
January 27, 2002 ECEN5033 University of Colorado -- Class Testing 1 Specifying interactions Remainder of slides assume Operations defined by a class are.
Testing. What is Testing? Definition: exercising a program under controlled conditions and verifying the results Purpose is to detect program defects.
Testing. Definition From the dictionary- the means by which the presence, quality, or genuineness of anything is determined; a means of trial. For software.
CMSC 345 Fall 2000 Unit Testing. The testing process.
1 Debugging and Testing Overview Defensive Programming The goal is to prevent failures Debugging The goal is to find cause of failures and fix it Testing.
Overview of Software Testing 07/12/2013 WISTPC 2013 Peter Clarke.
From Use Cases to Test Cases 1. A Tester’s Perspective  Without use cases testers will approach the system to be tested as a “black box”. “What, exactly,
Introduction to Software Design Chapter 1. Chapter Objectives  To become familiar with the software challenge and the software life cycle  To understand.
Testing Workflow In the Unified Process and Agile/Scrum processes.
CSC 395 – Software Engineering Lecture 13: Object-Oriented Analysis –or– Let the Pain Begin (At Least I’m Honest!)
111 Protocols CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, (Chapter 8) Meyer, B., Applying design by contract,
Low-Level Detailed Design SAD (Soft Arch Design) Mid-level Detailed Design Low-Level Detailed Design Design Finalization Design Document.
Test Drivers and Stubs Integration Testing System Testing CEN 5076 Class 12 – 11/21.
Software Construction Lecture 18 Software Testing.
CSC 395 – Software Engineering Lecture 14: Object-Oriented Analysis –or– Ripping the Band-Aid Off Quickly.
Systems Analysis and Design in a Changing World, Fourth Edition
1 Testing Object- Oriented Programs CS 4311 J. McGregor and D. Sykes. A Practical Guide to Testing Object-Oriented Software, Addison-Wesley, I. Burnstein.
What is Testing? Testing is the process of finding errors in the system implementation. –The intent of testing is to find problems with the system.
DOMAIN MODEL: ADDING ATTRIBUTES Identify attributes in a domain model. Distinguish between correct and incorrect attributes.
Introduction to Classes and Objects. Real Life When a design engineer needs an electrical motor he doesn’t need to worry about –How a foundry will cast.
PROGRAMMING TESTING B MODULE 2: SOFTWARE SYSTEMS 22 NOVEMBER 2013.
Chapter 7 Programming by contract: preconditions and postconditions.
Loop Invariants and Binary Search Chapter 4.4, 5.1.
Object Design More Design Patterns Object Constraint Language Object Design Specifying Interfaces Review Exam 2 CEN 4010 Class 18 – 11/03.
Testing Overview Software Reliability Techniques Testing Concepts CEN 4010 Class 24 – 11/17.
Northwest Arkansas.Net User Group Jay Smith Tyson Foods, Inc. Unit Testing nUnit, nUnitAsp, nUnitForms.
CSE 219 Final exam review.
Abstract Data Type.
Input Space Partition Testing CS 4501 / 6501 Software Testing
Introduction to Software Testing
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Defining Classes and Methods
Automated test.
CSE 1020:Software Development
Automated test.
Presentation transcript:

1 Software Testing and Quality Assurance Lecture 21 – Class Testing Basics (Chapter 5, A Practical Guide to Testing Object- Oriented Software)

2 Lecture Outline Dimensions of Class Testing Construction of Test Cases Adequacy of Test Suites for a Class

3 Class testing: dimensions of class testing (cont...) Who — developer What — code implements the specification exactly When — A test plan should be developed soon after the specification of the class is ready for coding

4 Class testing: dimensions of class testing (cont...) Class testing should be done prior to its use in other portion of the software Regression class testing should be performed whenever the class implementation is changed

5 Class testing: dimensions of class testing (cont...) How — develop a test driver that creates instances of the class and sets up a suitable environment around these instances to run a test case How much — Test operations and state transitions in all sorts of combinations Exhaustive or selective with combination with risk analysis.

6 Constructing test cases Possible ways for identifying test cases Class specification Pre- and post-conditions (OCL) State transition diagram Class implementation

7 Constructing test cases Test case construction from Pre- and Post-conditions Programming style: defensive vs. contract Steps in generating test cases from Pre- and Post-conditions Identify a list of pre-condition contributions Identify a list of post-condition contributions

8 Constructing test cases Form test case requirements by making all possible combinations of entries from the contributions lists Eliminate any conditions generated that are not meaningful For example, a precondition, say (color = red) or (color = blue) will generate a test case in which (color = red) and (color = blue), which cannot satisfied.

9 Constructing test cases Test case construction from state transition diagram: Each transition on the diagram represents a requirement for one or more test cases When testing based on state transition diagrams, make sure you investigate the boundaries and results of each transitions

10 Constructing test cases: adequacy of test suites for a class Common ways used measures of adequacy: State-based coverage: how many of the transitions in a state transition diagram are covered by the test suite. Constraint-based coverage: how many pairs of pre- and postconditions have been covered. Code-based coverage: how much of the code that implements the class is executed across all test cases in the suite.

11 Constructing test cases Boundary conditions: Boundary is the input value on which a large change occurs and must be identified when test cases are identified. Example: sorting an array the boundary values can be An array with zero elements An array with one element An array with two elements An array with many elements

12 Constructing test cases We need implementation-based testing, test cases derived from the specifications may not be enough: Example: the size of the array is used to choose the sorting algorithm for sorting an array

13 Constructing a test driver A test driver is a program that runs test cases and collects the results. Two approaches to build a test driver Embed the testing into the class under test itself Implement a separate class Keep relationship between CUT and its tester class through name, like a tester for Velocity class as VelocityTester.

14 Constructing a test driver: test driver requirements Test driver should have relatively simple design. Test driver must be easy to maintain and adapt in response to changes. Test driver should be reusable to create new drivers.

15 Constructing a test driver: test driver requirements (cont...) A class model for requirements for a tester class: Public interface Tester is an abstract class.

16 Constructing a test driver: test driver requirements (cont...) Test case suites: Functional (specification-based)— if derived from specification. Structural (implementation-based)— if identified from code. Interaction — if derived from sequence of events on an object such as pairs of input/output transitions.

17 Constructing a test driver: tester class design Tester class example

18 Constructing a test driver The main responsibility of the tester class is to run test cases and report results. Test case methods: one method per test case or group of closely related test cases: Execute a test case by creating the input state, generating a sequence of events, and checking the output state. Provide traceability to the test plan.

19 Constructing a test driver (cont...) Baseline testing: a baseline test suite is a set of test cases that tests the operations of the CUT that are needed for the other test cases to verify their outcome. This suite includes testing constructors and accessors. Two basic approaches to baseline testing: specification-based and implementation-based: Check that all the constructors and accessors are self-consistent. Create a test case for each constructor and verify that all attributes are correct by invoking accessors. Check that all the constructors and accessors use the variables in an object correctly.

20 Constructing a test driver (cont...) Running test suites: The abstract Tester class includes in its protocol some operations to run all test cases or selected test suites. Each calls a sequence of test case methods. Make sure that the baseline test suite is executed before any of these other suites are executed.

21 Constructing a test driver (cont...) Reporting test results: A test case method determines the success of a test case. The test case should report results to the tester instance.

22 Key points Possible ways for identifying test cases Pre- and post-conditions (OCL) State transition diagram Common ways used measures of adequacy: state-based coverage, constraint-based coverage and code-based coverage. Boundary conditions is the input value on which a large change occurs.

23 Key points (cont...) Test driver should have relatively simple design, easy to maintain and reusable to create new drivers. Test case suites: functional, structural, and interaction Test case methods: one method per test case or group of closely related test cases: Baseline — checking test cases results and accessor and modifier methods.