Dept of Computer Science and Engineering

CML

Module 5
1. Software Testing Fundamentals
2. Test Case Design
3. White-Box Testing-Basis Path Testing-Control Structure Testing
4. Black-Box Testing
5. Various levels of Testing: Modules to System.
6. Structured Programming
7. Implementation Techniques
8. Programming principles and guidelines
9. Case study : Test case design and Testlog preparation

1. Software Testing Fundamentals

Testing is the process of exercising a program with the specific intent of finding errors prior to delivery to
the end user.
Testability- It refers to how easily a program can be tested.
1.1 Characteristics of Testable Software
The characteristics of testable software are:-
1. Operable
2. Observable
3. Controllable
4. Decomposable
5. Simple
6. Stable
7. Understandable
1. Operable
The better it works (i.e., better quality), the easier it is to test. Few bugs will block execution of tests allowing test to
progress without fits & starts.
2. Observable
Incorrect output is easily identified; internal errors are automatically detected.
3. Controllable
The states and variables of the software can be controlled directly by the tester
4. Decomposable
The software is built from independent modules that can be tested independently.
5. Simple
The program should exhibit functional, structural, and code simplicity
6. Stable
The fewer the changes, the fewer the disruptions to testing.
7. Understandable

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:1 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

The more information we have, the smarter we will test.

1.2 Test Characteristics
Before applying methods to design effective test cases, a software engineer must understand the basic
principles that guide software testing. These are the attributes of a good test:-
1. A good test has a high probability of finding an error
The tester must understand the software and how it might fail
2. A good test is not redundant
Testing time is limited; one test should not serve the same purpose as another test
3. A good test should be best of breed
In a group of tests, tests that have the highest likelihood of uncovering a whole class of
errors should be used
4. A good test should be neither too simple nor too complex
Each test should be executed separately; combining a series of tests could cause side effects
and mask certain errors
2. TEST CASE DESIGN ( INTERNAL & EXTERNAL VIEWS OF TESTING)
There are two ways of testing practices widely used:-
Black-box testing
Knowing the specified function that a product has been designed to perform, test to see if that
function is fully operational and error free
Includes tests that are conducted at the software interface
Not concerned with internal logical structure of the software
Black Box Testing is a software testing method in which the internal structure/ design/
implementation of the item being tested is NOT known to the tester
White-box testing
Knowing the internal workings of a product, test that all internal operations are performed
according to specifications and all internal components have been exercised.
Involves tests that concentrate on close examination of procedural detail
Logical paths through the software are tested
Test cases exercise specific sets of conditions and loops
White Box Testing is a software testing method in which the internal structure/ design/
implementation of the item being tested is known to the tester.

3. White Box Testing-Basis Path Testing-Control Structure Testing

1. White box testing uses the control structure part of component-level design to derive the test cases.
2. White-box testing, sometimes called glass-box testing, is a test case design method that uses the control
structure of the procedural design to derive test cases.
3. White box testing test cases:-
a. Guarantee that all independent paths within a module have been exercised at least once

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:2 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

b. Exercise all logical decisions on their true and false sides

c. Execute all loops at their boundaries and within their operational bounds
d. Exercise internal data structures to ensure their validity
3.1 Basis Path Testing
Basis Path Testing is a White-box testing technique proposed by Tom McCabe.
Enables the test case designer to derive a logical complexity measure of a procedural design.
Uses this measure as a guide for defining a basis set of execution paths.
Test cases derived to exercise the basis set are guaranteed to execute every statement in the program at
least one time during testing.
Basis Path Testing is discussed under these topics:-
1. Flow graph Notation
2. Independent Program Paths
3. Deriving Test Cases
4. Graph Matrics
1. Flow graph Notation
Flow graph( program Graph) is the representation of control flow of a program.
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
A predicate node 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
Areas bounded by a set of edges and nodes are called regions
When counting regions, include the area outside the graph as a region, too.
The flow graph depicts logical control flow using the notation illustrated in Figure 17.1.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:3 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

