Path Testing

Path Testing
• Path testing is a Structural Testing method that involves using
the source code of a program to attempt to find every
possible executable path.

• The idea is that are able to test each individual path from
source code is as many way as possible in order to maximize
the coverage of each test case.

• Therefore, we use knowledge of the source code to define the

test cases and to examine outputs.

• Test cases derived to exercise the basis set are guaranteed to

execute every statement in the program at least one time
during testing
Flow Graph

• Given a program written in an imperative programming

language, its program graph is a directed graph in which
nodes are statement fragments, and edges represent flow of
control

• It may be called “Control Flow Graph”

Flow chart & Flow Graph
Flow Chart Flow Graph
0 0

1 1

2 2

3
3

6 4 6 4

7 8 5
7 8 5
9
9
11 10 11 10
Flow Graph Notation
Notation Description

A circle in a graph represents a node,

which stands for a sequence of one or
more procedural statements
A node containing a simple conditional
expression is referred to as a predicate
node which has two edges leading out
from it (True and False)

An edge, or a link, is a an arrow

representing flow of control in a
specific direction
- An edge must start and terminate at
a node
- An edge does not intersect or cross
over another edge
 Flow Graph Example(1)
2

1. Program ‘Simple Subtraction’

3
2. Input(x,y)
3. Output (x)
4
4. Output(y)
5. If x> y then Do
6. x-y = z 5
7. Else y-x = z
8. EndIf 6 7
9. Output(z)
8
10. Output “End Program”

10
Flow Graphs consist of
2

• A decision is a program point at which

the control can diverge. 3
• (e.g., if and case statements)
4

6 7
N Y Y

8
N

Switch case 9
While Loop Until Loop
10
Flow Graphs consist of
2

• A junction is a program point where

the control flow can merge. 3
• (e.g., end if , end loop, goto label)
4

6 7
Goto
8
Connector

10
Flow Graphs consist of
2

• A process block is a sequence of

program statements uninterrupted by 3
either decisions of junction.
• (i.e. straight-line code) 4

Sequence
6 7

10
 Flow Graph Example(2)
1

2
1. scanf(“%d %d”,&x, &y);
2. If (y<0) 3 4
3. pow = -y;
else 5
4. pow = y;
5. Z = 1.0 6
6. While (pow != 0) {
7. z = z*x; 7
8. pow = pow -1; }
9. If (y <0) 8
10. z = 1.0 /z;
11. printf(“%f”,z); 9
10
1
What is Path?
• A path through a program is a sequence of statements that
starts at an entry, junctions, or decision and ends.

• A path may go through several junctions, processes, or

decisions, on or more times.

• Paths consist of segments that has smallest segment is a link

between 2 nodes.
What is Path?
2

• For example: 3

Path1 = 2-3-4-5-6-8-9-10
4

6 7

10
What is Path?
2

• For example: 3

Path2 = 2-3-4-5-7-8-9-10
4

6 7

10
 Path Testing Strategies

1
• Statement Testing
a • 100% statement / node coverage

b
2 • Branch Testing
T F c • 100% branch/ link coverage
3 4
• Path Testing
d e • 100% path coverage
5
f T Fg
6 7

h i
8

j
9
 Path Testing Strategies

1
• Statement Testing
a • 100% statement / node coverage

b
2 • Branch Testing
T F c • 100% branch/ link coverage
3 4
• Path Testing
d e • 100% path coverage
5
f T Fg
6 7

h i
8

j
9
 Path Testing Strategies

1
• Statement Testing
a • 100% statement / node coverage

b
2 • Branch Testing
T F c • 100% branch/ link coverage
3 4
• Path Testing
d e • 100% path coverage
5
f T Fg
6 7

h i
8 Statement Testing < Branch Testing < Path Testing
j
9
 Path Testing Strategies

1
• Statement Testing
a • 100% statement / node coverage

b
2 • Branch Testing
T F c • 100% branch/ link coverage
3 4
• Path Testing
d e • 100% path coverage
5
f T Fg
6 7

