Program Testing - Object Oriented Programming - Lecture Slides | CMSC 132, Exams of Computer Science

Material Type: Exam; Class: OBJECT-ORIENTED PROG II; Subject: Computer Science; University: University of Maryland; Term: Unknown 1989;

Typology: Exams

Pre 2010

Uploaded on 07/29/2009

koofers-user-17r-1
koofers-user-17r-1 🇺🇸

9 documents

1 / 10

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
CMSC 132:
Object-Oriented Programming II
Program Testing
Department of Computer Science
University of Maryland, College Park
Overview
Testing
Types of testing
Levels of testing
pf3
pf4
pf5
pf8
pf9
pfa

Partial preview of the text

Download Program Testing - Object Oriented Programming - Lecture Slides | CMSC 132 and more Exams Computer Science in PDF only on Docsity!

CMSC 132:

Object-Oriented Programming II

Program Testing

Department of Computer Science

University of Maryland, College Park

Overview

Testing

Types of testing Levels of testing

Program Testing

Goal

Detect and eliminate errors in program Feedback to improve software Specification changes Add new functionality

Extremely important for success!

Program Testing

Empirical testing

Test software with selected test cases More scalable than verification Not guaranteed to detect all errors

Testing – Terminology

Tester (Quality Assurance)

Person devising and / or performing tests More effective if 2nd person writes tests

Walkthrough

Programmer explains code to 2nd^ person

Types of Testing

Clear box testing

Allowed to examine code Attempt to improve thoroughness of tests

Black box testing

No knowledge of code Treat program as “black box” Test behavior in response to inputs

Levels (Stages) of Testing

1. Unit test

2. Integration test

3. System test

4. Acceptance test

Unit Test

Test individual units extensively

Classes Methods

Central part of Extreme Programming (XP)

Extensive unit testing during development Pair programming (1 coder, 1 tester) Design unit tests along with specification

Approach

Test each method of class Test every possible flow path through method

Unit Test – Test Coverage

Automated test coverage

Performed by submit server For code, reports # tests executing code For set of tests selected (from link) E.g., all public tests, individual test For conditionals, reports X/Y where X = # tests executing True Y = # tests executing False Color Green = executed by some test case Pink = not executed

Unit Test – Test Coverage Example

Integration Test

Test interaction between units

Possible units fail when combined May find problems in specifications

Approach

Test units together Proceed bottom up, in increasing size

Example test sequence

1. AB, AC, AD, CD, CE

2. ACD

3. ABCDE

B

A

C

D E

System Test

Test entire software

Include all components of software In context in which software will be used

Ensure all pieces of software interact correctly

Regression Test

Ensure functionality is not lost / changed

As software is modified / extended

Approach

Save suite of tests and expected results Rerun test suite periodically after software changes Report any loss of functionality

Typically run overnight

Software is more stable when developers leave work

Developing Test Cases

Quality of testing depends on test cases

Tips on developing test cases

Develop test data during analysis & design phases Attempt to exercise alternate program paths Check boundary conditions 1 st^ and last iterations of loop 1 st^ and last values added to data structure Pay close attention to problem specification UML use cases → test cases