Software testing and quality assurance
1 / 24

Software Testing and Quality Assurance - PowerPoint PPT Presentation

  • Uploaded on

Software Testing and Quality Assurance. Lecture 30 - Introduction to Software Testing. Lecture Outline. Testing activities. Introduction to test cases, test oracles and their execution. Black-box & White-box Testing. Unit Testing. module to be tested. results. software engineer.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Software Testing and Quality Assurance' - nicolette

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Software testing and quality assurance

Software Testing and Quality Assurance

Lecture 30 - Introduction to Software Testing

Lecture outline
Lecture Outline

  • Testing activities.

  • Introduction to test cases, test oracles and their execution.

  • Black-box & White-box Testing

Unit testing
Unit Testing


to be





test cases

Integration testing
Integration Testing

  • The Big-bang Approach.

  • Incremental Approach.

Top down integration
Top-Down Integration


top module is tested with





stubs are replaced one at

a time, "depth first"


as new modules are integrated,

some subset of tests is re-run



Bottom up integration
Bottom-Up Integration





drivers are replaced one at a

time, "depth first"


worker modules are grouped into

builds and integrated




System testing
System Testing

  • System Functional Test

    • Test entire system against the functional requirements.

  • System Performance Test

    • Test the non-functional requirements of the system. For example,

    • Response times, load testing etc.

  • System Acceptance Test

    • Set of tests that the software must pass before it is accepted by the client.

Trivial example
Trivial Example

  • You have been asked to write a term paper on ‘Integration Testing in Component Based System’. To do this, you need to find references from a range of library databases.

  • You logs on to the KFUPM library system and uses the search facility to find relevant papers from IEEE, ACM and Elsevier databases.

  • One paper of special interest requires authentication and you have to fill an online form to receive the paper.

    • If you are allowed, the paper will be downloaded and ready for collection.

    • An email will be send to you once the paper is ready.

Scenario-based Testing

Student activity
Student Activity

  • Identify the possible interactions for the system testing of library system.

Trivial example system testing
Trivial Example - System Testing

  • Test the login mechanism using correct and incorrect login.

  • Test the search facility using queries against known source to check that the search mechanism is actually documents.

  • Test system presentation facility to check that information about documents is displayed properly.

  • Test the mechanism to request permission for downloading.

  • Test the e-mail response indicating that the download document is available.

Regression testing
Regression Testing

  • Change do not always effect the entire program.

  • Change in one part of system can effect other part.

  • After each change

    • Entire test suite of a system must be run again.

Need for an automatic test suite execution.

Test activities
Test Activities

  • Boils down to selecting and executing test cases. Test case consists of……

    • Set of test inputs, of if the program is non-terminating, a sequence of test inputs.

    • Expected results when the inputs are executed; and

    • Execution conditions or execution environment in which the inputs are to be executed.

These steps generally remain same from

unit testing to system testing.

Test case selection
Test Case Selection

  • Coverage criterion;

    • Equivalence Partitioning

    • Boundary-Value Analysis

    • Coverage-Based Testing

      • Control-flow

      • Data-flow

  • Expected behavior of every test input to be generated. (Test Oracles)

  • Testing environment.

Test oracles
Test Oracles

  • Determines whether or not the program has passed or failed the test case.

  • A test oracle is

    • A program

    • A process

    • A body of data

      • In many cases - directly form the requirements.

      • For example, a test case assessing performance - performance threshold.

Difficult to automate or to assess their quality

Test execution
Test Execution

  • Test inputs on the ‘program-under-test’

    • Record the actual behavior.

Generally can be automated to an extend !!!!

Test evaluation
Test Evaluation

  • Compare the actual behavior with the expected behavior.

Generally can be automated to an extend !!!!

Test reporting
Test Reporting

  • Report the outcome of the testing.

    • Developers

    • Project Mangers etc.

Generally can be automated to an extend !!!!

Black box testing





Black-Box Testing

Black box testing1
Black-box Testing

  • Test cases are derived from formal specification of the system.

  • Test case selection can be done without any reference to the program design or code.

  • Only tests the functionality and features of the program.

    • Not the internal operation.

Black box testing2
Black-box Testing

  • Advantages

    • Test case selection is done before the implementation of a program.

    • Help in getting the design and coding correct with respect to the specification.

White box testing1
White-Box Testing

  • Test cases are derived from the internal design specification or actual code for the program.

  • Advantages

    • Tests the internal details of the code;

    • Checks all paths that a program can execute.

  • Limitations

    • Wait until after designing and coding the program under test in order to select test cases.

Key points
Key Points

  • A system typically undergoes a range of testing types.

  • Each type of testing is aimed at detecting different kinds of failures.

  • Testing boils down to the selection and execution of test cases.

  • Black-box and white-box testing are complementary approaches.


  • SWE Revised Program Discussion

    • Monday December 29, 2008 at 12:10-1:00 in 24/141