h i
8 Statement Testing < Branch Testing < Path Testing
j
9
 Path Testing Strategies

1
• Statement Testing
a • 100% statement / node coverage

b
2 • Branch Testing
T F c • 100% branch/ link coverage
3 4
• Path Testing
d e • 100% path coverage
5
f T Fg
6 7

h i
8 Statement Testing < Branch Testing < Path Testing
j
9
 Path Testing Strategies

1
• Statement Testing
a • 100% statement / node coverage

b
2 • Branch Testing
T F c • 100% branch/ link coverage
3 4
• Path Testing
d e • 100% path coverage
5
f T Fg
6 7

h i
8 Statement Testing < Branch Testing < Path Testing
j
9
 A Coverage Table
Decisions Process-Link
1 Paths 2 5 a b c d e f g h i j
a
1-2-3-5-6-8- T T      
2
b c 9
T F
(a-b-d-f-h-j)
3 4
1-2-4-5-7-8- F F      
d e 9
5
f T F g (a-c-e-g-i-j)
6 7 1-2-3-5-7-8- T F      
h i 9
8
(a-b-d-g-i-j)
j
1-2-4-5-6-8- F T      
9
9
(a-c-e-f-h-j)
 Exmple Flow Graph
1. Program Triangle
4 5 6 7 8
2. Dim a, b,c As Integer
3. Dim IsTriangle As Boolean
9
4. Output ( “enter a,b, and c integers”)
5. Input (a,b,c) 10 11
6. Output (“side 1 is”, a)
7. Output (“side 2 is”, b)
12
8. Output (”side 3 is”, c)

9. If (a<b+c) AND (b<a+c) And (c<b+a) 13

Flow Graph
10. then IsTriangle = True
21 14
11. else IsTriangle = False
12. endif
15 16

13. If IsTriangle
17 18
14. then if (a=b) AND (b=c)
15. then Output (“equilateral”)
16. else if (a != b) AND (a != b) AND (b != c) 20 19
17. then Output ( “Scalene”)
18. else Output (“Isosceles”) 22
19. endif
20. endif
23
21. else Output (“not a triangle”)
22. endif
23. end Triangle2
Basis Path Testing
4 5 6 7 8

• Select Path is shortest or simple path 9

• For example: 10 11

4-5-6-7-8-9-10-12-13-21-22-23 12

13

21 14

15 16

17 18

20 19

22

23
Test Case for Path Coverage
 4-5-6-7-8-9-10-12-13-21-22-23
 4-5-6-7-8-9-11-12-13-14-15-20-22-23
 4-5-6-7-8-9-11-12-13-14-16-17-19-20-22-23
 4-5-6-7-8-9-11-12-13-14-16-18-19-20-22-23

Path Decision Test case Expected

Results
9 13 14 16 a b c
 T F 100 100 200 Not A
triangle
 F T T 100 100 100 Equilateral
 F T F T 100 50 60 Scalene
 F T T F 100 100 50 Isosceles
DD-Paths
• It stand for Decision-to-Decision path in
a directed graph.
• A path are consists of the initial and
nodes and interior node has indegree = 1
and outdegree = 1

indegree =1

outdegree =1
DD-Paths
Characteristic of DD-Path has 5 cases:
• Case 1: Single node with indeg =0
• Case 2: Single node with outdeg = 0
• Case 3: Single node with indeg >= 2 or outdeg >=2
• Case 4: Single node with indeg = 1 and outdeg =1
• Case 5: Maximum chain of length >=1
 Condensation of Code to Table then to Flow Graph
