SOFTWARE_TESTING (Black, white and gray testing)

This presentation explains the three fundamental software testing approaches—Black Box Testing, White Box Testing, and Grey Box Testing—using clear examples from automotive Body Control Module (BCM), Cluster, and Brakes applications.

Black Box Testing focuses on functional validation from the end-user perspective, using practical test case tables for features like remote door locking and hazard lamp indications in automotive BCM systems.

White Box Testing dives into code logic and structure for safety-critical applications such as ABS modules, showing how developers validate every code path and algorithm for robust braking performance.

Grey Box Testing combines both methods with partial system knowledge, demonstrating integration and interface validation in automotive clusters (e.g., CAN message decoding for digital speedometers and error handling in instrument displays).

The presentation is designed for automotive engineers, testers, and students who want real-world scenarios and requirements-driven use cases. It features a comparison table, application guidance, and references to industry-standard tools, making it valuable for professional training and practical software QA in embedded automotive domains.

1. SOFTWARE TESTING
Black Box, White Box & Grey Box Testing
BY:
ABHISHEK N
V M BHUVANESH

2. INTRODUCTION
What is Software Testing?
Process of verifying and validating that a software system meets specified
requirements.
Ensures functionality, safety, reliability, and performance.
In automotive systems, testing ensures compliance with standards like ISO 26262
(Functional Safety) and ASPICE.
Three Major Testing Techniques:
1.Black Box Testing
2.White Box Testing
3.Grey Box Testing

3. BLACK BOX TESTING
Testing the functionality of the software without knowing the internal code or structure.
Characteristics:
Focuses on input–output behavior
Performed by testers or validation engineers
Tests against requirements/specifications
Used in:
System testing
Acceptance testing
ECU functional validation (BCM, Cluster, Brakes)
Advantages:
No need to know source code
Simulates real-world use cases
Catches missing or wrong functionality
Disadvantages:
Cannot identify internal logic or code-level issues
Limited coverage if requirements are unclear

4. Test Case ID Key Fob Button Door Status Before Expected Output Pass Criteria
TC_01 Lock All doors closed All doors locked + Hazard blinks twice Lock signal received and confirmed
TC_02 Unlock All doors locked
All doors unlocked + Hazard blinks
once
Unlock signal received and
confirmed
TC_03 Lock One door open No locking action, buzzer alert System safety check OK
TC_04 Unlock Already unlocked No change No false trigger observed
Example :
Requirement :
When the user presses the key fob ‘Lock’ button, all doors should lock, and the hazard lamps should
blink twice.
Black Box Testing Approach:
1.System Under Test: Body Control Module (BCM)
2.Inputs: Remote key fob signals (Lock/Unlock)
3.Outputs: Door lock actuators, hazard lamp indicators

5. WHITE BOX TESTING
Testing internal logic, structure, and flow of the software code.
Characteristics:
Performed by developers
Involves understanding code
Helps in unit testing and integration testing
Used in:
ECU software module testing
Logic validation in safety-critical modules
Advantages:
Finds hidden logical or boundary errors
High code coverage
Ensures safety-critical path tested
Disadvantages:
Requires programming knowledge
Not suitable for full system-level behavior

6. White Box Testing Approach:
1.Access source code for ABS module.
2.Check logic:

3.Write unit tests to check all branches:
Requirement :
If brake pedal is pressed and wheel slip > 20%, the ABS modulation routine should activate.
Example :
if (brake_pedal_pressed && wheel_slip > 20) {
activate_ABS_modulation();
}
Case 1: Brake pressed, slip = 25 → ABS activates
Case 2: Brake pressed, slip = 10 → ABS does not activate
Case 3: Brake not pressed → No ABS

7. GREY BOX TESTING
Testing technique combining both Black Box and White Box methods.
Tester has partial knowledge of system internals.
Characteristics:
Tests system using functional and
structural understanding
Used for integration and regression testing
Detects issues at interface boundaries
Used in:
Communication between ECUs (CAN,
LIN, FlexRay)
Data validation in Instrument Clusters,
Infotainment, etc.
Advantages:
Detects integration and interface issues
More effective than pure black-box
Doesn’t require full code access
Disadvantages:
Partial visibility—cannot find all internal
logic bugs
Needs both domain & technical
knowledge

8. Grey Box Testing Approach:
1.Tester knows how CAN decoding logic works (e.g., scaling = raw_value * 0.01).
2.Inject CAN message manually via CANoe:
3.Verify: Display shows 30 km/h correctly.
4.Check boundary & error cases (e.g., invalid checksum).
Example
Requirement :
Speed value on CAN message should be displayed correctly on the digital speedometer.
Message ID: 0x180
Data: Raw Speed = 3000 (→ 30.00 km/h)

9. Feature Black Box White Box Grey Box
Knowledge of code No Full Partial
Focus Functionality Logic/Structure Integration & Behavior
Tester Validation Engineer Developer Integration Engineer
Example Door lock & hazard light ABS Routine Speed Display in Cluster
Used In System/Acceptance Testing Unit/Integration Testing Regression/Interface Testing
COMPARISON TABLE

10. TOOLS COMMONLY USED
Black Box: CANoe, NI VeriStand, dSPACE, Vector VT System
White Box: LDRA, VectorCAST, Tessy
Grey Box: CANalyzer, ETAS INCA, Simulink Test

11. THANK YOU