Module -4

Input Space Partitioning (ISP) in black-box testing is a test design technique where the entire
range of possible inputs to a program is divided into smaller groups (partitions or classes).
Each partition contains inputs that are expected to be processed in the same way by the system.
Instead of testing every possible input, you select representative values from each partition.

Key Idea

If one value in a partition works (or fails), all values in that partition are likely to behave the
same way. So testing one or a few values from each partition is enough.

Steps in Input Space Partitioning

1. Identify input parameters of the program.
2. Determine possible ranges or categories for each input.
3. Divide the input space into partitions (valid and invalid).
4. Select representative test cases from each partition.

Example
Suppose a system accepts age values from 18 to 60.

Possible partitions:

Partition Type Input Range Example Test Case

Invalid Age < 18 15
Valid 18 ≤ Age ≤ 60 30
Invalid Age > 60 65

Instead of testing every age from 0–100, we test a few representative values like 15, 30, and 65.

Types of Partitions
1. Valid partitions – Inputs that should be accepted.
2. Invalid partitions – Inputs that should be rejected or handled with errors.
Advantages
 Reduces number of test cases
 Improves test coverage efficiently
 Helps detect input validation errors
 Systematic way to design test cases

Related Techniques
Input Space Partitioning is closely related to:

 Equivalence Partitioning
 Boundary Value Analysis
 Decision Table Testing

Input Domain Modeling (IDM) is a black-box test design technique used to systematically
identify and organize the input conditions of a program and then generate effective test cases
from them.

It focuses on analyzing the program’s input domain (all possible inputs) and modeling it so
testers can choose representative test cases that cover important scenarios.

Definition
Input Domain Modeling is the process of identifying input variables, their possible values,
and the relationships between them, and then dividing the input space into subdomains from
which test cases are selected.

Steps in Input Domain Modeling

1. Identify input parameters
Determine all inputs the program accepts.
2. Identify the input domain
Determine possible values for each input.
3. Model the input domain
Represent inputs and their constraints using partitions or conditions.
 4. Divide the domain into subdomains
Create groups of inputs that behave similarly.
5. Select test cases
Choose representative inputs from each subdomain.

Example
Consider a login system with inputs:

 Username
 Password

Possible input domain model:

Condition Username Password

Valid login Correct Correct
Invalid username Incorrect Correct
Invalid password Correct Incorrect
Both invalid Incorrect Incorrect

Test cases are selected from each condition.

Types of Input Domain Models

1. Interface-based models
Derived from program input parameters.
2. Functionality-based models
Based on system behavior or requirements.

Benefits
 Helps systematically design test cases
 Ensures better coverage of input combinations
 Reduces redundant tests
 Detects input validation issues

Input Space Partitioning (ISP) in black-box testing is a test design technique where the entire
range of possible inputs to a program is divided into smaller groups (partitions or classes).
Each partition contains inputs that are expected to be processed in the same way by the system.
Instead of testing every possible input, you select representative values from each partition.

Key Idea

If one value in a partition works (or fails), all values in that partition are likely to behave the
same way. So testing one or a few values from each partition is enough.

Steps in Input Space Partitioning

1. Identify input parameters of the program.
2. Determine possible ranges or categories for each input.
3. Divide the input space into partitions (valid and invalid).
4. Select representative test cases from each partition.

Example
Suppose a system accepts age values from 18 to 60.

Possible partitions:

Partition Type Input Range Example Test Case

Invalid Age < 18 15
Valid 18 ≤ Age ≤ 60 30
Invalid Age > 60 65

Instead of testing every age from 0–100, we test a few representative values like 15, 30, and 65.

Types of Partitions
1. Valid partitions – Inputs that should be accepted.
2. Invalid partitions – Inputs that should be rejected or handled with errors.

Advantages
 Reduces number of test cases
  Improves test coverage efficiently
 Helps detect input validation errors
 Systematic way to design test cases

Related Techniques
Input Space Partitioning is closely related to:

 Equivalence Partitioning
 Boundary Value Analysis
 Decision Table Testing

Functionality-Based Approach is a black-box testing technique in Input Domain Modeling

where test cases are designed based on the functions or behavior of the system described in
the requirements or specifications, rather than just the input parameters.

The tester studies what the system is supposed to do and creates test cases to verify whether the
functionality works correctly.

Definition
Functionality-Based Approach is a method in black-box testing where the input domain is
modeled according to the system’s functional requirements, and test cases are designed to
verify each function.

Steps in Functionality-Based Approach

1. Study system requirements or specifications
2. Identify system functions
3. Determine input conditions for each function
4. Partition the input domain based on functionality
5. Design test cases to cover each functional scenario

Example
Consider an ATM withdrawal function.
Functional requirements:

 User enters PIN

 Selects withdrawal amount
 System checks account balance

Possible test scenarios

Scenario Description
Valid transaction Correct PIN + sufficient balance
Invalid PIN Wrong PIN entered
Insufficient balance Amount greater than account balance
Exceed daily limit Withdrawal beyond daily limit

Each scenario represents a functional partition, and test cases are created for them.

Characteristics
 Based on system behavior and requirements
 Focuses on what the system should do
 Covers functional scenarios

Advantages
 Ensures all system functions are tested
 Helps identify missing or incorrect functionality
 Works well for requirement-based testing

Difference from Interface-Based Approach

Aspect Interface-Based Functionality-Based
Focus Input parameters System behavior
Source Interface description Functional requirements
Testing Input validation Functional scenarios

Identifying Values in software testing (black-box testing) refers to the process of selecting
specific input values from each partition of the input domain to create effective test cases.
After dividing inputs using techniques like Input Space Partitioning or Input Domain
Modeling, testers must choose representative values to test the system.

Definition
Identifying values is the process of selecting specific test inputs from each input partition to
verify whether the software behaves correctly.

Steps in Identifying Values

1. Divide the input domain into partitions
Group inputs that behave similarly.
2. Select representative values
Choose one or more values from each partition.
3. Include boundary values
Test values at the edges of partitions where errors are common.
4. Create test cases
Use the selected values to design test scenarios.

Example
Suppose a system accepts marks from 0 to 100.

Input partitions

Partition Range
Invalid Marks < 0
Valid 0 – 100
Invalid Marks > 100

Identified values

Partition Example Values

Marks < 0 -5
0 – 100 50
Marks > 100 120

Here, -5, 50, and 120 are the identified test values.
Types of Values Often Selected
1. Typical values – Normal values within the partition
2. Boundary values – Values at the limits of the range
3. Invalid values – Values outside the valid range
4. Special values – Empty, null, or extreme inputs

Importance
 Ensures proper test coverage
 Helps detect edge-case errors
 Reduces number of unnecessary tests
 Improves test effectiveness