Path/node DD-path
code statement name Case
1. Program Triangle
2. Dim a, b,c As Integer Skip 1- 3
3. Dim IsTriangle As Boolean (or w/4)
4 first 1
4. Output ( “enter a,b, and c integers”) 5–8 A 5
5. Input (a,b,c)
6. Output (“side 1 is”, a) 9 B 3
7. Output (“side 2 is”, b)
8. Output (”side 3 is”, c)
10 C 4
11 D 4
9. If (a<b+c) AND (b<a+c) And (c<b+a) Def of 12 E 3
10. then IsTriangle = True DD-paths on 13 F 3
11. else IsTriangle = False 14 H 3
12. endif 15 I 4
16 J 3
13. If IsTriangle
14. then if (a=b) AND (b=c)
17 K 4
15. then Output (“equilateral”) 18 L 4
16. else if (a NE b) AND (a NE b) AND (b NE c) 19 M 3
17. then Output ( “Scalene”) 20 N 3
18. else Output (“Isosceles”) 21 G 4
19. endif 22 O 3
20. endif 23 last 2
21. else Output (“not a triangle”)
22. endif
23. end Triangle2
DD-Path
First
4 5 6 7 8

A
9
B
10 11
C D
12
E
13
F
21 14
G H
15 16
I J
17 18
K L
20 19
N M
22
O

23
Last
Path Analysis
• What is path analysis?

• Analyzes the number of paths that exist in the system

• Facilitates the decision process of how many paths to

include in the test
Path Analysis: Cyclomatic complexity
measure (CFC)
A

CFC can be calculated by

B D
F T
V(G) = e-n+2 p
T E F
e : the number of edges
n : the number of nodes C F
P:number if connected region
G
Example: = 10-7+2 = 5
Path Analysis: Cyclomatic complexity
measure (CFC)
• If flow graph has link between
sink node(G) to source node(A) which is
called a strongly connected graph. A

V(G) = e-n+1 B D
e : the number of edges F T
n : the number of nodes T E F

C F
Example: 11-7+1 = 5
G
How to select path

• Independent Path
• McCabe’s Baseline
 Independent Path
• Independent program paths an independent path is
any path through the program that introduces at least
one new set of processing statements or a new
condition.
• Cyclomatic complexity is a software metric that
provides a quantitative measure of the logical A
complexity if a program
• No count on traverse edge between sink node-G to
source node-A B D
• P1: A-B-C-G F T
• P2: A-B-C-B-C-G T E F
• P3: A-B-E-F-G
• P4: A-D-E-F-G C F
• P5: A-D-F-G
G
 Independent Path

Problem of Independent path

• P1: A-B-C-G
• P2: A-B-C-B-C-G
• P3: A-B-E-F-G A
• P4: A-D-E-F-G
• P5: A-D-F-G B D
• Ex1: A-B-C-B-E-F-G F T
• Ex2: A-B-C-B-C-B-C-G T E F

C F

G
McCabe’s Baseline
To determine a set of basis paths,
1. Pick a "baseline" path that corresponds to normal execution.
(The baseline should have as many decisions as possible.)

2. To get succeeding basis paths, retrace the baseline until you

reach a decision node. "Flip" the decision (take another
alternative) and continue as much of the baseline as possible.

3. Repeat this until all decisions have been flipped. When you
reach V(G) basis paths, you're done.

4. If there aren't enough decisions in the first baseline path, find

a second baseline and repeat steps 2 and 3.
McCabe’s Baseline

• P1: A-B-C-B-E-F-G A
• P2: A-D-E-F-G
• P3: A-D-F-G B D
• P4: A-B-E-F-G F T
T E F
• P5: A-B-C-G
C F

G
 McCabe’s Path of Triangle Program
First

McCabe Paths Expected A

Results
B
Original P1: First-A-B-C-E-F-H-J-K-M-N-O- Scalene
Last C D

Flip P1 P2: First-A-B-D-E-F-H-J-K-M-N-O- Infeasible E

at B Last path
F
Flip P1 P3: First-A-B-C-E-F-G-O-Last Infeasible
G H
at F path
I J
Flip P1 P4: First-A-B-C-E-F-H-I-N-O-Last Equilateral
at H K L

Flip P1 P5: First-A-B-C-E-F-H-J-L-M-N-O- Isosceles N M

at J Last
O

Last
 McCabe’s Path

• Weakness of McCabe’s Path may occur “infeasible path” which

means no found test case design to match with the path.

McCabe Paths Expected

