Unit II

Equivalence Class Testing

• input data is divided into partitions of valid and invalid
values,
• The use of equivalence classes as the basis for functional testing has
two motivations: we would like to have a sense of complete testing,
and, at the same time, we would have to avoid redundancy.
Examples
of
Equivalen
ce
Partitioni
ng
technique
Examples
of
Equivalen
ce
Partitioni
ng
technique
How we perform equivalence
partitioning
Pressman Method
General Practice method
• In the below image, the
pressman technique is enough to
test for an age text field for one
valid and two invalids. But, if we
have the condition for insurance
of ten years and above are
required and multiple policies for
various age groups in the age text
field, then we need to use the
practice method.
Traditional equivalence class testing
• Traditional equivalence class testing echoes the process of boundary
value testing.
• The below diagram shows test cases for a function F of two variables
x1 and x2,
• The extension to more realistic cases of n variables proceeds as
follows:
• 1. Test F for valid values of all variables.
• 2. If step 1 is successful, then test F for invalid values of x1 with valid values of
the remaining variables.
• 3. Any failure will be due to a problem with an invalid value of x1 ,repeat step
2 for the remaining variables.
Traditional equivalence class test
cases
Improved Equivalence Class Testing
• The key (and the craft!) of equivalence class testing is the choice of
the equivalence relation that determines the classes.
• Very often, we make this choice by second-guessing the likely
implementation and thinking about the functional manipulations that
must somehow be present in the implementation.
• Take a function, F, of two variables x1 and x2. When F is implemented
as a program, the input variables x1 and x2 will have the following
boundaries, and intervals within the boundaries:
• where square brackets and parentheses denote, respectively, closed
and open interval endpoints.
• The intervals presumably correspond to some distinction in the
program being tested, for example, the commission ranges in the
commission problem.
Weak Normal Equivalence Class
Testing
• Definition:
Weak Normal Equivalence Class Testing is a black-box testing
technique used in software testing to divide input data into
equivalence classes. This method ensures that test cases are selected
from valid input ranges while covering different classes of data
without redundancy.
• Key Characteristics:
• Focuses on Valid Input:
• Tests only valid equivalence classes.
• No invalid test cases are considered.
•Partitioning Input Domains:
•The input domain is divided into mutually exclusive equivalence classes.
•A single representative value from each class is tested.

•Reduces Test Cases:

•Instead of testing all possible values, it selects one value per class.
•Helps minimize test cases while ensuring maximum coverage.
• Example of Weak Normal Equivalence Class Testing:
• Consider a system that accepts ages between 18 and 60 (both
inclusive).
• Equivalence Classes:
• Valid Equivalence Class: 18 to 60 → Pick one value (e.g., 30)
• Invalid Equivalence Classes: Below 18 and Above 60 (ignored in weak normal
testing)
• Thus, a single test case from 18-60 is sufficient in this approach.
Feature Weak Normal EC Testing Strong Normal EC Testing
Selects multiple values per valid
Test Cases Selects one value per valid class
class
Invalid Values Not considered Not considered
Pick multiple values (e.g., 20, 40,
Example for (18-60) Age Range Pick one value (e.g., 30)
55)
Weak Normal Equivalence Class
Testing
• Weak normal equivalence class testing is accomplished by using one
variable from each equivalence class (interval) in a test case.
Strong Normal Equivalence Class
Testing
Strong Robust Equivalence Class
Testing
• As before, the robust part comes from consideration of invalid values,
and the strong part refers to the multiple fault assumption.
• We obtain test cases from each element of the Cartesian product of all
the equivalence classes, both valid and invalid,
• In mathematics, the Cartesian Product of sets A and B is defined as the
set of all ordered pairs (x, y) such that x belongs to A and y belongs to
B. For example, if A = {1, 2} and B = {3, 4, 5}, then the Cartesian
Product of A and B is {(1, 3), (1, 4), (1, 5), (2, 3), (2, 4), (2, 5)}.
Equivalence Class Test Cases for the
Triangle Problem
• In the problem statement, we note that four possible outputs can
occur: NotATriangle, Scalene, Isosceles, and Equilateral. We can use
these to identify output (range) equivalence classes as follows.
• Four weak normal equivalence class test cases, chosen arbitrarily
from each class are as follows:
• Because no valid subintervals of variables a, b, and c exist, the strong
normal equivalence class test cases are identical to the weak normal
equivalence class test cases.
• Considering the invalid values for a, b, and c yields the following
additional weak robust equivalence class test cases. (The invalid
values could be zero, any negative number, or any number greater
than 200.)
Equivalence Class Test Cases for the
NextDate Function
• The NextDate function illustrates very well the craft of choosing the
underlying equivalence relation.
• Recall that NextDate is a function of three variables: month, day, and
year, and these have intervals of valid values defined as follows:
• Here is the full set of weak robust test cases:
Equivalence Class Test Cases
• These classes yield the following weak normal equivalence class test
cases. As before, the inputs are mechanically selected from the
approximate middle of the corresponding class
Types of Equivalence Class Testing
• 1.Weak Normal Equivalence Class Testing (Weak Normal ECT)
• 📌 Definition:
• Each input variable is tested using one value from each valid
equivalence class, but independently (i.e., variables are not
combined).
• Key Points:
✔ Tests only valid inputs
✔ Each test case considers only one variable at a time, keeping
others fixed
• Example: If a banking system accepts balances between $100 and
$10,000, valid equivalence classes are:
• Low Valid: $100
• Mid Valid: $5,000
• High Valid: $10,000

