Testing-Software Engineering-Lecture 04 Slides-Computer Science, Slides for Software Engineering. University of Liverpool
gustavott3 February 2012

Testing-Software Engineering-Lecture 04 Slides-Computer Science, Slides for Software Engineering. University of Liverpool

PDF (92.0 KB)
13 pages
837Number of visits
The course is intended to develop an understanding of the problems associated with the development of significant computing systems (that is, systems that are too large to be designed and developed by a single person, an...
Download points needed to download
this document
Download the document
Preview3 pages / 13


Software Engineering

Mike Wooldridge

Lecture 4 Software Engineering

1 Testing

• Testing is critically important for quality software:

• Industry averages:

30-85 errors per 1000 lines of code; 0.5-3 errors per 1000 lines of code not

detected before delivery.

• The ability to test a system depends on a thorough, competent requirements document.

Mike Wooldridge 1

Lecture 4 Software Engineering

1.1 Bugs

• Errors of all kinds are known as “bugs”. • Bugs come in two main types:

compile-time (e.g., syntax errors) which are cheap to fix

run-time (usually logical errors) which are expensive to fix.

Mike Wooldridge 2

Lecture 4 Software Engineering

1.2 Testing Strategies

• Never possible for designer to anticipate every possible use of system.

• Systematic testing therefore essential. • Offline strategies:

1. syntax checking & “lint” testers; 2. walkthroughs (“dry runs”); 3. inspections

• Online strategies:

1. black box testing; 2. white box testing.

Mike Wooldridge 3

Lecture 4 Software Engineering

1.3 Syntax Checking

• Detecting errors at compile time is preferable to having them occur at run time!

• Syntax checking will simply determine whether a program “looks” acceptable — but completely dumb exercise.

• “lint” programs try to do deeper tests on program code:

will detect “this line will never be executed”

“this variable may not be initialised”

(The Java compiler does a lot of this in the form of “warnings”.)

Mike Wooldridge 4

Lecture 4 Software Engineering

1.4 Inspections

• Formal procedure, where a team of programmers read through code, explaining what it does.

• Inspectors play “devils advocate”, trying to find bugs.

• Time consuming process! • Can be divisive/lead to interpersonal


• Often used only for safety/time critical systems.

Mike Wooldridge 5

Lecture 4 Software Engineering

1.5 Walkthroughs/Dry Runs

• Similar to inspections, except that inspectors “mentally execute” the code using simple test data.

• Expensive in terms of human resources. • Impossible for many systems. • Usually used as discussion aid.

Mike Wooldridge 6

Lecture 4 Software Engineering

1.6 Black Box Testing

• In black box testing, we ignore the internals of the system, and focus on relationship between inputs and outputs.

• Exhaustive testing would mean examining output of system for every conceivable input. Clearly not practical for any real system!

• Instead, we use equivalence partitioning and boundary analysis to identify characteristic inputs.

Mike Wooldridge 7

Lecture 4 Software Engineering

Equivalence Partitioning

• Suppose system asks for “a number between 100 and 999 inclusive”.

• This gives three equivalence classes of input:

less that 100 100 to 999 greater than 999

•We thus test the system against characteristic values from each equivalence class. Example: 50 (invalid), 500 (valid), 1500 (invalid).

Mike Wooldridge 8

Lecture 4 Software Engineering

Boundary Analysis

• Arises from the fact that most program fail at input boundaries.

• Suppose system asks for “a number between 100 and 999 inclusive”.

• The boundaries are 100 and 999. •We therefore test for values:

99 100 101︸ ︷︷ ︸ lower boundary

998 999 1000︸ ︷︷ ︸ upper boundary

Mike Wooldridge 9

Lecture 4 Software Engineering

1.7 White Box Testing

• In white box testing, we use knowledge of the internal structure of systems to guide development of tests.

• The ideal: examine every possible run of a system. Not possible in practice!

• Instead: aim to test every statement at least once!


if (x > 5) { System.out.println(‘‘hello’’); } else { System.out.println(‘‘bye’’); }

There are two possible paths through this code, corresponding to x > 5 and x ≤ 5. Aim to cause each one to be executed.

Mike Wooldridge 10

Lecture 4 Software Engineering

2 Testing Plans

• Testing must be taken seriously, and rigorous test plans or test scripts developed.

• These are generated from requirements analysis document (for black box) and program code (for white box).

• Distinguish between:

1. unit tests; 2. integration tests; 3. system tests.

Mike Wooldridge 11

Lecture 4 Software Engineering

3 Alpha and Beta Testing

• In-house testing is usually called alpha testing.

• For software products, there is usually an additional stage of testing, called beta testing.

• Involves distributing tested code to “beta test sites” (usually prospective customers) for evaluation and use.

• Typically involves a formal procedure for reporting bugs.

• Delivering buggy beta test code is embarrassing!

Mike Wooldridge 12

comments (0)
no comments were posted
be the one to write the first!
This is only a preview
See and download the full document