Results
P1 Original P1: First-A-B-C-E-F-H-J-K-M-N-O-Last Scalene
P6(from P2 and P3) New P6: First-A-B-D-E-F-G-O-Last Not a Triangle
P4 Flip P1 at H P4: First-A-B-C-E-F-H-I-N-O-Last Equilateral
P5 Flip P1 at J P5: First-A-B-C-E-F-H-J-L-M-N-O-Last Isosceles
From path analysis to test case design

Test Case a b c Expected Results From Path

1 3 4 5 Scalene P1

2 4 1 2 Not a Triangle P6

3 5 5 5 Equilateral P4

4 3 2 2 Isosceles P5
 Steps of path testing

• Deriving Test Cases

1. Using the design or code, draw the corresponding flow graph.
2. Determine the cyclomatic complexity of the flow graph.
3. determine a set of path by basis/independent/McCabe’s paths.
4. Prepare test cases that will force execution of each path in the
basis set.
Basis Path Testing Example
public double calculate(int amount)
{
1. double rushCharge = 0;
if (nextday.equals("yes") )
{
2. rushCharge = 14.50; }
3 double tax = amount * .0725;
3 if (amount >= 1000) {
4. shipcharge = amount * .06 + rushCharge; }
5. else if (amount >= 200) {
6. shipcharge = amount * .08 + rushCharge; }
7. else if (amount >= 100) {
8. shipcharge = 13.25 + rushCharge; }
9. else if (amount >= 50) {
10. shipcharge = 9.95 + rushCharge; }
11. else if (amount >= 25) {
12. shipcharge = 7.25 + rushCharge; }
else {
13. shipcharge = 5.25 + rushCharge; }
14. total = amount + tax + shipcharge;
14. return total;
} //end calculate
Basis Path Testing Example
1
2
• Here is a drawing of the flowgraph.
3
4

5 6

7 8

9 10

11 12

13

14
Basis Path Testing Example

• Step 2: Determine the cyclomatic complexity of the flow

graph.

• V(G) = E - N + 2
= 19 - 14 + 2
= 7
Basis Path Testing Example

• Step 3: Determine the basis set of independent paths.

• Path 1: 1 - 2 - 3 - 5 - 7 - 9 - 11 - 13 - 14
Path 2: 1 - 3 - 4 - 14
Path 3: 1 - 3 - 5 - 6 - 14
Path 4: 1 - 3 - 5 - 7 - 8 - 14
Path 5: 1 - 3 - 5 - 7 - 9 - 10 - 14
Path 6: 1 - 3 - 5 - 7 - 9 - 11 - 12 - 14
Path 7: 1 - 3 - 5 - 7 - 9 - 11 - 13 - 14
Basis Path Testing Example
• step 4: Prepare test cases that force execution of each path in
the basis set.
Path Nextday Amount Expected
Results
P1 yes 10 30.48
P2 No 1500 1713.25
P3 No 300 345.75
P4 No 150 174.125
P5 No 75 90.3875
P6 No 30 39.425
P7 No 10 15.975
Essential Complexity
• McCabe’s work on cyclomatic complexity does more to improve
programming than testing, so our simplifications have been based
on removing either strong components or DD-paths. Here, we
condense around the structured programming constructs, which are
repeated.
• The basic idea is to look for the graph of one of the structured
programming constructs, collapse it into a single node, and repeat
until no more structured programming constructs can be found.
• Starts with the DD-path graph of the pseudocode triangle program.
The if–then–else construct involving nodes B, C, D, and E is
condensed into node a, and then the three if–then constructs are
condensed onto nodes b, c, and d. The remaining if–then–else
(which corresponds to the IF IsATriangle statement) is condensed
into node e, resulting in a condensed graph with cyclomatic
complexity V(G) = 1.
• In general, when a program is well structured (i.e., is composed
solely of the structured programming constructs), it can always be
reduced to a graph with one path.
322 235 การทดสอบซอฟต ์แวร ์ 45
322 235 การทดสอบซอฟต ์แวร ์ 46
322 235 การทดสอบซอฟต ์แวร ์ 47
The bottom line for testers is this: programs with high
cyclomatic complexity require more
testing but violations increase cyclomatic complexity