• 2. Strong Normal Equivalence Class Testing (Strong Normal ECT)

• 📌 Definition:
• All possible valid combinations of equivalence classes from multiple
input variables are tested.
• 3. Weak Robust Equivalence Class Testing (Weak Robust ECT)
• 📌 Definition:
• Tests both valid and invalid equivalence classes, but one variable at a
time (other variables are kept fixed).
• 4. Strong Robust Equivalence Class Testing (Strong Robust ECT)
• 📌 Definition:
• Tests all possible valid and invalid combinations of multiple input
variables.
• Weak Normal Equivalence Class Testing for Banking Application (Interest
Calculation on Savings Account Balance & Interest Rate)
• Test Scenario:
• A banking application calculates interest based on savings account balance
and interest rate.
• Assumptions & Constraints:
• Savings Account Balance Range: $100 to $1,000,000
• Interest Rate Range: 1% to 10%
• Equivalence Class Partitions (Valid Only - Weak Normal Testing)
• Since Weak Normal Equivalence Class Testing considers only valid input
values (ignoring invalid cases), we create partitions where both values are
within valid ranges.
• Strong Normal Equivalence Class Testing for Banking Application (Interest
Calculation on Savings Account Balance and Interest Rate)
• Assumptions & Constraints:
• Balance Range:
• Minimum balance: $100
• Maximum balance: $1,000,000
• Interest Rate Range:
• Minimum interest rate: 1%
• Maximum interest rate: 10%
• Equivalence Classes for Balance and Interest Rate
• Since Strong Normal Equivalence Class Testing requires us to test all valid
combinations of equivalence classes for multiple input variables, we define:
• Balance Equivalence Classes:
• Low valid balance: $100
• Medium valid balance: $500,000
• High valid balance: $1,000,000
• Interest Rate Equivalence Classes:
• Low valid interest rate: 1%
• Medium valid interest rate: 5%
• High valid interest rate: 10%
• In Weak Robust Equivalence Class Testing, we consider both valid and invalid
equivalence classes, including boundary values and out-of-range inputs.
Given that the minimum transaction amount allowed is 50 and the
maximum transaction amount allowed is 500,000, we define equivalence
classes as follows:
• Equivalence Classes
• Valid Equivalence Class (Within Range):
• 50 ≤ Amount ≤ 500,000
• Example values: 50, 100,000, 500,000
• Invalid Equivalence Class (Below Minimum):
• Amount < 50
• Example values: 0, 10, 49
•Invalid Equivalence Class (Above Maximum):
•Amount > 500,000
•Example values: 500,001, 1,000,000

•Invalid Equivalence Class (Non-Numeric / Special Cases):

