12- marks

1. Explain about bugs and its types.

Ans: Software bugs can be the bane of any software project,
causing delays, disruption, or even software failures. Any
software development project must pay close attention to bug
identification and resolution. This blog looks at some of the
most common bugs in software testing processes. We’ll also
explore how they can be identified and solved quickly and
effectively so software projects can stay on track and meet
their goals.
What is a Software Bug?
Software bugs are errors, flaws, deficiencies, or defects in a
computer program or system that cause it to produce an
incorrect or unexpected result or to behave in unintended
ways.
Different Types of Bugs in Software Testing:
Software bugs can be classified into multiple categories
based on their nature and impact. Broadly speaking, these
categories include Functional Bugs, Logical Bugs, Workflow
Bugs, Unit Level Bugs, System-Level Integration Bugs, Out of
Bound Bugs, and Security Bugs.
1. Functional Bugs
Functional bugs refer to defects or issues in software
applications that affect their intended functionality. These
bugs can manifest in various ways, such as incorrect
calculations, unexpected behavior, crashes, or unresponsive
features. They can arise due to coding errors, inadequate
testing, compatibility issues, or external factors like hardware
limitations.
For example, for functional testing, let us consider a scenario
wherein the user logs into their Testsigma account. The Email
field within the login page fails to accept special characters
like “@” and “.”, , triggering a functional defect in the form of
an error message.

2. Logical Bugs
Do you know Logical bugs are common in software
development and can be quite challenging to identify and fix?
Unlike syntax errors, which are relatively easy to spot due to
their violation of the programming language’s rules, logical
bugs occur when the code does not produce the expected
output or behavior.
In the image shown below, the user’s action of clicking on the
“Blog” page in Testsigma is depicted. It would be considered a
logical bug if the user is redirected to the “Support” or any
other page.
3. Workflow Bugs
This bug can be a major hindrance to productivity and
efficiency in any organization. These bugs refer to glitches,
errors, or bottlenecks within a workflow process, causing team
members delays, confusion, and frustration.
Let’s consider an example to explain this concept. Upon
accessing the website – Testsigma.com on the below-
mentioned page, the user is expected to be redirected to the
documents page upon clicking the “Doc” icon. However, this
expected behavior does not occur. In that case, it can be
inferred that a workflow bug exists within the system.
4. Unit Level Bugs
Unit-level bugs refer to the defects or errors at the smallest
testable component of a software system, known as a unit.
These units can be functions, methods, classes, or modules.
When developers write code, they break it into smaller units
to make it more manageable and easier to test.
Explaining a unit-level bug through an example is a simple
task. The image shows no action after clicking the “Schedule
a Demo” button. Based on this observation, it can be
concluded that the issue is a unit-level bug, which pertains to
a defect that occurs at the smallest unit of code – a module,
function, or statement.
5. System-Level Integration Bugs
System-level integration bugs refer to the issues that arise
when different components or subsystems of a complex
system fail to work together seamlessly. These bugs can
occur for various reasons, such as incompatible interfaces,
module miscommunication, or inadequate testing.
Consider an example scenario –
Suppose we have a web application with multiple modules
like user registration, login, checkout and payment
processing. Different teams develop each module, which must
be integrated for the application to function correctly. The
application throws an error when the user clicks on “Proceed
to Payment” – means the system failed where the checkout
was integrated with payment. This will be an example of a
system-level integration bug.
6. Out of Bound Bugs
Out Of Bound Bugs occur with logical and arithmetic errors
exceeding the allowable boundaries of a specified operation.
Consider the following scenario in which a user attempts to
schedule a Demo in Testsigma. Upon navigating to
the TimeSlot page, the user incorrectly selects a date one
day before the current date, July 18th, 2023. As a result, the
Demo gets scheduled for July 17th, 2023, which is outside the
acceptable range of dates. This can be categorized as an out-
of-bounds bug.
7. Security Bugs
These are persistent and concerning issues in the world of
technology. These bugs refer to vulnerabilities or flaws in
software, hardware, or systems that malicious actors can
exploit to gain unauthorized access, steal sensitive
information, disrupt services, or cause other harmful
consequences.
So, here is an example of a security flaw. Look at the image
below where the user enters the wrong combination login on
Testsigma login page, it lets the user in! This is a major
software flaw because it exposes the site to security risks.
This will enable anyone to log in to the application. It’s a
security bug.
Common Examples of Software Bugs
Software bugs are flaws within a program that prevents it from
performing correctly and can be caused by design or coding
errors. Common examples of software bugs include:
 Unexpected program crashes
 Results that don’t match expectations,
 The program encountering an infinite loop,
 Incorrect calculations,
 Data missing from a database
 Malfunctioning user interface elements,
 Unresponsive API
 Security vulnerabilities
 Errors with file permissions
 Unnatural slowness
 Compatibility issues
