lOMoARcPSD|35591857

Software Testing Answer Book

COMPUTER APPLICATION (University of Madras)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by 21-526 ([email protected])
 lOMoARcPSD|35591857

Software Testing Answers

2 Marks:

1.What is the purpose of testing?

Testing consumes at least half of the time and work required to produce a
functional program.

• MYTH: Good programmers write code without bugs. (It’s wrong!!!)

• History says that even well written programs still have 1-3 bugs per
hundred statements.

2.What is the purpose of debugging?

Debugging is the process of detecting and removing of existing and potential

errors (also called as 'bugs') in a software code that can cause it to behave
unexpectedly or crash. To prevent incorrect operation of a software or
system, debugging is used to find and resolve bugs or defects.

3.What are the 4 types of bugs?

i. Unit-Level Bugs
ii. System-Level Integration Bugs
iii. Out of bond bugs
iv. Functional errors
v. Syntax errors
vi. Logic errors
vii. Calculation errors

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

4.What is path instrumentation?

Instrumentation plays a bigger role in transaction flow testing than in unit
path testing. The information of the path taken for a given transaction must
be kept with that transaction and can be recorded by a central transaction
dispatcher or by the individual processing modules. In some systems, such
traces are provided by the operating systems or a running log.

5.What is the link marker?

A simple and effective form of instrumentation is called a traversal marker or

link marker. It names every link by a lower case. It instruments the links so
that the link’s name is recorded when the link is executed. The succession of
letters produced in going from the routine’s entry to its exit should, if there
are no bugs, exactly correspond to the path name.

6.What are hyperplanes?

A hyperplane is a boundary that divides the plane. It is a decision boundary

that classifies the data points into 2 distinct classes. As SVM is used to
classify data in multi-dimensional, a hyperplane can be a straight line if there
are 2 inputs or a 2 D plane if there are more than 2 inputs.

7.What is domain span?

The domain span is the set of numbers between (and including) the smallest
value and the largest value. For every input variable we want (at least):
compatible domain spans and compatible closures (Compatible but need not be
Equal).

8.List any 4 weakness apply to all linguistic metrics?

It is based on measuring properties of program text without interpreting what

the text means.

9.What is meta language?

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

Meta language is a means of describing the format or a grammar of another

language. Typically in computing, meta languages are used to describe the
syntax of a programming language or the format of data for storing in a file
or transferring between applications.

10.What is string recognizer?

A language recognizer is a function, which given a string, decides (yes/no) if

the string belongs to a certain language. Theoretical computer science is
interested in the types of computing machines necessary to identify languages.

11.What are the 4 areas of decision table?

A decision table is a table with various conditions and their corresponding

actions. Decision tree is a two-dimensional matrix. It is divided into four
parts, condition stub, action stub, condition entry, and action entry.

12.What is finite state machine?

Finite state machine (FSM) is a term used by programmers, mathematicians,

engineers and other professionals to describe a mathematical model for any
system that has a limited number of conditional states of being.

13.Define the terms “bugs”?

Bugs are more insidious (deceiving but harmful) than ever we expect them to
be. An unexpected test result may lead us to change our notion of what a bug
is and our model of bugs.

14.What are the elements of control flow graph?

A flow graph contains four different types of elements, Process Block,

Decisions, Junctions, Case Statements.

15.What is the motivation of Path testing?

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

Path testing follows a process of control flow or workflow, rather than

executing the process of testing on the basis of specifications. The main
intent behind this type of testing is to ensure that every possible path has
been covered and executed at least once, through the software program.

16.Differentiate between Domain and Range?

Domain is also defined as a set of all probable input values. This means that
the output value will depend on each member. On the other hand, range is
defined as a set of all probable output values. Moreover, the values in a range
can only be calculated by having the domain value.

17.What is Dynamic slicing?

A dynamic program slice is an executable part of the original program that

preserves part of the program's behavior for a specific input with respect to
a subset of selected variables, rather than for all possible computations. As a
result, the size of a slice can be significantly reduced.

18.What is BNF Notation?

Backus Normal Form (BNF) is a metasyntactic notation procedure used to

specify the syntax of computer programming languages, command/instruction
sets, document formatting and communication protocols. BNF is applied when
language descriptions are required. BNF is also known as Backus-Naur form.

19.Write any 2 principles of State Testing?

i. Testing shows the presence of defects

ii. Exhaustive testing is not possible