Flow graph of a flow chart is described in Figure 17.2 . To illustrate the use of a flow graph, we consider the
procedural design representation in Figure 17.2A. Here, a flowchart is used to depict program control structure.
Figure 17.2B maps the flowchart into a corresponding flow graph (assuming that no compound conditions are
contained in the decision diamonds of the flowchart). Referring to Figure 17.2B, each circle, called a flow graph
node, represents one or more procedural statements. A sequence of process boxes and a decision diamond can
map into a single node. The arrows on the flow graph, called edges or links, represent flow of control and are
analogous to flowchart arrows. An edge must terminate at a node, even if the node does not represent any procedural
statements (e.g., see the symbol for the if-then-else construct). Areas bounded by edges and nodes are
called regions. When counting regions, we include the area outside the graph as a region.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:4 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

Figure 17.2 Flow graph of a flow chart

2. Independent Program Paths
1. Defined as a path through the program from the start node until the end node that introduces at least one new set
of processing statements or a new condition (i.e., new nodes).
2. An independent path must move along at least one edge that has not been traversed before the path is defined.
3. Basis set for flow graph in Figure 17.2 (b) is
a. Path one: 0-1-11
b. Path two: 0-1-2-3-4-5-10-1-11
c. Path three: 0-1-2-3-6-8-9-10-1-11
d. Path four: 0-1-2-3-6-7-9-10-1-11
4. Basis Set Definition-
a. For basis set, if tests can be designed to force execution of these paths (a basis set), every statement in
the program will have been guaranteed to be executed at least one time and every condition will have
been executed on its true and false sides.
b. Paths 1, 2, 3, and 4 constitute a basis set for the flow graph.
c. The number of paths in the basis set is determined by the cyclomatic complexity.
5. Cyclomatic Complexity Definition-
Cyclomatic Complexity provides a quantitative measure of the logical complexity of a program
Defines the number of independent paths in the basis set
Provides an upper bound for the number of tests that must be conducted to ensure all statements have
been executed at least once
Can be computed three ways:-
The number of regions
V(G) = E N + 2, where E is the number of edges and N is the number of nodes in graph G
V(G) = P + 1, where P is the number of predicate nodes in the flow graph G

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:5 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

Results in the following equations for the example flow graph

Number of regions = 4
V(G) = 14 edges 12 nodes + 2 = 4
V(G) = 3 predicate nodes + 1 = 4
3. Deriving Test Cases
The following steps can be applied to derive the basis set:-
1) Using the design or code as a foundation, draw a corresponding flow graph
A flow graph is created using the symbols and construction rules . Referring to the PDL for average in
Figure 17.4, a flow graph is created by numbering those PDL statements that will be mapped into
corresponding flow graph nodes. The corresponding flow graph is in Figure 17.5.
2) Determine the cyclomatic complexity of the resultant flow graph
The cyclomatic complexity, V(G), is determined. It should be noted that V(G) can be determined
without developing a flow graph by counting all conditional statements in the PDL (for the procedure
average, compound conditions count as two) and adding 1.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:6 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

V(G) = 6 regions
V(G) = 17 edges -13 nodes + 2 = 6
V(G) = 5 predicate nodes + 1 = 6
3) Determine a basis set of linearly independent paths
The value of V(G) provides the number of linearly independent paths through the program control
structure. In the case of procedure average, we expect to specify six paths:
path 1: 1-2-10-11-13
path 2: 1-2-10-12-13
path 3: 1-2-3-10-11-13
path 4: 1-2-3-4-5-8-9-2-. . .
path 5: 1-2-3-4-5-6-8-9-2-. . .
path 6: 1-2-3-4-5-6-7-8-9-2-. . .
The ellipsis (. . .) following paths 4, 5, and 6 indicates that any path through the remainder of the control
structure is acceptable. It is often worthwhile to identify predicate nodes as an aid in the derivation of
test cases. In this case, nodes 2, 3, 5, 6, and 10 are predicate nodes.
4) Prepare test cases that will force execution of each path in the basis set
Data should be chosen so that conditions at the predicate nodes are appropriately set as each path is
tested.
4. Graph Matrics
Graph matrix

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:7 Prepared By: Merin
Mary Philip
Dept of Computer Science and Engineering
CML