Impact of Software Bugs!
Software bugs can have far-reaching consequences on
software systems, businesses, and users alike. The following
points outline the primary effects of software bugs:
 Extended Development Time: Software bugs can lead to
a prolonged development period, as they need to be
found, identified, and corrected.
 Increased Cost: Investigating and fixing software bugs
can be expensive and time-consuming, increasing
development costs.
 Reduced System Quality: Bugs may prevent a software
system from functioning properly, decreasing system
quality.
 User Frustration: Software bugs can create confusion,
frustration, and dissatisfaction, leading to a poor user
experience.
 Regulatory Compliance Violations: Software bugs can
sometimes cause a business to violate the applicable
regulatory standards.
2. Explain about path instrumentation.
Ans: Path Instrumentation
Path instrumentation confirms that the outcome was achieved
by the intended path.
The displayed image is an example of a routine for the
assumed input value x=4
If it yields the same output y=5 for all the case statements
then it said to be co-incidental correctness
Otherwise it detects a bug

Co-incidental Correctness: The co-incidental correctness

stands for achieving the desired outcome for wrong reason
The above image is an example of a routine, for the
(unfortunately) chosen input value (X=16), yields the same
outcome (y=2), no matter which case we select
Therefore, the tests chosen this way will not tell us whether
we have achieved coverage
For example, the five cases could be totally jumbled and still
the outcome would be the same.

Types of Path Instrumentation

Interpretive Trace Program:
An Interpretive Trace Program is the one that executes every
statement in order, and records the intermediate values of all
calculations, the statement labels traversed etc.
If we run the tested routine under a trace, then we have all the
information needed to confirm the outcome and furthermore,
to confirm that it was achieved by the intended path
The trouble with traces is that they give us far more
information than we need
In fact, the typical trace program provides so much
information that confirming the path from its massive output
dump is more work than simulating the computer by hand to
confirm the path
Traversal Marker or Link Marker:
A simple and effective form of instrumentation is called a
Traversal Marker or Link Marker
Name every link by a lower case letter
Instrument the links so that the links name is recorded when
the link is executed.
The succession of letters produced in going form the routines
entry to its exit should, if there are no bugs, exactly
correspond to the path name

Why single link markers aren't Enough:

Unfortunately, a single link marker may not do the trick
because links can be chewed by open bugs
We intended to traverse the 'i' km path. but because of a
GOTO in the middle of the 'm' link, we go to process B
If conditional correctness is against us, the outcomes will be
the same and we won't know about the bug.

Two Link Marker Method

The solution to the problem of single link marker method is to
implement two markers per link, one at the beginning of each
link and one at the end
The two link markers now specify the path name and confirm
both the beginning and end of the link

Link Counter
A less disruptive (and less informative) instrumentation
method is based on outcomes
Instead of a unique link name to be pushed into a string when
the link traversed, we simply increment a link counter, we now
confirm that the path length is expected
The same problem that led thus to double link markers also
leads us to double link counters.
3. Discuss in detail Domain and Path Testing.
Ans: Domain testing and path testing are both software
testing techniques that help identify issues in a program:
 Domain testing
A software testing method that involves inputting data into an
application and evaluating the outputs to ensure that the
application accepts the data and produces the expected
results. Domain testing is an example of partition testing,
which divides a program's input space into domains. Domain
boundaries are where most domain bugs occur.
  Path testing
A software testing technique that helps identify issues in a
program's code that could impact its performance and
functionality. Path testing is a white box testing technique that
analyzes a program's control-flow graph to find paths of
execution. It's often used by software programmers to unit
test code.
## Domain and Path Testing

Domain and path testing are essential techniques in software