322 235 การทดสอบซอฟต ์แวร ์ 48

E.F. Miller’s Coverage Metrics
• Several widely accepted test coverage metrics are used; most of those
in Table 8.1 are due to the early work of Miller (1977). Most quality
organizations now expect the C1 metric (DD-path coverage) as the
minimum acceptable level of test coverage. Miller’s test coverage
metrics are based on program graphs in which nodes are full
statements, whereas our formulation allows statement fragments
(which can be entire statements) to be nodes.

322 235 การทดสอบซอฟต ์แวร ์ 49

Statement Testing:
• program graphs allows statement fragments to be individual nodes,
Miller’s C0 metric is subsumed by our Gnode metric.
• Statement coverage is generally viewed as the bare minimum. If
some statements have not been executed by the set of test cases,
there is clearly a severe gap in the test coverage.

DD-Path Testing:
• When every DD-path is traversed (the C1 metric), we know that
each predicate outcome has been executed; this amounts to
traversing every edge in the DD-path graph (or program graph).
• For if–then and if–then–else statements, this means that both the
true and the false branches are covered (C1p coverage). For CASE
statements, each clause is covered.

322 235 การทดสอบซอฟต ์แวร ์ 50

• Simple Loop Coverage:
• The C2 metric requires DD-path coverage (the C1 metric) plus
loop testing.
• The simple view of loop testing is that every loop involves a
decision, and we need to test both outcomes of the decision: one is
to traverse the loop, and the other is to exit (or not enter) the loop.
• Predicate Outcome Testing:
• This level of testing requires that every outcome of a decision
(predicate) must be exercised. Because our formulation of program
graphs allows statement fragments to be individual nodes.
• Dependent Pairs of DD-Paths:
• Identification of dependencies must be made at the code level. This
cannot be done just by considering program graphs.
• The most common dependency among pairs of DD-paths is the
define/reference relationship, in which a variable is defined
(receives a value) in one DD-path and is referenced in another DD-
path. The importance of these dependencies is that they are closely
related to the problem of infeasible paths.
322 235 การทดสอบซอฟต ์แวร ์ 51
Complex Loop Coverage

Miller’s Cik metric extends the loop coverage metric to include

full paths from source to sink nodes that contain loops.

Concatenated loops are simply a sequence of disjoint loops,

while nested loops are such that one is contained inside another.
Knotted (Beizer calls them “horrible”) loops cannot occur when
the structured programming precepts are followed, but they can
occur in languages like Java with try/catch.

322 235 การทดสอบซอฟต ์แวร ์ 52

Fault-based Testing
The basic concepts of fault-based testing is to select test cases the
would distinguish the program under test from alternative program
that contain hypothetical faults. This is usually approached by
modifying the program under test to actually produce the hypothetical
fault program.

Assumption in fault-based testing

• Competent program hypothesis: states that program tend to write

program that are close to being correct.

• Coupling effect hypothesis: state that a test data set that detects all
simple faults in program is so sensitive that will also detect more
complex faults.
Fault-based adequacy criteria

Given a program and test suit T ,mutation analysis consists of following steps

Select mutation operator:If we are interested in the specific class of fault

,we may select a set of mutation operator relevant to those fault.

Generate mutants:Mutants are generated mechanically by applying

mutation operator to the original program.

Distinguish mutant:Execute the original program and each generated

mutant with test cases in T. A mutant is killed when it can be distinguish
from the original program.
Mutants not killed by test Suits because it two reasons:

1. Mutant can be distinguish from original program but test suite T doesn’t
contain a test case that distinguish them.

2. The mutant cannot be distinguish from original program by any test

case.

Therefore the test adequacy for above program is 25% since only one
mutant killed out of the 4 by the selected test suits TS.

Varition on mutation analysis

The mutation analysis process which kills mutant based on outputs

produced by execution of test cases is known as strong mutation.

65
 Test Execution
