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

Slides:



Advertisements
Similar presentations
1 Software Testing and Quality Assurance Lecture 13 - Planning for Testing (Chapter 3, A Practical Guide to Testing Object- Oriented Software)
Advertisements

Software Construction
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.
Feb 2003 R McFadyen1 Contracts (Ch 13) Used to help understand requirements more completely based on assertions; assertions are applicable to any.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der.
Introduction To System Analysis and Design
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
1 Software Testing and Quality Assurance Lecture 21 – Class Testing Basics (Chapter 5, A Practical Guide to Testing Object- Oriented Software)
Software Testing and Quality Assurance
Jan 2005 Ron McFadyen1 Contracts Used to help understand requirements more completely (and so may not always be necessary) based on assertions;
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.
NJIT Use Case Model Operation Contracts Prepared By: Sumit Sharma.
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)
November 13, 2006ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder 1 Testing Object-Oriented Software Principles Summary ECEN 5543 / CSCI.
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
Karlstad University Computer Science Design Contracts and Error Management Design Contracts and Errors A Software Development Strategy (anpassad för PUMA)
Fundamentals of Information Systems, Second Edition
September 2002 R McFadyen1 Domain Model Use Case Model text diagram SSD System operation contracts Design Model Figure 13.3.
Chapter 1 Principles of Programming and Software Engineering.
Software Testing and Quality Assurance
Software Testing and Quality Assurance: Introduction and Terminology
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)
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Class Testing Software Engineering of Standalone Programs University of Colorado, Boulder.
Spring 2009CS 225 Introduction to Software Design Chapter 1.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
 QUALITY ASSURANCE:  QA is defined as a procedure or set of procedures intended to ensure that a product or service under development (before work is.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
BY RAJESWARI S SOFTWARE TESTING. INTRODUCTION Software testing is the process of testing the software product. Effective software testing will contribute.
Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved Software.
Testing. Definition From the dictionary- the means by which the presence, quality, or genuineness of anything is determined; a means of trial. For software.
RUP Fundamentals - Instructor Notes
CPIS 357 Software Quality & Testing
Implementation Yaodong Bi. Introduction to Implementation Purposes of Implementation – Plan the system integrations required in each iteration – Distribute.
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.
 CS 5380 Software Engineering Chapter 8 Testing.
Introduction to Software Design Chapter 1. Chapter Objectives  To become familiar with the software challenge and the software life cycle  To understand.
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
Software Life Cycle Requirements and problem analysis. –What exactly is this system supposed to do? Design –How will the system solve the problem? Coding.
Testing Workflow In the Unified Process and Agile/Scrum processes.
111 Protocols CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, (Chapter 8) Meyer, B., Applying design by contract,
Composition of UML Described Refactoring Rules Presented by Chin-Yi Tsai.
9-1 © Prentice Hall, 2007 Chapter 9: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
Software Testing and Quality Assurance Practical Considerations (4) 1.
DOMAIN MODEL: ADDING ATTRIBUTES Identify attributes in a domain model. Distinguish between correct and incorrect attributes.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Software Engineering 2 -Prakash Shrestha.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Ivar Jacobson, Grady Booch, and James Rumbaugh The Unified Software Development Process Addison Wesley, : James Rumbaugh's OOMD 1992: Ivar Jacobson's.
7-1 © Prentice Hall, 2007 Topic 7: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
Chapter 1 Software Engineering Principles. Problem analysis Requirements elicitation Software specification High- and low-level design Implementation.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Winter 2007SEG2101 Chapter 121 Chapter 12 Verification and Validation.
1 Software Testing and Quality Assurance Lecture 17 - Test Analysis & Design Models (Chapter 4, A Practical Guide to Testing Object-Oriented Software)
Chapter 2 Principles of Programming and Software Engineering.
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.
Application Analysis. Application Interaction Model The purpose of analysis is to understand the problem so.
SOFTWARE TESTING LECTURE 9. OBSERVATIONS ABOUT TESTING “ Testing is the process of executing a program with the intention of finding errors. ” – Myers.
Principles of Programming & Software Engineering
Used to help understand requirements more completely
Software life cycle models
Presentation transcript:

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

2 Lecture Outline To know what to consider when testing a class. To identify test cases for testing a class.

3 Class testing A class is the fundamental unit of an object-oriented program. Class testing comprises the activities associated with verifying that the implementation of a class corresponds exactly with the specification for that class.

4 Class testing Class testing is roughly analogous to unit testing in traditional testing processes. The main focus is on execution-based testing.

5 Class testing (cont...) Assumptions: Class Under Test (CUT) has a complete specification expressed in a specification language like Object Constraint Language (OCL), a natural language, and/or state transition diagram If more than one form of specification is used for a class: All forms are consistent. Information can be taken from any model.

6 Class testing: ways to test a class Reviews: Reviews are subject to human error. Reviews require considerably more effort with respect to regression testing. Executing test cases: Considerable effort can be required for the identification of test cases and the development of test drivers.

7 Class testing and unit testing The purpose of unit testing is to ensure that each unit meets its specification. If the unit meets its specification, then any bugs that appear when units are integrated are more likely caused by incorrect interfacing of units. Unit testing is done as units are developed.

8 Class testing and unit testing Units are tested by code inspection and execution testing (more emphasis on execution testing). Units that have parameters can be unit tested if the driver can initialize the actual parameters. Should test driver itself be tested?

9 Class testing and unit testing (cont...) Identify test cases Test driver construction: create one or more instances of a class to run a test case Execution Result analysis

10 Class testing: dimensions of class testing Should we test a class independently as a unit or as a component of a larger part of the system, this decision is based on: The role of the class in the system; the risk associated with it.

11 Class testing: dimensions of class testing The complexity of the class measured in terms of: The number of states Operations Associations with other classes The amount of effort associated with developing a test driver for the class.

12 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

13 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

14 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.

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

16 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

17 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

18 Constructing test cases: Example Velocity class as specified in UML model (Figure 5.2) Velocity speed: Speed direction: Direction Velocity() Velocity (speed: Speed, direction: Direction) getSpeed(): Speed getSpeedX(): Speed getSpeedY(): Speed getDirection(): Direction setSpeed(speed: Speed) setDirection(direction: Direction) Reverse() ReverseX() ReverseY()

19 Constructing test cases: Example (cont...) OCL specification for the method setDirection of Velocity class Velocity::setDirection(dir:Direct ion) Pre:0 <= dir and dir < 360 Post:direction=dir and

20 Key points Ways to test a class: reviews and executing test cases The purpose of unit testing is to ensure that each unit meets its specification. Possible ways for identifying test cases Pre- and post-conditions (OCL) State transition diagram