A graph matrix is a square matrix whose size (i.e., number of rows and columns) is equal to the number
of nodes on the flow graph.
It is a data structure useful for developing a software tool that assists in basis path testing.
Each row and column corresponds to an identified node, and matrix entries correspond to connections
(an edge) between nodes.

Adding a link weight to each matrix entry, the graph matrix can become a powerful tool for evaluating
program control structure during testing.
Link weight is 1 (a connection exists) or 0 (a connection does not exist).
Link weights are assigned with following properties:
o The probability that a link (edge) will be executed.
o The processing time expended during traversal of a link.
o The memory required during traversal of a link.
o The resources required during traversal of a link.

The graph matrix in Figure 17.6 is redrawn as shown in Figure 17.7.

Each letter has been replaced with a 1, indicating that a connection exists (zeros have been excluded for
clarity).

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:8 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

Represented in this form, the graph matrix is called a connection matrix.

3.2 Control Structure Testing
It is a kind of white-box testing
Major control structure testing methods are:-
1. Condition Testing
2. Data Flow Testing
3. Loop Testing
1. Condition Testing
Condition testing is a test case design method that exercises the logical conditions contained in a
program module.
A simple condition is a Boolean variable or a relational expression, possibly preceded with one NOT
() operator.
A relational expression takes the form
E1 <relational-operator> E2
where E1 and E2 are arithmetic expressions and <relational-operator> is one of the following: <, , =,
(nonequality), >, or .
A compound condition is composed of two or more simple conditions, Boolean operators, and
parentheses.
We assume that Boolean operators allowed in a compound condition include OR (|), AND (&) and NOT
().
Boolean expression- A condition without relational expressions is referred to as a Boolean expression.
2. Data Flow Testing
The data flow testing method selects test paths of a program according to the locations of definitions
and uses of variables in the program.
Assume that each statement in a program is assigned a unique statement number and that each function
does not modify its parameters or global variables.
For a statement with S as its statement number,
DEF(S) = {X | statement S contains a definition of X}
USE(S) = {X | statement S contains a use of X}
If statement S is an if or loop statement, its DEF set is empty and its USE set is based on the
condition of statement S.
The definition of variable X at statement S is said to be live at statement S' if there exists a path from
statement S to statement S' that contains no other definition of X.
A definition-use (DU) chain of variable X is of the form [X, S, S'], where S and S' are statement
numbers, X is in DEF(S) and USE(S'), and the definition of X in statement S is live at statement S'.
3. Loop Testing
Loop testing is a white-box testing technique that focuses exclusively on the validity of loop constructs. Four
different classes of loops can be defined:
a. simple loops
b. nested loops
c. concatenated loops

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:9 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

d. unstructured loops
a. Simple loops

The following set of tests can be applied to simple loops, where n is the maximum number of allowable passes
through the loop.
1. Skip the loop entirely.
2. Only one pass through the loop.
3. Two passes through the loop.
4. m passes through the loop where m < n.
5. n 1, n, n + 1 passes through the loop.

b. Nested loops
The following set of tests can be applied to nested loops.

1. Start at the innermost loop. Set all other loops to minimum values.
2. Conduct simple loop tests for the innermost loop while holding the outer loops at their minimum
iteration parameter (e.g., loop counter) values. Add other tests for out-of-range or excluded values.
3. Work outward, conducting tests for the next loop, but keeping all other outer loops at minimum values
and other nested loops to "typical" values.
4. Continue until all loops have been tested.

c. Concantenated loops
Concatenated loops can be tested using the approach defined for simple loops, if each of the loops is independent
of the other. However, if two loops are concatenated and the loop counter for loop 1 is used as the initial value for
loop 2, then the loops are not independent. When the loops are not independent, the approach applied to nested
loops is recommended.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:10 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

d. Unstructured loops
Whenever possible, this class of loops should be redesigned to reflect the use of the structured
programmingconstructs.

4. Black-Box Testing
Black-box testing, also called behavioral testing, focuses on the functional requirements of the
software.Complements white-box testing by uncovering different classes of errors. Used during the later stages
of testing after white box testing has been performed. Black-box testing attempts to find errors in the following
categories:
(1) incorrect or missing functions
(2) interface errors
(3) errors in data structures or external data base access
(4) behavior or performance errors
(5) initialization and termination errors.
Questions answered by Black-box Testing are:-
How is functional validity tested?
How are system behavior and performance tested?
What classes of input will make good test cases?
Is the system particularly sensitive to certain input values?
How are the boundary values of a data class isolated?
What data rates and data volume can the system tolerate?
What effect will specific combinations of data have on system operation?

Black-box Testing is discussed under these topics:-

1. Graph-based testing methods
2. Equivalence Partitioning
3. Boundary Value Analysis
4. Orthogonal array testing

1. Graph-based testing methods

Software testing begins by creating a graph of important objects and their relationships and then devising a
series of tests that will cover the graph so that each object and relationship is exercised and errors are
uncovered. A collection of nodes that represent objects; links that represent the relationships between objects.
Node weights that describe the properties of a node (e.g., a specific data value or state behavior) . Link
weights that describe some characteristic of a link.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:11 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

Kinds of link:-
1. Directed link (represented by an arrow) indicates that a relationship moves in only one direction.
2. Bidirectional link, also called a symmetric link, implies that the relationship applies in both
directions.
3. Parallel links are used when a number of different relationships are established between graph
nodes.
As a simple example, consider a portion of a graph for a word-processing application
Object #1 = new file menu select
Object #2 = document window
Object #3 = document text
The software engineer then derives test cases by traversing the graph and covering each of the
relationships shown. These test cases are designed in an attempt to find errors in any of the
relationships.

Black box testing methods that can make use of graphs:

1. Transaction flow modeling
The nodes represent steps in some transaction and the links represent the logical connection between steps. Data
flow diagram can be used to assist in creating graphs of this type.
2. Finite state modeling
The nodes represent different user observable states of the software and the links represent the transitions that
occur to move from state to state .State transition diagram can be used to assist in creating graphs of this type.
3. Data flow modeling

The nodes are data objects and the links are the transformations that occur to translate one data object into
another.
4. Timing modeling

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:12 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

The nodes are program objects and the links are the sequential connections between those objects. Link weights
are used to specify the required execution times as the program executes.

2. Equivalence Partitioning

A black-box testing method that divides the input domain of a program into classes of data from which test
cases are derived.Test case design is based on an evaluation of equivalence classes for an input condition. An
equivalence class represents a set of valid or invalid states for input conditions. Guidelines for Defining
Equivalence Classes:-
If an input condition specifies a range, one valid and two invalid equivalence classes are defined
Input range: 1 10 Eq classes: {1..10}, {x < 1}, {x > 10}
If an input condition requires a specific value, one valid and two invalid equivalence classes are
defined
Input value: 250 Eq classes: {250}, {x < 250}, {x > 250}
If an input condition specifies a member of a set, one valid and one invalid equivalence class are
defined
Input set: {-2.5, 7.3, 8.4} Eq classes: {-2.5, 7.3, 8.4}, {any other x}
If an input condition is a Boolean value, one valid and one invalid class are define
Input: {true condition} Eq classes: {true condition}, {false condition}

3. Boundary Value Analysis

A greater number of errors occur at the boundaries of the input domain rather than in the "center". Boundary
value analysis is a test case design method that complements equivalence partitioning. It selects test cases at the
edges of a class. It derives test cases from both the input domain and output domain. Guidelines for Boundary
Value Analysis are:-
1. If an input condition specifies a range bounded by values a and b

test cases should be designed with (values a and b ), (values just above a and b) and (just below a and b).
2. If an input condition specifies a number of values,

test case should be developed that exercise (minimum and maximum numbers), (Values just above and just
below the minimum and maximum ).

3. Apply guidelines 1 and 2 to output conditions;

produce output that reflects the (minimum and the maximum values) expected and (test the values just below
and just above).

4. If internal program data structures have prescribed boundaries (e.g., an array)

design a test case to exercise the data structure at its (minimum and maximum boundaries).

4. Orthogonal Array Testing

Orthogonal array testing can be applied to problems in which the input domain is relatively small but too
large to accommodate exhaustive testing.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:13 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

Orthogonal array testing enables you to design test cases that provide maximum test coverage with a
reasonable number of test cases.
To illustrate the difference between orthogonal array testing and more conventional one input item at a
time approaches, consider a system that has three input items, X, Y, and Z. Each of these input items has
three discrete values associated with it. There are 33 = 27 possible test cases.
a geometric view of the possible test cases associated with X, Y, and Z illustrated in Figure 17.10.
Referring to the figure, one input item at a time may be varied in sequence along each input axis.
This results in relatively limited coverage of the input domain (represented by the left-hand cube in the
figure).

5. Various levels of Testing

Differents levels of testing are:-
1. Unit testing
2. Integration testing
3. Validation testing
4. System testing

1. Unit Testing

Unit testing focuses verification effort on the smallest unit of software designthe software component or
module.The unit test is white-box oriented, and the step can be conducted in parallel for multiple
components.
Unit testing is discussed under these topics:-
1.1 Unit Test Considerations
1.2 Unit Test Procedures
1.1 Unit Test Considerations

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:14 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

Module interface is tested to ensure that information properly flows into and out of the program unit under test.
Local data structure is examined to ensure that data stored temporarily maintains its integrity during all steps in
an algorithm's execution. Boundary conditions are tested to ensure that module operates properly at boundaries
established to limit or restrict processing. All independent paths (basis paths) through the control structure are
exercised to ensure that all statements in a module have been executed at least once. All error handling paths
are tested.

1.2 Unit Test procedures

A driver is a "main program" that accepts test case data, passes such data to the component (to be tested),
and prints relevant results. A stub or "dummy subprogram" uses the subordinate module's interface, may do
minimal data manipulation, prints verification of entry, and returns control to the module undergoing testing.
2. Integration testing

Many unit tested modules are combined into subsystems , which are then tested. Goal of integration testing is
to see if modules can be inegrated properly. Incremental integration strategies are:-
a. Top-down integration
b. Bottom-up integration
c. Sandwich integration
d. Regression testing
e. Smoke testing

a. Top-down Integration

Modules are integrated by moving downward through the control hierarchy, beginning with the main
module. Subordinate modules are incorporated in either a depth-first or breadth-first fashion.
Depth-First: All modules on a major control path are integrated
Breadth -First: All modules directly subordinate at each level are integrated
Advantages
This approach verifies major control or decision points early in the test process
Disadvantages

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:15 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

Stubs need to be created to substitute for modules that have not been built or tested yet; this
code is later discarded
Because stubs are used to replace lower level modules, no significant data flow can occur
until much later in the integration/testing process

b. Bottom-up integration

Integration and testing starts with the most atomic modules in the control hierarchy
Advantages
This approach verifies low-level data processing early in the testing process
Need for stubs is eliminated
Disadvantages
Driver modules need to be built to test the lower-level modules; this code is later discarded or expanded into
a full-featured version. Drivers inherently do not contain the complete algorithms that will eventually use the
services of the lower-level modules; consequently, testing may be incomplete or more testing may be needed
later when the upper level modules are available.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:16 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

c. Sandwich integration
Consists of a combination of both top-down and bottom-up integration.
Reaps the advantages of both types of integration while minimizing the need for drivers and stubs.
d. Regression testing
Each new addition or change to baselined software may cause problems with functions that previously
worked flawlessly.
Regression testing re-executes a small subset of tests that have already been conducted.
Regression test suite contains three different classes of test cases
i. A representative sample of tests that will exercise all software functions
ii. Additional tests that focus on software functions that are likely to be affected by the change
iii. Tests that focus on the actual software components that have been changed
e. Smoke testing

Smoke testing is an integration testing approach that is commonly used when shrinkwrapped software
products are being developed.Benefits of Smoke Testing
Integration risk is minimized
The quality of the end-product is improved
Error diagnosis and correction are simplified
Progress is easier to assess

5. Validation testing
Validation testing follows after integration testing
Designed to ensure that
All functional requirements are satisfied
All behavioral characteristics are achieved

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:17 Prepared By: Merin
Mary Philip
Dept of Computer Science and Engineering
CML

All performance requirements are attained

Documentation is correct
Usability and other requirements are met (e.g., transportability, compatibility, error recovery,
maintainability)
Kinds of acceptance test conducted to enable customer to Validate requirements are:-
Alpha Testing
Beta Testing

1. Alpha testing
Conducted at the developers site by end users.
Software is used in a natural setting with developers watching intently
Testing is conducted in a controlled environment
Errors and usage problems are recorded and corrected.
2. Beta testing
Conducted at one or more end-user sites
Developer is generally not present
It serves as a live application of the software in an environment that cannot be controlled by
the developer
The end-user records all problems that are encountered and reports these to the developers
at regular intervals
After beta testing is complete, software engineers make software modifications and prepare
for release of the software product to the entire customer base.

4.System Testing
During system testing entire software system is tested.
Kinds of System testing:-

1. Recovery testing
2. Security testing
3. Stress testing
4. Performance testing
5. Deployment Testing
1. Recovery testing
Forces the software to fail in a variety of ways and verifies that recovery is properly performed.
2. Security testing
Verifies that protection mechanisms built into a system and protect it from improper access.

3. Stress testing
It determines the robustness of software by testing beyond the limits of normal operation such as
Executing a system in a manner that demands resources in abnormal quantity, frequency, or volume.It
involves testing beyond normal operational capacity, often to a breaking point, in order to determine
breaking points or safe usage limits.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:18 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

4. Performance testing
Tests the run-time performance of software within the context of an integrated system.Often coupled with
stress testing and usually requires both hardware and software instrumentation.
5. Deployment Testing
It is also called configuration testing , exercises the software in each environment in which it is to be
operated.It examines all installation procedures and specialised installation software that will be used by
customers.
6. Structured programming
Structured Programming is a design technique that constrains logic flow to three constructs:
1. Sequence
2. condition
3. repetition
Sequence implements processing steps that are essential in the specification of any algorithm.
Condition provides the facility for selected processing based on some logical occurrence.
Repetition allows for looping.
Various notations depict the use of these constructs
1. Graphical design notation
Sequence, if-then-else, selection, repetition (see next slide)
2. Tabular design notation
3. Program design language
Similar to a programming language; however, it uses narrative text embedded
directly within the program statements
1. Graphical design notation
1. A box is used to indicate a processing step.
2. A diamond represents a logical condition, and arrows show the flow of control.
3. Sequence is represented as two processing boxes connected by an line (arrow) of control.
4. Condition, also called if then-else, is depicted as a decision diamond that if true, causes then-part
processing to occur, and if false, invokes else-part processing.
5. Repetition is represented using two slightly different forms.
6. The do while tests a condition and executes a loop task repetitively as long as the condition holds true.
7. A repeat until executes the loop task first, then tests a condition and repeats the task until the condition
fails.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:19 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

2. Tabular Design Notation

1) The upper left-hand quadrant contains a list of all conditions.
2) The lower left-hand quadrant contains a list of all actions that are possible based on combinations
of conditions.
3) The right-hand quadrants form a matrix that indicates condition combinations and the
corresponding actions that will occur for a specific combination.
4) Therefore, each column of the matrix may be interpreted as a processing rule.
5) The following steps are applied to develop a decision table:
1. List all actions that can be associated with a specific procedure (or module).
2. List all conditions (or decisions made) during execution of the procedure.
3. Associate specific sets of conditions with specific actions, eliminating impossible combinations of
conditions; alternatively, develop every possible permutation of conditions.
4. Define rules by indicating what action(s) occurs for a set of conditions.

