Performing Boundary Value Analysis

You will test software resilience by deliberately providing extreme input values to verify that error handling logic functions under stress.

Performing Boundary Value Analysis

In this lesson, you will learn how to verify your system’s software resilience by stress-testing the edges of your input ranges to ensure your error-handling logic doesn't collapse under extreme conditions.

In embedded systems, defects rarely hide in the middle of a range—they lurk at the transition points. If a function expects a sensor value between 0 and 100, an inexperienced developer might only test values like 50. However, a robust implementation must be tested against the boundary conditions: 0, 100, -1, and 101.

Why Boundaries Matter

In C or C++, boundary errors often manifest as "off-by-one" faults, buffer overflows, or unexpected integer overflows that lead to invalid memory access. Consider a simple calibration function that scales a sensor input:

void apply_calibration(int16_t raw_input) {
    // Expected range: 0 to 1023
    if (raw_input < 0 || raw_input > 1023) {
        handle_error(ERR_OUT_OF_RANGE);
        return;
    }
    // ... processing logic
}

If you only test raw_input values like 512, the code appears flawless. But when you perform Boundary Value Analysis, you specifically inject:

The Minimum: 0 (Should pass)
The Maximum: 1023 (Should pass)
Just below Minimum: -1 (Must trigger handle_error)
Just above Maximum: 1024 (Must trigger handle_error)

Integrating with Safety

By forcing these extreme values, you verify that your Defensive Input Validation and Error Handling Return Codes are doing their job. If your logic fails at 1024 but works at 1023, you have identified a potential reliability vulnerability before it reaches the field. This systematic approach ensures that even if a sensor malfunctions and sends a garbage signal, your system enters a safe state rather than attempting to process corrupt data.

When you automate this stimulus generation, ensure you include these "edge-case" vectors in every CI build. A system that gracefully rejects 1024 is far safer than one that crashes because the programmer assumed the input would always stay within the nominal range.

Key Takeaway: Software resilience is defined by how gracefully a system handles the inputs that exist just outside of its specified design limits.