All Combinations Coverage in software testing is a test design strategy where test cases are
created to cover every possible combination of input values for all input parameters.

It ensures that the software is tested for every possible interaction between input variables.

Definition
All Combinations Coverage is a testing technique in which every possible combination of
input parameter values is tested at least once.

How it Works
1. Identify input parameters.
2. Determine possible values for each parameter.
3. Generate test cases that include all combinations of these values.

Example
Suppose a system has two inputs:
  Browser: Chrome, Firefox
 Operating System: Windows, Linux

Possible combinations

Test Case Browser OS

TC1 Chrome Windows
TC2 Chrome Linux
TC3 Firefox Windows
TC4 Firefox Linux

Here, all combinations of inputs are tested.

Formula
If there are:

 n parameters
 each with m possible values

Total test cases = product of all possible values

Example:
3 parameters with values (2, 3, 2)

Total combinations = 2 × 3 × 2 = 12 test cases

Advantages
 Provides maximum coverage
 Detects interaction faults between inputs
 Ensures thorough testing

Disadvantages
 Number of test cases grows rapidly with more inputs
 Can become time-consuming and expensive
When Used
 Systems with small number of input parameters
 Critical systems where complete coverage is required
 Configuration testing

Each Choice Coverage (often written as Each-Choice Coverage) is a black-box testing

technique used in input domain testing where every value of each input parameter is tested
at least once in some test case.

Unlike All Combinations Coverage, it does not test every combination. It only ensures that
each individual value appears in at least one test case.

Definition
Each Choice Coverage is a test coverage criterion in which every possible value for each
input parameter must appear in at least one test case.

Example
Suppose a system has two inputs:

 Browser: Chrome, Firefox, Edge

 Operating System: Windows, Linux

Possible test cases

Test Case Browser OS

TC1 Chrome Windows
TC2 Firefox Linux
TC3 Edge Windows

Coverage

 All browsers (Chrome, Firefox, Edge) appear at least once

 Both OS values (Windows, Linux) appear at least once

So Each Choice Coverage is satisfied.

Characteristics
 Ensures every input value is tested
 Reduces number of test cases
 Does not guarantee testing of all interactions

Advantages
 Simple and easy to apply
 Requires fewer test cases
 Provides basic input coverage

Limitation
 May miss interaction errors between inputs.

Comparison with All Combinations Coverage

Aspect Each Choice Coverage All Combinations Coverage
Test cases Few Very large
Coverage Each value once Every combination
Complexity Low High

Pairwise Coverage (also called 2-way testing) is a black-box testing technique where test
cases are designed so that every possible pair of input parameter values appears in at least
one test case.

The idea is that most software faults occur due to interactions between two parameters, so
testing all pairs provides good coverage while keeping the number of test cases manageable.

Definition
Pairwise Coverage is a testing technique in which all possible combinations of every pair of
input parameters are covered by the test cases.

Example
Suppose a system has three inputs:

 Browser: Chrome, Firefox

 Operating System: Windows, Linux
 Network: WiFi, Mobile Data

Example test cases

Test Case Browser OS Network

TC1 Chrome Windows WiFi
TC2 Chrome Linux Mobile Data
TC3 Firefox Windows Mobile Data
TC4 Firefox Linux WiFi

These test cases ensure that every pair of parameter values (Browser–OS, Browser–Network,
OS–Network) appears at least once.

Why Pairwise Testing is Used

Testing all combinations can produce too many test cases.
Pairwise testing reduces the number of tests while still covering important interactions.

Example:

 All combinations: 8 test cases

 Pairwise coverage: about 4 test cases

Advantages
 Reduces number of test cases
 Covers interaction between two parameters
 More efficient than all combinations coverage
Limitations
 May miss defects caused by interaction of three or more parameters
 Not suitable for very critical systems where full coverage is required

Comparison with Other Coverage Methods

Method Coverage Test Cases
Each Choice Every value once Very few
Pairwise Every pair of values Moderate
All Combinations Every possible combination Very many

T-wise Coverage (or t-way testing) in software testing is a generalization of pairwise testing
where test cases are designed so that every possible combination of any t input parameters
appears at least once in the test suite.

 When t = 1 → Each Choice Coverage

 When t = 2 → Pairwise Coverage
 When t = 3 → 3-wise Coverage
 When t = n (all parameters) → All Combinations Coverage

Definition
T-wise Coverage is a testing technique in which all combinations of values for any t
parameters are included in at least one test case.

Example
Suppose a system has three parameters:

 Browser: Chrome, Firefox

 Operating System: Windows, Linux
 Network: WiFi, Mobile Data

If t = 2 (pairwise)
Every pair of parameters must appear together in at least one test case.

If t = 3 (3-wise)

Every combination of three parameters must be tested.

Example test cases (3-wise):

Test Case Browser OS Network

TC1 Chrome Windows WiFi
TC2 Chrome Windows Mobile Data
TC3 Chrome Linux WiFi
TC4 Chrome Linux Mobile Data
TC5 Firefox Windows WiFi
TC6 Firefox Windows Mobile Data
TC7 Firefox Linux WiFi
TC8 Firefox Linux Mobile Data

Advantages
 Detects interaction faults among multiple parameters
 More thorough than pairwise testing
 Flexible depending on value of t

Limitations
 As t increases, number of test cases grows rapidly
 Higher time and cost

Relationship with Other Coverage Criteria

Coverage Type Value of t
Each Choice Coverage t=1
Pairwise Coverage t=2
3-wise Testing t=3
All Combinations Coverage t = number of parameters
Base Choice Coverage is a black-box testing technique used in input domain testing where
one base value (default or typical value) is selected for each input parameter, and test cases are
created by changing one parameter value at a time while keeping others at their base values.

This helps test the effect of changing one input while others remain constant.

Definition
Base Choice Coverage is a test coverage criterion in which a base value is chosen for each
input parameter, and test cases are generated by varying one parameter at a time while
keeping the others fixed at their base values.

Steps in Base Choice Coverage

1. Identify input parameters
2. Select a base value for each parameter
3. Create a base test case using all base values
4. Generate new test cases by changing one parameter value at a time

Example
Suppose a system has three inputs:

 Browser: Chrome, Firefox

 Operating System: Windows, Linux
 Network: WiFi, Mobile Data

Base values

 Browser → Chrome
 OS → Windows
 Network → WiFi

Test cases

Test Case Browser OS Network

TC1 (Base case) Chrome Windows WiFi
TC2 Firefox Windows WiFi
 Test Case Browser OS Network
TC3 Chrome Linux WiFi
TC4 Chrome Windows Mobile Data