3. Program design language

It is also called structured English.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:20 Prepared By: Merin
Mary Philip
Dept of Computer Science and Engineering
CML

It uses the vocabulary of one language (i.e., English) and the overall syntax of another (i.e., a
structured programming language).
The difference between PDL and a real programming language lies in the use of narrative text (e.g.,
English) embedded directly within PDL statements.
Given the use of narrative text embedded directly into a syntactical structure, PDL cannot be
compiled.
PDL tools currently exist to translate PDL into a programming language skeleton and/or a
graphical representation (e.g., a flowchart) of design. These tools also produce nesting maps, a
design operation index, cross-reference tables, and a variety of other information.
PDL Example
To illustrate the use of PDL, we present an example of a procedural design for the SafeHome
security system software.
The system monitors alarms for fire, smoke, burglar, water, and temperature (e.g., furnace breaks
while homeowner is away during winter) and produces an alarm bell and calls a monitoring
service , generating a voice-synthesized message. In the PDL that follows, we illustrate some of the
important constructs.
The following PDL defines an elaboration of the procedural design for the security monitor
component.
PROCEDURE security.monitor;
INTERFACE RETURNS system.status;
TYPE signal IS STRUCTURE DEFINED
name IS STRING LENGTH VAR;
address IS HEX device location;
bound.value IS upper bound SCALAR;
message IS STRING LENGTH VAR;
END signal TYPE;
TYPE system.status IS BIT (4);
TYPE alarm.type DEFINED
smoke.alarm IS INSTANCE OF signal;
fire.alarm IS INSTANCE OF signal;
water.alarm IS INSTANCE OF signal;
temp.alarm IS INSTANCE OF signal;
burglar.alarm IS INSTANCE OF signal;
TYPE phone.number IS area code + 7-digit number;
initialize all system ports and reset all hardware;

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:21 Prepared By: Merin
Mary Philip
 Dept of Computer Science and Engineering
