Unlocking the Secrets of ISO 26262 Verification Methods

Equivalence classes

To reduce the test effort, the test input data/values are obtained by selecting equivalence classes required to execute the function. These test-methods are then based on the equivalence relation of the inputs. Test cases are selected covering the classes previously specified, at least one test case from each equivalence class.

Equivalence classes can be derived from the specification and analysis of requirements or derived from the architecture (equal blocks or functions) or internal structure of the software (set of values executes the same path).

Verification by equivalence classes

Equivalence classes can be derived at different level. Here are few examples:

• System with modules: The modules 1….n are identical at system level, the test and operation of the module can cover verification of modules.
• Hardware: Same type of components, e.g. DMA Controllers can be verified on HW detailed design level conducting tests at one of the two identical components.
• Software: Identical Software units, which are equivalent to each other, depend on specified equivalence relation and class.
• Software: The inputs to the DMA1 & DMA2 are processed in the same way and can be partitioned. A group is formed based on the same test object behaviour.
  • Example: the application you are testing accept values in the character limit of 1 – 100 only.
  • 3 partitions: one valid partition and two invalid partitions

There are two basic possibilities for input partitioning – equivalence classes derived from the specification:

• Interpretation of the specification may be either input orientated – the values selected are treated in the same way – or
• Output oriented – the set of values lead to the same functional result.

Output values

Equivalence Class Partitioning can also be used to test output values. For example, if a software application is supposed to return a specific set of outputs for certain input values, the expected output values can be partitioned into equivalent classes and only one value from each class can be tested.

Black-box testing

One of the testing methods typically used on system is the black-box testing:

→ Black Box testing doesn’t consider the internal structure, design is to be tested.
→ The internal functioning is not crucial as input for testing.
→ It only evaluates the external behaviour of the system.
→ The inputs implied at the system and the outputs or responses are tested.

The input data range is subdivided into specific input value ranges considering the specification and by analysing the requirements. Test cases are then formed from the:

• Data from permissible ranges
• Data from inadmissible ranges
• Data from range limits
• Extreme values
• or combination of the above cases.

White-box testing

Another test method is the white-box testing:

→ Test of the internal structures, used data structures, internal design, code structure, and the working of the software.
→ Code coverage analysis helps to analyse the code coverage of an application.
→ White-box testing method is used in SW Unit testing phase but can also occur in SW integration testing to verify the SW design is implemented in accordance with the requirements.

Related to the software, it verifies:

• Structured paths in the coding process
• Flow of specific paths through the code
• Loops, decision conditions
• Function & modules on an individual basis

On hardware level:

• Test of the internal logic, architectural blocks if applicable
• Test of safety mechanisms on block/component level
• Functions & modules

The advantage of the white-box testing method is that hidden errors, e.g in the code, can be successfully identified. On the downside this method often proves to be highly complex and time-consuming.

Other methods for evaluation of test cases

I’d like to wrap up with an introduction of the second part of this blog series. In the next instalment of the “Verification in ISO 26262” blog we’ll discuss other methods used for deriving test cases, such as boundary value analysis and error guessing. Additionally, we will examine various examples of their application, while also taking closer look at some examples of generation of equivalence classes in different applications. Stay tuned!

By Dijaz Maric, Quality Management & Reliability Engineering Consultant