Each test case changes only one parameter from the base value.

Advantages
 Requires few test cases
 Easy to design and understand
 Helps identify effect of individual input changes

Limitations
 Does not cover all parameter interactions
 May miss complex interaction faults

Comparison with Other Techniques

Technique Coverage
Each Choice Each value appears once
Pairwise Every pair of values
Base Choice One base case + vary one input
All Combinations Every possible combination

Multiple Base Choice Coverage is an extension of Base Choice Coverage in black-box

testing where instead of choosing a single base value for each input parameter, multiple base
values are selected. Test cases are then generated by varying one parameter at a time for each
base combination.

This approach increases coverage compared to the simple base choice method and is useful
when inputs have multiple representative values.

Definition
Multiple Base Choice Coverage is a test design technique in which more than one base value
is chosen for each input parameter, and test cases are created by varying one parameter at a
time while keeping the others fixed at one of their base values.

Steps
1. Identify input parameters
2. Select multiple base values for each parameter
3. Create all base combinations
4. Generate test cases by changing one parameter value at a time in each base combination

Example
Suppose a system has two inputs:

 Browser: Chrome, Firefox

 OS: Windows, Linux

Multiple base values:

 Browser → Chrome, Firefox

 OS → Windows, Linux

Base combinations:

1. Chrome + Windows
2. Chrome + Linux
3. Firefox + Windows
4. Firefox + Linux

Test cases (varying one parameter at a time for each base combination)

Test Case Browser OS

TC1 Chrome Windows
TC2 Firefox Windows
TC3 Chrome Linux
TC4 Firefox Linux

Here, each base combination is tested by changing one parameter at a time, giving better
coverage than single base choice.
Advantages
 More thorough coverage than single base choice
 Detects interaction faults missed by simple base choice
 Still smaller number of test cases than all combinations

Limitations
 Number of test cases increases with more base values
 May still miss some higher-order interactions

Comparison
Technique Coverage Test Case Size
Base Choice One base value per parameter Small
Multiple Base Choice Multiple base values per parameter Moderate
All Combinations Every possible value combination Large

Try-Typical Testing is a black-box testing technique where test cases are chosen using typical
or normal input values that a user would commonly provide, rather than boundary or extreme
values. It focuses on expected system behavior under normal conditions.

Example Scenario
System: A student grading system accepts marks from 0 to 100 and assigns grades:

 90–100 → A
 80–89 → B
 70–79 → C
 60–69 → D
 0–59 → F

Step 1: Identify input domain

 Marks: 0 to 100
Step 2: Choose typical values

 Instead of testing every value or boundaries, select normal, representative values from
each grade range.

Typical values selected:

Grade Typical Marks

A 95
B 85
C 75
D 65
F 50

Step 3: Create test cases

Test Case Input (Marks) Expected Output (Grade)

TC1 95 A
TC2 85 B
TC3 75 C
TC4 65 D
TC5 50 F

Here, the test values are normal, representative values within each partition, which is exactly
what Try-Typical Testing does.

Advantages
 Quick and easy to design
 Covers usual expected input scenarios
 Good for early or sanity testing

Limitations
 Does not cover boundary or invalid inputs
 May miss rare or edge-case defects

Functional Testing is a type of software testing that focuses on verifying the functions of a
system against its requirements. It checks what the system does, not how it does it internally.
Definition
Functional Testing is a testing technique where the functionality of the software is tested by
providing inputs and verifying that the outputs match the expected results according to the
specifications or requirements.

Key Characteristics
 Black-box testing approach – Does not require knowledge of internal code.
 Requirement-based – Tests are derived from functional specifications.
 Validates features – Checks if each function works correctly.

Types of Functional Testing

1. Unit Testing – Testing individual components or modules.
2. Integration Testing – Testing interaction between modules.
3. System Testing – Testing the complete system as a whole.
4. Acceptance Testing – Verifying if the system meets business requirements.

Example
Consider an ATM system with the following functionality:

 Users can withdraw money.

 Users can check balance.

Test Cases for Functional Testing:

Test Case Input Expected Output Function Tested

TC1 Withdraw $100 from account with $500 $400 remaining Withdraw money
TC2 Withdraw $600 from account with $500 Error: Insufficient funds Withdraw money
TC3 Check balance Display current balance Check balance

Advantages
  Confirms the system meets business requirements
 Detects functional errors early
 Can be automated for repetitive tests

Limitations
 Does not test non-functional aspects like performance, security, or usability
 Cannot detect issues in the internal code logic

Functional Testing Concepts of Howden

William E. Howden formalized an approach to functional testing by treating a software
program as a mathematical function that transforms inputs into outputs. This view forms a
structured basis for designing test cases.

🧠 Core Concepts According to Howden

Howden’s approach suggests four key ideas for systematic functional test design:

1. Precisely identify the domain of each input and output variable

o Understand exactly what values each input and output can take (data types,
ranges, categories).
2. Select values from each domain that have important properties
o Instead of random values, choose input values that are typical, special, or
meaningful (e.g., edge cases, defaults).
3. Consider combinations of special input values across different inputs
o Design test cases that explore important interactions between inputs (especially
when they affect each other).
4. Choose input values that cause the program to produce ‘special’ output values
o Select inputs that lead to key or interesting outputs (e.g., boundary results, error
conditions).

🔍 Why This Matters

Howden’s approach emphasizes structured functional testing by focusing on:

 Domains of inputs and outputs, not internal program code.

 Meaningful value selection rather than exhaustive testing.
 Reducing test space while maximizing coverage of behaviorally significant cases.

So a program is viewed as a function:

Output Yi=P(Xi)\text{Output } Y_i = P(X_i)Output Yi=P(Xi)

Where:

 XiX_iXi is a vector of input values

 YiY_iYi is the corresponding output
 PPP is the program under test.

This framing helps testers take a rigorous, mathematics-inspired view of input and output
behavior.

🧪 Example (Simplified)
Imagine a calculator function F(a, b):

 Inputs: integers a and b

 Output: a result such as a + b

Using Howden’s concepts:

 Identify valid domains for a and b (e.g., −100 to 100)

 Pick special values like 0, positive, negative
 Combine pairs that might reveal issues (e.g., −100 + 100, 0 + 0)
 Choose values likely to produce interesting outputs (e.g., overflow cases)

Steps in Functional Testing

Functional testing is requirement-based testing, so its steps focus on validating the system’s
behavior against its specifications.

1. Understand Requirements

 Study functional specifications, requirement documents, or user stories.

 Identify what the system should do.
 Example: For an ATM, understand withdrawal limits, PIN validation, balance display,
etc.
2. Identify Functions to Test

 List all features and functions of the system.

 Break down complex functions into smaller sub-functions.
 Example: Login function → username validation, password validation, error messages.

