Page History
Set Data  

 
4 
Excerpt  

 
Specific recommendations for verifying software requirements with multiple conditional statements. 
...
0  1. MultiLogic Testing  Definitions 

1  2. When Conditions Are Not Discrete 
2  3. Summary 
3  4. Resources 
4  5. Lessons Learned 
...
id  tabs1 

1.1 MultiLogic 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)
Note 

The recommendations in this topic are for functional software requirements

1.2 MultiLogic Condition Requirements
...
 Multilogic 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 Multilogic Condition Requirements
1. If possible, rewrite software requirement to eliminate multilogic 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^{3})
 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.
 To find minimum set of required test cases
...
...
 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)
...
Note 

Using same methods used to find MCDC minimum set of unit tests: for n logic conditions (operands) n+1 tests will sufficiently verify the requirement. 
...
id  tabs2 

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.”
...
...
id  tabs3 

3. Summary  Verifying Multilogic Condition Requirements
...
Swerefn  


...
Swerefn  


...
 Therefore, we need to decouple requirements testing from implementation
 Only way that can be assured is by running all permutations
...
See SWE134  Safety Critical Software Design Requirements for additional guidance.
...
id  tabs4 

4. Resources
4.1 References
refstabletopic 

...
group  confluenceusers 

...
titleColor  red 

title  Visible to editors only 
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
...
Div  

 
5. Lessons LearnedCurrently there are no Lessons Learned identified for this topic. 