Instructor: Dr.
Syed Ali Raza
Department of Computer Science
GC University Lahore
Software
Testing Conventional Applications
Testability
• Operability—it operates cleanly
• Observability—the results of each test case are readily observed
• Controllability—the degree to which testing can be automated and
optimized
• Decomposability—testing can be targeted
• Simplicity—reduce complex architecture and logic to simplify tests
• Stability—few changes are requested during testing
• Understandability—of the design
What is a “Good” Test?
• A good test has a high probability of finding an error
• A good test is not redundant.
• A good test should be “best of breed”
• A good test should be neither too simple nor too complex
Internal and External Views
• Any engineered product (and most other things) can
be tested in one of two ways:
• Knowing the specified function that a product has been
designed to perform, tests can be conducted that
demonstrate each function is fully operational while at the
same time searching for errors in each function
• Knowing the internal workings of a product, tests can be
conducted to ensure that "all gears mesh," that is, internal
operations are performed according to specifications and all
internal components have been adequately exercised.
Test Case Design
• "Bugs lurk in corners and congregate at boundaries ..."
Boris Beizer
• OBJECTIVE
• to uncover errors
• CRITERIA
• in a complete manner
• CONSTRAINT
• with a minimum of effort and time
Exhaustive Testing
Q: How many possible paths are
there?
14
There are 10 possible paths! If we execute one
test per millisecond, it would take 3,170 years to
test this program!!
loop < 20 X
Selective Testing
Selected path
loop < 20 X
Software Testing
white-box black-box
methods methods
Methods
Strategies
White-Box Testing
... our goal is to ensure that all
statements and conditions have
been executed at least once ...
White Box Testing
White box Testing: Statement
coverage
• Statement coverage involves the execution of all the statements at
least once in the source code.
• Through statement coverage we can identify the statements
executed and where the code is not executed because of blockage.
• The statement coverage covers only the true conditions.
• The statement coverage is counted as per below formula
White box Testing: Statement
coverage
• Set1 :If A =5, B =2 Read A
• No of statements executed: 5
• Total no of statements in the source
Read B
code: 7 if A>B
• Statement coverage =5/7*100 =71%
Print “A is greater than B”
• Set1 :If A =2, B =5 [False-Not
supported by Statement coverage] else
• No of statements Executed: 6 Print "B is greater than A"
• Total no of statements in the source
code: 7 endif
• Statement coverage =6/7*100 = 85%
Path Testing
• Path Testing when used is based upon achieving “complete” path
coverage.
• This involves following all of the possible paths in a module.
• Different paths in a software module are created by the choice in
conditional statements.
• The main reason for working as a percentage to find out how much
of the testing has been completed.
• However when looking at the amount of resources needed it
becomes very “impractical”.
Path Testing
• Another major problem that is addresses is “the cost” an example of this can
be shown below.
• Modules = 5 conditional statements
• Each with only 2 options (IF-THEN-ELSE)
• EQUALS = 24 different paths (25 – 50 lines of code)
• Achieve “Complete Path Coverage”
• Modules = 50 conditional statements
• Achieve “Complete Path Coverage”
• Equals = ???
Cyclomatic Complexity
• Measures the complexity of a program or module. modules
• Addition to this it also measures the “maximum
number of independent paths needed to successfully
achieve full line coverage”
• Calculates this through a formulae to work out the
independent paths needed.
• This type of method works off the characteristics of V(G)
a flow graph. Our example will give us a better
understanding of how McCabes theories work! modules in this range are
more error prone
• A number of industry studies have indicated that the
higher V(G), the higher the probability or errors.
Basis Path Testing
• V(G) = R
First, we compute the cyclomatic
complexity:
• V (G) = E –N + 2
• V(G) = P + 1
number of simple decisions + 1
• R = The number of regions that is
or involved in the program flow graph.
(Any enclosed area including the
number of enclosed areas + 1 outer layer of the flow diagram.)
• E = The number of edges
In this case, V(G) = 4
• N = The number of nodes
• P = The number of decisions
Basis Path Testing
• Red Circles indicate the regions within our car insurance example
• The amount of arrows subtracted by the number of
nodes
• The diamond shapes are represented
as P as they are decision entities.
• Our Example • V(G) = R
• V(G) = 6 • V (G) = E –N + 2
• V(G) = 21 -17 + 2 = 6 • V(G) = P + 1
• V(G) = 5 + 1 = 6
• R = The number of regions
• E = The number of edges
• N = The number of nodes
• P = The number of decisions
Basis Path Testing Notes
you don't need a flow chart,
but the picture will help when
you trace program paths
count each simple logical test,
compound tests count as 2 or
more
basis path testing should be
applied to critical modules
Deriving Test Cases
• Summarizing:
• Using the design or code as a foundation, draw a
corresponding flow graph.
• Determine the cyclomatic complexity of the resultant flow
graph.
• Determine a basis set of linearly independent paths.
• Prepare test cases that will force execution of each path in
the basis set.