3. Determine Input Data

 Identify all input parameters for each function.

 Define input ranges, valid/invalid inputs, and data types.
 Example: Withdrawal amount: valid 1–10,000, invalid negative amounts, exceeding
balance, etc.

4. Define Expected Output

 For each input, define the expected output or behavior.

 Example: Enter correct PIN → access granted; incorrect PIN → error message.

5. Design Test Cases

 Create test cases based on inputs and expected outputs.

 Use techniques like:
o Equivalence Partitioning
o Boundary Value Analysis
o Try-Typical Testing
o Input Domain Testing (Base Choice, Pairwise, etc.)

6. Execute Test Cases

 Run the test cases on the actual system.

 Record the actual results.

7. Compare Results

 Compare actual outputs with expected outputs.

  Determine pass or fail for each test case.

8. Report Defects

 Document any deviations or failures as defects.

 Include details such as input, expected output, actual output, and steps to reproduce.

9. Regression Testing

 After fixing defects, re-run functional tests to ensure no new issues are introduced.

Summary Table
Step Description
1 Understand requirements
2 Identify functions to test
3 Determine input data
4 Define expected output
5 Design test cases
6 Execute test cases
7 Compare actual vs expected
8 Report defects
9 Regression testing

Types of Functional Testing

Functional testing is requirement-based and focuses on verifying that the system works as
intended. It can be categorized into several types depending on the scope and level of testing.

1. Unit Testing

 Tests individual components or modules of the software.

 Ensures that each module performs its function correctly.
 Usually automated and performed by developers.
 Example: Testing a single function that calculates interest in a banking app.
2. Integration Testing

 Tests the interaction between two or more modules.

 Checks that modules work together correctly.
 Can be top-down, bottom-up, or big bang integration.
 Example: Testing login module + dashboard module together.

3. System Testing

 Tests the complete system as a whole.

 Validates that all functional requirements are met.
 Performed in an environment similar to production.
 Example: Testing the entire e-commerce website workflow (login → search → checkout
→ payment).

4. Smoke Testing

 A high-level functional test to check basic functionality.

 Determines whether the system is stable enough for further testing.
 Example: Opening a web application and checking if the homepage loads, login works,
and main menu is accessible.

5. Sanity Testing

 Performed after minor changes or bug fixes to ensure the related functionality works
correctly.
 Narrow and focused testing.
 Example: After fixing a payment gateway bug, testing only the payment process.

6. Acceptance Testing

 Done to verify if the system meets business requirements.

 Usually performed by end users or clients.
 Types:
o Alpha Testing – Conducted at the developer’s site before release.
o Beta Testing – Conducted at the client or end-user site.
  Example: Testing a new payroll system by HR team before full deployment.

7. Regression Testing (Functional Focus)

 Ensures that new code changes do not break existing functionality.

 Re-executes previous functional test cases.
 Example: After adding a new feature, re-test login, search, and checkout workflows to
ensure they still work.

8. User Interface (UI) Functional Testing

 Verifies that UI elements work correctly and trigger the expected functions.
 Example: Clicking a submit button actually saves data to the database.

9. End-to-End Testing

 Verifies complete workflow from start to finish across modules and systems.
 Example: User registers → selects products → places order → receives confirmation
email.

Summary Table
Type Purpose Example
Unit Testing Test individual modules Interest calculator function
Integration Testing Test module interactions Login + Dashboard
System Testing Test complete system E-commerce workflow
Smoke Testing Quick basic check App homepage loads
Sanity Testing Test after changes Payment gateway bug fix
Acceptance Testing Verify business requirements Payroll system by HR
Regression Testing Test unchanged features Login, search after updates
UI Functional Testing Verify UI triggers correct actions Submit button saves data
End-to-End Testing Verify full workflow User registration → purchase → email

Equivalence Class Partitioning (ECP) is a widely used black-box testing technique in

software testing where the input domain is divided into groups (equivalence classes) that are
expected to be treated the same way by the program. Test cases are then selected from each
group rather than testing every possible input.

Definition
Equivalence Class Partitioning is a black-box testing method that divides input data into
equivalence classes such that any one value from each class can represent all values in that
class for testing purposes.

Key Concepts
1. Equivalence Class – A set of input values that are treated similarly by the program and
are expected to produce the same result.
2. Valid Class – Contains input values that are valid according to requirements.
3. Invalid Class – Contains input values that are invalid and should be rejected or handled
with errors.

Steps in Equivalence Class Partitioning

1. Identify input conditions from specifications.
2. Determine valid and invalid ranges or categories for each input.
3. Divide the input values into equivalence classes.
4. Select one representative value from each class for testing.

Example
Suppose a system accepts age from 18 to 60.

Step 1: Identify input domain

 Age: 0–120

Step 2: Define equivalence classes

Equivalence Class Input Range Type Representative Value

EC1 18–60 Valid 30
Equivalence Class Input Range Type Representative Value
EC2 < 18 Invalid 15
EC3 > 60 Invalid 65

Step 3: Select test cases

 Test Case 1: Age = 30 → valid

 Test Case 2: Age = 15 → invalid
 Test Case 3: Age = 65 → invalid

Here, one value from each class is enough to test the behavior of the system.

Advantages
 Reduces number of test cases significantly
 Improves test coverage efficiency
 Helps detect input validation errors

Limitations
 May miss boundary errors (needs Boundary Value Analysis for that)
 Only works well when classes are properly identified

Boundary Value Analysis (BVA) is a key black-box testing technique that focuses on testing
the edges or boundaries of input ranges, where errors are most likely to occur. It is often used
along with Equivalence Class Partitioning to improve coverage.

Definition
Boundary Value Analysis is a black-box testing technique where test cases are designed to
include values at the boundaries of equivalence classes, as errors often occur at the minimum,
maximum, just above, and just below boundary values.

Key Concepts
 Boundaries are critical points in input ranges where the program might fail.
  Test both valid and invalid boundary values.
 Helps detect off-by-one errors and other boundary-related defects.

Steps in Boundary Value Analysis

1. Identify input domain and equivalence classes.
2. Determine boundary values for each class:
o Minimum value
o Maximum value
o Just below minimum
o Just above maximum
3. Design test cases using these boundary values.

Example
Suppose a system accepts age between 18 and 60.

Step 1: Identify boundaries

 Minimum valid: 18
 Maximum valid: 60
 Invalid boundaries: 17, 61

Step 2: Design test cases

Test Case Age Type

TC1 17 Invalid (just below min)
TC2 18 Valid (min boundary)
TC3 19 Valid (just above min)
TC4 59 Valid (just below max)
TC5 60 Valid (max boundary)
TC6 61 Invalid (just above max)

