Testing-Software Engineering-Lecture 04 Slides-Computer Science, Slides of Software Engineering

Download Testing-Software Engineering-Lecture 04 Slides-Computer Science and more Slides Software Engineering in PDF only on Docsity!

LECTURE 4: TESTING

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.

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.

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”.)

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.

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.

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

upper boundary

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!
• EXAMPLE.

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.

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!