Designing test cases and test suites is creative, executing test cases
should be automatic with the help of test automation .

The purpose of run-time support for testing is to enabale frequent

hands-free reexecution of test suits.

From test case specification to test cases

Test deign often yields test case specification rather then concrete
data.
Example:”A sorted sequence.length greater than 2,with item in
ascending order with no duplicates.
A rule of thumb is that, while test cases design involves
judgement and creativity, test case generation should be a
mechanical steps.
Automatic generation of concrete test cases from more abstract
test case specification reduces the impact of small interface
changes in the course of development.
The corresponding changes to the test suite are still required
with each program change,but change to test case specification
are likely to be smaller and more localized than changes to the
concerete tes cases.
Instantiating test cases that satisfy several constrains may be
simple if the constaints are independent but becomes more
difficult to automate when multiple constraints apply to the
same item.
Test case specification that may require considerable
computation to produce test data often arise in model based
testing.
SCOFFOLIDING

Code developed to facilitate testing is called scoffoliding.

Scaffolding includes:
1. Test driver(substituting for main or calling program)
2. Test harnesses(substituting for parts of the deployment
environment)
3. Stubs(substituting for functionality called or used by the
software under test)

The purposes of scaffolding are to provide controllability to

execute test cases and observability to judge the outcome of
test execution.
scaffolding for controllability and observability may be
required because the external interfaces of the system may
not provide sufficient control to drive the module under test
through test cases, or sufficient observability of the effect.

Example:An interactive program that is normally driven

through a graphical user interface. Assume that each night the
program goes through a fully automated and unattended cycle
of integration, compilation, and test execution.
It is necessary to perform some testing through the interactive
interface, but it is neither necessary nor efficient to execute all
test cases that way.
Small driver programs, independent of the graphical user
interface, can drive each module through large test suites in a
short time.
Generic versus Specific Scaffolding
The simplest form of scaffolding is a driver program that runs a
single, specific test case.
Fully generic scaffolding may suffice for small numbers of hand-
written test cases. For larger test suites, and particularly for those that
are generated systematically.
The simplest kind of stub, sometimes called a mock, can be generated
automatically by analysis of the source code.
The balance of quality, scope, and cost for a substantial piece of
scaffolding software say, a network traffic generator for a distributed
system .
Figure below illustrates use of generic test scaffolding in the JFlex
lexical analyzer generator.
Test Oracles
Software that applies a pass/fail criterion to a program
execution is called a test oracle.

A test oracle may apply a pass/fail criterion that reflects only

part of the actual program specification, or is an
approximation, and therefore passes some program
executions it ought to fail.

Several partial test oracles (perhaps applied with different

parts of the test suite) may be more cost-effective than one
that is more comprehensive. A test oracle may also give false
alarms, failing an execution that it ought to pass. False alarms
in test execution are highly undesirable.
One approach to judging correctness - but not the only one -
compares the actual output or behavior of a program with predicted
output or behavior. A test case with a comparison-based oracle relies
on predicted output that is either precomputed as part of the test case
specification or can be derived in some way independent of the
program under test.

Figure shows a test harness with a comparison-based test oracle

processes test cases consisting of (program input, predicted output)
pairs.
Precomputing expected test results is reasonable for a small
number of relatively simple test cases, and is still preferable
to manual inspection of program results because the expense
of producing (and debugging) predicted results is incurred
once and amortized over many executions of the test case.

 The comparison-based test oracles is often included in a

test harness program or testing framework. A harness
typically takes two inputs: (1) the input to the program under
test (or can be mechanically transformed to a well-formed
input), and (2) the predicted output.

The comparison-based test oracles are useful mainly for

small, simple test cases,but some times excepted outputs can
also be produced for complex test cases and large test suites.
Self-Checks as Oracles

Figure shows the When self-checks are embedded in the program, test
cases need not include predicted outputs.
A program or module specification describes all correct program
behaviors, so an oracle based on a specification need not be paired
with a particular test case. Instead, the oracle can be incorporated
into the program under test, so that it checks its own work.