Advantages
 Detects boundary-related defects effectively
 More efficient than testing all values
 Complements Equivalence Class Partitioning
Limitations
 Only works well if boundaries are properly defined
 Does not guarantee all internal logic errors are found

Comparison with Equivalence Class Partitioning

Aspect Equivalence Class Partitioning Boundary Value Analysis
Focus Representative values within a class Values at the edges of classes
Purpose Reduce test cases Detect boundary-related errors
Typical Test Cases 1 per class Min, Max, just above, just below

Decision Tables are a powerful black-box testing technique used to represent and analyze
complex combinations of inputs (conditions) and their corresponding outputs (actions).
They help systematically design test cases when the system has multiple conditions affecting
behavior.

Definition
A Decision Table is a tabular representation of conditions and their corresponding actions. It
is used to derive test cases by enumerating all possible combinations of input conditions and
expected outputs.

Key Concepts
1. Condition – A specific input or state that affects system behavior.
2. Action – The system’s response corresponding to a set of conditions.
3. Rule – A column in the decision table that represents one unique combination of
conditions and its resulting action.

Steps to Create a Decision Table

1. Identify conditions – List all input conditions or decisions.
 2. Identify possible actions – List all possible outputs or responses.
3. Enumerate rules – List all valid combinations of conditions.
4. Map actions – Specify what action occurs for each rule.
5. Design test cases – Each rule becomes a test case.

Example
Scenario: Login system with two conditions:

 Username valid? (Yes/No)

 Password valid? (Yes/No)

Actions:

 Grant access
 Deny access

Decision Table:

Rule Username Valid Password Valid Action

1 Yes Yes Grant access
2 Yes No Deny access
3 No Yes Deny access
4 No No Deny access

Test Cases Derived:

 TC1 → Username = valid, Password = valid → Access granted

 TC2 → Username = valid, Password = invalid → Access denied
 TC3 → Username = invalid, Password = valid → Access denied
 TC4 → Username = invalid, Password = invalid → Access denied

Advantages
 Ensures all combinations of conditions are tested
 Useful for complex business rules
 Easy to understand and communicate with stakeholders
Limitations
 Can become very large if there are many conditions (combinatorial explosion)
 Requires careful analysis to avoid redundant rules

Random Testing is a black-box testing technique in software testing where test inputs are
generated randomly from the input domain, without considering any specific conditions,
partitions, or boundaries. It is mainly used to check the system’s behavior under unexpected or
arbitrary inputs.

Definition
Random Testing is a software testing technique in which inputs are randomly selected from
the input domain to test the system for correctness, robustness, and reliability.

Key Concepts
1. Black-box approach – No knowledge of internal code is required.
2. Input domain – All possible valid and invalid inputs are considered.
3. Random selection – Test cases are not systematic; they rely on randomness to uncover
defects.

Steps in Random Testing

1. Identify the input domain – Determine all possible inputs for the system.
2. Generate random values – Use random number generators or tools to select input
values.
3. Execute the system – Apply the random inputs and observe outputs.
4. Compare results – Check outputs against expected behavior or system specifications.
5. Log defects – Record any anomalies or unexpected behavior.

Example
Suppose a program accepts age between 1 and 100:

 Randomly selected test inputs: 7, 55, 101, -3, 42

  Expected behavior:
o 7 → valid
o 55 → valid
o 101 → invalid
o -3 → invalid
o 42 → valid

Here, test cases are not planned; they are randomly generated to check system behavior.

Advantages
 Simple and easy to implement
 Can uncover unexpected defects that systematic testing may miss
 Useful when input domain is large or complex

Limitations
 May not cover all important cases
 Can miss boundary cases or rare conditions
 Effectiveness depends on number of random inputs

Module-5

Grey Box Testing is a software testing technique that combines elements of both black-box
and white-box testing. It tests the application with partial knowledge of the internal
structure while focusing on functional behavior.

Definition
Grey Box Testing is a technique where the tester has limited knowledge of the internal code
or architecture and tests the system primarily from the user’s perspective, while also
considering internal logic to design effective test cases.

Key Concepts
 1. Partial knowledge – Testers know some internal details, like data structures, algorithms,
or architecture, but not the full code.
2. Combination approach – Leverages functional (black-box) and structural (white-
box) testing.
3. Focus areas – Inputs, outputs, data flow, and internal interfaces.

Advantages
 Detects defects related to both functionality and internal logic
 More effective than pure black-box testing
 Can identify security issues, data flow problems, and interface errors

Limitations
 Requires testers with some programming or system knowledge
 May not detect all low-level code defects
 Can be more time-consuming than black-box testing

When to Use
 Testing web applications, APIs, or complex systems
 Security and penetration testing
 Integration testing where internal module interaction matters

Example
Suppose a web application allows users to log in:

 Tester knows the database schema partially (user table, password hash)
 Tester checks for:
o Correct login behavior (black-box)
o SQL injection vulnerabilities (grey-box, using partial internal knowledge)

Here, the tester doesn’t see the full source code but uses internal knowledge to design better test
cases.
Grey Box Testing Methodology
Grey Box Testing is a hybrid approach that combines aspects of black-box (functional) and
white-box (structural) testing. The methodology provides a structured way to plan, design, and
execute tests with partial knowledge of the internal system.

Key Steps in Grey Box Testing Methodology

1. Understand Requirements and Specifications

 Review functional requirements and design documents.

 Identify critical features to be tested.
 Determine areas where internal knowledge (data structures, architecture) can improve
test design.

2. Identify Test Objectives

 Define what to test:

o Functional behavior (inputs → outputs)
o Internal logic or data flow
o Integration points between modules

3. Analyze System Architecture

 Study system components, data flow, and interfaces.

 Identify areas prone to defects (e.g., input validation, database access, API calls).

4. Design Test Cases

 Use functional testing techniques (like equivalence partitioning, boundary value

analysis, decision tables) for external behavior.
 Use internal knowledge to design tests for:
o Data flow paths
o Security vulnerabilities
o Error handling
5. Execute Test Cases

 Run the designed test cases.

 Check actual vs expected results.
 Monitor internal system responses when possible (e.g., logs, database updates).

6. Record and Analyze Results

 Log defects or unexpected behavior.

 Identify if errors are due to internal logic, integration issues, or functional flaws.

7. Regression and Iteration

 After defect fixes, re-run test cases to ensure no new defects are introduced.
 Adjust tests as the system evolves.

Advantages

 Combines benefits of black-box and white-box testing.

 Detects defects related to both functionality and internal logic.
 Useful for security, integration, and system testing.