20.What is the use of Decision Table?

The decision table is a software testing technique which is used for testing
the system behavior for different input combinations. This is a systematic
approach where the different input combinations and their corresponding
system behavior are captured in a tabular form.

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

21.What is program’s environment?

A test environment is any space in which software undergoes a series of

experimental uses. Testing is essential to any software development
methodology. And a weak testing strategy can result in final deployments that
are rife with bugs and errors. There are many ways to run tests, and most
involve test environments.

22.What is the objective of path testing?

The objective of path testing is to ensure that each independent path through
the program is executed at least once. An independent program path is one
that traverses at least one new edge in the flow graph. In program terms,
this means exercising one or more new conditions.

23.What is unachievable path?

If you can’t find a solution to any of the sets of inequalities, the path is
unachievable. The act of finding a set of solutions to the path predicate
expression is called path sensitization.

24.Define required element testing?

Required element testing is a class of testing strategies that. dom inputs

(random testing) to identifying important test data allow the various
approaches to testing to be combined. In. for each of the functions that the
program performs (as in general, a required element testing strategy is a rule
for specify.

25.List the three possible kinds of incorrect actions?

i. Error
ii. Bugs
iii. Accidental changes in program

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

26. What are the three sets of sequences in set of tests?

i. Unit Testing
ii. Integration Testing
iii. System Testing
iv. Acceptance Testing

27.List a few goals of software testing?

The main goal of software testing is to find bugs as early as possible and fix
bugs and make sure that the software is bug-free.

28.Define Data Flow Testing?

Data flow testing is a family of test strategies based on selecting paths

through the program's control flow in order to explore sequences of events
related to the status of variables or data objects. Dataflow Testing focuses
on the points at which variables receive values and the points at which these
values are used.

29.What is partition testing?

It is a software testing technique that divides the input test data of the
application under test into each partition at least once of equivalent data from
which test cases can be derived.

30.Define Slicing and Dicing?

To slice and dice is to break a body of information down into smaller parts or
to examine it from different viewpoints so that you can understand it better.

31.What is linguistic metric?

It is based on measuring properties of program text without interpreting what

the text means.

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

32.What is path expression?

Any expression that consists of path names and "OR"s and which denotes a set
of paths between two nodes is called a path expression.

33.Define linear predicate?

In domain testing, predicates are assumed to be interpreted in terms of input

vector variables.

5 Marks:

1. Explain the model of testing process with a diagram.

Below figure is a model of testing process. It includes three models: A model

of the environment, a model of the program and a model of the expected
bugs.

Environment:

* A Program's environment is the hardware and software required to make it

run.

* For online systems, the environment may include communication lines, other
systems, terminals and operators.

* The environment also includes all programs that interact with and are used
to create the program under test - such as OS, linkage editor, loader,
compiler, utility routines.

* It’s because the hardware and firmware are stable, it is not smart to blame
the environment for bugs.

Program:

* Most programs are too complicated to understand in detail.

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

* The concept of the program is to be simplified in order to test it.

* If simple model of the program doesn't explain the unexpected behavior, we

may have to modify that model to include more facts and details. And if that
fails, we may have to modify the program.

Bugs:

* Bugs are more insidious (deceiving but harmful) than ever we expect them to
be.

* An unexpected test result may lead us to change our notion of what a bug is
and our model of bugs.

2. Explain the productivity and quality in software?

* In production of consumer goods and other products, every manufacturing

stage is subjected to quality control and testing from component to final
stage.

* If flaws are discovered at any stage, the product is either discarded or

cycled back for rework and correction.

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

* Productivity is measured by the sum of the costs of the material, the

rework, and the discarded components, and the cost of quality assurance and
testing.

* If sufficient time is not spent in quality assurance, the reject rate will be
high and so will be the net cost. If inspection is good and all errors are
caught as they occur, inspection costs will dominate, and again the net cost
will suffer.

The biggest part of software cost is the cost of bugs: the cost of detecting
them, the cost of correcting them, the cost of designing tests that discover
them, and the cost of running those tests.

For software, quality and productivity are indistinguishable because the cost
of a software copy is trivial.

3.What are the principles of State Testing?

Principles of State Testing

The strategy for state testing is analogous to that used for path testing flow
graphs.

Just as it's impractical to go through every possible path in a flow graph, it's
impractical to go through every path in a state graph.

The notion of coverage is identical to that used for flow graphs.

Even though more state testing is done as a single case in a grand tour, it's
impractical to do it that way for several reasons.

In the early phases of testing, you will never complete the grand tour because
of bugs. Later, in maintenance, testing objectives are understood, and only a
few of the states and transitions have to be tested. A grand tour is waste of
time.

Theirs is no much history in a long test sequence and so much has happened
that verification is difficult.

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

Starting point of state testing

Define a set of covering input sequences that get back to the initial state
when starting from the initial state.

For each step in each input sequence, define the expected next state, the
expected transition, and the expected output code.

A set of tests, then, consists of three sets of sequences: o Input sequences

Corresponding transitions or next-state names

Output sequences

Limitations and Extensions

State transition coverage in a state graph model does not guarantee complete
testing.

How defines a hierarchy of paths and methods for combining paths to produce
covers of state graphs.

The simplest is called a "0 switch" which corresponds to testing each transition
individually. The next level consists of testing transitions sequences consisting
of two transitions called "1 switches".

The maximum length switch is "n-1 switch" where there are n numbers of
states. o Situations at which state testing is useful

Any processing where the output is based on the occurrence of one or more
sequences of events, such as detection of specified input sequences, sequential
format validation, parsing, and other situations in which the order of inputs is
important.

Most protocols between systems, between humans and machines, between

components of a system.

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

Device drivers such as for tapes and discs that have complicated retry and
recovery procedures if the action depends on the state.

Whenever a feature is directly and explicitly implemented as one or more

state transition tables.

4.Explain the span compatibility with an example?

5.Explain briefly the application of path testing?

i. Path Testing is the name given to a family of test techniques based on

judiciously (with good judgement or sense) selecting a set of test paths
through the program.

ii. Path testing techniques are the oldest of all structural test techniques.

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

iii. Path testing is most applicable to new software for unit testing. It is a
structural test technique.

iv. It requires complete knowledge of the program's structure.

v. It is most often used by programmers to unit test their own code.

vi. The effectiveness of path testing rapidly decreses as the size of the
software aggregate under test increases.

6.Give a brief account on achievable paths?

REVIEW: ACHIEVABLE AND UNACHIEVABLE PATHS:

We want to select and test enough paths to achieve a satisfactory notion of

test completeness such as C1+C2.

Extract the programs control flowgraph and select a set of tentative covering
paths.

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.

Trace the path through, multiplying the individual compound predicates to

achieve an expression such as:

(A+BC) (D+E) (FGH) (IJ) (K) (I) (L).

Multiply out the expression to achieve a sum of products form:

ADFGHIJKL+AEFGHIJKL+BCDFGHIJKL+BCEFGHIJKL

Each product term denotes a set of inequalities that if solved will yield an
input vector that will drive the routine along the designated path.

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

Solve any one of the inequality sets for the chosen path and you have found a
set of input values for the path.

If you can find a solution, then the path is achievable.

If you can’t find a solution to any of the sets of inequalities, the path is un
achievable.

The act of finding a set of solutions to the path predicate expression is called
PATH SENSITIZATION.

7.Explain the importance of bugs?

The importance of bugs depends on frequency, correction cost,

installation cost, and consequences:

a. Frequency: How often does that kind of bug occur? Pay more
attention to the
ii. More frequent bug types:
a. Correction Cost: What does it cost to correct the bug after it is
found. The cost is the sum of 2 factors: (1) the cost of discovery
(2) the cost of correction. These costs go up dramatically later in
the development cycle when the bug is discovered. Correction cost
also depends on system size.
b. Installation Cost: Installation cost depends on the number of
installations: small for a single user program but more for
distributed systems. Fixing one bug and distributing the fix could
exceed the entire system's development cost.
c. Consequences: What are the consequences of the bug? Bug
consequences can range from mild to catastrophic.
iii. A reasonable metric for bug importance is:
Importance= ($) = Frequency * (Correction cost + Installation cost +
Consequential cost)

8.Compare Testing vs Debugging?

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

9.Write a short note on Path Instrumentation?

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

10.What is Interface testing?

For interface testing, bugs are more likely to concern single variables
rather than peculiar combinations of two or more variables.

i. Test every input variable independently of other input

variables to confirm compatibility of the caller's range
and the called routine's domain span and closure of every
domain defined for that variable.

ii. There are two boundaries to test and it's a one-

dimensional domain; therefore, it requires one on-off
point per boundary or a total of two on points and two
off points for the domain - pick the off points
appropriate to the closure (COOOOI).

iii. Start with the called routine's domains and generate test
points in accordance to the domain-testing strategy used
for that routine in component testing.

iv. Unless you're a mathematical whiz you won't be able to

do this without tools for more than one variable at a
time.

11.Write down the steps in Syntax testing?

Syntax Testing, a black box testing technique, involves testing the System
inputs and it is usually automated because syntax testing produces a large
number of tests. Internal and external inputs have to conform the below
formats:

Format of the input data from users:

i. File formats.

ii. Database schemas.

iii. Syntax Testing - Steps:

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

Identify the target language or format.

Define the syntax of the language.
Validate and debug the syntax.

iv. Syntax Testing - Limitations:

Sometimes it is easy to forget the normal cases.
Syntax testing needs driver program to be built that automatically sequences
through a set of test cases usually stored as data.

12.How to classify metrics?

Software metrics is a standard of measure that contains many activities which

involve some degree of measurement. It can be classified into three
categories: product metrics, process metrics, and project metrics.

(i) Product metrics

Product metrics describe the characteristics of the product such as size,

complexity, design features, performance, and quality level.

(ii) Process metrics

Process metrics can be used to improve software development and

maintenance. Examples include the effectiveness of defect removal during
development, the pattern of testing defect arrival, and the response time of
the fix process.

(iii) Project metrics

Project metrics describe the project characteristics and execution. Examples

include the number of software developers, the staffing pattern over the life
cycle of the software, cost, schedule, and productivity.

Some metrics belong to multiple categories. For example, the in-process

quality metrics of a project are both process metrics and project metrics.

13.Write a short note on transition testing?

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

State Transition testing, a black box testing technique, in which outputs are
triggered by changes to the input conditions or changes to 'state' of the
system. In other words, tests are designed to execute valid and invalid state
transitions.

When to use?

When we have sequence of events that occur and associated conditions that
apply to those events

When the proper handling of a particular event depends on the events and
conditions that have occurred in the past

It is used for real time systems with various states and transitions involved

Deriving Test cases:

Understand the various state and transition and mark each valid and invalid
state

Defining a sequence of an event that leads to an allowed test ending state

Each one of those visited state and traversed transition should be noted down

Steps 2 and 3 should be repeated until all states have been visited and all
transitions traversed

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

For test cases to have a good coverage, actual input values and the actual
output values have to be generated.

14. Explain the terminology used in data- flow testing strategies?

TERMINOLOGY:
i. Definition-Clear Path Segment, with respect to variable X, is a
connected sequence of links such that X is (possibly) defined on
the first link and not redefined or killed on any subsequent link of
that path segment. ll paths in Figure 3.9 are definition clear
because variables X and Y are defined only on the first link (1,3)
and not thereafter. In Figure 3.10, we have a more complicated
situation. The following path segments are definition-clear:
(1,3,4), (1,3,5), (5,6,7,4), (7,8,9,6,7), (7,8,9,10), (7,8,10),
(7,8,10,11). Subpath (1,3,4,5) is not definition-clear because
the variable is defined on (1,3) and again on (4,5). For practice,
try finding all the definition-clear subpaths for this routine (i.e.,
for all variables).

ii. Loop-Free Path Segment is a path segment for which every node
in it is visited almost once. For Example, path (4,5,6,7,8,10) in
Figure 3.10 is loop free, but path (10,11,4,5,6,7,8,10,11,12) is
not because nodes 10 and 11 are each visited twice.

iii. Simple path segment is a path segment in which at most one node
is visited twice. For example, in Figure 3.10, (7,4,5,6,7) is a
simple path segment. A simple path segment is either loop-free or
if there is a loop, only one node is involved.

iv. A du path from node i to k is a path segment such that if the

last link has a computational use of X, then the path is simple and
definition-clear; if the penultimate (last but one) node is j - that
is, the path is (i,p,q,...,r,s,t,j,k) and link (j,k) has a predicate
use - then the path from i to j is both loop-free and definition-
clear.

15. Explain the range/domain closure compatibility?

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

16.Write of brief note on Halstead’s metrics?

Halstead’s metrics are included in a number of current commercial tools that

count software lines of code. By counting the tokens and determining which
are operators and which are operands, the following base measures can be
collected:
n1 = Number of distinct operators.
n2 = Number of distinct operands.
N1 = Total number of occurrences of operators.
N2 = Total number of occurrences of operands.

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

In addition to the above, Halstead defines the following:

n1* = Number of potential operators.

n2* = Number of potential operands.

Halstead refers to n1* and n2* as the minimum possible number of operators
and operands for a module and a program respectively. This minimum number
would be embodied in the programming language itself, in which the required
operation would already exist (for example, in C language, any program must
contain at least the definition of the function main()), possibly as a function
or as a procedure: n1* = 2, since at least 2 operators must appear for any
function or procedure : 1 for the name of the function and 1 to serve as an
assignment or grouping symbol, and n2* represents the number of
parameters, without repetition, which would need to be passed on to the
function or the procedure.

Halstead metrics are:

 Halstead Program Length – The total number of operator

occurrences and the total number of operand occurrences.
N = N1 + N2
And estimated program length is, N ^ = n1log2n1 + n2log2n2
The following alternate expressions have been published to estimate
program length:

 NJ = log2(n1!) + log2(n2!)
 NB = n1 * log2n2 + n2 * log2n1
 NC = n1 * sqrt(n1) + n2 * sqrt(n2)
 NS = (n * log2n) / 2
 Halstead Vocabulary – The total number of unique operator and
unique operand occurrences.
n = n1 + n2
 Program Volume – Proportional to program size, represents the size,
in bits, of space necessary for storing the program. This parameter
is dependent on specific algorithm implementation. The properties V,
N, and the number of lines in the code are shown to be linearly
connected and equally valid for measuring relative program size.
V = Size * (log2 vocabulary) = N * log2(n)
The unit of measurement of volume is the common unit for size
“bits”. It is the actual size of a program if a uniform binary
encoding for the vocabulary is used. And error = Volume / 3000

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

 Potential Minimum Volume – The potential minimum volume V* is

defined as the volume of the most succinct program in which a
problem can be coded.

V* = (2 + n2*) * log2(2 + n2*)

Here, n2* is the count of unique input and output parameters

 Program Level – To rank the programming languages, the level of

abstraction provided by the programming language, Program Level (L)
is considered. The higher the level of a language, the less effort it
takes to develop a program using that language.
L = V* / V

The value of L ranges between zero and one, with L=1 representing
a program written at the highest possible level (i.e., with minimum
size).
And estimated program level is L ^ =2 * (n2) / (n1)(N2)
 Program Difficulty – This parameter shows how difficult to handle
the program is.
D = (n1 / 2) * (N2 / n2)
D = 1 / L
As the volume of the implementation of a program increases, the
program level decreases and the difficulty increases. Thus,
programming practices such as redundant usage of operands, or the
failure to use higher-level control constructs will tend to increase
the volume as well as the difficulty.
 Programming Effort – Measures the amount of mental activity
needed to translate the existing algorithm into implementation in the
specified program language.
E = V / L = D * V = Difficulty * Volume

 Language Level – Shows the algorithm implementation program

language level. The same algorithm demands additional effort if it is
written in a low-level program language. For example, it is easier to
program in Pascal than in Assembler.
L’ = V / D / D
lambda = L * V* = L2 * V

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

 Intelligence Content – Determines the amount of intelligence

presented (stated) in the program This parameter provides a
measurement of program complexity, independently of the program
language in which it was implemented.
I = V / D
 Programming Time – Shows time (in minutes) needed to translate the
existing algorithm into implementation in the specified program
language.
T = E / (f * S)
The concept of the processing rate of the human brain, developed
by the psychologist John Stroud, is also used. Stoud defined a
moment as the time required by the human brain requires to carry
out the most elementary decision. The Stoud number S is therefore
Stoud’s moments per second with:
5 <= S <= 20. Halstead uses 18. The value of S has been
empirically developed from psychological reasoning, and its
recommended value for programming applications is 18.

Stroud number S = 18 moments / second

seconds-to-minutes factor f = 60.

17.Write about Path Testing Criteria?

Any testing strategy based on paths must at least both exercise every
instruction and take branches in all directions.

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.

So we have explored three different testing criteria or strategies out of a

potentially infinite family of strategies.

Path Testing (Pint):

Execute all possible control flow paths through the program: typically, this is
restricted to all possible entry/exit paths through the program.

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

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.

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. We denote this by C1.

This is the weakest criterion in the family: testing less than this for new
software is unconscionable (unprincipled or can not be accepted) and should
be criminalized.

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.

An alternative characterization is to say that we have achieved 100% link

coverage.

For structured software, branch testing and therefore branch coverage

strictly includes statement coverage.

We denote branch coverage by C2.

18.Write the steps of Transactional Flow Techniques?

GET THE TRANSACTIONS FLOWS:

Complicated systems that process a lot of different, complicated transactions

should have explicit representations of the transactions flows, or the
equivalent. Transaction flows are like control flow graphs, and consequently

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

we should expect to have them in increasing levels of detail. The system's

design documentation should contain an overview section that details the main
transaction flows. Detailed transaction flows are a mandatory pre requisite
to the rational design of a system's functional test.

INSPECTIONS, REVIEWS AND WALKTHROUGHS:

Transaction flows are natural agenda for system reviews or inspections. o In

conducting the walkthroughs, you should:

Discuss enough transaction types to account for 98%-99% of the transaction

the system is expected to process.

Discuss paths through flows in functional rather than technical terms.

Ask the designers to relate every flow to the specification and to show how
that transaction, directly or indirectly, follows from the requirements:

Make transaction flow testing the corner stone of system functional testing
just as path testing is the corner stone of unit testing. Select additional flow
paths for loops, extreme values, and domain boundaries. o Design more test
cases to validate all births and deaths. Publish and distribute the selected
test paths through the transaction flows as early as possible so that they
will exert the maximum beneficial effect on the project.

PATH SELECTION:

Select a set of covering paths (c1+c2) using the analogous criteria you used
for structural path testing. Select a covering set of paths based on
functionally sensible transactions as you would for control flow graphs. Try to
find the most tortuous, longest, strangest path from the entry to the exit
of the transaction flow.

PATH SENSITIZATION:

Most of the normal paths are very easy to sensitize-80% - 95% transaction
flow coverage (c1+c2) is usually easy to achieve. The remaining small
percentage is often very difficult. Sensitization is the act of defining the

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

transaction. If there are sensitization problems on the easy paths, then bet
on either a bug in transaction flows or a design bug.

PATH INSTRUMENTATION:

Instrumentation plays a bigger role in transaction flow testing than in unit

path testing. The information of the path taken for a given transaction must
be kept with that transaction and can be recorded by a central transaction
dispatcher or by the individual processing modules. In some systems, such
traces are provided by the operating systems or a running log.

10 Marks:

1.Describe the 3 types of testing on typical software system?

Tests are formal procedures, Inputs must be prepared, Outcomes should

predict, tests should be documented, commands need to be executed, and
results are to be observed. All these errors are subjected to error.

We do three distinct kinds of testing on a typical software system. They

are:

• Unit / Component Testing:

A Unit is the smallest testable piece of

software that can be compiled, assembled, linked, loaded etc. A unit is

usually the work of one programmer and consists of several hundred or fewer
lines of code. Unit Testing is the testing we do to show that

the unit does not satisfy its functional specification or that its

implementation structure does not match the intended design

structure. A Component is an integrated aggregate of one or more

units. Component Testing is the testing we do to show that the

component does not satisfy its functional specification or that its

implementation structure does not match the intended design

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

structure.

1. Integration Testing: Integration is the process by which components

are aggregated to create larger components. Integration Testing is

testing done to show that even though the components were

individually satisfactory (after passing component testing), checks the

combination of components are incorrect or inconsistent.

2. System Testing: A System is a big component. System Testing is

aimed at revealing bugs that cannot be attributed to components. It

includes testing for performance, security, accountability, configuration

sensitivity, startup and recovery.

2.Explain the transactional flow in details?

 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.
 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:

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

USAGE:
 Transaction flows are indispensable for specifying requirements of
complicated systems, especially online systems.
 A big system such as an air traffic control or airline reservation system
has not hundreds, but thousands of different transaction flows.
 The flows are represented by relatively simple flow graphs, many of
which have a single straight-through path.
 Loops are infrequent compared to control flow graphs.
 The most common loop is used to request a retry after user input
errors. An ATM system, for example, allows the user to try, saying
three times, and will take the card away the fourth time.
COMPLICATIONS:
 In simple cases, the transactions have a unique identity from the time
they're created to the time they're completed.
 In many systems, the transactions can give birth to others, and
transactions can also merge.

3.List any 5 data flow testing strategies?

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

STRATEGIES: The structural test strategies discussed below are based on

the program's control flowgraph. They differ in the extent to which
predicate uses and/or computational uses of variables are included in the test
set. Various types of data flow testing strategies in decreasing order of
their effectiveness are:

o All - du Paths (ADUP): The all-du-paths (ADUP) strategy is the

strongest data-flow testing strategy discussed here. It requires that every
du path from every definition of every variable to every use of that
definition be exercised under some test.

For variable X and Y: In Figure 3.9, because variables X and Y are used only
on link (1,3), any test that starts at the entry satisfies this criterion (for
variables X and Y, but not for all variables as required by the strategy).

For variable Z: The situation for variable Z (Figure 3.10) is more complicated
because the variable is redefined in many places. For the definition on link
(1,3) we must exercise paths that include sub paths (1,3,4) and (1,3,5). The
definition on link (4,5) is covered by any path that includes (5,6), such as
sub path (1,3,4,5,6, ...). The (5,6) definition requires paths that include
sub paths (5,6,7,4) and (5,6,7,8).

For variable V: Variable V (Figure 3.11) is defined only once on link (1,3).
Because V has a predicate use at node 12 and the subsequent path to the
end must be forced for both directions at node 12, the all-du-paths
strategy for this variable requires that we exercise all loop-free entry/exit
paths and at least one path that includes the loop caused by (11,4). Note
that we must test paths that include both sub paths (3,4,5) and (3,5) even
though neither of these has V definitions. They must be included because
they provide alternate du paths to the V use on link (5,6). Although (7,4) is
not used in the test set for variable V, it will be included in the test set
that covers the predicate uses of array variable V() and U.

The all-du-paths strategy is a strong criterion, but it does not take as many
tests as it might seem at first because any one test simultaneously satisfies
the criterion for several definitions and uses of several different variables.

 All Uses Strategy (AU):

The all uses strategy is that at least one definition clear path from every
definition of every variable to every use of that definition be exercised

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

under some test. Just as we reduced our ambitions by stepping down from all
paths (P) to branch coverage (C2), say, we can reduce the number of test
cases by asking that the test set should include at least one path segment
from every definition to every use that can be reached by that definition.

For variable V: In Figure 3.11, ADUP requires that we include sub paths
(3,4,5) and (3,5) in some test because subsequent uses of V, such as on link
(5,6), can be reached by either alternative. In AU either (3,4,5) or (3,5)
can be used to start paths, but we don't have to use both. Similarly, we can
skip the (8,10) link if we've included the (8,9,10) sub path. Note the hole.
We must include (8,9,10) in some test cases because that's the only way to
reach the c use at link (9,10) - but suppose our bug for variable V is on link
(8,10) after all? Find a covering set of paths under AU for Figure 3.11.

 All p-uses/some c-uses strategy (APU+C):

For every variable and every definition of that variable, include at least one
definition free path from the definition to every predicate use; if there are
definitions of the variables that are not covered by the above prescription,
then add computational use test cases as required to cover every definition.

For variable Z: In Figure 3.10, for APU+C we can select paths that all take
the upper link (12,13) and therefore we do not cover the c-use of Z: but
that's okay according to the strategy's definition because every definition is
covered. Links (1,3), (4,5), (5,6), and (7,8) must be included because they
contain definitions for variable Z. Links (3,4), (3,5), (8,9), (8,10), (9,6),
and (9,10) must be included because they contain predicate uses of Z. Find a
covering set of test cases under APU+C for all variables in this example - it
only takes two tests.

For variable V: In Figure 3.11, APU+C is achieved for V by

(1,3,5,6,7,8,10,11,4,5,6,7,8,10,11,12[upper], 13,2) and
(1,3,5,6,7,8,10,11,12[lower], 13,2). Note that the c-use at (9,10) need not
be included under the APU+C criterion.

o All c-uses/some p-uses strategy (ACU+P): The c-uses/some p-uses

strategy (ACU+P) is to first ensure coverage by computational use cases and
if any definition is not covered by the previously selected paths, add such

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

predicate use cases as are needed to assure that every definition is included
in some test.

For variable Z: In Figure 3.10, ACU+P coverage is achieved for Z by path

(1,3,4,5,6,7,8,10, 11,12,13[lower], 2), but the predicate uses of several
definitions are not covered. Specifically, the (1,3) definition is not covered
for the (3,5) p-use, the (7,8) definition is not covered for the (8,9), (9,6)
and (9, 10) p-uses. The above examples imply that APU+C is stronger than
branch coverage but ACU+P may be weaker than, or incomparable to, branch
coverage.

 All Definitions Strategy (AD):

The all definitions strategy asks only every definition of every variable be
covered by at least one use of that variable, be that use a computational use
or a predicate use.

For variable Z: Path (1,3,4,5,6,7,8, . . .) satisfies this criterion for

variable Z, whereas any entry/exit path satisfies it for variable V. From the
definition of this strategy we would expect it to be weaker than both ACU+P
and APU+C.

 All Predicate Uses (APU), All Computational Uses(ACU)Strategies:

The all predicate uses strategy is derived from APU+C strategy by dropping
the requirement that we include a c-use for the variable if there are no p-
uses for the variable. The computational uses strategy is derived from
ACU+P strategy by dropping the requirement that we include a p-use for the
variable if there are no c-uses for the variable.

It is intuitively obvious that ACU should be weaker than ACU+P and that APU
should be weaker than APU+C.

4.Explain the bug assumptions for domain testing?

The bug assumption for the domain testing is that processing is okay but the
domain definition is wrong. An incorrectly implemented domain means that
boundaries are wrong, which may in turn mean that control flow predicates
are wrong.

Many different bugs can result in domain errors. Some of them are:

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

Domain Errors:

Double Zero Representation:

In computers or Languages that have a distinct positive and negative zero,

boundary errors for negative zero are common.

Floating point zero check:

A floating point number can equal zero only if the previous definition of that
number set it to zero or if it is subtracted from itself or multiplied by zero.
So, the floating point zero check to be done against an epsilon value.

Contradictory Domains:

An implemented domain can never be ambiguous or contradictory, but a

specified domain can. A contradictory domain specification means that at
least two supposedly distinct domains overlap.

Ambiguous domains:

Ambiguous domains means that union of the domains is incomplete. That is

there are missing domains or holes in the specified domains. Not specifying
what happens to points on the domain boundary is a common ambiguity.

Over-specified Domains:

The domain can be overloaded with so many conditions that the result is a
null domain. Another way to put it is to say that the domain's path is
unachievable.

Boundary Errors: Errors caused in and around the boundary of a domain.

Example, boundary closure bug, shifted, tilted, missing, extra boundary.

Closure Reversal:

A common bug. The predicate is defined in terms of > =. The programmer

chooses to implement the logical complement and incorrectly uses <= for the
new predicate; (i.e.), x >= 0 is incorrectly negated as x <= 0, thereby
shifting boundary values to adjacent domains.

Faulty Logic:

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

Compound predicates (especially) are subject to faulty logic transformations

and improper simplification. If the predicates define domain boundaries, all
kinds of domain bugs can result from faulty logic manipulations.

5.Explain the Model of Testing process?

Refer 5 mark

6.Describe various steps for transaction flow testing?

Refer 5 mark

7.Describe the model of Domain Testing?

8.Discuss any 5 rules of Path Product?

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

9.What are the various types of bugs?

A bug is a software-related problem. If something on a website or in an

application does not work as intended, this “error” is called a bug. Here at
test IO, we distinguish between the following bug types:
 Functional bugs
 Content bugs
 Visual bugs

Functional Bugs

Functional bugs are related to the functionality of a piece of software, e.g. a

button doesn’t submit a form, the search doesn’t react to the user input, an
app crashes, etc. Every time you perform an action and the website/app
doesn’t respond as you expect, it might be a functional issue.

Content Bugs

Content bugs relate to the actual content of websites or apps: text, labels,
pictures, videos, icons, links, data, etc. Hence, typical content bugs are:
 Broken links or images (404s) (unless located in the navigation menu,
header, footer, or a breadcrumb navigation, which are low functional
bugs)
 Defective redirections in general
 Missing text, example, in an empty tooltip
 Missing content, example, empty content area
 Missing content, example, if 4 out of 5 icons have a tooltip, 1 doesn't
 Missing translations, example, some button on an English website having
French labels
 Some products are missing in search results but the search function
itself works
 Missing data

Visual Bugs

Visual bugs relate to the graphical user interfaces of websites or apps, e.g.:
 Layout framework problems such as misaligned texts/elements

Downloaded by 21-526 ([email protected])

 lOMoARcPSD|35591857

A Responsive Design problem, example, an element is displayed on one

mobile device but not on another
 Text/elements unintentionally overlap each other
 Text/elements are cut off.

10.Different categories of State testing?

Downloaded by 21-526 ([email protected])