Program Testing - Lecture Slides - Object-Oriented Programming II | CMSC 132, Study notes of Computer Science

Material Type: Notes; Professor: Padua-Perez; Class: OBJECT-ORIENTED PROG II; Subject: Computer Science; University: University of Maryland; Term: Fall 2005;

Typology: Study notes

Pre 2010

Uploaded on 07/29/2009

koofers-user-b6c
koofers-user-b6c 🇺🇸

10 documents

1 / 9

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
Program Testing
Nelson Padua-Perez
Chau-Wen Tseng
Department of Computer Science
University of Maryland, College Park
Testing
Goal
Detect and eliminate errors in program
Feedback to improve software
Specification changes
Add new functionality
Extremely important for success!
pf3
pf4
pf5
pf8
pf9

Partial preview of the text

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

Program Testing

Nelson Padua-Perez

Chau-Wen Tseng

Department of Computer Science

University of Maryland, College Park

Testing

Goal

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

Extremely important for success!

Testing

Empirical testing

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

Testing – Terminology

Test case

Individual test

Test suite

Collection of test cases

Test harness

Program that executes a series of test cases

Test framework

Software that facilitates writing & running tests Example – JUnit

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

Flow Path

Unique execution sequence through program

Example

S

while (B1) { if (B2) S else S }

Flows

S

S1, S

S1, S

S1, S2, S

S1, S2, S

S1, S3, S

S1, S3, S

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

Acceptance Test

Test full functionality of software

Ensure program meets all requirements

Approach

Place software in user environment Test software with Real-world data Real users Typical operating conditions Test cases selected by users

Acceptance Test – Stages

Alpha test

Test components during development Usually clear box test

Beta test

Test in real user environment Always black box test

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