Skip to content
Rounder
Start
BCA-441E · Software Testing
Unit 2

Approaches to Testing (White Box, Black Box, Gray Box and Integration)

Sign in to save
Unit 2 Learning Hub

Approaches to Testing (White Box, Black Box, Gray Box and Integration)

Core Definitions & Key Concepts

Core Definitions & Key Concepts

White Box Testing (Glass Box / Structural Testing)

A testing methodology where the tester has complete visibility and access to internal program source code, architecture, and logic paths, designing test cases based on statements, branches, and conditions.

Black Box Testing (Behavioral / Specification-Based Testing)

A testing methodology where the software is treated as an opaque black box with zero visibility into internal source code. Test cases are derived strictly from functional requirements and specifications.

What is Gray Box Testing

A hybrid testing approach where the tester has partial knowledge of internal structures, database schemas, or system architecture (e.g., verifying database state changes after submitting a GUI form).

Statement Coverage and its mathematical formula

Measures the proportion of executable source code statements executed by a test suite: $Statement Coverage = \frac{Number of Executed Statements}{Total Number of Executable Statements} × 100\%$

Branch / Decision Coverage

Measures whether every boolean decision branch (both True and False outcomes) in control flow structures (if, while, switch) has been executed by test cases: $Branch Coverage = \frac{Number of Traversed Decision Outcomes}{Total Number of Decision Outcomes} × 100\%$

What is Equivalence Partitioning (EP)

A black-box technique that divides the input domain into distinct partitions of equivalent data where the system is expected to behave identically, selecting one representative test case from each valid and invalid partition.

What is Boundary Value Analysis (BVA)

A black-box testing technique focused on testing values at the boundaries/edges of input partitions (Minimum, Just above Minimum, Nominal, Just below Maximum, Maximum), where defects disproportionately cluster.

What is Unit Testing

The testing of individual software units, functions, classes, or modules in complete isolation from the rest of the application, typically automated by developers using frameworks like JUnit or Jest.

A Test Stub and a Test Driver

  • Test Stub: A dummy mock component that replaces a low-level module called by the unit under test (used in Top-Down integration).
  • Test Driver: A dummy test harness that invokes and passes parameters to the module under test (used in Bottom-Up integration).

What is Big-Bang Integration Testing

A non-incremental integration strategy where all developed modules are combined simultaneously into a single build and tested as a whole. Disadvantage: Pinpointing the root cause of failures is exceptionally difficult.

✓Topic 1 covered: Core Definitions & Key Concepts
Next: Conceptual & Architectural Analysis↓

Conceptual & Architectural Analysis

Conceptual & Architectural Analysis

Compare White Box Testing and Black Box Testing Across All Key Dimensions

DimensionWhite Box TestingBlack Box Testing
Code VisibilityComplete access to source code & logicZero access to internal source code
Basis for TestsControl flow graphs, branch decisionsRequirements, user stories, specifications
Performed ByDevelopers & Specialized SDETsDedicated QA testers, business analysts
GranularityUnit level, function levelSystem level, integration, acceptance
StrengthsDiscovers dead code, hidden logic errorsValidates genuine user workflows
WeaknessesCannot detect missing requirementsCannot identify unexercised hidden code paths

Integration Testing Strategies: Top-Down vs Bottom-Up vs Sandwich

Integration Testing Hierarchies

CODE
1          [ Module A (Root) ]
2              /         \
3   [ Module B ]         [ Module C ]
4      /     \                 \
5  [ Mod D ] [ Mod E ]      [ Mod F (Leaf) ]
  1. Top-Down Integration: Starts from the top-level control module (A). Lower-level modules are simulated using Stubs. Verifies high-level system control logic early; stubs require significant coding effort.
  2. Bottom-Up Integration: Starts with primitive leaf modules (D, E, F). Invoked via Drivers. Simplifies test harness construction; critical architectural design flaws are discovered late.
  3. Sandwich (Hybrid) Integration: Combines Top-Down and Bottom-Up simultaneously, meeting at a predefined middle target layer. Minimizes total stub and driver development overhead.

Detail Boundary Value Analysis (BVA) with Concrete Numeric Range Example

BVA Mathematical Example

Suppose a university admission system accepts age X in the range 18 ≤ X ≤ 60.

  • Valid Partition: [18, 60]
  • Invalid Partitions: X < 18 and X > 60

Standard 2-Boundary Values Tested:

  1. X = 17 (Just below Minimum - Invalid)
  2. X = 18 (Minimum - Valid Boundary)
  3. X = 19 (Just above Minimum - Valid)
  4. X = 35 (Nominal interior value - Valid)
  5. X = 59 (Just below Maximum - Valid)
  6. X = 60 (Maximum - Valid Boundary)
  7. X = 61 (Just above Maximum - Invalid)
  • Rationale: Off-by-one errors (using < instead of <=) are among the most common bugs in computer science.

Decision Table Testing for Complex Business Logic

Decision Table Structure (E-Commerce Discount Example)

System Architecture / Concept DiagramHorizontal Scroll Enabled
+---------------------------+----+----+----+----+
| Conditions (Inputs)       | R1 | R2 | R3 | R4 |
+---------------------------+----+----+----+----+
| Order Total > $1000?      | Y  | Y  | N  | N  |
| Premium Member Loyalty?   | Y  | N  | Y  | N  |
+---------------------------+----+----+----+----+
| Actions (Outputs)         |    |    |    |    |
+---------------------------+----+----+----+----+
| Apply 20% Discount        | X  |    |    |    |
| Apply 10% Discount        |    | X  | X  |    |
| Standard Shipping ($10)   |    |    |    | X  |
+---------------------------+----+----+----+----+
  • Systematically tests all 2^n combinations of conditions, guaranteeing that zero logical edge combinations are overlooked by QA.