testing that focus on validating the behavior of programs
under various input conditions and execution paths. Both
methodologies aim to ensure software reliability and
correctness by systematically exploring input spaces and
control flows.

## Domain Testing

### Overview
Domain testing is a technique that evaluates the behavior of a
program based on specific sets of input values, known as
domains. The primary goal is to verify that the software
correctly handles valid inputs while rejecting invalid ones. This
method can be categorized into two types based on its
application:
- **Functional Testing**: When based on specifications,
focusing on what the software should do.
- **Structural Testing**: When based on implementation
details, focusing on how the software is constructed.

### Key Concepts

1. **Domains**: A domain is defined as a set of possible
values for one or more independent variables in a program.
Each domain can be classified into valid and invalid input
ranges.
2. **Boundary Value Analysis**: This technique emphasizes
testing at the edges of input domains, as errors often occur at
these boundaries.
3. **Predicates**: In domain testing, predicates are used to
define boundaries. For example, in the statement `IF X > 0
THEN ALPHA ELSE BETA`, numbers greater than zero
belong to ALPHA, while numbers less than or equal to zero
belong to BETA[1][2].

### Testing Strategy

The steps involved in domain testing typically include:
- **Identify Input Variables**: Determine which inputs will be
tested.
- **Classify Domains**: Divide the input space into valid and
invalid domains.
- **Select Test Points**: Focus on boundary values and points
near boundaries to maximize error detection.
- **Execute Tests**: Run tests and analyze outputs to identify
any discrepancies or bugs.

### Advantages
- **Efficient Use of Resources**: By concentrating on specific
input ranges, domain testing allows for more effective
allocation of testing resources.
- **Enhanced Test Coverage**: It helps ensure that all
relevant scenarios are tested, particularly those that may lead
to errors[4].
- **Improved Software Quality**: Identifying edge case issues
contributes to building more robust applications.

## Path Testing

### Overview
Path testing is a structural testing technique that focuses on
executing various paths through a program's control flow
graph. The objective is to ensure that all possible execution
paths are tested at least once, which helps uncover logical
errors in the code.

### Key Concepts

1. **Control Flow Graph (CFG)**: A graphical representation
of all possible paths through a program, where nodes
represent instructions or blocks of code and edges represent
control flow between them.
2. **Cyclomatic Complexity**: A metric used to measure the
number of linearly independent paths through a program. It is
calculated using the formula:
$$ \text{Cyclomatic Complexity} = E - N + 2P $$
where $$E$$ is the number of edges, $$N$$ is the number
of nodes, and $$P$$ is the number of connected components
in the graph[5].

### Testing Strategy

The path testing process generally involves:
- **Constructing a Control Flow Graph**: Visualizing the
program's flow to identify all potential execution paths.
- **Calculating Cyclomatic Complexity**: Determining how
many unique paths need to be tested.
- **Creating Test Cases**: Developing test cases for each
independent path identified in the CFG.

### Advantages
- **Comprehensive Coverage**: Path testing ensures that all
logical paths are executed, reducing the likelihood of
undetected errors.
- **Focus on Logic Flaws**: It specifically targets logical errors
that may not be evident through other testing methods[5].

## Conclusion
Both domain and path testing play crucial roles in software
quality assurance by focusing on different aspects of program
behavior. Domain testing emphasizes input validation and
boundary conditions, while path testing concentrates on
execution logic. Together, they provide a comprehensive
approach to identifying and resolving potential issues within
software applications.
4. Explain the concept of design tables in software
testing and discuss their structure and importance.
Ans: A "design table" in software testing, also known as a
"decision table," is a tabular structure used to systematically
define various input conditions and their corresponding
expected outcomes, essentially helping testers create
comprehensive test cases by considering all possible
combinations of conditions within a system with complex
business rules, ensuring thorough test coverage and
identifying potential logical errors.
Structure of a Design Table:
 Conditions:
The top row of the table lists all the relevant input conditions
that can affect the system's behavior, often represented as
Boolean values (True/False) or discrete values.
 Actions:
The next row(s) define the possible actions or outputs that the
system should perform based on the conditions.
 Rules:
Each row below the conditions and actions represents a
unique combination of conditions (a "rule") and specifies the
corresponding expected action for that scenario.
Importance of Design Tables:
 Comprehensive Test Coverage:
By systematically listing all possible combinations of
conditions, design tables help ensure that all potential
scenarios are tested, reducing the risk of missing edge
cases.
 Clear Test Case Design:
The tabular format makes it easy to visualize and understand
the relationships between input conditions and expected
outcomes, facilitating clear test case creation.
 Identifying Logical Errors:
When reviewing the rules in a design table, testers can readily
identify potential inconsistencies or illogical behaviors in the
system's logic.
 Documentation and Communication:
Design tables act as valuable documentation for both testers
and developers, clearly outlining the expected behavior under
different conditions.
Example Scenario:
Imagine testing a discount calculation feature on an online
store.
 Conditions:
o Customer is a member (True/False)
o Order total exceeds $50 (True/False)
o Current promotion active (True/False)
 Actions:
o Apply 10% discount
o Apply 15% discount
o Apply no discount
 Rules:
o Rule 1: (Member = True, Total > $50, Promotion =
True) - Apply 15% discount
o Rule 2: (Member = True, Total > $50, Promotion =
False) - Apply 10% discount
o Rule 3: (Member = False, Total > $50, Promotion =
True) - Apply 10% discount
Key Points:
 Design tables are particularly useful when testing
complex business rules with multiple conditions and
interactions.
 While creating a design table, it's important to identify all
relevant conditions and ensure that all possible
combinations are considered.
  Design tables can be used in conjunction with other
testing techniques like equivalence partitioning and
boundary value analysis to further enhance test
coverage.
1. Condition Stubs : The conditions are listed in this first
upper left part of the decision table that is used to
determine a particular action or set of actions.
2. Action Stubs : All the possible actions are given in the
first lower left portion (i.e, below condition stub) of the
decision table.
3. Condition Entries : In the condition entry, the values are
inputted in the upper right portion of the decision table. In
the condition entries part of the table, there are multiple
rows and columns which are known as Rule.
4. Action Entries : In the action entry, every entry has
some associated action or set of actions in the lower
right portion of the decision table and these values are
called outputs.
Types of Decision Tables :
The decision tables are categorized into two types and these
are given below:
1. Limited Entry : In the limited entry decision tables, the
condition entries are restricted to binary values.
2. Extended Entry : In the extended entry decision table,
the condition entries have more than two values. The
decision tables use multiple conditions where a condition
 may have many possibilities instead of only ‘true’ and
‘false’ are known as extended entry decision tables.
Applicability of Decision Tables :
 The order of rule evaluation has no effect on the
resulting action.
 The decision tables can be applied easily at the unit level
only.
 Once a rule is satisfied and the action selected, n
another rule needs to be examined.
 The restrictions do not eliminate many applications.
Example: https://www.guru99.com/decision-table-testing.html
5. Describe briefly the Flow/Graphs and Path testing.
Ans: Flow graphs and path testing are techniques used in
software engineering to analyze and test programs:
 Flow graphs
A pictorial representation of a program's structure, similar to a
topographic map. Flow graphs focus on a program's control
flow, and don't show the details of what's inside a process
block.
 Path testing
A family of test techniques that involve selecting a set of test
paths through a program. The basis path testing method is a
white box technique that analyzes a program's control flow
graph to find linearly independent paths of execution.
 Control flow graphs
A graphical representation of a program's control
structure. Control flow graphs can be used to clarify control
flow and data flow issues.
## Flow Graphs and Path Testing

Flow graphs and path testing are essential concepts in

software testing, particularly in the realm of white-box testing.
They focus on the internal structure of the code to ensure that
all possible execution paths are examined.

****Flow Graphs****

A **flow graph** is a visual representation of a program's

control flow, illustrating how control moves between various
statements and decision points. Each node in the graph
represents a block of code or a decision point, while edges
represent the flow of control between these nodes. This
graphical representation helps testers identify all possible
paths through the code, which is crucial for thorough testing.

Key characteristics of flow graphs include:

- **Nodes**: Represent executable statements or blocks of

code.
- **Edges**: Indicate the flow of control from one node to
another.
- **Decision Points**: Highlight where the program can take
different paths based on conditions (e.g., if-else statements).

The creation of a flow graph involves translating the source

code into its graphical form, allowing testers to visualize and
analyze the program's execution paths effectively.

