Scribd
Upload
13 views

Lecture 9 Software Engineering CS-2105

The document outlines key concepts in software testing, focusing on testability attributes such as operability, observability, and controllability. It discusses the importance of good test design, including criteria for effective testing and methods like white-box and black-box testing. Additionally, it introduces concepts like cyclomatic complexity and basis path testing to measure and ensure thorough testing coverage in software applications.

Uploaded by

Muhammad Usama
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
13 views

Lecture 9 Software Engineering CS-2105

The document outlines key concepts in software testing, focusing on testability attributes such as operability, observability, and controllability. It discusses the importance of good test design, including criteria for effective testing and methods like white-box and black-box testing. Additionally, it introduces concepts like cyclomatic complexity and basis path testing to measure and ensure thorough testing coverage in software applications.

Uploaded by

Muhammad Usama
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 20

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.

You might also like