Scribd
Upload
51 views

Easy Software Testing

1) Software testing aims to find faults and ensure quality, with the cost to fix faults increasing significantly the later they are found. 2) A test plan outlines the testing process, requirements, schedule, procedures, and environment. 3) Testing typically progresses from component testing of individual units by developers, to integration testing of combined components by an independent team.

Uploaded by

Gaurav Tyagi
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
51 views

Easy Software Testing

1) Software testing aims to find faults and ensure quality, with the cost to fix faults increasing significantly the later they are found. 2) A test plan outlines the testing process, requirements, schedule, procedures, and environment. 3) Testing typically progresses from component testing of individual units by developers, to integration testing of combined components by an independent team.

Uploaded by

Gaurav Tyagi
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 18

Software Testing and

Analysis
Ultimate goal for software testing

Quality
Assurance
Cost to fix faults

60* to 100*

1.5* to 6*

Cost 1*

Definition Development Post Release


The structure of a software test plan

• The testing process


• Requirements traceability
• Tested items
• Testing schedule
• Test recording procedures
• Hardware and software requirements
• Constraints
Testing phases

Component Integration
testing testing

Software developer Independent testing team


Testing phases
• Component testing
– Testing of individual program components
– Usually the responsibility of the component
developer (except sometimes for critical
systems)
– Tests are derived from the developer’s
experience
• Integration testing
– Testing of groups of components integrated to
create a system or sub-system
– The responsibility of an independent testing
team
– Tests are based on a system specification
Testing priorities
• Only exhaustive testing can show a program
is free from defects. However, exhaustive
testing is impossible
• Tests should exercise a system's capabilities
rather than its components
• Testing old capabilities is more important
than testing new capabilities
• Testing typical situations is more important
than boundary value cases
Test data and test cases

• Test data Inputs which have been


devised to test the system

• Test cases Inputs to test the system and


the predicted outputs from these inputs if
the system operates according to its
specification
Development of test cases

• Test cases and test scenarios comprise much


of a software systems testware.

• Black box test cases are developed by


domain analysis and examination of the
system requirements and specification.

• Glass box test cases are developed by


examining the behavior of the source code.
Methods of testing

• Test to specification:
– Black box,
– Data driven
– Functional testing
– Code is ignored: only use specification document
to develop test cases
• Test to code:
– Glass box/White box
– Logic driven testing
– Ignore specification and only examine the code.
Black-box testing

• An approach to testing where the


program is considered as a ‘black-box’
• The program test cases are based on the
system specification
• Test planning can begin early in the
software process
Black-box testing
Inputs causing
anomalous
Input test data I behaviour
e

System

Outputs which reveal


the presence of
Output test results Oe defects
Testing guidelines - sequences

• Test software with sequences which have


only a single value
• Use sequences of different sizes in
different tests
• Derive tests so that the first, middle and
last elements of the sequence are
accessed
• Test with sequences of zero length
Integration testing

• Tests complete systems or subsystems


composed of integrated components
• Integration testing should be black-box testing
with tests derived from the specification
• Main difficulty is localising errors
• Incremental integration testing reduces this
problem
Incremental integration testing

A T1
T1
A
T1 T2
A B
T2
T2 B T3
T3
B C
T3 T4
C
T4
D T5

Test sequence Test sequence Test sequence


1 2 3
Approaches to integration testing

• Top-down testing
– Start with high-level system and integrate from the
top-down replacing individual components by stubs
where appropriate
• Bottom-up testing
– Integrate individual components in levels until the
complete system is created
• In practice, most integration involves a
combination of these strategies
Top-down testing

Testing
Level 1 Level 1 . ..
sequence

Level 2 Level 2 Le vel 2 Level 2

Le vel 2
stubs

Le vel 3
stubs
Bottom-up testing

Test
drivers

Testing
Level N Level N Le vel N Level N Level N
sequence

Test
drivers
Level N–1 Level N–1 Level N–1

You might also like