****Path Testing****

**Path testing** is a technique used to design test cases

based on the control flow graph. It focuses on identifying and
executing all possible paths through the program to ensure
that each path behaves as expected. The primary goal is to
achieve comprehensive test coverage by ensuring that every
line of code is executed at least once during testing.

### Process of Path Testing

1. **Create Control Flow Graph**: Develop a flow graph from

the source code to visualize all executable paths.

2. **Calculate Cyclomatic Complexity**: Use McCabe’s

Cyclomatic Complexity formula:
$$
V(G) = E - N + 2P
 $$
where $$E$$ is the number of edges, $$N$$ is the number
of nodes, and $$P$$ is the number of connected
components. This metric helps determine the number of
linearly independent paths in the program.

3. **Identify Independent Paths**: Generate a set of

independent paths based on the flow graph. Each
independent path represents a unique execution route
through the program.

4. **Create Test Cases**: Develop test cases for each

identified path to ensure that all scenarios are tested.
**Advantages**:

- Ensures thorough testing by covering multiple execution

paths.
- Helps identify logical errors and edge cases.
- Reduces redundancy in test cases by focusing on
independent paths.
**Disadvantages**:

- Requires a deep understanding of programming and code

structure.
- As code complexity increases, the number of test cases can
grow significantly, making it challenging to manage.
- Some paths may not cover all conditions if certain logical
branches are missed during path selection.

In summary, flow graphs and path testing are vital tools in

software testing that help ensure comprehensive coverage
and validation of software functionality by analyzing how
different parts of a program interact through various execution
paths.
6. Explain in detail about Logic Based Testing.
Ans: Logic-based testing is a software testing technique that
involves designing tests based on logical expressions in
software artifacts like source code, design models, and
requirements specifications. It can be used at various stages
of testing, including unit, integration, system, and acceptance
testing.
Here are some key aspects of logic-based testing:
 Boolean algebra
Boolean algebra is used to analyze consistency and
completeness, and can also be used as a basis for test
design.
 Decision tables
Decision tables can be used to specify the functional
requirements of programs. They can also be used to simplify
difficult choices by visually depicting the rules, circumstances,
and steps involved in making a decision.
 Path expressions
Path expressions are generated by path tracing, and then
converted into boolean algebra using the predicates' truth
values as weights.
 Structural and functional testing
Logic-based testing can be structural or functional depending
on whether it's applied to structure or a specification.
In logic-based testing we focus on the truth values of control
flow predicates. A predicate is implemented as a process
whose outcome is a truth-functional value. For our purpose,
logic-based testing is restricted to binary predicates.
Logic-based testers design tests from logical expressions that
appear in software artifacts such as source code, design
models, and requirements specifications.
7. Explain about Data Flow Testing strategies?
Ans: STRATEGIES OF DATA FLOW TESTING:
https://csestudyzone.blogspot.com/2015/06/strategies-in-
data-flow-testing-in.html Refer this if u can’t understand
what is below

 INTRODUCTION:
o Data Flow Testing Strategies are structural
strategies.
 o In contrast to the path-testing strategies, data-flow
strategies take into account what happens to data
objects on the links in addition to the raw
connectivity of the graph.
o In other words, data flow strategies require data-
flow link weights (d,k,u,c,p).
o Data Flow Testing Strategies are based on selecting
test path segments (also called sub paths) that
satisfy some characteristic of data flows for all data
objects.
o For example, all subpaths that contain a d (or u, k,
du, dk).
o A strategy X is stronger than another strategy Y if
all test cases produced under Y are included in
those produced under X - conversely for weaker.
 TERMINOLOGY:
1. 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).
2. Loop-Free Path Segment is a path segment for
which every node in it is visited atmost 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.
3. 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.
4. 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.
 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:
