➢

➢
➢
➢
➢
➢
➢
6.
➢
➢
➢
➢
7.
➢

8.
➢

➢
➢

9.
 Functional Testing Non-functional
Testing
It verifies the operations and It verifies the behavior of an
actions of an application. application.
It is based on requirements of It is based on expectations
customer. of customer.
It helps to enhance the behavior It helps to improve the
of the application. performance of the
application.
It is hard to execute non-functional
testing Functional testing is easy to execute manually. manually.
It tests what the product does. It describes how the product does.

10.
➢

➢
➢

➢
➢
11.
 Testing Debugging

Testing is the process to find Debugging is the process of

bugs and errors. correcting the bugs found during
testing.
It is the process to identify the It is the process to give
failure of implemented code. absolution to code failure.

Testing is the display of errors. Debugging is a deductive

process.
Testing is done by the tester. Debugging is done by either
programmer or the developer.

There is no need of design

Debugging can’t be done without
knowledge in the testing
proper design knowledge.
process.
Testing can be done by insiders Debugging is done only by
as well as outsiders. insiders. An outsider can’t do
debugging.
Testing can be manual or Debugging is always manual.
automated. Debugging can’t be automated.
It is based on different testing Debugging is based on different
levels i.e. types of bugs.
unit testing, integration testing,
system testing, etc.
Testing is a stage of the Debugging is not an aspect of
software development life cycle the software development life
(SDLC). cycle, it occurs as a
consequence of testing.
Testing is composed of the While debugging process seeks
validation and verification of to match symptoms with cause,
software. by that it leads to error
correction.
Testing is initiated after the Debugging commences with the
code is written. execution of a test case.

Testing process based on Debugging process based on

various various

Testing Debugging

levels of testing-system types of bugs is present in a

testing, system.
integration testing, unit
testing, etc.
➢
➢
➢

➢
➢
➢
➢
➢

➢
•

•
•

o
➢

➢
➢
➢
➢

•
Dynamic data Static Data

1. They are transitory 1. they are fixed in

form and content
2. Their lifetime is relatively 2. They appear in
the Source code or Short, typically the
database directly or indirectly. processing time of one transaction.
3. This can be handled in one of 3 ways 3. Compile time
processing will solve the
(i)Clean up after the use by the user bugs
caused by static data (ii)Common Cleanup by the
resource Manager.
(iii)No clean up
UNIT- II
1. PATH TESTING
a. Path testing is used for program’s control flow as a structural
model is the cornerstone of testing.
b. It defines the program’s control flow, criteria for selecting
paths, and how to determine path–forcing input values.
c. Path testing is the name given to a family of test techniques
based on judiciously selecting a set of test paths through the
program.
d. The set of path will be tested through conducting path testing.
e. Path–testing techniques are the oldest of all structural test
techniques
f. It is the technique which comes under the theoretical
examination.
g. Path testing was independently discovered and used many
times in many different places.
h. It is a structural technique.
i. Path testing is rarely, if ever, used for system testing.

2. THE BUG ASSUMPTION

a. Structured programming languages prevent many of the bugs
targeted by path testing.
b. The effectiveness of path testing for these languages is reduced.
c. Conversely, old code, especially in assembly languages, COBOL,
FORTRAN, and Basic, has a higher proportion of control–flow bugs
than contemporary code, and for such software path testing is
indispensable (Unimportant).

3. CONTROL FLOW GRAPH

a. The control flow graph (or flow graph) is a graphical
representation of a program’s control structure
b. It uses the elements process blocks, decisions, and junctions.

4. PROCESS BLOCK
a. A process block* is a sequence of program statements
uninterrupted by either decisions or junctions.
 b. Formally, it is a sequence of statements such that if any one
statement of the block is executed, then all statements thereof
are executed.
c. A process block can be one source statement or hundreds
d. Once a process block is initiated, every statement within it will be
executed.
e. The term “process” will be used interchangeably with “process
block.”
f. A process has one entry and one exit.
g. It can consist of a single statement or instruction, a sequence of
statements or instructions, a single–entry/single–exit subroutine,
a macro or function call, or a sequence of these.
h. If the processing does affect the flow of control, the effect will
make clear at a subsequent decision or case statement.

5. DECISION AND CASE STATEMENT

a. A decision is a program point at which the control flow can
diverge.
b. Machine language conditional branch and conditional skip
instructions are examples of decisions.
c. While most decisions are two–way or binary, some (such as the
FORTRAN IF) are three–way branches in control flow.
d. The design of test cases is generally easier with two–way
branches than with three–way branches, and there are also more
powerful test–design tools that can be used.
e. A case statement is a multiway branch or decision.

6. JUNCTIONS
a. A junction is a point in the program where the control flow can
merge.
b. Examples of junctions are: the target of a jump or skip instruction
in assembly language, a label that is the target of a GOTO, the
END–IF and CONTINUE statements in FORTRAN, and the Pascal
statement labels, END and UNTIL.
 c. Unconditional branches such as FORTRAN’s GOTO or
unconditional jump instructions are not fundamental to
programming.

7. CONTROL FLOW VERSES FLOW CHART

a. A program’s flowchart is similar to control flow graph, but
differs in one important way.
b. In control flow graphs, we don’t show the details of what is in a
process block
c. If the process block contains more statement it will be
considered as a single block.
d. In flowcharts, conversely, every part of the process block is
drawn: if a process block consists of 100 steps, the flowchart
may have 100 boxes.
e. There are no fixed rules about how this should be done in flow
charting.
 f. The flowchart focuses on process steps, whereas the control
flow graph all but ignores them.
g. The flowchart forces an expansion of visual complexity by
adding many off–page connectors, which confuse the control
flow, but the flow graph compacts the representation and
makes it easier to follow.
h. Flowcharts are rarely used today.
i. There may also be specification control–flow graphs prior to
design.
j. The act of drawing a control flow graph (and also data flow
graph) is a useful tool that can help us clarify the control flow
and data flow issues.