•Negative values: -1, -50
•Zero: 0
•Non-numeric: "ABC", "", null
• Strong Robust Equivalence Class Testing – Online Payment Transaction
Amount Validation
• In String Robust Equivalence Class Testing, we consider both valid and
invalid equivalence classes, including unexpected input types (such as
strings, special characters, or mixed inputs) in addition to numeric boundary
values.
• Given Constraints:
• Minimum transaction amount: 50
• Maximum transaction amount: 500,000
• Equivalence Class Partitions (Including Robust Cases)
• In Strong Robust Equivalence Class Testing, we consider all possible valid
and invalid partitions, including boundary values and out-of-range cases.
• 1. Valid Equivalence Classes (Within Range)
• Valid Minimum: 50
• Valid Mid-Range: 100,000
• Valid Maximum: 500,000
• Invalid Equivalence Classes (Out of Range)
• Below Minimum:
• Just below minimum (49)
• Well below minimum (10)
• Zero (0)
• Negative values (-50, -1)
• Above Maximum:
• Just above maximum (500,001)
• Well above maximum (1,000,000)
• Invalid Data Types & Special Cases
• Non-Numeric Inputs:
• Alphabets ("ABC")
• Special characters ("$100")
• Empty string ("")
• Null (null)
Decision Table Based Testing in
Software Testing
• Decision tables are used in various engineering fields to represent
complex logical relationships.
• This testing is a very effective tool in testing the software and its
requirements management.
• The output may be dependent on many input conditions and decision
tables give a tabular view of various combinations of input conditions
and these conditions are in the form of True(T) and False(F).
Parts/Components of Decision Tables
• 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.
• Action Stubs : All the possible actions are given in the first lower left
portion (i.e, below condition stub) of the decision table.
• 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.
• 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.
• How to make a decision table for account registration
• The registration function of a website with the following requirements:
• Email and password are required information when registering.
• The conditions for registration is only if the email has never been
registered on this website before, and the password must be more than
8 characters.
• Possible conditions are:
• Email is valid (correct email format, email cannot be empty)
• Email has not been registered
• Password length must be 8 characters or more
• Possible actions are:
• Be able to register, navigate to homepage
• Unable to register, an error message will be shown
• Checking the created decision table above again, we see that rules 3 and
4 can be combined into 1 rule because "Password has 8 characters or
more" or not does not affect the result.
• If “Email is valid” and “Email has not been registered”,
the output will be “Unable to register, an error message will be shown”.
• Similarly, we can combine rules 5,6,7,8 into 1 rule.
Types of Decision Tables
• Limited Entry : In the limited entry decision tables, the condition
entries are restricted to binary values.
• 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.
• Decision Table with "Don't Care" Entries in Software Testing
• "Don't Care" Entries (Denoted as ‘-’) are used in Decision Table Testing when a
specific condition does not affect the outcome. This helps reduce redundant test
cases while improving efficiency.
• Example: Subscription Activation with “Don't Care” Entries
• An online platform determines whether to activate a subscription based on the
following conditions:
• Conditions (Inputs):
• User Age ≥ 18? (Users must be at least 18 years old)
• Payment Successful? (Subscription is only activated if payment is made)
• Promo Code Applied? (A promo code can be used, but it does not affect
activation)
• Actions (Outputs):
• Activate Subscription
• Reject Subscription
• Mutually Exclusive Conditions in Decision Table Testing
• Mutually Exclusive Conditions in a Decision Table are conditions where
only one can be true at a time, meaning they cannot occur
simultaneously. These conditions represent scenarios where selecting
one option automatically excludes the others.
• Example: Payment Method Selection for Online Transactions
• A user can choose only one payment method to complete a transaction.
The system supports:
• Credit Card
• Debit Card
• PayPal
• These conditions are mutually exclusive because a user cannot select
more than one payment method at the same time.
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, then another rule
needs to be examined.
• The restrictions do not eliminate many applications.
Portions of a Decision Table
Decision Table for Triangle Problem
Structural Testing
• Structural testing, which is used to test the internal
design of the software or structure of the coding for the
particular software.
• In this testing, the development team members are
included in the testing team to execute the software's
internal design.
Types of Structural Testing
Mutation Testing
• Mutation testing is a white box method in software testing where we insert
errors purposely into a program (under test) to verify whether the existing
test case can detect the error or not.
• In this testing, the mutant of the program is created by making some
modifications to the original program.
• The mutation is a small modification in a program; these
minor modifications are planned to typical low-level errors
which are happened at the time of coding process.
• Generally, we deliberate the mutation operators in the form
of rules which match the data and also generate some
efficient environment to produce the mutant.
Types of mutation testing
• Mutation testing can be classified into three parts,
which are as follows:
• Decision mutations
• value mutations
• Statement mutations
How to perform mutation testing
• Data Flow Testing in Software Testing
• What is Data Flow Testing?
• Data Flow Testing is a white-box testing technique that focuses on how
data is defined, used, and moved through a program. It helps detect issues
related to variable initialization, incorrect usage, and improper data flow
in a program’s execution.
• Key Concepts in Data Flow Testing
• Definition (def): A variable is assigned a value.
• Usage (use): A variable is used in an operation or a decision-making
statement.
• Kill: A variable goes out of scope or is no longer used.
• int x; // x is declared but not initialized (potential issue)
• x = 10; // x is defined (def)
• y = x + 5; // x is used (use)