1. 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 subpaths
(1,3,4) and (1,3,5). The definition on link (4,5) is
covered by any path that includes (5,6), such as
subpath (1,3,4,5,6, ...). The (5,6) definition requires
paths that include subpaths (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 subpaths (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.
2. All Uses Startegy (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 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 subpaths (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) subpath.
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.
3. 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.
 4. All c-uses/some p-uses strategy (ACU+P) : The
all 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 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.
5. All Definitions Strategy (AD) : The all definitions
strategy asks only every definition of every variable
be covered by atleast 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.
 6. 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 all 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.
 ORDERING THE STRATEGIES:
o Figure 3.12 compares path-flow and data-flow
testing strategies. The arrows denote that the
strategy at the arrow's tail is stronger than the
strategy at the arrow's head.
 o The right-hand side of this graph, along the path
from "all paths" to "all statements" is the more
interesting hierarchy for practical applications.
o Note that although ACU+P is stronger than ACU,
both are incomparable to the predicate-biased
strategies. Note also that "all definitions" is not
comparable to ACU or APU.
 SLICING AND DICING:
o A (static) program slice is a part of a program (e.g.,
a selected set of statements) defined with respect to
a given variable X (where X is a simple variable or a
data vector) and a statement i: it is the set of all
 statements that could (potentially, under static
analysis) affect the value of X at statement i - where
the influence of a faulty statement could result from
an improper computational use or predicate use of
some other variables at prior statements.
o If X is incorrect at statement i, it follows that the bug
must be in the program slice for X with respect to i
o A program dice is a part of a slice in which all
statements which are known to be correct have
been removed.
o In other words, a dice is obtained from a slice by
incorporating information obtained through testing
or experiment (e.g., debugging).
o The debugger first limits her scope to those prior
statements that could have caused the faulty value
at statement i (the slice) and then eliminates from
further consideration those statements that testing
has shown to be correct.
o Debugging can be modeled as an iterative
procedure in which slices are further refined by
dicing, where the dicing information is obtained from
ad hoc tests aimed primarily at eliminating
possibilities. Debugging ends when the dice has
been reduced to the one faulty statement.
o Dynamic slicing is a refinement of static slicing in
which only statements on achievable paths to the
statement in question are included.
8. Write a note on a) Linguistic Metrics b) Path products c)
Path Expressions with examples?
Ans: A) Linguistic Metrics:
Linguistic metrics are quantitative measures used to analyze
and compare textual data based on linguistic features,
providing insights into the complexity, readability, and style of
a text. They are often employed in fields like natural language
processing, computational linguistics, and text analysis.
Key aspects of linguistic metrics:
 Lexical diversity:
Measures the variety of words used in a text, usually
calculated by dividing the number of unique words by the total
number of words.
 Example: A text with a high lexical diversity uses a
wide range of vocabulary, while a text with low
diversity may repeat the same words frequently.
 Vocabulary richness:
Similar to lexical diversity, but often takes into account the
frequency distribution of words.
 Average sentence length:
Measures the average number of words per sentence in a
text.
 Type-token ratio:
The ratio of unique words (types) to the total number of words
(tokens) in a text.
 Readability scores:
Metrics designed to estimate the reading level of a text, like
Flesch-Kincaid grade level or Gunning Fog Index, which
consider factors like sentence length and complexity of
vocabulary.
Applications of linguistic metrics:
 Text analysis:
Assessing the complexity of academic writing, analyzing
author style, identifying potential plagiarism.
 Machine translation evaluation:
Measuring the quality of translated text by comparing its
linguistic features to the source text.
 Education research:
Evaluating the readability of educational materials for different
age groups.
b) Path Products:
In software testing, a "path product" refers to the combination
of all possible execution paths through a program's control
flow graph, representing all potential sequences of program
statements that could be executed under different input
conditions.
Key points about path products:
 Control flow graph:
A graphical representation of a program's logic, where nodes
represent program statements and edges represent
transitions between them.
  Path:
A sequence of connected edges in a control flow graph,
representing a possible execution path through the program.
 Path product calculation:
By combining all possible paths through a control flow graph
using mathematical operations like concatenation and union,
you can generate a "path product" which represents all
potential execution sequences.
 Use in testing:
Analyzing the path product helps identify critical execution
paths that should be covered by test cases to ensure
thorough testing.
Example:
Consider a simple program with three statements: A, B, and
C, where B is an if-statement that can either lead to statement
D or E depending on a condition. The path product would be:
(A, B, D) U (A, B, E), representing all possible execution
sequences.
c) Path Expressions:
A "path expression" is a sequence of steps used to navigate
through a hierarchical data structure, such as an XML
document or a database schema, to access specific data
elements.
Key points about path expressions:
 Syntax:
Path expressions typically use a syntax like
"parent/child/grandchild" to specify the relationships between
nodes.
 Operators:
 Child operator (/): Navigates to a direct child
element
 Descendant operator (//): Navigates to any
descendant element
 Attribute operator (@): Accesses an attribute of an
element
 Predicate ([]): Filters results based on specific
conditions
Example:
 XPath expression: "bookstore/book[price </title"
o Explanation: This expression selects the "title"
element from all "book" elements within the
"bookstore" node where the "price" attribute is less
than 20.
Applications of Path Expressions:
 XML data extraction: Extracting specific data from an
XML document using XPath queries
 Database querying: Accessing related data in a relational
database using path-like navigation
 Web scraping: Retrieving information from web pages by
navigating through HTML structure using path
expressions.
(OR)
In software testing, "linguistic metrics" refer to measurements
based on the language used in code, "path products" are a
way to represent possible execution paths through a program
using a string of symbols, and "path expressions" are a
notation to describe these paths using algebraic expressions,
all used to analyze code complexity and design effective test
cases.
a) Linguistic Metrics:
 Definition:
Linguistic metrics quantify aspects of a code's readability and
maintainability by analyzing its syntax, vocabulary, and
structure.
 Examples:
 Code Complexity: Measures like cyclomatic
complexity (number of decision points in a function)
indicate how intricate the logic is.
 Vocabulary Size: The number of unique words used
in comments and code can reflect the clarity of
expression.
 Halstead Complexity: A metric based on the number
of operators and operands in a code snippet,
indicating potential complexity.
 Application in Testing:
High linguistic complexity can indicate areas where bugs are
more likely to occur, prompting testers to focus on those parts
of the code with more intricate logic.
b) Path Products:
 Definition:
A path product is a string of symbols representing a sequence
of execution steps through a program's control flow graph,
where each symbol corresponds to a decision point or a code
block.
 How to Calculate:
 Represent the program as a flow graph where
nodes are code blocks and edges are transitions
between them.
 Assign a unique label to each edge.
 A path product is formed by concatenating the
labels of edges traversed along a specific path
through the graph.
 Example:
 Consider a simple flow with decisions "A" and "B":
 Path 1: A -> B -> C (path product: "ABC")
 Path 2: A -> D -> E (path product: "ADE")
 Application in Testing:
Path products are used to identify all possible execution paths
in a program, which are then used to design comprehensive
test cases covering all potential scenarios.
c) Path Expressions:
 Definition:
A path expression is a mathematical notation used to
represent complex combinations of path products, often using
operators like concatenation, union, and repetition to describe
sets of possible paths.
 Example:
 Consider a loop with condition "C":
 Path expression: "A*(BC)*D"
 Interpretation: Execute "A" once, followed by
zero or more iterations of "B" and "C", then
execute "D".
 Application in Testing:
Path expressions are used to systematically generate test
cases by exploring all possible combinations of paths within a
program, especially when dealing with loops and complex
decision structures.
Key Points:
 Linguistic metrics provide insights into code readability,
while path products and expressions help testers
analyze program execution flow to design effective test
cases.
 By combining these techniques, testers can identify
areas of potential complexity in the code and create test
suites that thoroughly cover all possible execution paths.
  The complexity of the code directly impacts the number
of possible paths, and therefore the effort needed to
design comprehensive test cases.
9. Explain in detail about State Transition Graph?
Ans: A state transition graph (STG) is a directed graph that
models the behavior of a system by showing its possible
states and how it transitions between them. STGs are made
up of nodes and arcs, with each node representing a state
and each arc representing a transition:
 Nodes
Represent states, which are conditions that an object can be
in. Nodes can optionally display the functions related to them,
such as entry, exit, and do (root) functions.
 Arcs
Represent transitions, which are changes in state that occur
when an event is triggered. Arcs are labeled with the name of
the event that causes the transition.
STGs are useful for modeling objects with a finite number of
states and how they interact with the outside world. They can
be used in a variety of applications, including:
 Object-oriented modeling: To represent the life cycle of
an object
 Finite state recognizer: To describe regular expressions
used in computer languages
  Traffic light systems: To represent the different
combinations of red, green, and yellow lights that make
up a system state

https://www.geeksforgeeks.org/state-transition-testing/