8. NOTATIONAL EVALUATION
a. The control flow graph is a simplified (i.e., more abstract)
representation of the program’s structure.
b. This evaluation will be written by using the languages like
program design language (PDL).
c. Here the process steps replaced with the single process block.
d. That will be again simplified.
e. For doing this we need to make some notational changes.\
f. The process boxes weren’t really needed. There is an implied
process on every line joining junctions and decisions, especially
if we allow do–nothing or dummy processes.
g. We don’t need to know (at this time) the specifics of the
decisions, just the fact that there is a branch—so we can do
away with things such as “U > V?”, “yes”, “no”, and so on.
h. The specific target label names aren’t important—just the fact
that they exist. So we can replace them by simple numbers.
i. We usually represent the program’s control flow graph by using
two components: circle and arrow that join circle.
j. A circle with more than one arrow leaving it is a decision.
k. A circle with more than one arrow entering is a junction.
l. We call the circles nodes and the arrows links.
m. The entry and exit are also denoted by circles and are
thereby also considered to be nodes.
n. Nodes are usually numbered or labeled by using the original
program labels.
o. Each and every link will be having link name.

Simplified Flowgraph Notation

 Even Simplified Flowgraph Notation

9. FLOW GRAPH PROGRAM CORRESPONDANCE

a. A flow graph is a pictorial representation of a program.
b. Here one of the distinction is failure to make it can lead to
bugs.
c. You can’t always associate the parts of a program in a unique
way with flowgraph parts because many program structures,
such as IF–THEN–ELSE constructs, consist of a combination of
decisions, junctions, and processes.
d. Furthermore, the translation from a flow graph element to a
statement and vice versa is not always unique.
e. A FORTRAN DO has three parts: a decision, an end–point
junction, and a process that iterates the DO variable.
f. The FORTRAN IF–THEN–ELSE has a decision, a junction, and
three processes.