CML

CASE OF control.panel.switches (cps):

WHEN cps = "test" SELECT
CALL alarm PROCEDURE WITH "on" for test.time in seconds;
WHEN cps = "alarm-off" SELECT
CALL alarm PROCEDURE WITH "off";
WHEN cps = "new.bound.temp" SELECT
CALL keypad.input PROCEDURE;
WHEN cps = "burglar.alarm.off" SELECT deactivate signal [burglar.alarm];
DEFAULT none;
ENDCASE
REPEAT UNTIL activate.switch is turned off
reset all signal.values and switches;
DO FOR alarm.type = smoke, fire, water, temp, burglar;
READ address [alarm.type] signal.value;
IF signal.value > bound [alarm.type]
THEN phone.message = message [alarm.type];
set alarm.bell to "on" for alarm.timeseconds;
PARBEGIN
CALL alarm PROCEDURE WITH "on", alarm.time in seconds;
CALL phone PROCEDURE WITH message [alarm.type], phone.number;
ENDPAR
ELSE skip
ENDIF
ENDFOR
ENDREP
END security.monitor
Note that the designer for the security.monitor component has used a new construct
PARBEGIN . . . ENDPAR that specifies a parallel block. All tasks specified within
the PARBEGIN block are executed in parallel. In this case, implementation details are
not considered.
8.Programming principles and guidelines
Before applying methods to design effective test cases, a software engineer must understand the basic
principles that guide software testing. Following are the testing principles:-