Self-check assertion may be left in the production version of a

system, where they provide much better diagnostic information
than the uncontrolled application crash the customer may
otherwise report.

 The cost of a runtime assertion check is too high - most tools for
assertion processing also provide controls for activating and
deactivating assertions.
Capture and Replay
The savings from automated retesting with a captured log
depends on how many build and-test cycles we can continue
to use it in, before it is invalidated by some change to the
program.
Capturing events at a more abstract level suppresses
insignificant changes. For example, if we log only the actual
pixels of windows and menus, then changing even a typeface
or background color can invalidate an entire suite of
execution logs.
 The value of a captured log can be obtained by varying the
logged events to obtain additional test cases. Creating
meaningful and well-formed variations also depends on the
abstraction level of the log.
 Basic Principles
1. Sensitivity
Human developers make errors, producing faults in software.
Faults may lead to failures, but faulty software may not fail on
every execution. The sensitivity principle states that it is better to
fail every time than sometimes.
Consider the cost of detecting and repairing a software fault. If it
is detected immediately (e.g., by an on-the-fly syntactic check in a
design editor), then the cost of correction is very small, and in fact
the line between fault prevention and fault detection is blurred. If a
fault is detected in inspection or unit testing, the cost is still
relatively small.
A failure detected in integration testing, the cost of correction is
much greater. If the first failure is detected in system or acceptance
testing, the cost is very high indeed, and the most costly faults are
those detected by customers in the field.
2. Redundancy
Redundancy is the opposite of independence. If one part of a software
artifact (program, design document, etc.) constrains the content of
another, then they are not entirely independent, and it is possible to
check them for consistency.
 In communication, redundancy can be introduced into messages in
the form of error detecting and error-correcting codes to guard against
transmission errors.
The redundancy can be introduced or exploited with an automatic,
algorithmic check for consistency, it has the advantage of being much
cheaper and more thorough than dynamic testing or manual
inspection.
Checkable redundancy is not limited to program source code, nor is it
something that can be introduced only by programming language
designers.
For example, software design tools typically provide ways to check
consistency between different design views or artifacts.

When redundancy is already present - as between a software

specification document and source code - then the remaining
challenge is to make sure the information is represented in a way that
facilitates cheap, thorough consistency checks.
3.Restriction
When there are no acceptably cheap and effective ways to check a
property, sometimes one can change the problem by checking a
different, more restrictive property or by limiting the check to a smaller,
more restrictive class of programs.
Consider the problem of ensuring that each variable is initialized before it
is used, on every execution.

Figure 3.2: Can the variable k ever be uninitialized the first time i is added
to it? The property is undecidable, so Java enforces a simpler, stricter
property.
4. Partition
Partition, often also known as "divide and conquer," is a general
engineering principle. Dividing a complex problem into subproblems
to be attacked and solved independently is probably the most common
human problem-solving strategy.
 Software engineering in particular applies this principle in many
different forms and at almost all development levels, from early
requirements specifications to code and maintenance.
Partitioning can be applied both at process and technique levels. At
the process level, we divide complex activities into sets of simple
activities that can be attacked independently.
5. Visibility
Visibility means the ability to measure progress or status against
goals. In software engineering, one encounters the visibility principle
mainly in the form of process visibility, and then mainly in the form
of schedule visibility: ability to judge the state of development against
a project schedule.
 Quality process visibility also applies to measuring achieved (or
predicted) quality against quality goals. The principle of visibility
involves setting goals that can be assessed as well as devising
methods to assess their realization.
Visibility is closely related to observability, the ability to extract
useful information from a software artifact.
6. Feedback

Feedback is another classic engineering principle that applies to

analysis and testing. Feedback applies both to the process itself
(process improvement) and to individual techniques (e.g., using test
histories to prioritize regression testing).
Systematic inspection and walkthrough derive part of their success
from feedback. Participants in inspection are guided by checklists,
and checklists are revised and refined based on experience. New
checklist items may be derived from root cause analysis, analyzing
previously observed failures to identify the initial errors that lead to
them.
Thank You