• If x was used before it was initialized, this would be a data flow error.

• Types of Data Flow Anomalies Detected

• 🔹 Uninitialized Variables → Using a variable before it is assigned a value.
🔹 Unused Variables → Declaring a variable but never using it.
🔹 Re-initialization Without Use → Assigning a value to a variable but never
using it before reassignment.
• Data Flow Testing Strategies
1
• 1️⃣ Definition-Use (DU) Chains
• Tracks variables from their definition (assignment) to their usage.
• Helps find uninitialized variables and unnecessary reassignments.
• 2️⃣ All-Defs Coverage
• Ensures that every defined variable is used at least once.
• 3️⃣ All-Uses Coverage
• Ensures that every variable use is covered in testing.
• All DU-Paths Coverage
• Ensures every possible path from a variable’s definition to its use is tested.
• Most comprehensive but expensive in terms of test effort.
• void calculate(int a, int b) {
• int sum, product; // sum is declared but not initialized
• product = a * b; // product is defined
• printf("%d", sum); // ERROR: sum is used before assignment
•}
• Data Flow Issues:
• ✅ sum is declared but not defined before use → Error
• ✅ product is defined but never used → Potential issue
• Advantages of Data Flow Testing
• ✔ Detects data anomalies early in development.
✔ Ensures variables are properly initialized and used.
✔ Improves program efficiency by identifying redundant variables.

• Disadvantages of Data Flow Testing

• ❌ Can be complex for large programs with multiple variables.
❌ Requires detailed code analysis, increasing test effort.

• Conclusion
• Data Flow Testing is a powerful technique to analyze how data moves
within a program, ensuring proper variable usage and eliminating bugs
caused by incorrect data handling. It is especially useful for critical
applications like banking, healthcare, and embedded systems.
• Commission Problem Using Define-Use (DU) Testing
• Commission Problem Statement
• A company calculates the sales commission for its employees based on the
following rules:
• If sales amount is less than $1000, commission is 5%.
• If sales amount is between $1000 and $5000, commission is 10%.
• If sales amount is greater than $5000, commission is 20%.
Advantages of Data Flow Testing
• To find a variable that is used but never defined,
• To find a variable that is defined but never used,
• To find a variable that is defined multiple times before it is use,
• Deallocating a variable before it is used.
Disadvantages of Data Flow Testing
• Time consuming and costly process
• Requires knowledge of programming languages
• Slice-Based Testing in Software Testing
• What is Slice-Based Testing?
• Slice-Based Testing is a white-box testing technique that focuses on
analyzing program slices to detect errors. A program slice is a subset of the
program that affects the value of a particular variable at a specific point in
execution.
• Example: Slice-Based Testing in a Commission Calculation Program
Control Flow Testing
• Control flow testing is a testing technique that comes
under white box testing.
• The aim of this technique is to determine the execution
order of statements or instructions of the program
through a control structure.
• Control Flow Graph is formed from the node, edge,
decision node, junction node to specify all possible
execution path.
Notations used for Control Flow
Graph
• Nodes in the control flow graph are used to create a
path of procedures. Basically, it represents the
sequence of procedures which procedure is next to
come so, the tester can determine the sequence of
occurrence of procedures.
• Edge in control flow graph is used to link the direction
of nodes.
• Decision node in the control flow graph is used to
decide next node of procedure as per the value.
• Junction node in control flow graph is the point where
at least three links meet.
Example
Slice-based testing
• Slicing or program slicing is a technique used in software
testing that takes a slice or a group of program statements
in the program for testing particular test conditions or cases
that may affect a value at a particular point of interest.

• It can also be used to debug to find the bugs more easily and quickly.
• Slicing techniques were originally defined by Mark Weiser and they were
only static at that time.
• Afterward, Bogdan Korel and Janusz Laski introduced dynamic slicing, which
can work for a particular execution of the program.
Types
• Static Slicing
• A static slice of a program contains all statements that may impact the value
of a variable at any point for any arbitrary execution of the program.
• Static slices are generally larger.
• It considers every possible execution of the program.

• Dynamic Slicing
• A dynamic slice of a program contains all the statements that actually impact
the value of a variable at any point for a particular execution of the program.
• Dynamic slices are mostly smaller.
• Considers only a particular execution of the program.
Example
Example
Program Slicing Tools
Test method pendulum
Effort and
efficacy of
unit test
methods