1. All tests should be traceable to customer requirements

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:22 Prepared By: Merin
Mary Philip
Dept of Computer Science and Engineering
CML

As we have seen, the objective of software testing is to uncover errors. It follows that the most severe
defects (from the customers point of view) are those that cause the program to fail to meet its
requirements.

2. Tests should be planned long before testing begins

Test planning can begin as soon as the requirements model is complete. Detailed definition of test cases
can begin as soon as the design model has been solidified. Therefore, all tests can be planned and
designed before any code has been generated.

3. The Pareto principle applies to software testing

Stated simply, the Pareto principle implies that 80 percent of all errors uncovered during testing
will likely be traceable to 20 percent of all program components. The problem, of course, is to isolate
these suspect components and to thoroughly test them.
4. Testing should begin in the small and progress toward testing in the large.
The first tests planned and executed generally focus on individual components. As testing progresses,
focus shifts in an attempt to find errors in integrated clusters of components and ultimately in the entire
system.

5. Exhaustive testing is not possible

The number of path permutations for even a moderately sized program is exceptionally large. For this
reason, it is impossible to execute every combination of paths during testing. It is possible, however, to
adequately cover program logic and to ensure that all conditions in the component-level design have
been exercised.

6. To be most effective, testing should be conducted by an independent third party

By most effective, we mean testing that has the highest probability of finding errors (the primary
objective of testing). Testing should be conducted by an independent third party then it will be more
effective.
(Note:-Implementation Techniques and Case study: Test case design and Testlog preparation
notes will be send later)

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:23 Prepared By: Merin
Mary Philip