Limitations

 Requires testers with some system knowledge.

 More time-consuming than pure black-box testing.
 Cannot replace full white-box testing for low-level code errors.

Example

Testing a web application login module:

1. Black-box aspect: Verify correct login and error messages for invalid credentials.
2. Grey-box aspect: Use knowledge of database schema and authentication flow to test
for SQL injection or bypass attempts.
Matrix Testing is a black-box testing technique used to systematically test relationships
between inputs and outputs of a system. It is especially useful when the system has multiple
inputs and corresponding outputs, and you want to ensure all combinations are tested.

Definition
Matrix Testing is a method of black-box testing in which test cases are designed using a table
(matrix) that maps all possible input conditions to their expected outputs. It helps ensure
complete coverage of input-output relationships.

Key Concepts
1. Input conditions – The different input values or categories that affect system behavior.
2. Expected outputs – The corresponding system responses for each input combination.
3. Matrix representation – A table showing inputs vs outputs to design test cases.

Steps in Matrix Testing

1. Identify input parameters – Determine all inputs affecting the system.
2. List possible values – Include valid and invalid values for each input.
3. Determine expected outputs – Define what the system should do for each combination.
4. Construct the matrix – Create a table with inputs as rows or columns and outputs as
corresponding entries.
5. Generate test cases – Each row/column combination becomes a test case.
6. Execute tests and compare results – Check actual outputs against expected outputs.

Example
Scenario: Login system with two inputs:

 Username valid? (Yes/No)

 Password valid? (Yes/No)

Matrix Representation:
Username Valid Password Valid Expected Output
Yes Yes Grant Access
Yes No Deny Access
No Yes Deny Access
No No Deny Access

 Here, each row is a test case, covering all input-output relationships systematically.

Advantages
 Ensures systematic coverage of all input-output combinations
 Helps detect errors caused by specific input interactions
 Easy to visualize and communicate test cases

Limitations
 Can become very large for many input parameters
 May be time-consuming for complex systems

Regression Testing in black-box testing is a method used to ensure that new changes,
enhancements, or bug fixes in the software do not introduce new defects into existing
functionality. It focuses on testing the software’s behavior rather than its internal code.

Definition
Regression Testing is a type of software testing where previously executed test cases are re-
executed to verify that recent changes have not adversely affected existing functionality.

Key Concepts
1. Black-box approach – Tests are based on functional requirements rather than internal
code.
2. Re-execution of test cases – Existing test cases for previously tested functionality are
reused.
 3. Change impact – Focuses on areas affected by new code or updates.

Steps in Regression Testing

1. Identify changes – Determine what parts of the system were modified.
2. Select test cases – Choose relevant existing test cases that may be impacted.
3. Prioritize test cases – High-risk or critical functionalities first.
4. Execute test cases – Run the selected tests against the modified system.
5. Compare results – Check actual results against expected results.
6. Report defects – Document any failures caused by new changes.

Example
Scenario: E-commerce website adds a new “discount coupon” feature.

 Previously tested functionality: Login, add-to-cart, checkout.

 Regression test cases:
o TC1 → Login works after adding coupon feature
o TC2 → Add-to-cart works correctly
o TC3 → Checkout completes with and without coupon

Here, existing functionalities are retested to ensure nothing broke due to the new feature.

Advantages
 Detects side-effects of code changes
 Ensures software stability after updates
 Can be automated for frequent regression testing

Limitations
 Can be time-consuming if the test suite is large
 Needs maintenance of test cases to reflect changes in requirements
Orthogonal Array Testing (OAT) is a systematic black-box testing technique used to test all
possible combinations of input parameters efficiently. It is especially useful when a system
has multiple inputs with multiple possible values, and exhaustive testing would be impractical.

Definition
Orthogonal Array Testing is a software testing technique that uses orthogonal arrays
(mathematical tables) to design a minimal set of test cases covering all pairwise or higher-
order interactions of input parameters.

Key Concepts
1. Input parameters – The factors or fields that affect system behavior.
2. Levels – The possible values each parameter can take.
3. Orthogonal array – A table that ensures every pair of parameter values appears at
least once in the selected test cases.
4. Efficient coverage – Reduces the number of test cases while covering critical
combinations.

Steps in Orthogonal Array Testing

1. Identify parameters and levels – Determine input factors and possible values for each.
2. Select an appropriate orthogonal array – Choose an array based on the number of
parameters and levels.
3. Assign parameters to columns – Map system inputs to the array columns.
4. Generate test cases – Each row in the array becomes a test case.
5. Execute test cases and analyze results – Verify actual outputs against expected
behavior.

Example
Scenario: Test a login system with three parameters:

Parameter Levels
Browser Chrome, Firefox, Edge
OS Windows, Linux
Parameter Levels
Network WiFi, Mobile

 Total combinations: 3 × 2 × 2 = 12 (full combination testing)

 Using Orthogonal Array, we can reduce to 6 test cases while still covering all pairwise
combinations:

Test Case Browser OS Network

TC1 Chrome Windows WiFi
TC2 Chrome Linux Mobile
TC3 Firefox Windows Mobile
TC4 Firefox Linux WiFi
TC5 Edge Windows Mobile
TC6 Edge Linux WiFi

Here, every pair of parameter values appears at least once.

Advantages
 Reduces the number of test cases significantly
 Ensures pairwise or higher-order coverage
 Systematic and mathematically sound

Limitations
 Complex to set up for large number of parameters
 Only detects interaction faults up to the level of the array (may miss higher-order
defects)
 Requires knowledge of orthogonal arrays and mapping

Pattern Testing is a black-box software testing technique used to detect defects by checking
the software against typical input patterns, sequences, or usage scenarios. It focuses on
repeated structures or common sequences that are likely to reveal faults in the system.

Definition
Pattern Testing is a software testing method where test cases are designed using specific
input patterns or sequences that represent realistic or frequently occurring scenarios, to
uncover defects that occur under predictable or repetitive conditions.

Key Concepts
1. Patterns – Typical input values, sequences, or workflows commonly used by end users.
2. Focus on repetition – Tests how the system behaves with frequent, recurring inputs.
3. Black-box approach – Does not require internal code knowledge; focuses on observable
behavior.

Steps in Pattern Testing

1. Analyze the system – Identify areas where patterns occur (e.g., form inputs, menu
navigation).
2. Identify typical patterns – Choose input sequences or repeated actions that users are
likely to perform.
3. Design test cases – Create tests using these patterns.
4. Execute test cases – Apply the patterns to the system and observe outputs.
5. Record and analyze defects – Log any anomalies detected during testing.

Example
Scenario: Testing a text input field in a form:

 Common patterns for input:

o All uppercase letters → “HELLO”
o All lowercase letters → “hello”
o Repeated characters → “aaaaaa”
o Mixed case → “HeLLo”
o Numeric input → “12345”
 Test cases check whether the system handles these typical user patterns correctly,
without crashing or misbehaving.

Another example: Menu navigation patterns

 User clicks menu A → submenu B → option C repeatedly

 System should respond consistently each time.
Advantages
 Detects defects that occur under typical real-world usage
 Useful for user interface and data input testing
 Simple to implement and understand

Limitations
 Does not guarantee full coverage of all input combinations
 May miss edge cases or rare inputs
 Highly dependent on correctly identifying typical patterns

PEX (Program EXploration) can also be applied in Grey Box Testing to systematically
generate test cases by using partial knowledge of the internal system along with observable
behavior. It combines the functional perspective of black-box testing with limited structural
insights from white-box testing, making it very effective for complex systems.

Definition
PEX in Grey Box Testing is an automated testing approach where inputs are generated
systematically to explore program behavior, using partial internal knowledge (e.g., data
structures, function contracts, or APIs) while still observing outputs as a black-box tester.

Key Concepts
1. Partial System Knowledge – Unlike pure black-box PEX, the tester has some insight
into the system’s logic or structure.
2. Symbolic or Generated Inputs – Inputs are generated to explore different execution
paths or boundary conditions.
3. Test Coverage – Focuses on critical paths, data flow, or API behavior informed by
partial system knowledge.
4. Observation-Based Validation – Outputs are checked against expected results or
specifications.
Steps in PEX Grey Box Testing
1. Identify Inputs and API Interfaces – Determine parameters or modules to test.
2. Apply Partial Knowledge – Use known constraints or data flow to guide input
generation.
3. Generate Test Inputs – Systematically create symbolic or concrete inputs covering
important paths.
4. Execute Program – Run the program with generated inputs.
5. Observe Outputs – Compare actual outputs with expected results.
6. Analyze Defects – Record failures related to functional behavior or internal constraints.

Example
Scenario: Testing a banking API function for fund transfer:

 Known constraints:
o Transfer amount ≤ account balance
o Accounts must exist in the system
 PEX generates inputs based on:
o Transfer amounts at boundary and typical values (0, balance, > balance)
o Account numbers from database and random invalid values
 Test outputs:
o Transfer success for valid inputs
o Transfer failure or error messages for invalid inputs

Here, partial knowledge of account rules and system constraints guides input generation,
improving test effectiveness.

Advantages
 Automates test case generation for complex systems
 Uses partial internal knowledge to focus on critical areas
 Detects both functional and constraint-related defects

Limitations
  Requires understanding of system constraints or architecture
 May produce many test cases, requiring careful selection
 Not fully black-box, so some internal logic errors could still be missed

Testing Problems in Grey Box Testing

Grey Box Testing is a hybrid testing approach combining black-box and white-box testing.
While it offers many advantages, it also has certain challenges and limitations.

1. Limited Internal Knowledge

 Problem: Testers only have partial knowledge of the internal system.

 Effect: Some deep internal logic errors may remain undetected.
 Example: A hidden memory leak or inefficient loop may not be revealed if the tester
only knows partial architecture.

2. Complexity in Test Design

 Problem: Designing test cases is more complex than pure black-box or white-box
testing.
 Effect: Requires careful selection of functional tests plus targeted internal tests.
 Example: Testing database transactions may require combining interface inputs with
knowledge of internal queries.

3. Difficulty in Prioritizing Test Cases

 Problem: Grey box testing often involves both functional and structural aspects,
making it harder to prioritize.
 Effect: Risk of overlooking critical paths or wasting resources on low-risk areas.
 Example: API testing with partial code knowledge may miss critical data flow paths if
test coverage is not planned well.

4. Tool Dependency
  Problem: Grey box testing often requires specialized tools for logging, code inspection,
or monitoring internal state.
 Effect: Test effectiveness depends on tool availability and accuracy.
 Example: Tools for inspecting database access patterns or system logs may not be
available for all systems.

5. Time-Consuming

 Problem: Combining black-box functional testing with internal knowledge testing

can increase testing time.
 Effect: May delay releases if test planning and execution are not efficient.

6. Limited Coverage of Non-Functional Requirements

 Problem: Grey box testing primarily targets functional and internal data flow aspects.
 Effect: Non-functional requirements like performance, scalability, or usability may be
insufficiently tested.

Summary Table

Problem Description Effect

Limited Internal Tester has only partial system
Some logic defects missed
Knowledge info
Complexity in Test Combines functional &
Hard to design effective tests
Design structural testing
Difficulty in Prioritizing Many possible paths to test Critical paths may be missed
Requires monitoring/logging Effectiveness depends on tool
Tool Dependency
tools availability
Time-Consuming Hybrid testing approach Increased testing time
Limited Non-Functional Performance or usability issues may
Focus on functionality
Coverage be overlooked
Pattern Unit Testing is a type of unit testing where test cases are designed based on repetitive
or recurring patterns in the software. It is a white-box/black-box hybrid approach that
focuses on testing repeated structures, sequences, or code patterns to ensure correctness.

Definition
Pattern Unit Testing is a software testing technique where individual units or modules are
tested using predefined patterns of inputs and outputs to detect defects caused by common
usage or repeated sequences.

Key Concepts
1. Unit Testing Focus – Tests small modules or functions independently.
2. Pattern-Based Inputs – Uses typical sequences, repeated data, or structured
patterns to design test cases.
3. Defect Detection – Helps detect errors that occur with repeated or structured inputs
that may not appear in random testing.

Steps in Pattern Unit Testing

1. Identify the module/unit – Choose the smallest testable component.
2. Analyze patterns – Determine input patterns the unit will encounter (e.g., numeric
sequences, repeated characters, typical user inputs).
3. Design test cases – Create test cases based on these patterns.
4. Execute tests – Run the unit with pattern-based inputs.
5. Compare outputs – Check actual outputs against expected results.
6. Record defects – Document any failures.
Example
Scenario: Testing a function that reverses strings:

 Pattern inputs:
o All uppercase letters → "HELLO"
o All lowercase letters → "hello"
o Repeated characters → "aaaa"
o Mixed case → "HeLLo"
 Expected outputs:
o "HELLO" → "OLLEH"
o "hello" → "olleh"
o "aaaa" → "aaaa"
o "HeLLo" → "oLLeH"

This ensures the unit behaves correctly for common and repetitive patterns.

Advantages
 Detects defects related to typical and repetitive inputs
 Complements other unit testing techniques (random, boundary, or equivalence class
testing)
 Useful for modules with predictable or structured input behavior

