4

...

...

 1.1 Multi-Logic Testing – Definitions

...

• Confirmation that products properly reflect the requirements specified for them. Verification ensures that “you built it right.” (Source: IEEE 1012)

• Software Integration Testing -
• Integration testing examines if the individual components developed and tested separately, interact as expected when they are combined to form a part of a larger system. (Source: IEEE)

• Integration Testing -
  • Integration testing examines if the individual components developed and tested separately, interact as expected when they are combined to form a part of a larger system. (Source: IEEE)

1.2 Multi-Logic Condition Requirements

...

• Multi-logic condition requirements complicate testing and should be reduced or eliminated, if possible

...

• If the result of “A and (B or C)” is TRUE, then the current time will be stored.
• Operators are “and” and “or”, operands are “A” , “B”, and “C” each with two possible states (i.e. True/False)
• Three operands yields a possible 2n test combinations, 8 possible test cases

1.3 Verifying Multi-logic Condition Requirements

 1. If possible, rewrite software requirement to eliminate multi-logic conditions

 2. The preferred method of verification should be test

• Inspection, Analysis, or Demonstration should only be used if test is not possible

 3. Run a test case for each possible combination of operand values (2n)

• Test all possible permutations (i.e. cover the full truth table)
• Note this method is analogous to the Multiple Condition Coverage (MCC) test method used for code unit testing

 4. If running all 2n test cases is not possible (due to hardware limitations or resource constraints):

• At a minimum, run the subset of tests to prove that varying each operand affects the result, independently
  • Must perform an analysis to determine the correct subset of tests
  • Note this method is analogous to the Modified Condition/Decision Coverage (MCDC) test method used for code unit testing

Example on the following tabs illustrate application of this recommendation. 

 1.4 Determining the Minimum Set of Tests Required

Full set of tests

Example of three operand case [If A and (B or C) then {result}]

• There are 8 possible permutations (2³)
• Running all eight test cases will completely verify this requirement

Minimum set of Required Tests

• If running all 8 test cases is not practical, then 4 test cases will ensure that varying each operand affects the result independently
  • To find minimum set of required test cases
    • Take operands one at a time and select test cases where varying only that operand, changes the result.

...

...

• Example of three operand case [If A and (B or C) then {result}]
• A test cases needed:  2 and 6
  • A changes, B and C are unchanged, and result is changed
• B test cases needed:  5 and 7
  • B changes, A and C are unchanged, and result is changed
• C test cases needed:  5 and 6
  • C changes, A and B are unchanged, and result is changed
• Total possible test cases = 8
• Total test cases needed   = 4  (2, 5, 6, 7) 

...

...

 2. Recommendations for Requirements When Conditions Are Not Discrete

Simplified Example:

• “ If mode is PROCESSING and TEMPERATURE is greater than 50.0, the software shall set a WARNING.”

The example above can be restated as: If A and (B>50.0) then set a warning.

• In this case, operand A can have two possible states but B can have many states
• Very difficult to test and analyze all combinations

...

Best practice is to run tests with values just below the limit, at the limit, and just above the limit.

• Note this method is analogous to Parameter Boundary Testing
• For each value of A, vary B just below the limit, at limit, and just above the limit

...

...

• Simplified Example: If (A < 25.0) and (B > 50.0) then set a warning
• Using the same method as the last example, vary both A and B

...

...

• If (A < 25.0) then set LO_PRESS = TRUE
• If (B > 50.0) and LO_PRESS then set a warning
• In this simplified example, the number of test cases is the same (whether there is one requirement or two), but the test cases are easier to understand.

...

...

In cases where a specific operand can have a range of values best practice is to use Boundary Parameter Testing and also select values in the middle of the range

Example:

• “ If (PRESURE > 25) and (PRESSURE < 45), the software shall set PRESSURE_OK.”

...

...

3. Summary - Verifying Multi-logic Condition Requirements

...

...

...

• Therefore, we need to decouple requirements testing from implementation
• Only way that can be assured is by running all permutations

...

See SWE-134 - Safety Critical Software Design Requirements for additional guidance. 

...

4. Resources

4.1 References

...

...

Enter the necessary modifications to be made in the table below:

...

SWEREFs called out in the text: 083, 278

SWEREFs NOT called out in text but listed as germane: none

...