State Transition Testing for Finite State Machines (FSM)

State Transition Methodology

Used for event-driven systems transitioning between finite states (e.g., ATM card authentication, order checkout):

  1. States: Logged Out, Logged In, Account Locked.
  2. Events/Transitions: Enter Correct PIN \to Logged In; Enter Wrong PIN (1st/2nd try) \to Re-prompt; Enter Wrong PIN (3rd try) \to Account Locked.
  3. State Transition Matrix: Tabulates all valid and invalid transitions, testing both positive paths and negative transition rejection.
✓Topic 2 covered: Conceptual & Architectural Analysis
Next: In-Depth Analysis & Implementation↓

In-Depth Analysis & Implementation

In-Depth Analysis & Implementation

Provide the Complete Mathematical and Algorithmic Formulation of Thomas McCabe's Cyclomatic Complexity, Control Flow Graph Construction, and Basis Path Testing

McCabe's Cyclomatic Complexity Theory

CODE
1        [ Node 1: Entry / x > 0? ]
2               /          \
3       (True) /            \ (False)
4             v              v
5      [ Node 2: y = 10 ]  [ Node 3: y = 20 ]
6             \              /
7              v            v
8           [ Node 4: Exit ]

1. Control Flow Graph (CFG) Definitions

A directed graph G = (V, E) where:

  • V: Nodes representing sequential statements or basic blocks.
  • E: Directed edges representing control flow transfers between nodes.

2. Three Equivalent Cyclomatic Complexity Formulas

  1. Formula 1 (Edges and Nodes):

$V(G) = E - N + 2P where E is edge count, N is node count, and P is connected components (typically P=1$).

  1. Formula 2 (Predicate Nodes):

$V(G) = P_{pred} + 1 where P_{\text{pred}}$ is the number of decision/predicate nodes containing binary conditions.

  1. Formula 3 (Enclosed Regions):

$V(G) = R where R$ is the number of planar bounded regions plus the 1 unbounded external region.

3. Basis Path Testing Execution Steps

  1. Draw the formal CFG from program source code.
  2. Calculate V(G). This number defines the exact upper bound on the number of linearly independent paths required to achieve 100% branch and statement coverage.
  3. Identify a Basis Set of linearly independent execution paths through G.
  4. Author test cases with inputs specifically engineered to execute each identified basis path.

Design and Implement an Automated White-Box and Black-Box Test Harness in Python using PyTest

Comprehensive PyTest Implementation

System Architecture / Concept DiagramHorizontal Scroll Enabled
import pytest

def calculate_ticket_price(age: int, is_student: bool) -> float:
    """
    Business Logic:
    - Age < 5: Free (0.0)
    - Age 5-17: Child ($10.0)
    - Age 18-59: Adult ($20.0), Students get 25% discount ($15.0)
    - Age >= 60: Senior ($12.0)
    """
    if age < 0 or age > 120:
        raise ValueError("Invalid age boundary")
    if age < 5:
        return 0.0
    elif age <= 17:
        return 10.0
    elif age <= 59:
        return 15.0 if is_student else 20.0
    else:
        return 12.0

# --- Black Box Boundary Value Analysis (BVA) Test Suite ---
@pytest.mark.parametrize("age, is_student, expected_price", [
    (0, False, 0.0),       # Min Valid Boundary
    (4, False, 0.0),       # Boundary: Under 5
    (5, False, 10.0),      # Boundary: Child Start
    (17, False, 10.0),     # Boundary: Child End
    (18, False, 20.0),     # Boundary: Adult Start
    (18, True, 15.0),      # Boundary: Student Discount
    (59, False, 20.0),     # Boundary: Adult End
    (60, False, 12.0),     # Boundary: Senior Start
    (120, False, 12.0),    # Boundary: Max Valid
])
def test_bva_pricing(age, is_student, expected_price):
    assert calculate_ticket_price(age, is_student) == expected_price

# --- Negative Partition Testing ---
@pytest.mark.parametrize("invalid_age", [-1, -50, 121, 200])
def test_invalid_boundaries(invalid_age):
    with pytest.raises(ValueError):
        calculate_ticket_price(invalid_age, False)

Analyze Integration Testing Dynamics: Top-Down vs Bottom-Up Stub/Driver Engineering Complexity

Integration Engineering Complexity Analysis

1. Mathematical Stub Overhead in Top-Down

  • In a tree-structured system of branching factor b and depth d, testing root Module 1 requires writing b stubs.
  • Testing level k requires mocking all unbuilt descendants at level k+1.
  • Stubs often need complex state simulation (returning dynamic responses based on previous calls), inflating test maintenance costs.

2. Driver Overhead in Bottom-Up

  • Primitive modules require drivers to simulate environment setups, instantiate database connections, and inject test arguments.
  • Advantage: Reusable in automated unit test suites.

3. Continuous Integration (CI) Paradigm Shift

  • Modern agile teams avoid prolonged monolithic integration phases by adopting Continuous Integration (CI): micro-integrations occurring multiple times daily, automated via GitHub Actions with ephemeral containerized dependencies (Testcontainers), rendering manual big-bang integration obsolete.
✓Topic 3 covered: In-Depth Analysis & Implementation
Next: Important Exam Points & Quick Revision↓

Important Exam Points & Quick Revision

Important Exam Points & Quick Revision

Examiners frequently evaluate: Equivalence Partitioning & BVA numeric problems (10 marks), McCabe Cyclomatic Complexity formula and CFG (10/15 marks), and Stubs vs Drivers in Integration (5 marks).

Practice Ready

Ready to practice Unit 2?

You've read the core concepts. Take the balanced 10-question practice set to test your mastery!

Save progress