Software Testing

Naresh Chauhan, Assistant Professor in the

Department of Computer Engineering at the
YMCA University of Science and Technology,
Faridabad

1
© Oxford University Press 2011. All rights
 Chapter 7
Validation Activities

2
© Oxford University Press 2011. All rights
 Objectives

• Validation is the next step after verification.

• Validation is performed largely by black box testing techniques.
• Unit validation testing
• Integration Testing and its types
• Function Testing
• System Testing and its types: Recovery testing, Security testing,
Stress testing, Performance Testing, Usability testing, Compatibility
testing
• Acceptance Testing and its types: Alpha and Beta testing

3
© Oxford University Press 2011. All rights
 Evolution
Unitof Software
Validation Testing Testing

∙ Drivers

• a test driver is supporting code and data used to provide an

environment for testing part of a system in isolation.
• A test driver may take inputs in the following form and call the
unit to be tested:
• It may hardcode the inputs as parameters of the calling unit.
• It may take the inputs from the user.
• It may read the inputs from a file.

4
© Oxford University Press 2011. All rights
 Unit Validation Testing
Evolution of Software Testing
• Stubs
Stub can be defined as a piece of software that works similar to
a unit which is referenced by the Unit being tested, but it is much
simpler that the actual unit.

5
© Oxford University Press 2011. All rights
 Integration Testing

• Integration testing exposes inconsistency between the modules

such as improper call or return sequences.
• Data can be lost across an interface.
• One module when combined with another module may not give the
desired result.
• Data types and their valid ranges may mismatch between the
modules.

6
© Oxford University Press 2011. All rights
Decomposition Based Integration

7
© Oxford University Press 2011. All rights
 Integration Testing

8
© Oxford University Press 2011. All rights
 Practical Approach for Integration Testing

There is no single strategy adopted for industry practice.

For integrating the modules, one cannot rely on a single

strategy. There are situations depending upon the project
in hand which will force to integrate the modules by
combining top-down and bottom-up techniques.

This combined approach is sometimes known as Sandwich

Integration testing.

The practical approach for adopting sandwich testing is driven

by the following factors:
Priority
Availability

9
© Oxford University Press 2011. All rights
 Software Testing
Decomposition based Myths
integration testing

• The integration testing effort is computed as number of test

sessions. A test session is one set of test cases for a specific
configuration. The total test sessions in decomposition based
integration is computed as:

Number of test sessions = nodes – leaves + edges

10
© Oxford University Press 2011. All rights
Incremental Integration Testing

11
© Oxford University Press 2011. All rights
 Call Graph Based Integration

• A call graph is a directed graph wherein nodes are modules or units

and a directed edge from one node to another node means one
module has called another module. The call graph can be captured
in a matrix form which is known as adjacency matrix.

12
© Oxford University Press 2011. All rights
 Pair-wise Integration

13
© Oxford University Press 2011. All rights
 Neighborhood Integration

The total test sessions in

neighborhood integration can be
calculated as:
Neighborhoods = nodes – sink
nodes
= 20 - 10
= 10
where Sink Node is an instruction in
a module at which execution
terminates.

14
© Oxford University Press 2011. All rights
 Path Based Integration

• Source Node
• Sink Node
• Module Execution Path (MEP) Message
• MM-Path
• MM-Path Graph

15
© Oxford University Press 2011. All rights
 Path Based Integration

16
© Oxford University Press 2011. All rights
 Path Based Integration

17
© Oxford University Press 2011. All rights
 Function Testing

• The process of attempting to detect discrepancies between the

functional specifications of a software and its actual behavior.
• The function test must determine if each component or
business event:
– performs in accordance to the specifications,
– responds correctly to all conditions that may be presented
by incoming events / data,
– moves data correctly from one business event to the next
(including data stores), and
– business events are initiated in the order required to meet
the business objectives of the system.

18
© Oxford University Press 2011. All rights
 System Testing

19
© Oxford University Press 2011. All rights
 Recovery Testing

• Recovery is just like the exception handling feature in a

programming language.

• Recovery is the ability of a system to restart operations after the

integrity of the application has been lost.

• It reverts to a point where the system was functioning correctly and

then reprocesses the transactions up until the point of failure Some

20
© Oxford University Press 2011. All rights
 Security Testing

• Confidentiality
• Integrity
• Authentication
• Authorization
• Availability
• Non-repudiation

21
© Oxford University Press 2011. All rights
 Performance Testing

The performance testing requires that performance requirements

must be clearly mentioned in SRS and system test plans.

The main thing is that these requirements must be quantified.

For example, a requirement that the system return a response to a

query in a reasonable amount is not an acceptable requirement; the
time must be specified in a quantitative way.
• Load Testing
• Stress Testing

22
© Oxford University Press 2011. All rights
 Usability Testing

Ease of Use

Interface steps

Response Time

Help System

Error Messages

23
© Oxford University Press 2011. All rights
 Compatibility/Conversion/Configuration Testing

• Operating systems: The specifications must state all the targeted

end-user operating systems on which the system being developed
will be run.

• Software/ Hardware: The product may need to operate with certain

versions of web browsers, with hardware devices such as printers,
or with other software, such as virus scanners or word processors.

• Conversion Testing
• Ranking of possible configurations: Identification of test cases:

• Updating the compatibility test cases

24
© Oxford University Press 2011. All rights
 Acceptance Testing

• Acceptance Testing is the formal testing conducted to determine

whether a software system satisfies its acceptance criteria and to
enable buyer to determine whether to accept the system or not.
• Determine whether the software is fit for the user to use.
• Making users confident about product
• Determine whether a software system satisfies its acceptance
criteria.
• Enable the buyer to determine whether to accept the system.

• Alpha Testing Beta Testing

25
© Oxford University Press 2011. All rights