Software testing - Definition
Is a formal ( SW test plan ) process carried out
Software testing objectives
Direct objectives:
To identify and reveal as many errors as possible in the tested SW.
To bring the tested SW, after correction of the
identified errors and retesting, to an acceptable level of quality.
To perform the required tests efficiently, within budgetary and scheduling limitations.
Indirect objectives
Software testing Strategies
To test the SW in its entirety, once the
completed package is available; otherwise known as “big bang testing “.
To test the SW piecemeal, in modules, as they are completed ( unit tests ) ; then to test groups of tested modules integrated with newly
completed modules ( integrated tests ). This
process continues until all the entire package is tested as whole ( system test ). This testing
strategy is usually termed “incremental testing”
Incremental testing is also performed according to two basic Strategies:
Bottom-Up ( 4 stages ) see fig page 183
Top-down ( 6 stages )
The incremental pathes:
Horizontal sequence ( breadth first )
Vertical sequence ( Depth first )
Stubs & Drivers for incremental testing
Stubs and drivers are SW replacement
simulators required for modules not available when performing a unit test or an integration test.
Stubs ( often termed a “Dummy Module “ ) replaces an unavailable lower level module, subordinate to the module tested.
It is required for top-down testing of
incomplete systems. See example fig 9.2
Stubs & Drivers for incremental testing
A driver is a substitute module but of the
upper level module that activates the module tested.
The driver is passing the test data on to the tested module and accepting the results
calculated by it.
It is required in bottom-up testing until the upper level modules are developed.
See example fig 9.2
Bottom-Up Vs Top-Down strategies
Main Adv. Of bottom-up :
The relative ease of its performance
Main disadv.
The lateness at which the prog. As whole can be observed ( at the stage following testing of the last module )
Main adv. Of Top-down:
The possibility it offers to demonstrate the entire prog. Function shortly after activation of the upper-level modules has been completed. This characteristic allows for early identification of analysis & design errors related to algorithms, functional requir. , and the like.
Main disadv.
The relative difficulty of preparing the required stubs, with often require very complicated programming.
The relative difficulty of analyzing the result of the tests.
Big bang Vs. Incremental testing
The main disadvantages of big bang :
Identification of errors becomes difficult
Corrections will be at the same time.
Error correction estimation of the required testing
resources and testing schedule a rather fuzzy endeaver.
Incremental testing adv.:
Usually performed on relatively small SW modules, as unit or integration tests.( more errors detection )
Identification and correction of errors is much simpler
Software test classification.
Classification according to testing concept:
Two testing classes have been developed:
Black box ( functionality ) testing:
Identifies bugs only according to SW malfunctioning as they are revealed in its erroneous output.
Incases that outputs are found to be correct, black box testing disregarded the internal path of calculations and processing performed.
White box ( structural ) testing:
Examines internal calculation paths in order to identify bugs.
The white is meant to emphasize the contrast between methods
Software test classification.
Classification according to requirements:
See table 9.1 Page 188
White Box Testing
White box testing concept requires verification of every program statement and comment.
See table 9.2 , white box testing enables performance of
data processing and calculations correctness tests
SW qualification tests
Maintainability tests
Reusability tests
Every computational operation in the sequence of operations created by each test case ( “Path” ) must be examined.
This type of verification allows us to decide whether the processing operations and their sequences were programmed correctly for the path in question, but not for other pathes.
Data processing and calculation correctness tests Path coverage & line coverage
Path coverage : total number of possible paths
10 if-then-else : 1024 paths
Line coverage: for full line coverage, every line of code be executed at least once during the process of testing. The line coverage metrics for completeness of a line-testing plan are defined as the percentage of
lines indeed executed during the tests. Flow chart and a program flow graph are used.
Example 191.
McCabe’s cyclomatic complexity metrics
Measures the complexity of a program or module at the same time as it determines the maximum number of independent paths needed to achieve full line Coverage of the program.
The measure is based on graph theory using program flow graph.
An independent path is defined with reference to the succession of independent paths accumulated.
Independent path is any path on the program flow graph that includes at least one edge that is not included in any former independent paths.
See table 9.5 page 194
McCabe’s cyclomatic complexity metrics
The cyclomatic complexity metric V(G)
V(G) = R = E – N + 2 = P + 1
Where R = the number of regions
E = number of edges
N = number of nodes
P = number of decisions ( nodes having more than one leaving edge).
See example page 195
An empirical studies show that if V(G) < 5 considered simple
If it is 10 or less considered not too difficult
If 20 or more it is high
SW qualification & reusability testing
SW qualification testing
SW reusability testing
Adv & disadv. Of White box