Limitations
 May not detect rare or exceptional inputs
 Focused on patterned behavior, so coverage may be incomplete
 Requires good understanding of input patterns
Symbolic Execution in Grey Box Testing is a technique where inputs are treated as symbolic
variables, and partial knowledge of the system’s internal structure is used to explore
program behavior, generate test cases, and detect defects.

 It combines white-box analysis (partial code or architectural insight) with black-box

observation (focusing on input-output behavior).
 Test cases are derived from solving constraints on symbolic inputs.

Key Concepts
1. Symbolic Inputs – Inputs are represented as symbols instead of concrete values.
2. Constraints – Partial knowledge of system logic is used to formulate constraints that
must hold for different execution paths.
3. Path Exploration – Different paths in the program are explored based on symbolic input
constraints.
4. Test Case Generation – Concrete inputs are generated by solving constraints to cover
important scenarios.
5. Observation-Based Validation – Output is checked against expected results.

Steps in Symbolic Execution (Grey Box)

1. Identify Inputs and System Constraints
o Select input parameters and note constraints known from system architecture or
design.
2. Represent Inputs Symbolically
o Example: x for an integer input, y for a string input.
3. Formulate Path Constraints
o Use partial knowledge of logic to identify conditions along program paths.
o Example: If x > 10 → action A, else → action B
4. Solve Constraints to Generate Test Cases
o Derive concrete inputs that satisfy each path condition.
5. Execute Test Cases
o Run the program with generated inputs and observe outputs.
6. Analyze Results
o Verify outputs against specifications and log any defects.

Example
Scenario: Bank transfer function
  Input: amount (symbolic a), balance (symbolic b)
 Partial knowledge:
o Transfer allowed if a <= b
o Amount must be > 0
 Path constraints:
o Path 1: a > 0 && a <= b → Success
o Path 2: a <= 0 || a > b → Failure
 Solve constraints to generate concrete test cases:
o a = 50, b = 100 → Success
o a = 150, b = 100 → Failure
o a = -10, b = 100 → Failure

Here, partial knowledge of business rules guides the test, making it more effective than pure
black-box symbolic execution.

Advantages
 Systematically generates test cases for critical paths
 Detects defects in both functional behavior and partial internal logic
 Reduces redundant tests compared to random testing

Limitations
 Requires some understanding of system rules or architecture
 Can become complex for large systems with many constraints
 May miss errors unrelated to known constraints

A Symbolic Execution Tree (SET) in grey box testing is a graphical representation of all
possible execution paths in a program, based on symbolic inputs and partial knowledge of the
system’s internal logic.

 Each node represents a program state or decision point.

 Each edge represents a condition or path constraint derived from symbolic inputs.
 Leaves represent end states (outputs, exceptions, or errors).

This helps testers systematically explore paths using partial internal knowledge while focusing
on functional correctness.

Key Concepts
 1. Symbolic Inputs – Variables represented symbolically instead of concrete values.
2. Path Constraints – Conditions that must be satisfied for execution to follow a particular
path.
3. Nodes – Represent program statements, decision points, or states.
4. Edges – Represent branching conditions (true/false).
5. Leaves – Represent outputs or program termination points.

Steps to Create a Symbolic Execution Tree

1. Identify Inputs – Represent program inputs as symbolic variables (e.g., x, y).
2. Start at Entry Point – Begin at the program’s starting node.
3. Branch at Conditions – At each decision point (if/else, switch), create branches for
true/false symbolic conditions.
4. Propagate Constraints – Along each path, accumulate constraints on symbolic inputs.
5. Generate Leaves – Mark each leaf node with expected output or error based on path
constraints.
6. Generate Test Cases – Solve the symbolic constraints along paths to create concrete test
inputs.

Example
Program snippet:

if x > 0:
if y < 5:
output = "A"
else:
output = "B"
else:
output = "C"

Symbolic Execution Tree:

Start
|
[x > 0?]
/ \
Yes No
/ \
[y < 5?] output = "C"
/ \
Yes No
/A/ /B/
  Path Constraints & Test Cases:
o Path 1: x > 0 and y < 5 → Output A → Test: x=1, y=0
o Path 2: x > 0 and y >= 5 → Output B → Test: x=2, y=5
o Path 3: x <= 0 → Output C → Test: x=-1, y=any

Advantages
 Provides systematic coverage of program paths
 Helps detect defects in both functional behavior and partially known internal logic
 Useful for critical systems and boundary testing

Limitations
 Can grow exponentially for complex programs
 Requires partial knowledge of internal logic
 Constraint solving may be computationally expensive

PEX (Program EXploration) Applications

PEX is an automated testing framework (especially for .NET programs) that systematically
explores program behavior by generating inputs, analyzing outputs, and detecting defects. It is
widely used in black-box, grey-box, and white-box testing scenarios.

Key Applications of PEX

1. Test Case Generation

 Automatic generation of test cases for methods or functions.

 Ensures path coverage by exploring all feasible execution paths.
 Example: Generating tests for a banking API method to cover success and failure cases.

2. Boundary Testing

 Identifies boundary conditions for input parameters automatically.

 Useful for detecting off-by-one errors or input validation issues.
 Example: Testing array indexing, numeric limits, or string lengths.
3. Path Exploration

 Explores all feasible execution paths in a program.

 Uses symbolic execution and constraint solving to systematically explore program
logic.
 Example: A login function with multiple conditions (username/password validation) can
have all paths tested automatically.

4. Regression Testing

 Generates repeatable test inputs to re-run after code changes.

 Detects whether new code introduces defects in previously tested functionality.
 Example: Testing fund transfer function after adding a new feature.

5. Security and Robustness Testing

 Can generate edge-case inputs to check for errors, exceptions, or vulnerabilities.

 Helps find defects such as null inputs, invalid data, or unexpected sequences.
 Example: Detecting SQL injection possibilities or invalid API parameters.

6. Integration Testing Assistance

 Helps test interactions between modules or APIs by generating input sequences that
cover different scenarios.
 Can be used in grey-box testing to focus on critical data flow paths.

Example Use Case

Bank Transfer Function:

 Input parameters: amount, sourceAccount, destinationAccount.

 PEX generates inputs:
o Normal: amount=100, valid accounts
o Boundary: amount=0, amount=balance, amount>balance
o Invalid: non-existing accounts, negative amounts
 Outputs are verified against expected behavior (success/failure/error).
Advantages

 Automates test case generation, saving time.

 Ensures high path coverage.
 Detects edge-case defects and boundary errors.
 Can support black-box, grey-box, and white-box testing.

Limitations

 Mostly available for specific platforms (e.g., .NET programs).

 Can generate too many test cases, requiring prioritization.
 Requires some understanding of input domain and constraints.