Alternative Flowgraphs for same logic (Statement "IF (A=0) AND

(B=1) THEN . . ").

10. FLOW GRAPH AND FLOW CHART GENERATION

a. The control flow graph is a simplified version of the earlier
flowchart.
 b. Although there are many commercially available flowcharting
packages, there are relatively few control flow graph
generators as of the time of writing.
c. Flowcharts can be (1) hand–drawn by the programmer, (2)
automatically produced by a flowcharting program based on a
mechanical analysis of the source code, or (3) semi
automatically produced by a flowcharting program based in
part on structural analysis of the source code and in part on
directions given by the programmer.
d. The semiautomatic flowchart is most common with assembly
language source code.
e. A flowcharting package that provides controls over how
statements are mapped into process boxes can be used to
produce a flowchart that is reasonably close to the control flow
graph.
f. If you have automatically produced flowcharts, then it is
effective to check the correspondence between the
specification control–flowgraph and the flowchart produced
from code.
g. Do it as part of an inspection or review. Many bugs can be
caught this way. It may seem like a lot of extra work, but
consider which you would rather do:
h. A calm, manual retranslation of the code back into a flow
graph with an unbiased comparison, or
i. “Look this over for me, will you? I just can’t find the bug.”

11. PATH TESTING

a. A path through a program is a sequence of instructions or
statements that starts at an entry, junction, or decision and
ends at another, or possibly the same, junction, decision, or
exit.
b. A path may go through several junctions, processes, or
decisions, one or more times. Paths consist of segments.
c. The smallest segment is a link—that is, a single process that
lies between two nodes (e.g., junction–process–junction,
 junction–process–decision, decision–process–junction, decision–
process–decision).
d. A direct connection between two nodes, as in an unconditional
GOTO, is also called a “process” by convention, even though no
actual processing takes place.
e. A path segment is a succession of consecutive links that
belongs to some path.
f. The length of a path is measured by the number of links in it
and not by the number of instructions or statements executed
along the path.
g. An alternative way to measure the length of a path is by the
number of nodes traversed—this method has some analytical
and theoretical benefits.
h. Each and every path should have its own name.
i. A path has a loop in it if any node (link) name is repeated.

12. MULTI ENTRY AND MULTI EXIT ROUTINES

a. If the routine performs several variations on the same
processing and it is effective to bypass part of the processing,
the correct way to design the routine is to provide an entry
parameter that within the routine (say, by a case statement),
directs the control flow to the proper point.
b. Similarly, if a routine can have several different kinds of
outcomes, then an exit parameter should be used.
c. Another alternative is to encapsulate the common parts into
subroutines.
d. Instead of using direct linkages between multiple exits and
entrances, we handle the control flow by examining the values
of the exit parameter that can serve as an entry parameter for
the next routine or a return parameter for the calling routine.
e. But the parameter does not have to be passed explicitly
between the routines—it can be a value in a register or in a
common memory location.
f. The trouble with multi–entry and multi–exit routines is that it
can be very difficult to determine what the inter process control
 flow is, and consequently it is easy to miss important test
cases.
g. Furthermore, the use of multi–entry and multi–exit routines
increases the number of entries and exits and therefore the
number of interfaces.

13. FUNDAMENTAL PATH SELECTION CRITERIA

a. There are many paths between the entry and exit of a typical
routine
b. Every decision doubles the number of potential paths, and
every loop multiplies the number of potential paths by the
number of different iteration values possible for the loop.
c. If a routine has one loop, each pass through that loop (once,
twice, three times, and so on) constitutes a different path
through the routine, even though the same code is traversed
each time
d. These are all the criteria for selecting the path,
e. Even small routines can have an incredible number of potential
paths
f. Exercise every path from entry to exit.
g. Exercise every statement or instruction at least once.
h. Exercise every branch and case statement, in each direction,
at least once.

14. PATH TESTING CRITERIA

a. Any testing strategy based on paths must at least both
exercise every instruction and take branches in all directions.
b. A set of tests that does this is not complete in an absolute
sense, but it is complete in the sense that anything less must
leave something untested.
c. We have, therefore, explored three different testing criteria
or strategies out of a potentially infinite family of strategies.
They are:
 d. Path Testing (P∞)—Execute all possible control flow paths
through the program: typically, this is restricted to all possible
entry/exit paths through the program. If we achieve this
prescription, we are said to have achieved 100% path
coverage.* This is the strongest criterion in the path–testing
strategy family: it is generally impossible to achieve
e. Statement Testing (P1)—Execute all statements in the program
at least once under some test. If we do enough tests to achieve
this, we are said to have achieved 100% statement
coverage.* An alternate, equivalent characterization is to say
that we have achieved 100% node coverage (of the nodes in
the program’s control flow graph). Testing less than this for
new software is unconscionable and should be criminalized.
f. Branch Testing (P2)—Execute enough tests to assure that every
branch alternative has been exercised at least once under
some test. If we do enough tests to achieve this prescription,
then we have achieved 100% branch coverage (see page 74
footnote). An alternative characterization is to say that we have
achieved 100% link coverage (of the links in the control flow
graph of the program).

15. COMMON SENSE AND STRATERGIES

a. Not testing a piece of code leaves a residue of bugs in the
program in proportion to the size of the untested code and the
probability of bugs.
b. The high–probability paths are always thoroughly tested if only
to demonstrate that the system works properly. If you have to
leave some code untested at the unit level, it is more rational
to leave the normal, high–probability paths untested, because
someone else is sure to exercise them during integration
testing or system testing.
c. Logic errors and fuzzy thinking are inversely proportional to the
probability of the path’s execution.
d. The subjective probability of executing a path as seen by the
routine’s designer and its objective execution probability are
far apart. Only analysis can reveal the probability of a path,
 and most programmers’ intuition with regard to path
probabilities is miserable .
e. The subjective evaluation of the importance of a code segment
as judged by its programmer is biased by aesthetic sense, ego,
and familiarity.

16. PATH SELECTION RULES

a. Pick the simplest, functionally sensible entry/exit path.
b. Pick additional paths as small variations from previous paths.
Pick paths that do not have loops rather than paths that do.
Favor short paths over long paths, simple paths over
complicated paths, and paths that make sense over paths that
don’t.
c. Pick additional paths that have no obvious functional meaning
only if it’s necessary to provide coverage.
d. Be comfortable with your chosen paths.
e. Don’t follow rules slavishly—except for coverage.

17. Path Selection Example:

An example flowgraph to explain path selection

Practical Suggestions in Path Testing:

1. Draw the control flow graph on a single sheet of paper.

2. Make several copies - as many as you will need for coverage
(C1+C2) and several more.
3. Use a yellow highlighting marker to trace paths. Copy the paths onto
a master sheets.
4. Continue tracing paths until all lines on the master sheet are
covered, indicating that you appear to have achieved C1+C2.
5. As you trace the paths, create a table that shows the paths, the
coverage status of each process, and each decision.
6. The above paths lead to the following table considering the above
figure.

18. LOOPS
a. There are only three kinds of loops: nested loop, concatenated
loop and horrible loop.

19. CASES FOR SINGLE LOOP

a. A single loop can be covered with two cases: looping and not
looping.

20. Case 1—Single Loop, Zero Minimum, N Maximum, No Excluded

Values
a. Try bypassing the loop (zero iteration). If you can’t, you either
have a bug, or zero is not the minimum and you have the
wrong case.
b. Could the loop–control variable be negative?
c. One pass through the loop.
d. Two passes through the loop for reasons discussed below.
e. A typical number of iterations, unless covered by a previous
test.
f. One less than the maximum number of iterations.
g. The maximum number of iterations.
h. Attempt one more than the maximum number of iterations.
21. Case 2—Single Loop, Nonzero Minimum, No Excluded Values
a. Try one less than the expected minimum.
b. The minimum number of iterations.
c. One more than the minimum number of iterations.
d. Once, unless covered by a previous test.
e. Twice, unless covered by a previous test.
f. One less than the maximum value.
g. The maximum number of iterations.
h. Attempt one more than the maximum number of iterations.

22. Case 3—Single Loops with Excluded Values

a. Treat single loops with excluded values as two sets of tests
consisting of loops without excluded values, such as Cases 1
and 2 above.
b. The total range of the loop–control variable was 1 to 20, but
that values 7, 8, 9, and 10 were excluded.
c. The two sets of tests are 1–6 and 11–20. The test cases to
attempt would be 0,1,2,4,6,7, for the first range and
10,11,15,19,20,21, for the second range.

23. NESTED LOOPS

a. Start at the innermost loop. Set all the outer loops to their
minimum values.
b. Test the minimum, minimum + 1, typical, maximum – 1, and
maximum for the innermost loop, while holding the outer loops
at their minimum–iteration–parameter values. Expand the tests
as required for out–of–range and excluded values.
c. If you’ve done the outermost loop, GOTO step 5, ELSE move
out one loop and set it up as in step 2—with all other loops set
to typical values.
d. Continue outward in this manner until all loops have been
covered.
e. Do the five cases for all loops in the nest simultaneously.

24. CONCATENEATED LOOPS

a. Concatenated loops fall between single and nested loops
with respect to test cases.
b. Two loops are concatenated if it’s possible to reach one after
exiting the other while still on a path from entrance to exit.
c. If the loops cannot be on the same path, then they are not
concatenated and can be treated as individual loops.
d. Even if the loops are on the same path and you can be sure
that they are independent of each other, you ca

n still
treat them as individual loops.
 e. But if the iteration values in one loop are directly or indirectly
related to the iteration values of another loop, and they can
occur on the same path, then treat them as you would nested
loops.

Example of Loop types

25. HORRIBLE LOOPS

a. The use of code that jumps into and out of loops, intersecting
loops, hidden loops, and cross–connected loops, makes
iteration–value selection for test cases an awesome and ugly
task, which is another reason such structures should be
avoided.
b. It’s also difficult at times to see how deeply nested the loops
are, or indeed whether there are any nested loops.

26. LOOP TESTING TIME

a. Show that the combined execution time results from an
unreasonable or incorrect specification. Fix the specification.
b. Prove that although the combined extreme cases are
hypothetically possible.
c. Put in limits or checks that prevent the combined extreme
cases. Then you have to test the software that implements
such safety measures
d. Test with the extreme–value combinations, but use different
numbers.

27. Proper way to test multi–entry or multi–exit routines is:

a. Get rid of them.
b. Completely control those you can’t get rid of.
c. Augment the flow graph with fictitious, equivalent, input case
statements and exit parameters to help you organize the tests
for those that remain and accept the weakness of the
approach.
d. Do stronger unit testing by treating each entry/exit
combination as if it were a completely different routine.
 e. Recognize that you are dealing with a much more complicated
beast than you thought, and pay for it in much heavier
integration testing.
f. Be sure you understand the strategies and assumptions built
into your automatic test generators and confirm that they do
(don’t) necessarily work for multi–entry/multi–exit routines.
28. Effectiveness of Path Testing
a. Planning to cover does not mean you will cover. Path testing
may not cover if you have bugs.
b. Path testing may not reveal totally wrong or missing functions.
c. Interface errors, particularly at the interface with other
routines, may not be caught by unit–level path testing.
d. Database and data–flow errors may not be caught.
e. The routine can pass all of its tests at the unit level, but the
possibility that it interferes with or perturbs other routines
cannot be determined by unit–level path tests.
f. Not all initialization errors are caught by path testing.
g. Specification errors can’t be caught.

29. PREDICATE, PATH PREDICATE AND ACHIVABLE PATH

a. Selecting a path does not mean that it is achievable.
b. If all decisions are based on variables whose values are
independent of the processing and of one another, then all
combinations of decision outcomes are possible and all paths
are achievable.
c. Every selected path leads to an associated Boolean expression,
called the path predicate expression, which characterizes
the input values (if any) that will cause that path to be
traversed.
d. For binary decisions, decision processing ultimately results in
the evaluation of a logical (i.e., boolean) function whose
outcome is either TRUE or FALSE.
e. Although the function evaluated at the decision can be numeric
or alphanumeric, when the decision is made it is based on a
logical function’s truth value.
 f. The logical function evaluated at a decision is called a
predicate.
g. a sequence of predicates whose truth values will cause the
routine to take a specific path. A predicate associated with a
path is called a path predicate.
30. INPUTS
a. variables in a subroutine call, but includes all data objects
referenced by the routine whose values are fixed prior to
entering it
b. Inputs may be numerical, set members, boolean, integers,
strings, or virtually any combination of object types, we can
talk about data as if they are numbers.
c. We can treat the set of inputs to the routine as if it is a one–
dimensional array, which we call the input vector.

31. INDEPENDENCE AND CORRELATION OF VARIABLES AND

PREDICATES.
a. The path predicates take on truth values (TRUE/FALSE) based
on the values of input variables, either directly (interpretation
is not required) or indirectly (interpretation is required).
b. If a variable’s value does not change as a result of processing,
that variable is independent of the processing.
c. Conversely, if the variable’s value can change as a result of the
processing the variable is process dependent.
d. Similarly, a predicate whose truth value can change as a result
of the processing is said to be process dependent and one
whose truth value does not change as a result of the
processing is process independent.
e. Variables, whether process dependent or independent, may be
correlated to one another.
f. Two variables are correlated if every combination of their
values cannot be independently specified.
g. Variables whose values can be specified independently without
restriction are uncorrelated.
32. PATH PREDICATE EXPRESSION
a. The result of this mental exercise is a set of boolean
expressions, all of which must be satisfied to achieve the
selected path. This set is called the path predicate
expression.
b. Assuming (for the sake of our example) that the input variables
are numerical, the expression is equivalent to a,

X1 + 3X2 + 17 >= 0
X3 = 17
X4 – X1 >= 14X2

33. TESTING BLINDNESS

a. Testing blindness is a pathological situation in which the
desired path is achieved for the wrong reason.
b. It can occur because of the interaction of two or more
statements that makes the buggy predicate “work” despite its
bug and because of an unfortunate selection of input values
that does not reveal the situation.
c. There are three kinds of predicate blindness: assignment
blindness, equality blindness, and self–blindness.
d. Assignment blindness occurs when the buggy predicate
appears to work correctly because the specific value chosen for
an assignment statement works with both the correct and
incorrect predicate
e. Equality blindness occurs when the path selected by a prior
predicate results in a value that works both for the correct and
buggy predicate.
f. Self–blindness occurs when the buggy predicate is a multiple
of the correct predicate and as a result is indistinguishable
along that path.

34. PATH SENSITIZING

a. We want to select and test enough paths to achieve a
satisfactory notion of test completeness
 b. Extract the program’s control flowgraph and select a set of
tentative covering paths.
c. For any path in that set, interpret the predicates along the
path as needed to express them in terms of the input vector. In
general, individual predicates are compound or may become
compound as a result of interpretation.
d. Trace the path through, multiplying (boolean) the individual
compound predicates to achieve a boolean expression.

35. HEURISTIC PROCEDURES FOR SENSITIZING PATHS

a. Identify all variables that affect the decisions.
b. Classify the predicates as dependent or independent
c. Start path selection with uncorrelated, independent predicates.
d. The predicates are correlated and/or dependent in such a way
as to nullify the dependency.
e. The predicates are incorrectly classified. Check your work.
f. Your path tracing is faulty. Look for a missing path or
incomplete coverage.
g. There is a bug.
h. coverage hasn’t been achieved using independent uncorrelated
predicates, extend the path set by using correlated predicates;
preferably those whose resolution is independent of the
processing
i. Last, use correlated, dependent predicates.
j. For each path selected above, list the input variables
corresponding to the predicates required to force the path.

36. PATH INSTRUMENTATION AND LINK MARKER.

a. We can only say that some of the necessary conditions for
passing are satisfied, but the conditions are not sufficient
because the desired outcome could have been achieved for the
wrong reason. This situation is called coincidental
correctness.
 b. Simple and effective form of instrumentation (RAMA75B) is
called a traversal marker or link marker.
c. Name every link by a lowercase letter. Instrument the links so
that the link’s name is recorded when the link is executed.

37. PROCEDURES FOR LINK COUNTER

a. Do the begin–link counter values equal the end–link counter
values for all links?
b. Do the input–link count of every decision equal the sum of the
link counts of the output links from that decision?
c. Do the sum of the input–link counts for a junction equal the
output–link count for that junction?
d. Do the counts match the values you predicted when you
designed the test?

TRANSACTION FLOW TESTING

DEFINTION
a. A transaction is a unit of work seen from a system user’s point
of view.
b. Transaction consists of a sequence of operations, some of which
are performed by a system, persons, or devices that are outside
of the system.
c. Transactions begin with birth—that is, they are created as a
result of some external act.
 d. . At the conclusion of the transaction’s processing, the transaction
is no longer in the system, except perhaps in the form of historical
records
e. A transaction for an online information retrieval system might
consist of the following steps or tasks:
f. Accept input (tentative birth), Validate input (birth), Transmit
acknowledgment to requester, Do input processing, Search file,
Request directions from user, Accept input, Validate input.
Process request, Update file, Transmit output, Record transaction
in log and cleanup.
Example of a transaction: A transaction for an online information
retrieval system might consist of the following steps or tasks:

 Accept input (tentative birth)

 Validate input (birth)
 Transmit acknowledgement to requester
 Do input processing
 Search file
 Request directions from user
 Accept input
 Validate input
 Process request
 Update file
 Transmit output
 Record transaction in log and clean up (death)

USAGE.
a. Transaction flows are indispensable for specifying requirements of
complicated systems, especially online systems.
b. A big system such as an air traffic control or airline reservation
system has not hundreds, but thousands of different transaction
flows.
c. The flows are represented by relatively simple flow graphs, many
of which have a single straight-through path.
d. Loops are infrequent compared to control flow graphs.
e. The most common loop is used to request a retry after user input
errors.
IMPLEMENTATION
a. The implementation of a transaction flow is usually implicit in the
design of the system’s control structure and associated data
base.
b. That is, there is no direct, one-to-one correspondence between
the “processes” and “decisions” of the transaction flows and
corresponding program component.
c. A transaction flow is a representation of a path taken by a
transaction through a succession of processing modules.
d. Each transaction as represented by a token—such as a
transaction-control block that is passed from routine to routine as
it progresses through its flow.
e. Transaction flow graph is a pictorial representation of what
happens to the tokens.
f. it is not the control structure of the program that manipulates
those tokens.
g. The system is controlled by an
executive/scheduler/dispatcher/operating system—call it what
you will.

TRANSACTION FLOW GRAPHS:

 Transaction flows are introduced as a representation of a system's

processing.
 The methods that were applied to control flow graphs are then used
for functional testing.
 Transaction flows and transaction flow testing are to the
independent system tester what control flows are path testing are to
the programmer.
 The transaction flow graph is to create a behavioral model of the
program that leads to functional testing.
 The transaction flowgraph is a model of the structure of the system's
behavior (functionality).
 An example of a Transaction Flow is as follows:
PERSPECTIVE.
a. The computer transaction can be single instruction multiple data
(SIMD) or multi instruction Multiple data (MIMD).
b. We didn’t restrict the communication methods between
processing components:.
c. We didn’t restrict the communication methods between
processing components.
d. It could be via data structures, over communication lines,
processing queues, or direct transfers in a call.
e. Transaction-flow testing is the ultimate black-box technique
because all we ask is that there is something identifiable as a
transaction and that the system will do predictable things to
transactions.
f. Transaction flow graphs are a kind of data flow graph.
g. It explains the history of operations applied to the data objects.

PERCEPTIONS
a. Biosis- The incoming transaction (the parent) gives birth to a new
transaction (the daughter), whence both transactions continue on
their separate paths, the parent retaining its identity as a
transaction. I call this situation biosis.
 b. Mitosis- It is similar as biosis except that the parent transaction is
destroyed and two new transactions (daughters) are created. I
call this situation mitosis because of its similarity to biological
mitotic division.
c. Absorption- The junction in a control flow-graph. It is understood
that a transaction can arrive either on one link (path 1) or the
other (path 2). (absorption) a predator transaction absorbs a
prey.
d. Conjunction- A slightly different situation in which two parent
transactions merge to form a new daughter. In keeping with the
biological flavor of this section, I call this act conjugation.

TRANSACTION FLOW STRUCTURE

a. It’s a model of a process, not just code. Humans may be involved
in loops, decisions, and so on. We can’t bind human behavior to
software structure rules, no matter how fervently we might wish
it.
b. Parts of the flows may incorporate the behavior of other systems
over which we have no control.
c. Small part of the totality of transaction flows exists to model error
conditions, failures, malfunctions, and subsequent recovery
actions.
d. The number of transactions and the complexity of individual
transaction flows grow over time as features are added and
enhanced. Often, the world imposes the structure of the flows on
us.
e. Systems are built out of modules and the transaction flows result
from the interaction of those modules. Good system design
dictates that we avoid changing modules in order to implement
new transactions or to modify existing transactions.
 f. Our models are just that—approximations to reality. Interrupts,
priorities, multitasking, mult icomputers, synchronization, parallel
processing, queue disciplines, polling—all of these make
mincemeat out of structuring concepts that apply to units.

TRANSACTION BASED SYSTEM.

a. Transaction Control Block—There’s an explicit transaction control
block associated with every live transaction. The block contains,
among other things, the transaction’s type, identity, and
processing state. Whether the block itself contains the
information or just pointers to the information is immaterial.
b. Centralized, Common, Processing Queues—Transactions (actually,
transaction control blocks) are not passed directly from one
process to another but are transferred from process to process by
means of centralized explicit processing queues.
c. Transaction Dispatcher—There is a centralized transaction
dispatcher. Based on the transaction’s current state and
transaction type, the next process is determined from stored
dispatch tables or a similar mechanism.
d. Recovery and Other Logs—Key points in the transaction’s life are
recorded for several different purposes—the two most important
being transaction recovery support and transaction accounting.
e. Self-Test Support—The transaction control tables have privileged
modes that can be used for test and diagnostic purposes. There
are special transaction types and states for normal transactions
whose sole purpose is to facilitate testing.

TESTABILITY TIPS.

a. Implement transaction flows along with supporting data

structures as a primary specification and design tool.
b. Use explicit transaction-control blocks as a primary control
mechanism.
c. Build all instrumentation in as part of the system design.
d. Use a centralized, table-driven, transaction dispatcher to control
transaction flows.
 e. Implement transaction control as table-driven finite-state
machines for which transaction state information is stored in the
transaction-control block.
f. Be willing to add fields to transaction-control blocks and states to
transaction flows if by doing so you can avoid biosis, mitosis,
absorption, and conjugation.
g. Make sure there is one-to-one correspondence between
transaction-flow paths and functional requirements, if possible.
h. To the extent that you can control it, apply the same structure
rules to transaction flows that you apply to code.
i. Emulate the testability criteria for code; that is, keep the number
of covering paths, number of feasible paths, and total path
number as close as possible to one another.
Unit 3
Domain testing:
1. Domain Testing :
It is a software testing technique where minimum numbers of
inputs are used to access appropriate output of a system, to ensure
the system does not accept invalid input values. The system is
expected to give required outputs blocking the invalid inputs.
2. Domain and Path

o Domain:In mathematics, domain is a set of possible

values of an independant variable or the variables of a
function. o Programs as input data classifiers: domain
testing attempts to determine whether the classification
is or is not correct.
o Domain testing can be based on specifications or
equivalent implementation information.
o If domain testing is based on specifications, it is a
functional test technique.
o If domain testing is based implementation details, it is
a structural test
3. Importance of Domain Testing
 Protection of Input Space:
 Error detection:
 Preventing Bugs: .
 Enhanced Efficiency of Tests:
4. Domains :
 a. Domains can be specified directly and are predefined by their
boundaries.
b. A Single Domain may consist of one or more boundaries.
c. Every boundaries consists of one or more predicates in order to
check the number which belong or do not belong to domain
d. With domain there are 2 possibilities. Which are as follows
i. Domain consists of a connected part
ii. Domain consists of a disconnected part
5. Domain Closure:
a. The aim of the domain closure is to allow the Wrong closre
bugs to become as frequent domain bugs
b. To understand the domain closure, let us take an example
which consists of three cases for one dimensional domain
c. If the boundary points are related to other domain they are
called as OPEN BOUNDARY
d. If the boundary points are related to that domain itself they are
called as closed boundary.
e. The cases for one Dimensional domain are as follows
i. Domain is open on one side
ii. Domain is closed on both side
iii. Domain is open on both side
iv. Domain is open on one side

6. Domain Dimensionality
a. Every input variable adds one dimension to the domain.
b. One variable defines domains on a number line
c. Two variable defines planar domains
d. Three variables define solid domains
7. Bug Assumption for Domain testing
a. Ambiguous Domain
 i. In this, the union of the Specific domains results either in
missing domains or holes. Hence the union operation is
incomplete
ii. This bug will occur when the combination of required
domains are not completed.
b. Overloaded Domain:
i. The bug will occur when the domain consists of too many
conditions which results in a null domain.
c. Closure bug:
i. This bug happens when we have selected the Wrong
predicate Such as x>=0 is written as x<=0
d. Boundary Error :
i. This bug occurs when the boundary is shifted or when the
boundary is tilted or missed.
e. Faulty Logic:
i. This bug happens when there are incorrect manipulations
calculations or Simplications in a domain.
8. NICE AND UGLY DOMAINS
a. NICE DOMAINS
i. There are some of the properties related to domain
boundaries
ii. If we apply these properties then it makes domain testing
very simple
iii. If we do not apply these properties then it makes domain
testing very difficult.

iv. Some important properties of nice domains are:

Linear, Complete, Systematic, Orthogonal,
Consistently closed, Convex and Simply
connected.
b. LINEAR AND NON LINEARY BOUNDARIES:
i. Nice Domains boundaries can be described by using
linear inequalities or equation
ii. Linear boundaries are more frequently used than the
non linear boundaries
c. COMPLETE BOUNDARIES
 i. NICE domain boundaries have complete boundaries
because they cover from plus infinity to the minus
infinity
ii. One of the main advantage of a complete boundaries
is that it requires only one set of test to verify the
boundary irrespective of the number of surrounding
domains.
d. ORTHOGONAL BOUNDARIES

E. Consistent closure:
a. they are most Simple and fundamental closure that gives a
systematic results after performing the required analysis.
b. in the below fig. the shading lines on the boundary shows that the
domain consists of shading lines
c. inconsistent closure in contrast to consistent closure , are not
fundamental and does not give any systematic results.
 e. Convex:
i. For any 2 boudaries with 2 points placed on them are
combined by using a single then all the points on that line
are within the range.
ii. Nice Domain support convex property, whereas Dirty
domains are don’t.
f. Simply connected :
i. Nice domains are Simply connected because they are
available at one place as a whole but not dispersed in
other domains.
ii. Simply connected and convex domains are related to each
other
g. Systematic boundaries:
i. It refers to boundary inequalities associate with simple
mathematical functions such as constant
ii. If the boundaries are systematic then generating a test for
one boundary can automatically generate the tests for the
remaining boundaries within the set.

UGLY DOMAINS
A. These Simplication can be either good orbad depending upon
the Specifications
B. If the domains complexity is important and the programmers
simplications is safe, then it will not cause any bugs
 C. When the domain complexity is important and the
programmers simplications is not safe it will results in bugs

NON LINEARY BOUNDARIES :

A. These boundaries may or may not be present in simple
programming because these boundaries do not provide an
information regarding simplification of boundaries even if they
are important.
B. Ambiguity and Contradictions: Programs cant be ambiguous
contradictory whereas specification can be.
C. It leads to holes or cracks in the input Space. A hole in the one
variable input space can be easily viewed whereas Ambiguity in
2 variables input Space is difficult to identify.
 SIMPLIFICATION OF TOPOLOGY
A. Once the programmers find out the bugs from domain topology
then the testers try to simplify the domains topology by using
following cases.

9. PATH PRODUCTS AND PATH EXPRESSIONS:

a. Path a. : A path is a combination of several path
segments. Each segment is given a name
b. The path is expressed as the concatenation of all the path
segment of that path.
c. PATH PRODUCTS:
i. The product after Concatenation is known as path
products.
ii. In the fig, there are 4 path segments a,b,c,d the path from
node 1 to 5 can be expressed as concatenation.
iii. If A and B ARE Path segments
A=abc
B=def then the path products would be
AB=abcdef

d. PATH EXPRESSIONS:
i. The expressions which represents the set of all possible
paths between an entry and exit nodes as path expression
ii. The path expression consists of path names and (+)
means (ORs)
iii. If we consider node I as entry node and node 5 as an exit
node, then [Link] paths available between 1 to 5 are
Abcdef
Abccdef
Abccdeef and so on

iv. Path Sums

a. The parallel path segments in the path indicates that
the flow can occur of those parallel paths
b. It can be represented by OR or Sum (+)
c. Path sum is the path between parallel links between
the 2 nodes
d. If the paths between nodes 2 and 3 are considered,
there are 5 parallel links b,c,d,ef, the path between
those 2 nodes would be represented as
 B+c+d+e+f
 The entire path would be represented as
a(b+c+d+e+f_g
 Abg+acg+adg+aeg+afg
Domain and Interface testing
1. Domain testing plays a very important in integration testing
2. It is a technique used to determine whether the components
are accurate or not
3. Possible forms of interface as follows
4. Global variables of 2 components
5. Data objects of two components
6. Subroutine of the 2 components
7. Interface testing can be defined as a method of testing in which
call to the Subroutine is made to detect the presence of any
errors
8. Some of the applications of domains testing for interface
testing are as follows
 Domains and range
 Closure compatablity
 Span compatablity
 Interface range and Domain compatablity
 DOMAIN AND RANGE:
1. Domains are nothing but the values taken as input by the
function
2. Range is just opposite to domains
3. Ranges are the values obtained as output from the function
4. In more testing techniques more focuses is on input values. But
interface testing mainly focuses on output values.
5. Interface testing is also used to check the accuracy between
the Domain and range
 CLOSURE COMPATABLITY
1. It is used to determine the closure affinity between the domain
range
2. Let their domain lie between the numbers 1 to 18
3. The closure compatablity can be determined by taking 2 types
of numbers lines. They are
 Thick number lines(Closed lines)
 Thin number lines(Open lines)
 These 2 lines can be represented in 4 possible ways
 Thick lines on top and bottom
 Thin lines on top and thick lines on bottom
 Thick lines on top and thin lines at the bottom
 Thin lines on top and bottom
Differences between Verification and Validation
Verification Validation

It includes checking documents, design, It includes testing and validating the actual
codes and programs. product.
 Verification Validation

Verification is the static testing. Validation is the dynamic testing.

It does not include the execution of the

It includes the execution of the code.
code.

Methods used in verification are reviews, Methods used in validation are Black Box
walkthroughs, inspections and desk- Testing, White Box Testing and non-
checking. functional testing.

It checks whether the software meets the

It checks whether the software conforms
requirements and expectations of a customer
to specifications or not.
or not.

It can find the bugs in the early stage of It can only find the bugs that could not be
the development. found by the verification process.

The goal of verification is application and

The goal of validation is an actual product.
software architecture and specification.

Validation is executed on software code with

Quality assurance team does verification.
the help of testing team.

It comes before validation. It comes after verification.

It consists of checking of documents/files It consists of execution of program and is

and is performed by human. performed by computer.

Verification refers to the set of activities Validation refers to the set of activities that
that ensure software correctly ensure that the software that has been built is
implements the specific function. traceable to customer requirements.
 Verification Validation

After a valid and complete specification

Validation begins as soon as project starts.
the verification starts.

Verification is for prevention of errors. Validation is for detection of errors.

Verification is also termed as white box Validation can be termed as black box testing
testing or static testing as work product or dynamic testing as work product is
goes through reviews. executed.

Verification finds about 50 to 60% of the Validation finds about 20 to 30% of the
defects. defects.

Verification is based on the opinion of

Validation is based on the fact and is often
reviewer and may change from person to
stable.
person.

Verification is about process, standard

Validation is about the product.
and guideline.

Software Testing Tools

Last Updated : 13 Mar, 2024





Software Testing tools are the tools that are used for the testing of software.
Software testing tools are often used to assure firmness, thoroughness, and
performance in testing software products. Unit testing and subsequent
integration testing can be performed by software testing tools. These tools
are used to fulfill all the requirements of planned testing activities. These
tools also work as commercial software testing tools. The quality of the
software is evaluated by software testers with the help of various testing
tools.
Types of Testing Tools
Software testing is of two types, static testing, and dynamic testing. Also,
the tools used during these testing are named accordingly on these testings.
Testing tools can be categorized into two types which are as follows:
1. Static Test Tools: Static test tools are used to work on the static testing
processes. In the testing through these tools, the typical approach is taken.
These tools do not test the real execution of the software. Certain input and
output are not required in these tools. Static test tools consist of the
following:
 Flow analyzers: Flow analyzers provides flexibility in the data flow from
input to output.
 Path Tests: It finds the not used code and code with inconsistency in the
software.
 Coverage Analyzers: All rationale paths in the software are assured by
the coverage analyzers.
 Interface Analyzers: They check out the consequences of passing
variables and data in the modules.
2. Dynamic Test Tools: Dynamic testing process is performed by the
dynamic test tools. These tools test the software with existing or current
data. Dynamic test tools comprise the following:
 Test driver: The test driver provides the input data to a module-under-
test (MUT).
 Test Beds: It displays source code along with the program under
execution at the same time.
 Emulators: Emulators provide the response facilities which are used to
imitate parts of the system not yet developed.
 Mutation Analyzers: They are used for testing the fault tolerance of the
system by knowingly providing the errors in the code of the software.

Software Testing Tools - Win Runner

Win Runner is the most used Automated Software Testing Tool.
Main Features of Win Runner are

 Developed by Mercury Interactive

 Functionality testing tool
 Supports C/s and web technologies such as (VB, VC++, D2K, Java, HTML, Power
Builder, Delphe, Cibell (ERP))
 To Support .net, xml, SAP, Peoplesoft, Oracle applications, Multimedia we can
use QTP.
 Winrunner run on Windows only.
 Xrunner run only UNIX and linux.
 Tool developed in C on VC++ environment.
 To automate our manual test win runner used TSL (Test Script language like c)
 ABOUT SILK TEST
Silk Test identifies all windows and controls of the application under test
as objects and defines all of the properties and attributes of each window.
Thus it supports an object-based implementation. Silk Test supports both
recording and descriptive programming methods to identify and verify the
elements in the AUT.

Types of Software Testing

As we know, software testing is a process of analyzing an application's functionality as per the
customer prerequisite.

If we want to ensure that our software is bug-free or stable, we must perform the various types of
software testing because testing is the only method that makes our application bug-free.
The different types of Software Testing
The categorization of software testing is a part of diverse testing activities, such as test strategy,
test deliverables, a defined test objective, etc. And software testing is the execution of
the software to find defects.

The purpose of having a testing type is to confirm the AUT (Application Under Test).

To start testing, we should have a requirement, application-ready, necessary

resources available. To maintain accountability, we should assign a respective module to different
test engineers.

The software testing mainly divided into two parts, which are as follows:

o Manual Testing o
Automation Testing

What is Manual Testing?

Testing any software or an application according to the client's needs without using any automation tool
is known as manual testing.

In other words, we can say that it is a procedure of verification and validation. Manual testing
is used to verify the behavior of an application or software in contradiction of requirements specification.
We do not require any precise knowledge of any testing tool to execute the manual test cases. We can easily
prepare the test document while performing manual testing on any application.

Classification of Manual Testing

In software testing, manual testing can be further classified into three different types of
testing, which are as follows:

o White Box Testing o

Black Box Testing o
Grey Box Testing

White Box Testing

In white-box testing, the developer will inspect every line of code before handing it over to the testing
team or the concerned test engineers.
Subsequently, the code is noticeable for developers throughout testing; that's why this process is known
as WBT (White Box Testing).

In other words, we can say that the developer will execute the complete white-box testing for the
particular software and send the specific application to the testing team.

The purpose of implementing the white box testing is to emphasize the flow of inputs and outputs over
the software and enhance the security of an application.

White box testing is also known as open box testing, glass box testing, structural testing,
clear box testing, and transparent box testing.
 Black Box Testing
Another type of manual testing is black-box testing. In this testing, the test engineer will analyze
the software against requirements, identify the defects or bug, and sends it back to the development
team.

ADVERTISEMENT

Then, the developers will fix those defects, do one round of White box testing, and send it to the testing
team.

Here, fixing the bugs means the defect is resolved, and the particular feature is working according to the
given requirement.

The main objective of implementing the black box testing is to specify the business needs or the
customer's requirements.

In other words, we can say that black box testing is a process of checking the functionality of an
application as per the customer requirement. The source code is not visible in this testing; that's why it is
known as black-box testing.

Types of Black Box Testing

Black box testing further categorizes into two parts, which are as discussed below:
 o Functional Testing o
Non-function Testing

Functional Testing
The test engineer will check all the components systematically against requirement specifications is
known as functional testing. Functional testing is also known as Component testing.

In functional testing, all the components are tested by giving the value, defining the output, and
validating the actual output with the expected value.

Functional testing is a part of black-box testing as its emphases on application requirement rather than
actual code. The test engineer has to test only the program instead of the system.

Types of Functional Testing

Just like another type of testing is divided into several parts, functional testing is also classified into
various categories.

The diverse types of Functional Testing contain the following:

o Unit Testing o
Integration Testing o
System Testing
Now, Let's understand them one by one:

1. Unit Testing
Unit testing is the first level of functional testing in order to test any software. In this, the test engineer
will test the module of an application independently or test all the module functionality is called unit
testing.

The primary objective of executing the unit testing is to confirm the unit components with their
performance. Here, a unit is defined as a single testable function of a software or an application. And it is
verified throughout the specified application development phase.

2. Integration Testing
Once we are successfully implementing the unit testing, we will go integration testing. It is the second
level of functional testing, where we test the data flow between dependent modules or interface
between two features is called integration testing.

The purpose of executing the integration testing is to test the statement's accuracy between each
module.

Types of Integration Testing

Integration testing is also further divided into the following parts:

o Incremental Testing o
Non-Incremental Testing
 Incremental Integration Testing
Whenever there is a clear relationship between modules, we go for incremental integration testing.
Suppose, we take two modules and analysis the data flow between them if they are working fine or not.

If these modules are working fine, then we can add one more module and test again. And we can
continue with the same process to get better results.

In other words, we can say that incrementally adding up the modules and test the data flow between the
modules is known as Incremental integration testing.

Types of Incremental Integration Testing

Incremental integration testing can further classify into two parts, which are as follows:

1. Top-down Incremental Integration Testing

2. Bottom-up Incremental Integration Testing

Let's see a brief introduction of these types of integration testing:

1. Top-down Incremental Integration Testing

In this approach, we will add the modules step by step or incrementally and test the data flow between
them. We have to ensure that the modules we are adding are the child of the earlier ones.
2. Bottom-up Incremental Integration Testing

In the bottom-up approach, we will add the modules incrementally and check the data flow between
modules. And also, ensure that the module we are adding is the parent of the earlier ones.

Non-Incremental Integration Testing/ Big Bang Method

Whenever the data flow is complex and very difficult to classify a parent and a child, we will go for the
non-incremental integration approach. The non-incremental method is also known as the Big Bang
method.

3. System Testing
Whenever we are done with the unit and integration testing, we can proceed with the system testing.

In system testing, the test environment is parallel to the production environment. It is also known as
end-to-end testing.

In this type of testing, we will undergo each attribute of the software and test if the end feature works
according to the business requirement. And analysis the software product as a complete system.

Non-function Testing
The next part of black-box testing is non-functional testing. It provides detailed information on
software product performance and used technologies.

Non-functional testing will help us minimize the risk of production and related costs of the software.

Non-functional testing is a combination of performance, load, stress, usability and,

compatibility testing.

Types of Non-functional Testing

Non-functional testing categorized into different parts of testing, which we are going to discuss further:

o Performance Testing
o Usability Testing o
Compatibility Testing
 1. Performance Testing
In performance testing, the test engineer will test the working of an application by applying some load.

In this type of non-functional testing, the test engineer will only focus on several aspects, such as
Response time, Load, scalability, and Stability of the software or an application.

Classification of Performance Testing

Performance testing includes the various types of testing, which are as follows:

o Load Testing o Stress Testing o Scalability Testing o Stability Testing

 o Load Testing

While executing the performance testing, we will apply some load on the particular application to check
the application's performance, known as load testing. Here, the load could be less than or equal to
the desired load.

It will help us to detect the highest operating volume of the software and bottlenecks. o Stress

Testing

It is used to analyze the user-friendliness and robustness of the software beyond the common functional
limits.

Primarily, stress testing is used for critical software, but it can also be used for all types of software
applications.

o Scalability Testing

To analysis, the application's performance by enhancing or reducing the load in particular balances is
known as scalability testing.

In scalability testing, we can also check the system, processes, or database's ability to
meet an upward need. And in this, the Test Cases are designed and implemented efficiently.

o Stability Testing
Stability testing is a procedure where we evaluate the application's performance by applying the load for
a precise time.

It mainly checks the constancy problems of the application and the efficiency of a developed product. In
this type of testing, we can rapidly find the system's defect even in a stressful situation.

2. Usability Testing
Another type of non-functional testing is usability testing. In usability testing, we will
analyze the user-friendliness of an application and detect the bugs in the software's enduser interface.

Here, the term user-friendliness defines the following aspects of an application:

 o The application should be easy to understand, which means that all the features must be visible to
end-users.
o The application's look and feel should be good that means the application should be pleasant looking
and make a feel to the end-user to use it.

3. Compatibility Testing
In compatibility testing, we will check the functionality of an application in specific hardware and
software environments. Once the application is functionally stable then only, we go for compatibility
testing.

Here, software means we can test the application on the different operating systems and other
browsers, and hardware means we can test the application on different sizes.

Grey Box Testing

Another part of manual testing is Grey box testing. It is a collaboration of black box
and white box testing.

Since, the grey box testing includes access to internal coding for designing test cases.
Grey box testing is performed by a person who knows coding as well as testing.

In other words, we can say that if a single-person team done both white box and blackbox
testing, it is considered grey box testing.